Workshop #2

The Analysis Model

2

Use Case ModelRequirements

Analysis Model

Design Model

DeploymentModel

Implementation

Analysis

Design

Implementation

Test

specified by

Test Model

realized by

distributed by

implemented by

verified by

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Primary Unified Process Models

Deployment

3

Requirements Model Analysis Model

Language of customer

External view of system

Functionality of system

Structured by use cases

Contract between customer and developer

Redundancies, inconsistencies

Language of developer

Internal view of system

How to realize functionality of system

Structured by classes and packages

Outlines function realization; first-cut design

No redundancies or inconsistencies

Requirements to Analysis

4

Architect Use-CaseEngineer

ComponentEngineer

Analysis Phase*

AnalysisModel

ArchitecturalDescription

responsible forresponsible for

Use Case Realization-Analysis-

AnalysisClass

AnalysisPackage

Roles

Artifacts

Analysis ModelRoles and Artifacts

5

AnalysisModel

AnalysisSystem

AnalysisPackage

1 1 1 **

AnalysisClass

Use Case Realization-Analysis-

**

(typically a collaboration diagram)

Analysis Model

6

Requirements Model Analysis Model

<<trace>>

AddPatron AddPatron

The use case realizations in the analysis model trace to those in the

requirements model.

Analysis ModelRealizing a Use Case

7

Use-Case Realization

The process of extending and refining use cases is called use-case realization

8

Use-Case Realization (contd) The verb “realize” is used at least 3 different ways:

Understand (“Harvey slowly began to realize that he was in the wrong classroom”);

Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and

Accomplish (“Janet hopes to realize her dream of starting a computer company”)

In the phrase “realize a use case,” the word “realize” is used in this last sense It means to accomplish (or achieve) the use case

9

Use-Case Realization (contd)

The realization of a specific scenario of a use case is depicted using an interaction diagram Either a sequence diagram or collaboration diagram

10

Use CaseModel

BusinessDomain Model

ArchitecturalDescription

[Use Case View]

SupplementaryRequirements

ArchitecturalAnalysis

Architect AnalysisPackage[Outline]

AnalysisClass

[Outline]

ArchitecturalDescription

[Analysis View]

Analysis Model – Role of Architect

11

Use CaseModel

BusinessDomain Model

ArchitecturalDescription

[Use Case View]

SupplementaryRequirements

Analyze aUse Case

AnalysisClass

[Outline]

Use-CaseEngineer Use Case Realization

-Analysis-

Analyze aClass

AnalysisClass

[complete]

ComponentEngineer

Analysis Model – Role of Use Case Engineer

12

LibrarianInterface

PatronCatalog

A communciation diagram (UML 2) or collaboration diagram (UML 1) is a UML interaction diagram that primarily focuses on the structural relationships among classes.A communication/collaboration diagram may also provide a rough sketch of the message flows among classes.

The Unified Process primarily uses collaboration diagrams to realize use cases in the analysis model. However, collaboration diagrams are also legal in the design model.

2.2: Find Patron

relation

message flow

messagesequence

analysis class

analysis class(note: analysis classes may be abstract

collections of numerous design classes like the Librarian Interface or a single design

class like the Patron Catalog class)

Communication/Collaboration Diagram

Components

13

Introduction to ClassificationExercise

Take a moment to group the following items into what you wouldConsider to be logical groups. Identify each group with some typeTitle.

StickBallPenPaper clipBean Rubber bandPencilGlue

14

Introduction to ClassificationExercise Continued

So, how did you classify the different objects below?

Stick, Ball, Pen, Paper clip, Bean, Rubber band, Pencil, Glue

Some of you may have grouped the objects based on a particular attribute/characteristics such as round, stick, wood, etc. Others may have categorized the objects based on the functions/behaviors of the different objects such as rolls, attaches things, writing utensil, etc.

Some of you may even have grouped the objects by attributes in one case and by functions in the other.

Humans view their world through complex classification schemas that we have constructed in our minds throughout our lives. These classification schemas follow the similar concepts we learned in our biology classes.

Biological Classification Schema

Vertebrate

Homo-Sapien

Mammal

...

...

Super Class/ Parent Class

Super Class/ Parent ClassSubclass / Child Class

Subclass / Child Class

Generalization

Specialization

16

Biological Classification Schema continued

Vertebrate

Homo-Sapien

Mammal

...

...

Attributes: 1. Backbone 2.

Attributes: 1. Backbone 2.

Additional Attributes: 1. Opposable thumb 2.

