Sie sind auf Seite 1von 54

Software Architecture Design I OOAD in the Unied Process

Matthew Dailey
Computer Science and Information Management Asian Institute of Technology

Matthew Dailey (CSIM-AIT)

Requirements

1 / 54

Readings

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 16. Some material c Larman (2005).

Matthew Dailey (CSIM-AIT)

Requirements

2 / 54

Outline

Introduction OOAD Overview UP Overview Inception Requirements Analysis

Matthew Dailey (CSIM-AIT)

Requirements

3 / 54

Introduction

It is dicult 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 communicate, review, implement, and evolve.

Matthew Dailey (CSIM-AIT)

Requirements

4 / 54

Introduction
The UP

OOAD need to be performed within a software development process. The Unied Process is an iterative, risk-driven, architecture-centric approach to software development.
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.

Larman (2005), Fig. 2.1

OOAD and the UP work well together.


Matthew Dailey (CSIM-AIT) Requirements 5 / 54

Outline

Introduction OOAD Overview UP Overview Inception Requirements Analysis

Matthew Dailey (CSIM-AIT)

Requirements

6 / 54

OOAD Overview

To develop a system using OOAD, 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. OOA means nding the objects and concepts in the problem domain.
Plane domain concept tailNumber visualization of domain concept

representation in an object-oriented programming language

public class Plane { private String tailNumber; public List getFlightHistory() {...} }

Larman (2005), Fig. 1-2

Matthew Dailey (CSIM-AIT)

Requirements

7 / 54

OOAD Overview

Player name 1 Plays 1 DiceGame

Rolls

Die faceValue 2

Includes

Larman (2005), Fig. 1-3

Matthew Dailey (CSIM-AIT)

Requirements

8 / 54

OOAD Overview
OOD means dening the software components, their responsiblities, and how they collaborate to fulll the requirements.

Larman (2005), Fig. 1-4

Matthew Dailey (CSIM-AIT)

Requirements

9 / 54

OOAD Overview

Design classes are the detailed classes necessary to fulll requirements.


DiceGame die1 : Die die2 : Die play() 1 2 Die faceValue : int getFaceValue() : int roll()

Larman (2005), Fig. 1-5

Matthew Dailey (CSIM-AIT)

Requirements

10 / 54

OOAD Overview

We will use the Unied Modeling Language to communicate domain and design models. UML has 3 uses in software engineering: As a sketch tool: informal, 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. We will favor agile approaches that use UML as a sketch tool. Dont overdo UML!

Matthew Dailey (CSIM-AIT)

Requirements

11 / 54

OOAD Overview
We begin with analysis. At this point, the classes we derive will be conceptual, representing real world things in the problem domain.
DiceGame 1 Includes 2 Die faceValue Conceptual Perspective (domain model) Raw UML class diagram notation used to visualize real-world concepts.

DiceGame die1 : Die die2 : Die play() 2

Die faceValue : int getFaceValue() : int roll()

Specification or Implementation Perspective (design class diagram) Raw UML class diagram notation used to visualize software elements.

Larman (2005), Fig. 1-6

Later the model will be elaborated into software classes or design classes providing a solution, and implementation classes in a real OO language.

Matthew Dailey (CSIM-AIT)

Requirements

12 / 54

Outline

Introduction OOAD Overview UP Overview Inception Requirements Analysis

Matthew Dailey (CSIM-AIT)

Requirements

13 / 54

UP Overview

The Unied Process is an iterative development process. Iterative development is now standard in the industry. Compared to traditional waterfall methods, iterative development has proven to reduce defects, increase productivity, and increase project success rates. The basic idea is short iterations that are xed in length or timeboxed. Depending on implementation in the organization, UP, the UP can be low ceremony and agile.

Matthew Dailey (CSIM-AIT)

Requirements

14 / 54

UP Overview

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

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

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

3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.

Larman (2005), Fig. 2-1

Matthew Dailey (CSIM-AIT)

Requirements

15 / 54

UP Overview

Iterative development is not new. The spiral process has been around since the 1980s. Many big projects in the 60s and 70s used iterative techniques. The benet is it allows us to embrace change. On every iteration, shareholders have the opportunity to say yes, its what I asked for, but... Typical iterations are 26 weeks. They should be as short as possible. Be careful to prevent the iterations from becoming waterfall phases!

Matthew Dailey (CSIM-AIT)

Requirements

16 / 54

UP Overview
Example process implementation: Two-day requirements workshop to detail the 10% of your use cases with the higest business value, greatest risk, and higest architectural impact. This is the end of the inception phase. Plan the rst iteration. Pick a subset of the detailed scenarios to design, implement and test, in a short period, e.g. 4 weeks. Do 2 days of modeling on whiteboards. Program, test, and integrate continuously. 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. Demo for stakeholders and request feedback. Repeat until 80%90% of the use cases are fully detailed and the architecture is baselined. This is the end of the elaboration phase.
Matthew Dailey (CSIM-AIT) Requirements 17 / 54

UP Overview
1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

requirements

requirements

software

software

90%

90%

50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5

week 1 M T W Th F

week 2 M T W Th F

