Object-Oriented Analysis
& Design with UML
HERY HERYANTO
hery@likmi.ac.id,
Overview
UML has become the de facto standard for
modeling object-oriented software. UML has been
adopted by companies throughout the world, and
today more than 50 commercial and academic
modeling tools support software and business
modeling using UML.
UML enables system developers to specify,
visualize, and document models in a manner that
supports scalability, security, and robust
execution. Because UML modeling raises the level
of abstraction throughout the analysis and design
process, it is easier to identify patterns of
Objectives
1. Teaching the basic concepts and principles of Object Orientation including Object Oriented Analysis and Design.
2. Introducing the Syntax, Semantics and Pragmatics of the Unifed Modeling Language.
3. Showing how requirements can be described informally and how they are modeled using Use Case Diagrams.
Usecase Diagram cont.
• Actor: A role played by a person, system, device, or
even an enterprise, that has a stake in the successful operation of the system.
• Use case: Identifes a key behavior of the system.
Without this behavior, the system will not fulfll the actor's requirements. Each use case expresses a goal
that the system must achieve and/or a result that it must produce.
• Association: Identifes an interaction between actors
and use cases. Each association becomes a dialog that should be explained in a use case narrative. Each
narrative in turn provides a set of scenarios that can help in the development of test cases when evaluating the
Usecase Diagram cont.
• Include relationship: Identifes a reusable use case
that is unconditionally incorporated into the execution of another use case. Responsibility for the decision about when and why to use the included use case lies with the calling use case.
• Extend redlationship: Identifes a reusable use case
that conditionally interrupts the execution of another use case to augment its functionality. The responsibility for deciding when the extending use case should be used lies with the extending use case.
• Generalization: Identifes an inheritance relationship
Modeling Actors
In UML, the term actor refers to a type of user. Users, in the classic sense, are people who use the system. But users may also be
other systems, devices, or even businesses that trade information. In Use Case diagrams, people, systems, devices, and even
Modeling Actors cont.
Any icon may be used to replace these. Picture below ofers some alternatives. A company logo might represent an
enterprise. A cartoon image might represent a device. A graphic may be used to represent a system. Often, using
Include Relationship
To use the «include» relationship, the use cases must conform to two constraints:
• The calling use case may only depend on the result from the
called use case. It can have no knowledge of the internal structure of the use case.
Extend Relationship
Use Case Narrative
Use Case Narrative for SelectPerformance
Element Description
Use Case Name SelectPerformance Use Case Number 12
Author Jane Analyst and Joe Client Last Updated April 1, 2003
Assumptions The actor has the appropriate authority to use this feature. Preconditions None.
Use Case Initiation This use case starts on demand.
Use Case Dialog The user should be given a default set of information about the shows scheduled within the next 20 days. The user
should also be provided with all the events currently scheduled at the venue.
When the user selects an event, the system should provide the set of shows scheduled for that event (the event display should remain unchanged).
When the user selects a show, the system should prompt him for a confrmation of his selection in order to avoid mistakes. The user should also be able to request a list of shows for a date range and get a new list of shows (the event display should remain unchanged).
The user may cancel out of this use case without making a selection.
Post conditions The selected show must be saved so that it can be passed on to the next step in the workfow. One selected show is the net output from this use case.
Summary
Use case diagrams, together with use case narratives and
scenarios, defne the goals of a system, or other classifer, such as an enterprise, subsystem, or component. The purpose of the use case approach is to focus the development efort on the essential objectives of the system without getting lost in, or driven by,
particular implementations or practices.
The elements of a Use Case diagram include:
– The Use Case diagram is complemented by the use case narrative and use case scenarios.
– Actors defne entities outside the system that will use the system in some way.
– Associations indicate which actors will interact with features (use cases) of the system.
– «include» and «extend» relationships describe the nature of the interactions between use cases.
– Generalization defnes inheritance relationships between use cases or between actors.
The goal of the Use Case diagram is to defne the expectations of the external actors. Those actors may be people, systems, or
Activity Diagram -
Overview
• The Activity diagram is often seen as part of the functional view of a system because it describes logical processes, or functions. Each process describes a sequence of tasks and the decisions that govern when and how they are
performed.
• There are at least three places in a model where an Activity diagram provides valuable insight:
– Modeling workfow
– Describing use cases
– Specifying operations
• An Activity diagram for one use case explains how the actor interacts with the system to accomplish the goal of the use case, including rules, information exchanged, decisions
Activity Diagram
Notation
• MODELING ACTIVITIES AND ACTIONS
Activities and actions are the two fundamental units of behavior in an Activity diagram. An activity is the highest-level unit of
behavior in an Activity diagram. An activity consists of a set of
Activity Diagram
Notation
• MODELING INITIAL AND ACTIVITY FINAL NODES
Activity Diagram
Notation
• MODELING ACTIVITY EDGES
Modeling control fow requires a means to illustrate the movement from one action to the next. The Activity diagram provides two
types of ActivityEdge to model fow from one action to the next: a
Activity Diagram
Notation
• MODELING DECISION AND MERGE POINTS
Activity Diagram
Notation
• MODELING DECISION AND MERGE POINTS
The MergeNode provides a point where a fow of control can return to an existing activity edge to take advantage of the existing fow of control from that point forward. Picture below adds a merge
Activity Diagram
Notation
• MODELING FORK AND JOIN NODES FOR CONCURRENCY
An Activity diagram may model a process in which parallel
processing is available. In fact, any logic sequence that does not require a specifc sequence may potentially be executed in
parallel. The Activity diagram uses fork and join notation to model parallel, or concurrent, processes or threads. Note the change
from UML 1.4, which called both the fork and join notation "synchronization bars.“
A ForkNode is represented as a bar with one incoming activity edge and two or more outgoing activity edges. The incoming edge is split into multiple outgoing edges that may execute in any
order, including simultaneously. Any data passed along the incoming edge is duplicated and a copy is passed along each outgoing activity edge.
Activity Diagram
Notation
• MODELING OBJECT NODES AND OBJECT FLOWS
Activity Diagram
Notation
• MODELING ACTION INPUT AND OUTPUT PINS
Actions are behaviors that work with data. Actions create, transform, and delete data, and in doing so, they may pass data produced by one action as input to another action.
This process is reminiscent of the classic input-process-output pattern of functional modeling.
Input and output may be explicitly modeled using InputPins and OutputPins. Pins are object nodes that contain values. The pin concept is borrowed from Action Semantics. Each input pin receives a single value. Input pins correspond to the parameters passed to an invocation action. As such, the model assumes that the pins are ordered just as the
parameters are ordered. Also, because of this pairing
Summary
The UML 1.4 Activity diagram is the UML version of the
classic fowchart. It may be applied to any process, large or small. Three common applications of Activity diagrams are to explain workfow (a series of Use cases), to explain a single use case, and to explain a method.
The UML 2.0 specifcation includes the concepts defned in UML 1.4 but refnes the metamodel to separate the
concepts from the state machine metamodel and to refne and clarify the concepts for an Activity diagram. UML 2.0 has also added new concepts to address limitations that no longer exist now that the Activity diagram metamodel is distinct form the State Machine diagram metamodel. The new concepts include pins, fow fnal nodes, combining decision and merge nodes, bufers and data stores,
Class Diagram -
Overview
• The Class diagram stands at the center of the
object-modeling process. It is the primary diagram for capturing all the rules that govern the defnition and use of objects. As the repository for all the rules it is also the primary source for forward engineering (turning a model into code), and the target for reverse engineering (turning code into a model).
Class Diagram – Modelling a
Class
• A class is very much like a dictionary entry. If our theater application has to manipulate information about events, then we frst need to explain what we mean by the term event using a class defnition. A UML Class defnition
describes a type of object.
• One class defnition describes many objects of the same type. Each class defnition contains at least a unique name. This name defnes the class in the repository so that any time the same name is referenced it is associated with the same repository defnition. A class can also contain
attributes and operations that describe everything
Class Diagram – Modelling
Visibility
• Visibility is applied to both attributes and operations in a class. Since this concept applies equally to attributes and
operations, I'll cover the concept here, and then demonstrate how to apply it in the descriptions of attributes and
operations that follow.
• Visibility refers to the scope of access allowed for a member of a class. Scope refers to specifc regions within the total
system. UML visibility or access levels map to similar visibility designations in most OO programming languages as follows:
– Private scope: Within a class
– Package scope: Within the same package
– Public scope: Within a system
Class Diagram – Modelling
Multiplicity
• Multiplicity, like visibility is a concept used with a number
of UML model elements, most notably with attributes and associations. Multiplicity specifes the number of values that may be associated with a model element.
• Multiplicity is modeled as a value expression. When
Class Diagram – Modelling an
Association
• Modeling an association begins by identifying the
Class Diagram – Modelling
Aggregation
• Aggregation describes a special type of association
designed to help us cope with complexity. In a typical
association the participating classes are peers. Each class remains independent of the other and neither class is
superior to the other. They simply communicate. Aggregation, on the other hand, defnes a defnite hierarchical relationship. It defnes an assembly or
Class Diagram – Generalization &
Dependency
• Generalization is the process of organizing the properties
of a set of objects that share the same purpose. You might also hear this type of relationship called inheritance. Many times the terms generalization and inheritance are used
synonymously.
• Dependency represents a client-supplier relationship in
