Oose Ood

Requirements
OOA: Investigation of the requirements, concepts, and operations related to a system.

OOD: Designing a solution for this iteration in terms of collaborating software objects.
Real and Essential use cases Essential use case: Real use case:
Use case degree of design commitment very abstract very concrete
Essential
Essentialuse
usecase
casesvery abstract
- created during earlyreal veryof eliciting the requirements
stage
concrete
- independent of the design decisions
Real use cases

- Describe the functionality of the system in terms of its actual current design
committed to specific input output technologies
- Developed only after the design decisions have been made
- Design artifacts
Saroj Shakya, OOSE, Nepal College of
8/1/2010 1
Information Technology
Real vs Essential Use Case
Essential use case
Actor action System response

1. customer identifies themselves 2. Provide Customer with options
3. ……
Real use case

1. customer inserts their cards 2. Prompts for PIN
3. enters PIN on key pad 4. Displays option menu
……………..

8/1/2010 2
Buy Items use case
Essential
1. cashier records identifier for each item 2. Determine the item price and add the item info
If there is more than one of the same to the running sales transaction description
The cashier enters quantity price of the current item in item presented
Real
1. For each item cashier types UPC 2. Display item price and add the item information
In the UPC input field of window then to the running sales transactions the description
They press “enter item” button and price of current item are displayed
with the mouse or keyboard

8/1/2010 3
Elaboration of ATM Use Case
Use Case Name : Withdraw Funds
Summary : Customer uses a valid card to withdraw funds from a valid bank
account.
Actor : ATM Customer
Precondition : ATM is displaying the idle welcome message
Description :
– Customer inserts an ATM Card into the ATM Card Reader.
– If the system can recognize the card, it reads the card number.
– System prompts the customer for a PIN.
– Customer enters PIN.
– System checks the card's expiration date and whether the card has been stolen
or lost.
– If the card is valid, the system checks if the entered PIN matches the card PIN.
– If the PINs match, the system finds out what accounts the card can access.
– System displays customer accounts and prompts the customer to choose a
type of transaction.
There are three types of transactions, Withdraw Funds, Get Balance are part of
all three use cases;

8/1/2010 4
Elaboration of ATM Use Case – (2/3)
Description (continued) :
– Customer selects Withdraw Funds, selects the account number, and enters the
amount.
– System checks that the account is valid, makes sure that customer has enough
funds in the account, makes sure that the daily limit has not been exceeded,
and checks that the ATM has enough funds.
– If all four checks are successful, the system dispenses the cash.
– System prints a receipt with a transaction number, the transaction type, the
amount withdrawn, and the new account balance.
– System ejects card.
– System displays the idle welcome message.

8/1/2010 5
Alternatives :
– If the system cannot recognize the card, it is ejected and the welcome
message is displayed.
– If the current date is past the card's expiration date, the card is confiscated
and the welcome message is displayed.
– If the card has been reported lost or stolen, it is confiscated and the welcome
message is displayed.
– If the customer entered PIN does not match the PIN for the card, the system
prompts for a new PIN.
– If the customer enters an incorrect PIN three times, the card is confiscated and
the welcome message is displayed.
– If the account number entered by the user is invalid, the system displays an
error message, ejects the card and the welcome message is displayed.

8/1/2010 6
– If the request for withdraw exceeds the maximum allowable daily withdrawal
amount, the system displays an apology message, ejects the card and the
welcome message is displayed.
– If the request for withdraw exceeds the amount of funds in the ATM, the
system displays an apology message, ejects the card and the welcome message
is displayed.
– If the customer enters Cancel, the system cancels the transaction, ejects the
card and the welcome message is displayed.
Postcondition :
Funds have been withdrawn from customer's account.

8/1/2010 7
OOD
During object design, a logical solution based on the object-oriented paradigm is
developed.
The heart of this solution is the creation of interaction diagrams, which illustrate how
objects collaborate to fulfill the requirements.
Design class diagrams can be drawn after or in parallel with drawing interaction
diagrams.
These summarize the definition of the software classes (and interfaces) that are to
be implemented in software.
In terms of the UP, these artifacts are part of the Design Model.
The creation of interaction diagrams requires the application of principles for

assigning responsibilities and the use of design principles and patterns.

