software architecture & object oriented analysis nupul kukreja 3 rd october, 2014
TRANSCRIPT
Agenda• Software Architecture– Styles & Patterns– Handling ‘-ilities’
• Object oriented Analysis– Why OOA and OOP?– What is OOA?– Starting with OOAD
Software Architecture• Principle design decisions about a system• Manifest as a system’s:– Components– Connectors– Topology/Configuration
• All pervading Global system impact• Involves:– Process of arriving at principal design decisions– Creation of artifacts reifying the decisions
“Why” Architecture?• Communication among stakeholders– Mutual understanding, negotiation, consensus
• Early design decisions– Analyzing future impacts of decisions
• Transferable abstraction of a system– Can transfer knowledge of how elements work
together, across other systems
Architectural Analysis• Constraints on Implementation• Dictates organization structure (i.e., WBS)• Inhibits/Enables system’s quality attributes
(a.k.a., levels of service)• Predict system qualities by studying
architecture• Easier to reason about and manage change• Aids in evolutionary prototyping• Enables more accurate cost/schedule estimates
Architecture Reusability• Architecture reuse >> code reuse– Experience reuse– Requirements reuse– LOS reuse
• Software Product Lines• COTS integration for large systems• Less is More: – Minimize design complexity of system being built– Pays to restrict to small set of design alternatives
• Permits template based development• Can be used as basis for training
Examples of Past Experience
(Program)Design
Patterns
Styles
ArchitecturalPatterns
Domain-Specific Software Architectures
Appl
icati
on D
omai
nKn
owle
dge
Scope
Shallow
Deep
Syst
emSt
ruct
ure
Prog
ram
min
g(la
ngua
ge
leve
l)
Appl
icati
onSt
ruct
ure
Architectural PatternsDefinition: Named collection of architectural design decisions that are applicable to a recurring design problem, parameterized to account for different software development contexts in which that problem appears• State-Logic-Display (3-Tier)• Model-View-Controller (MVC)• Sense-Compute-Control
Architectural Styles• Definition: Named collection of architectural
design decisions that1. Are applicable in a given development context2. Constrain architectural design decision that are
specific to a particular system within that context
3. Elicit beneficial qualities of the systems
• Main program and sub-routines• Object-orientedLanguage Influenced
• Virtual Machine• Client-ServerLayered
• Batch-sequential• Pipe-and-filterDataflow Styles
• Blackboard• Rule-basedShared Memory
• Publish/Subscribe• Event-basedImplicit Invocation
• Interpreter• Mobile codeInterpreter
• Representational State Transfer (e.g. WWW)REST
• (e.g. Gnutella, Skype, Napster etc.,)Peer-to-Peer
Breaking The Rules• Remember - patterns and styles are abstractions– Design guides from past experience– Not rules engraved in stone
• OK to deviate, but you should do so for a reason• Example: An existing layered architecture must add
role-based security.– LDAP is chosen as both the authentication and
authorization tool (single, gold standard).– All front-ends must support user authentication– Before any action is performed, the system must validate
that the user is authorized to perform the action.
“How” to Architect1. Choose module to decompose (initially whole
system)2. Choose architectural drivers (functionality + LOS)3. Choose an architectural pattern/style satisfying the
drivers– Apply tactics for achieving ilities to drivers
4. Instantiate modules and allocate functionality5. Define interfaces of child modules6. Verify and refine use cases and LOS scenarios and
make them constraints for child modules7. Repeat
Why OOA/P/D• Procedural Programming– High coupling– Spaghetti code– “How” is paramount
• Object-Orientation– “Data” is paramount– Operations are performed on data and are coupled
with that data– Explicit representation of commonality– Tackle more challenging domains– Improves analyst domain expert interaction
15
Object Oriented Design• OO in the `60s & `70s – Informal notions– Simula, Smalltalk
• In `82, Grady Booch coined the term Object Oriented Design– The idea was to combine a design methodology
with language constructs that implement design concepts
– Objects in design space are classes in implementation space
16
OOP• Major features include– Encapsulation• Access is restricted (separation of concerns, no
spaghetti code)
– Message passing• Well-defined interfaces to the outside
– Inheritance• Reuse, subtypes
17
What Are Objects?• Three key attributes:– State• The collection of information known to an object• State changes are a consequence of operations
performed on an object
– Operations• The actions that can be performed on an object
– Identity• Two objects with identical state are still different from
one another
Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann
18
Design Goals for OOD• Booch defined three goals– Identify the objects/classes– Identify the functionality of these objects/classes– Identify the relationship between these
objects/classes• This is an iterative process– Decisions in design space are complex– Identification and specification of one aspect of a
class might force changes in other aspects
Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann
19
Simple Methodology• Objects are nouns in a problem statement or
requirement• Operations are verbs in the problem statement or
requirement– A user shall be able to delete a message from a mailbox
• Relationships are found by looking for use, aggregation, and inheritance– “is-a” & “has-a” statements– Basic Use: Does an operation of Object A modify, require, or
produce an Object B?– Aggregation: Does Object A have a reference to Object B?– Inheritance: Does Object A contain all aspects of Object B?
Are all operations on Object B therefore allowed for Object A?Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann
20
Beyond the Simple Methodology• Good for very constrained problems, but not
larger, more complex software systems.• What about NFPs, levels of service, interaction
with software frameworks and middleware?• Largely ties back to reasoning about the
Software Architecture.• What about past experience?