UNIT-II

Introduction to UML: Why we model, Conceptual model of UML, Architecture,

Classes, Relationships, Common Mechanisms, Class diagrams, Object diagrams.

WHY WE MODEL

A model is a simplification at some level of abstraction

1. Importance of Modeling:

We build models to better understand the systems we are developing.

To help us visualize
To specify structure or behaviour
To provide template for building system
To document decisions we have made

2. Principles of Modeling:

The models we choose have a profound influence on the solution we provide Every
model may be expressed at different levels of abstraction
The best models are connected to reality
No single model is sufficient, a set of models is needed to solve any nontrivial system

UML is a visual modeling language

“A picture is worth a thousand words.” - old saying
Unified Modeling Language: “A language provides a vocabulary and the rules for
combining words [...] for the purpose of communication.
A modeling language is a language whose vocabulary and rules focus on the conceptual
and
physical representation of a system. A modeling language such as the UML is thus a
standard
language for software blueprints.”
Usages of UML: UML is used to
i. document designs
design patterns / frameworks
ii. Represent different views/aspects of design – visualize and construct designs static /
dynamic / deployment / modular aspects
iii. Provide a next-to-precise, common, language –specify visually for the benefit of
analysis, discussion, comprehension...
Object Oriented Modeling:

Traditionally two approaches to modeling a software system

Algorithmically – becomes hard to focus on as the requirements change
Object-oriented – models more closely real world entities
CONCEPTUAL MODEL OF THE UML

Conceptual Model of UML

Building Blocks Rules Common Mechanisms

Things RelationshipsDiagrams 1) Specifications

2) Adornments
1. Class Diagram. 3) Common Divisions
1)Association 2. Object Diagram. 4) Extensibility Mechanisms
2)Dependency 3. Use Case Diagram.
3)Generalization 4. Sequence Diagram. *Stereotypes
4) Realization 5. Collaboration Diagram. *Tagged Values
6.State Chart Diagram. 1) Names *Constraints
7.Activity Diagram. 2) Scope
9.Deployment Diagram. 3) Visibility
4) Integrity

5) Execution

Structural Things Behavioral Things Grouping Things Annotational

Things

*Classes *Interaction *Packages *notes

*Interfaces *State machines
*Collaborations *States
*Use Case
*Component
*Node
To understand the UML, you need to form a conceptual model of the language, and this
requires learning three major elements: the UML's basic building blocks, the rules that
dictate how those building blocks may be put together, and some common mechanisms
that apply throughout the UML. Once you have grasped these ideas, you will be able to
read UML models and create some basic ones. As you gain more experience in applying
the UML, you can build on this conceptual model, using more advanced features of the
language.

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:

1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first-class citizens in a model; relationships tie these
things together; diagrams group interesting collections of things.
Things in the UML
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML. You use them to
write well-formed models.
Structural 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. Collectively, the
structural things are called classifiers.
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. Graphically, a
class is rendered as a rectangle, usually including its name, attributes, and operations, as
shown in the following figure.
 Figure: Classes

An 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 defines a set of operation specifications (that is, their
signatures) but never a set of operation implementations. The declaration of an interface
looks like a class with the keyword «interface» above the name; attributes are not
relevant, except sometimes to show constants. An interface rarely stands alone, however.
An interface provided by a class to the outside world is shown as a small circle attached
to the class box by a line. An interface required by a class from some other class is shown
as a small semicircle attached to the class box by a line, as shown in the following figure.
Figure: Interfaces

A 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. Collaborations have structural, as well as behavioral, dimensions. A given
class or object might participate in several collaborations. These collaborations therefore
represent the implementation of patterns that make up a system. Graphically, a
collaboration is rendered as an ellipse with dashed lines, sometimes including only its
name, as shown in the following figure.
Figure: Collaborations

A use case is a description of sequences of actions that a system performs that yield
observable results of value to a particular actor. A 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, as shown
in the following figure.
Figure: Use Cases

The remaining three thingsactive classes, components, and nodesare all class-like,
meaning they also describe sets of entities that share the same attributes, operations,
relationships, and semantics. However, these three are different enough and are necessary
for modeling certain aspects of an object-oriented system, so they warrant special
treatment.
An active class is a class whose objects own one or more processes or threads
and therefore can initiate control activity. An 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 as a class with double lines on the left and right; it
usually includes its name, attributes, and operations, as shown in the following figure.

Figure: Active Classes

