OOAD – Module 2

Part1
Concepts of Object Orientation: Object Modelling Technology,
Basic Principles of Object Orientation: Abstraction Encapsulation, Polymorphism,
Modularity, Hierarchy.
UML Modelling Mechanisms.
Structural Modelling: Classes and Interfaces, Attributes and Operations,
Relationships: Association, Dependency, Generalization, Multiplicity, Aggregation,
Interface, Types and Roles, Instances.
UML Notation: Things, Relationships, Extensibility, Diagrams. UML Standard
Elements: Stereotypes, Tagged Values, Constraints.
Object Modeling Technology

• Three analysis techniques that are used in conjunction with each other for object-
oriented analysis are
• Object modeling
• Dynamic modeling
• Functional modeling
Object Modeling

The process of object modeling can be visualized in the following steps:

• Identify objects and group into classes
• Identify the relationships among classes
• Create user object model diagram
• Define user object attributes
• Define the operations that should be performed on the classes
Dynamic Modeling

• “A way of describing how an individual object responds to events, either internal

events triggered by other objects, or external events triggered by the outside
world”.
• The process of dynamic modelling can be visualized in the following steps −
• Identify states of each object
• Identify events and analyze the applicability of actions
• Construct dynamic model diagram, comprising of state transition diagrams
• Express each state in terms of object attributes
• Validate the state–transition diagrams drawn
Functional Modeling

• Processes that are performed within an object and how the data changes as it
moves between methods.
• It specifies the meaning of the operations of object modelling and the actions of
dynamic modelling.
• The functional model corresponds to the data flow diagram of traditional
structured analysis.
• The process of functional modelling can be visualized in the following steps −
• Identify all the inputs and outputs
• Construct data flow diagrams showing functional dependencies
• State the purpose of each function
• Identify constraints
• Specify optimization criteria
 Concepts of Object Orientation
Basic Principles of Object Orientation :
• The conceptual framework of object–oriented systems is based upon the object
model.
• There are two categories of elements in an object-oriented system: Major elements
and minor elements.
• Five major elements
• Abstraction
• Encapsulation
• Polymorphism
• Modularity
• Hierarchy
• Three minor elements
• Typing
• Concurrency
• Persistence
Abstraction

• Grady Booch, “An abstraction denotes the essential characteristics of an object

that distinguish it from all other kinds of objects and thus provide crisply defined
conceptual boundaries, relative to the perspective of the viewer.”
• eg., Employee.
• An abstraction isolates use from implementation: an abstraction can be used
without knowledge of its implementation and implemented without knowledge of
its use.
• A way or mechanism to represent complex reality using simplified model.
• The behavior of the data objects were completely characterized by the set
of operations. Classical example is definition of stack cluster using only push
and pop operations.
• Dependency relationship that relates two elements or sets of elements
(called client and supplier) representing the same concept but at different
levels of abstraction or from different viewpoints.
• Realization is a specialized abstraction relationship between two sets of model
elements, one representing a specification (the supplier) and the other
represents an implementation of the latter (the client).
Encapsulation
• Encapsulation is the process of binding both attributes and methods together
within a class.
• Internal details of a class can be hidden from outside.
• The class has methods that provide user interfaces by which the services provided
by the class may be used.
• Encapsulation is a development technique which includes creating new data types
(classes) by combining both information (structure) and behaviors, and restricting
access to implementation details.
• Object is defined as an entity with a well defined boundary and identity
that encapsulates state (attributes and relationships) and behavior (operations,
methods, and state machines).
• Elements in peer packages are encapsulated and are not a priori visible to
each other.
• Component represents a modular part of a system that encapsulates its
contents and whose manifestation is replaceable within its environment.
• Component is encapsulated and as a result, Components and subsystems can
be flexibly reused and replaced by connecting ("wiring") them together.
Polymorphism
• Implies using operations in different ways, depending upon the instance they
are operating upon.
• Ability to apply different meaning (semantics, implementation) to the same
symbol (message, operation) in different contexts.
• Allows objects with different internal structures to have a common external
interface.
• Particularly effective while implementing inheritance.
• Example : Circle and Square.
• When context is defined at compile time, it is called static or compile-time
polymorphism. Eg. Overloading, Parametric polymorphism : templates.
• When context is defined during program execution, it is dynamic or run-time
polymorphism. Eg. Dynamic binding or late binding
• Operations are specified in the model and can be dynamically selected only
through polymorphism.
Modularity

