1. Software Architecture & Object Oriented Analysis
Nupul Kukreja
3rd October, 2014

2. Agenda Software Architecture Object oriented Analysis
Styles & Patterns
Handling ‘-ilities’
Object oriented Analysis
Why OOA and OOP?
What is OOA?
Starting with OOAD

3. 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
Alternate definition: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them.
Even “no” architecture is an architecture: Big ball of mud 
Every system has an architect

4. “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

5. 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

6. 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

7. Examples of Past Experience
Deep
Domain-Specific
Software Architectures
Application Domain
Knowledge
Architectural
Patterns
Styles
(Program)
Design
Patterns
Shallow
Programming
(language
level)
Scope
Application
Structure
System
Structure

8. Architectural Patterns
Definition: 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

9. Architectural Styles
Definition: Named collection of architectural design decisions that
Are applicable in a given development context
Constrain architectural design decision that are specific to a particular system within that context
Elicit beneficial qualities of the systems

10. Language Influenced Layered Dataflow Styles Shared Memory
Main program and sub-routines
Object-oriented
Language Influenced
Virtual Machine
Client-Server
Layered
Batch-sequential
Pipe-and-filter
Dataflow Styles
Blackboard
Rule-based
Shared Memory
Publish/Subscribe
Event-based
Implicit Invocation
Interpreter
Mobile code
Representational State Transfer (e.g. WWW)
REST
(e.g. Gnutella, Skype, Napster etc.,)
Peer-to-Peer
More complex styles like C2 and Distribute objects (e.g., CORBA) exists which can be thought of as a combination of the above. You can have composite/complex architectures that incorporate >1 of the above styles

11. 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.

12. “How” to Architect Choose module to decompose (initially whole system)
Choose architectural drivers (functionality + LOS)
Choose an architectural pattern/style satisfying the drivers
Apply tactics for achieving ilities to drivers
Instantiate modules and allocate functionality
Define interfaces of child modules
Verify and refine use cases and LOS scenarios and make them constraints for child modules
Repeat

13. Object Oriented Analysis

14. Why OOA/P/D Procedural Programming Object-Orientation 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 Message passing Inheritance
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 Operations Identity
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?

21. Domain Modeling

22. Use-case Modeling & User Stories