8/1/2010 8
UP Artifacts
Requirements
Business Model
Op. Contract
Method( ) Operation
Starting events
Domain Model Sys. Seq. Diagram Post-conditions
Use Case
Suggestions for names Title
Functional
1. …
requirements
2. …
method1( )
method2( )
method3( ) Item details
Glossary
Interaction Diagrams Domain rules
Non-functional Supplementary
requirements Specification
Design Class Diagram
Design Model

8/1/2010 9
Determining Visibility
Sale Captured on Register Produce Catalogue
timeStamp
Domain Model
Process Sale
1. Customer arrives
conceptual makeNewSale( )
Process Sale
classes in 2. Cashier makes
the new sale…. System Events
Cashier
domain enterItem(id,quantity )
inspire the
names of Use Case
some Use Case Model Sys. Seq. Diagram Use Case Diagrams
software
classes in :Register :ProductCatalogue
the design
makeNewSale( ) create( )
:Sale
enterItem(id,quantity )
spec:=getSpecification(id)
addLineItem(spec, quantity)
the design
classes
Register ProductCatalogue discovered
while designing
1 1
UCRs can be
makeNewSale( ) getSpecification( ) summarized in
class diagrams
enterItem(id,quantity )
…………………..
Design Model
8/1/2010 10
interaction diagram
The term interaction diagram, is a generalization of two more specialized UML

diagram types; both can be used to express similar message interactions:
- Collaboration diagrams
- Sequence diagrams
Buy Item-version 1 :System
enterItem
Operation : enterItem (UPC, qty)
enterItem
Post-conditions
endSale
If a new sale, a new sale :Register
makePayment created.
Collaboration
System Sequence Contract
Diagram
Diagram

8/1/2010 11
Common Interaction Diagram
Notation
For any kind of UML element (class, actor, ...), an instance uses the same graphic
symbol as the type, but the designator string is underlined.
To show an instance of a class in an interaction diagram, the regular class box

graphic symbol is used, but the name is underlined.
A name can be used to uniquely identify the instance. If none is used, a ":"
precedes the class name.
The UML has adopted a simple and consistent approach to illustrate instances vs.
classifiers:

8/1/2010 12
Basic Message Expression Syntax
The UML has a standard syntax for message expressions:
return := message(parameter : parameterType) : returnType
Type information may be excluded if obvious or unimportant. For example:
spec := getProductSpect(id)
spec := getProductSpect(id:ItemID)
spec := getProductSpect(id:ItemID) ProductSpecification

8/1/2010 13
Basic Collaboration Diagram Notation
Links
A link is a connection path between two objects; it indicates some form of
navigation and visibility between the objects is possible
More formally, a link is an instance of an association.
For example, there is a link or path of navigation from a Register to a Sale, along
which messages may flow, such as the makePayment message.

8/1/2010 14
Messages
Each message between objects is represented with a message expression and small
arrow indicating the direction of the message.
Many messages may flow along this link .
A sequence number is added to show the sequential order of messages in the
current thread of control.

8/1/2010 15
Messages to "self" or "this"

A message can be sent from an object to itself , illustrated by a link to itself, with
messages flowing along the link.

8/1/2010 16
Creation of Instances
A convention in the UML to use a message named create for this purpose.
If another (perhaps less obvious) message name is used, the message may be
annotated with a special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of initial
values. e.g. a constructor call with parameters in Java.
The UML property {new} may optionally be added to the instance box to highlight
the creation

8/1/2010 17
Conditional Messages
A conditional message is shown by following a sequence number with a conditional

clause in square brackets, similar to an iteration clause.
The message is only sent if the clause evaluates to true.

8/1/2010 18
Iteration or Looping
Iteration notation: If the details of the iteration clause are not important to the
modeler, a simple ’*’ can be used.

8/1/2010 19
Mutually Exclusive Conditional Paths

The example illustrates the sequence numbers with mutually exclusive conditional
paths.

8/1/2010 20
Path letter. The first letter used is a by convention.
Example:
Either 1a or 1b could execute after msg1. Both are sequence number 1 since either
could be the first internal message.
Note that subsequent nested messages are still consistently prepended with their
outer message sequence. Thus Ib. 1 is nested message within Ib.

