ooad-2-r20

lOMoARcPSD|50445077
OOAD-2 - R20
Object Oriented Analysis and Design (Jawaharlal Nehru Technological University,

Kakinada)
Scan to open on Studocu
Studocu is not sponsored or endorsed by any college or university

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)
lOMoARcPSD|50445077
Object Oriented Analysis and Design Using UML

UNIT II:
Introduction to UML: Importance of modeling, principles of modeling, object oriented modeling,
conceptual model of the UML, Architecture, and Software Development Life Cycle.
Basic Structural Modeling: Classes, Relationships, common Mechanisms, and diagrams. Case Study:
Control System: Traffic Management.
.
The UML is a graphical language for visualizing, specifying, constructing, and documenting the
artifacts of a software-intensive system. The UML gives you a standard way to write a system's
blueprints, covering conceptual things, such as business processes and system functions, as well as
concrete things, such as classes written in a specific programming language, database schemas, and
reusable software components.
Model
A model is a simplification of reality. A model provides the blueprints of a system. A model may be
structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the
dynamics of the system.
Why do we model
We build models so that we can better understand the system we are developing.
Through modeling, we achieve four aims.

1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.
We build models of complex systems because we cannot comprehend such a system in its entirety.
Principles of Modeling
There are four basic principles of model
1. The choice of what models to create has a profound influence on how a problem is attacked and
how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models.
Object Oriented Modeling
In software, there are several ways to approach a model. The two most common ways are
1. Algorithmic perspective
2. Object-oriented perspective
Algorithmic Perspective
The traditional view of software development takes an algorithmic perspective.

In this approach, the main building block of all software is the procedure or function.
This view leads developers to focus on issues of control and the decomposition of larger algorithms into
smaller ones.
Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

lOMoARcPSD|50445077

As requirements change and the system grows, systems built with an algorithmic focus turn out to be
very hard to maintain.
Object-oriented perspective
The contemporary view of software development takes an object-oriented perspective.
In this approach, the main building block of all software systems is the object or class.
A class is a description of a set of common objects.
Every object has identity, state, and behavior.
Object-oriented development provides the conceptual foundation for assembling systems out of
components using technology such as Java Beans or COM+.
An Overview of UML
 The Unified Modeling Language is a standard language for writing software blueprints. The
UML may be used to visualize, specify, construct, and document the artifacts of a software-
intensive system.
 The UML is appropriate for modeling systems ranging from enterprise information systems to
distributed Web-based applications and even to hard real time embedded systems. It is a very
expressive language, addressing all the views needed to develop and then deploy such systems.
The UML is a language for

 Visualizing
 Specifying
 Constructing
 Documenting
 Visualizing The UML is more than just a bunch of graphical symbols. Rather, behind each symbol
in the UML notation is a well-defined semantics. In this manner, one developer can write a model in
the UML, and another developer, or even another tool, can interpret that model unambiguously
 Specifying means building models that are precise, unambiguous, and complete.
 Constructing the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages
 Documenting a healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include
o Requirements
o Architecture
o Design
o Source code
o Project plans
o Tests
o Prototypes
o Releases

lOMoARcPSD|50445077
UML Building Blocks

To understand the UML, you need to form a conceptual model of the language, and this requires
learning three major elements:
1. Things
2. Relationships
3. Diagrams
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things

lOMoARcPSD|50445077

Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. In all, there are seven kinds of structural
things.
1. Classes
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes
Class is a description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle,
usually including its name, attributes, and operations.
Interface
Interface is a collection of operations that specify a service of a class or component.
An interface therefore describes the externally visible behavior of that element.
An interface might represent the complete behavior of a class or component or only a part of that
behavior.
An interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is
typically attached to the class or component that realizes the interface
Collaboration defines an interaction and is a society of roles and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. Therefore,
collaborations have structural, as well as behavioral, dimensions. A given class might participate in
several collaborations.
Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name
Usecase
 Use case is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor
 Use case is used to structure the behavioral things in a model.
 A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with
solid lines, usually including only its name

lOMoARcPSD|50445077

Active class is just like a class except that its objects represent elements whose behavior is concurrent
with other elements. Graphically, an active class is rendered just like a class, but with heavy lines,
usually including its name, attributes, and operations
Component is a physical and replaceable part of a system that conforms to and provides the realization
of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs
Node is a physical element that exists at run time and represents a computational resource, generally
having at least some memory and, often, processing capability. Graphically, a node is rendered as a
cube, usually including only its name
Behavioral Things are the dynamic parts of UML models. These are the verbs of a model, representing
behavior over time and space. In all, there are two primary kinds of behavioral things
Interaction
state machine
Interaction
Interaction is a behavior that comprises a set of messages exchanged among a set of objects within a
particular context to accomplish a specific purpose
An interaction involves a number of other elements, including messages, action sequences and links
Graphically a message is rendered as a directed line, almost always including the name of its operation
State Machine
State machine is a behavior that specifies the sequences of states an object or an interaction goes
through during its lifetime in response to events, together with its responses to those events
State machine involves a number of other elements, including states, transitions, events and activities
Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates
Grouping Things:-
1. are the organizational parts of UML models. These are the boxes into which a model can be
decomposed

lOMoARcPSD|50445077

2. There is one primary kind of grouping thing, namely, packages.
Package:-
 A package is a general-purpose mechanism for organizing elements into groups. Structural things,
behavioral things, and even other grouping things may be placed in a package
 Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents
