Intro 1

Object-Oriented Analysis & Design

Course Leader

Dr. S. Narayana Prasad

Duration: 8 SessionsSchedule: Wed, Thu, Fri (4 – 20 Jan)

Evaluation:Internal Assessment I (Midterm Test)Internal Assessment II

Intro 2

Text:

Applying UML and Patterns , 3rd Edition, Craig Larman, Pearson.

References:

1. Brown, D.W., An Introduction to Object-Oriented Analysis, Wiley,2nd Ed., 2004.

2. Mark Priestley, Practical Object Oriented Design with UML, TMH,2nd Ed., 2005.

3. Michael Bleha, James Rambaugh, Object-Oriented Modelling &Design with UML, Pearson, 2nd Ed., 2005.

4. Bahrami A., Object Oriented Systems Development using UnifiedModeling Language, McGraw Hill, 1999.

5. Grady Booch et al., Unified Modeling Language User Guide, PearsonEducation, 1999

6. Martin Fowler et al., UML Distilled, Pearson Education, 2000

7. Rebecca Wirfs-Brock et al., Designing Object-Oriented Software,PHI, 1996

8. Bruegge B., Object-Oriented Software Engineering, Pearson, 2000.

Intro 3

Outline• Object-Oriented Technology: Historical Background

• The Object Model: Basic Concepts

• OO Programming

• OO Analysis

• OO Design

• OO Benefits

• Software Development Life Cycle Models

• Iterative & Evolutionary Development

• Agile Models

• Unified Process Model

• UML

• UML Diagrams

• Structural Modeling: Class Diagrams

• Behaviour Modeling: Use Cases, Collaborations &Interaction Diagrams

Intro 4

Introduction to OOT

Intro 5

Object Oriented TechnologyHistorical Background

•Software Engineering: “Programming-in-the-large” OO Programming Languages & OO Programming

Methodology

•User Interface

Graphical objects on the screen

•Databases

Data models (structures & operations for large

data sets)

•Computer Architectures Capability-based architectures for large, interconnected

networks and systems

=> “Object Model”

Intro 6

The Object Model: Basic Concepts

Object: “a tangible entity that exhibits some well-defined behaviour”.

• States: structures (components andinterconnections)

• Behaviour: operations for manipulating thestructures

• Invariants: constraints on structures andoperations.

Objects can model a variety of real-world orapplication domain entities.

Example: An Elevator object has

• States: floors at which it may be positioned

• Behaviour: travel up and down

• Invariants: limited to stopping only at differentfloors

Intro 7

The Object Model: Basic Concepts

Class: a collection of objects that share commonproperties (states, behaviour and invariants).

• Class specification: defines a template of theproperties applicable to objects in the class.

• Objects are “instances” of a class: every object is amember of a class extension and derives its statesand behaviour from the class specification.

Classes and Objects unify:

• Data abstraction: states of objects are hidden andcan only be manipulated indirectly in terms of objectbehaviour.

• Procedural abstraction: A well-defined interfacespecifies the operations and invariants supported byeach object.

Intro 8

Object-Oriented Programming

[Ref: Rentsch, 1982/N-2.1]

“OO programming will be in the 1980s what

structured programming was in the 1970s. Everyone

will be in favour of it. Every vendor will say his

products support it. Every manager will pay lip service

to it. Every programmer will practice it (differently).

And no one will know quite what it is.”

• Evolved to handle the complexity of “programming-

in-the-large”

Intro 9

Object-Oriented Programming

“Programs are organized as cooperative collections ofobjects, each of which is an instance of some class,and whose classes are interrelated by a propertyinheritance relationship”

Features

• Objects (not procedures) are the buildingblocks.

• Objects are instances of classes, and combinedata abstractions (hidden local states) andprocedural abstractions (visible interfaces withspecified behaviour).

Intro 10

Object-Oriented Programming

• Is-a (property inheritance) relationship defines

a class hierarchy: “subclasses” inherit

properties from “superclasses”.

Example: Define classes Rose, Flower and Plant

Is-a relationship (denoted )