A component is a modular part of the system design that hides its implementation
behind a set of external interfaces. Within a system, components sharing the same
interfaces can be substituted while preserving the same logical behavior. The
implementation of a component can be expressed by wiring together parts and
connectors; the parts can include smaller components. Graphically, a component is
rendered like a class with a special icon in the upper right corner, as shown in the
following figure.
Figure: Components

The remaining two elementsartifacts and nodesare also different. They represent physical
things, whereas the previous five things represent conceptual or logical things.
An artifact is a physical and replaceable part of a system that contains physical
information ("bits"). In a system, you'll encounter different kinds of deployment artifacts,
such as source code files, executables, and scripts. An artifact typically represents the
physical packaging of source or run-time information. Graphically, an artifact is rendered
as a rectangle with the keyword «artifact» above the name, as shown in the following
figure.
Figure: Artifacts
A 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. A set
of components may reside on a node and may also migrate from node to node.
Graphically, a node is rendered as a cube, usually including only its name, as shown in
the following figure.
Figure: Nodes

These elements classes, interfaces, collaborations, use cases, active classes, components,
artifacts, and nodes are the basic structural things that you may include in a UML model.
There are also variations on these, such as actors, signals, and utilities (kinds of classes);
processes and threads (kinds of active classes); and applications, documents, files,
libraries, pages, and tables (kinds of artifacts).
Behavioral Things
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 three primary kinds of
behavioral things.
First, an interaction is a behavior that comprises a set of messages exchanged
among a set of objects or roles within a particular context to accomplish a specific
purpose. The behavior of a society of objects or of an individual operation may be
specified with an interaction. An interaction involves a number of other elements,
including messages, actions, and connectors (the connection between objects).
Graphically, a message is rendered as a directed line, almost always including the name
of its operation, as shown in the following figure.
Figure: Messages
Second, a 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. The behavior of an individual class or a collaboration of classes may be specified
with a state machine. A state machine involves a number of other elements, including states,
transitions (the flow from state to state), events (things that trigger a transition), and activities
(the response to a transition). Graphically, a state is rendered as a rounded rectangle, usually
including its name and its substates, if any, as shown in the following figure.
Figure: States

Third, an activity is a behavior that specifies the sequence of steps a computational process
performs. In an interaction, the focus is on the set of objects that interact. In a state machine, the
focus is on the life cycle of one object at a time. In an activity, the focus is on the flows among
steps without regard to which object performs each step. A step of an activity is called an action.
Graphically, an action is rendered as a rounded rectangle with a name indicating its purpose.
States and actions are distinguished by their different contexts.

Figure: Actions

These three elements interactions, state machines, and activities are the basic behavioral
things that you may include in a UML model. Semantically, these elements are usually connected
to various structural elements, primarily classes, collaborations, and objects.
Grouping Things
Grouping things are the organizational parts of UML models. These are the boxes into
which a model can be decomposed. There is one primary kind of grouping thing, namely,
packages.
A package is a general-purpose mechanism for organizing the design itself, as opposed to
classes, which organize implementation constructs. Structural things, behavioral things, and even

67
other grouping things may be placed in a package. Unlike components (which exist at run time),
a package is purely conceptual (meaning that it exists only at development time). Graphically, a
package is rendered as a tabbed folder, usually including only its name and, sometimes, its
contents, as shown in the following figure.
Figure: Packages

Packages are the basic grouping things with which you may organize a UML model. There are
also variations, such as frameworks, models, and subsystems (kinds of packages).
Annotational Things
Annotational things are the explanatory parts of UML models. These are the comments you may
apply to describe, illuminate, and remark about any element in a model. There is one primary
kind of annotational thing, called a 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, as shown in the
following figure.
Figure: Notes

This element is the one basic annotational thing you may include in a UML model. You'll
typically use notes to adorn your diagrams with constraints or comments that are best expressed
in informal or formal text. There are also variations on this element, such as requirements (which
specify some desired behavior from the perspective of outside the model).

Relationships in the UML

There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks of the UML. You use them to write

68
well-formed models.
First, a dependency is a semantic relationship between two model elements in which a change to
one element (the independent one) may affect the semantics of the other element (the dependent
one). Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally
including a label, as shown in the following figure.
Figure: Dependencies

Second, an association is a structural relationship among classes that describes a set of links, a
link being a connection among objects that are instances of the classes. Aggregation is a special
kind of association, representing a structural relationship between a whole and its parts.
Graphically, an association is rendered as a solid line, possibly directed, occasionally including a
label, and often containing other adornments, such as multiplicity and end names, as shown in the
following figure.
Figure: Associations

Third, a generalization is a specialization/generalization relationship in which the specialized