Annotational things are the explanatory parts of UML models. These are the comments you may apply
to describe about any element in a model.
A note is simply a symbol for rendering constraints and comments attached to an element or a
collection of elements.
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or
graphical comment
Relationships in the UML: There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:-
Dependency is a semantic relationship between two things in which a change to one thing may affect
the semantics of the other thing
Graphically a dependency is rendered as a dashed line, possibly directed, and occasionally including a
label
Association is a structural relationship that describes a set of links, a link being a connection among
objects.
Graphically an association is rendered as a solid line, possibly directed, occasionally including a label,
and often containing other adornments, such as multiplicity and role names
Generalization: is a relationship between General and more specific things. Graphically, a

generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent

lOMoARcPSD|50445077
Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract
that another classifier guarantees to carry out. Graphically a realization relationship is rendered as a
cross between a generalization and a dependency relationship
Diagrams in the UML
 Diagram is the graphical presentation of a set of elements, most often rendered as a connected
graph of vertices (things) and arcs (relationships).
 In theory, a diagram may contain any combination of things and relationships.
 For this reason, the UML includes nine such diagrams:
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Statechart diagram
 Activity diagram
 Component diagram
 Deployment diagram
Class diagram
A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
Class diagrams that include active classes address the static process view of a system.
Object diagram
 Object diagrams represent static snapshots of instances of the things found in class diagrams
 These diagrams address the static design view or static process view of a system
 An object diagram shows a set of objects and their relationships
Use case diagram

 A use case diagram shows a set of use cases and actors and their relationships
 Use case diagrams address the static use case view of a system.
 These diagrams are especially important in organizing and modeling the behaviors of a system.
Interaction Diagrams
Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams
Interaction diagrams address the dynamic view of a system
A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the
objects that send and receive messages
Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and
transform it into the other
Statechart diagram
 A statechart diagram shows a state machine, consisting of states, transitions, events, and
activities
 Statechart diagrams address the dynamic view of a system
 They are especially important in modeling the behavior of an interface, class, or collaboration
and emphasize the event-ordered behavior of an object
Activity diagram
An activity diagram is a special kind of a statechart diagram that shows the flow from activity to
activity within a system
Activity diagrams address the dynamic view of a system

lOMoARcPSD|50445077

They are especially important in modeling the function of a system and emphasize the flow of control
among objects
Component diagram
 A component diagram shows the organizations and dependencies among a set of components.
 Component diagrams address the static implementation view of a system
 They are related to class diagrams in that a component typically maps to one or more classes,
interfaces, or collaborations
Deployment diagram
 A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them
 Deployment diagrams address the static deployment view of an architecture
Rules of the UML

The UML has semantic rules for
1. Names :What you can call things, relationships, and diagrams
2. Scope :The context that gives specific meaning to a name
3. Visibility :How those names can be seen and used by others
4. Integrity :How things properly and consistently relate to one another
5. Execution:What it means to run or simulate a dynamic model
Models built during the development of a software-intensive system tend to evolve and may be viewed
by many stakeholders in different ways and at different times. For this reason, it is common for the
development team to not only build models that are well-formed, but also to build models that are
1. Elided Certain elements are hidden to simplify the view

2. Incomplete Certain elements may be missing
3. Inconsistent The integrity of the model is not guaranteed
Common Mechanisms in the UML
UML is made simpler by the presence of four common mechanisms that apply consistently throughout
the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms
Specification that provides a textual statement of the syntax and semantics of that building block. The
UML's specifications provide a semantic backplane that contains all the parts of all the models of a
system, each part related to one another in a consistent fashion
Adornments Most elements in the UML have a unique and direct graphical notation that provides a
visual representation of the most important aspects of the element. A class's specification may include
other details, such as whether it is abstract or the visibility of its attributes and operations. Many of
these details can be rendered as graphical or textual adornments to the class's basic rectangular notation.

lOMoARcPSD|50445077
Extensibility Mechanisms
The UML's extensibility mechanisms include
1. Stereotypes
2. Tagged values
3. Constraints
 Stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem
 A tagged value extends the properties of a UML building block, allowing you to create new
information in that element's specification
 A constraint extends the semantics of a UML building block, allowing you to add new rules or
modify existing ones
Architecture
A system's architecture is perhaps the most important artifact that can be used to manage these different
viewpoints and so control the iterative and incremental development of a system throughout its life
cycle.
Architecture is the set of significant decisions about
The organization of a software system

The selection of the structural elements and their interfaces by which the system is composed
Their behavior, as specified in the collaborations among those elements
The composition of these structural and behavioral elements into progressively larger subsystems
The architectural style that guides this organization: the static and dynamic elements and their
interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage,
functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints
and trade-offs, and aesthetic concerns.
Vocabulary System Assembly

Functionality Configuration Mgmt
Design View Implementation
View
Use
case
view Behavior
Process View Deployment
view
Performance System topology

Scalability distribution delivery
Throughput installation
Modeling a System's Architecture
Use case view

The use case view of a system encompasses the use cases that describe the behavior of the system as
seen by its end users, analysts, and testers.
With the UML, the static aspects of this view are captured in use case diagrams

lOMoARcPSD|50445077

The dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity
diagrams.
Design View
 The design view of a system encompasses the classes, interfaces, and collaborations that form the
vocabulary of the problem and its solution.
 This view primarily supports the functional requirements of the system, meaning the services that
