OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT – I
Introduction to UML: Importance of modeling, principles of modeling, object
oriented modeling, Conceptual model of the UML, Architecture, and Software
Development Life Cycle.

UNIT – I

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.

Importance of modeling
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.

Aims of modeling
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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  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.
 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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

Conceptual model of UML

To understand the UML, you need to form a conceptual model of the language, and
this requires learning three major elements:

 Basic building blocks of the UML

 Rules
 Common Mechanisms in the UML

Basic building blocks of the UML: Vocabulary of the UML can be defined

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

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
 It 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.

Fig: Class

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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.

IUnkonwn

Fig: Interface

Collaboration
 It 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.

Fig: Collaboration

Use case
 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

Fig: Use case

Active class
 It 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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Active class

Component
 It 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.

Fig: Component
Node
 It 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.

Fig: Node
Behavioral Things
 They 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

Fig: Message
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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  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

Fig: State machine

Grouping Things
1. These are the organizational parts of UML models. These are the boxes into
which a model can be decomposed
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.

Fig: Package
Annotational things
 These are the explanatory parts of UML models. These are the comments you may
apply to describe about any element in a model.
 There is one primary kind of Annotational thing, namely, note.

Note
 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.

Fig: Note

Relationships in the UML: There are four kinds of relationships in the UML:

1. Dependency
2. Association
3. Generalization
4. Realization

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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.

Fig: Dependency

Association
 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.

Fig: Association
Generalization
 Generalization is a special kind of association, representing a structural relationship
between a whole and its parts.
 Graphically, a generalization relationship is rendered as a solid line with a hollow
arrowhead pointing to the parent.

Fig: Generalization

Realization
 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.

Fig: Realization

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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 State chart 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 state chart diagram shows a state machine, consisting of states, transitions,
events, and activities
 State chart 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 state chart diagram that shows the flow
from activity to activity within a system
Activity diagrams address the dynamic view of a system
They are especially important in modeling the function of a system and
emphasize the flow of control among objects.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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
 They 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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  Many of these details can be rendered as graphical or textual adornments to the
class's basic rectangular notation.

Common Divisions
In modeling object-oriented systems, the world often gets divided in at least a couple of
ways.
First, there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, you can model classes as well as
objects, as shown in Figure 2-17

