Software Architecture Design I

OOAD in the Unified Process
Matthew Dailey
Computer Science and Information Management
Asian Institute of Technology

Matthew Dailey (CSIM-AIT)


1 / 54


Readings for these lecture notes:
- Larman (2005), Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative Development, 3rd
edition, Chapters 1–6.
c Larman (2005).
Some material

Matthew Dailey (CSIM-AIT)


2 / 54





OOAD Overview


UP Overview




Requirements Analysis

Matthew Dailey (CSIM-AIT)


3 / 54


It is difficult to deliver quality software that meets stakeholder needs!
OOAD is one method for tackling the problem by capturing the design in a
way that is easy to
implement, and

Matthew Dailey (CSIM-AIT)


4 / 54

The UP

OOAD need to be performed within a software development process.
The Unified Process is an iterative, risk-driven, architecture-centric
approach to software development.

Implementation &
Test & Integration
& More Design
Final Integration
& System Test


Implementation &
Test & Integration
& More Design

Feedback from
iteration N leads to
refinement and
adaptation of the
requirements and
design in iteration

Final Integration
& System Test

3 weeks (for example)
Iterations are fixed in
length, or timeboxed.

The system grows

Larman (2005), Fig. 2.1

OOAD and the UP work well together.
Matthew Dailey (CSIM-AIT)


5 / 54

Outline 1 Introduction 2 OOAD Overview 3 UP Overview 4 Inception 5 Requirements Analysis Matthew Dailey (CSIM-AIT) Requirements 6 / 54 .