the system should provide to its end users.
 Static aspects of are captured with Class and object diagrams
 Dynamic aspects are captured with Interaction diagrams,activity diagrams and Statechart diagrams
Process View
 The process view of a system encompasses the threads and processes that form the system's
concurrency and synchronization mechanisms.
 This view primarily addresses the performance, scalability, and throughput of the system
 Static aspects of are captured with Class and object diagrams
 Dynamic aspects are captured with Interaction diagrams,activity diagrams and Statechart diagrams
Implementation View
The implementation view of a system encompasses the components and files that are used to assemble
and release the physical system.
This view primarily addresses the configuration management of the system's releases, made up of
somewhat independent components and files that can be assembled in various ways to produce a
running system.
Static aspects of are captured with Component diagrams
Dynamic aspects are captured with Interaction diagrams, activity diagrams and Statechart diagrams
Deployment Diagram
The deployment view of a system encompasses the nodes that form the system's hardware topology on
which the system executes.
This view primarily addresses the distribution, delivery, and installation of the parts that make up the
physical system.
Static aspects of are captured with deployment diagrams
Dynamic aspects are captured with Interaction diagrams,activity diagrams and Statechart diagrams
Software Development Life Cycle:

The UML is largely process-independent, meaning that it is not tied to any particular software
development life cycle.
However, to get the most benefit from the UML, you should consider a process that is
• Use case driven
• Architecture-centric
• Iterative and incremental
Use case driven : means that use cases are used as a primary artifact for establishing the desired
behavior of the system, for verifying and validating the system's architecture, testing,
communicating among the stakeholders of the project.
Architecture-centric means that a system's architecture is used as a primary artifact for
conceptualizing, constructing, managing, and evolving the system under development.
An iterative process is one that involves managing a stream of executable releases. An iterative and
incremental process is risk-driven, meaning that each new release is focused on attacking and reducing
the most significant risks to the success of the project.
• This use case driven, architecture-centric, and iterative/incremental process
can be broken into four phases. A phase is the span of time between two major milestones of the
process.

lOMoARcPSD|50445077
There are four phases in the software development life cycle:

inception, elaboration, construction, and transition
Inception is the first phase of the process, when the seed idea for the development is brought up to the
point of being at least internally sufficiently well-founded to warrant entering into the elaboration phase.
Elaboration is the second phase of the process, when the product vision and its architecture are
defined. In this phase, the system’s requirements are prioritized and baselined.
Construction is the third phase of the process, when the software is brought from an executable
architectural baseline to being ready to be transitioned to the user community.
Transition is the fourth phase of the process, when the software is turned into the hands of the user
community. Rarely does the software development process end here, for even during this phase, the
system is continuously improved, bugs are eradicated and features that didn’t make an earlier release
are added.
Basic Structural Modeling:

Contents:
1. Classes 2.Relationships 3.Common Mechanisms 4.Diagrams
Class
 A class is a description of a set of objects that share the same attributes, operations, relationships,
and semantics.
 A class implements one or more interfaces.
 The UML provides a graphical representation of class

lOMoARcPSD|50445077
Terms and Concepts
Names
Every class must have a name that distinguishes it from other classes.
A name is a textual string that name alone is known as a simple name;
a path name is the class name prefixed by the name of the package in which that class lives.
Simple Name Path Name
Attributes
 An attribute is a named property of a class that describes a range of values that instances of the
property may hold.
 A class may have any number of attributes or no attributes at all.
 An attribute represents some property of thing you are modeling that is shared by all objects of that
class
 You can further specify an attribute by stating its class and possibly a default initial value
Attributes and Their Class

Operations
 An operation is the implementation of a service that can be requested from any object of the class to
affect behavior.
 A class may have any number of operations or no operations at all
 Graphically, operations are listed in a compartment just below the class attributes
 You can specify an operation by stating its signature, covering the name, type, and default value of
all parameters and a return type

lOMoARcPSD|50445077

Organizing Attributes and Operations
To better organize long lists of attributes and operations, you can also prefix each group with a
descriptive category by using stereotypes
Responsibilities
 A Responsibility is a contract or an obligation of a class
 When you model classes, a good starting point is to specify the responsibilities of the things in your
vocabulary.
 A class may have any number of responsibilities, although, in practice, every well-structured class
has at least one responsibility and at most just a handful.
 Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class icon
Common Modeling Techniques
Modeling the Vocabulary of a System

 You'll use classes most commonly to model abstractions that are drawn from the problem you are
trying to solve or from the technology you are using to implement a solution to that problem.
 They represent the things that are important to users and to implementers
 To model the vocabulary of a system
o Identify those things that users or implementers use to describe the problem or solution.
o Use CRC cards and use case-based analysis to help find these abstractions.
o For each abstraction, identify a set of responsibilities.
o Provide the attributes and operations that are needed to carry out these responsibilities for
each class.
Modeling the Distribution of Responsibilities in a System
 Once you start modeling more than just a handful of classes, you will want to be sure that your
abstractions provide a balanced set of responsibilities.
 To model the distribution of responsibilities in a system
o Identify a set of classes that work together closely to carry out some behavior.
o Identify a set of responsibilities for each of these classes.
o Look at this set of classes as a whole, split classes that have too many responsibilities into

lOMoARcPSD|50445077

smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and
reallocate responsibilities so that each abstraction reasonably stands on its own.
o Consider the ways in which those classes collaborate with one another, and redistribute their
responsibilities accordingly so that no class within a collaboration does too much or too little.
Modeling Nonsoftware Things
 Sometimes, the things you model may never have an analog in software
 Your application might not have any software that represents them
 To model non software things