element (the child) builds on the specification of the generalized element (the parent). The child
shares the structure and the behavior of the parent. Graphically, a generalization relationship is
rendered as a solid line with a hollow arrowhead pointing to the parent, as shown in the following
figure.
Figure: Generalizations

Fourth, a realization is a semantic relationship between classifiers, wherein one classifier

specifies a contract that another classifier guarantees to carry out. You'll encounter realization
relationships in two places: between interfaces and the classes or components that realize them,
and between use cases and the collaborations that realize them. Graphically, a realization
relationship is rendered as a cross between a generalization and a dependency relationship, as
shown in the following figure.
Figure: Realizations

These four elements are the basic relational things you may include in a UML model. There are

69
also variations on these four, such as refinement, trace, include, and extend.

Diagrams in the UML

A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships). You draw diagrams to visualize a
system from different perspectives, so a diagram is a projection into a system. For all but the
most trivial systems, a diagram represents an elided view of the elements that make up a system.
The same element may appear in all diagrams, only a few diagrams (the most common case), or
in no diagrams at all (a very rare case). In theory, a diagram may contain any combination of
things and relationships. In practice, however, a small number of common combinations arise,
which are consistent with the five most useful views that comprise the architecture of a software-
intensive system. For this reason, the UML includes thirteen kinds of diagrams:

1. Class diagram
2. Object diagram
3. Component diagram
4. Composite structure diagram
5. Use case diagram
6. Sequence diagram
7. Communication diagram
8. State diagram
9. Activity diagram
10. Deployment diagram
11. Package diagram
12. Timing diagram
13. Interaction overview diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.
These diagrams are the most common diagram found in modeling object-oriented
systems. Class diagrams address the static design view of a system. Class diagrams that include
active classes address the static process view of a system. Component diagrams are variants of
class diagrams.
An object diagram shows a set of objects and their relationships. 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 as do class diagrams, but from
70
the perspective of real or prototypical cases.
A component diagram is shows an encapsulated class and its interfaces, ports, and
internal structure consisting of nested components and connectors. Component diagrams address
the static design implementation view of a system. They are important for building large systems
from smaller parts. (UML distinguishes a composite structure diagram, applicable to any class,
from a component diagram, but we combine the discussion because the distinction between a
component and a structured class is unnecessarily subtle.)
A use case diagram shows a set of use cases and actors (a special kind of class) 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.
Both sequence diagrams and communication diagrams are kinds of interaction diagrams.
An interaction diagram shows an interaction, consisting of a set of objects or roles, including the
messages that may be dispatched among them. Interaction diagrams address the dynamic view of
a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of
messages; a communication diagram is an interaction diagram that emphasizes the structural
organization of the objects or roles that send and receive messages. Sequence diagrams and
communication diagrams represent similar basic concepts, but each diagram emphasizes a
different view of the concepts. Sequence diagrams emphasize temporal ordering, and
communication diagrams emphasize the data structure through which messages flow. A timing
diagram (not covered in this book) shows the actual times at which messages are exchanged.

A state diagram shows a state machine, consisting of states, transitions, events, and
activities. A state diagrams shows the dynamic view of an object. They are especially important
in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered
behavior of an object, which is especially useful in modeling reactive systems.

An activity diagram shows the structure of a process or other computation as the flow of
control and data from step to step within the computation. 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.
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. A node typically hosts one or more artifacts.
An artifact diagram shows the physical constituents of a system on the computer.
Artifacts include files, databases, and similar physical collections of bits. Artifacts are often used

71
in conjunction with deployment diagrams. Artifacts also show the classes and components that
they implement. (UML treats artifact diagrams as a variety of deployment diagram, but we
discuss them separately.)
A package diagram shows the decomposition of the model itself into organization units
and their dependencies.
A timing diagram is an interaction diagram that shows actual times across different
objects or roles, as opposed to just relative sequences of messages. An interaction overview
diagram is a hybrid of an activity diagram and a sequence diagram. These diagrams have
specialized uses and so are not discussed in this book. See the UML Reference Manual for more
details.
This is not a closed list of diagrams. Tools may use the UML to provide other kinds of
diagrams, although these are the most common ones that you will encounter in practice.

Rules of the UML

The UML's building blocks can't simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony with all its
related models.
The UML has syntactic and semantic rules for
Names What you can call things, relationships, and diagrams
Scope The context that gives specific meaning to a name

Visibility How those names can be seen and used by others

Integrity How things properly and consistently relate to one another
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
Elided Certain elements are hidden to simplify the view
Incomplete Certain elements may be missing

Inconsistent The integrity of the model is not guaranteed

These less-than-well-formed models are unavoidable as the details of a system unfold and

