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