o Model the thing you are abstracting as a class.
o If you want to distinguish these things from the UML's defined building blocks, create a new
building block by using stereotypes to specify these new semantics and to give a distinctive
visual cue.
o If the thing you are modeling is some kind of hardware that itself contains software, consider
modeling it as a kind of node, as well, so that you can further expand on its structure.
Modeling Primitive Types
At the other extreme, the things you model may be drawn directly from the programming language you
are using to implement a solution.
Typically, these abstractions involve primitive types, such as integers, characters, strings, and even
enumeration types
To model primitive types
Model the thing you are abstracting as a type or an enumeration, which is rendered using class notation
with the appropriate stereotype.
If you need to specify the range of values associated with this type, use constraints.
Relationships
In the UML, the ways that things can connect to one another, either logically or physically, are modeled
as relationships.
Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the
kinds of relationships
In object-oriented modeling, there are three kinds of relationships that are most important:
Dependencies
Generalizations
Associations
Dependency
A dependency is a using relationship that states that a change in specification of one thing may affect
another thing that uses it but not necessarily the reverse.
Graphically dependency is rendered as a dashed directed line, directed to the thing being depended on.
Most often, you will use dependencies in the context of classes to show that one class uses another class
as an argument in the signature of an operation

lOMoARcPSD|50445077

Generalization
o A generalization is a relationship between a general thing (called the super class or parent)and a
more specific kind of that thing (called the subclass or child).
o generalization means that the child is substitutable for the parent. A child inherits the properties of
its parents, especially their attributes and operations
o An operation of a child that has the same signature as an operation in a parent overrides the
operation of the parent; this is known as polymorphism.
o Graphically generalization is rendered as a solid directed line with a large open arrowhead, pointing
to the parent
Association
o An association is a structural relationship that specifies that objects of one thing are connected to
objects of another
o An association that connects exactly two classes is called a binary association
o An associations that connect more than two classes; these are called n-ary associations.
o Graphically, an association is rendered as a solid line connecting the same or different classes.
o Beyond this basic form, there are four adornments that apply to associations
Name
o An association can have a name, and you use that name to describe the nature of the relationship
Role
o When a class participates in an association, it has a specific role that it plays in that relationship;
o The same class can play the same or different roles in other associations.
o An instance of an association is called a link

lOMoARcPSD|50445077

Multiplicity
o In many modeling situations, it's important for you to state how many objects may be connected
across an instance of an association
o This "how many" is called the multiplicity of an association's role
o You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*).
You can even state an exact number (for example, 3).
Aggregation
o Sometimes, you will want to model a "whole/part" relationship, in which one class represents a
larger thing (the "whole"), which consists of smaller things (the "parts").
o This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that
an object of the whole has objects of the part
o Aggregation is really just a special kind of association and is specified by adorning a plain
association with an open diamond at the whole end
Another type of aggregation relationship, composition, is one in which the part elements cannot exist
without the aggregate. For instance, the rooms in a house cannot continue to exist if the house is
destroyed. For a composition relationship, a filled diamond is shown on the line near the aggregate
Modeling Simple Dependencies

The most common kind of dependency relationship is the connection between a class that only uses
another class as a parameter to an operation.
To model this using relationship
Create a dependency pointing from the class with the operation to the class used as a parameter in the
operation.
This figure shows a dependency from CourseSchedule to Course, because Course is used in both the
add and remove operations of CourseSchedule.
The dependency from Iterator shows that the Iterator uses the CourseSchedule; the CourseSchedule
knows nothing about the Iterator. The dependency is marked with a stereotype, which specifies that this
is not a plain dependency, but, rather, it represents a friend, as in C++.

lOMoARcPSD|50445077
Modeling Single Inheritance

To model inheritance relationships
 Given a set of classes, look for responsibilities, attributes, and operations that are common to
two or more classes.
 Elevate these common responsibilities, attributes, and operations to a more general class. If
necessary, create a new class to which you can assign these
 Specify that the more-specific classes inherit from the more-general class by placing a
generalization relationship that is drawn from each specialized class to its more-general parent.
Modeling Structural Relationships
 Dependency and generalization relationships are one-sided.

 Associations are, by default, bidirectional; you can limit their direction
 Given an association between two classes, both rely on the other in some way, and you can navigate
in either direction
 An association specifies a structural path across which objects of the classes interact.
To model structural relationships
 For each pair of classes, if you need to navigate from objects of one to objects of another, specify an
association between the two. This is a data-driven view of associations.
 For each pair of classes, if objects of one class need to interact with objects of the other class other
than as parameters to an operation, specify an association between the two. This is more of a
behavior-driven view of associations.
 For each of these associations, specify a multiplicity (especially when the multiplicity is not *,
which is the default), as well as role names (especially if it helps to explain the model).

lOMoARcPSD|50445077
 If one of the classes in an association is structurally or organizationally a whole compared with the
classes at the other end that look like parts, mark this as an aggregation by adorning the association
at the end near the whole
Common Mechanisms
Note
A note is a graphical symbol for rendering constraints or comments attached to an element or a
collection of elements
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or
graphical comment.
A note may contain any combination of text or graphics
Stereotypes
A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of
building blocks similar to existing ones but specific to your problem.
Graphically, a stereotype is rendered as a name enclosed by guillemets and placed above the name of
another element