8/1/2010 21
Message Number Sequencing
The order of messages is illustrated with sequence numbers.
The numbering scheme is:
1. The first message is not numbered. Thus,msg1() is unnumbered.
2. The order and nesting of subsequent messages is shown with a legal numbering
scheme in which nested messages have a number appended to them.
Nesting is denoted by prepending the incoming message number to the out going
message number.

8/1/2010 22
Iteration Over a Collection
(Multiobject)
A common algorithm is to iterate over all members of a collection (such as a list or
map), sending a message to each.
Often, some kind of iterator object is ultimately used, such as an implementation of
java.util.Iterator or a C++ standard library iterator.
In the UML, the term multiobject is used to denote a set of instances .a collection.
The "*" multiplicity marker at the end of the link is used to indicate that the
message is being sent to each element of the collection, rather than being
repeatedly sent to the collection object itself.

8/1/2010 23
Messages to a Class Object
Messages may be sent to a class itself, rather than an instance, to invoke class or
static methods.
A message is shown to a class box whose name is not underlined, indicating the
message is being sent to a class rather than an instance .

8/1/2010 24
Collaboration Diagram
The collaboration diagram is read as follows:

1. The message makePayment is sent to an instance of a Register. The sender is not
identified.
2. The Register instance sends the makePayment message to a Sale instance.
3. The Sale instance creates an instance of a Payment.

8/1/2010 25
Polymorphism?

8/1/2010 26
Basic Sequence Diagram Notation
Links
Unlike collaboration diagrams, sequence diagrams do not show links.
Messages
Each message between objects is represented with a message expression on an
arrowed line between the objects.
The time ordering is organized from top to bottom.

8/1/2010 27
Focus of Control and Activation Boxes
sequence diagrams may also show the focus of control using an activation box. The
box is optional, but commonly used by UML practitioners.
Illustrating Returns
the return from a message is shown as a dashed open-arrowed line at the end of an
activation box (Optional). Some annotate the return line to describe what is being
returned (if anything) from the message.

8/1/2010 28
Messages to "self" or "this"

A self message is shown as being sent from an object to itself by using a nested
activation box

8/1/2010 29
Object Lifelines and Object
Destruction
object lifelines are the vertical dashed lines underneath the objects that indicate the
extent of the life of the object in the diagram.
In some circumstances it is desirable to show explicit destruction of an object (as in
C++, which does not have garbage collection);

8/1/2010 30
Conditional Messages
Mutually Exclusive Conditional Messages

The notation for this case is a kind of angled message line emerging from a common
point

8/1/2010 31
Iteration for a Single Message
Messages to Class Objects

As in a collaboration diagram, class or static method calls are shown by not
underlining the name of the classifier, which signifies a class object rather than an
instance.
Iteration for a sequence of
8/1/2010 32
Iteration over a multiobject
Invoking class or static methods

8/1/2010 33
Interaction Diagrams and System
Events Example
In the current scenario of POST , let us consider two use cases and their
associated system events
Buy Items
enterItem()
endSale()
makePayment()
Start Up
startup()
At least four interaction diagrams, one for each system event.
The POST can be chosen as the controller for handling the events

8/1/2010 34
Interaction Diagrams and System
Events
enterItem()  1: ???() 
:POST
endSale()  1: ???() 
:POST
makePayment()  1: ???() 
:POST
startUp()  1: ???() 
:POST

8/1/2010 35
Contracts
For each system a contract exists which elaborates on what the operation must
achieve
Using the contract responsibility and post conditions, and use cases as a starting
point, design a system of interacting objects to fulfill the task
Name: enterItems (upc: number, quanity: integer)
Responsibility: Enter (record) sale of an item and add it to the sale. Display the item description
and price.
Type System, System Functions: R1.1, R1.3, R1.9
Cross References: Use Cases: Buy Items
Exceptions: If UPC is not valid, indicate that it was an error.
Pre-conditions:
Post-condition: If a new sale, a sale was created (instance)

If a new sale, the new sale was associated with the POST (association formed)
A SaleLineItem was created (instance creation)
The SaleLineItem was associated with the Sale. (association formed)
enterItem(upc, qty)  :POST 1: [new sale] create()  :Sale

8/1/2010 36
Responsibilities and Methods
The UML defines a responsibility as "a contract or obligation of a classifier”
Responsibilities are related to the obligations of an object in terms of its behavior.

