You are on page 1of 71

UNIT II OBJECT ORIENTED METHODOLOGIES 9

Rumbaugh Methodology - Booch Methodology - Jacobson Methodology - Patterns – Frameworks – Unified


Approach – Unified Modeling Language: Static and dynamic model – UML diagrams - UML class diagram – Use
case diagramUML dynamic modeling (Sequence diagram, Collaboration Diagram, State Diagram) - Activity
Diagram – Implementation diagrams (Component diagram, Deployment diagram

Rumbaugh’s Object Modelling Technique (OMT)-

Object Modeling Technique (OMT) is real world based modeling approach for software
modeling and designing. It was developed basically as a method to develop object-oriented
systems and to support object-oriented programming. It describes the static structure of the
system.
Object Modeling Technique is easy to draw and use. It is used in many applications like
telecommunication, transportation, compilers etc. It is also used in many real world problems.
OMT is one of the most popular object oriented development techniques used now-a-days. OMT
was developed by James Rambaugh.

Purpose of Object Modeling Technique:


• To test physical entity before construction of them.
• To make communication easier with the customers.
• To present information in an alternative way i.e. visualization.
• To reduce the complexity of software.
• To solve the real world problems.

Object Modeling Technique’s Models:


There are three main types of models that has been proposed by OMT:
1. Object Model:
Object Model encompasses the principles of abstraction, encapsulation, modularity,
hierarchy, typing, concurrency and persistence. Object Model basically emphasizes on
the object and class. Main concepts related with Object Model are classes and their
association with attributes. Predefined relationships in object model are aggregation and
generalization (multiple inheritance).
2. Dynamic Model:
Dynamic Model involves states, events and state diagram (transition diagram) on the model.
Main concepts related with Dynamic Model are states, transition between states and events
to trigger the transitions. Predefined relationships in object model are aggregation
(concurrency) and generalization.
3. Functional Model:
Functional Model focuses on the how data is flowing, where data is stored and different
processes. Main concepts involved in Functional Model are data, data flow, data store,
process and actors. Functional Model in OMT describes the whole processes and actions
with the help of data flow diagram (DFD).

Phases of Object Modeling Technique:


OMT has the following phases:
1. Analysis:
This the first phase of the object modeling technique. This phase involves the preparation of
precise and correct modelling of the real world problems. Analysis phase starts with setting a
goal i.e. finding the problem statement. Problem statement is further divided into above
discussed three models i.e. object, dynamic and functional model.
2. System Design:
This is the second phase of the object modeling technique and it comes after the analysis
phase. It determines all system architecture, concurrent tasks and data storage. High level
architecture of the system is designed during this phase.
3. Object Design:
Object design is the third phase of the object modelling technique and after system design is
over, this phase comes. Object design phase is concerned with classification of objects into
different classes and about attributes and necessary operations needed. Different issues
related with generalization and aggregation are checked.
4. Implementation:
This is the last phase of the object modeling technique. It is all about converting prepared
design into the software. Design phase is translated into the Implementation phase.

A method for analysis, design and implementation by an object oriented technique.


-fast and intuitive approach for identifying and modeling all objects making up a system

.-Class attributes, methods, inheritance and association canb e expressed easily

.-Dynamic behavior of objects can be described using the OMT dynamic model.

-Detailed specification of state transitions and their-descriptions within a system

The Booch Methodology


The Booch’s methodology is a widely used object- oriented method that helps to design a system using
the object paradigm. It covers the analysis and design phases of an object-oriented system.

The Booch method consists of the following diagrams:

Class diagrams
Object diagrams
State transition diagrams
Interaction diagrams
Module diagrams
Process diagrams

OMT DFD of the ATM System

Booch Methodology and Development Process


The Booch methodology prescribes a macro development process and a micro development process.
The Macro Development Process The macro process serves as a controlling framework for the micro
process and can take weeks or even months. The primary concern of the macro process is technical
management of the system. In the macro process, the traditional phases of analysis and design to a large
extent are preserved.

The Macro Development Process


The macro process serves as a controlling framework for the micro process and can take weeks or even
months. The primary concern of the macro process is technical management of the system. In the macro
process, the traditional phases of analysis and design to a large extent are preserved.

The macro development process consists of the following steps:

1. Conceptualization. During conceptualization, you establish the core requirements of the system. You
establish a set of goals and develop a prototype to prove the concept.

2. Analysis and development of the model. In this step, you use the class diagram to describe the roles
and responsibilities objects are to carry out in performing The arrows represent specialization; for
example, the class Taurus is subclass of the class Ford. The desired behaviour of the system. then, we
use the object diagram to describe the desired behaviour of the system in terms of scenarios or,
alternatively, use the interaction diagram to describe behaviour of the system in terms of scenarios.

The arrows represent specialization; for example, the class Taurus is subclass of the class Ford. We use
the object diagram to describe the desired behaviour of the system in terms of scenarios or, alternatively,
use the interaction diagram to describe behaviour of the system in terms of scenarios

.3. Design or create the system architecture. In the design phase, you use the class diagram to decide
what classes exist and how they relate to each other. Next, you use the object diagram to decide what
mechanisms are used to regulate how objects collaborate.

4. Evolution or implementation. Successively refine the system through much iteration. Produce a stream
of software implementations (or executable releases), each of which is a refinement of the prior one

.5. Maintenance. Make localized changes to the system to add new requirements and eliminate bugs.

Object Modelling using Booch Notation

The Micro Development Process


Each macro development process has its own micro development processes. The micro process is a
description of the day-to-day activities by a single or small group of software developers, which could look
blurry to an outside viewer, since the analysis and design phases are not clearly defined.

Micro Development Process

Each macro process has its own micro development process


Steps:

- Identify classes & objects

- Identify class & objects semantics

- Identify class & object relationship

- Identify class & objects interface and implementation

JACOBSON METHODOLOGIES
The Jacobson et al. methodologies cover the entire life cycle and

stress traceability between the different phases both forward and

backward.

(example Object – Oriented Business Engineering (OOBE), Object

Oriented Software Engineering (OOSE) and Objectory)

This traceability enables reuse of analysis and design work,

possibly much bigger factors in the reduction development time

then reuse of code.

At the heart of their methodologies is the use-case concept,

which evolved with Objectory (Object Factory for Software

Development).

◼ Use Cases.
◼ Object Oriented Software Engineering(OOSE)
◼ Object Oriented Business Engineering(OOBE)
Use cases
use cases are scenarios for understanding system requirements.

A use case is an interaction between users and the system. the use case model
captures the goal of the user and the responsibility of the system to its users.

In the requirements analysis, the use cases are described as of the following.

• Non formal text with no clear flow of events

• Text, easy to read but with a clear flow of events to follow

• Formal styles using pseudo code.

The use case description must contain

• How and when the use case begins and ends.

• The interaction between the use case and its actors including when the interaction
occurs and what is

exchanged.

• How and When the use case will need data stored in the system or will store data in
the system.

• Exceptions to the flow of events.

• How and when concepts of the problem domain are handled.

Every single use case should describe one main flow of events.
An exceptional or additional flow of events could be added.

The exceptional use case extends another use case to include the additional one.

The use-case model employs extend and uses relationships.


The extends relationship is used when you have one use case that is like another use
case but does a bit more. In essence extends the functionality of the original use case
(like a subclass) .

The user’s relationship reuses common behavior in different use cases.

Use cases would be viewed as a concrete or abstract.

An Abstract use case is not complete and has no actors that initiated it but it is used
by another use case. This inheritance could be used in several levels.

abstract use cases also are the ones that have uses or extends relationship.

OOSE

object oriented software engineering is also called Objectory, is a method of object-


oriented development with the specific aim to fit the development or large, real- time
systems.

The development process called use-case driven development, stresses that use cases
are involved in several phases of the development including analysis, design, validation,
and testing.

The use-case scenario begins with a user of the system initiating a sequence of
interrelated events.

The system development method on OOSE, Objectory, is a disciplined process for the
industrialized development of software, based on the use-case driven design that centers
on understanding the ways in which the system actually is used.

By organizing the analysis and design models around sequences of user interactions
and actual usage scenarios, the method produces system that are both most usable and
more robust, adapting more easy to change in usage.

The Jacobson et al.’s Objectory has been developed and applied to numerous application

areas and embodied in the CASE tools systems.


Objectory is built around several different models:

• use case model

• domain object model

• analysis object model

• Implementation model

• Test model

OOBE:
◼ Object Oriented Business Engineering
◼ OOBE is object modeling at the enterprise level.
◼ Analysis phase
◼ Design and Implementation phase
◼ Testing phase
◼ E.g. Unit testing, integration and system testing.

Pattern and Framework


Patterns support reuse of software architecture and design
– Patterns capture the static and dynamic structures and collaborations of
successful solutions to problems that arise when building applications in a
particular domain
Frameworks support reuse of detailed design and code – A framework is an
integrated set of components that collaborate to provide a reusable architecture
for a family of related pplications.
Together, design patterns and frameworks help to improve software quality
and reduce development time

Pattern:

• Design pattern solves many software architecture issues


• Design pattern is a category of patterns that deals with object oriented
software.
• Design pattern captures the static and dynamic structure and
collaboration among key participants in software designs.
• They can be used across different domains.
• They have tight scope
Design patterns provide a standard terminology and are specific to particular
scenario. For example, a singleton design pattern signifies use of single
object so all developers familiar with single design pattern will make use of
single object and they can tell each other that program is following a
singleton pattern.

Creational Patterns
These design patterns provide a way to create objects while hiding the
creation logic, rather than instantiating objects directly using new operator.
This gives program more flexibility in deciding which objects need to be
created for a given use case.
Structural Patterns
These design patterns concern class and object composition. Concept of
inheritance is used to compose interfaces and define ways to compose objects
to obtain new functionalities.
Behavioral Patterns
These design patterns are specifically concerned with communication
between objects

Creational Patterns
Factory Method
– Method in a derived class creates associates
Abstract Factory
– Factory for building related objects
Builder
– Factory for building complex objects incrementally
Prototype
– Factory for cloning new instances from a prototype
Singleton
– Factory for a singular (sole) instance

Structural Patterns
Adapter
– Translator adapts a server interface for a client
Bridge
– Abstraction for binding one of many implementations
Composite
– Structure for building recursive aggregations
Decorator
– Decorator extends an object transparently
Facade
– Facade simplifies the interface for a subsystem
Flyweight
– Many fine-grained objects shared efficiently
Proxy
– One object approximates another

Behavioral Patterns
Chain of Responsibility
– Request delegated to the responsible service provider
Command
– Request as first-class object
Interpreter
– Language interpreter for a small grammar
Iterator
– Aggregate elements are accessed sequentially
Mediator
– Mediator coordinates interactions between its associates
Memento
– Snapshot captures and restores object states privately
Observer
– Dependents update automatically when a subject changes
State
– Object whose behavior depends on its state

Framework:-
• Framework is made up of group of concrete classes which can be
directly implemented on an existing platform.
• Frameworks are written in programming languages. It is a large entity
comprising of several design patterns.
• Frameworks are concerned with specific application domain e.g.
database, web application etc.
• It has large scope.

1. Frameworks are semi-complete applications


Complete applications are developed by inheriting from, and instantiating
parameterized framework components
2. Frameworks provide domain-specific functionality
e.g., business applications, telecommunication applications,
window systems, databases, distributed applications, OS kernels
3. Frameworks exhibit inversion of control at run-time
i.e., the framework determines which objects and methods to invoke in
response to events

Component Integration in Frameworks


Framework components are loosely coupled via “callbacks”
Callbacks allow independently developed software components to be
connected together
Callbacks provide a connection-point where generic framework objects can
communicate with application objects
– The framework provides the common template methods and the application
provides the variant hook methods

Component Integration in Frameworks


Framework components are loosely coupled via “callbacks”
Callbacks allow independently developed software components to be
connected together
Callbacks provide a connection-point where generic framework objects can
communicate with application objects
– The framework provides the common template methods and the application
provides the variant hook methods

The Unified Process (UP)

🞭 A process is a set of partially ordered steps intended to reach a goal.

🞭 In Software Engineering, the goal is to efficiently and predictably


delivera software product that meets the needs of your business.

🞭 A software development process is an approach to building,


deploying and maintaining software.
🞭 The Unified Process (UP) is a process for building object-oriented
systems.

🞭 The goal of the UP is to enable the production of high quality software that
meets users needs within predictable schedules and budgets.
🞭For simple systems, it might be feasible to sequentially define the
whole problem, design the entire solution, build the software,
and then test the product.

🞭 For complex and sophisticated systems, this linear approach is not


realistic.
🞭 The UP promotes iterative development the life ofasystem stretches
over a series of cycles, each resulting in a product release.

Static and dynamic model


UML CLASS DIAGRAMS

The UML includes class diagrams to illustrate classes, interfaces, and


their associations. They are used for static object modelling.

Class diagrams are used for


• Describing the static view of the system.
• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.
Class Notation
A class represent a concept which encapsulates state (attributes) and behavior (operations). Each
attribute has a type. Each operation has a signature. The class name is the only mandatory information.

Class Name:
• The name of the class appears in the first partition.Class Attributes:
• Attributes are shown in the second partition.
• The attribute type is shown after the colon.
Class Operations (Methods):
• Operations are shown in the third partition. They are services the class provides.
• The return type of a method is shown after the colon at the end of the method
signature.
• The return type of method parameters are shown after the colon following the
parameter name.

Class Visibility
The +, - and # symbols before an attribute and operation
name in a class denote the visibility of the attribute and
operation.

• + denotes public attributes or operations


• denotes private attributes or operations
• # denotes protected attributes or operations
Relationships between classes:

1. Association
Associations are relationships between classes in a UML Class
Diagram. They are represented by a solid line between classes.
Associations are typically named using a verb or verb phrase which
reflects the real world problem domain.

Simple Association
• A structural link between two peer classes.
• There is an association between Class1 and Class2

Binary association
A binary association relates two classes. It is shown as a solid-line path connecting
the two related classes. A binary association may be labeled with a name. The name is
usually read from left to right and top to bottom; otherwise, it may have a small black solid
triangle next to it where the point of the triangle indicates the direction in which to read
the name

Example:
• A worker is responsible for work products and performs units of work
• Units of work consume work products as input and produce work products as output.

Figure 3-9. Binary associations

N-ary associations
An n-ary association relates three or more classes. It is shown as a large diamond with
solid-line pathsfrom the diamond to each class. An n-ary association may be labeled with a
name.

Example: Utilization involves workers, units of work, and


work products.

Reflexive associations
A class can also be associated with itself, using a reflexive
association.

Example: Employee can be the manager of another Employee


instance
Roles:
Each end of an association is called a role. Roles may optionally have:
• name
• multiplicity expression
• navigability

Multiplicity/Cardinality
Multiplicity defines how many instances of a class A can be associated
with one instance of a class B. It is a definition of cardinality - i.e. number of
elements - of some collection of elements by providing an inclusive interval
of non-negative integers to specify the allowable number of instances of
described element. Multiplicity interval has some lower bound and (possibly
infinite) upper bound.

Some examples of multiplicity expressions:

Multiple Association between two Classes:

Two classes may have multiple associations between them.


Qualified Association/ Association Qualifier
It is an Association attribute that is used to select an object from a larger set of
related objects, based upon the qualifier key. A qualifier is shown as a small rectangle
attached to the end of an association between the final path segment and the symbol
of the classifier that it connects to. The qualifier rectangle is part of the association, not
part of the classifier.
Example: Given a company and a social security number at most one employee could be
(SSN)

found.

Association class
It allows you to treat an association itself as a class, and model it with attributes,
operations, and other features. It is shown as a class symbol attached by a dashed line to
an association path. Its lifetime is dependent on the association.

Example: A Person may work for a single Company. We need to keep information
about the period of time that each employee works for each Company. We can do this by
adding a dateRange attribute to the association.

2. Inheritance (or Generalization)


A generalization is a taxonomic relationship between a more general classifier and
a more specific classifier. Each instance of the specific classifier is also an indirect instance
of the general classifier. Thus, the specific classifier inherits the features of the more
general classifier. The relationship is displayed as a solid line with a hollow arrowhead that
points from the child element to the parent element .

• Represents an "is-a" relationship.


• An abstract class name is shown in italics.
• SubClasses are specializations of SuperClass.
Example: Shapes

The figure below shows an inheritance example with two styles. Although the
connectors are drawn differently, they are semantically equivalent.

3. Realization
Realization is a relationship between the blueprint class and the object
containing its respective implementation level details. This object is said to realize the
blueprint class. In other words, you can understand this as the relationship between
the interface and the implementing class.
Example: Owner interface might specify methods for acquiring property and disposing
of property. The Person and Corporation classes need to implement these methods,
possibly in very different ways.
4. Dependency
An object of one class might use an object of another class in the code of a
method. If the object is not stored in any field, then this is modeled as a
dependency relationship.
• A special type of association.
• Exists between two classes if changes to the definition of one may cause changes to the
other.
• Class1 depends on Class2
Example: The Person class might have a hasRead method with a Book parameter that
returns true if the person has read the book (perhaps by checking some database).

5. Aggregation
A special type of association. The relationship is displayed as a solid line with a hollow
diamond atthe association end, which is connected to the class that represents the aggregate .

• It represents a "part of" relationship.


• Objects of both classes have separate lifetimes.
Example: Passengers are part of Car

6. Composition
A special type of aggregation where parts are destroyed when the whole is destroyed. The relationship
is displayed as a solid line with a filled diamond at the association end, which is connected to the class that
represents the whole or composite.

Example: Objects of Engine live and die with Car. Engine cannot stand
by itself.

Keywords
A UML keyword is a textual adornment to categorize a model element. For
example, the keyword to categorize that a classifier box is an interface is
«interface».
Most keywords are shown in guillemet (« ») but some are shown in curly braces,
such as {abstract}, which is a constraint containing the abstract keyword.
Keyword Meaning Example Usage
«actor» classifier is an actor in class diagram, above classifier name
«interface» classifier is an interface in class diagram, above classifier name
{abstract} abstract element; can't be instantiated in class diagrams, after classifier nameor
operation name
{ordered} a set of objects have some imposed order in class diagrams, at an association end

«actor» Keyword

The «actor» keyword was used to replace the human stick-figure actor icon with a class box
to model computer-system or robotic actors.

«interface» Keyword

{ordered} Keyword

If multiplicity element is multivalued and specified as


ordered, then the collection of values in an instantiation of
this element is sequentially ordered. By default, collections are
not ordered.
If multiplicity element is multivalued and specified as
unique, then each value in the collection of values in an
instantiation of this element must be unique. By default, each
value in collection is unique.

Example: Purchases are in specific order and each one is


unique (by default)

Constraints
Constraints may be used on most UML diagrams, but
are especially common on class diagrams. A UML constraint
is a restriction or condition on a UML element. It is
visualized in text between braces; for
example: { size >= 0 }. The text may be natural language or anything else, such as UML’s formal specificationlanguage, the Object
Constraint Language (OCL)

OR Association
For a Constraint that applies to two elements (such
as two classes or two associations), the constraint may be
shown as a dashed line between the elements labeled by
the constraint string in curly braces.
Example: Account owner is either Person or
Corporation, {xor} is predefined UML constraint.

User-Defined Compartments
In addition to common predefined compartments
class compartments such as name, attributes, and
operations, user-defined compartments can be added to
a class box.
Active Class
An active object runs on and controls its own thread
of execution. The class of an active object is an active
class. In the UML, it may be shown with double vertical
lines on the left and right sides of the class box.
Dynamic Diagrams

UML interaction diagrams


The UML includes interaction diagrams to illustrate how objects interact via messages. 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
Collaboration diagrams illustrate object interactions in a graph or network format, in which objects can be
placed anywhere on the diagram, as shown in Figure 15.1.

Type Strengths Weakness Example


Sequence • Clearly shows • Forced to
sequence or time extend to the
ordering of right when
messages adding new
• Simple notation objects;
• Consumes
horizontal
space

Collaboration • Space economical • Difficult to


– flexibility to add see sequence
new objects in two of messages
dimensions • More
• Better to illustrate complex
complex notation
branching,
iteration, and
concurrent
behavior

System sequence diagram


System Behavior
System behavior is a description of what a system does, without explaining how it does it. One part of that
description is a system sequence diagram.
A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events
that external actors generate, their order, and inter-system events. All systems are treated as a black box;
the emphasis of the diagram is events that cross the system boundary from actors to systems.
Example of an SSD
The main success scenario of the Process Sale use case. It indicates that the cashier generates makeNewSale,
enteritem, endSale, and makePayment system events.

SSDs and Use Cases


An SSD shows system events for a scenario of a use case
System Events and the System Boundary
For the purposes of software development, the system boundary is usually chosen to be the software (and
possibly hardware) system itself. In this context, a system event is an external event that directly stimulates
the software.
Eg:
The Process Sale use case is used to identify system events.
First, we must determine the actors that directly interact with the software system. The customer interacts
with the cashier, but for this simple cash-only scenario, does not directly interact with the POS system—
only the cashier does. Therefore, the customer is not a generator of system events; only the cashier is.

Naming System Events and Operations


Start the name of a system event with a verb (adds..., enter..., end..., make...)

Showing Use Case Text


It is sometimes desirable to show at least fragments of use case text for the scenario, to clarify or enhance
the two views
SSDs Within the UP
SSDs are part of the Use-Case Model—a visualization of the interactions implied in the use cases. SSDs
were not explicitly mentioned in the original UP description, although the UP creators are aware of and
understand the usefulness of such diagrams.
Phases
Inception—SSDs are not usually motivated in inception.
Elaboration—Most SSDs are created during elaboration, when it is useful to identify the details of the
system events to clarify what major operations the system must be designed to handle, write system
operation contracts, and possibly support estimation (for example, macro estimation with unadjusted
function points and COCOMO II).

Collaboration diagram
Collaboration diagrams illustrate object interactions in a graph or network format, in which objects can be
placed anywhere on the diagram
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

Messages
Each message between objects is represented with a message expression and small arrow indicating the
direction of the message. A sequence number is added to show the sequential order of messages in the
current thread of control.

Messages to "self" or "this"

A message can be sent from an object to itself

Creation of Instances
Any message can be used to create an instance, but there is 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>>

Message Number Sequencing


The order of messages is illustrated with sequence numbers,
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 outgoing message number.
Conditional Messages
A conditional message (Figure 15.12) 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.
Mutually Exclusive Conditional Paths
In this case it is necessary to modify the sequence expressions with a conditional path letter. The first letter
used is a by convention. Figure 15.13 states that either 1a or 1b could execute after msg1. Both are sequence
number 1 since either could be the first internal message.

Iteration or Looping
If the details of the iteration clause are not important to the modeler, a simple '*' can be used

Iteration Over a Collection (Multiobject)


In the UML, the term multiobject is used to denote a set of instances - collection When to use
Communication Diagrams

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
When to use Communication Diagrams
You should use interaction diagrams when you want to look at the behavior of several objects within a
single use case. Interaction diagrams are good at showing collaborations among the objects; they are not
so good at precise definition of the behavior.
State machine diagram and Modelling
An event is a significant or noteworthy occurrence.
For example: A telephone receiver is taken off the hook.
A state is the condition of an object at a moment in time—the time between events.
For example: A telephone is in the state of being "idle" after the receiver is placed on the hook and
until it is taken off the hook.
A transition is a relationship between two states that indicates that when an event occurs, the object moves
from the prior state to the subsequent state.
For example: When the event "off hook" occurs, transition the telephone from the "idle" to "active"
state.
State chart Diagrams
A UML state chart diagrams the interesting events and states of an object, and the behavior of an object in
reaction to an event. Transitions are shown as arrows, labeled with their event. States are shown in rounded
rectangles. It is common to include an initial pseudo-state, which automatically transitions to another state
when the instance is created.

Subject of a State chart Diagram


A state chart diagram may be applied to a variety of UML elements, including:
• classes (conceptual or software)
• use cases
Since an entire "system" may be represented by a class, it too may have its own state chart diagram.
State chart Diagrams in the UP?
It is not present in UP model. Rather, any element in any model (Design Model, Domain Model, and so
forth) may have a state chart to better understand or communicate its dynamic behavior in response to
events.
Use Case Statechart Diagrams
A statechart diagram that depicts the overall system events and their sequence within a use case is a kind
of use case statechart diagram.
A useful application of statechart diagrams is to describe the legal sequence of external system events that
are recognized and handled by a system in the context of a use case
Eg: During the Process Sale use case in the NextGen POS application, it is not legal to perform the
makeCreditPayment operation until the endSale event has happened.

Utility of Use Case Statechart Diagrams


During design and implementation work, it is necessary to create and implement a design that ensures no
out-of-sequence events occur, otherwise an error condition is possible.
Possible design solutions include:
• hard-coded conditional tests for out-of-order events
• use of the State pattern
• disabling widgets in active windows to disallow illegal events (a desirable approach)
• a state machine interpreter that runs a state table representing a use case statechart diagram
Use Case State chart Diagrams for the POS Application

Classes that Benefit from Statechart Diagrams


State-Independent and State-Dependent Objects
If an object always responds the same way to an event, then it is considered state-independent (or
modeless) with respect to that event. For example, if an object receives a message, and the responding
method always does the same thing—the method will typically have no conditional logic.
By contrast, state-dependent objects react differently to events depending on their state.
Common State-dependent Classes
Following is a list of common objects which are usually state-dependent, and for which it may be useful
to create a statechart diagram:
Use cases
ο Viewed as a class, the Process Sale use case reacts differently to the endSale event
dependent of if a sale is underway or not.
Stateful sessions—These are server-side software objects representing ongoing sessions or
conversations with a client; for example, EJB stateful session objects.
ο Another very common example is server-side handling of web client application and
presentation flow logic; for example, a Java technology servlet helper or "controller" that
remembers the state of the session with a Web client, and controls the transitions to new
web pages, or the modified display of the current web page, based upon the state of the
session or conversation.
ο A stateful session can usually be viewed as a software class representing a use case.
Recall that one of the GRASP Controller pattern variants is a use case controller, which is
a use case stateful session object.
Systems—This is a class representing the overall application or system.
ο The "POS system."
Windows
ο The Edit-Paste action is only valid if there is something in the "clipboard" to paste.
Controllers—These are GRASP controller objects.
ο The Register class, which handles the enterltem and endSale system events.
Transactions—These are ways a transaction (a sale, order, payment) reacts to an event is often
dependent on its current state within its overall lifecycle.
ο If a Sale received a makeLineltem message after the endSale event, it should either raise
an error condition or be ignored.
Devices
ο TV, microwave oven: they react differently to a particular event depending upon their
current state.
Role Mutators—These are classes that change their role.
ο A Person changing roles from being a civilian to a veteran.

Event Types
It is useful to categorize events as follows:
External event—Also known as a system event, is caused by something (for example, an actor)
outside our system boundary. SSDs illustrate external events. Noteworthy external events
precipitate the invocation of system
operations to respond to them.
ο When a cashier presses the "enter item" button on a POS terminal, an external event has
occurred.
Internal event—Caused by something inside our system boundary. In terms of software, an
internal event arises when a method is invoked via a message or signal that was sent from another
internal object. Messages in interaction diagrams suggest internal events.
ο When a Sale receives a makeLineltem message, an internal event has occurred.
Temporal event—Caused by the occurrence of a specific date and time or passage of time. In terms
of software, a temporal event is driven by a realtime or simulated-time clock.
ο Suppose that after an endSale operation occurs, a makePayment operation must occur
within five minutes, otherwise the current sale is automatically purged.
Transition Actions and Guards

Nested States
When to use State Diagrams
State diagrams are good at describing the behavior of an object across several use cases. State
diagrams are not very good at describing behavior that involves a number of objects collaborating. As
such, it is useful to combine state diagrams with other techniques.

Activity diagram
A UML activity diagram offers rich notation to show a sequence of activities. It may be applied to any
purpose (such as visualizing the steps of a computer algorithm), but is considered especially useful for
visualizing business workflows and processes, or use cases.
One of the UP workflows (disciplines) is Business Modeling; its purpose is to understand and
communicate "the structure and the dynamics of the organization in which a system is to be deployed"
[RUP]. A key artifact of the Business Modeling discipline is the Business Object Model (a superset of the
UP Domain Model), which essentially visualizes how a business works, using UML class, sequence, and
activity diagrams. Thus, activity diagrams are especially applicable within the Business Modeling
discipline of the UP.
An activity diagram is considered a special kind of UML state chart diagram in which the states are actions,
and event transition is automatically triggered by action completion.
When to use activity diagrams
Like most behavioral modeling techniques, activity diagrams have definite strengths and weaknesses, so
they are best used in combination with other techniques. The great strength of activity diagrams lies in the
fact that they support and encourage parallel behavior.
Component and Deployment Diagrams
A component represents a modular, deployable, and replaceable part of a system that encapsulates
implementation and exposes a set of interfaces [OMG01]. It may, for example, be source code, binary, or
executable. Examples include executables such as a browser or HTTP server, a database, a DLL, or a JAR
file (such as for an Enterprise Java Bean). UML components are usually shown within deployment
diagrams, rather than on their own. Figure 38.4 illustrates some common notation.
Deployment Diagrams
A deployment diagram shows how instances of components and processes are configured for run-time
execution on instances of processing nodes (something with memory and processing services; see Figure
38.5)

A deployment diagram shows the physical relationships among software and hardware components in
the delivered system. A deployment diagram is a good place to show how components and objects are
routed and move around a distributed system. Each node on a deployment diagram represents some kind
of computational unit-in most cases, a piece of hardware. The hardware may be a simple device or sensor,
or it could be a mainframe.
Class diagrams are used for
• Describing the static view of the system.
• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.

Class Notation
A class represent a concept which encapsulates state (attributes) and behavior (operations). Each
attribute has a type. Each operation has a signature. The class name is the only mandatory information.

Class Visibility
The +, - and # symbols before an attribute and operation name in a class denote the visibility of
theattribute and operation.

• + denotes public attributes or operations


• - denotes private attributes or operations
• # denotes protected attributes or operations

Relationships between classes


Class Diagram Example: Order System
Activity Diagrams

Activity diagram is another important diagram in UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.

Purpose of Activity Diagrams


The basic purposes of activity diagrams is similar to other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object to
another but activity diagram is used to show message flow from one activity to another.
Activity diagrams are not only used for visualizing the dynamic nature of a system, but they are also
used to construct the executable system by using forward and reverse engineering techniques

Basic components of an activity diagram


Before you begin making an activity diagram, you should first understand its
makeup. Some of the most common components of an activity diagram include:

• Action: A step in the activity wherein the users or software perform a given
task. In Lucidchart, actions are symbolized with round-edged rectangles.

• Decision node: A conditional branch in the flow that is represented by a


diamond. It includes a single input and two or more outputs.

• Control flows: Another name for the connectors that show the flow between
steps in the diagram.

• Start node: Symbolizes the beginning of the activity. The start node is
represented by a black circle.

• End node: Represents the final step in the activity. The end node is
represented by an outlined black circle.
Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be either
vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary to incorporate
swimlane in the activity diagram. But it is used to add more transparency to the activity diagram.

Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one inward
edge and several outward edges.
Join or Merge Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the inward edges as
it synchronizes the flow of input across one single output (outward) edge.
Sequence Diagrams:
A sequence diagram simply depicts interaction between objects in a sequential order .
UML Sequence Diagrams are interaction diagrams that detail how operations are carried
out. They capture the interaction between objects in the context of a collaboration.

Purpose of a Sequence Diagram


1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram


Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top
of the diagram.

Actor
A role played by an entity that interacts with the subject is called as an actor. It is out of the scope of
the system. It represents the role, which involves human users and external hardware or subjects. An
actor may or may not represent a physical entity, but it purely depicts the role of an entity. Several
distinct roles can be played by an actor or vice versa.
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation
is performed by an element, such that the top and the bottom of the rectangle is associated with the
initiation and the completion time, each respectively.

Skip Ad
Messages
The messages depict the interaction between the objects and are represented by arrows. They are in
the sequential order on the lifeline. The core of the sequence diagram is formed by messages and
lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an interaction, which
represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of interaction that
represent the flow of information from the receiver of the corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an interaction that
represents a message of the same lifeline, has been invoked.
o Recursive Message: A self message sent for recursive purpose is called a recursive message. In other
words, it can be said that the recursive message is a special case of the self message as it represents the
recursive calls.

o Create Message: It describes a communication, particularly between the lifelines of an


interaction describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of an


interaction that depicts a request to destroy the lifecycle of the target.
o Duration Message: It describes a communication particularly between the lifelines of an
interaction, which portrays the time passage of the message while modeling a system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.
GAME Application

Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system. Both the
sequence and the collaboration diagrams represent the same information but differently. Instead of
showing the flow of messages, it depicts the architecture of the object residing in the system as it is
based on object-oriented programming

Notations of a Collaboration Diagram


Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and class underlined,
separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each
actor has its respective role and name. In this, one actor initiates the use case.
3. Links: The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a solid line.
The link helps an object to connect with or navigate to another object, such that the message flows are
attached to links.
4. Messages: It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labeled arrow, which is placed near a
link. The messages are sent from the sender to the receiver, and the direction must be navigable in that
particular direction. The receiver must understand the message.

Steps for creating a Collaboration Diagram


1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for performing the
functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence diagram for
summarizing alternative situations.
Example1: Application of Finding Job

Example2: Ticket Reservation System


Statechart Diagrams
• It describes different states of a component in a system. The states are specific to a
component/object of a system.
• A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events.

• Statechart diagram describes the flow of control from one state to another state.

Statechart diagrams are also used for forward and reverse engineering of a system. However, the
main purpose is to model the reactive system.
Following are the main purposes of using Statechart diagrams −
• To model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.
Before drawing a Statechart diagram we should clarify the following points −
• Identify the important objects to be analyzed.
• Identify the states.
• Identify the events.
Basic components of a statechart diagram –

1. Initial state – We use a black filled circle represent the initial state of a System or a
class.

2. Transition – We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the change in
state.

3. State – We use a rounded rectangle to represent a state. A state represents the


conditions or circumstances of an object of a class at an instant of time.

4. Fork – We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly created
states. We use the fork notation to represent a state splitting into two or more concurrent
states.

5. Join – We use a rounded solid rectangular bar to represent a Join notation with
incoming arrows from the joining states and outgoing arrow towards the common goal
state. We use the join notation when two or more states concurrently converge into one
on the occurrence of an event or events.
6. Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to represent such cases.

7. Composite state – We use a rounded rectangle to represent a composite state also.We


represent a state with internal activities using a composite state.

8. Final state – We use a filled circle within a circle notation to represent the final state in a
state machine diagram.

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.


2. Identify the possible states in which the object can exist (boundary values corresponding
to different attributes guide us in identifying different states).
3. Label the events which trigger these transitions.

Example – state diagram for an online order –


Deployment diagram
A deployment diagram is a UML diagram type that shows the execution architecture of a system,
including nodes such as hardware or software execution environments,

Deployment diagrams are typically used to visualize the physical hardware and software of a system

The purpose of deployment diagrams can be described as −


• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software components.
• Describe the runtime processing nodes.
Deployment diagrams can be used −
• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.

Deployment Diagram Notations

Nodes

A node, represented as a cube, is a physical entity that executes one or more


components, subsystems or executables. A node could be a hardware or software
element.

Artifacts

Artifacts are concrete elements that are caused by a development process. Examples of
artifacts are libraries, archives, configuration files, executable files etc.

Communication Association

This is represented by a solid line between two nodes. It shows the path of
communication between nodes.
Devices

A device is a node that is used to represent a physical computational resource in a


system. An example of a device is an application server.

Deployment Specifications

How to Draw a Deployment Diagram


Step 1: Identify the purpose of your deployment diagram. need to identify the nodes and
devices within the system you’ll be visualizing with the diagram.

Step 2: Figure out the relationships between the nodes and devices. Once you know how
they are connected, proceed to add the communication associations to the diagram.

Step 3: Identify what other elements like components, active objects you need to add to
complete the diagram.

Step 4: Add dependencies between components and objects as required.


Deployment Diagram Examples
Deployment Diagram for Online Shopping System

Deployment Diagram for Library Management System


Deployment Diagram for Hospital Management System
Component diagrams

Component diagrams are used to model the physical aspects of a system. Component diagrams are used to
visualize the organization and relationships among components in a system. These diagrams are also used to
make executable systems.
It models the physical view of a system such as executables, files, libraries, etc. that resides within the node.
he purpose of the component diagram can be summarized as −
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
Before drawing a component diagram, the following artifacts are to be identified clearly −
• Files used in the system.
• Libraries and other artifacts relevant to the application.
• Relationships among the artifacts.
After identifying the artifacts, the following points need to be kept in mind.
• Use a meaningful name to identify the component for which the diagram is to be drawn.
• Prepare a mental layout before producing the using tools.
• Use notes for clarifying important points.

a) A component

b) A node

• 42M

• 794

• Difference between JDK, JRE, and JVM


Groups together multiple elements of the
system and is represented by file folders

Allows developers to affix a meta-analysis to the component diagram.


Provided interfaces: A straight line from the
component box with an attached circle. These symbols
represent the interfaces where a component produces
information used by the required interface of another
component.

Required interfaces: A straight line from the


component box with an attached half circle (also
represented as a dashed arrow with an open arrow).
These symbols represent the interfaces where a
component requires information in order to perform
its proper function.

You might also like