week 3 M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching. 5 hours

start coding & testing

de-scope iteration goals if too much work

final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop

demo and 2-day requirements workshop

next iteration planning meeting; 2 hours

Most OOA/D and applying UML during this period

Larman (2005), Fig. 2-4


Matthew Dailey (CSIM-AIT) Requirements 18 / 54

UP Overview

The UP is risk driven: in early iterations we identify and mitigate the most signicant risks. The UP is client driven: we build the features the client cares about most rst. The UP is architecture centric: we focus on the architecturally signicant use cases rst.

Matthew Dailey (CSIM-AIT)

Requirements

19 / 54

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

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

UP Overview
Example of some practical modeling:

Larman (2005), Fig. 2-5

Matthew Dailey (CSIM-AIT)

Requirements

22 / 54

UP Overview

Best practices for UP application: Attack high risk, high value issues rst. Continuously engage users. Develop a cohesive core architecture in early iterations. Continuously verify quality test early, often, and realistically. Apply the use cases where appropriate. Do some visual modeling. Carefully manage requirements. Practice change request and conguration management.

Matthew Dailey (CSIM-AIT)

Requirements

23 / 54

UP Overview

The phases in the UP are: Inception: work out the initial vision, business case, and scope, with vague estimates. Elaboration: rene the vision, develop the core architecture, resolve major risks, further detail the requirements. Construction: work on the lower-risk, easier elements. Transition: beta test and deploy

Matthew Dailey (CSIM-AIT)

Requirements

24 / 54

UP Overview

development cycle iteration phase

inc.

elaboration

construction

transition

milestone An iteration endpoint when some significant decision or evaluation occurs.

release A stable executable subset of the final product. The end of each iteration is a minor release.

increment The difference (delta) between the releases of 2 subsequent iterations.

final production release At this point, the system is released for production use.

Larman (2005), Fig. 2-6

Matthew Dailey (CSIM-AIT)

Requirements

25 / 54

UP Overview

Each phase in the UP involves all disciplines to an extent, with dierent weightings in dierent phases. In this course, we focus on business modeling, requirements analysis, and design.

Matthew Dailey (CSIM-AIT)

Requirements

26 / 54

UP Overview

A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Sample UP Disciplines Business Modeling Focus of this book Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations

Note that although an iteration includes work in most disciplines, the relative effort an emphasis chang over time. This example is suggestive, not literal.

Larman (2005), Fig. 2-7

Matthew Dailey (CSIM-AIT)

Requirements

27 / 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. You spend more time creating documents than programming.

Matthew Dailey (CSIM-AIT)

Requirements

28 / 54

Outline

Introduction OOAD Overview UP Overview Inception Requirements Analysis

Matthew Dailey (CSIM-AIT)

Requirements

29 / 54

Inception

Here we consider requirements analysis, which has the most weight during the elaboration phase. Inception is not requirements! Inception focuses on What is the vision and business case? Is it feasible? Buy or build? Whats the rough cost? Do it or not?

Matthew Dailey (CSIM-AIT)

Requirements

30 / 54

Inception

See the text for inception artifacts. Most are optional! The only UML produced in inception will possibly be use case diagrams, but they are not necessary. Most of the artifacts are pure text.

Matthew Dailey (CSIM-AIT)

Requirements

31 / 54

Inception

You are executing inception incorrectly if: Inception takes more than a few weeks. You dene the architecture. You try to do requirements, design, and implementation. There is no business case or vision. Most use cases are detailed. No use cases are detailed.

Matthew Dailey (CSIM-AIT)

Requirements

32 / 54

Outline

Introduction OOAD Overview UP Overview Inception Requirements Analysis

Matthew Dailey (CSIM-AIT)

Requirements

33 / 54

Requirements Analysis

In UP, we manage requirements and expect them to change. Studies show that on average, 25% of requirements change during the project! Other studies have found that 2/3 of the features specied in waterfall requirements documents are never or rarely used!

Matthew Dailey (CSIM-AIT)

Requirements

34 / 54

Requirements Analysis
Fig. 5.1
Poor user input 13%

Incomplete requirements 12% Other 50% Changing requirements 12% Poor technical skills 7% Poor staffing 6%

Larman (2005), Fig. 5-1

Matthew Dailey (CSIM-AIT)

Requirements

35 / 54

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, and sometimes we distinguish between functional and non-functional requirements.
Matthew Dailey (CSIM-AIT) Requirements 36 / 54

Requirements Analysis