c
Basically, these responsibilities are of the following two types:
Doing responsibilities of an object include:

- doing something itself, such as creating an object or doing a calculation
- initiating action in other objects
- controlling and coordinating activities in other objects
Knowing responsibilities of an object include:

- knowing about private encapsulated data
- knowing about related objects
- knowing about things it can derive or calculate

8/1/2010 37
Responsibilities are assigned to classes of objects during object design.

For example,
"a Sale is responsible for creating SalesLineltems"
? (a doing),
"a Sale is responsible for knowing?its total" (a knowing).
Relevant responsibilities related to "knowing" are often inferable from the domain
model, because of the attributes and associations it illustrates.
The translation of responsibilities into classes and methods is influenced by the

granularity of the responsibility.
responsibility to "provide access to relational databases" involves dozens of classes

and hundreds of methods, packaged in a subsystem.
responsibility to "create a Sale" may involve only one or few methods.

8/1/2010 38
A responsibility is not the same thing as a method, but methods are implemented
to fulfill responsibilities.
Responsibilities are implemented using methods that either act alone or

collaborate with other methods and objects.
the Sale class might define one or more methods to know its total; say, a method
named getTotal.
To fulfill that responsibility, the Sale may collaborate with other objects, such as
sending agetSubtotal message to each SalesLineltem object asking for its subtotal.

8/1/2010 39
Responsibilities and Interaction
Diagrams
Within the UML artifacts, a common context where these responsibilities
(implemented as methods) are considered is during the creation of interaction
diagrams
Sale objects have been given a responsibility to create Payments, which is invoked
with a makePayment message and handled with a corresponding makePayment
method.
Interaction diagrams show choices in assigning responsibilities to objects.

When created, decisions in responsibility assignment are made, which are reflected
in what messages are sent to different classes of objects.

8/1/2010 40
Patterns
Experienced object-oriented developers build up a repertoire of both general

principles and idiomatic solutions that guide them in the creation of software.
These principles and idioms, if codified in a structured format describing the

problem and solution, and given a name, may be called patterns.
Patterns are named problem/solution pairs that codify good advice and
principles often related to the assignment of responsibilities.
For example:
Pattern Name:
Solution:
Problem It Solves:

8/1/2010 41
Patterns Have Names
All patterns ideally have suggestive names.
Naming a pattern, technique, or principle has the following advantages:
- It supports chunking and incorporating that concept into our

understanding and memory.
- It facilitates communication. Naming a complex idea such as a pattern is

an example of the power of abstraction
- reducing a complex form to a simple one by eliminating detail.

Therefore, the GRASP patterns have concise names such as Information
Expert, Creator, Protected Variations.
GRASP: General Responsibility Assignment Software Patterns.
the GRASP patterns guide choices in where to assign responsibilities.

These choices are reflected in interaction diagrams.

8/1/2010 42
i. Information Expert
Assign a responsibility to the class that has the information necessary to fulfill the
responsibility.
Who should be responsible for knowing the grand total of a sale"? (Look up in the
design model and the domain model)
Only sales instance in conceptual model knows the information about the grand total
by having the all the information about the SalesLineItem in the Sale and the sum of
their subtotals. Hence sale in information expert

8/1/2010 43
i. Information Expert

8/1/2010 44
ii. Creator
Assign class B the responsibility to create an instance of class A if one or more of

the following is true:
- B aggregates A objects.
- B contains A objects.
- B records instances of A objects.
- B closely uses A objects.
B has the initializing data that will be passed to A when it is created (thus B is an
Expert with respect to creating A).
B is a creator of A objects.
If more than one option applies, prefer a class B which aggregates or contains
class A.

8/1/2010 45
ii. Creator
Aggregates many sales

line items!!

8/1/2010 46
iii. High Cohesion
Assign responsibility so that cohesion remains high

cohesion (or more specifically, functional cohesion) is a measure of how strongly
related and focused the responsibilities of an element are.
An element with highly related responsibilities, and which does not do a
tremendous amount of work, has high cohesion.
A class with low cohesion does many unrelated things, or does too much work.
Such classes are undesirable; they suffer from the following problems
- hard to comprehend
- hard to reuse
- hard to maintain
- delicate; constantly effected by change
Low cohesion classes often represent a very "large grain" of abstraction, or have
taken on responsibilities that should have been delegated to other objects