• Process of decomposing a problem (program) into a set of modules so as to

reduce the overall complexity of the problem.
• Booch has defined modularity: “Modularity is the property of a system that has
been decomposed into a set of cohesive and loosely coupled modules.”
• Modularity is intrinsically linked with encapsulation.
• Modularity can be visualized as a way of mapping encapsulated abstractions into
real, physical modules having high cohesion within the modules and their inter–
module interaction or coupling is low.
Hierarchy

• Booch, “Hierarchy is the ranking or ordering of abstraction”.

• System can be made up of interrelated subsystems, which can have their
own subsystems and so on until the smallest level components are reached.
• It uses the principle of “divide and conquer”. Hierarchy allows code
reusability.
• Two types of hierarchies
• “IS–A” hierarchy − hierarchical relationship in inheritance, example, if
we derive a class Journal, Magazine and Study material from a class
Book, we can say that a rose “is–a” Book.
• “PART–OF” hierarchy − hierarchical relationship in aggregation by
which a class may be composed of other classes. For example, a Book is
composed of author name, publisher, edition, No, of copies. It can be
said that a publisher is a “part–of” Book.
Typing

• Enforcement of the notion that an object is an instance of a single class or

type.
• Enforces that objects of different types may not be generally interchanged;
and can be interchanged only in a very restricted manner if absolutely
required to do so.
• Strong Typing − Operation on an object is checked at the time of
compilation.
• Weak Typing − Messages may be sent to any class. Operation is checked
only at the time of execution.
Concurrency
• Two types: active and inactive objects.
• Active objects have independent threads of control that can execute concurrently
with threads of other objects.
• Active objects synchronize with one another as well as with purely sequential
objects.

Persistence
• An object occupies a memory space and exists for a particular period of time.
• Lifespan of an object was typically the lifespan of the execution of the program
that created it.
• Object lifespan is longer than the duration of the process creating the object.
• Object continues to exist even after its creator ends to exist.
Structural Modeling: Classes, Relationships, Common mechanism
and Diagrams
1. Classes:
• A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
• Names
• Every class must have a name that distinguishes it from other classes.
• A name is a textual string.
• 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
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.
• 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.
• Invoking an operation on an object changes the object's data or state.
• 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
Organizing Attributes and Operations
• When drawing a class, you don't have to show every attribute and every operation
at once.
• choose to show only some or none of a class's attributes and operations.
• 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
• 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
Modeling the Vocabulary of a System
• To model the vocabulary of a system,
• Identify those things that users or implementers use to describe the
problem or solution.
• Use 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.
• Modeling the Distribution of Responsibilities in a System
• 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.
• 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.
• Redistribute their responsibilities
accordingly so that no class within
a collaboration does too much or
too little.
• Modelling 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.
2.Relationships:
• A relationship is a connection among things.
• In object-oriented modeling, the three most important relationships are
dependencies, generalizations, and associations.
• Dependencies
• Relationship that states that one thing uses the information and services of
another thing , but not necessarily the reverse.
• Generalizations
• A generalization is a relationship between a general kind of thing and a more
specific kind of thing.
• Generalization is sometimes called an "is-a-kind-of" relationship: one thing (class
Journal) is-a-kind-of a more general thing (the class Book).
• 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.
• 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.
• There are four adornments that apply to associations : Name, Role,
Multiplicity and Aggregation.
• Name:
• An association can have a name, which is used to describe the nature of the
relationship.

