INFO2414 BIT Object-Oriented Systems Analysis & Design 2.1 © Copyright De Montfort University 2005...

INFO2414 BIT Object-Oriented Systems Analysis & Design 2.1 © Copyright De Montfort University 20052414T02.ppt All Rights Reserved

INFO2404BIT Object-Oriented

Systems Analysis & Design

Revision Lectures Dave Bell’s own composition

School of Computing

INFO2414 BIT Object-Oriented Systems Analysis & Design 2.2 © Copyright De Montfort University 20052414T02.ppt All Rights ReservedINFO2404 Object-Oriented Systems Analysis & Design 6.2 © Copyright De Montfort University 20092404T06.ppt All Rights Reserved

What is a Software Development Process?

Role

ArtifactsWorker

in

Activities

performs

deliver

{ordered}


The Four Phases of the Software Development Life Cycle

Any software-intensive development can be said to have these four phases in its development life cycle• Inception

• Purpose is to make a business case, or justification, for making a new product (or major upgrade to a legacy system)

• Elaboration• Purpose is to analyze the solution, develop a plan that

factors in risk, and design the solution• Construction

• Purpose is to physically implement the product including programming source code, executables etc.

• Transition• Purpose is to hand over the completed product and any

support required to use it


The Four Phases of the Development Cycle

Time

Inception

Elaboration

Construction

Transition

ProductRelease

The concept

Analysis and design

Physical implementation

Transfer of product to owner or

user

In each phase workers in roles perform activities to deliver artifacts


Milestones and Artifacts (1)

Each phase is marked by a milestone• The collected set of objectives for that

phase Typical key objectives are:

• Inception• Formulation of core requirements• Initial risk assessment• (optionally) conceptual prototype

• Elaboration• Model of system behaviour (including context,

scenarios, domain model, baseline product vision)• Development plan• Evaluation criteria


Milestones and Artifacts (2)

•Construction•Executable codes•Deployment plan•Quality assurance results• (Optionally) a behavioural prototype

•Transition•Completed artifacts of the project


Phase Milestones

Time

Inception

Elaboration

Construction

Transition

ProductRelease

ObjectiveMilestone

ArchitectureMilestone Operational

CapabilityMilestone


Characteristics of OO Development Processes

Object-Orientation is Model-Driven• Multiple OO models are built in an OO process

Both the ‘problem space’ and the ‘solution space’ are modelled with objects• And, usually, a specification model is built to map

between the other two The development process amounts to

• Building the different models for different spaces• Each model is populated with appropriate UML

diagrams• Managing the transition from one to another

Most OO processes are also• Use-Case driven• Iterative and Incremental• Architecture-centric


Model-Driven Development

TestModel

Problem Space Models(also known as ComputationallyIndependent Models – CIM)

e.g., Proposal Business Model

Inception

Specification Models(also known as PlatformIndependent Models –PIM)

Elaboration

e.g., Use Case Model Analysis Model Design model

Solution Space Models (also known as PlatformSpecific Models –PSM)

Construction Transition

e.g., Implementation Model Component Model Deployment Model


A Lightweight Roadmap

Inception Elaboration Construction Transition

Proposal

Use Case Model

expressed as

AnalysisModel

realised by

Design Model

refined as

implemented as

Variousphysicalmodels(outsidescope ofthis module)



Proposal/Business Model• Vision - A description (agreed with the Customer)

of what the system-to-be-built is to achieve• Plan - Evolution Cycles• Risks -what might make the project fail, become

delayed, go over budget• Business Case-value added by the project

Use Case Model• Use Case descriptions -In template form• A supporting (set of) UML Use Case Diagram(s)• Other (not necessarily UML) documentation

• e.g. non-functional requirements



Analysis Model - Use Case Realization- Analysis• UML analysis class diagram for each Use Case

• Candidate classes are extracted from the Use Case descriptions

• providing a structural view• UML Communication diagrams

• Use CRC cards to explore the interactions between the candidate classes