8/1/2010 47
Makes it
incohisive!!
Here the Register is taking on part of the responsibility fulfilling the

makePayment function.

8/1/2010 48
iv. Low Coupling
Assign a responsibility so that the coupling remains low.

Coupling is a measure of how strongly one element is connected to, has knowledge
of, or relies on other elements.
An element with low (or weak) coupling is not dependent on too many other
elements
A class with low cohesion does many unrelated things, or does too much work.
Such classes are undesirable; they suffer from the following problems:
- hard to comprehend
- hard to reuse
- hard to maintain
- delicate; constantly effected by change
Low cohesion classes often represent a very "large grain" of abstraction, or have
taken on responsibilities that should have been delegated to other objects

8/1/2010 49
iv. Low Coupling
A need to create a Payment instance and associate it with the Sale.

What class should be responsible for this?
Since a Register "records" a Payment in the real-world domain, the Creator pattern
suggests Register for creating the Payment.

8/1/2010 50
iv. Low Coupling
The Register instance then sends an addPayment message to the Sale, passing along
the new Payment as a parameter.
makePayment  1:create() 
:Register p: Payment
2: addPayment(p) 
:Sale
makePayment  1:makePayment 
:Register :Sale
1.1: create()
Lessens coupling
hence better!!
: Payment

8/1/2010 51
v. Controller
Assign the responsibility for receiving or handling a system event message to a

class representing one of the following choices:
Represents the overall system, device, or subsystem (facade controller).
Represents a use case scenario within which the system event occurs, often named
<UseCaseName> Handler, <UseCaseName> Coordinator, or <Use-CaseName>
Session (use-case or session controller).

8/1/2010 52
v. Controller
Use the same controller class for all system events in the same use case
scenario.
Informally, a session is an instance of a conversation with an actor.
Sessions can be of any length, but are often organized in terms of use cases
A Controller is a non-user interface object responsible for receiving or handling a

system event.
A Controller defines the method for the system operation.

8/1/2010 53
v. Controller

8/1/2010 54
v. Controller

8/1/2010 55
v. Controller

8/1/2010 56
Visibility between Objects
For a Sender Object to send message to a receiver object, the sender must be
visible to the receiver or sender must have some kind of reference or pointer to the
receiver object

8/1/2010 57
Visibility
Q. What is visibility?
A. Visibility is the ability of one object to see or have reference to another.
The ability of one object to see or have reference to another object
It is related to the issue of scope
Q. When is visibility necessary?

A. To send a message from one object to another, the receiver object must be
visible to the sender, so the sender has to have a pointer or reference to the
receiver.

8/1/2010 58
Four common ways that visibility can be achieved from Object A to Object B.
Attribute Visibility-B is an Attribute of an A.

Parameter Visibility-B is a parameter of a method of A.
Locally Declared Visibility-B is declared as a local object in a method of A.
Global Visibility-B is in some way globally visible.
“For any object A to send a message to an object B, B must be visible to A”

8/1/2010 59
I. Attribute Visibility
It exist from A to B when B is an attribute of A.

It is permanent visibility because it persists as long as A and B exists.
It is very common form of visibility in object oriented systems.
public class Register{
…
private ProductCatalog catalog;
…
}

8/1/2010 60
ii. Parameter Visibility
It exists from A to B when B is passed as a parameter to a method of A.

It is temporary as it persists only within the scope of the method.
It is common to transform parameter visibility into attribute visibility.

8/1/2010 61
It exists from A to B when B is passed as a parameter to a method of A.

It is temporary as it persists only within the scope of the method.
Within the scope of the makeLineItem method, the

sale has parameter visibility to ProdutSpecification

8/1/2010 62
For example, when the Sale creates a new SalesLineItem, it passes a
ProductSpecifi-cation in to its initializing method (in C++ or Java, this would
be its constructor).
Within the initializing method, the parameter is assigned to an attribute, thus
establishing attribute visibility

8/1/2010 63
iii. Local Visibility
Local visibility from A to B exists when B is declared as a local object within a

method of A.
It is a relatively temporary visibility because it persists only within the scope of

the method
Two common means by which local visibility is achieved are:
• Create a new local instance and assign it to a local variable.

• Assign the returning object from a method invocation to a local variable.
Ex: anObject.getAnotherObject.doSomething();