• Role :
• Class 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.
• Explicitly name the role a class plays in an association.
• Multiplicity:
• An association represents a structural relationship among objects.
• 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-show a multiplicity of exactly
one (1), zero or one (0..1), many (0..*), or one or more (1..*).
• Integer range (such as 2..5). You can even state an exact number (for example, 3,
which is equivalent to 3..3).
• Aggregation:
• Association between two classes represents both classes are conceptually at the
same level, no one more important than the other.
• 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.
Modelling Simple Dependencies
• 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.
Modelling Single Inheritance
• To model inheritance relationships,
• Given a set of classes, look for responsibilities, attributes, and operations that
are common to two or more classes.
• Elevate these common responsibilities, attributes, and operations to a more
general class. If necessary, create a new class to which you can assign these
elements (but be careful about 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.
Modelling Structural Relationships
• 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.
Modelling Structural Relationships
• To model structural relationships,
• 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
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.
• Notes are the most important kind of adornment.
• A note is a graphical symbol for rendering constraints or comments attached to an
element or a collection of elements.
• 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.
• A stereotype extends the vocabulary of the UML, 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, to create new
information in that element's specification.
• A constraint extends the semantics of a UML building block, to add new rules or
modify existing ones.
• For example, if you are modeling a network, you might want to have symbols for
routers and hubs; you can use stereotyped nodes to make these things appear as
primitive building blocks.
• if you are part of your project's release team, responsible for assembling, testing,
and then deploying releases, you might want to keep track of the version number
and test results for each major subsystem. You can use tagged values to add this
information to your models.
• Finally, if you are modeling hard real time systems, you might want to adorn your
models with information about time budgets and deadlines; you can use
constraints to capture these timing requirements.
 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.
• Notes may be attached to more than one element by using dependencies
• A note may contain any combination of text or graphics.
• You can put a live URL inside a note, or even link to or embed another document
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.
• For example, the basic notation for an association is a line, but this may be
adorned with such details as the role and multiplicity of each end.
• In using the UML, the general rule to follow is this: Start with the basic notation
for each element and then add other adornments only as they are necessary to
convey specific information that is important to your model.
Stereotypes
• Introduce new things that speak the vocabulary of your domain and look like
primitive building blocks.
• metatype, equivalent of a new class in the UML's metamodel.
• each stereotype may provide its own set of tagged values, semantics (each
stereotype may provide its own constraints), and notation (each stereotype may
provide its own icon).
Tagged Values

• Define tags for existing elements of the UML, or define tags that apply to
individual stereotypes so that everything with that stereotype has that tagged
value.
• A tagged value is not the same as a class attribute.
• tagged value is a metadata because its value applies to the element itself, not its
instances.
• For example, to specify the number of processors installed on each kind of node in
a deployment diagram, or you might want to require that every component be
stereotyped as a library if it is intended to be deployed on a client or a server.
Constraints

• A constraint specifies conditions that must be held true for the model to be well-
formed.
Standard Elements

The UML defines a number of standard stereotypes for classifiers, components,

relationships, and other modeling elements.
There is one standard stereotype, mainly of interest to tool builders, that lets you
model stereotypes themselves.
• stereotype - Specifies that the classifier is a stereotype that may be applied to other
elements
The UML also specifies one standard tagged value that applies to all modeling
elements.
• documentation - Specifies a comment, description, or explanation of the element
to which it is attached
Modelling Comments
• To model a comment,
• Show a more explicit relationship by connecting a note to its elements using a
dependency relationship.
• Expose your comments in your diagrams only in so far as you need to
communicate that information in that context.
Modelling Comments
• To model a comment,
• 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 Building Blocks

• The UML's building blocks - classes, interfaces, collaborations, components,

nodes, associations, and so on - are generic enough to address most of the things
you'll want to model.
• If you want to extend your modeling vocabulary or give distinctive visual cues to
certain kinds of abstractions that often appear in your domain, 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 have a common modeling problem, chances are there's already some
standard stereotype that will do what you want.
• If not, identify the primitive thing in the UML to model (for example, class,
interface, component, node, association, and so on) and define a new
stereotype for that thing.
• Remember that you can define hierarchies of stereotypes so that you can have
general kinds of stereotypes along with their specializations (but as with any
hierarchy, use this sparingly).
• 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.
Modelling New Properties
• To model new properties,
• First, make sure there's not already a way to express what you want by using
basic UML.
• If you’re convinced there's no other way to express these semantics, define a
stereotype and add the new properties to the stereotype.
• The rules of generalization apply tagged values defined for one kind of
stereotype apply to its children.
Modelling New Semantics
• 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.
Notations
Modeling Classes, Objects and Relationships

• A company consists of departments. Departments are located in one or more

offices. One office acts as a headquarter. Each department has a manager
who is recruited from the set of employees. Model the system for the
company.

Identify the classes, objects and relationship for the following applications
• e-commerce shopping website.
• ATM software.
• Car modeling.
• Customer
Attributes: customerId, name, email, address
Methods: register(), login(), updateProfile()
• Order
Attributes: orderId, orderDate, totalAmount
Methods: placeOrder(), cancelOrder(), calculateTotal()
• Product
Attributes: productId, name, price, stock
Methods: updateStock(), applyDiscount()
• Payment
Attributes: paymentId, paymentType, amount
Methods: processPayment(), refundPayment()
• Cart
Attributes: cartId, items, totalPrice
Methods: addItem(), removeItem(), checkout()
ATM system
Diagrams

• Build your models from basic building blocks, such as classes, interfaces,
collaborations, components, nodes, dependencies, generalizations, and
associations.
• Diagrams are the means by which you view these building blocks.
• A diagram is a graphical presentation of a set of elements, most often rendered as
a connected graph of vertices (things) and arcs (relationships).
• Use diagrams to visualize your system from different perspectives.
• Because no complex system can be understood in its entirety from only one
perspective,
• The UML defines a number of diagrams so that you can focus on different aspects
of your system independently.
• Good diagrams make the system you are developing understandable and
approachable.
• Choosing the right set of diagrams to model your system forces you to ask the
right questions about your system and helps to illuminate the implications of your
decisions.
In the context of software, there are five complementary views that are most
important in visualizing, specifying, constructing, and documenting a software
architecture:
1. the use case view,
2. the design view,
3. the process view,
4. the implementation view, and
5. the deployment view.

• Each of these views involves structural modeling (modeling static things), as

well as behavioral modeling (modeling dynamic things).
• Together, these different views capture the most important decisions about the
system.
• Individually, each of these views lets you focus attention on one perspective of
the system so that you can reason about your decisions with clarity.
• The UML defines nine kinds of diagrams, which can mixed and matched to
assemble each view.
• For example, the static aspects of a system's implementation view might be
visualized using component diagrams; the dynamic aspects of the same
implementation view might be visualized using interaction diagrams.
• Similarly, the static aspects of a system's database might be visualized using class
diagrams; its dynamic aspects might be visualized using collaboration diagrams.
• Create your own kinds of diagrams to view UML elements in different ways.
Use the UML's diagrams in two basic ways:
• to specify models from which you'll construct an executable system (forward
engineering) and
• to reconstruct models from parts of an executable system (reverse engineering).
• Either way, just like a building architect, create your diagrams incrementally
(crafting them one piece at a time) and iteratively (repeating the process of design
a little, build a little).
Terms & Concepts:
• System is a collection of subsystems organized to accomplish a purpose and
described by a set of models, possibly from different viewpoints.
• Subsystem is a grouping of elements, some of which constitute a specification of
the behavior offered by the other contained elements.
• 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 is a projection into the organization and structure of a system's model,
focused on one aspect of that system.
• Diagram is the graphical presentation of a set of elements, most often rendered as
a connected graph of vertices (things) and arcs (relationships).
• In modeling real systems, no matter what the problem domain, you'll find
yourself creating the same kinds of diagrams, because they represent
common views into common models.
• Static parts of a system using one of the following diagrams.
1. Class diagram
2. Component diagram
3. Composite structure diagram
4. Object diagram
5. Deployment diagram
6. Artifact diagram
• Dynamic parts of a system.
1. Use case diagram
2. Sequence diagram
3. Communication diagram
4. State diagram
5. Activity diagram
• 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.
• For anything but the most trivial system, you'll want to organize your diagrams into
packages.
• You can project any combination of elements in the UML in the same diagram.
• For example, you can show both classes and objects in the same diagram (a
common thing to do), or you might even show both classes and components in the
same diagram (legal, but less common).
• It's more common for you to have roughly the same kinds of things in one diagram.
• The UML's defined diagrams are named after the element you'll most often place in
each.
• For example, if you want to visualize a set of classes and their relationships, you'll
use a class diagram.
• Similarly, if you want to visualize a set of components, you'll use a component
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.
Class Diagram
• A class diagram shows a set of classes, interfaces, and collaborations
and their relationships.
• Class diagrams are the most common diagram found in modeling
object-oriented systems.
• Use class diagrams to illustrate the static design view of a system.
• Class diagrams that include active classes are used to address the
static process view of a system.
Object Diagram
• An object diagram shows a set of objects and their relationships.
• Use object diagrams to illustrate data structures, the static snapshots
of instances of the things found in class diagrams.
• 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.
Component Diagram
• A component diagram shows a set of components and their
relationships.
• Use component diagrams to illustrate the static implementation view
of a system.
• Component diagrams 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 a set of nodes and their relationships.
• Use deployment diagrams to illustrate the static deployment view of
an architecture.
• Deployment diagrams are related to component diagrams in that a
node typically encloses one or more components.
• There are some common variants of these four diagrams, named
after their primary contents.
• For example, you might create a subsystem diagram to illustrate the
structural decomposition of a system into subsystems.
• A subsystem diagram is just a class diagram that contains, primarily,
subsystems.
• UML's structural diagrams are roughly organized around the major groups
of things you'll find when modeling a system.