• providing a dynamic view Design Model - Use Case Realization- Design

• UML design class diagram – GUIs, storage etc.• UML Sequence Diagrams, State Machine Diagrams,

Activity Diagrams – express various aspects of design


Moving to Physical Implementation

The conceptual design expressed in the Design Model needs to get mapped into physical implementations

This may involve• An Implementation Model

• Comprising UML Component Diagrams– Showing physical code dependencies

• Source code in a target programming language• Other supporting documentation

• A Deployment Model• Using UML Deployment Diagrams

– Showing physical distribution across nodes (processors)


What is CASE?

“Computer Aided Software Engineering (CASE) are the software tools that provide automated support for some portion of the systems development process”

(Hoffer,2002)


CASE Tools

Support activities occurring across several phases of the systems development lifecycle

• Act as a guide the development process. CASE provide

• tools to create diagrams, forms & report definitions

• facilities for analysis, reporting and code generation

• shares and integrates data across and between tools

Rely on common terminology, notation and system development methods

Use a common repository to allow data to be shared between tools and SDLC activities


CASE Tool Components Vary depending on which CASE tool is considered but in

general will include:• diagramming facilities• means of describing/defining functional and data

objects• means of identifying relationships between system

components• central repository of system information• error checking facilities (syntax errors)• consistency and completeness checks• user interface generators• database specification• code generators• project management aids• documentation generators• features for group working (e.g. version control,

security)


Traceability from Design to Analysis

In a well-formed process there is a <<trace>> dependency between the Analysis Classes and their corresponding Design classes

This means that the value of any attribute modelled in an Analysis class should be theoretically retrievable from the Design Class• Remember attributes in Analysis are conceptual• No design decision has been made as to how they

should be represented in code Validation and verification of the design

includes this ‘retrieval test’• i.e., Can the design deliver the value of this

attributeINFO2404 Object-Oriented Systems Analysis & Design 13.17 © Copyright De Montfort University 20102404T13.ppt All Rights Reserved


Retrieval Example (1) Consider an Analysis class called Bank Account• It has a public attribute called balance

There are at least two ways in design of finding its value for any instance• Querying the object for the current value

of a private, stored data member (attribute)

• In which case methods need to be added to make sure the value is up-to-date

• Asking it to calculate the balance from the values of all its transactions

• In which case no data member called balance is needed, but more processing needs to be done

class Class Model

Bank Account 1

- accountNumber: int- balance: int- etc.: int

+ getBalance() : void+ updateBalance() : void

class Class Model

Bank Account 2

- accountNumber: int- etc.: int

+ getBalance() : void

INFO2404 Object-Oriented Systems Analysis & Design 13.18 © Copyright De Montfort University 20102404T13.ppt All Rights Reserved


Retrieval Example (2)

These are two completely different design solutions• Both pass the retrieval test• But processing takes place at a different point• Storage requirements differ

N.B. Deciding how to represent attributes is one of the last design decisions you should make• Choices about data structures and algorithms

tend to have the biggest impact on performance



States

States are steady conditions that an object remains in for an interval of time (between two events).

Events trigger changes to new steady states (i.e. discrete states).

A state is an abstraction of an object’s attribute and association values.



State Machine Diagrams

A state Machine diagram is prepared for every object class with non-trivial behaviour.

State Machine diagram shows:• All events affecting that class;• All its possible states.

Used to:• Cross-check against Sequence Diagrams;• Identify operation triggers/parameters

/constraints.



State Machine Diagrams - UML Notation

Class Name

State 1

entry/ actiondo/ activityexit/ action

Start State 2

End

event(parameters)[condition]/action



Solution:flight arrives at gate(flightno, gate)/ ^gate.occupied(flight no.)

waiting

do: display details

cleared for passengers

loading

do: display ‘go to gate’

boarding

do: display ‘boarding’

cleared for boarding

departed

entry: clear display

flight departs/ ^gate.cleared()



State Machine Diagrams - Transitions