72
churn during the software development life cycle. The rules of the UML encourage you but do
not force you to address the most important analysis, design, and implementation questions that
push such models to become well-formed over time.

Common Mechanisms in the UML

A building is made simpler and more harmonious by the conformance to a pattern of common
features. A house may be built in the Victorian or French country style largely by using certain
architectural patterns that define those styles. The same is true of the UML. It 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

Specifications
The UML is more than just a graphical language. Rather, behind every part of its
graphical notation there is a specification that provides a textual statement of the syntax and
semantics of that building block. For example, behind a class icon is a specification that provides
the full set of attributes, operations (including their full signatures), and behaviors that the class
embodies; visually, that class icon might only show a small part of this specification.
Furthermore, there might be another view of that class that presents a completely different set of
parts yet is still consistent with the class's underlying specification. You use the UML's graphical
notation to visualize a system; you use the UML's specification to state the system's details.
Given this split, it's possible to build up a model incrementally by drawing diagrams and then
adding semantics to the model's specifications, or directly by creating a specification, perhaps by
reverse engineering an existing system, and then creating diagrams that are projections into those
specifications.
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. The UML's
diagrams are thus simply visual projections into that backplane, each diagram revealing a specific
interesting aspect of the system.
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. For example, the notation for
a class is intentionally designed to be easy to draw, because classes are the most common
73
element found in modeling object-oriented systems. The class notation also exposes the most
important aspects of a class, namely its name, attributes, and operations.
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. For example, the following figure
shows a class, adorned to indicate that it is an abstract class with two public, one protected, and
one private operation.
Figure: Adornments

Every element in the UML's notation starts with a basic symbol, to which can be added a variety
of adornments specific to that symbol.
Common Divisions
In modeling object-oriented systems, the world often gets divided in several 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 the following figure. Graphically, the UML distinguishes an object by using the same symbol
as its class and then simply underlying the object's name.

Figure: Classes and Objects

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

74
 Almost every building block in the UML has this same kind of class/object dichotomy.
For example, you can have use cases and use case executions, components and component
instances, nodes and node instances, and so on.
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 the following figure.

Figure: Interfaces and Implementations

In this figure, there is one component named SpellingWizard.dll that provides

(implements) two interfaces, IUnknown and ISpelling. It also requires an interface, IDictionary,
that must be provided by another component.
Almost every building block in the UML has this same kind of interface/implementation
dichotomy. For example, you can have use cases and the collaborations that realize them, as well
as operations and the methods that implement them.
Third, there is the separation of type and role. The type declares the class of an entity,
such as an object, an attribute, or a parameter. A role describes the meaning of an entity within its
context, such as a class, component, or collaboration. Any entity that forms part of the structure
of another entity, such as an attribute, has both characteristics: It derives some of its meaning
from its inherent type and some of its meaning from its role within its context (below Figure).
Figure: Part with role and type

Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not

75
possible for one closed language to ever be sufficient to express all possible nuances of all
models across all domains across all time. For this reason, the UML is opened-ended, making it
possible for you to extend the language in controlled ways. The UML's extensibility mechanisms
include
• Stereotypes
• Tagged values
• Constraints
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. For
example, if you are working in a programming language, such as Java or C++, you will often
want to model exceptions. In these languages, exceptions are just classes, although they are
treated in very special ways. Typically, you only want to allow them to be thrown and caught,
nothing else. You can make exceptions first-class citizens in your modelsmeaning that they are
treated like basic building blocksby marking them with an appropriate stereotype, as for the class
Overflow in Figure 2-19.
A tagged value extends the properties of a UML stereotype, allowing you to create new
information in the stereotype's specification. For example, if you are working on a shrink-
wrapped product that undergoes many releases over time, you often want to track the version and
author of certain critical abstractions. Version and author are not primitive UML concepts. They
can be added to any building block, such as a class, by introducing new tagged values to that
building block. For example, the class EventQueue is extended by marking its version and
author explicitly.
A constraint extends the semantics of a UML building block, allowing you to add new
rules or modify existing ones. For example, you might want to constrain the EventQueue class so
that all additions are done in order. As shown in the following figure shows, you can add a
constraint that explicitly marks these for the operation add.
Figure: Extensibility Mechanisms

76
Collectively, these three extensibility mechanisms allow you to shape and grow the UML to your
project's needs. These mechanisms also let the UML adapt to new software technology, such as
the likely emergence of more powerful distributed programming languages. You can add new
building blocks, modify the specification of existing ones, and even change their semantics.
Naturally, it's important that you do so in controlled ways so that through these extensions, you
remain true to the UML's purpose the communication of information.