lOMoARcPSD|50445077
Tagged Values
 Every thing in the UML has its own set of properties: classes have names, attributes, and
operations; associations have names and two or more ends (each with its own properties); and so
on.
 With stereotypes, you can add new things to the UML; with tagged values, you can add new
properties.
 A tagged value is not the same as a class attribute. Rather, you can think of a tagged value as
metadata because its value applies to the element itself, not its instances.
 A tagged value is an extension of the properties of a UML element, allowing you to create new
information in that element's specification.
 Graphically, a tagged value is rendered as a string enclosed by brackets and placed below the
name of another element..
 That string includes a name (the tag), a separator (the symbol =), and a value (of the tag).
Constraints
A constraint specifies conditions that must be held true for the model to be well-formed.
Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated
element or connected to that element or elements by dependency relationships.
Modeling Comments
To model a comment,
Put your comment as text in a note and place it adjacent to the element to which it refers
Remember that you can hide or make visible the elements of your model as you see fit.
If your comment is lengthy or involves something richer than plain text, consider putting your comment
in an external document and linking or embedding that document in a note attached to your model

lOMoARcPSD|50445077
Modeling New Building Blocks

 The UML's building blocks—classes, interfaces, collaborations, components, nodes,
associations, and so on—are generic enough to address most of the things you'll want to model.
 However, if you want to extend your modeling vocabulary or give distinctive visual cues to
certain kinds of abstractions that often appear in your domain, you need to use stereotypes
 To model new building blocks,
o Make sure there's not already a way to express what you want by using basic UML
o If you're convinced there's no other way to express these semantics, identify the primitive
thing in the UML that's most like what you want to model and define a new stereotype
for that thing
o Specify the common properties and semantics that go beyond the basic element being
stereotyped by defining a set of tagged values and constraints for the stereotype.
o If you want these stereotype elements to have a distinctive visual cue, define a new icon
for the stereotype
Modeling New Properties

To model new properties,
First, make sure there's not already a way to express what you want by using basic UML
If you're convinced there's no other way to express these semantics, add this new property to an
individual element or a stereotype.

lOMoARcPSD|50445077
Modeling New Semantics

When you create a model using the UML, you work within the rules the UML lays down
However, if you find yourself needing to express new semantics about which the UML is silent or that
you need to modify the UML's rules, then you need to write a constraint.
To model new semantics,
First, make sure there's not already a way to express what you want by using basic UML
If you're convinced there's no other way to express these semantics, write your new semantics as text in
a constraint and place it adjacent to the element to which it refers
A diagram is the graphical presentation of a set of elements, most often rendered as a

connected graph of vertices (things) and arcs (relationships).
The static parts of a system using one of the following diagrams:
1. Class diagram
2. Component diagram
3. Object diagram
4. Deployment diagram
You'll often use five additional diagrams to view the dynamic parts of a system:
1. Use case diagram
2. Sequence diagram
3. Collaboration diagram
4. State diagram
5. Activity diagram
.2 Control System: Traffic Management

Imagine using a manual system to control air traffic around a major metropolitan center or to
manage the life-support system of a manned spacecraft or the accounting activities of a multinational
bank. Successfully automating such systems not only addresses the very real problems at hand but also
leads to a number of tangible and intangible benefits, such as lower operational costs, greater safety, and
increased functionality. Of course, the operative word here is successfully. Building complex systems is
plain hard work and requires the application of the best engineering practices we know, along with the
creative insight of a few great designers.
This chapter tackles the development of such a problem.

lOMoARcPSD|50445077
4.2.1 Inception
Train traffic management, including computerized train routing and monitoring of all elements
of the train system. Lower operating costs and more efficient use of resources are the goals, with
improved safety as an integral by-product.
In this section, we begin our analysis of the fictitious Train Traffic Management System
(TTMS) by specifying its requirements and the system use cases that further describe the required
functionality.
Requirements for the Train Traffic Management System
This is a very large and highly complex system that in reality would not be specified by simple
requirements. However, for this chapter, the requirements that follow will suffice for the purposes of
our analysis and design effort. Quite clearly, we would need to focus our efforts on the most critical
elements and prototype candidate solutions within the operational context of the system under
development.
The Train Traffic Management System has two primary functions: train routing and train
systems monitoring. Related functions include traffic planning, failure prediction, train location
tracking, traffic monitoring, collision avoidance, and maintenance logging. From these functions, we
define eight use cases, as shown in the following list.
■ Route Train: Establish a train plan that defines the travel route for a particular train.
■ Plan Traffic: Establish a traffic plan that provides guidance in the development of train plans for a
time frame and geographic region.
■ Monitor Train Systems: Monitor the onboard train systems for proper functioning.
■ Predict Failure: Perform an analysis of train systems’ condition to predict probabilities of failure
relative to the train plan.
■ Track Train Location: Monitor the location of trains using TTMS resources and the Navstar Global
Positioning System (GPS).
■ Monitor Traffic: Monitor all train traffic within a geographic region.
■ Avoid Collision: Provide the means, both automatic and manual, to avoid train collisions.
■ Log Maintenance: Provide the means to log maintenance performed on trains.
These use cases establish the basic functional requirements for the Train Traffic Management
System, that is, they tell us what the system must do for its users. In addition, we have nonfunctional
requirements and constraints that impact the requirements specified by our use cases, as listed here.
Nonfunctional requirements:
■ Safely transport passengers and cargo
■ Support train speeds up to 250 miles per hour
■ Interoperate with the traffic management systems of operators at the TTMS boundary
■ Ensure maximum reuse of and compatibility with existing equipment
■ Provide a system availability level of 99.99%
■ Provide complete functional redundancy of TTMS capabilities
■ Provide accuracy of train position within 10.0 yards
■ Provide accuracy of train speed within 1.5 miles per hour
■ Respond to operator inputs within 1.0 seconds
■ Have a designed-in capability to maintain and evolve the TTMS
Constraints:
■ Meet national standards, both government and industry