Event(arguments)[Condition]/Action• Actions are processes that occur quickly are

associated with transitions and not interruptible• Conditions (a.k.a. Guard) return a logical

True/False - the transition occurs on True• When there is no Event in the label the transition

occurs as soon as the activities of the current state are completed

• A Send-clause is a special case of an action: ^dest-expression.dest-message-

name(argument)



State Machine Diagram: Order Processing

[All items checked &&all items available]

Delivered

[All items checked && some items not in stock]

Item received[Some items not in stock]

Item received[all items available]

Checking

do/ check item

Waiting

Dispatching

do/ initiate delivery

[Not all items checked/get next item

OrderStart

/get first item

Delivered

(Fowler, 2004)



State Machine Diagrams - Superstates

Where transitions may occur from several states to a single state the State Machine Diagram may show this single state as a Superstate (Nested States)

•e.g. a Purchase Order may be cancelled at any point prior to delivery.

This may be drawn with several transitions or by creating a Superstate



Solution:

Cancelled


Delivered




Cancelled

Checking

do/ check item

Waiting

Dispatching


Cancelled

[Not all items checked/get next item



State Machine Diagram: Superstates

(Fowler, 2000)

Active

Checking

do/ check item

Waiting

Dispatching


Checking

do/ check item

Cancelled

Waiting

Dispatching


[Not all items checked] /get next item


Delivered




Cancelled

Start

Delivered



Relationship to Class Diagram

The class for which the State Machine is drawn must be present on the Class Diagram.

A status attribute should be present to hold the state of the object.

Events on the State Machine are equivalent to Public Operations in the Class Diagram.

Entry/Action, Exit/Action and Do/Activity within a State will normally be equivalent to Operations in the Class Diagram.

A Send Clause is equivalent to an Operation in a destination class.



Interaction Diagrams

In design Sequence Diagrams are often preferred to Communication Diagrams• Primary focus is on finding detailed, chronological

sequences of actions• Communication Diagrams, in contrast, focus on

the existence of objects and links

These diagrams are isomorphic• i.e., the underlying information is the same• Visual emphasis is different• Often a menu press in CASE tools to generate one

from the other (not in Enterprise Architect™)



Sequence Diagrams

Sequence Diagrams illustrate object interaction

Often start from converted Communication Diagrams in Use-Case Realization - Analysis

• Therefore start with an actor instance• Each Design Class identified in the previous step

should have at least one design object in the Sequence Diagram

• Messages are shown between object lifelines to realize the use case

• Temporary names for message may be used initially• Until the operations being invoked on the

receiving objects are determined



Sequence Diagram: Example 1

: AccountHolder : ATMDialog : Transaction : AccountsList : Account

enterBankCard(acNo:String) Transaction(acNo:String) Account:=isValid(acNo:String)

enterPIN(pinNo:String)pinEntered(pinNo:String)

requestWithdrawalOptions( )

boolean:=isValid(pinNo:String)

withdraw(amt:Money) withdraw(amt:Money)debit (amt:Money)

cardWithdrawn( )

cashWithdrawn( )terminate( )



Sequence Diagrams: Notation

A message is shown with a horizontal solid line from the lifeline of one object to the lifeline of another object.

The arrow is labelled with the name of the message (operation or signal), argument values and optionally a sequence number.

The vertical axis indicates the passage of time

The labels on arrows reflect the corresponding names on messages• The full syntax is eventName(args)[condition]/action ^send clause



Sequence Diagrams: Notation

A procedure call is shown by a full arrowhead. Sending objects are blocked.

A return (optional) is shown by a dashed arrow.

Timings may be shown on the diagram for messages or operations. These can be used to specify constraints.



Sequence Diagrams

An X at the bottom of the lifeline of an object indicates its destruction

The creation of an object can be shown by positioning its icon on the timeline where it is created



Sequence Diagram: Example 2sd View Account details

Client

(from Actors)

:View Account Details

:Account

ref

View History

ref

View Open Orders



Sequence Diagram: Example 3sd View History

Client

(from Actors)

:View History

:Account :Transaction

retrieveAccountDetails()

loadAccountHistory()



Sequence Diagram: Example 4sd View Open Orders

:View OpenOrders

:Account :Transaction

Client

(from Actors)

loadAccountDetails()

loadOpenOrders()



Designing Associations

The navigability of each association needs to be analysed to determine whether it is

a one-way association

or

a two-way association

i.e. how is message passing initiated between objects

Lecturer Course

BookBorrower



Designing Associations

Depending upon multiplicity we may use collection classes

In general we ask questions about object visibility (navigation)

• does object A need to know object B's object-id?

• does it need to provide third-party objects with the object-id?

If ‘yes’ to above & if A does not receive the object-id in message parameters when it needs it then A needs the object-id



Designing Associations1 : 0..* - with one-way navigation

Customer List of Orders is a collection class. Its operations are concerned with the behaviour of the collection

What does the 1:1 multiplicity above suggest?

Customer

customerListOfOrdersObjectID1 111

Customer List of Orders

orderObjectID[0..*]

addOrder()removeOrder()getFirstOrder()getNextOrder()

1 0..*0..*1 Order

<<uses>>



Designing Associations 1 : 0..* - with two-way navigation

This placement of object ids permits navigation from Customer to CustomerListofOrders and from CustomerListofOrders to Customer.

A collection is not needed between Order and Customer as the navigation is from the 0..* end towards the 1 end i.e. sending a message to one object only.

1

Customer

customerListOfOrdersObjectID

1 0..*

1 11 1


orderObjectID[0..*]


1 0..*0..*1Order

customerObjectID

0..*

<<uses>>



Designing Associations 0..* : 0..* - with two-way navigation

How would we design the following * to * association with two-way navigation?

Consider• Collection classes• Placing of object identifiers.

Student 0..* 0..*0..*0..* Module



Suggested Solution:

Note that each Student has a ModuleList and each Module has a StudentList

StudentList OfModules

moduleObjId[0..*]

addModule()removeModule()getFirstModule()getNextModule()

ModuleList OfStudents

studentObjID[0..*]

addStudent()removeStudent()getFirstStudent()getNextStudent()

Module

moduleListOfStudentsObjID

0..*

0..*

0..*

0..*

1

1

1

1

Student

studentListOFModulesObjID

1

1

1

1

0..*

0..*

0..*

0..*

<<uses>>

<<uses>>



Adding Collection Classes to Sequence Diagrams

The collection Class is added to the Sequence Diagram in the Design Model

This illustrates the message passing sequence that will allow the customer object to find and send a message to its linked order objects

Customer

customerListOfOrdersObjectID1 111


orderObjectID[0..*]


1 0..*0..*1 Order

<<uses>>



Adding Collection Classes to Sequence Diagrams

The customer object requests from the collection object the objID (memory address) for the order.

This is assigned to the variable “order” which is then used as the parameter of the getOrderDetails() message


sd Collection Classes - Sequence Diagram

:Customer :Customer List ofOrders

:Order

order:=getOrder() :objID

getOrderDetails(order)


A pattern-based approach

Larman (1998) calls a DM object a “Database Broker” - he argues:

Class could be responsible for its own storage......but:

•highly coupled (to storage mechanism)• lessens class cohesion•class must now have expert knowledge of

storage tasks• these are un-related to application tasks

Solution: indirection (adding a go-between)



Database Broker

Database Broker object is responsible for:-•“materialising” objects•“de-materialising” objects• caching objects

Application class is insulated from storage Allows migration of storage sub-systems

• e.g. implement on existing relational system• Replace this with ODBMS• Application programs unaffected by change



Caching objects

Objects can be cached for efficiency The cache is a collection maintained

by the database broker When an object is requested, the

cache is searched first If the object sought is not in the

cache it is materialised by the database broker from the database



Transaction management

Multiple caches can be used for transaction management:• new clean cache• old clean cache• new dirty cache• old dirty cache• new delete cache• old delete cache

PFWBroker

inCache(ObjId)material iseWith(ObjId)objectWith(ObjId)

Object Cache

add(ObjId)find(ObjId)isEmpty()

61

clean = unmodifieddirty = modified



Larman’s Database Broker PatternObject Cache


PFWBroker

inCache(ObjId)materialiseWith(ObjId)objectWith(ObjId)

61 61

Relational Broker

currentRecordAsObject()materializeWith(ObjId)selectFirst()

ApplClass1RB ApplClass2RB ApplClass..n..RB...



Larman’s Database Broker – Example 1Object Cache


PFWBroker

inCache(ObjId)materialiseWith(ObjId)objectWith(ObjId)

Relational Broker

currentRecordAsObject()materializeWith(ObjId)selectFirst()

61 61

Order

Order Relational Broker

1

1..*

Order Line

Order Line Relational Broker

1

1..*

1

1..*

1

1..*

Stock Item

Stock Item Relational Broker

1

1..*

1

1..*



Larman’s Database Broker - Example 2class Cottage Booking System

Customer

- address: char- eMail: char- name: char- number: int- phoneNumber: char

Booking

- arrivalDate: date- bookingDate: date- bookingStatus: int- departureDate: date- numberOfGuests: int

Cottage

- cottageAddress: char- cottageCode: int- facil ityCode: int- keyHolderPhone: char- priceBand: money

Owner

- eMail: char- ownerAddress: char- ownerName: char- ownerPhone: char

Customer Relational Broker

Booking Relational Broker

Cottage Relational Broker

Owner Relational Broker

Relational Broker

+ currentRecordAsObject() : void+ materializeWith() : void+ selectFirst() : void

PFW Broker

+ inCache() : void+ materializeWith() : void+ objectWith() : void

Object Cache

+ add() : void+ find() : void+ isEmpty() : void

*

owns

1*

isFor

11

makes

*

1

*

1

*

1

*

1

*

1 6



Patterns - Recap

Design Patterns are elements of reusable software• inspiration from the built environment

• Christopher Alexander, architect has written about patterns since at least 1973

• now a thriving “patterns community”, e.g. see:

• Patterns Home Page (http://www.hillside.net/patterns)

• Portland Pattern Repository (http://c2.com/ppr/index.html)



Patterns - Recap Patterns are often presented as class

diagrams• But this can lead to confusion between patterns and

reusable components• Patterns are described in template formats in which

the diagram is just one section• Depicting roles played by collaborating elements

Patterns describe general solutions to common, recurring design problems in particular contexts• Can be applied “a million times over” without being

used the same way twice A pattern is a named structure together with

the steps needed to create that structure• Captures expertise that can be reused by non-

expertsINFO2404 Object-Oriented Systems Analysis & Design 21.55 © Copyright De Montfort University 20102404T21.ppt All Rights Reserved


Design Patterns Eric Gamma et al described 23 patterns

categorised as:• Creational (5) - Patterns that deal with the

creation of objects at run-time• Structural (7) - Patterns that deal with the

layout and distribution of responsibilities between classes and objects

• Behavioural (11) - Patterns that deal with complex behaviour

In this lecture we look at Creational and Structural patterns• Behavioural patterns will be examined in the

next lecture

Other Design Patterns introduced by authors such as Larman (1998) and Grand (1998)



Characteristics of Software Design Patterns

Problem, not solution-centred• First step in using them is to identify the design

problem, then look for the common solution May focus on “non-functional” aspects Discovered, not invented

• Represent ‘best practice’ as seen in previously successful designs

Complement, do not replace existing techniques.

(Gamma, 1994)

Eric Gamma et al, (1994) “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley



Creational Patterns: Singleton

Singleton

-uniqueInstance-singletonData

+instance()+singletonOperation()+getSingletonData()-Singleton

Solution: the Singleton patternThis is the name of a role; it is not the name of the class in a

real system

Underlined attributes are ‘class-

scope’ attributes

Underlined operations are ‘class scope’ operations

Returns a unique

instance ID

The constructor is private and therefore inaccessible

to clientsINFO2404 Object-Oriented Systems Analysis & Design 21.58 © Copyright De Montfort University 20102404T21.ppt All Rights Reserved


Structural Patterns: Composite

Leaf

operation()

Client

Composite

operation()add(component)remove(component)getChild(int)

Component

operation()add(component)remove(component)getChild(int)

0..n0..n

Solution: the Composite pattern



Composite Example:

Graphic

drawgetChildremoveGraphicaddGraphic

CompositeGraphic

drawgetChildremoveGraphicaddGraphic

Line

draw

Rectangle

draw

Circle

draw

Client 0..*

Inheritance ensures the composite (e.g., a ‘grouped’ picture) has the same operations

as the ‘primitives’ that make it up



Façade PatternSolution: the Façade pattern. NB This is the basis for componentware

Client

fc

ba

d

e

Facade

n

1

n

1

Uses

g

This class is a kind of ‘postbox’ for the classes that do the real work in the package. It does nothing itself, but delegates

messages to the classes inside the package that it knows



Behavioural Patterns

Recall there are three categories of patterns in the Design Patterns book• Creational, Structural and Behavioural

Behavioural patterns deal with complex behaviour

The State Pattern is one of 11 behavioural patterns in the Gamma book (23 patterns in all)• Can be seen in most object systems.



The State Pattern

Deals with the ‘promotion’ of attributes to classes

Presents a simple, powerful idea:• i.e., make the state of an object an object in its own

right. Implemented differently in different contexts:

• As is true of most patterns• depending on the particular benefit sought in a

“trade off”• Remember that design choices almost always

making trade offs We will view the pattern in its Gamma form

and then apply it to a simple Library problem• To see some variations in its application



The State Pattern

Problem:• How do you represent state when an object’s

behaviour changes depending upon its current state

Forces:• State is often represented by the value of attributes

in a class• But if behaviour depends upon current state, each

operation will have to check the values of state operations

• Switch statements or nested ‘If…else’ statements are expensive nd difficult to maintain

• If new states are added then each operation’s method that checks state has to be changed, retested etc.



State Pattern - Structure

Contextrequest( )

State {abstract}handle( )

ConcreteStateA ConcreteStateB

handle( ) handle( )

state->handle( )

state

Applicability: •use when behaviour depends on state, and must change its behaviour at run-time depending on that state or

•operations have large multi-part conditional statements that are dependent on state

This is extracted from the GOF book’s

description of the State pattern. It partly

illustrates the GOF template



Participants in the State Pattern

Context (Copy)defines the interface of interest to clientsmaintains an instance of a ConcreteState subclass that defines the current state

State (LoanStatus)defines an interface for encapsulating the behaviour associated with a particular state of the Context

ConcreteState subclasses (Available,OnLoan)

each subclass implements a behaviour associated witha state of the Context

The classes in brackets are the one’s we will use to play these

roles in the Library example



State Pattern - Collaborations

Context (Copy) delegates state-specific requests to the current ConcreteState object.

Context is the primary interface for clients.

Either Context or ConcreteState subclasses can decide which state succeeds another and under what circumstances



State Pattern example : A Library System

• Copy delegates checking itself out to its State objectpublic checkOut(user:Borrower){

currentState.checkOut (user)}

//in Availablepublic checkOut(user:Borrower) { state = OnLoan(user)}

//in OnLoanpublic checkOut(user:Borrower){ System.out.printf (“Already On Loan);}

The concrete subclasses define the method according to the state they represent

LoanStatuscheckOut(user:Borrower)

Available OnLoan

checkOut(user:Borrower) aBorrower:BorrowercheckOut(user:Borrower)

Copy

currentState:LoanStatuscheckOut(user:Borrower)



State Pattern example : Hotel Booking System

Active

Unguaranteed

guaranteeBooking()

Guaranteed

checkIn()

Registered

checkOut()

Completed

bookingPaid()

Paid

archiveBooking()

Cancelled

archiveBooking()

Booking

arrivalDatedepartureDatedateBookingMadebookingStatus

addBooking()

BookingStatus



Methodology - Definition

“A methodology is a collection of procedures, techniques, tools and documentation aids, supported by a philosophy, which will help the systems developers in their efforts to implement a new information system”

What does a methodology consist of? “A methodology will consist of phases, and sub-

phases, which will guide the systems developers in their choice of techniques that might be appropriate at each stage of the project and also help manage, control and evaluate system projects.”

(Avison & Fitzgerald, 1995)



Methodologies

Are more than a collection of tools and techniques

Should specify:• stages into which a project should be broken

down• tasks for each stage• outputs produced• support tools to use• how the project is to be managed and

controlled

All encompassed in a philosophy



The Unified Software Development Process Overview

Provides disciplined approach to assigning tasks and responsibilities during systems development

Guide for how to use Unified Modelling Language (UML) effectively

Activities create and maintain (UML) models

Is a configurable process Unified Process is distinguished by being

• use-case driven• architecture-centric• iterative and incremental



Use Case Driven

Use Case“A description of a set of sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor.” (Jacobson et.al. 1999)• i.e. A piece of functionality that gives a user a result of

value

Development process follows a flow• proceeds through a series of workflows derived from the

use cases• use cases are specified, designed and are the source for

test cases• they drive system architecture which in turn influences

use case selection• both mature as the development lifecycle continues



Architecture-Centric

Software architecture shows different views of the system being built and embodies the static & dynamic aspects of the system (design framework)

Also influenced by the computer architecture, operating system, DBMS, network protocols etc.

Related as function (use case) and form (architecture)

The form must allow the system to evolve from initial development through future requirements (i.e. the design needs to be flexible)

Key use cases influence the design of the architecture which may in turn influence development of other use cases



Iterative and Incremental Systems development is frequently a large

undertaking - may be divided into several “mini-projects” each of which is an iteration resulting in incremental development of the system

Iterations must be selected & developed in a planned way i.e. in a logical order - early iterations must offer utility to the users

• iteration based on a group of use cases extending the usability of the system developed so far

• iterations deal with the most important risks first• not all iterations are additive - some replace earlier

“superficial” developments with a more sophisticated and detailed one.

Concepts of use case driven, architecture centric and iterative & incremental are of equal importance



Life of the Unified Process

Unified Process repeats over a series of cycles each concluding with a product release to the users

Each cycle has 4 phases (each with a number of iterations)

• Inception, Elaboration, Construction & Transition

Delivered products will be described by related models each with “trace” dependencies which chain backwards and forwards• Use Case Model; Analysis Model; Design Model• Deployment Model; Implementation Model; Test

Model



Analysis & Design Artifact Set

Captures and presents information related to the solution to the problems posed in the Requirements set.



The Analysis & Design Workflow



Analysis Activities

To identify the classes which perform a use case’s flow of events.

To distribute the use case behaviour to those classes, using use-case realizations.

To identify the responsibilities, attributes and associations of the classes.

To note the usage of analysis and architectural patterns



Design Activities

Centred around the software architecture• early iterations focus on its

production/validation• represented by a number of architectural

views

Production of the Design Model• classes structured into design packages with

well defined interfaces• how objects collaborate to perform the use

cases• check completeness and consistency of the

design INFO2404 Object-Oriented Systems Analysis & Design 23.80 © Copyright De Montfort University 20102404T23.ppt All Rights Reserved

INFO2414 BIT Object-Oriented Systems Analysis & Design 2.1 © Copyright De Montfort University 2005...

Documents

Transcript of INFO2414 BIT Object-Oriented Systems Analysis & Design 2.1 © Copyright De Montfort University 2005...