In this figure, there is one class, named Customer, together with three objects: Jan (which
is marked explicitly as being a Customer object), :Customer (an anonymous Customer
object), and Elyse (which in its specification is marked as being a kind of Customer
object, although it's not shown explicitly here).

Second, there is the separation of interface and implementation. An interface declares a

contract, and an implementation represents one concrete realization of that contract,
responsible for faithfully carrying out the interface's complete semantics. In the UML,
you can model both interfaces and their implementations, as shown in Figure 2-18.

In this figure, there is one component named spellingwizard.dll that implements two
interfaces, IUnknown and ISpelling.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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. Examples for these are

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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: 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
 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.

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.

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.

Deployment View
 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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 With the UML, the static aspects of this view are captured in deployment diagrams;
the dynamic aspects of this view are captured in interaction diagrams, statechart
diagrams, and activity diagrams.

 Each of these five views can stand alone so that different stakeholders can focus on
the issues of the system's architecture that most concern them.

 These five views also interact with one another• nodes in the deployment view hold
components in the implementation view that, in turn, represent the physical
realization of classes, interfaces, collaborations, and active classes from the design
and process views.

 The UML permits you to express every one of these five views and their interactions.

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

 It 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, for
testing, and for communicating among the stakeholders of the project.

Architecture-centric
 It 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
 It is one that involves managing a stream of executable releases.

An incremental process
 It is one that involves the continuous integration of the system's architecture to
produce these releases, with each new release embodying incremental
improvements over the other.

 Together, 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 phases.

 A phase is the span of time between two major milestones of the process, when a
well-defined set of objectives are met, artifacts are completed, and decisions are
made whether to move into the next phase.

 As below figure shows, there are four phases in the software development life
cycle: inception, elaboration, construction, and transition. In the diagram,

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 workflows are plotted against these phases, showing their varying degrees of
focus over time.

Fig: Figure Software Development Life Cycle

Inception phase:
 It 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 phase:
 It is the second phase of the process
 When the product vision and its architecture are defined.
 In this phase, the system's requirements are articulated, prioritized, and baselined.
 A system's requirements may range from general vision statements to precise
evaluation criteria, each specifying particular functional or nonfunctional
behavior and each providing a basis for testing.

Construction phase:
 It 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.
 The system's requirements and especially its evaluation criteria are constantly
reexamined against the business needs of the project, and resources are allocated
as appropriate to actively attack risks to the project.

Transition phase:
 It is the fourth phase of the process.
 When the software is turned into the hands of the user community.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  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.

 One element that distinguishes this process and that cuts across all four phases is
an iteration.
 An iteration is a distinct set of activities, with a baselined plan and evaluation
criteria that result in a release, either internal or external.
 This means that the software development life cycle can be characterized as
involving a continuous stream of executable releases of the system's architecture.
 It is this emphasis on architecture as an important artifact that drives the UML to
focus on modeling the different views of a system's architecture.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

UNIT - II
Basic Structural Modeling: Classes, Relationships, Common Mechanisms, and
diagrams.
Advanced Structural Modeling: Advanced classes, advanced relationships,
Interfaces, Types and Roles, Packages.

UNIT – II
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

Fig: Graphical Representation of Class in UML

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.

Fig: Simple and Path Names

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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.

Fig: 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.

Fig: Operations

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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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

Fig: Responsibilities

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

 Identify those things that users or implementers use to describe the problem or
solution.
 Use CRC cards and use case-based analysis to help find these abstractions.
 For each abstraction, identify a set of responsibilities.
 Provide the attributes and operations that are needed to carry out these
responsibilities for each class.

Figure shows a set of classes drawn from a retail system, including Customer, Order,
and Product. This figure includes a few other related abstractions drawn from the
vocabulary of the problem, such as Shipment (used to track orders), Invoice (used to bill
orders), and Warehouse (where products are located prior to shipment). There is also one
solution-related abstraction, Transaction, which applies to orders and shipments.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Modeling the Vocabulary of a System

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

 Identify a set of classes that work together closely to carry out some behavior.
 Identify a set of responsibilities for each of these classes.
 Look at this set of classes as a whole, split classes that have too many
responsibilities into smaller abstractions, collapse tiny classes that have trivial
responsibilities into larger ones, and reallocate responsibilities so that each
abstraction reasonably stands on its own.
 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.

For example, figure shows a set of classes drawn from Smalltalk, showing the
distribution of responsibilities among Model, View, and Controller classes. Notice how
all these classes work together such that no one class does too much or too little.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Modeling the Distribution of Responsibilities in a System

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 nonsoftware things

 Model the thing you are abstracting as a class.

 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.
 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.

Figure below shows, it's perfectly normal to abstract humans (like

AccountsReceivableAgent) and hardware (like Robot) as classes, because each
represents a set of objects with a common structure and a common behavior.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Modeling Nonsoftware Things

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.

Figure shows, these things can be modeled in the UML as types or enumerations, which
are rendered just like classes but are explicitly marked via stereotypes. Things like
integers (represented by the class Int) are modeled as types, and you can explicitly
indicate the range of values these things can take on by using a constraint. Similarly,
enumeration types, such as Boolean and Status, can be modeled as enumerations, with
their individual values provided as attributes.

Fig: Modeling Primitive Types

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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

Dependencies
 Dependencies are using relationships. For example, pipes depend on the water
heater to heat the water they carry..

Generalizations
 Generalizations connect generalized classes to more-specialized ones in what is
known as subclass/superclass or child/parent relationships.
 For example, a bay window is a kind of window with large, fixed panes; a patio
window is a kind of window with panes that open side to side.

Associations
 Associations are structural relationships among instances.
 For example, rooms consist of walls and other things; walls themselves may have
embedded doors and windows; pipes may pass through walls..

Fig: Relationships

Object Oriented Analysis and design, Dept. of CSE, RGMCET

Terms and Concepts

 A relationship is a connection among things. In object-oriented modeling, the

three most important relationships are dependencies, generalizations, and
associations.
 Graphically, a relationship is rendered as a path, with different kinds of lines used
to distinguish the kinds of relationships.

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

