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

Agenda Software Architecture Object oriented Analysis 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 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

“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 Deep Domain-Specific Software Architectures Application Domain Knowledge Architectural Patterns Styles (Program) Design Patterns Shallow Programming (language level) Scope Application Structure System Structure

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

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

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

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

Object Oriented Analysis

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

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

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

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

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

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

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?

Domain Modeling

Use-case Modeling & User Stories