1.Class diagram Classes, interfaces, and collaborations

2.Component diagram Components
3.Object diagram Objects
4.Deployment diagram Nodes
Behavioral Diagrams
• The UML's five behavioral diagrams are used to visualize, specify,
construct, and document the dynamic aspects of a system.
• The dynamic aspects of a software system encompass such things as
the flow of messages over time and the physical movement of
components across a network.
• The UML's behavioral diagrams are roughly organized around the
major ways you can model the dynamics of a system.
Use Case Diagram
• A use case diagram shows a set of use cases and actors (a special kind
of class) and their relationships.
• 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.
Interaction diagram
• Interaction diagram is the collective name given to sequence
diagrams and collaboration diagrams.
• All sequence diagrams and collaborations are interaction diagrams,
and an interaction diagram is either a sequence diagram or a
collaboration diagram.
• Sequence and collaboration diagrams are isomorphic, meaning that
you can convert from one to the other without loss of information.
Sequence Diagram
• 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.
• Use sequence diagrams to illustrate the dynamic view of a system.
Collaboration Diagram
• 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.
• Use collaboration diagrams to illustrate the dynamic view of a system.
Statechart Diagram
• A statechart diagram shows a state machine, consisting of states,
transitions, events, and activities.
• 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.
• Statechart diagrams emphasize the event-ordered behavior of an
object, which is especially useful in modeling reactive systems.
Activity Diagram
• 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.
• 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
Model the dynamics of a system using one kind of behavioral diagram and
then transform it to another kind of diagram without loss of information.