Fig: Dependencies
Generalization
 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).
 Generalization means that the child is substitutable for the parent. A child inherits
the properties of its parents, especially their attributes and operations
 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.
 Graphically generalization is rendered as a solid directed line with a large open
arrowhead, pointing to the parent

Fig: Generalization

Object Oriented Analysis and design, Dept. of CSE, RGMCET

Association

 An association is a structural relationship that specifies that objects of one thing

are connected to objects of another
 An association that connects exactly two classes is called a binary association
 An associations that connect more than two classes; these are called n-ary
associations.
 Graphically, an association is rendered as a solid line connecting the same or
different classes.
 Beyond this basic form, there are four adornments that apply to associations

Name

Fig: Association Names

 An association can have a name, and you use that name to describe the nature of
the relationship

Role
 When a class participates in an association, it has a specific role that it plays in
that relationship;
 The same class can play the same or different roles in other associations.
 An instance of an association is called a link

Fig: Role Names

Multiplicity

 In many modeling situations, it's important for you to state how many objects
may be connected across an instance of an association
 This "how many" is called the multiplicity of an association's role
 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).

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Multiplicity

Aggregation

 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").
 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
 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

Fig: Aggregation

Common Modeling Techniques

Modeling Simple Dependencies

The most common kind of dependency relationship is the connection between
classes that only uses another class as a parameter to an operation.

To model simple dependencies

 Create a dependency pointing from the class with the operation to the class used
as a parameter in the operation.
 The following figure shows a set of classes drawn from a system that manages
the assignment of students and instructors to courses in a university.
 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++.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Modeling simple dependency relationships

Modeling Single Inheritance

To model single 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.

Fig: Inheritance Relationships

Modeling Structural Relationships

 When you model with dependencies or generalization relationships, you are

modeling classes that represent different levels of importance or different levels of
abstraction
 Given a generalization relationship between two classes, the child inherits from its
parent but the parent has no specific knowledge of its children.
 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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 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).

 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

Fig: Structural Relationships

Common Mechanisms

 The UML is made simpler by the presence of four common mechanisms that apply
consistently throughout the language: specifications, adornments, common divisions,
and extensibility mechanisms.
 This chapter explains the use of two of these common mechanisms, adornments and
extensibility mechanisms.
 Notes are the most important kind of adornment that stands alone.
 A note is a graphical symbol for rendering constraints or comments attached to an
element or a collection of elements.
 You use notes to attach information to a model, such as requirements, observations,
reviews, and explanations.
 The UML's extensibility mechanisms permit you to extend the language in controlled
ways.
 These mechanisms include stereotypes, tagged values, and constraints.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 A 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. You use these mechanisms to tailor the UML to
the specific needs of your domain and your development culture.

Terms and Concepts

 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 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. As an option, the stereotyped element may be
rendered by using a new icon associated with that stereotype.

 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.

 A constraint is an extension of the semantics of a UML element, allowing you to add

new rules or to modify existing ones. 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. As an alternative, you can render a
constraint in a note.

Fig: Note, Stereotypes, Tagged Values, and Constraints

Object Oriented Analysis and design, Dept. of CSE, RGMCET

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. If your implementation
allows it,
 You can put a live URL inside a note, or even link to or embed another ocument.
In this way, you can use the UML to organize all the artifacts you might generate
or use during development.

Fig: Notes
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.

Fig: Stereotypes

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.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  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.
 In its simplest form, 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).

Fig: Tagged Values

Constraints
 A constraint specifies conditions that must be held true for the model to be well-
formed.
 A constraint is rendered as a string enclosed by brackets and placed near the
associated element
 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.

Fig: Constraints

Object Oriented Analysis and design, Dept. of CSE, RGMCET

Common Modeling Techniques

Modeling Comments
 The most common purpose for which you'll use notes is to write down free-form
observations, reviews, or explanations.
 By putting these comments directly in your models, your models can become a
common repository for all the disparate artifacts you'll create during
development.

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
 As your model evolves, keep those comments that record significant decisions
that cannot be inferred from the model itself, and• unless they are of historic
interest discard the others.

Fig: Modeling Comments

 For example, the above figure shows a model that's a work in progress of a class