ARCHITECTURE
Any real world system is used by different users. The users can be developers, testers, business
people, analysts and many more. So before designing a system the architecture is made with
different perspectives in mind. The most important part is to visualize the system from different
viewer.s perspective. The better we understand the better we make the system.
UML plays an important role in defining different perspectives of a system. These
perspectives are:
• Design View
• Implementation View
• Process View
• Deployment View
• Usecase View
And the centre is the Use Case view which connects all these four. A Use case represents
the functionality of the system. So the other perspectives are connected with use case.
Design of a system consists of classes, interfaces and collaboration. UML provides class
diagram, object diagram to support this.
Implementation defines the components assembled together to make a complete physical
system. UML component diagram is used to support implementation perspective.
Process defines the flow of the system. So the same elements as used in Design are also
used to support this perspective.
Deployment represents the physical nodes of the system that forms the hardware. UML
deployment diagram is used to support this perspective.

Software Development Life Cycle:

The Unified Software Development Process
A software development process is the set of activities needed to transform a user„s requirements
into a software system.
Basic properties:
77
• use case driven
• architecture centric
• iterative and incremental
Use case Driven
Use cases
• capture requirements of the user,
• divide the development project into smaller subprojects,
• are constantly refined during the whole development process
• are used to verify the correctness of the implemented software
Architecture Centric:
• Find structures which are suitable to achive the function specified in the use cases,
• understandable,
• maintainable,
• reusable for later extensions or newly discovered use cases and describe them, so that they can
be communicated between developers and users.
Inception establishes the business rationale for the project and decides on the scope of the
project.
Elaboration is the phase where you collect more detailed requirements, do high-level analysis
and design to establish a baseline architecture and create the plan for construction.
Construction is an iterative and incremental process. Each iteration in this phase builds
production- quality software prototypes, tested and integrated as subset of the requirements of the
project.
Transition contains beta testing, performance tuning and user training.

CLASSES

A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. Graphically, a class is rendered as a rectangle.

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 qualified name is the class name prefixed by the
name of the package in which that class lives. A class may be drawn showing only its name

78
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 the thing you are modeling that is shared by all objects of that class.
For example, every wall has a height, width, and thickness; you might model your customers in
such a way that each has a name, address, phone number, and date of birth.

Operations
An operation is the implementation of a service that can be requested from any object of the
class to affect behavior. In other words, an operation is an abstraction of something you can do to
an object that is shared by all objects of that class. A class may have any number of operations or
no operations at all. For example, in a windowing library such as the one found in Java's awt
package, all objects of the class Rectangle can be moved, resized, or queried for their properties.
Often (but not always), invoking an operation on an object changes the object's data or state.
Graphically, operations are listed in a compartment just below the class attributes. Operations
may be drawn showing only their names

You can specify an operation by stating its signature, which includes the name, type, and default
value of all parameters and (in the case of functions) a return type.

79
Organizing Attributes and Operations

When drawing a class, you don't have to show every attribute and every operation at once. In
fact, in most cases, you can't (there are too many of them to put in one figure) and you probably
shouldn't (only a subset of these attributes and operations are likely to be relevant to a specific
view). For these reasons, you can elide a class, meaning that you can choose to show only some
or none of a class's attributes and operations. You can indicate that there are more attributes or
properties than shown by ending each list with an ellipsis ("...").

Responsibilities
A responsibility is a contract or an obligation of a class. When you create a class, you are
making a statement that all objects of that class have the same kind of state and the same kind of
behavior. At a more abstract level, these corresponding attributes and operations are just the
features by which the class's responsibilities are carried out. A Wall class is responsible for
knowing about height, width, and thickness; a FraudAgent class, as you might find in a credit
card application, is responsible for processing orders and determining if they are legitimate,
suspect, or fraudulent; a TemperatureSensor class is responsible for measuring temperature and
raising an alarm if the temperature reaches a certain point.

80
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.
Each of these abstractions is a part of the vocabulary of your system, meaning that, together, 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. Make sure that each class is crisply
defined and that there is a good balance of responsibilities among all your classes. Provide the
attributes and operations that are needed to carry out these responsibilities for each class.
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.

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

Modeling Nonsoftware Things

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.

82
Modeling Primitive Types
To model primitive types,
Model the thing you are abstracting as a class 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

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.
Dependencies
A dependency is a relationship that states that one thing (for example, class Window)
uses the information and services of another thing (for example, class Event), but not necessarily
the reverse. Graphically, a dependency is rendered as a dashed directed line, directed to the thing
being depended on. Choose dependencies when you want to show one thing using another.