Rose Flower Plant

Subclass SuperclassRose FlowerFlower Plant

Intro 11

Object-Oriented Design

OO design involves specifying an “object-oriented

decomposition” of a system in terms of physical

and logical as well as static and dynamic models,

and a notation for defining these specifications.

Models Static (Structures)

Dynamic (Behaviour)

Logical

(Specifications)

Objects, classes, Is-a hierarchy

Operations

Interfaces

Physical

(Implementations)

Modules Processes

Intro 12

Object-Oriented AnalysisOO Analysis involves specifying requirements (applicationand system) in terms of entities (objects), properties(attributes & relationships) and operations (behaviours) inthe problem (application and system) domain.

Example: College Information System

Entities (Attributes):

Students (Name, Address, Qualification, Programme, Year, CGPA)

Teachers (Name, Address< Qualification, Designation)

Courses (Code, Department, Description, Prerequisites)

Relationships:

Course_offering <Courses, Teachers, Term>

Operations:

Enroll (Students, Courses)

Intro 13

Object-Oriented Modeling: Benefits

Object-oriented modeling enables design of well-structured complex systems through the followingattributes:

1. Expressive power of OO languages => improvement inproductivity and quality.

2. Reuse of code as well as design.

3. Flexibility in system structuring => adaptablesystems

4. Easier system integration: due to separation ofbehavioural and implementation specifications.

5. More intuitive modeling => easier understanding ofdesigns and specifications by humans.

Intro 14

Software Development Life Cycle

Intro 15

Software Development Life Cycle

Software Development Process Tasks

• Requirements Specifications

• Systems Analysis & Design

• Programming & Coding

• Verification & Validation

• Cataloguing & Configuration Management

• Project & Program Management

Software Development Process Models

• Traditional Model -> “Waterfall” Model

• Iterative Models

• Agile Models (XP (Extreme Programming), Scrum etc.)

• Unified Process Model

Intro 16

Software Development Life Cycle

Roles in Software Development Lifecycle

• Analyst & End User (Requirements specifications)

• Architect (System analysis and design)

• Developer (Implementation and coding)

• Quality Assurance (Verification and validation)

• Librarian (Cataloguing and Configuration management)

• Project & Program Management (Overall responsibility)

Intro 17

Iterative Development Process Models

Features

• Iterations: short, fixed-duration, mini-projects whichproduce tested & executable system implementationswith part functionality.

• The functionality of the implemented system grows witheach iteration.

Benefits:

• Better productivity

• Early mitigation of project risks

• Better user engagement & feedback during development

Waterfall Models

• Strict separation of the process activities into phases

• Inflexibility with reference to changing requirements

• Little user feedback & collaboration

Intro 18

Agile Process Models

Agile Manifesto

• Individuals & Interactions over Processes & tools

• Working software over Comprehensive documentation

• Customer collaboration over Contract agreements

• Flexible processes over Fixed plans

Methodology

• Use formal & informal models to understandcustomer/system requirements

• Start with simple models; add detail (complexity)incrementally.

• Developers should model (no separation between analyst,designer & programmer roles)

Intro 19

Unified Process

• Workflow: set of activities associated with the differentstages of the software development lifecycle

Development Workflows:– Business Modeling– Requirements Specification– Analysis and Design– Implementation– Testing– Deployment

Supporting Workflows:

– Configuration & Change Management

– Environment

– Project Management

Intro 20

Unified Process

Iteration: a sequence of workflows within one phase, that results in a (internal or external) “release” of a system implementation.

• Phase: a time interval with well defined milestones.

Rational Unified Process (RUP) has 4 phases:

• Inception – Initial/Preliminary that conceives of thesoftware project/product.

• Elaboration: Requirements specification andarchitectural design.

• Construction: detailed design and implementation.

• Transition: system release and user acceptance.

Intro 21

Agile Unified Process

• Start with a small set of workflows & artifacts

• Requirements & design evolve incrementally over

multiple iterations

• Employ a flexible language & tool like UML

• Project Planning