hierarchy, showing some requirements that shape the model, as well as some
notes from a design review.
 In this example, most of the comments are simple text (such as the note to
Mary), but one of them (the note at the bottom of the diagram) provides a
hyperlink to another document

Modeling New Building Blocks

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  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

 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, identify the
primitive thing in the UML that's most like what you want to model and define a
new stereotype for that thing
 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.
 If you want these stereotype elements to have a distinctive visual cue, define a
new icon for the stereotype

Fig: Modeling New Building Blocks.

 The above Figure shows, there are two things that stand out-Coach objects and
Team objects. These are not just plain kinds of classes. Rather, they are now
primitive building blocks that you can use in this context.
 You can create these new building blocks by defining a coach and team
stereotype and applying them to UML's classes. In this figure, the anonymous
instances called: Coach and: Team (the latter shown in various states namely,
unregistered, registered, and finished) appear using the icons associated with
these stereotypes.

Modeling New Properties

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  The basic properties of the UML's building blocks—attributes and operations for
classes, the contents of packages, and so on—are generic enough to address most
of the things you'll want to model.
 However, if you want to extend the properties of these basic building blocks, you
need to use tagged values.

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.

 Figure shows four subsystems, each of which has been extended to include its
version number and status. In the case of the Billing subsystem, one other tagged
value is shown the person who has currently checked out the subsystem.

Fig: Modeling New Properties

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

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  If you need to specify your semantics more precisely and formally, write your
new semantics using OCL.

Fig: Modeling New Semantics

 This diagram shows that each Person may be a member of zero or more
Departments and that each Department must have at least one Person as a
member.
 This diagram goes on to indicate that each Department must have exactly one
Person as a manager and every Person may be the manager of zero or more
Departments. All of these semantics can be expressed using simple UML.

Diagrams

 When you view a software system from any perspective using the UML, you use
diagrams to organize the elements of interest.
 The UML defines nine kinds of diagrams, which you can mix and match to
assemble each view.
 Of course, you are not limited to these nine diagrams. In the UML, these nine are
defined because they represent the most common packaging of viewed elements.
To fit the needs of your project or organization, you can create your own kinds of
diagrams to view UML elements in different ways.
 You'll use the UML's diagrams in two basic ways:
 To specify models from which you'll construct an executable system
(forward engineering)
 To reconstruct models from parts of an executable system (reverse
engineering).

Terms and Concepts

System
 A system is a collection of subsystems organized to accomplish a purpose and
described by a set of models, possibly from different viewpoints
Subsystem
 A subsystem is a grouping of elements, of which some constitute a specification
of the behavior offered by the other contained elements.
Model
 A model is a semantically closed abstraction of a system, meaning that it
represents a complete and self-consistent simplification of reality, created in order
to better understand the system. In the context of architecture
View
 view is a projection into the organization and structure of a system's model,
focused on one aspect of that system

Object Oriented Analysis and design, Dept. of CSE, RGMCET

Diagram
 A diagram is the graphical presentation of a set of elements, most often rendered
as a connected graph of vertices (things) and arcs (relationships).
 A diagram is just a graphical projection into the elements that make up a system
 Each diagram provides a view into the elements that make up the system
 Typically, you'll view the static parts of a system using one of the four following
diagrams.
Class diagram
Object diagram
Component diagram
Deployment diagram
You'll often use five additional diagrams to view the dynamic parts of a system.
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram.

The UML defines these nine kinds of diagrams.

 Every diagram you create will most likely be one of these nine or occasionally of
another kind
 Every diagram must have a name that's unique in its context so that you can refer
to a specific diagram and distinguish one from another
 You can project any combination of elements in the UML in the same diagram.
For example, you might show both classes and objects in the same diagram

Structural Diagrams

 The UML's four structural diagrams exist to visualize, specify, construct, and
document the static aspects of a system.
 The UML's structural diagrams are roughly organized around the major groups of
things you'll find when modeling a system.
o Class diagram : Classes, interfaces, and collaborations
o Object diagram : Objects
o Component diagram : Components
o Deployment diagram : Nodes
Class Diagram
 We use class diagrams to illustrate the static design view of a system.
 Class diagrams are the most common diagram found in modeling object-oriented
systems.
 A class diagram shows a set of classes, interfaces, and collaborations and their