lOMoARcPSD|50445077

■ Maximize use of commercial-off-the-shelf (COTS) hardware and software
We find that we have three types of people who interact with the system: Dispatcher,
TrainEngineer, and Maintainer. In addition, the Train Traffic Management System interfaces with one
external system, Navstar GPS. These actors play the following roles within the TTMS.
■ Dispatcher establishes train routes and tracks the progress of individual trains.
■ TrainEngineer monitors the condition of and operates the train.
■ Maintainer monitors the condition of and maintains train systems.
■ Navstar GPS provides geolocation services used to track trains.
Determining System Use Cases
Figure 9–1 The Use Case Diagram for the Train Traffic Management System
Figure 9–1 shows the use case diagram for the Train Traffic Management System. In it, we see
the system functionality used by each of the actors. We also see that we have «include» and «extend»
relationships used to organize relationships between several of the use cases. The functionality of the
use case Monitor Train Systems is extended by the use case Predict Failure. During the course of
monitoring systems, a failure prediction analysis (condition: {request Predict Failure}) can be requested
for a particular system that is operating abnormally or may have been flagged with a yellow condition
indicating a problem requiring investigation. This occurs at the Potential Failure extension point.

lOMoARcPSD|50445077
We may specify the details of the functionality provided by each of these use cases in textual
documents called use case specifications. We have chosen to focus on the two primary use cases, Route
Train and Monitor Train Systems, in the following use case specifications. The format of the use case
specification is a general one that provides setup information along with the primary scenario and one
or more alternate scenarios.
This view is used when we are concerned with what the system does, not how the system does it.
Use case name: Route Train
Use case purpose: The purpose of this use case is to establish a train plan that acts as a repository for
all the pertinent information associated with the route of one particular train and the actions that take
place along the way.
Point of contact: Katarina Bach
Date modified: 9/5/06
Preconditions: A traffic plan exists for the time frame and geographic region (territory) relevant to the
train plan being developed.
Postconditions: A train plan has been developed for a particular train to detail its travel route.
Limitations: Each train plan will have a unique ID within the system. Resources may not be committed
for utilization by more than one train plan for a particular time frame.
Assumptions: A train plan is accessible by dispatchers for inquiry and modification and accessible by
train engineers for inquiry.
Primary scenario:
A. The Train Traffic Management System (TTMS) presents the dispatcher with a list of options.
B. The dispatcher chooses to develop a new train plan.
C. The TTMS presents the template for a train plan to the dispatcher.
D. The dispatcher completes the train plan template, providing information about locomotive ID(s),
train engineer(s), and waypoints with times.
E. The dispatcher submits the completed train plan to the TTMS.
F. The TTMS assigns a unique ID to the train plan and stores it. The TTMS makes the train plan
accessible for inquiry and modification.
G. This use case ends.
Alternate scenarios:
Condition triggering an alternate scenario:
Condition 1: Develop a new train plan, based on an existing one.
B1. The dispatcher chooses to develop a new train plan, based on an existing one.
B2. The dispatcher provides search criteria for existing train plans.
B3. The TTMS provides the search results to the dispatcher.
B4. The dispatcher chooses an existing train plan.
B5. The dispatcher completes the train plan.
B6. The primary scenario is resumed at step E.
Condition triggering an alternate scenario:
Condition 2: Modify an existing train plan.
B1. The dispatcher chooses to modify an existing train plan.
B2. The dispatcher provides search criteria for existing train plans.
B3. The TTMS provides the search results to the dispatcher.
B4. The dispatcher chooses an existing train plan.
B5. The dispatcher modifies the train plan.
B6. The dispatcher submits the modified train plan to the TTMS.
B7. The TTMS stores the modified train plan and makes it accessible for inquiry and modification.
B8. This use case ends.
4.2.2 Elaboration
Our attention now turns to developing the overall architecture framework for the Train Traffic
Management System. We begin by analyzing the required system functionality that leads us into the

lOMoARcPSD|50445077

definition of the TTMS architecture. From there, we begin our transition from systems engineering to
the disciplines of hardware and software engineering. We conclude this section by describing the key
abstractions and mechanisms of the TTMS.
Analyzing System Functionality

Now that the requirements for the Train Traffic Management System have been specified, our
focus turns to how the system’s aggregate parts provide this required functionality. This perspective is
often referred to as a white-box view since the internal functioning of the system is seen externally. We
use activity diagrams to analyze the various use case scenarios to develop this further level of detail.
Let’s begin by looking at Figure 9–2, which analyzes the primary scenario of the Route Train
use case. This activity diagram is relatively straightforward and follows the course of the use case
scenario. Here we see the interaction of the Dispatcher actor and the RailOperationsControlSystem,
which we’ve designated as the primary command and control center for the TTMS, as the Dispatcher
creates a new TrainPlan object.
Figure 9–2 The Route Train Primary Scenario
Defining the TTMS Architecture

lOMoARcPSD|50445077