• This lets you reason about different aspects of your system's dynamics.
• For example, you might want first to create a sequence diagram that
illustrates the time ordering of messages and then turn that into a
collaboration diagram so that you can develop the structural relationships
among the classes whose objects participate in this collaboration (you can go
from collaboration diagrams to sequence diagrams, as well).
• Similarly, you might want to start with a statechart diagram to illustrate the
event-driven response of the system and then turn it into an activity
diagram that focuses on the flow of control (you can also go from activity
diagrams to statechart diagrams).
• There are obvious practical limitations to illustrating something that's
inherently dynamic (the behavior of a system) using diagrams
(inherently static artifacts, especially when you draw them on a sheet
of paper, a whiteboard, or the back of an envelope).
• Rendered on a computer display, there are opportunities for
animating behavioral diagrams so that they either simulate an
executable system or mirror the actual behavior of a system that's
executing.
• The UML allows you to create dynamic diagrams and to use color or
other visual cues to "run" the diagram.
• Some tools have already demonstrated this advanced use of the UML.
• UML's behavioral diagrams are roughly organized around the major
ways you can model the dynamics of a system.

1.Use case diagram Organizes the behaviors of the system

2.Sequence diagram Focuses on the time ordering of messages
3.Collaboration diagram Focuses on the structural organization of
objects that send and receive messages
4.State diagram Focuses on the changing state of a system
driven by events
5.Activity diagram Focuses on the flow of control from activity to
activity
Modeling Different Views of a System
• 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.
• The five views of an architecture described earlier are a good starting
point.
• For each of these views, decide which artifacts you need to create to capture
the essential details of that view. For the most part, these artifacts will consist
of various UML diagrams.
• 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.
• These are the diagrams for which you'll want to schedule reviews and to
preserve as documentation for the project.
• Allow room for diagrams that are thrown away. Such transitory diagrams are
still useful for exploring the implications of your decisions and for
experimenting with changes.
• 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
Sequence diagrams
• Design view Class diagrams (for structural modeling)
Interaction diagrams (for behavioral modeling)
State diagrams (for behavioral modeling)
Activity diagrams
• Interaction view Interaction diagrams (for behavioral modeling)
• Implementation view Class diagrams
Composite structure diagrams
• Deployment view Deployment diagrams
Modeling Different Levels of Abstraction
• 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:

1. Building blocks and relationships: Hide those that are not relevant
to the intent of your diagram or the needs of your reader.

2. Adornments: Reveal only the adornments of these building blocks

and relationships that are essential to understanding your intent.

3. Flow: In the context of behavioral diagrams, expand only those

messages or transitions that are essential to understanding your
intent.

4. 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.
• 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:

1. Use cases and their realization: Use cases in a use case model
will trace to collaborations in a design model.

2. Collaborations and their realization: Collaborations will trace to

a society of classes that work together to carry out the
collaboration.

3. Components and their design: Components in an

implementation model will trace to the elements in a design model.

4. Nodes and their components: Nodes in a deployment model

will trace to components in an implementation model.
Higher Level Abstraction

Lower Level Abstraction

• Prepare a class diagram for the object diagram given.
Prepare a class diagram for the object diagram given.
• Multiplicity is a constraint on the size of a collection;
• Cardinality is the count of elements that are actually in a collection.
• Therefore, multiplicity is a constraint on the cardinality.
• To have two links between the same objects, you must have two
associations.
• The qualified model adds information.
• The qualified model adds a multiplicity constraint, that the
combination of a bank and an account number yields at most one
account.
• The qualified model conveys the significance of account number in
traversing the model.
• A stock exchange lists many companies.
• However, a stock exchange lists only one company with a given ticker
symbol.
• A company may be listed on many stock exchanges, possibly under
different symbols. (We are presuming this is true.
• If every stock had a single ticker symbol that was invariant across
exchanges, we would make tickerSymbol an attribute of Company.)
• The word written next to the generalization line in the diagram—
dimensionality—is a generalization set name.
• A generalization set name is an enumerated attribute that indicates
which aspect of an object is being abstracted by a particular
generalization.
• Generalize only one aspect at a time.
• The generalization set name is optional.
• Do not nest subclasses too deeply.
• Deeply nested subclasses can be difficult to understand, much like
deeply nested blocks of code in a procedural language.
• Often, with some careful thought and a little restructuring, reduce
the depth of an overextended inheritance hierarchy.
• In practice, whether or not a subclass is “too deeply nested”
depends upon judgment and the particular details of a problem.
The following guidelines may help:
An inheritance hierarchy that is two or three levels deep is certainly
acceptable; ten levels deep is probably excessive; five or six levels
may or may not be proper.