relationships.
 Class diagrams that include active classes are used to address the static process
view of a system.
Object Diagram
 Object diagrams address the static design view or static process view of a system
just as do class diagrams, but from the perspective of real or prototypical cases.
 An object diagram shows a set of objects and their relationships.
 You use object diagrams to illustrate data structures, the static snapshots of
instances of the things found in class diagrams.
Component Diagram

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  We use component diagrams to illustrate the static implementation view of a
system.
 A component diagram shows a set of components and their relationships.
 Component diagrams are related to class diagrams in that a component typically
maps to one or more classes, interfaces, or collaborations.
Deployment Diagram
 We use deployment diagrams to illustrate the static deployment view of an
architecture.
 A deployment diagram shows a set of nodes and their relationships.
 Deployment diagrams are related to component diagrams in that a node typically
encloses one or more components.

Behavioral Diagrams

 The UML's five behavioral diagrams are used to visualize, specify, construct, and
document the dynamic aspects of a system.
 The UML's behavioral diagrams are roughly organized around the major ways
you can model the dynamics of a system.

 Use case diagram : Organizes the behaviors of the system

 Sequence diagram : Focused on the time ordering of messages
 Collaboration diagram : Focused on the structural organization of objects that
Send and receive messages
 Statechart diagram : Focused on the changing state of a system driven by
Events
 Activity diagram : Focused on the flow of control from activity to
Activity
Use Case Diagram
 A use case diagram shows a set of use cases and actors and their relationships.
 We apply use case diagrams to illustrate the static use case view of a system.
 Use case diagrams are especially important in organizing and modeling the
behaviors of a system.

Sequence Diagram
 We use sequence diagrams to illustrate the dynamic view of a system.
 A sequence diagram is an interaction diagram that emphasizes the time ordering
of messages.
 A sequence diagram shows a set of objects and the messages sent and received by
those objects.
 The objects are typically named or anonymous instances of classes, but may also
represent instances of other things, such as collaborations, components, and
nodes.
Collaboration Diagram
 We use collaboration diagrams to illustrate the dynamic view of a system.

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages.
 A collaboration diagram shows a set of objects, links among those objects, and
messages sent and received by those objects.
 The objects are typically named or anonymous instances of classes, but may also
represent instances of other things, such as collaborations, components, and
nodes.

* Sequence and collaboration diagrams are isomorphic, meaning that you can convert
from one to the other without loss of information.

Statechart Diagram
 We use statechart diagrams to illustrate the dynamic view of a system.
 They are especially important in modeling the behavior of an interface, class, or
collaboration.
 A statechart diagram shows a state machine, consisting of states, transitions, events,
and activities.
 Statechart diagrams emphasize the event-ordered behavior of an object, which is
especially useful in modeling reactive systems.
Activity Diagram
 We use activity diagrams to illustrate the dynamic view of a system.
 Activity diagrams are especially important in modeling the function of a system.
 Activity diagrams emphasize the flow of control among objects.
 An activity diagram shows the flow from activity to activity within a system.
 An activity shows a set of activities, the sequential or branching flow from activity to
activity, and objects that act and are acted upon.

Common Modeling Techniques

Modeling Different Views of a System

 When you model a system from different views, you are in effect constructing your
system simultaneously from multiple dimensions.

To model a system from different views

 Decide which views you need to best express the architecture of your system and to
expose the technical risks to your project
 For each of these views, decide which artifacts you need to create to capture the
essential details of that view.
 As part of your process planning, decide which of these diagrams you'll want to put
under some sort of formal or semi-formal control.

 For example, if you are modeling a simple monolithic application that runs on a
single machine, you might need only the following handful of diagrams.

 Use case view : Use case diagrams

 Design view : Class diagrams (for structural modeling)
Interaction diagrams (for behavioral
modeling)
 Process view : None required
 Implementation view : None required
 Deployment view : None required

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 If yours is a reactive system or if it focuses on process flow, you'll probably want to
include statechart diagrams and activity diagrams, respectively, to model your
system's behavior.

 Similarly, if yours is a client/server system, you'll probably want to include

component diagrams and deployment diagrams to model the physical details of your
system.

 Finally, if you are modeling a complex, distributed system, you'll need to employ the