8/1/2010 64
iv. Global Visibility
It exists between A to B when B is global to A. It is relatively permanent visibility

because it persists as long as A and B exists
One way to achieve global visibility is to assign an instance to a global variable,

which is possible in some languages, such as C++, but not others, such as Java.
The least common form of visibility in OO Systems.

8/1/2010 65
Visibility in the UML
Public:
Any outside classifier with visibility to the given classifier can use the feature;
specified by pre-pending the symbol “+”
Protected:
Any descendant of the classifier can use the feature; specified by pre-pending
the symbol “#”
Private:
Only the classifier itself can use the feature; specified by pre-pending the
symbol “-”

8/1/2010 66
Q. Which would you use if you wanted a relatively permanent

connection?
A. attribute, or ?global
Q. Which would you use if you didn't want a permanent connection?

A. parameter, or? local
Q. How would you create a local visibility?

A. Create a new instance - use
? result of a method call
Q. How would you achieve a global visibility?

A. Use a global variable in C++, static (or class) variable (in C++ or Java) -
use the Singleton pattern (a static ?method that returns the object)

8/1/2010 67
DESIGN CLASS DIAGRAM
functional (behavioral)
calculations, technical details, data manipulation and processing and other specific
functionality
non-functional (everything else);
(also known as quality requirements), which impose constraints on the design or
implementation (such as performance requirements, security, cost and reliability).

8/1/2010 68
Activities and Dependencies

identify the specification for the software classes (and interfaces) that participate in
the software solution, and annotate them with design details, such as methods.
The creation of a class diagram is dependent on:
Interaction Diagram: this tells the designer about the software classes that
participate in the solution
Conceptual Model: The designers adds details to this class definitions.
“Class Diagrams are created in parallel with Interaction Diagrams”

8/1/2010 69
During analysis -> emphasize domain concepts
During design -> shift to software artifacts
UML has no explicit notation for DCDs
It illustrates the specification for software classes and interfaces in an application.
Typical information that it includes: classes, association and attributes

interface with their operation and constants , methods, attribute type,
information, navigability, dependencies

8/1/2010 70
Domain Model: Real-world DCD: Definitions for

Conceptual Classes Concepts Design Classes Software Classes
UML uses Class Diagram for Design Class Diagram

8/1/2010 71
How to make Design Class Diagram?
Identify all the classes participating in the software solution by analyzing the
interaction diagram
Draw them in a class diagram
Duplicate the attributes from the associated concepts in the conceptual model
Add methods names by analyzing the interaction diagrams
Add type information to the attributes and methods
Add the associations necessary to support the required attribute visibility

Add navigability arrow to the association to indicate the direction of attribute
visibility
Add dependency relationship line to indicate non-attribute visibility

8/1/2010 72
Conceptual Model vs Design Class
Diagram
Domain Model:
a Sale does not represent a software definition ; rather, it is an abstraction of a
real-world concept about which we are interested in making a statement.
DCDs:
Design Classes express the definition of classes as software components. In these
diagrams, a Sale represents a software class

8/1/2010 73
Developing a Domain Class Diagram:
the POS DCD
1) Identify software classes:
2) Begin drawing a Class Diagram
3) Include the attributes from the domain model

4) Add method names
—from interaction diagrams
—model class & interaction diagrams in parallel
5) Add associations and navigability

—Navigability implies visibility of attributes
6) Adding dependency relationships

8/1/2010 74
the POS DCD
1) Identify software classes:
These can be found by scanning all the interaction diagrams and listing the classes
mentioned.
For the POS application, these are:
Register Sale
ProductCatalog ProductSpecification
Store SalesLineItem
Payment

8/1/2010 75
the POS DCD
2) Begin drawing a Class Diagram

3) Include the attributes from the domain model
Draw a Class Diagram by including attributes identified in previous conceptual
model

8/1/2010 76
the POS DCD
4) Add method names
This can be done by analyzing the interaction diagram (collaboration diagram)

8/1/2010 77
the POS DCD
Method Names: Issues
The following special issues must be considered with respect to method names
- Interpretation of the create() message
- Depiction of accessing methods
- Interpretation of messages to multiobjects
- Language dependent syntax

8/1/2010 78
the POS DCD
Method names – Create:
The create message is the UML language independent form to indicate