Generalizations
A generalization is a relationship between a general kind of thing (called the superclass

83
or parent) and a more specific kind of thing (called the subclass or child). Generalization is
sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-
of a more general thing (for example, the class Window). An objects of the child class may be
used for a variable or parameter typed by the parent, but not the reverse

Associations
An association is a structural relationship that specifies that objects of one thing are
connected to objects of another. Given an association connecting two classes, you can relate
objects of one class to objects of the other class. It's quite legal to have both ends of an
association circle back to the same class. This means that, given an object of the class, you can
link to other objects of the same class. An association that connects exactly two classes is called a
binary association. Although it's not as common, you can have associations that connect more
than two classes; these are called n-ary associations.
Beyond this basic form, there are four adornments that apply to associations.
Name
An association can have a name, and you use that name to describe the nature of the relationship.
So that there is no ambiguity about its meaning, you can give a direction to the name by
providing a direction triangle that points in the direction you intend to read the name.

84
Role
When a class participates in an association, it has a specific role that it plays in that
relationship; a role is just the face the class at the far end of the association presents to the class at
the near end of the association. You can explicitly name the role a class plays in an association.
The role played by an end of an association is called an end name (in UML1, it was called a role
name). the class Person playing the role of employee is associated with the class Company
playing the role of employer.

Multiplicity
An association represents a structural relationship among objects. 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. It represents
a range of integers specifying the possible size of the set of related objects.
The number of objects must be in the given range. You can show a multiplicity of exactly
one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can give an integer range
(such as 2..5). You can even state an exact number (for example, 3, which is equivalent to 3..3).

Aggregation
A plain association between two classes represents a structural relationship between
peers, meaning that both classes are conceptually at the same level, no one more important than
85
the other. 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

Common Modeling Techniques

Modeling Simple Dependencies
A common kind of dependency relationship is the connection between a class that 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.
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.

Modeling Single Inheritance

In modeling the vocabulary of your system, you will often run across classes that are
structurally or behaviorally similar to others. You could model each of these as distinct and
unrelated abstractions. A better way would be to extract any common structural and behavioral
features and place them in more-general classes from which the specialized ones inherit.
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 elements (but be careful about
86
introducing too many levels).
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

When you model with dependencies or generalization relationships, you may be modeling
classes that represent different levels of importance or different levels of abstraction. Given a
dependency between two classes, one class depends on another but the other class has no
knowledge of the one.
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 local variables in a procedure or 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 they help 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 with a diamond.

87
COMMON MECHANISMS
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 (French quotation marks of the form «
»), placed above the name of another element.
Optionally the stereotyped element may be rendered by using a new icon associated with
that stereotype.
A tagged value is a property of a stereotype, allowing you to create new information in
an element bearing that stereotype. Graphically, a tagged value is rendered as a string of the form
name = value within a note attached to the object.
A constraint is a textual specification 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.

Notes
A note that renders a comment has no semantic impact, meaning that its contents do not
alter the meaning of the model to which it is attached. This is why notes are used to specify
things like requirements, observations, reviews, and explanations, in addition to rendering
constraints.
A note may contain any combination of text or graphics

88
Other Adornments
Adornments are textual or graphical items that are added to an element's basic notation
and are used to visualize details from the element's specification.

Stereotypes
The UML provides a language for structural things, behavioral things, grouping things,
and notational things. These four basic kinds of things address the overwhelming majority of the
systems you'll need to model.
In its simplest form, a stereotype is rendered as a name enclosed by guillemets (for
example, «name») and placed above the name of another element.

89
Tagged Values
Everything 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 to a stereotype.

Constraints
Everything in the UML has its own semantics. Generalization (usually, if you know what's good
for you) implies the Liskov substitution principle, and multiple associations connected to one
class denote distinct relationships. With constraints, you can add new semantics or extend
existing rules. A constraint specifies conditions that a run-time configuration must satisfy to
conform to the model.

90
• Stereotype specifies that the classifier is a stereotype that may be applied to other elements
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.
To model a comment,
Put your comment as text in a note and place it adjacent to the element to which it refers.
You can show a more explicit relationship by connecting a note to its elements using a
dependency relationship.
Remember that you can hide or make visible the elements of your model as you see fit.
This means that you don't have to make your comments visible everywhere the elements to which
it is attached are visible. Rather, expose your comments in your diagrams only insofar as you
need to communicate that information in that context.
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.

Modeling New Properties

The basic properties of the UML's building blocksattributes and operations for classes, the
contents of packages
To model new properties,
First, make sure there's not already a way to express what you want by using basic UML.