Methods: 1. Complex Movement 2.

Additional Methods: 1. Walks upright 2. Speech

Methods: 1. Complex Movement 2.

Additional Methods: 1. Live Birth 2. Produces milk

Additional Attributes: 1. Mammary Glands 2.

17

The basic concept is that humans are continually classifying things in our world everyday based on what we know about that object’s attributes and behaviors.

When you walk into a room and see a table, you know that this is a table that you can either sit behind, eat off of or work on based on contextual clues. We use the contextual clues to fine tune our classification of the basic concept that we know of as a table so that we can understand how we are suppose to interact with the table. For example, if the table is in a classroom with chairs behind it, we’ll sit behind it and use it to write down our notes from class. If the table is in a dining room with food on it, we’ll use it to eat off of.

The Object-Oriented Paradigm is based on how humans’ think about their world. We classify things based on the attributes and behavior of the given object we are analyzing. The OO Paradigm does not separate out data (attributes) from functions (behavior/methods). OO encapsulates data and methods together in classes which define common object types, I.e. a class called student.

What are Objects?

19

What are objects?

“A discrete entity with a well-defined boundary that encapsulates state and behavior in an instance of a class.”

• An object is a cohesive packet of data and function.• Generally speaking, the only way to get to the data part of an object is by calling one of the functions as operations in analysis and methods in design.

• In analysis – we are describing an abstract specification of a function (operation)• In design – we are describing the actual, physical implementation of a function (method)

• Objects hide data behind a layer of functions• Called encapsulation or data hiding

20

• Every object is an instance of some class that defines the common set of features (attributes, and operations or methods) that are shared by all instances of a class.

• Every object is uniquely identifiable• Every object has a state – this is determined by the attribute values of an object at a particular point in time.• Attribute values hold the object’s data.• An object’s functions are called operations in analysis and methods in design.

--Invoking an operation or method will often cause a change in the values of one or more of its attributes, and this may constitute a state transition.

• An object’s behavior is “what it can do for us” – its operations.• Object’s generate system behavior by sending messages to each other over links – this is collaboration.

What are Classes?

22

Types of Things

Things can be identified with methodology

Separate the tangible from the intangible

Include information from all types of users

Ask important questions about nature of event

“What actions upon things should be acknowledged and recorded by the system?”

Example case: customer placing an order

... Intelligent classification is intellectually hard work, and it best comes about through an incremental and iterative process Booch

..There is no such thing as the perfect class structure, nor the right set of objects. As in any engineering discipline, our design choice is compromisingly shaped by many competing factors.

Booch

Classification Theory Classification is the process of checking to see if

an object belongs to a category or a class and it is regarded as a basic attribute of human nature.

Point To Remember

Two Issues A class is a specification of structure,

behavior, and the description of an object.

Classification is more concerned with identifying classes than identifying the individual objects in a system.

The Challenge of Classification

Intelligent classification is intellectually hard work and may seem rather arbitrary.

Martin and Odell have observed in object-oriented analysis and design, that “In fact, an object can be categorized in

more than one way.”

28

Problem Domain Classes

Problem domain Set of work-related “things” in system component

◘ Things have data representation within system

Examples: products, orders, invoices, customers

OO approach to things in problem domain Objects that interact in the system

Identify and understand things in problem domain Key initial steps in defining requirements

Approaches for Identifying Classes

The noun phrase approach. The common class patterns approach. The use-case driven approach. The class responsibilities collaboration (CRC)

approach.

30

ClassificationTypes of Things

31

Procedure for Developing an Initial List of Things

List nouns users mention when discussing system 

Select nouns with questions concerning relevance

Further research may be needed

Noun Phrase Approach

Using this method, you have to read through the Use cases, interviews, and requirements specification carefully, looking for noun phrases.

Noun Phrase Strategy (Con’t)

Change all plurals to singular and make a list, which can then be divided into three categories.

Relevent Classes Irrelevent ClassesFuzzy Classes

Noun Phrase Strategy (Con’t) It is safe to scrap the Irrelevant Classes. You must be able to formulate a statement of

purpose for each candidate class; if not, simply eliminate it.

You must then select candidate classes from the other two categories.

Guidelines For Identifying Classes

The followings are guidelines for selecting classes in your application:

Look for nouns and noun phrases in the problem statement.

Some classes are implicit or taken from general knowledge.

Guidelines For Identifying Classes (Con’t)

All classes must make sense in the application domain.

Avoid computer implementation classes, defer it to the design stage.

Carefully choose and define class names.