• Phase Plan: high-level plan for the entire project

• Iteration Plan: detailed for each iteration

Intro 22

Software Development with UML

An UML-based software development process is:

• Use Case-driven: use cases are the primary model ofbehaviour.

• Architecture-centric: system modeling is based onthe architectural principles.

• Incremental: system functionality, design andimplementation evolve in incremental stages.

• Iterative: multiple iterations of requirements, designimplementation and release life cycles.

Intro 23

UML

Intro 24

System Modeling

Modeling Basics

• “A model is a simplification of reality”

• “Complex systems cannot be comprehended withoutmodels”

• “Models enable better understanding of the systemunder development”

Examples:

1. Architectural models -> Plan, Elevation, Structureetc. drawings

2. Physical models -> Wind tunnel models of aircraft.

3. Mathematical models -> Weather systems modeledby a set of mathematical equations.

Intro 25

System ModelingPurposes of Models

• Visualization of systems.

• Specification of system structure and behaviour• Template that guides design and construction.

• Documentation and communication of design choices,decisions.

Informal Models• Architecture: Sketch on a blackboard

• Software Development: Class-Responsibility-Collaboration (CRC) cards

Formal Models

• Building Construction: Blueprints showing views

• Electrical System: Circuit diagrams

• Aircraft Design: Wind tunnel scale model

Intro 26

UML History

Object-Oriented Paradigm

• Mid 1970s – Late 1980s -> O-O modeling languages

• 1989 – 1994 -> # of O-O methods grew from 10 to 50

O-O Methodologies

• Booch (Rational): software design and construction

• Jacobson (Objectory): OOSE (Object-Oriented SoftwareEngineering) for requirements specifications, analysis andhigh-level design)

• Rumbaugh (GE): OMT (Object Modeling Technique) foranalysis and data-intensive applications.

• Fusion

• Shlaer-Mellor: Real-time systems.

• Coad-Yourdon: Structured design

Intro 27

UML History

UML resulted from a project to unify the Booch, Jacobsonand Rumbaugh methodologies.

Goals of UML:

1. Model systems from concept to executable systemusing O-O techniques.

2. Provide scalability to handle large, complex andmission-critical systems.

3. Provide a language suitable for human understandingas well as machine processing.

Time line:

Oct 1994: Start of “Unified Method” project by Boochand Rumbaugh at Rational

Intro 28

UML HistoryTime line (continued):

Oct 1995: Draft version 0.8 released; Jacobson joins theteam.

Jan 1997: UML version 1.0 released; Offered to OMG (ObjectManagement Group) for standardization.

Jan – Jul 1997: Group of partners working on the design of thelanguage expanded.

July 1997: UML version 1.1 offered to OMG forstandardization.

Sep 1997: UML accepted by OMG’s ADTF (Analysis & DesignTask Force).

14 Nov 1997: OMG’s Architecture Board accepts UML as astandard

June 1998: OMG RTF (Revision Task Force) releases UML 1.2

Fall 1998: RTF releases UML 1.3

Intro 29

Standard Diagrams in UML Models

Common levels of abstraction: specification mappings

View Diagram

Requirement Specifications Use Case diagram

Design Specifications Collaboration diagrams

Implementation Specifications Component diagram

Deployment Specifications Deployment diagram

• Within each view, further abstraction levels can bedefined.

Intro 30

UML Class Diagrams

• Capture static, structural aspects of the model.

• Primary constituents - Classes, Interfaces,Collaborations and Relationships.

• Additional constituents – Packages, Subsystems,Instances.

• Foundation for component and deployment diagrams.

Modeling simple collaborations

1. Define a mechanism for the collaboration –participating classes, interfaces, collaborations andrelationships.

2. Start by sketching a basic framework.

3. Refine iteratively.

Intro 31

UML Class Diagrams

Data Modeling Example

member

0..1

Company

Department

name: String

Office

address: Stringphone: Integer

Headquarters Person

subset

manager

Location

*1..*

1

*

* *

*

*

1..* 1

Intro 32

UML Class Diagrams