A much more thorough analysis of the functionality required by all the use case scenarios,
including the impact of the nonfunctional requirements and constraints, leads us to a block diagram for
the Train Traffic Management System’s major elements, as shown in Figure 9–5 [2]. The locomotive
analysis and reporting system includes several digital and analog sensors for monitoring locomotive
conditions, including oil temperature, oil pressure, fuel quantity, alternator volts and amperes, throttle
setting, engine RPM, water temperature, and drawbar force.
The energy management system advises the train engineer in real time as to the most efficient
throttle and brake settings. The onboard display system provides the human/machine interface for the
train engineer.
The data management unit serves as the communications gateway between all onboard systems
and the rest of the network, to which all trains, dispatchers, and other users are connected.
Train location tracking is achieved via two devices on the network: location transponders and
the Navstar GPS.
A wayside interface unit is placed wherever there is some controllable device (such as a switch)
or a sensor (such as an infrared sensor for detecting overheated wheel bearings).
Every ground terminal controller relays its information to a common network control system.
The network control system is ultimately connected to one or more dispatch centers, which
comprise the rail operations control system and other users.
From Systems Engineering to Hardware and Software Engineering
After completing our systems engineering analysis of the TTMS functionality (through its
architectural levels), we must allocate the system requirements to hardware, software, and even
operational elements.
Figure 9–7 illustrates the target deployment hardware for the Train Traffic Management System,
using the notation for deployment diagrams. This hardware architecture parallels the block diagram of
the system shown earlier in Figure 9–5.
Figure 9–7 The Deployment Diagram for the Train Traffic Management System

lOMoARcPSD|50445077
Key Abstractions and Mechanisms

A study of the requirements for the Train Traffic Management System suggests that we really
have four different subproblems to solve:
1. Networking
2. Database
3. Human/machine interface
4. Real-time analog and digital device control
If we do a brief domain analysis across these four subproblem areas, we find that there are three
common high-level key abstractions:
1. Trains: including locomotives and cars
2. Tracks: encompassing profile, grade, and wayside devices
3. Plans: including schedules, orders, clearances, authority, and crew Assignments Continuing, we may
devise a key mechanism for each of the four nearly independent subproblems:
1. Message passing
2. Train schedule planning
3. Displaying information
4. Sensor data acquisition
These four mechanisms form the soul of our system.
4.2.3 Construction
In this section, we start by examining the semantics of each of this system’s four key
mechanisms: message passing, train schedule planning, displaying information, and sensor data
acquisition.
Message Passing
By message, we do not mean to imply method invocation, as in an object-oriented programming
language; rather, we are referring to a concept in the vocabulary of the problem domain, at a much
higher level of abstraction. For example, typical messages in the Train Traffic Management System
include signals to activate wayside devices, indications of trains passing specific locations, and orders
from dispatchers to train engineers. In general, these kinds of messages are passed at two different
levels within the TTMS:
1. Between computers and devices

2. Among computers
The class diagram in Figure 9–8 captures our design decisions regarding some of the most
important messages in the Train Traffic Management System. Note that all messages are ultimately
instances of a generalized abstract class named Message, which encompasses the behavior common to
all messages. Three lower-level classes represent the major categories of messages, namely, Train-
StatusMessage, TrainPlanMessage, and WaysideDeviceMessage.
Each of these classes is further specialized. Indeed, our final design might include dozens of
such specialized classes, at which time the existence of these intermediate classes becomes even more
important; without them, we would end up with many unrelated—and therefore difficult to maintain—
components representing each distinct specialized class. As our design unfolds, we are likely to
discover other important groupings of messages and so invent other intermediate classes.
Fortunately, reorganizing our class hierarchy in this manner tends to have minimal semantic
impact on the clients that ultimately use te base classes.

lOMoARcPSD|50445077
Figure 9–8 The Message Class Diagram

Train Schedule Planning
A train plan is central to the operation of the Train Traffic Management System. Each train has
exactly one active plan, and each plan is assigned to exactly one train and may involve many different
orders and locations on the track.

lOMoARcPSD|50445077
Figure 9–10 The TrainPlan Class Diagram

Figure 9–10 captures our strategic decisions regarding the structure of the TrainPlan class. We
use a class diagram to show the parts that compose a train plan (much as a traditional entity-relationship
diagram would do). Thus, we see that each train plan has exactly one crew and may have many general
orders and many actions. We expect these actions to be time ordered, with each action composed of
information such as time, a location, speed, authority, and orders. For example, a specific train plan
might consist of the actions shown in Table 9–1.
Displaying Information
It is important to encapsulate our design decisions regarding how various objects are represented
visually.

lOMoARcPSD|50445077
Figure 9–12 Class Utilities for Displaying

Figure 9–12 illustrates this design, showing that the implementation of all displayable objects
shares common class utilities. These utilities in turn build on lower-level Windows interfaces, which are
hidden from all of the higher-level classes. Pragmatically, interfaces such as the Windows API cannot
easily be expressed in a single class. Therefore, our diagram is a bit of a simplification: It is more likely
that our implementation will require a set of peer class utilities for the Windows API as well as for the
train display utilities.
Sensor Data Acquisition