public List getFlightHistory() {.. we need to know an OO language and UML. but just as important we need to think in terms of objects. OOAD is mainly about assigning responsibilities to classes of objects..} } Larman (2005).OOAD Overview To develop a system using OOAD. Fig. OOA means finding the objects and concepts in the problem domain. 1-2 Matthew Dailey (CSIM-AIT) Requirements 7 / 54 . Plane tailNumber domain concept representation in an object-oriented programming language visualization of domain concept public class Plane { private String tailNumber.

1-3 Matthew Dailey (CSIM-AIT) Requirements 8 / 54 . Fig.OOAD Overview Player 1 Rolls Die 2 name faceValue 1 2 Plays 1 DiceGame 1 Includes Larman (2005).

OOAD Overview OOD means defining the software components. Larman (2005). 1-4 Matthew Dailey (CSIM-AIT) Requirements 9 / 54 . and how they collaborate to fulfill the requirements. their responsiblities. Fig.

DiceGame die1 : Die die2 : Die Die 1 2 faceValue : int getFaceValue() : int roll() play() Larman (2005).OOAD Overview Design classes are the detailed classes necessary to fulfill requirements. Fig. 1-5 Matthew Dailey (CSIM-AIT) Requirements 10 / 54 .

incomplete diagrams sketched on a whiteboard to explore tricky problems. As a blueprint tool: detailed diagrams used for reverse engineering and code generation (forward engineering). As an end-to-end programming language: still in development. Don’t overdo UML! Matthew Dailey (CSIM-AIT) Requirements 11 / 54 . UML has 3 uses in software engineering: As a sketch tool: informal.OOAD Overview We will use the Unified Modeling Language to communicate domain and design models. We will favor agile approaches that use UML as a sketch tool.

Fig. 1-6 Later the model will be elaborated into software classes or design classes providing a solution. Larman (2005). DiceGame 1 Includes 2 Die faceValue DiceGame die1 : Die die2 : Die play() Die 2 faceValue : int getFaceValue() : int roll() Conceptual Perspective (domain model) Raw UML class diagram notation used to visualize real-world concepts. and implementation classes in a real OO language. the classes we derive will be conceptual.OOAD Overview We begin with analysis. Specification or Implementation Perspective (design class diagram) Raw UML class diagram notation used to visualize software elements. Matthew Dailey (CSIM-AIT) Requirements 12 / 54 . At this point. representing real world things in the problem domain.

Outline 1 Introduction 2 OOAD Overview 3 UP Overview 4 Inception 5 Requirements Analysis Matthew Dailey (CSIM-AIT) Requirements 13 / 54 .

Matthew Dailey (CSIM-AIT) Requirements 14 / 54 . Iterative development is now standard in the industry.UP Overview The Unified Process is an iterative development process. increase productivity. Depending on implementation in the organization. iterative development has proven to reduce defects. UP. the UP can be low ceremony and agile. and increase project success rates. Compared to traditional waterfall methods. The basic idea is short iterations that are fixed in length or timeboxed.

Final Integration & System Test 3 weeks (for example) Iterations are fixed in length. Larman (2005). 2-1 Matthew Dailey (CSIM-AIT) Requirements 15 / 54 .UP Overview Requirements Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time Design Implementation & Test & Integration & More Design Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1. or timeboxed. The system grows incrementally. Fig.

. but. it’s what I asked for. Many big projects in the 60s and 70s used iterative techniques.” Typical iterations are 2–6 weeks. They should be as short as possible. On every iteration. The benefit is it allows us to embrace change. Be careful to prevent the iterations from becoming waterfall phases! Matthew Dailey (CSIM-AIT) Requirements 16 / 54 .UP Overview Iterative development is not new. The spiral process has been around since the 1980s.. shareholders have the opportunity to say “yes.

Do 2 days of modeling on whiteboards. This is the end of the “elaboration” phase. test. e. greatest risk. Pick a subset of the detailed scenarios to design. This is the end of the “inception” phase. Stick to the plan! One week before end of the iteration: decide what will make it into the current iteration and postpone remainder to the next.g. Plan the first iteration. Repeat until 80%–90% of the use cases are fully detailed and the architecture is baselined. and integrate continuously. in a short period. Demo for stakeholders and request feedback. Program.UP Overview Example process implementation: Two-day requirements workshop to detail the 10% of your use cases with the higest business value. Matthew Dailey (CSIM-AIT) Requirements 17 / 54 . 4 weeks. and higest architectural impact. implement and test.

the requirements evolve over a set of the early iterations..UP Overview 1 2 3 4 5 . 2-4 Matthew Dailey (CSIM-AIT) Requirements 18 / 54 . 20 software software requirements In evolutionary iterative development. requirements requirements workshops Imagine this will ultimately be a 20iteration project. Fig.. 5 hours Th start coding & testing F M T de-scope iteration goals if too much work Most OOA/D and applying UML during this period week 3 W Th F M final check-in and codefreeze for the iteration baseline T W demo and 2-day requirements workshop Th F next iteration planning meeting. UML whiteboard sketching. 1 hour T W team agile modeling & design. 90% of the requirements are defined and refined. Nevertheless. 2 hours Use-case modeling during the workshop Larman (2005). Perhaps after four iterations and workshops. through a series of requirements workshops (for example). only 10% of the software is built. 90% 90% 50% 30% 20% 5% 2% Iteration 1 20% 10% 8% Iteration 2 Iteration 3 Iteration 4 Iteration 5 a 3-week iteration week 2 week 1 M kickoff meeting clarifying iteration goals with the team.

The UP is architecture centric: we focus on the architecturally significant use cases first. The UP is client driven: we build the features the client cares about most first. Matthew Dailey (CSIM-AIT) Requirements 19 / 54 .UP Overview The UP is risk driven: in early iterations we identify and mitigate the most significant risks.

UP Overview UP is compatible with the agile manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Resonding to change over following a plan Matthew Dailey (CSIM-AIT) Requirements 20 / 54 .

and testers — take ownership. Use simple tools like whiteboards before CASE tools. developers. not the simple parts. Use “good enough” notation – don’t drown yourself in the details. e. Matthew Dailey (CSIM-AIT) Requirements 21 / 54 . we should apply the principles of agility: Modeling is for understanding and communication. Don’t model alone and rotate the whiteboard marker.UP Overview When modeling. not documentation. Teams should be horizontal. static and dynamic. Be ready to throw your models away and reverse engineer from the code you wrote. Model the difficult tricky parts of the design. There is no such thing as analysts. from modeling to testing.g. Do parallel models. not vertical.

2-5 Matthew Dailey (CSIM-AIT) Requirements 22 / 54 .UP Overview Example of some practical modeling: Larman (2005). Fig.

Apply the use cases where appropriate. Practice change request and configuration management.UP Overview Best practices for UP application: Attack high risk. high value issues first. Carefully manage requirements. Continuously engage users. and realistically. Do some visual modeling. Continuously verify quality — test early. Develop a cohesive core architecture in early iterations. often. Matthew Dailey (CSIM-AIT) Requirements 23 / 54 .

and scope. Elaboration: refine the vision. Transition: beta test and deploy Matthew Dailey (CSIM-AIT) Requirements 24 / 54 . with vague estimates. easier elements. business case. further detail the requirements. resolve major risks.UP Overview The phases in the UP are: Inception: work out the initial vision. Construction: work on the lower-risk. develop the core architecture.

UP Overview development cycle phase iteration inc. final production release At this point. The difference (delta) between the releases of 2 subsequent iterations. the system is released for production use. 2-6 Matthew Dailey (CSIM-AIT) Requirements 25 / 54 . Fig. The end of each iteration is a minor release. transition release increment A stable executable subset of the final product. elaboration construction milestone An iteration endpoint when some significant decision or evaluation occurs. Larman (2005).

requirements analysis. Matthew Dailey (CSIM-AIT) Requirements 26 / 54 . and design. with different weightings in different phases. In this course. we focus on business modeling.UP Overview Each phase in the UP involves all disciplines to an extent.

A mini-project that includes work in most disciplines. Sample UP Disciplines Business Modeling Focus of this book Requirements Note that although an iteration includes work in most disciplines.UP Overview A four-week iteration (for example). Fig. the relative effort an emphasis chang over time. This example is suggestive. Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations Larman (2005). not literal. ending in a stable executable. 2-7 Matthew Dailey (CSIM-AIT) Requirements 27 / 54 .

You spend more time creating documents than programming. Matthew Dailey (CSIM-AIT) Requirements 28 / 54 .UP Overview You are doing it wrong if you notice You detail all the requirements before starting to program. You spend days or weeks on UML modeling before starting to program.

Outline 1 Introduction 2 OOAD Overview 3 UP Overview 4 Inception 5 Requirements Analysis Matthew Dailey (CSIM-AIT) Requirements 29 / 54 .

Inception is not requirements! Inception focuses on What is the vision and business case? Is it feasible? Buy or build? What’s the rough cost? Do it or not? Matthew Dailey (CSIM-AIT) Requirements 30 / 54 . which has the most weight during the elaboration phase.Inception Here we consider requirements analysis.

but they are not necessary. Most of the artifacts are pure text. Matthew Dailey (CSIM-AIT) Requirements 31 / 54 .Inception See the text for inception artifacts. Most are optional! The only UML produced in inception will possibly be use case diagrams.

design. You define the architecture. There is no business case or vision. Matthew Dailey (CSIM-AIT) Requirements 32 / 54 . You try to do requirements. No use cases are detailed.Inception You are executing inception incorrectly if: Inception takes more than a few weeks. Most use cases are detailed. and implementation.

Outline 1 Introduction 2 OOAD Overview 3 UP Overview 4 Inception 5 Requirements Analysis Matthew Dailey (CSIM-AIT) Requirements 33 / 54 .

Requirements Analysis In UP. 25% of requirements change during the project! Other studies have found that 2/3 of the features specified in waterfall requirements documents are never or rarely used! Matthew Dailey (CSIM-AIT) Requirements 34 / 54 . Studies show that on average. we manage requirements and expect them to change.

1 Poor user input 13% Incomplete requirements 12% Other 50% Changing requirements 12% Poor technical skills 7% Poor staffing 6% Larman (2005). 5.Requirements Analysis Fig. 5-1 Matthew Dailey (CSIM-AIT) Requirements 35 / 54 . Fig.

Requirements Analysis One breakdown for requirements is FURPS+: Functional Usability Reliability Performance Supportability Implementation Interface Operations Packaging Legal Sometimes we make special note of quality attributes. Matthew Dailey (CSIM-AIT) Requirements 36 / 54 . and sometimes we distinguish between functional and non-functional requirements.

Requirements Analysis The key requirements artifacts are: The Use Case Model The Supplementary Specification (a place for non-functional requirements and features that don’t fit in the use case model) The Glossary (definition of noteworthy terms) The Vision (an overview and high-level summary of the requirements) The Business Rules (cross-project requirements such as tax laws) Where to put these artifacts? A project wiki works well. Matthew Dailey (CSIM-AIT) Requirements 37 / 54 .

Requirements Analysis Use cases are text stories that are useful for discovering and recording requirements. See example (p63): Matthew Dailey (CSIM-AIT) Requirements 38 / 54 .

: Cashier system operations make NewSale() Supplementary Specification enterItem (id. terms. Customer arrives . goals. associations scope. . quantity) non-functional reqs. Fig. actors. features Use-Case Model Vision Process Sale Process Sale use case names Cashier Requirements 1. ..Requirements Analysis Sample UP Artifact Relationships Domain Model Sale Business Modeling 1. quantity ) Larman (2005).. quantity) spec = getProductSpec( itemID ) addLineItem( spec. quality attributes System Sequence Diagrams Operation Contracts requirements : Register Design Design Model : ProductCatalog : Sale enterItem (itemID. Sales LineItem . Cashier makes new sale.. 3..... attributes..... 6-1 Matthew Dailey (CSIM-AIT) Requirements 39 / 54 . quantity objects. validation Glossary Use Case Text Use Case Diagram system events : System Operation: enterItem(…) Post-conditions: -. attributes. 2...* 1 date .

Scenario: a specific sequence of actions and interactions. Sometimes called a use case instance. and their relationships.Requirements Analysis Definitions: Actor: something with behavior. Matthew Dailey (CSIM-AIT) Requirements 40 / 54 . The use case model includes the use cases along with an optional use case diagram showing the names of the use cases. the actors. outside the system under discussion (SuD). Use case: a collection of related success/failure scenarios.

but are crucial to OOAD. Use cases are the recommended central mechanism for discovering requirements.Requirements Analysis Use cases are not object oriented. Matthew Dailey (CSIM-AIT) Requirements 41 / 54 . especially the functional requirements.

Offstage: interested but not directly involved. Matthew Dailey (CSIM-AIT) Requirements 42 / 54 . Supporting: provides service to the SuD.g.Requirements Analysis Actor types: Primary: has user goals which the SuD must fulfill. E. the tax agency.

Requirements Analysis Enterprise Selling Things Checkout Service Sales Tax Agency Goal: Collect taxes on sales POS System Sales Activity System Cashier Customer Goal: Buy items Goal: Analyze sales and performance data Goal: Process sales Larman (2005). 6-2 Matthew Dailey (CSIM-AIT) Requirements 43 / 54 . Fig.

Requirements Analysis A use case can be written in one of 3 notations: Brief: only the main scenario. Casual: multiple scenarios described by short paragraphs. For the use case model. Matthew Dailey (CSIM-AIT) Requirements 44 / 54 . “Fully-dressed”: fully elaborated with supporting sections. with a short description. Larman uses the Cockburn notation.

Matthew Dailey (CSIM-AIT) Requirements 45 / 54 .Requirements Analysis A fully-dressed use case has these sections: Use case name Scope Level Primary actor Stakeholders and interests Preconditions Success guarantee (postconditions) Main success scenario Extensions Special requirements Technology and data variations list Frequency of occurrence Miscellaneous See the example. pp. 68–72.

Matthew Dailey (CSIM-AIT) Requirements 46 / 54 . It can be adapted to your organization and project’s needs. There are other notations besides Cockburn’s. Come from the actor and actor-goal perspective.Requirements Analysis Always remember that your use cases will be wrong! They will change as the project matures. Guidelines for writing use cases: Essential style (no UI) Keep it terse Treat the system as a black box.

Requirements Analysis Finding use cases: Choose the system boundary Identify primary actors Identify goals for each primary actor Define use cases in terms of user goals Matthew Dailey (CSIM-AIT) Requirements 47 / 54 .

g. Approve Credit or Price Order. The size test (3–10 pages.Requirements Analysis Tests to see if your proposed use case is a good one: The boss test The EBP (elementary business process) test: a task performed by one person in one place at one time. in response to a business event. which adds measurable business value and leaves the data in a consistent state. fully dressed)! Matthew Dailey (CSIM-AIT) Requirements 48 / 54 . e.

but don’t overuse them. only for summary purposes. Matthew Dailey (CSIM-AIT) Requirements 49 / 54 . The biggest mistake novices make is too much emphasis on the diagram and not enough emphasis on the text.Requirements Analysis Diagram your use cases. Sometimes UML activity diagrams will be useful for complex use cases.

6-3 Matthew Dailey (CSIM-AIT) Requirements 50 / 54 ... Fig.Requirements Analysis system boundary communication NextGen POS Process Sale Customer Payment Authorization Service alternate notation for a computer system actor Handle Returns actor «actor» Tax Calculator Cashier Cash In «actor» Accounting System Analyze Activity «actor» HR System Manager «actor» Sales Activity System Manage Security System Administrator Manage Users use case . Larman (2005).

Requirements Analysis For a use case context diagram. 6-4 Matthew Dailey (CSIM-AIT) Requirements 51 / 54 . Fig. primary actors on the left supporting actors on the right Larman (2005). NextGen «actor» Payment Authorization Service Process Sale Cashier .. Show computer system actors with an alternate notation to human actors.. limit the use cases to user-goal level use cases.

computer or human.. «system» Payment Payment Authorization Authorization Service Service «actor» Payment Authorization Service Some UML alternatives to illustrate external actors tha other computer systems. The class box style can be u for any actor. Larman (2005). Fig. Using it for compute actors provides visual distinction.Requirements Analysis NextGen Process Sale .. 6-5 Matthew Dailey (CSIM-AIT) Requirements 52 / 54 .

6-6 Matthew Dailey (CSIM-AIT) Requirements 53 / 54 . Fig.Requirements Analysis Larman (2005).

. do not try to define or polish all requirements.. Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows . 3. Fig. 2. 2.Requirements Analysis When Where Once during inception.. helping to write use cases. Short. present them on the project website. Led by system analyst who is responsible for requirements definition. 6-7 Matthew Dailey (CSIM-AIT) Requirements 54 / 54 . 3. Software: For use case text. Extensions: System Analyst End User Use Case: Handle Returns ... will play the role of requirements specifier.. At a requirements workshop... . Main Success Scenario: 1. Main Success Scenario: 1. .. For use case diagrams. Larman (2005). including end users and developers.. Extensions: Customer Developer Software Architect How: Tools Who Many. . January February Two adjacent projections.. Hyperlink the use cases. .. Several times during elaboration iterations. Use Case: Capture a Sale . ... a UML CASE tool.. use a web-enabled requirements tool that integrates with a popular word processor.. .