91
If you re convinced there's no other way to express these semantics, define a stereotype and add
the new properties to the stereotype. The rules of generalization applytagged values defined for
one kind of stereotype apply to its children.
the model itself, andunless they are of historic interestdiscard the others.

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 in
a constraint placed near the element to which it refers. You can show a more explicit relationship
by connecting a constraint to its elements using a dependency relationship.
If you need to specify your semantics more precisely and formally, write your new
semantics using OCL.

CLASS DIAGRAMS
A class diagram is a diagram that shows a set of classes, interfaces, and collaborations
and their relationships. Graphically, a class diagram is a collection of vertices and arcs.
Common Properties

92
 A class diagram is just a special kind of diagram and shares the same common properties
as do all other diagrams a name and graphical content that are a projection into a model. What
distinguishes a class diagram from other kinds of diagrams is its particular content.

Contents
Class diagrams commonly contain the following things:
Classes
Interfaces
Dependency, generalization, and association relationships
Common Uses
You use class diagrams to model the static design view of a system. This view primarily
supports the functional requirements of a system the services the system should provide to its end
users.
When you model the static design view of a system, you'll typically use class diagrams in
one of three ways.
1. To model the vocabulary of a system
Modeling the vocabulary of a system involves making a decision about which abstractions are a
part of the system under consideration and which fall outside its boundaries. You use class
diagrams to specify these abstractions and their responsibilities.
2. To model simple collaborations
A collaboration is a society of classes, interfaces, and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. For example,
when you re modeling the semantics of a transaction in a distributed system, you can't just stare
at a single class to understand what's going on. Rather, these semantics are carried out by a set of
classes that work together. You use class diagrams to visualize and specify this set of classes and
their relationships.
3. To model a logical database schema
Think of a schema as the blueprint for the conceptual design of a database. In many domains,
you'll want to store persistent information in a relational database or in an object-oriented
database. You can model schemas for these databases using class diagrams.
Common Modeling Techniques
Modeling Simple Collaborations
To model a collaboration,
Identify the mechanism you'd like to model. A mechanism represents some function or
93
behavior of the part of the system you are modeling that results from the interaction of a society
of classes, interfaces, and other things.
For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as well. Use
scenarios to walk through these things. Along the way, you'll discover parts of your model that
were missing and parts that were just plain semantically wrong.
Be sure to populate these elements with their contents. For classes, start with getting a
good balance of responsibilities. Then, over time, turn these into concrete attributes and
operations.

Modeling a Logical Database Schema

To model a schema,
Identify those classes in your model whose state must transcend the lifetime of their
applications.
Create a class diagram that contains these classes. You can define your own set of
stereotypes and tagged values to address database-specific details.

Expand the structural details of these classes. In general, this means specifying the details
of their attributes and focusing on the associations and their multiplicities that relate these
classes.
Watch for common patterns that complicate physical database design, such as cyclic
associations and one-to-one associations. Where necessary, create intermediate abstractions to

94
simplify your logical structure.
Consider also the behavior of these classes by expanding operations that are important for
data access and data integrity. In general, to provide a better separation of concerns, business
rules concerned with the manipulation of sets of these objects should be encapsulated in a layer
above these persistent classes.
Where possible, use tools to help you transform your logical design into a physical
design.

Forward and Reverse Engineering

Forward engineering is the process of transforming a model into code through a mapping to an
implementation language. Forward engineering results in a loss of information, because models
written in the UML are semantically richer than any current object-oriented programming
language. In fact, this is a major reason why you need models in addition to code. Structural
features, such as collaborations, and behavioral features, such as interactions, can be visualized
clearly in the UML, but not so clearly from raw code.
To forward engineer a class diagram,
Identify the rules for mapping to your implementation language or languages of choice.
This is something you'll want to do for your project or your organization as a whole. Depending
on the semantics of the languages you choose, you may want to constrain your use of certain

95
UML features. For example, the UML permits you to model multiple inheritance, but Smalltalk
permits only single inheritance. You can choose to prohibit developers from modeling with
multiple inheritance (which makes your models language-dependent), or you can develop idioms
that transform these richer features into the implementation language (which makes the mapping
more complex).
Use tagged values to guide implementation choices in your target language. You can do
this at the level of individual classes if you need precise control. You can also do so at a higher
level, such as with collaborations or packages.
Use tools to generate code.

All of these classes specify a mapping to Java, as noted in their stereotype. Forward engineering
the classes in this diagram to Java is straightforward, using a tool. Forward engineering the class
EventHandler yields the following code.

