Transcript Object Oriented Analysis & Design & UML (Unified Modeling

Part III: Analysis
Analysis Workflow
Classes and Objects
Finding Analysis Classes
Analysis Relationships
Object Oriented Analysis & Design & UML (Unified Modeling Language)
1
The Analysis Workflow



The main work starts at the end of inception
The main focus of Elaboration is the analysis
Most of the activity of elaboration is



Requirements capture


and analysis go together
The main aim is


Creating models to capture
the desired behavior of the system
To produce the analysis model
Focus:


What the system needs to do
not the details of how.
Object Oriented Analysis & Design & UML (Unified Modeling Language)
2
The Analysis Workflow
Object Oriented Analysis & Design & UML (Unified Modeling Language)
3
Analysis Activities
Object Oriented Analysis & Design & UML (Unified Modeling Language)
4
Analysis Model


Every system is different
Moderate size and complexity projects:


Concentrate only on the classes


50-100 analysis classes in the analysis model
that are part of the problem domain
Avoid from design classes


Communication classes
Database access classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
5
Rules of Thumb


Use the language of business
Each diagram must


Concentrate on the capturing the big picture




if there is a natural hierarchy of abstractions
Try to provide a model


the problem domain (business requirements)
and solution domain
Try to minimize the coupling
Explore inheritance


Do not lose time for details
Distinguish between


tell important part of the system’s desired behavior
that is useful for all stakeholders
Keep the model simple
Object Oriented Analysis & Design & UML (Unified Modeling Language)
6
What are objects?

Definition (The UML Reference Manual):

A discrete entity with a well-defined boundary



by calling a function of the object
A function is called as



data and function
Access to data is only possible


An instance of a class
A cohesive packet of


encapsulating state and behavior
Operation in analysis
Method in design
Data-hiding


To hide the data part of the object
behind the function layer
Object Oriented Analysis & Design & UML (Unified Modeling Language)
7
What are objects?

Every object is an instance of a class

defining the common set of features:




Attributes,
Operations/Methods
Class: Epson
Photo 1200
A specific instance of a class is called object
Common properties of objects
Object: Epson
Photo 1200
S/N: 34120098
Identity: Makes it different from all other objects
Object: Epson
Photo 1200
S/N: 30040065




State


The unique existence of object in time and space
An address in memory
The attribute values of object at a time
Object: Epson
Photo 1200
S/N: 70050516
Behavior


Movement of object from one state to another state
Changing attribute value or values in time
Object Oriented Analysis & Design & UML (Unified Modeling Language)
8
Encapsulation

To enable user to concern


only with the services the object offers
Instead of the structure of data


The behavior of an object is


What it can do for us.
List of operations



Data is hidden inside of the object.
changing attribute values
and generate state transitions.
State transition:

Any method invocation



leading to substantive change
in the object’s nature
in UML:


Statecharts (Chapter 19) are used
to model state transition.
Object Oriented Analysis & Design & UML (Unified Modeling Language)
9
Encapsulation
Operation
Semantics
deposit()
Deposit some money in the Account
object.
Increment the balance attribute
value.
withdraw
Withdraw some money from the
Account.
Decrement the balance attribute
value.
getOwner() Returns the owner of the Account
object.
setOwner()

Operations causing state transitions (changing attribute values):


Change the owner of the Account
object.
deposit(), withdraw(), setOwner().
Operations causing state transitions (not changing attribute values):

getOwner()
Object Oriented Analysis & Design & UML (Unified Modeling Language)
10
Messaging

Objects collaborate to perform functions of the
system



Forming links to other objects
and send messages back and forth along these links
When an object receives a message


Compares the message with operation signatures
defined
if there is any match




invokes the corresponding operation
performs the activities
sends the result back to the caller object.
This is quite different from procedural systems


Execution is not ordered in time.
Exact time of invoking operation is undetermined.
Object Oriented Analysis & Design & UML (Unified Modeling Language)
11
Messaging of Objects
Object Oriented Analysis & Design & UML (Unified Modeling Language)
12
UML Object Notation

Object icon of UML has two compartments:

Object identifier




Always underlined to distinguish from class notation
The class name might be included using a colon
Example: jimsAccount:Account
Attributes

Name, type and values can be shown



name:type=value
Example: number:int=1234567
Attribute types might be omitted for simplification
Object Oriented Analysis & Design & UML (Unified Modeling Language)
13
UML Object
Object Oriented Analysis & Design & UML (Unified Modeling Language)
14
What are Classes?

Definition (The UML Reference Manual):

The descriptor for a set of objects sharing the same





A class is a descriptor for a set of objects



attributes,
operations/methods,
relationships
and behavior
having the same features
Every object is an instance of exactly one class
A class is a template for objects


Determines the structure of objects
Allows to describes a set of features



that all objects must have
No need to describe every feature of each object
All objects have


the same attributes, and relationships
but different attribute values
Object Oriented Analysis & Design & UML (Unified Modeling Language)
15
Classes and Objects

Relationship


A connection between the modeling elements
Dependency


A relationship between two elements
A change in supplier element


affects the client element
«instantiate» relationship

Represented by a dotted arrow


between the class and objects
An ordinary dependency

Between the class and objects of that class
Object Oriented Analysis & Design & UML (Unified Modeling Language)
16
Relationship between Class and Objects
Object Oriented Analysis & Design & UML (Unified Modeling Language)
17
Object Instantiation

Instantiation


The creation of new instances of model
elements
Constructors:






Special operations belong to the class
Used to create class instances
Allocates memory for the new object
Gives a unique identity to the object
Sets the initial attribute values
Constructs links to other objects
Object Oriented Analysis & Design & UML (Unified Modeling Language)
18
UML Class Notation


Three compartments:
Name compartment



Attribute compartment




The only mandatory part
Contains the name and general information about the
class
Is optional
Used for data values
Initial values are represented
Operations compartment


Is optional
Used to define the operations
Object Oriented Analysis & Design & UML (Unified Modeling Language)
19
UML Class Example
Object Oriented Analysis & Design & UML (Unified Modeling Language)
20
Name compartment

Convention is



Avoid abbreviations



to represent class names in CamelCase
Special symbols are avoided
Class name must reflect
real world entities
Abbreviated names are

harder to read and understand
Object Oriented Analysis & Design & UML (Unified Modeling Language)
21
Attribute Compartment
visibility
optional

Represents the accessibility of the attribute
Used to identify the attribute
To constraint the number of occurrences
Type



optional
Multiplicity


mandatory
Name


multiplicity:type = initialValue
Visibility


name
Type of the attribute
Integer, string, array, float, char, etc.
Initial Value


The first value assigned to the attribute
after the object creation
Object Oriented Analysis & Design & UML (Unified Modeling Language)
22
Visibility



To restrict the access to the attribute
Implementation language dependent
Must be described at the design
Object Oriented Analysis & Design & UML (Unified Modeling Language)
23
Visibility - semantics
Object Oriented Analysis & Design & UML (Unified Modeling Language)
24
Multiplicity




Widely used in design
Might be used in analysis too
Expresses the constraints to the number of
things
Arrays



If multiplicity is an integer greater than 1
colors[7]
Null values

Values for non-initialized attributes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
25
Multiplicity Examples
Object Oriented Analysis & Design & UML (Unified Modeling Language)
26
Operation Compartment
Operation signature
visibility
name
(parameterName: paramaeterType, …) : returnType
parameter list

Operation signature: combination of




Operation name
Type of all parameters
Return type
When a message sent to an object

Message signature is compared


If a match is found


with operations signature
the operation is invoked
Operations are named camelCase

Always starts with lowercase character
Object Oriented Analysis & Design & UML (Unified Modeling Language)
27
Scope

It is sometimes useful

to define attributes



to have those operations that



have a single shared value
for every object of the class
Do not operate on any particular class instance
Example: object creation and destruction operations
Such type of attributes and operations have
class scope.


Provide a set of global features
for an entire objects of that class.
Object Oriented Analysis & Design & UML (Unified Modeling Language)
28
Scope

Instance scope operations


are specific for the object operations
can access



other instance scope attributes and operations
all class scope attributes and operations
Class scope operations



are defined as class-wide
access only other class scope attributes and operations
can’t access instance scope operations.
Object Oriented Analysis & Design & UML (Unified Modeling Language)
29
Example: BankAccount
create(aNumber: int)
{
count=count + 1;
accountNumber= aNumber;
}
create(aNumber: int)
{
incrementCount();
accountNumber= aNumber;
}
Object Oriented Analysis & Design & UML (Unified Modeling Language)
30
Object Destruction

Objects are destructed when they are not required anymore



Different languages have different semantics
C++:


Finalize()
Some languages (Java) automatically destructs the objects



finalize()
C#:


~ClassName(parameterList)
Java:


their memory is deallocated
When they are not referenced anymore
Garbage collector removes such objects from memory.
It is a good programming style


To call destructors
when objects are not required anymore
Object Oriented Analysis & Design & UML (Unified Modeling Language)
31
UP Activity: Analyze a use case


To realize the use cases
To derive the analysis classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
32
Analysis Classes


Represent an abstraction in the problem
domain
Map on to real-world business concept

OO analyst must



Try to clarify the confused business concepts
to a form a basis for analysis classes
Clarify the problem domain!
Object Oriented Analysis & Design & UML (Unified Modeling Language)
33
Anatomy of Analysis Classes

Analysis classes


Must present very high level set of attributes
Contain the attributes


that might be the member of design classes
Only a subset of class syntax is used

Name


Attributes



Generally not shown
Stereotypes


As a very high level statements
Parameters and return types shown only if it is important
Visibility


Names are mandatory, types optional
Operations


Mandatory, shown
Shown only if they enhance the model
Tagged values

Shown only if they enhance the model
Object Oriented Analysis & Design & UML (Unified Modeling Language)
34
Example: Analysis Class
Object Oriented Analysis & Design & UML (Unified Modeling Language)
35
A Good Analysis Class:



models an element in problem domain
Maps to a clearly identifiable feature
Has small, well defined set of
responsibilities

Well defined set of services


accommodating the intent of the class
Example: ShoppingBasket



Add item to the basket
Remove item from the basket
Show the items in the basket
Object Oriented Analysis & Design & UML (Unified Modeling Language)
36
A Good Analysis Class:

Has a name reflect its intent:

in e-commerce system:



WebSiteVisitor: has vague semantics
Has high cohesion

All responsibilities must be


working for the same goal
Example:


Customer, ShoppingBasket:
ShoppingBasket: validate card, accept payment, print receipt
Has low coupling

Optimize relationships with other classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
37
Finding Classes

There is no simple algorithm


Finding the “right” classes depends on




to find the right analysis classes
Perspective
Skill
Experience
Some techniques are available to help
Object Oriented Analysis & Design & UML (Unified Modeling Language)
38
Noun/Verb Analysis

A simple way to find




Classes
Attributes
Responsibilities
Analyze the text (i.e. specification)

Nouns and noun phrases:


Verbs and verb phrases;




become responsibilities or operations
Be aware of


become Classes or attributes
Synonyms: different words meaning the same thing
Homonyms: the same words with different meanings
The problem domain must be well-understood
Hidden classes:

Classes that are not mentioned directly
Object Oriented Analysis & Design & UML (Unified Modeling Language)
39
Noun/Verb Analysis Procedure

Collect as much relevant information as possible





Highlight






Requirements specification
Use cases
Project glossary
Architecture, vision documents, etc.
Nouns: e.g. flight
Noun phrases: e.g. flight number
Verbs: e.g. allocate
Verb phrases: e.g. verify credit card
Clarify the words/terms that are not understood
Prepare a first cut

entering the classes to a CASE tool
Object Oriented Analysis & Design & UML (Unified Modeling Language)
40
CRC Analysis


Class-Responsibility-Collaborators
The sticky notes method with three
compartments:

Class name


Responsibilities


The name of the candidate class
The expected responsibilities of the classes
Collaborators

Other classes that the class interact with
Object Oriented Analysis & Design & UML (Unified Modeling Language)
41
CRC Card
Class Name:
Superclasses:
Subclasses:
Responsibilities
Collaborators
Object Think
Property
Object Oriented Analysis & Design & UML (Unified Modeling Language)
42
CRC Example: Rental Contract
Class Name: Rental Contract
Superclasses:
Subclasses:
Responsibilities
Collaborators Object Think
Property
Update customer info
Customer
I know the customer
Customer
Select vehicle
Rental agent
I know the rental agent
Rental Agent
Return vehicle
Rental agent
I know the vehicle
Vehicle
Print contract
Vehicle
I know the time checkout
Out Time Stamp
I know the time return
In Time Stamp
I know the miles driven
Miles Driven
I know any damage done
Damage Report
I know the rental status
Status
Object Oriented Analysis & Design & UML (Unified Modeling Language)
43
CRC Procedure


Should be used in conjunctions with
noun/verb analysis
Two phase activity:

Brainstorming


Gather the information
Analyze the information

Deciding which of the sticky notes would become
classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
44
Phase –1: Brainstorming
Explain that this is a true brainstorming
1.
1.
2.
All ideas are accepted as good ideas
Ideas are recorded but not debated


Never argue about something
Just write it down
Ask the team members to name ‘things’
2.
1.
2.
Write each thing on a sticky note
Stick the note on a wall or whiteboard
Ask the team to state responsibilities
3.

Write down to the responsibilities compartment
Identify the classes to work together
4.


Draw lines between them
Record them in collaborators department
Object Oriented Analysis & Design & UML (Unified Modeling Language)
45
Phase –2: Analyze Information

Classes:

Certain sticky notes represent



an abstraction in business domain
need to be classes
Attributes

Check the following notes




logically seems to be a part of other note
not selected as classes
does not seem to be particularly important
has very little interesting behavior
Object Oriented Analysis & Design & UML (Unified Modeling Language)
46
Other Sources of Classes

Physical objects in the problem domain


Paperwork:


Invoices, orders, bankbooks, etc.
Known interfaces to outside world


Aircraft, people, hotels, etc.
Screens, keyboards, peripherals, etc.
Conceptual entities


Not concrete
But crucial for the business operation
Object Oriented Analysis & Design & UML (Unified Modeling Language)
47
What is a Relationship?


A semantic connections between modeling elements
Examples:

Between actors and use cases


Between use cases and other use cases





Generalization
«include»
«extend»
Between actors and other actors


Associations
Generalization
Objects must be connected to perform a useful job
Link:


A connection between the objects
An instance of an association between their classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
48
Object Diagrams



A snapshot of an executing OO system
To show objects and their relationships
Connected objects



Links are dynamic connections


may adopt various roles
relative to each other
after a time, the roles might change
Links may connect

One object to the other



Two objects to each other


Unidirectional link
Arrow head shows the target
Single line
More than two objects to each other


More than one line
all are connecting the objects
Object Oriented Analysis & Design & UML (Unified Modeling Language)
49
Objects and Roles
Object Oriented Analysis & Design & UML (Unified Modeling Language)
50
Unidirectional Links
Data sent only from :PersonDetails to :Address but not vice versa
Object Oriented Analysis & Design & UML (Unified Modeling Language)
51
Paths
Connecting objects with orthogonal paths to represent the links
Object Oriented Analysis & Design & UML (Unified Modeling Language)
52
Association


Is a relationship between classes
If there is a link between two objects


There must be an association between their classes
Associations may have

Association name




Role name




Verb phrase
An arrow head is used to represent the direction
CamelCase starting with lowercase letter
Alternative to the single name
On one or both ends of the association
Multiplicity
Navigability
Object Oriented Analysis & Design & UML (Unified Modeling Language)
53
Objects: Class Instances
Object Oriented Analysis & Design & UML (Unified Modeling Language)
54
Association Syntax
Object Oriented Analysis & Design & UML (Unified Modeling Language)
55
Role Names in Associations
Role names are represented in both ends of the association
Object Oriented Analysis & Design & UML (Unified Modeling Language)
56
Multiplicity

Specifies






the number of objects
can participate in a relationship
at any point in time
Depends on the requirements
Can encode business rules
Specified as a comma-separated list of
intervals:

minimum..maximum
Object Oriented Analysis & Design & UML (Unified Modeling Language)
57
Multiplicity
Multiplicity is 1-to-n
Object Oriented Analysis & Design & UML (Unified Modeling Language)
58
Specifying the Multiplicity
Object Oriented Analysis & Design & UML (Unified Modeling Language)
59
Association Example with Multiplicity
Object Oriented Analysis & Design & UML (Unified Modeling Language)
60
Modeling with Multiplicity

There is a certain amount of debate on


to show the multiplicity on analysis model or not
It should be included

Because multiplicity describes




business rules
constraints
assumptions
Reflexive associations

One class has an association to itself
Object Oriented Analysis & Design & UML (Unified Modeling Language)
61
Reflexive Associations
Object Oriented Analysis & Design & UML (Unified Modeling Language)
62
Hierarchies and Networks

Hierarchy



Tree structured systems
One root at the top
An object



has only one object above
but many objects below
Network



Graph structured systems
No root is defined
Many objects are connected to each other
Object Oriented Analysis & Design & UML (Unified Modeling Language)
63
Example: Hierarchy
Object Oriented Analysis & Design & UML (Unified Modeling Language)
64
Example: Network
Object Oriented Analysis & Design & UML (Unified Modeling Language)
65
Navigability


Shows that it is possible to traverse from one
object to the other
Means:


Navigability is used


To minimize the coupling between classes
Relationships with arrows



“messages are sent in one direction”
are unidirectional
Traverse in one direction is possible
Relationships without arrows


are bi-directional
Traverse in both directions is possible
Object Oriented Analysis & Design & UML (Unified Modeling Language)
66
Navigability
Object Oriented Analysis & Design & UML (Unified Modeling Language)
67
Associations and Attributes

One-to-one associations between classes


is converted into attributes of source class
Multiplicities greater than one
implemented as either


An attribute of type array
An attribute of some type that is a collection

Example: Java - Vector
Object Oriented Analysis & Design & UML (Unified Modeling Language)
68
1-to-1 Associations
public class
{
private Address address;
}
1-to-1 associations turn into attributes of the source classes
Object Oriented Analysis & Design & UML (Unified Modeling Language)
69
Dependency

A relationship between two elements




The client depends on the supplier
4 basic dependencies:





Usage
Abstraction
Permission
Binding
Dependencies occur between




A change to one element (supplier)
effect the other element (client)
Classes and classes
Classes and objects
Packages and packages
Represented with


Dotted arrow
With the name of the dependency
Object Oriented Analysis & Design & UML (Unified Modeling Language)
70
Basic Types of Dependencies
Object Oriented Analysis & Design & UML (Unified Modeling Language)
71
Dependency Example
Object Oriented Analysis & Design & UML (Unified Modeling Language)
72
End of Chapter
Object Oriented Analysis & Design & UML (Unified Modeling Language)
73