Guidelines For Refining Classes

Redundant Classes: Do not keep two classes that express the

same information. If more than one word is being used to

describe the same idea, select the one that is the most meaningful in the context of the system.

Guidelines For Refining Classes (Con’t)

Adjective Classes: Does the object represented by the noun behave

differently when the adjective is applied to it?

Guidelines For Refining Classes (Con’t)

If the use of the adjective signals that the behavior of the object is different, then make a new class.

For example, If Adult Membership and Youth Membership behave differently, than they should be classified as different classes.

Guidelines For Refining Classes (Con’t)

Attribute Classes: Tentative objects which are used only as values

should be defined or restated as attributes and not as a class.

For example the demographics of Membership are not classes but attributes of the Membership class.

Guidelines For Refining Classes (Con’t)

Irrelevant Classes: Each class must have a purpose and every class

should be clearly defined and necessary. If you cannot come up with a statement of

purpose, simply eliminate the candidate class.

42

Attributes of Things Specific details of things are called attributes

Analyst should identify attributes of things

Identifier (key): attribute uniquely identifying thing

Examples: Social Security number, vehicle ID number, or product ID number

Compound attribute is a set of related attributes

Example: multiple names for the same customer

43

Figure 5-16Attributes and Values

44

Classes and Objects Domain model class diagram as UML class

OOA applies domain model class diagram to things

Problem domain objects have attributes

Software objects encapsulate attributes and behaviors

Behavior: action that the object processes itself

Software objects communicate with messages

Information system is a set of interacting objects

45

Figure 5-17Objects Encapsulate Attributes and Methods

46

Classes

The three class types in the Unified Process are Entity classes Boundary classes Control classes

UML notation

47

AnalysisClass

ControlClass

EntityClass

BoundaryClass

Analysis Stereotypes

extends

UP provides for three defaultclass types in the analysis mocdel

48

Entity Classes An entity class models information that is long lived

Examples: Account Class in a Bank Case Study Library Card in the Library Case Study

Instances of all these classes remain in the information system for years

49

Boundary Classes A boundary class models the interaction between

the information system and its actors

Boundary classes are generally associated with input and output

Examples: Library Interface and Library Card Reader in

Library Case Study

50

Control Classes

A control class models complex computations and algorithms

A control class coordinates the operations and transactions of other classes in order to realize a use case (e.g. catalogs, main windows)

Examples: Patron Catalog and Patron Factory in the

Library Case Study

51

UML notation for these three types of classes

These are stereotypes (extensions of UML) UML allows us to define additional constructs that are not

part of UML but which we need in order to model a system accurately

Stereotypes

52

The Unified Process and Classes

The Unified Process does not describe how classes are extracted Users of the Unified Process are expected to have a

background in object-oriented analysis and design

We temporarily suspend this discussion of the Unified Process to explain how classes are extracted, and then return to the Unified Process

53

Extracting Entity Classes Entity class extraction consists of three steps that are

carried out iteratively and incrementally: Functional modeling

◘ Present scenarios of all the use cases (a scenario is an instance of a use case)

Class modeling◘ Determine the entity classes and their attributes

◘ Determine the interrelationships and interactions between the entity classes

◘ Present this information in the form of a class diagram

54

Dynamic modeling◘ Determine the operations performed by or to each

entity class

◘ Present this information in the form of a statechart

Extracting Entity Classes

55

Flowchart for Extracting Entity Classes

56

Extracting Boundary Classes

It is usually easy to extract boundary classes Each input screen, output screen, and printed report

is generally modeled by a boundary class

57

Extracting Control Classes

It is also usually easy to extract control classes Each nontrivial computation is generally modeled

by a control class

58

Analyze a Use Case - Techniques

Identify classes whose objects (class instances) are needed to perform the use case’s flow of events study and detail use cases to identify information to be

manipulated and used identify one central boundary class for each human actor identify one primitive boundary class for each entity

class – things the actor will interact with identify one central boundary class for each external

system actor identify one control class responsible for handling the

control and coordination of the use-case realization

59

Designing with Communication Diagrams

Shows a view of the use case that emphasizes coupling

Uses the same symbols as a sequence diagram for actors, objects, and messages

Lifeline symbols are not used Link symbols indicate that two items share a

message Numbers indicate the sequence in which messages

are sent

60

The symbols of a communication diagram

61

A Pay Order Use Case Realization

Class Diagram

Buyer<<Actor>>

Order Confirmation<<entity>>

Order Handler<<control>>

Invoice<<entit...