public abstract class EventHandler {

EventHandler successor; private Integer currentEventID; private String source;
EventHandler() {}
public void handleRequest() {}
}

Reverse engineering is the process of transforming code into a model through a mapping from a
specific implementation language. Reverse engineering results in a flood of information, some of
which is at a lower level of detail than you'll need to build useful models. At the same time,
reverse engineering is incomplete. There is a loss of information when forward engineering

96
models into code, and so you can't completely recreate a model from code unless your tools
encode information in the source comments that goes beyond the semantics of the
implementation language.
To reverse engineer a class diagram,
Identify the rules for mapping from your implementation language or languages of
choice. This is something you'll want to do for your project or your organization as a whole.
Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a
new model or modify an existing one that was previously forward engineered. It is unreasonable
to expect to reverse engineer a single concise model from a large body of code. You need to
select portion of the code and build the model from the bottom.
Using your tool, create a class diagram by querying the model. For example, you might
start with one or more classes, then expand the diagram by following specific relationships or
other neighbouring classes. Expose or hide details of the contents of this class diagram as
necessary to communicate your intent.
Manually add design information to the model to express the intent of the design that is
missing or hidden in the code.

OBJECT DIAGRAMS
Object diagrams model the instances of things contained in class diagrams. An object diagram
shows a set of objects and their relationships at a point in time.
An object diagram is a diagram that shows a set of objects and their relationships at a
point in time. Graphically, an object diagram is a collection of vertices and arcs.
Common Properties
An object diagram is a special kind of diagram and shares the same common properties as all
other diagrams that is, a name and graphical contents that are a projection into a model. What
distinguishes an object diagram from all other kinds of diagrams is its particular content.
Contents
Object diagrams commonly contain
•Objects
•Links
Like all other diagrams, object diagrams may contain notes and constraints. Sometimes you'll
want to place classes in your object diagrams as well, especially when you want to visualize the
classes behind each instance.
Common Uses

97
You use object diagrams to model the static design view or static process view of a system just as
you do with class diagrams, but from the perspective of real or prototypical instances. This view
primarily supports the functional requirements of a system that is, the services the system should
provide to its end users. Object diagrams let you model static data structures.
When you model the static design view or static process view of a system, you typically use
object diagrams in one way:
To model object structures
Modeling object structures involves taking a snapshot of the objects in a system at a given
moment in time. An object diagram represents one static frame in the dynamic storyboard
represented by an interaction diagram. You use object diagrams to visualize, specify, construct,
and document the existence of certain instances in your system, together with their relationships
to one another.

Common Modeling Techniques

Modeling Object Structures
To model an object structure,
•Identify the mechanism you'd like to model. A mechanism represents some function or behavior
of the part of the system you are modeling that results from the interaction of a society of classes,
interfaces, and other things.
• Create a collaboration to describe a mechanism.
• For each mechanism, identify the classes, interfaces, and other elements that participate in this
collaboration; identify the relationships among these things as well.
•Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in
time, and render each object that participates in the mechanism.
•Expose the state and attribute values of each such object, as necessary, to understand the
scenario.
•Similarly, expose the links among these objects, representing instances of associations among
them.
Forward and Reverse Engineering
Forward engineering (the creation of code from a model) an object diagram is theoretically
possible but pragmatically of limited value. In an object-oriented system, instances are things that
are created and destroyed by the application during run time. Therefore, you cannot exactly
instantiate these objects from the outside.
Reverse engineering (the creation of a model from code) an object diagram can be useful. In fact,

98
while you are debugging your system, this is something that you or your tools will do all the
time. For example, if you are chasing down a dangling link, you'll want to literally or mentally
draw an object diagram of the affected objects to see where, at a given moment in time, an
object's state or its relationship to other objects is broken.
To reverse engineer an object diagram,
•Chose the target you want to reverse engineer. Typically, you'll set your context inside an
operation or relative to an instance of one particular class.
• Using a tool or simply walking through a scenario, stop execution at a certain moment in time.
• Identify the set of interesting objects that collaborate in that context and render them in an
object diagram.
• As necessary to understand their semantics, expose these object's states.
• As necessary to understand their semantics, identify the links that exist among these objects.

IMPORTANT QUESTIONS
1. Discuss about conceptual model in UML and building blocks of UML.
2. What are the common mechanisms of UML and explain in detailed.
3. Define UML and explain how the architecture of UML meets the requirements of
modeling?
4. Explain in detail about the extensibility mechanisms in UML.
5. Explain the various relationships with UML notation.
6. Enumerate the steps to model logical database schema. Give all example class diagrams.
7. Enumerate the steps to model different views of a system.

99