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

Software Architecture&

Object Oriented Analysis

Nupul Kukreja3rd October, 2014

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

OBJECT ORIENTED ANALYSIS

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?

DOMAIN MODELING

USE-CASE MODELING & USER STORIES