Payment Request UI<<boundary>>

Payment Scheduler<<control>>

Payment Request<<entity>>

Payment Request

Buyer

Order Confirmation

Order Handler

Invoice

Payment Request UI

Payment Scheduler

With stereotype icons With stereotype labels

62

Analyze a Use Case – Technique Describe object interactions

Collaboration diagram◘ Actor instances, analysis objects, links

◘ One collaboration diagram for each unique flow through the use case

Start at beginning of flow and proceed one step at a time◘ Decide object and actor instance interactions necessary to

realize the step Complement diagram with appropriate textual

descriptions Capture special requirements

63

A Pay Order Use Case Realization Collaboration Diagram

: Buyer

: Payment Request

: Payment Request UI

: Order Handler

: Order Confirmation

: Invoice

: Payment Scheduler

1: Browse Invoice

2: Browse

3: Check invoice

4: Get

5: Get

6: Schedule invoice for payment

7: Schedule payment

8: New

9: setStatus (scheduled)

64

PatronFactory

Patron

Use-Case Model Analysis Model

LibraryCard Reader

LibrarianInterface

<<trace>>

AddPatron AddPatron

Librarian Package Analysis Classes

Use Case Realizations

PatronCatalog

LibraryCard

65

Librarian LibrarianInterface

1: Add new patron2: Enter patron info.

1.1: Create

PatronFactory

Patron3: Accept Card

Add Patron Collaboration Diagram

1.2: new

LibraryCard Reader

4: Swipe Card

2.2: Set Name

1.3: add

PatronCatalog

5.1: setId6: save

LibraryCard

4.1: new(id)

5: getId

6.1: Save

66

PatronFactory

Patron

Use-Case Model Analysis Model

LibraryCard Reader

LibrarianInterface

<<trace>>

AddPatron AddPatron

PatronCatalog

LibraryCard

67

Librarian LibrarianInterface

1: Add new patron5: Enter patron info.

2: Create

PatronFactory

Patron7: Accept Card

Add Patron Collaboration Diagram

3: new

LibraryCard Reader

8: Swipe Card

6: Set Name

4: add

PatronCatalog

11: setId12: save

LibraryCard

9: new(id)

10: getId

13: Save

68

: Buyer : Payment Request : Payment Request UI : Order Handler : Order Confirmation : Invoice : Payment Scheduler

Browse Invoice

Browse

Check invoice

Get

Get

Schedule invoice for payment

Schedule payment

New

setStatus (scheduled)

A Pay Order Use

Case Realization Sequence Diagram

This sequence diagram is

equivalent to the previous

collaboration diagram

69

Analyze a Use Case – Techniques (continued)

Guidelines Invoke use case by a message from an actor instance to a boundary

object Each analysis class should have at least one object in a collaboration

diagram Messages are not (yet) assigned to operations

◘ Denote the intent of the invoking object when interacting with the invoked object – responsibility of invoked object

Links in collaboration are instances of associations between analysis classes

Sequence is not primary focus – exclude if cluttered◘ Focus on relations (links) between objects and on requirements

(messages) on objects Capture use-case relationships (e.g., if case A specializes case B,

then diagram of A refers to diagram of B

70

Analyze a Package

Purposes Ensure packages are as independent as possible (de-coupled)

◘ Describe dependencies to understand effect of future changes Ensure package realizes some domain classes or use cases

Guidelines Define and maintain the dependencies of the package on

other packages whose contained classes are associated with it

Make the package cohesive by including only functionally related objects

Relocate classes to other packages to reduce package dependencies

71

Library SystemAnalysis Model

«topLevelPackage»Model

«AnalysisSystem»Analysis System

«AnalysisPackage»Librarian

«AnalysisPackage»Overdue

«AnalysisPackage»Patron

72

Results of Analysis Modeling Analysis packages and their dependencies and contents Analysis classes, their responsibilities, attributes,

relationships and special requirements Localize the behavior and information they represent

Use-case realizations—analysis that describes how use cases are refined in terms of collaborations within the analysis model Localize changes in a use case

Architectural view – significant elements of analysis model

73

Analysis Model Impacts Design

Preserve structure while addressing non-functional requirements and implementation constraints Functional structures: cohesive, decoupled packages Packages Subsystems

Analysis classes are specifications of design classes Entity classes databases Boundary classes UI or communications

Use-case realizations More precise specifications of use cases Identify process flow in design (threads of activity and control)

Architectural view will trace to multiple views of design model Add physical realization and structure to the logical structure