Department

Person

Name: String

employeeID: Integer

Title: String

getPhoto (p: Person)

getContact ()

getPersonRecords ()

ContactInfo

Address: String

PersonnelRecordtaxIDemploymentHistorysalary

IsecureInfo Classes, Interfaces & Relationships

Intro 33

UML Sequence Diagram

: OrderTaker : OrderFulfillment

Submit order

Place order

Acknowledge order

Abstract Level 1

Intro 34

UML Sequence Diagram

: BillingAgent: OrderTaker : OrderFulfillment

Submit order

Place order

Acknowledge order

Abstract Level 2

: CreditCardAgent

ok

Process card

Trigger bill

Intro 35

Basic Behavioral Modeling

Use Cases

A use case:

• Specifies behaviour of the system in a specifiedcontext.

• Typically, corresponds to a single user transaction.

• Is defined in terms of a set sequences ofactions/events the system performs to yield anobservable result of value to an “actor” (an actor is arole played by a user or a system component in thecontext of the use case).

A set of use cases specify the functional requirementsfor the system from a user’s perspective.

Intro 36

Basic Behavioral Modeling

Use Case Diagram

Example: In the context of a Banking system, a “LoanOfficer” is an actor and “Process Loan” is a use case(executed by the actor).

Process Loan

LoanOfficer Use case

Actor

The actor is outside of and not part of the system beingmodeled and developed.

Intro 37

Basic Behavioral Modeling

Use Cases

A use case is defined in terms of a set of sequences or flowsof actions/events.

An action/event is modeled as an interaction among actorsand/or objects (in the system) exchanging messages.

Example: In an ATM system, an “Authenticate User” use case may

be defined by the following main flow of events as follows:

1. Card holder inserts card into the ATM.

2. ATM prompts for PIN number.

3. Card holder enters PIN number.

4. Card holder commits entry.

5. ATM checks validity of PIN.

6. If PIN is valid, ATM acknowledges authentication.

Intro 38

Basic Behavioral Modeling

Use Case

There are also exception flows corresponding to other scenariosduring user authentication:

“Cancel transaction” scenario

1. Card holder cancels transaction.

2. System acknowledges cancellation.

“Edit PIN transaction” scenario

1. Card holder clears entered PIN

2. Card holder reenters PIN.

“Invalid PIN transaction” scenario

1. Increment counter “Attempt_count”

2. If “Attempt_count” > 3, exit.

3. Acknowledge invalid PIN.

4. Reset.

Intro 39

Basic Behavioral ModelingUse Case ScenariosA use case scenario corresponds to one sequence of

events/actions.

• Each scenario represents a variation in or alternativesequence of events/actions.

• Scenarios are instances of a Use Case (just like objectsare instances of a class).

Use Cases and Collaborations

• A use case specifies functionality or behaviour (“what”).

• A collaboration implements a use case in terms of objectsand interactions (“how”).

• A use case is “realized” by a collaboration.

Intro 40

Basic Behavioral Modeling

Example: In an Order Processing system, a collaboration“Order Management” may realize use cases “ PlaceOrder”, “Cancel Order”, and “Track Order”

Place Order

CancelOrder

Track Order

OrderManagement

“Realization” relationship

Intro 41

Basic Behavioral Modeling

Example: An Order Processing system

<<extend>>Set priority

Place OrderExtension point:

Set priority

Place Rush Order

Track Order

Authenticate User

Retinal scan

Check Password

<<include>><<include>>

generalization

Intro 42

Collaborations and Collaboration Diagrams

Collaboration:

• A society of classes, interfaces and otherelements that cooperate together to provide aspecified behaviour.

• Encompass structural and behavioural elements.

• Structural elements -> Classes, Interfaces,Components, Nodes etc.

• Behavioural elements -> Interactions.

• A collaboration does not “own” the elements, butonly references them.

Intro 43

Collaborations and Collaboration Diagrams

Organizing Collaborations

PlaceOrder

OrderManagemen

t

OrderValidation

<<refine>>Use CaseCollaboration

realizes