System Modeling
Content
-Why to use model?
- UML models, standard guideline, examples.
- UML Use Case Diagram
- UML Class Diagram
- UML Sequence Diagram
- UML Package Diagram
- UML State machine Diagram
Why models?
Models aim for efficient and precise communication and documentation.
- Abstractions (simplifications) of reality.
- Different levels of abstraction.
- Communication between domains
( problem -> design -> implementation)
Why models?
Models give different perspectives to the system (structure,
operation)
Model 2
Model 1
Model 3
System
Representing Models- Diagrams
To represent models, the organization needs to adopt standards and guidelines to
be practiced.
• First step: Settle on a common notation. UML de nes the notation and semantics
for common object-oriented models.
• Second step: Set modeling style guidelines for creating consistent and cleanlooking diagrams.
• Standard- involves using a squared rectangle to model a class on a class diagram.
• Style guideline- would involve placing subclasses on diagrams below their
superclass(es).
• Third step: Enact modeling standards and guidelines through training and
mentoring the staffs.
Diagram types
• Use case diagrams.
• Class diagrams.
• Interaction diagrams, ie. sequence and collaboration diagrams.
• State chart diagrams
• Activity diagrams.
• Component diagrams.
• Deployment diagrams.
Diagram types (example..)
Use case diagram
• Use case diagrams.
Handle tree
• Displays actors, use cases, and their relationships.
driver
• A very simple notation.
Cut log
popularity: 3, complexity: 1
Class/object diagrams
• Class diagrams.
• Displays classes and their relationships.
1..*
Tree
Log
pine: Tree
:Tree
• By far the most important diagram type in all OO methods.
• Used from domain analysis to implementation.
• A rich notation.
popularity: 2, complexity: 3
Popularity&complexity are ranked from 1 to 3 (a very subjective ranking by ijh)
Diagram types (example)
• Interaction diagrams, ie. sequence and collaboration
diagrams:
• Describes a scenario of object interactions
• A simple notation.
Sequence diagram
pine:Tree
:Log
Driver
Cut
<<create>>
calcullate
• Statechart diagrams:
• Describes the functionality of an object (or any system)
• A rich notation, systems can be modelled to almost any
level of detail (enables code generation)
Feed
setMeasures
popularity: 3, complexity: 1
Activity diagram
State diagram
H
• Activity diagrams:
H
UML std: An activity diagram is a
special case of a state diagram in
which all (or at least most) of the
states are action or subactivity
states
Catch hold of tree
Saw idle
Cut /
^Start chain
CutOK /
^StopChain
Fall the tree
Select tree
variety
H
Saw
operational
popularity: 2, complexity: 1
Feed&saw
H
popularity: 2, complexity: 3
Popularity&complexity are ranked from 1 to 3 (a very subjective ranking by ijh)
UML Use-Case Diagrams
Use-Case diagram
A use case diagram is a graph, consists of
- Actors
- A set of use cases
- Possibly some interfaces, and
- Relationships between these elements.
-
Associations between the actors and the use cases.
-
Generalizations between the actors
-
Generalizations, Extends, and Includes among the use cases.
- The use cases may optionally be enclosed by a rectangle:
Represents the boundary of the containing system.
Use-Case diagram: notations
Actor: the user role
participating to the
use case
System
Use case
Use case contains
points of expansion, to
which another use case
may be placed
<<extend>>
Use case
Actor
The use case includes
Another UC
Use case
<<include>>
Use case
Use case is a special
case of another UC
Use-Case diagram: Guidelines
A UML use-case diagram shows the relationships among actors and
use cases within a system.
Use-case models should be developed from the point of view of
project stakeholders and not from the (often technical) point of view
of developers.
Use-Case Guidelines
Begin Use-Case Names with a Strong Verb: As, Withdraw Funds,
Register Student in Seminar, and Deliver shipment.
Problematic: “process,” “perform,” and “do” are often.
Problematic: Technically oriented, as Process Withdrawal Transaction or
Perform Student Enrollment Req.
Name Use Cases Using Domain
Terminology.
Imply logical timing Considerations
by stacking Use Cases.
Actor Guidelines
An actor is a person, organization, local process (e.g., system clock),
or external system that plays a role in one or more interactions with the
system.
Place Primary Actor(s) in the Top Left Corner of the Diagram.
Draw Actors on the Outside Edges of a Use-Case Diagram: Actors are
outside scope of control.
Name Actors with Singular,
Domain-Relevant Nouns:
That accurately reflects
its role.
Associate Each Actor with
One or More Use Cases.
Actor Guidelines
Name Actors to Model Roles, Not Job Titles.
Use
<<system>> to Indicate System Actors: The <<system>>
stereotype is applicable to system/concrete diagrams that reflect
architectural decisions made for the system.
Don’t Allow Actors to Interact
with One Another.
Introduce an Actor Called
“Time” to Initiate Scheduled
Events.
Relationship Guidelines
an association between an actor and a use case,
an association between two use cases,
a generalization between two actors,
a generalization, includes and extends among use cases.
Associations are depicted as:
Lines connecting two modeling elements.
An optional open-headed arrowhead on one end of the line, indicating
the direction of the initial invocation of the relationship.
Generalizations are depicted as closed-headed arrows pointing
toward the more general modeling elements.
Relationship Guidelines
Indicate an Association Between an Actor and a Use Case if the Actor
Appears Within the Use-Case Logic:
If an actor, supplies information
initiates the use case, or
receives any information as a result of the use case
Avoid Arrowheads on Actor–Use-Case Relationships: Associations
do not represent
information.
Relationship Guidelines
Apply <<include>> When You Know Exactly When to Invoke the Use
Case: association is as the invocation of one use case by another one, just
like calling a function or invoking an operation within source code.
Apply <<extend>>: A generalization relationship where the extending use
case continues the behavior of the base use case by conceptually inserting
additional action sequences into the base use case.
Generalize Use Cases When a
Single Condition Results in
Significantly New Business Logic.
Relationship Guidelines
Avoid More Than Two Levels of Use-Case Associations.
Place an Included Use Case to the Right of the Invoking Use Case.
Place an Extending Use Case Below the Parent Use Case.
Place an Inheriting Use Case Below the Base Use Case.
Place an Inheriting Actor Below the Parent Actor.
Apply the “Is Like” Rule to Actor and Use-Case Inheritance.
System Boundary Box Guidelines
The rectangle around the use cases is called the system boundary box.
It indicates the scope of the system.
Indicate Release Scope with a System Boundary Box.
Avoid Meaningless System Boundary Boxes.
Describing use cases
The contents of a use case can for example be described as follows:
Name of the use case: A Descriptive Name
Actors: list of participating actors
Preconditions: Which conditions apply in the beginning of the use case
Description: Informal description (text, pictures, state diagrams, activity
diagrams, interaction diagrams)
Exceptions: exception conditions (included in the description in brackets [ ])
Postconditions: Conditions that apply at the end of the use case
Other conditions: Non-functional requirements.
Example (1/3)
An usage scenario: Class-room researvation system
A university class-room reservation system can be accessed by the
lecturer, course assisant and the maintainance officer. Both lecturer
and the assistant can reserve a room, with the lecturer and the
maintainance officer has the privillage to cancel a prior reservation.
Reservation can be made to a auditorium and conventional class
rooms. To perform any of the above mentioned actions, user must
provide and authenticate their identity first.
Example (2/3)
classroom reservation system
Remove
reservations
Maintenance
Lecturer
<<include>>
Reserve
auditorium
Maintain data
<<include>>
<<include>>
Reserve
class
assistant
<<include>>
User
indentification
Example (3/3)
Name: Reserve auditorium, version 1.0 / ijh
Actors: Lecturer, course assistant, maintainance officer
Preconditions: Person and course is available in the system (UC “personal data
management”)
Description: The lecturer follows a www-link that leads to the system’s main page and
fills in his user name and password (includes: UC “user identification”). The user requests
the system to show the reservation situation of a certain room at a certain time. He gets
the time schedule screen of the room (see appendix). The user sees on the screen all the
free timeslots. He also sees the courses the room is reserved for and the length of the
reservations. The user makes a reservation for a free time slot [exception: reservation
fails].
Exceptions: Reservation fails: The reservation situation may have changed during the
user is making his reservation. The system notifies the user about the situation and the
user tries again.
Postconditions: The reservations for the course lecture times have been made
successfully.
Other conditions: The response time has to be under 1 second, time schedule screen
update per day may last 5 seconds.
Why use cases?
Connecting customer requirements to the system’s functions
Enables a common understanding of the system under development
Defines the boundary of the system
Helps to recognize who or what is using the system
Specifies the higher level functionality of the system
Specifies the basic terms of the system
Helps identifying objects/subsystems
Helps in assigning responsibilities/functionality to different parts of the system
Can be used for organizing software development (planning iterations)
Can be used in design of test cases
Can be used in writing user manuals
UML Class Diagrams
Class diagram
UML class diagrams show
•
the classes of a system
•
their interrelationships, and the
•
operations and attributes of the classes.
They are used to
•
Analyze requirements in the form of a conceptual/analysis
model.
•
Depict the detailed design of object-oriented or object-based
software.
Class Diagram
1. Classes
2. Relationships
A class
Indicate Language-Dependent Visibility with Property Strings
Visibility
Indicate Visibility:
The visibility of an operation or attribute defines the level of access that
objects have to it.
Class Style Guidelines
Be Consistent with Attribute Names and Types:
Customer-Number can be a string or an integer.
customerID
can be a string or an integer.
Use Common Terminology for Class Names:
For business classes, terminology such as Customer, OrderItem,
and Shipment
For technical classes, terminology such as MessageQueue,
ErrorLogger, and PersistenceBroker
Prefer Complete Singular Nouns for Class Names:
Names such as Customer and PersistenceBroker are preferable
to Cust and PBroker, respectively
Class Style Guidelines
Name Operations with Strong Verbs: Operations implement the functionality of an
object.
Class Style Guidelines
Name Attributes with Domain-Based Nouns:
Class Style Guidelines
Do Not Model Scaffolding Code:
Class Style Guidelines
Center Class Names.
Left-Justify Attribute Operation and Names.
Do Not Model Keys: Keys are a data concept, not an object-oriented concept
Never Show Classes with Just Two Compartments:
Topmost compartment indicates the name of the class and any information
pertinent to the class as a whole (such as a stereotype).
Second optional compartment typically lists the attributes.
Third optional compartment typically lists the operations.
Include an Ellipsis ( . . . ) at the End of an Incomplete List
Label Uncommon Class Compartments.
Class Style Guidelines
List Static Operations/Attributes Before Instance Operations/Attributes.
List Operations/Attributes in Order of Decreasing Visibility.
For Parameters That Are Objects, List Only Their Types.
Develop Consistent Operation and Attribute Signatures:
For example, theFirstName, firstName, and fNm.
doFF(securityToken, xx) and doFFF(yy, securityToken).
Avoid Stereotypes Implied by Language Naming Conventions:
For example, <<constructor>>, <<getter>>, <<setter>>
Indicate Exceptions in an Operation’s Property String:
Relationship Guidelines
Relationships will include all UML concepts such as associations, aggregation,
composition, dependencies, inheritance, and realizations.
Model Relationships Horizontally.
Model Collaboration Between Two Elements Only When They Have a Relationship.
Model a Dependency When the Relationship Is Transitory (short-lived or temporary):
Transitory relationships—relationships that are not persistent—occur when one or
more of the items involved in a relationship is either itself transitory or a class.
Relationship Guidelines
Always Indicate the Multiplicity.
Avoid a Multiplicity of “*”: Reader can never be sure if you really mean “0.. ”
or “1.. ”
Relationship Guidelines
Do Not Model Implied Relationships.
UML does not specify, where and how the mapping between OrderItem and
Item is maintained, only that it is based on itemNumber’s.
Association Guidelines
Center Names on Associations.
Write Concise Association Names in Active Voice: For example, “places” instead of “is
placed by”
Indicate Directionality to Clarify an Association Name. Indicate the directionality on
recursive associations, where the association starts and ends on the same class.
Indicate Role Names When Multiple Associations Between Two Classes Exist.
Inheritance Guidelines
Inheritance, also called generalization, models “is a” and “is like” relationships.
Place Subclasses Below Superclasses.
A Subclass Should Inherit Everything.
Indicate Power Types on Shared Generalization: Power types, a meta modeling
concept, can be indicated using a role name associated with a generalization
relationship.
Person: superclass
Student: subclass
Student inherits from Person
Pure Inheritance
Aggregation and Composition Guidelines
Represents “is part of” relationships.
Be Interested in Both the Whole and the Part. Place the Whole to the Left of the Part.
Apply Composition to Aggregates of Physical Items.
Apply Composition When the Parts Share Their Persistence Life Cycle with the Whole.
Don’t Worry About the Diamonds. “If in doubt, leave it out.”
CheckList
Weak dependency
(e.g. call)
Parser
Association
Person
Composition
Aggregation
Tail
Workstation
Scanner
owns
1
1..*
Car
1
1
Cat
Network
between
objects
CheckList
between
classes
Generalization
Realization
Car
Car
Vehicle
<<interface>>
Vehicle
A relationship between two model elements, in which one model element (the client)
realizes the behavior that the other model element (the supplier) specifies. Several
clients can realize the behavior of a single supplier.
nested class
nestedClass
MyClass
CheckList
Navigation direction
Navigation
Person
AccessRight
Project
N-ary associations
Programmer
Language
References
The Elements of UMLTM 2.0 Style.
Lecture slides of Ilkka Haikala.