The key requirements artifacts are: The Use Case Model The Supplementary Specication (a place for non-functional requirements and features that dont t in the use case model) The Glossary (denition 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

Requirements Analysis
Sample UP Artifact Relationships Domain Model Business Modeling Sale date ... 1 1..* Sales LineItem quantity objects, attributes, associations Use-Case Model Process Sale
Process Sale Cashier

... ...

scope, goals, actors, features

Vision

use case names

1. Customer arrives ... 2. Cashier makes new sale. 3. ... Use Case Text system events : System

terms, attributes, validation

Glossary

Requirements

Use Case Diagram

Operation: enterItem() Post-conditions: -... Operation Contracts requirements

: Cashier

system operations

make NewSale() enterItem (id, quantity)

Supplementary Specification non-functional reqs, quality attributes

System Sequence Diagrams

: Register enterItem (itemID, quantity)

Design Model

: ProductCatalog

: Sale

Design

spec = getProductSpec( itemID ) addLineItem( spec, quantity )

Larman (2005), Fig. 6-1

Matthew Dailey (CSIM-AIT)

Requirements

39 / 54

Requirements Analysis

Denitions: Actor: something with behavior, outside the system under discussion (SuD). Scenario: a specic sequence of actions and interactions. Sometimes called a use case instance. Use case: a collection of related success/failure scenarios. The use case model includes the use cases along with an optional use case diagram showing the names of the use cases, the actors, and their relationships.

Matthew Dailey (CSIM-AIT)

Requirements

40 / 54

Requirements Analysis

Use cases are not object oriented, but are crucial to OOAD. Use cases are the recommended central mechanism for discovering requirements, especially the functional requirements.

Matthew Dailey (CSIM-AIT)

Requirements

41 / 54

Requirements Analysis

Actor types: Primary: has user goals which the SuD must fulll. Supporting: provides service to the SuD. Ostage: interested but not directly involved. E.g. the tax agency.

Matthew Dailey (CSIM-AIT)

Requirements

42 / 54

Requirements Analysis

Enterprise Selling Things Checkout Service Sales Tax Agency Goal: Collect taxes on sales Sales Activity System Customer POS System

Cashier

Goal: Buy items

Goal: Analyze sales and performance data

Goal: Process sales

Larman (2005), Fig. 6-2

Matthew Dailey (CSIM-AIT)

Requirements

43 / 54

Requirements Analysis

A use case can be written in one of 3 notations: Brief: only the main scenario, with a short description. Casual: multiple scenarios described by short paragraphs. Fully-dressed: fully elaborated with supporting sections. For the use case model, Larman uses the Cockburn notation.

Matthew Dailey (CSIM-AIT)

Requirements

44 / 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. 6872.
Matthew Dailey (CSIM-AIT) Requirements 45 / 54

Requirements Analysis

Always remember that your use cases will be wrong! They will change as the project matures. There are other notations besides Cockburns. It can be adapted to your organization and projects needs. Guidelines for writing use cases: Essential style (no UI) Keep it terse Treat the system as a black box. Come from the actor and actor-goal perspective.

Matthew Dailey (CSIM-AIT)

Requirements

46 / 54

Requirements Analysis

Finding use cases: Choose the system boundary Identify primary actors Identify goals for each primary actor Dene use cases in terms of user goals

Matthew Dailey (CSIM-AIT)

Requirements

47 / 54

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, e.g. Approve Credit or Price Order. The size test (310 pages, fully dressed)!

Matthew Dailey (CSIM-AIT)

Requirements

48 / 54

Requirements Analysis

Diagram your use cases, only for summary purposes. The biggest mistake novices make is too much emphasis on the diagram and not enough emphasis on the text. Sometimes UML activity diagrams will be useful for complex use cases, but dont overuse them.

Matthew Dailey (CSIM-AIT)

Requirements

49 / 54

Requirements Analysis
system boundary NextGen POS communication

Process Sale Customer

Payment Authorization Service Handle Returns actor Tax Calculator actor Accounting System actor HR System

alternate notation for a computer system actor

actor

Cashier

Cash In Manager actor Sales Activity System Analyze Activity

Manage Security

System Administrator

Manage Users use case

...

Larman (2005), Fig. 6-3

Matthew Dailey (CSIM-AIT)

Requirements

50 / 54

Requirements Analysis
For a use case context diagram, limit the use cases to user-goal level use cases. NextGen Show computer system actors with an alternate notation to human actors.

Process Sale

actor Payment Authorization Service

Cashier

...

primary actors on the left

supporting actors on the right

Larman (2005), Fig. 6-4

Matthew Dailey (CSIM-AIT)

Requirements

51 / 54

Requirements Analysis

NextGen Process Sale 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, computer or human. Using it for compute actors provides visual distinction.

...

Larman (2005), Fig. 6-5

Matthew Dailey (CSIM-AIT)

Requirements

52 / 54

Requirements Analysis

Larman (2005), Fig. 6-6

Matthew Dailey (CSIM-AIT)

Requirements

53 / 54

Requirements Analysis
When
Once during inception. Short; do not try to define or polish all requirements. Several times during elaboration iterations.

Where
At a requirements workshop.

January

February

Two adjacent projections.

Use Case: Capture a Sale ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:

Use Case: Handle Returns ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:

System Analyst End User

Customer Software Architect

Developer

How: Tools Who


Many, including end users and developers, will play the role of requirements specifier, helping to write use cases. Led by system analyst who is responsible for requirements definition. Software: For use case text, use a web-enabled requirements tool that integrates with a popular word processor. For use case diagrams, a UML CASE tool. Hyperlink the use cases; present them on the project website. 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 .

Larman (2005), Fig. 6-7

Matthew Dailey (CSIM-AIT)

Requirements

54 / 54

Das könnte Ihnen auch gefallen