full range of the UML's diagrams in order to express the architecture of your system
and the technical risks to your project, as in the following.

• Use case view : Use case diagrams Activity diagrams (for behavioral modeling)
• Design view : * Class diagrams (for structural modeling)
* Interaction diagrams (for behavioral modeling)
* Statechart diagrams (for behavioral modeling)
• Process view : * Class diagrams (for structural modeling)
* Interaction diagrams (for behavioral modeling)
• Implementation view : Component diagram
• Deployment view : Deployment diagrams

Modeling Different Levels of Abstraction

 Not only do you need to view a system from several angles, you'll also find
people involved in development who need the same view of the system but at
different levels of abstraction
 Basically, there are two ways to model a system at different levels of abstraction:
1. By presenting diagrams with different levels of detail against the same
model
2. By creating models at different levels of abstraction with diagrams that
trace from one model to another.
To model a system at different levels of abstraction by presenting diagrams with
different levels of detail,
 Consider the needs of your readers, and start with a given model
 If your reader is using the model to construct an implementation, she'll need
diagrams that are at a lower level of abstraction which means that they'll need to
reveal a lot of detail
 If she is using the model to present a conceptual model to an end user, she'll need
diagrams that are at a higher level of abstraction which means that they'll hide a
lot of detail
 Depending on where you land in this spectrum of low-to-high levels of
abstraction, create a diagram at the right level of abstraction by hiding or
revealing the following four categories of things from your model:

Building blocks and relationships:

 Hide those that are not relevant to the intent of your diagram or the needs
of your reader.
Adornments:
 Reveal only the adornments of these building blocks and relationships that
are essential to understanding your intent.
Flow:

Object Oriented Analysis and design, Dept. of CSE, RGMCET

  In the context of behavioral diagrams, expand only those messages or
transitions that are essential to understanding your intent.
Stereotypes:
 In the context of stereotypes used to classify lists of things, such as
attributes and operations, reveal only those stereotyped items that are
essential to understanding your intent.

 The main advantage of this approach is that you are always modeling from a
common semantic repository.

 The main disadvantage of this approach is that changes from diagrams at one level
of abstraction may make obsolete diagrams at a different level of abstraction.

To model a system at different levels of abstraction by creating models at different

levels of abstraction,

 Consider the needs of your readers and decide on the level of abstraction that each
should view, forming a separate model for each level.
 In general, populate your models that are at a high level of abstraction with simple
abstractions and your models that are at a low level of abstraction with detailed
abstractions. Establish trace dependencies among the related elements of different
models.
 In practice, if you follow the five views of an architecture, there are four common
situations you'll encounter when modeling a system at different levels of abstraction:

Use cases and their realization:

 Use cases in a use case model will trace to collaborations in a design model.
Collaborations and their realization:
 Collaborations will trace to a society of classes that work together to carry out the
collaboration.
Components and their design:
 Components in an implementation model will trace to the elements in a design
model.
Nodes and their components:
 Nodes in a deployment model will trace to components in an implementation
model.
The main advantage of the approach is that diagrams at different levels of abstraction
remain more loosely coupled. This means that changes in one model will have less direct
effect on other models.

The main disadvantage of this approach is that you must spend resources to keep these
models and their diagrams synchronized

Object Oriented Analysis and design, Dept. of CSE, RGMCET

 Fig: Interaction Diagram at a High Level of Abstraction

Fig: Interaction at a Low Level of Abstraction

* Both of these diagrams work against the same model, but at different levels of detail.

Modeling Complex Views

To model complex views

 First, convince yourself there's no meaningful way to present this information at a
higher level of abstraction, perhaps eliding some parts of the diagram and retaining
the detail in other parts.

 If you've hidden as much detail as you can and your diagram is still complex,
consider grouping some of the elements in packages or in higher level collaborations,
then render only those packages or collaborations in your diagram.

 If your diagram is still complex, use notes and color as visual cues to draw the
reader's attention to the points you want to make.

 If your diagram is still complex, print it in its entirety and hang it on a convenient
large wall. You lose the interactivity an online version of the diagram brings, but you
can step back from the diagram and study it for common patterns.

Object Oriented Analysis and design, Dept. of CSE, RGMCET