instantiation and initialization.
In java it implies the invocation of the new operator followed by a constructor call
Method Names – Accessing methods:
Accessing methods are those which retrieve or set attributes.

For example, the ProductSpecification’s price (or getPrice) method is not shown,
although present, because price is a simple accessor method.

8/1/2010 79
Method Names – MultiObjects

A message to multiobject is interpreted as a message to the container/collection
object itself.
The find() message is to the container object, not to a ProductSpecification
Thus the find() method is not a part of the ProductSpecification class; rather it is
part of the hash table or dictionary class definition.

8/1/2010 80
the POS DCD
Method names – Language Dependent Syntax
Some languages such as small talk, have a syntactic form for methods that is
different from that of the basic UML format of methodName (parameterList).
It is recommended that the Basic UML format be used even if the planned
implementation language uses a different syntax.
The translation should ideally take place during the code generation time, instead
of during the creation of the class diagram.
Rectangle(100, 200); Rectangle width: 100 height: 200
Adding More Type- Information

The Design Class Diagram should be considered by considering the audience
If it is being in a CASE tool with automatic code generation, full and exhaustive
details are necessary.
If it is being created for the software developer to read, exhaustive detail may
adversely affect the noise – to –value ratio.

8/1/2010 81
the POS DCD
5) Add associations and navigability
Each end of an association is called a role, and in the DCDs the role may be
decorated with a navigability arrow.
Navigability is a property of the role that indicates that it is possible to navigate uni-
directionally across the association from objects of the source to target class.
Navigability implies visibility—usually attribute visibility
The usual interpretation of an association with navigability arrow is attribute visibility

from the source to target class.
For instance Register class will define an attribute that references a Sale instance.

8/1/2010 82
the POS DCD

8/1/2010 83
the POS DCD
Common situations suggesting a need to define an association with navigability
adornment from A to B
- A sends a message to B
- A creates an instance of B
- A needs to maintain a connection to B

8/1/2010 84
Navigability is defined from Collaboration Diagram
From the collaboration diagram we see that the Store should have an ongoing
connection to the Register and Product Catalogue instance that is created.
Similarly the ProductCataloge needs an on going to the collection of

ProductSpecifications it created
Thus the creator of another object very typically requires an ongoing

connection to it.

8/1/2010 85
8/1/2010 86
Adding Dependency Relationships
Visibility
The UML includes general dependency relationship which indicates that one
element has knowledge of another element. It is illustrated with dashed arrow line.
In Class Diagram its significance is to depict non-attribute visibility between classes.

8/1/2010 87

Oose Ood

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Oose Ood

Transféré par

Droits d'auteur :

Formats disponibles

Requirements

OOA: Investigation of the requirements, concepts, and operations related to a system.

Real use cases

Essential use case

Actor action System response

Real use case

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

The creation of interaction diagrams requires the application of principles for

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

The term interaction diagram, is a generalization of two more specialized UML

Buy Item-version 1 :System

Saroj Shakya, OOSE, Nepal College of

To show an instance of a class in an interaction diagram, the regular class box

Saroj Shakya, OOSE, Nepal College of

The UML has a standard syntax for message expressions:

return := message(parameter : parameterType) : returnType

Type information may be excluded if obvious or unimportant. For example:

spec := getProductSpect(id:ItemID) ProductSpecification

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Messages to "self" or "this"

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

A conditional message is shown by following a sequence number with a conditional

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Mutually Exclusive Conditional Paths

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

The collaboration diagram is read as follows:

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Focus of Control and Activation Boxes

Saroj Shakya, OOSE, Nepal College of

Messages to "self" or "this"

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Mutually Exclusive Conditional Messages

Saroj Shakya, OOSE, Nepal College of

Iteration for a Single Message

Messages to Class Objects

Iteration over a multiobject

Invoking class or static methods

Saroj Shakya, OOSE, Nepal College of

At least four interaction diagrams, one for each system event.

Saroj Shakya, OOSE, Nepal College of

Saroj Shakya, OOSE, Nepal College of

Name: enterItems (upc: number, quanity: integer)

Post-condition: If a new sale, a sale was created (instance)

enterItem(upc, qty)  :POST 1: [new sale] create()  :Sale

Saroj Shakya, OOSE, Nepal College of