The Train Traffic Management System includes many different kinds of sensors. For example,
sensors on each train monitor the oil temperature, fuel quantity, throttle setting, water temperature,
drawbar load, and so on. Similarly, active sensors in some of the wayside devices report among other
things the current positions of switches and signals. The kinds of values returned by the various sensors
are all different, but the processing of different sensor data is all very much the same. Furthermore,
most sensors must be sampled periodically. If a value is within a certain range, nothing special happens
other than notifying some client of the new value. If this value exceeds certain preset limits, a different
client might be warned. Finally, if this value goes far beyond its limits, we might need to sound some
sort of alarm and notify yet another client to take drastic action (e.g., when locomotive oil pressure
drops to
dangerous levels).
Release Management
Since we are using an incremental development approach, we will investigate the employment
of release management techniques and further analyze the system’s architecture and the specification of
its subsystems.
For example, we might select just the primary scenarios of three use cases: Route Train, Monitor
Train Systems, and Monitor Traffic. Together, the implementation of these three scenarios requires us
to touch almost every critical architectural interface, thereby forcing us to validate our strategic
assumptions. Once we successfully pass this milestone, we might then generate a stream of new
releases, according to the following sequence.

lOMoARcPSD|50445077

1. Create a train plan based on an existing one; modify a train plan.
2. Request detailed monitoring of a system with a yellow condition; request a failure prediction
analysis; request maintainer review of a failure prediction analysis.
3. Manually avoid a collision; request automated assistance in avoiding a collision; track train traffic
using either TTMS resources or Navstar GPS.
For a 12- to 18-month development cycle, this probably means generating a reasonably stable
release every 3 months or so, each building on the functionality of the other. When we are done, we will
have covered every scenario in the system.
System Architecture
Figure 9–13 The Top-Level Component Diagram for the Train Traffic Management System
The component diagram shown in Figure 9–13 represents our design decisions regarding the
top-level system architecture of the Train Traffic Management System. Here we see a layered
architecture that encompasses the functions of the four subproblems we identified earlier, namely,
networking, database, the human/ machine interface, and real-time device control.
Subsystem Specification
The component diagram in Figure 9–13 is merely a starting point for the specification of the
TTMS subsystem architecture. These top-level subsystems must be further decomposed through
multiple architectural levels of nested subsystems.
Looking at the NetworkFacilities subsystem, we decompose it into two other subsystems, a

private RadioCommunication subsystem and a public Messages subsystem. The private subsystem
hides the details of software control of the physical radio devices, while the public subsystem provides
the functionality of the message-passing mechanism we designed earlier.
The subsystem named Databases builds on the resources of the subsystem NetworkFacilities and
implements the train plan mechanism we created earlier. We choose to further decompose this
subsystem into two public subsystems, representing the major database elements in the system. We
name these nested subsystems TrainPlanDatabase and TrackDatabase, respectively. We also expect to
have one private subsystem, DatabaseManager, whose purpose is to provide all the services common to
the two domain-specific databases.

lOMoARcPSD|50445077
In the Devices subsystem, we choose to group the software related to all wayside devices into
one subsystem and the software associated with all onboard locomotive actuators and sensors into
another. These two subsystems are available to clients of the Devices subsystem, and both are built on
the resources of the TrainPlanDatabase and Messages subsystems. Thus, we have designed the Devices
subsystem to implement the sensor mechanism we described earlier.
Finally, we choose to decompose the top level UserApplications subsystem into several smaller
ones, including the subsystems EngineerApplications and DispatcherApplications, to reflect the
different roles of the two main users of the Train Traffic Management System. The subsystem
Engineer-pplications includes resources that provide all the train-engineer/machine interaction specified
in the requirements, including the functionality of the locomotive analysis and reporting system and the
energy management system. We include the subsystem DispatcherApplications to encompass the
software that provides the functionality of all dispatcher/machine interactions. Both
EngineerApplications and DispatcherApplications share common private resources, as provided from
the subsystem Displays, which
embodies the display mechanism we described earlier.
4.2.4 Post-Transition
For the Train Traffic Management System, we can envision a significant addition to our
requirements, namely, payroll processing. Specifically, suppose that our analysis shows that train
company payroll is currently being supported by a piece of hardware that is no longer being
manufactured and that we are at great risk of losing our payroll processing capability because a single
serious hardware failure would put our accounting system out of action forever. For this reason, we
might choose to integrate payroll processing with the Train Traffic Management System.
At first, it is not difficult to conceive how these two seemingly unrelated problems could
coexist; we could simply view them as separate applications, with payroll processing running as a
background activity.

ooad-2-r20

Uploaded by

Copyright:

Available Formats

ooad-2-r20

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ooad-2-r20

Uploaded by

Copyright:

Available Formats

lOMoARcPSD|50445077

Object Oriented Analysis and Design (Jawaharlal Nehru Technological University,

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Object Oriented Analysis and Design Using UML

Through modeling, we achieve four aims.

Object Oriented Modeling

The traditional view of software development takes an algorithmic perspective.

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

The UML is a language for

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

UML Building Blocks

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Generalization: is a relationship between General and more specific things. Graphically, a

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Diagrams in the UML

Use case diagram

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Rules of the UML

1. Elided Certain elements are hidden to simplify the view

Common Mechanisms in the UML

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

The organization of a software system

Vocabulary System Assembly

Performance System topology

Modeling a System's Architecture

Use case view

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Software Development Life Cycle:

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

There are four phases in the software development life cycle:

Basic Structural Modeling:

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)

Object Oriented Analysis and Design Using UML

Terms and Concepts

Simple Name Path Name

Attributes and Their Class

Prepared by T Siva Ramakrishna, Associate Professor,CSE,BVCITS.

Downloaded by Ranjan Yadav (ranjanyadav6709@gmail.com)