Oosd Unit 2

Object Oriented System Design (KCS-056)

UNIT – I & II
Object-Oriented
Object-oriented refers to a programming language, system or software methodology that is built on the concepts of
logical objects. These objects incorporate data structure and behavior.
The object-oriented technique is different from conventional programming, which focuses on functions/behaviors,
while object-oriented works on the interactions of one or more objects.
An object-oriented based system is modeled and created through the use of objects, where each object's class instance
has specific attributes and behaviors, and the relative methods or behaviors are called to manipulate or utilize such a
system. The essence of object-oriented is that each of the created objects can be reused in the same and other
programs and applications.
What is OOPS
• Break down requirement into objects.
• Built object hierarchies and interaction rather than program control flow.
• Easy to change the code according to the requirements.
Feature of OOPS
• Emphasis on data rather procedure.
• Programs are divided into units called “Objects”.
• Objects used to communicate with each other through functions.
• New functionality can be easily developed by creating objects and functions.
Benefits of object oriented programming (OOPs)
o Reusability: In OOP’s programs functions and modules that are written by a user can be reused by other users
without any modification.
o Inheritance: Through this we can eliminate redundant code and extend the use of existing classes.
o Data Hiding: The programmer can hide the data and functions in a class from other classes. It helps the
programmer to build the secure programs.
o Reduced complexity of a problem: The given problem can be viewed as a collection of different objects. Each object
is responsible for a specific task. The problem is solved by interfacing the objects. This technique reduces the
complexity of the program design.
o Easy to Maintain and Upgrade: OOP makes it easy to maintain and modify existing code as new objects
can be created with small differences to existing ones. Software complexity can be easily managed.
o Message Passing: The technique of message communication between objects makes the interface
with external systems easier.
o Modifiability: it is easy to make minor changes in the data representation or the procedures in an OO
program. Changes inside a class do not affect any other part of a program, since the only public interface that the
external world has to a class is through the use of methods.
There is the some dispute about exactly what characteristics (Principles) are required by an OO approach, but they
generally include:
o identity
o classification
o inheritance
o polymorphism
BRIJESH KUMAR VERMA 1

o Data abstraction
o Dynamic Binding
o Message passing
Object identity
An object is an instance of a class. Object identity is a fundamental object orientation concept. Identity is a property of
an object that distinguishes the object from all other objects in the application by their own inherent identity. In other
words, two objects are distinct even if all their attribute values (such as name and size) are identical. An object has an
existence which is independent of its value. Thus two notions of object equivalence exist: two objects can be identical
(they are the same object) or they can be equal (they have the same value). This has two implications: one is object
sharing and the other one is object updates.
Object sharing: Consider the following example: a Person has a name, an age and a set of children. Assume Peter
and Susan both have a 15-year-old child named John. In real life, two situations may arise: Susan and Peter are parent
of the same child or there are two children involved. In a system without identity, Peter is represented by:
(peter, 40, {(john, 15, {})})
and Susan is represented by:
(susan, 41, {(john, 15, {})}).
Thus, there is no way of expressing whether Peter and Susan are the parents of the same child. In an identity-based
model, these two structures can share the common part (john, 15, {}) or not, thus capturing either situations.
Object updates: assume that Peter and Susan are indeed parents of a child named John. In this case, all updates to
Susan's son will be applied to the object John and, consequently, also to Peter's son. In a value-based system, both sub-
objects must be updated separately.
Classification
Classification means that objects with the same data structure (attributes) and behavior (operations) are grouped in
to a class.
Class is a user defined data type, which holds its own data members and member functions, which can be accessed and
used by creating an instance of that class. A class is like a blueprint for an object.
For Example: Consider the Class of Cars. There may be many cars with different names and brand but all of them will
share some common properties like all of them will have 4 wheels, Speed Limit, Mileage range etc. So here, Car is the
class and wheels, speed limits, mileage are their properties.
• A Class is a user defined data-type which has data members and member functions.
• Data members are the data variables and member functions are the functions used to manipulate these variables and
together these data members and member functions defines the properties and behavior of the objects in a Class.
• In the above example of class Car, the data member will be speed limit, mileage etc and member functions can be
apply brakes, increase speed etc
Object : Anything that can be seen or touched is an object. Objects are everywhere around you. They may represent a
book, your computer, a place, a person, concepts or any item that the program has to deal with. Objects are basic
elements in an object-oriented system. They are also known as class instances, class objects or instance objects.
Object definition
Objects in programming are the basic run-time entities that contain the data and the functions which contain the code
to manipulate that data.
When a class is defined, no memory is allocated but when it is instantiated (i.e. an object is created) memory is
allocated.

A class is defined in C++ using keyword class followed by the name of class. The body of class is defined inside the
curly brackets and terminated by a semicolon at the end.
Encapsulation
For a computer novice, data hiding and data encapsulation might mean the same thing. However, there are major
differences between the two concepts.
Data encapsulation and data hiding both involve objects (classified as values, data, structures, or functions), classes
(collection of data and methods), the computer code, and methods.
In general, encapsulation is the inclusion of one thing within another thing so that the included thing is not apparent. In
normal terms Encapsulation is defined as wrapping up of data and information under a single unit.
Decapsulation is the removal or the making apparent a thing previously encapsulated.
Consider a real life example of encapsulation, in a company there are different sections like the accounts section,
finance section, sales section etc. The finance sections handle all the financial transactions and keep records of all the
data related to finance. Similarly the sales section handles all the sales related activities and keeps records of all the
sales. Now there may arise a situation when for some reason an official from finance section needs all the data about
sales in a particular month. In this case, he is not allowed to directly access the data of sales section. He will first have
to contact some other officer in the sales section and then request him to give the particular data. This is what
encapsulation is. Here the data of sales section and the employees that can manipulate them are wrapped under a
single name “sales section”.
The process of implementing encapsulation can be sub-divided into two steps:
1. The data members should be labeled as private using the private access specifiers
2. The member function which manipulates the data members should be labeled as public using the public access
specifier.
On the other hand, data hiding is the process of hiding the details of an object or function. It is also a potent
(important) technique in programming that result in data security and less data complexity.
The data inside is classified as private or non-accessible from other objects, classes, and API’s in the system. The
data appear as invisible to outsiders – whether objects, other classes, or users.
Data encapsulation is one of the chief mechanisms of data hiding. Data hiding works by nesting the data or
arranging it into capsules.
Data hiding has many uses, including:

• Security purposes and data protection from misuse and unauthorized access;
• Utilizing changing functions to move with difficulty from the outside;
• Hiding the data from unauthorized access or use by suspicious users, especially computer hackers who try to
manipulate sensitive data or the program;
• Hiding the physical storage layout for data and avoiding linking to incorrect data. (If a programmer does link to said
data, the program will display an error to protect the content.)

Summary
1. Data encapsulation is a process, while data hiding is both a process and a technique. They both share the category of
object-oriented programming.
2. The data in data encapsulation is either public or private, while the data in data hiding is private and non-accessible.
3. Data encapsulation is one of the mechanisms of data hiding.
4. Data encapsulation’s concern is for consolidation, which is related to data’s hiding goal of reaching less complexity in
data. On the other hand, data hiding encompasses not only less data complexity, but also data protection and security.
5. The focus of data encapsulation is on the data inside the capsule, while data hiding is concerned with restrictions on
terms of access and use.
Abstraction
Data abstraction is one of the most essential and important feature of object oriented programming in C++.
Abstraction means displaying only essential information and hiding the details. Data abstraction refers to providing
only essential information about the data to the outside world, hiding the background details or implementation.
Consider a real life example of a man driving a car. The man only knows that pressing the accelerators will
increase the speed of car or applying brakes will stop the car but he does not know about how on pressing accelerator
the speed is actually increasing, he does not know about the inner mechanism of the car or the implementation of
accelerator, brakes etc in the car. This is what abstraction is.
Access specifiers are the main pillar of implementing abstraction in C++. We can use access specifiers to enforce
restrictions on class members. For example:
• Members declared as public in a class, can be accessed from anywhere in the program.
• Members declared as private in a class, can be accessed only from within the class. They are not allowed to be
accessed from any part of code outside the class.
Polymorphism
Polymorphism (from the Greek meaning "having multiple forms") is the characteristic of being able to assign a different
meaning or usage to something in different contexts - specifically, to allow an entity such as a variable, a function, or
an object to have more than one form. In single statement objects are allowed to take on more than one form
depending on the context.
Real life example of polymorphism, a person at the same time can have different characteristic. Like a man at the
same time is a father, a husband, an employee. So the same person posses different behavior in different situations.
This is called polymorphism. Polymorphism is considered as one of the important features of Object Oriented
Programming.
In C++ polymorphism is mainly divided into two types:
• Compile time Polymorphism
• Runtime Polymorphism
Compile time polymorphism: This type of polymorphism is achieved by function overloading or operator overloading.
Runtime polymorphism: This type of polymorphism is achieved by Function Overriding.
Inheritance: Inheritance is the process by which one object can acquire the properties of another class.
When the class child, inherits the class parent, the class child is referred to as derived class (sub class) and the class
parent as a base class (super class). In this case, the class child has two parts: a derived part and an incremental part.
The derived part is inherited from the class parent. The incremental part is the new code written specifically for the
class child.
Dynamic binding and Static binding:
Binding generally refers to a mapping of one thing to another. In the context of compiled languages, binding is the link
between a function call and the function definition. There are two types of binding in C++:
• Static (or early/ compile time) binding
• Dynamic (or late/run time ) binding

1. The static binding happens at the compile – time and dynamic binding happens at the run time. Hence, they are also
called early and late binding respectively.
2. In the static binding, the function definition and function call are linked during the compile-time whereas in dynamic
binding the function call is linked during the run time.
3. Static binding can achieved using the normal functions calls, function overloading and operator overloading while
dynamic binding can achieved using the virtual functions.
4. Since all information needed to call a function is available before runtime, static binding results in faster execution of a
program. Unlike static binding, a function call is not resolved until runtime for later binding and this result in somewhat
slower execution of code.
5. The major advantage of dynamic binding is that it is flexible since a single function can handle different type of objects
at run time. This significantly reduces the size of the code base and also makes the source code more readable.
Dynamic binding is an object oriented programming concept and it is related with polymorphism and inheritance.
Message passing:
An object oriented program consists of set of object that communicates with each other. Objects communicate with
each other by sending and receiving information.
Messages for an object are a request for execution of a procedure and therefore invoke the function that is called for
an object and generates result
• Modeling:
A model is a simplification of reality. A model provides the blueprints of a system. A model may be structural,
emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.
“Object-oriented modeling is the process of preparing and designing what the model’s code will actually look like.”
Important of modeling
We build models so that we can better understand the system we are developing.
Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.
We build models of complex systems because we cannot comprehend such a system in its entirety. We build model so
that we can better understand the system we are developing. A model may encompass an overview of the system
under consideration, as well as a detailed planning for system design, implementation and testing.

Principles of Modeling
1. The choice of model is important
The choice of what models to create has a profound influence on how a problem is attacked and how a solution is
shaped. We need to choose your models well.
• The right models will highlight the most critical development problems.
• Wrong models will mislead you, causing you to focus on irrelevant issues.
For Example: We can use different types of diagrams for different phases in software development.
2. Every model may be expressed at different levels of precision

For Example,
• If you are building a high rise, sometimes you need a 30,000-foot view for instance, to help your investors visualize its
look and feel.
• Other times, you need to get down to the level of the studs for instance, when there's a tricky pipe run or an unusual
structural element.
3. The best models are connected to reality
All models simplify reality and a good model reflects important key characteristics.
4. No single model is sufficient
Every non-trivial system is best approached through a small set of nearly independent models. Create models that can
be built and studied separately, but are still interrelated. In the case of a building:
• You can study electrical plans in isolation
• But you can also see their mapping to the floor plan and perhaps even their interaction with the routing of pipes in the
plumbing plan.
Object Oriented Modeling
Object-oriented modeling (OOM) is an approach to modeling an application that is used at the beginning of the
software development life cycle when using an object-oriented approach to software development.
Object oriented modeling is entirely a new way of thinking about problems. This methodology is all about
visualizing the things by using models organized around real world concepts. Object oriented models help in
understanding problems, communicating with experts from a distance, modeling enterprises, and designing programs
and database. We all can agree that developing a model for a software system, prior to its development or
transformation, is as essential as having a blueprint for large building essential for its construction. Object oriented
models are represented by diagrams. A good model always helps communication among project teams, and to assure
architectural soundness.

In software, there are several ways to approach a model. The two most common ways are
1. Algorithmic perspective
2. Object-oriented perspective
1. Algorithmic Perspective
The traditional view of software development takes an algorithmic perspective. In this approach, the main building
block of all software is the procedure or function. This view leads developers to focus on issues of control and the
decomposition of larger algorithms into smaller ones. As requirements change and the system grows, systems built
with an algorithmic focus turn out to be very hard to maintain.
2. Object-oriented perspective
The contemporary view of software development takes an object-oriented perspective. In this approach, the main
building block of all software systems is the object or class. A class is a description of a set of common objects. Every
object has identity, state, and behavior. Object-oriented development provides the conceptual foundation for
assembling systems out of components using technology such as Java Beans or COM+.
• Introduction to Unified Modeling Language (UML)
UML is a visual modeling language
“A picture is worth a thousand words.” - Old saying
The Unified Modeling Language is a standard language for writing software blueprints (Blue print of source code). The
UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive system as well as
for business modeling and other non-software systems.
The UML is appropriate for modeling systems ranging from enterprise information systems to distributed Web-based
applications and even to hard real time embedded systems. It is a very expressive language, addressing all the views
needed to develop and then deploy such systems.
The UML is a very important part of developing objects oriented software and the software development process. The
UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the architectural design of the software.
The UML is a language for
o Visualizing
o Specifying
o Constructing
o Documenting
Visualizing The UML is more than just a bunch of graphical symbols. Rather, behind each symbol in the UML notation is
a well-defined semantics. In this manner, one developer can write a model in the UML, and another developer, or even
another tool, can interpret that model unambiguously
Specifying means building models that are precise, unambiguous, and complete.
Constructing the UML is not a visual programming language, but its models can be directly connected to a variety of
programming languages
Documenting a healthy software organization produces all sorts of artifacts in addition to raw executable code. These
artifacts include
1. Requirements 2.Architecture 3.Design 4.Source code 5.Project plans
6. Tests 7.Prototypes 8.Releases

Why UML
As the strategic value of software increases for many companies, the industry looks for techniques to automate the
production of software and to improve quality and reduce cost and time-to-market. These techniques include
component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the
complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring
architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault
tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated
these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs. The
primary goals in the design of the UML summarize by Page-Jones in Fundamental Object-Oriented Design in UML as
follows:
1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful
models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks, patterns and components.
7. Integrate best practices
Conceptual Model of UML
To understand the UML, you need to form a conceptual model of the language, and this requires learning
three major elements: 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.
1. Building blocks of UML
These are the fundamental elements in UML. Every diagram can be represented using these building blocks. The

building block of UML contains three types of elements. They are:

1) Things (object oriented parts of uml)
2) Relationships (relational parts of uml)
3) Diagrams
1.1 Things
A diagram can be viewed as a graph containing vertices and edges. In UML, vertices are replaced by things, and the
edges are replaced by relationships. There are four types of things in UML. They are:
1) Structural things (nouns of uml – static parts)
2) Behavioral things (verbs of uml – dynamic parts)
3) Grouping things (organizational parts)
4) Annotational things (explanatory parts)
1.1.1 Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are ither conceptual or physical. Collectively, the structural things are called classifiers. In
all, there are seven kinds of structural things.
1. Classes
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes
Class: A class is a collection of similar objects having similar attributes, behavior, relationships and semantics.
Graphically class is represented as a rectangle with three compartments.
Graphical representation:
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. At a given moment, an object of a class will
have specific values for every one of its class's attributes.
An operation is the implementation of a service that can be requested from any object of the class to affect behavior. A
class may have any number of operations or no operations at all.
Example :

Interface
Interface is a collection of operations that specify a service of a class or component. An interface therefore describes
the externally visible behavior of that element. An interface is rendered as a circle together with its name. An interface
rarely stands alone. Rather, it is typically attached to the class or component that realizes the interface.
An interface provided by a class to the

outside world is shown as a small circle Provided interface (circle shape) Required interface (socket shape)
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 in
Figure
Collaboration:
Collaboration is the collection of UML building blocks (classes, interfaces, relationships) that work together to provide
some functionality within the system. Graphically collaboration is represented as a dashed ellipse.

Use Cases:
A use case is a collection of actions, defining the interactions between a role (actor) and the system. Graphically use
case is represented as a solid ellipse with its name written inside the ellipse.
Graphical representation: A Simple example
Active classes:
a class whose instance is an active object; an active object is an object that owns a process or thread (units
of execution). Graphically, an active class is rendered as a class with double lines on the left and right; in another
notation with heavy lines, usually including its name, attributes, and operations it usually includes its name, attributes,
and operations, as in Figure
Components:
A component is a physical and replaceable part of a system. Graphically component is represented as a tabbed
rectangle. Examples of components are executable files, dll files, database tables, files and documents.
Example: Orderform.java
Nodes:
A physical element that exists at run-time and represents a computational resource (typically, hardware
resources).
Graphical representation: Example:
1.1.2 Behavioral Things are the dynamic parts of UML models. These are the verbs of a model, representing
behavior over time and space. In all, there are two primary kinds of behavioral things
1.Interaction
2. State machine (as a sequence of state changes)
Interaction: A behavior made up of a set of messages exchanged among a set of objects to perform a particular task. A
message is represented as a solid arrow. Below is an example of interaction representing a phone conversation:

State Machine: A behavior that specifies the sequences of states an object or interaction goes through during its’
lifetime in response to events. A state is represented as a rectangle with rounded corners. Below is an example of state
machine representing the states of a phone system:
1.1.3 Grouping Things

1. are the organizational parts of UML models. These are the boxes into which a model can be decomposed
2. There is one primary kind of grouping thing, namely, packages.
Package:-
• A package is a general-purpose mechanism for organizing elements into groups. Structural things, behavioral
things, and even other grouping things may be placed in a package
• Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its
contents

Example
1.1.4 Annotational things are the explanatory parts of UML models. These are the comments you may apply to
describe about any element in a model. A note is simply a symbol for rendering constraints and comments attached to
an element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared corner, together
with a textual or graphical comment
1.2 Relationships
The things in a diagram are connected through relationships. So, a relationship is a connection between two or more
things.
Relationships in the UML are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
1.2.1 Dependency: Dependency is a semantic relationship between two things in which a change to one
thing (the independent thing) may affect the semantics of the other thing (the dependent thing). Graphically
a dependency is rendered as a dashed line, possibly directed, and occasionally including a label.
Notation:
(Arrow-head points to the independent thing)
1.2.2 Association: An association describes a group of links with common structure and common semantics.
A link being a connection among objects. Graphically an association is rendered as a solid line, possibly directed,
occasionally including a label, and often containing other adornments, such as multiplicity and role names. Given an
association connecting two classes, you can navigate from an object of one class to an object of the other class, and
vice versa.

Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be unary, binary, or
ternary.
• A unary/self Association (relationship) connects objects of the same class.
• A binary Association (relationship) connects objects of two classes.
• A ternary relationship(N-ary Association) connects objects of three or more classes.
Cardinality Ratios of Associations
Cardinality of an association denotes the number of instances participating in an association. There are three types of
cardinality ratios, namely
• One–to–One − A single object of class A is associated with a single object of class B.
• One–to–Many − A single object of class A is associated with many objects of class B.
• Many–to–Many − An object of class A may be associated with many objects of class B and conversely an object of class
B may be associated with many objects of class A.
Name: An association can have a name, and you use that name to describe the nature of the relationship.
Role: When a class participates in an association, it has a specific role that it plays in that
relationship. In Figure, a Person playing the role of employee is associated with a Company playing the role of
employer.
Multiplicity specifies how many objects (instances of one class) may relate to a single instance of an associated class.
Multiplicity constraints can only be used with binary associations. This "how many" is called the multiplicity of an
association's role, and is written as an expression that evaluates to a range of values or an explicit value as in Fig.
When you state a multiplicity at one end of an association, you are specifying that, for each object of the class at the
opposite end, there must be that many objects at the near end. You can show a multiplicity of exactly one (1), zero or
one (0..1), many (0..*), or
one or more (1..*). You can even state an exact number (for example, 3, which is equivalent to 3..3).

Multiplicity Option Cardinality

0..0 0 Collection must be empty
0..1 No instances or one instance
1..1 1 Exactly one instance
0..* * Zero or more instances
1..* At least one instance
5..5 5 Exactly 5 instances
m..n At least m but no more than n instances
1.2.2.1 Aggregation is an aggregation relationship can be described in simple words as ”Aggregation is a

way of composing different abstractions together in defining a class. 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. Direction between them
specified which object contains the other object. An aggregation describes a group of objects and how you interact
with them. Aggregation implies a relationship where the child can exist independently of the parent. Example: Class
(parent) and Student (child). Delete the Class and the Students still exist.
Aggregation is a special form of association. Composition is a special form of aggregation

For example, a car class can be defined to contain other classes such as engine class, seat class, wheels class etc.
A car object is an aggregation of engine, seat, wheels and other objects.
Example
A single Employee can not belong to multiple Companies (legally!!), but if we delete the Company, Employee object
will not destroy.
1.2.2.2 Composition when one class owns other class and other class cannot meaningfully exist, when it's
owner destroyed, for example, Human class is a composition of several body parts including Hand, Leg and Heart.
When human object dies, all it's body part ceased to exist meaningfully, this is one example of Composition.
Example
House can contain multiple rooms there is no independent life for room and any room can not belong to two different
house. If we delete the house room will also be automatically deleted.

1.2.3 Generalization:
A generalization is a relationship between a class and one or more refined versions of that class. Generalization is
transitive.
In other word a relationship between a general thing (called “parent” or “superclass”) and a more specific kind of that
thing (called the “child” or “subclass”), such that the latter can substitute the former. Also known as “is-a” relationship.
Generalization is a mechanism for combining similar classes of objects into a single, more general class.

Specialization is the reverse process of Generalization means creating new sub classes from an existing class.
1.2.4 Realization:
Defines a semantic relationship in which one class specifies something that another class will perform. In a realization
relationship of UML, one entity denotes some responsibility which is not implemented by itself and the other entity
that implements them. This relationship is mostly found in the case of interfaces.
1.3 Diagram in the UML

Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices
(things) and arcs (relationships). In theory, a diagram may contain any combination of things and relationships.
For this reason, the UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram

8. Component diagram
9. Deployment diagram
Class 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 are the main building block of any
object-oriented solution. Class diagrams address the static design view of a system.
Terms and Concepts
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.
Contents
Class diagrams commonly contain the following things:
· Classes
· Interfaces
· Collaborations
· Dependency, generalization, and association relationships
The class BankAccount, for example, will define attributes such as account No and balance.
The operations defined for the BankAccount class could include functions such as returnBalance () or updateBalance
().
Minus sign ("-") in front of the attribute name indicates that these attributes are private.
The operations have a plus sign ("+") in front of them showing that they are public.
The notion of classifying UML class attributes and operations as either private or public reflects the way in which class
variables and methods in object oriented programming languages are declared.
Naming conventions used here. If a class, attribute or operation has a name that contains more than one word, there
is no space between the words. The name of the class has a capital letter at the start of each word it contains. For
attribute and operation names however, the first word should always start with a lower-case letter. The name of an
operation is followed by a pair of parentheses.
A class diagram usually includes a number of class icons, connected together by lines that indicate the type of
relationship that exists between the interconnected classes. They provide a static view of the system, because although

they show the relationships between the various classes they provide no information about what actually happens
when these classes interact.
class diagrams are a useful tool for enabling analysts to explain the system to clients. By the same token, they are also
useful for enabling clients to discuss the problem domain with analysts. Once completed, they will form a design
blueprint that can be used by programmers to create the application’s data structures and program logic.
Attributes: The attributes of a class (assuming there are any) are listed in the middle rectangle of the class icon, and
represent some item of data that can be recorded about an instance of the class. An instance of the
class BankAccount will have a unique account number, and an account balance that will vary over time.
UML allows you to specify the data type for an attribute (e.g. string, integer, floating-point, Boolean etc.), and an initial
default value. Below is a modified version of the BankAccount class that demonstrates the principle.
We should at some point therefore specify the data type that is to be used for these attributes. This is a good example
of how software designers can communicate their requirements very precisely to programmers.
Associations: We can draw lines to connect the various classes together in order to show the relationships that exist
between the various classes. These connections, when they appear on class diagrams, are usually referred to
as associations. The connecting line may have an arrowhead at one end to indicate which way the association works,
and a label that provides a name or brief description of the relationship. If no arrowhead is present, the association is
assumed to be bi-directional.
The multiplicity of an association may also be shown on a class diagram. The multiplicity of a relationship
essentially tells us whether the relationship between two classes is a one-to-one, one-to-many, or many-to-
many relationship. In the case of a one-to-many relationship, the notation used must tell us which end of the
association represents the one and which end represents the many. Below is part of the simple bank system class
diagram.
The association between the BankAccount and Transaction classes has a one-to-zero-or-more relationship. From the
point of view of our system, a transaction can only relate to one account. When the bank account is first opened, there
will be zero transactions, so at that point in time we have a one-to-zero situation (one bank account, zero transactions).
Over time, however, we can expect a number of transactions to be made. Even if the account is closed again

immediately after it is opened (unlikely as that might seem), the multiplicity holds true because it allows for zero
transactions.
The association between the Customer and BankAccount classes is characterized by a one-to-one-or-more
relationship. A bank account can only belong to one customer. A customer, on the other hand, might have several
accounts (e.g. current account, savings account, business account, and so on).
At the BankAccount end of the association, the multiplicity is going to be one-or-more rather than zero-or-
more. This is because, due to the nature of a bank, a customer is not a customer until they have opened some kind of
account.
Generalization and inheritance In the UML, the word generalizations used instead of inheritance, but it means more or
less the same thing, which is that one class can be a sub-class, or child class, of another class (the parent class). The
child class will have a different name, but inherits all of the characteristics of the parent class including its attributes
and operations.
You can see from the diagram that the classes CurrentAccount and SavingsAccount are both children of
the BankAccount class. A class that is used purely as a generalization from which to derive other (child) classes, and
which is not used to create objects (instances) in its own right, is called an abstract class.
Purpose of Class Diagrams

1. Describing the static structure of a system
2. Showing the collaboration among the elements of the static view.
3. Proper design and analysis of application can be faster and efficient.
4. Describing the functionalities performed by the system.
5. Helpful for developers and other team members too, to Analysis and design of the static view of an application.
6. Construction of software applications using object oriented languages.
Object Diagram:
Objects are the real-world entities whose behavior is defined by the classes. Objects are used to represent the static
view of an object-oriented system but this static view is a snapshot of the system at a particular moment. We cannot
define an object without its class. Object diagrams are derived from class diagrams so object diagrams are dependent
upon class diagrams.
“Object diagrams describe the static structure of a system at a particular time. It shows a complete or partial
view of the structure of a modeled system at a specific time. They can be used to test class diagrams for accuracy.”
An object diagram describes the instance of a class diagram. It visualizes the particular functionality of a
system.
Both class diagrams and object diagrams represent a static, structural view of a system. Object diagrams are not
frequently used, but they can sometimes be useful for demonstrating the way in which objects interact in a system "at
run time".

Terms and Concepts

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.
Contents : Object diagrams commonly contain
· Objects · Links
Class vs. Object Diagrams
S. Class Object
no.
1 It represents static aspects of a system. It represents the behavior of a system in real
time.
2 It doesn't include dynamic changes. It captures runtime changes of a system.
3 It never includes attributes or data values of an It includes attributes and data values of any
instance. instance.
4 Class diagram manipulates the behavior of Objects are instances of classes.
objects.
A class icon represents all of the instances of a particular class that exist, have existed, or ever will exist in a system; an
object icon represents exactly one instance of a class at one particular moment in time. The illustration below shows
the difference between how a class icon, and its instantiation as an object, are represented in the UML.
The name of the object is underlined to show that it is an object. It is also the convention to add the name of the class
of which the object is an instance, following the name of the object and separated from it by a colon. In our example
we have "HartleyJR : BankAccount", which indicates an object of type BankAccount with the name "HarleyJR" (note
that the names of objects normally start with a lower case character).
The icon shows the details of the first object, with additional objects being implied by the addition of a second
rectangle drawn in such a fashion that it appears to be behind the first.
An icon representing several objects of type BankAccount

The connection between two objects on an object diagram is called a link. A link is represented by a solid line between
two object icons. The difference between a link and an association is that a link connects two objects, rather than two
classes. The object diagram below tells us that an object named "HartleyJR" of type Customer is linked with both an
object named "HartleyJR" of type SavingsAccount and an object named "HartleyJR" of type CurrentAccount

An object diagram with linked objects
A class diagram for a college information system

This diagram tells us the following things:
• The college is an aggregation of one or more faculties, and a faculty can only belong to one college.
• Each faculty is an aggregation of one or more departments, and a department may only belong to one faculty.
• Each department is an aggregation of a number of lecturers, and a lecturer may only belong to one department.
• Each faculty administers one or more courses, and a course may only be administered by one faculty.
• Each department administers one or more modules, and a module may only be administered by one department.
• Each course is an aggregation of one or more modules, and a module may belong to one or more courses.
• Each course may have zero or more students enrolled on it, but a student must be enrolled on one (and only
one) course
The class diagram does in fact tell us quite a lot, but there may be questions that haven't been answered. One obvious
question here revolves around modules, because it would seem that a module could be a part of a number of courses.
Faculties are split into departments, and it is the departments that have responsibility for administering the modules,
whereas the courses are administered by the faculties. Does this mean that a module that is administered by a
department of one faculty might be included on a course run by another faculty? The implication is that this is indeed
possible, but some concrete examples would be nice. Let's look at an object diagram that provides such an example.

An object diagram representing part of a college information system
The object diagram shown above is designed to highlight the fact that a single course (in this case "Computing and
Informatics") is administered by the Faculty of Technology, and includes a number of modules administered by
the Computing department (as you might expect, given the title of the course). It also tells us that the course includes
modules administered by both the Management department and the Finance department, both of which are in turn
administered by the Faculty of Business Studies.
Object diagrams can be used to highlight all kinds of situations that can arise at some moment in the life of an
information system, at an arbitrary level of detail (the level of detail shown on an object diagram should only be as
much as is necessary to make the point we are trying to make). They are useful for helping stakeholders to understand
a class diagram, or for showing a client how part of the system is supposed to work in a given scenario. They are not as
a rule used by system designers or programmers to design an application or write program code (class diagrams are far
better suited for that purpose).
Use Case Diagram: Terms and Concepts
A use case diagram at its simplest is a representation of a user's interaction with the system that shows the relationship
between the user and the different use cases in which the user is involved. a use-case diagram can help provide a
higher-level view of the system. They provide the simplified and graphical representation of what the system must
actually does (i.e. its functionality), not how it does it.
Contents
Use case diagrams commonly contain
· Use cases
· Actors
· Dependency, generalization, and association relationships
The elements of a use case diagram include:
• use cases - Draw use cases using ovals and specific pieces of the system's functionality

• actors - people or things(users of the system) that interact with the system's use cases
• Relationships - used to link actors with the use cases they interact with
• System boundary - defines what functionality is included within the system. Draw your system's boundaries using a
rectangle that contains use cases. Place actors outside the system's boundaries.
• Include - An include relationship specifies how the behavior for the

inclusion use case is inserted into the behavior defined for the base use case.
An include relationship defines that a use case contains the behavior defined in
another use case.
• Extend - An extend relationship specifies how the behavior of
the extension use case can be inserted into the behavior defined for
the base use case.
How to draw a use-case diagram?
To draw a use case diagram in UML first one need to analyze the entire system carefully. You have to find out every
single function that is provided by the system. After all the functionalities of a system are found out, then these
functionalities are converted into various use cases which will be used in the use case diagram.
After organizing the use cases, we have to enlist the various actors or things that are going to interact with the
system. These actors are responsible for invoking the functionality of a system. Actors can be a person or a thing.
After the actors and use cases are enlisted, then you have to explore the relationship of a particular actor with the
use case or a system. One must identify the total number of ways an actor could interact with the system. A single
actor can interact with multiple use cases at the same time, or it can interact with numerous use cases simultaneously.
Following rules must be followed while drawing use-case for any system:
1. The name of an actor or a use case must be meaningful and relevant to the system.
2. Interaction of an actor with the use case must be defined clearly and in an understandable way.
3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant interactions must be displayed.
An example of a use-case diagrams following use case diagram represents the working of the student management
system:

In the above use case diagram, there are two actors named student and a teacher. There are a total of five use cases
that represent the specific functionality of a student management system. Each actor interacts with a particular use
case. A student actor can check attendance, timetable as well as test marks on the application or a system. This actor
can perform only these interactions with the system even though other use cases are remaining in the system.
It is not necessary that each actor should interact with all the use cases, but it can happen.
The second actor named teacher can interact with all the functionalities or use cases of the system. This actor
can also update the attendance of a student and marks of the student. These interactions of both student and a
teacher actor together sum up the entire student management application.
In general use case diagrams are used for:
The primary purpose of a use case diagram is to describe the behavior of a system from the user's point of view. Use
case diagrams capture the dynamic behaviour of a live system. It models how an external entity interacts with the
system to make it work. Use case diagrams are responsible for visualizing the external things that interact with the part
of the system.
• Analyzing the requirements of a system
• High-level visual software designing
Interaction Diagram: Terms and concepts

An interaction is defined as a behavior that consists of a group of messages exchanged among elements of
accomplishing a specific task in the system. Interaction diagrams capture the dynamic behavior of any system. This
interactive behavior is represented in UML by two diagrams known as Sequence diagram and Collaboration diagram.
The basic purpose of both the diagrams is similar. The collaboration diagram is also called as a communication diagram.
The sequence diagram shows the interaction between two lifelines as a time-ordered sequence of events. i.e. Time
oriented view of object interaction.
The purpose of a collaboration diagram is to emphasize structural view of messaging objects i.e., how various lifelines
in the system connect.

Contents
Interaction diagrams commonly contain
· Objects
· Links
· Messages
Sequence Diagram:
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order in which these
interactions take place. A sequence diagram is a type of interaction diagram because it describes how—and in what
order—a group of objects works together. We can also use the terms event diagrams or event scenarios to refer to a
sequence diagram. These diagrams are widely used by businessmen and software developers to document and
understand requirements for new and existing systems.
Basic Sequence Diagram Notations
• Class Roles or Participants- Class roles describe the way an object will behave in context. Use the UML object symbol
to illustrate class roles, but don't list object attributes.
• Activation or Execution Occurrence: Activation boxes represent the time

an object needs to complete a task. A thin rectangle on a lifeline represents the
period during which an element is performing an operation.
• Lifeline Notation: Lifelines are vertical dashed lines that indicate the
object's presence over time. A sequence diagram is made up of several of these
lifeline Notations that should be arranged horizontally across the top of the diagram.
No two lifeline notations should overlap each other. They represent the different
objects or parts that interact with each other in the system during the sequence.
I. A lifeline represents an individual participant in the Interaction.
• Actor
It Shows entities that interact with or are external to the system. It represents roles
played by human users, external hardware, or other subjects.
I. An actor does not necessarily represent a specific physical entity but merely a
particular role of some entity
II. A person may play the role of several different actors and, conversely, a given
actor may be played by multiple different person.

• Call Message is a kind of message that represents an invocation of operation of target lifeline.
• Return Message is a kind of message that represents the pass of information back to the caller of a corresponded
former message.
• Self Message is a kind of message that represents the invocation of message of the same lifeline.
• Create Message is a kind of message that represents the instantiation of (target) lifeline.
• Destroy Message is a kind of message that represents the request of destroying the lifecycle of target lifeline.
• Duration Message shows the distance between two time instants for a message invocation.
• Note A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force,
but may contain information that is useful to a modeler.
• Found Message A message sent from an unknown recipient, shown by an arrow from an endpoint to a lifeline.
• Lost Message A message sent to an unknown recipient. It's shown by an arrow going from a lifeline to an endpoint, a
filled circle or an x.

How to Draw a Sequence Diagram

A sequence diagram represents the scenario or flow of events in one single use case. The message flow of the
sequence diagram is based on the narrative of the particular use case.
Then, before you start drawing the sequence diagram or decide what interactions should be included in it, you
need to draw the use case diagram and ready a comprehensive description of what the particular use case does.
From the above use case diagram example of ‘Create New Online Library Account’, we will focus on the use case
named ‘Create New User Account’ to draw our sequence diagram example.
Before drawing the sequence diagram, it’s necessary to identify the objects or actors that would be involved in creating
a new user account. These would be;
I. Librarian
II. Online Library Management system
III. User credentials database
IV. Email system
Once you identify the objects, it is then important to write a detailed description on what the use case does. From this
description, you can easily figure out the interactions (that should go in the sequence diagram) that would occur
between the objects above, once the use case is executed.
Here are the steps that occur in the use case named ‘Create New Library User Account’.
• The librarian request the system to create a new online library account
• The librarian then selects the library user account type
• The librarian enters the user’s details
• The user’s details are checked using the user Credentials Database
• The new library user account is created
• A summary of the of the new account’s details are then emailed to the user
From each of these steps, you can easily specify what messages should be exchanged between the objects in the
sequence diagram. Once it’s clear, you can go ahead and start drawing the sequence diagram.
The sequence diagram below shows how the objects in the online library management system interact with each other
to perform the function ‘Create New Library User Account’.


Benefits of sequence diagrams

Sequence diagrams can be useful references for businesses and other organizations. Try drawing a sequence diagram
to:
• Represent the details of a UML use case.
• Model the logic of a sophisticated procedure, function, or operation.
• See how objects and components interact with each other to complete a process.
• Plan and understand the detailed functionality of an existing or future scenario.
Collaboration Diagram:
A collaboration diagram is a type of visual presentation that shows how various software objects interact with each
other within the system. This is difficult to determine from a sequence diagram.

State Chart Diagram

A state diagram, also known as a state machine diagram or state chart diagram, is an illustration of the states
an object can attain as well as the transitions between those states in the Unified Modeling Language (UML). In this
context, a state defines a stage in the evolution or behavior of an object, which is a specific entity in a program or the
unit of code representing that entity.
What is the Difference between a State Diagram and a Flowchart?
A flowchart illustrates processes that are executed in the system that change the state of objects. A state diagram
shows the actual changes in state, not the processes or commands that created those changes.
Basic components of a state chart diagram –
Initial state – We use a black filled circle represent the initial state of a System or a class.
State – We use a rounded rectangle to represent a state. A state represents the conditions or circumstances of an
object of a class at an instant of time.
Transition - We use a solid arrow to represent the transition or change of control from one state to another. The arrow
is labelled with the event which causes the change in state.
Self transition – We use a solid arrow pointing back to the state itself to represent a self transition. There might be
scenarios when the state of the object does not change upon the occurrence of an event. We use self transitions to
represent such cases.
Final State - An arrow pointing to a filled circle nested inside another circle represents the object's final state.
Fork – We use a rounded solid rectangular bar to represent a Fork notation with
incoming arrow from the parent state and outgoing arrows towards the newly
created states. We use the fork notation to represent a state splitting into two
or more concurrent states.
Join – We use a rounded solid rectangular bar to represent a Join notation
with incoming arrows from the joining states and outgoing arrow towards
the common goal state. We use the join notation when two or more states
concurrently converge into one on the occurrence of an event or events.

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary values corresponding to different attributes guide
us in identifying different states).
3. Label the events which trigger these transitions.
Activity Diagram: An activity diagram visually presents a series of actions or flow of control from activity to activity in a
system similar to flowchart or a data flow diagram. Activity diagrams are often used in business process modeling.
You use activity diagrams to model the dynamic aspects of a system. For the most part, this involves modeling the
sequential (and possibly concurrent) steps in a computational process. It is also called object-oriented flowchart.Most
similar to state diagram)
Terms and Concepts
An activity diagram shows the flow from activity to activity. An is an ongoing nonatomic execution within a state
machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in
a change in state of the system or the return of a value. Graphically, an activity diagram is a collection of vertices and
arcs.
Some of the most common components of an activity diagram include:
• Action: A step in the activity wherein the users or software perform a given task. Actions are symbolized with round-
edged rectangles.
• Decision node: A conditional branch in the flow that is represented by a diamond. It includes a single input and two or
more outputs.
• Control flows: Another name for the connectors that show the flow between steps in the diagram.
• Start node: Symbolizes the beginning of the activity. The start node is represented by a black circle.

• End node: Represents the final step in the activity. The end node is represented by an outlined black circle.
A fork and join mode used together are often referred to as synchronization.
Activity diagram for a login page
Component diagram - Component diagrams are different in terms of nature and behavior. Component diagrams are
used to model the physical aspects of a system. Physical aspects are the elements such as executables, libraries, files,
documents, etc. which reside in a node.
A component is a replaceable and executable piece of a system whose implementation details are hidden. A
component provides the set of interfaces that a component realizes or implements. Components also require
interfaces to carry out a function.
Interface -An interface (small circle or semi-circle on a stick) describes a group of operations used (required) or created
(provided) by components. A full circle represents an interface created or provided by the component. A semi-circle
represents a required interface, like a person's input.

Dependencies -Draw dependencies among components using dashed arrows.
Port - Ports are represented using a square along the edge of the system or a component. A port is often used to help
expose required and provided interfaces of a component.
How to draw a component diagram

A component is nothing but an executable piece of a system. Various components together make a single system.
Component diagrams are used widely during the execution phase of any system.
Before modeling the component diagram, one must know all the components within the system. The working of each
component should be mentioned. Component diagrams are used to analyze the execution of a system.
One should also explore each component in depth to understand the connection of a component to other physical
artifacts in the system.
The relationship amongst various artifacts, libraries, and files are the essential things required during modeling of a
component diagram.
The purpose of the component diagram can be summarized as −
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
Example

Terms and Concepts

A component diagram shows a set of components and their relationships. Graphically, a component diagram is a
collection of vertices and arcs.
Common Properties
A component diagram is just a special kind of diagram and shares the same common properties as do all other
diagrams• a name and graphical contents that are a projection into a model. What distinguishes a component diagram
from all other kinds of diagrams is its particular content.
Contents
Component diagrams commonly contain
· Components
· Interfaces
· Dependency, generalization, association, and realization relationship
Deployment diagram
A deployment diagram, models the run-time architecture of a system. It shows the configuration of the hardware
elements (nodes) and shows how software elements and artifacts are mapped onto those nodes.
Deployment diagram elements: A variety of shapes make up deployment diagrams.
• Artifact: A product developed by the software, symbolized by a rectangle with the name and the word “artifact”
enclosed by double arrows.
• Association: A line that indicates a message or other type of communication between nodes.
• Component: A rectangle with two tabs that indicates a software element.

• Dependency: A dashed line that ends in an arrow, which indicates that one node or component is dependent on
another.
• Interface: A circle that indicates a contractual relationship. Those objects that realize the interface must complete
some sort of obligation.
• Node: A hardware or software object, shown by a three-dimensional box.
• Node as container: A node that contains another node inside of it—such as in the example below, where the nodes
contain components.

• Stereotype: A device, artifacts contained within the node, presented at the top of the node, with the name bracketed
by double arrows.
Terms and Concepts
A deployment diagram is a diagram that shows the configuration of run time processing nodes and the
components that live on them. Graphically, a deployment diagram is a collection of vertices and arcs.
Common Properties
A deployment diagram is just a special kind of diagram and shares the same common properties as all other diagrams•
a name and graphical contents that are a projection into a model. What distinguishes a deployment diagram from all
other kinds of diagrams is its particular content.
Contents
Deployment diagrams commonly contain
· Nodes
· Dependency and association relationships
When to Use Deployment Diagram
• What existing systems will the newly added system need to interact or integrate with?
• How robust does system need to be (e.g., redundant hardware in case of a system failure)?
• What and who will connect to or interact with system, and how will they do it
• What middleware, including the operating system and communications approaches and protocols, will system use?
• What hardware and software will users directly interact with (PCs, network computers, browsers, etc.)?
• How will you monitor the system once deployed?
• How secure does the system needs to be (needs a firewall, physically secure hardware, etc.)?

Rule: It is an accepted instruction that states the way things are or should be done, and tells you what you
are allowed or are not allowed to do. The UML has a number of rules that specify what a well-formed model should
look like. The UML rules for Names, Scope, Visibility, Integrity and Execution. The UML has semantic rules for
1. Name: What you can call things, relationships, and diagrams
2. Scope: The scope of a feature specifies whether each instance of the classifier has its own distinct value of the
feature
or whether there is just a single value of the feature shared by all instances of the classifier.
3. Visibility: How those names can be seen and used by others (types of visibility – public [+], protected [#], private
[-],
package [~]).
4. Integrity: How things properly and consistently relate to one another
5. Execution: What it means to run or simulate a dynamic model.
Common Mechanisms: It a system of parts working together in a system for particular task.
The UML is made simpler by the presence of four common mechanisms that apply consistently throughout the
language:
• notes
a. specificatins
b. adornments
• common divisions
• extensibility mechanisms.
a. Stereotypes

b. Tagged values
c. constraints
A note is used to specify things like: requirements, observations, reviews, explanations and constraints. A note
may
contain simple text or graphical symbols. A note has no effect on the semantics of a model means it does not
alter the
meaning of the model.
Specifications: Specification provides a textual statement of the syntax and semantics of a building block which
describing interesting aspects of a system.
Adornments: unique and direct graphical notation that provides a visual representation of the most important
aspects
of the element.
Common Divisions:
• In modeling, object-oriented systems get divided in multiple ways.
• For example, class vs. object, interface vs. implementation
• An object uses the same symbol as its class with its name underlined
Extensibility Mechanisms
Extensibility mechanisms allow extending the language in controlled ways. They include Sterotypes, Tagged
Values
and Constraints
Extensibility mechanisms can be classified in to

Stereotypes
Tagged Values
Constraints
Stereotypes
• Stereotypes are used to create new building blocks from existing blocks

• New building blocks are domain-specific

• Stereotypes are used to extend the vocabulary of a system
• Graphically represented as a name enclosed by guillemets (« »)
Tagged Values
• Tagged values are used to add to the information of the element (not of its instances)
• Stereotypes help to create new building blocks, whereas tagged values help to create new attributes
• These are commonly used to specify information relevant to code generation, configuration management and so on
Constraints
• Constraints are used to create rules for the model
• Rules that impact the behavior of the model, and specify conditions that must be met
• Can apply to any element in the model, i.e., attributes of a class, relationship
• Graphically represented as a string enclosed by braces {....} and placed near the associated elements or connected to
that elements by dependency relationships
Architecture:
A system's architecture is perhaps the most important artifact that can be used to manage these different
viewpoints and so control the iterative and incremental development of a system throughout its life cycle.
Architecture is the set of significant decisions about
1. The organization of a software system
2. The selection of the structural elements and their interfaces by which the system is composed
3. Their behavior, as specified in the collaborations among those elements
4. The composition of these structural and behavioral elements into progressively larger subsystems
The architectural style that guides this organization: the static and dynamic elements and their interfaces,
their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage, functionality,
performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and
aesthetic concerns. Architecture can be best represented as a collection five views:
1) Use case view,
2) Design/logical view,
3) Implementation/development view,
4) Process view and
5) Deployment/physical view.

Use case view: The use case view of a system encompasses (covers) the use cases that describe the behavior
of
the system as seen by its end users, analysts, and testers. With the UML, the static aspects of this view are
captured in use case diagrams. The dynamic aspects of this view are captured in interaction diagrams, state
chart
diagrams, and activity diagrams.
Design View:
• The design view of a system encompasses (covers) the classes, interfaces, and collaborations that form
the
vocabulary of the problem and its solution.
• This view primarily supports the functional requirements of the system, meaning the services that the
system
should provide to its end users.
Process View:
• The process view of a system encompasses the threads and processes that form the system's concurrency
and
synchronization mechanisms.
• This view primarily addresses the performance, scalability, and throughput of the system
Implementation View:
The implementation view of a system encompasses the components and files that are used to assemble
and
release the physical system. This view primarily addresses the configuration management of the system's
releases, made up of somewhat independent components and files that can be assembled in various ways
to
produce a running system.
Deployment View:
The deployment view of a system encompasses the nodes that form the system's hardware topology on
which
the system executes. This view primarily addresses the distribution, delivery, and installation of the parts
that

make up the physical system.
Events and Signals

Events
• An event is the specification of a significant occurrence that has a location in time and space.
• Any thing that happens is modeled as an event in UML.
• In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition
• four kinds of events – signals, calls, the passing of time, and a change in state.
• Figure 1: Events
• Events may be external or internal and asynchronous or synchronous.
Asynchronous events are events that can happen at arbitrary times eg:- signal, the passing of time, and a
change of state. Synchronous events, represents the invocation of an operation eg:- Calls
External events are those that pass between the system and its actors. Internal events are those that pass
among the objects that live inside the system.
A signal is an event that represents the specification of an asynchronous stimulus communicated between
instances.
Processes and Threads

• A process is a heavyweight flow that can execute concurrently with other processes.
• A thread is a lightweight flow that can execute concurrently with other threads within the same process.
• An active object is an object that owns a process or thread and can initiate control activity.
• An active class is a class whose instances are active objects.
• Graphically, an active class is rendered as a rectangle with thick lines. Processes and threads are rendered as
stereotyped active classes.
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.
• Depending on the semantics of the languages you choose, you may want to constrain your use of certain
UML features. For example, the UML permits you to model multiple inheritance, but Smalltalk permits only
single inheritance.
• 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.

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

Oosd Unit 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oosd Unit 2

Uploaded by

Copyright:

Available Formats

Object Oriented System Design (KCS-056)

Object Oriented System Design (KCS-056)

BRIJESH KUMAR VERMA 1

BRIJESH KUMAR VERMA 2

Data hiding has many uses, including:

BRIJESH KUMAR VERMA 3

• Dynamic (or late/run time ) binding

BRIJESH KUMAR VERMA 5

2. Every model may be expressed at different levels of precision

BRIJESH KUMAR VERMA 6

BRIJESH KUMAR VERMA 7

1. Building blocks of UML

BRIJESH KUMAR VERMA 8

building block of UML contains three types of elements. They are:

BRIJESH KUMAR VERMA 9

An interface provided by a class to the

BRIJESH KUMAR VERMA 10

Graphical representation: Example:

BRIJESH KUMAR VERMA 11

1.1.3 Grouping Things

BRIJESH KUMAR VERMA 12

BRIJESH KUMAR VERMA 13

BRIJESH KUMAR VERMA 14

Multiplicity Option Cardinality

1.2.2.1 Aggregation is an aggregation relationship can be described in simple words as ”Aggregation is a

BRIJESH KUMAR VERMA 15

BRIJESH KUMAR VERMA 16

BRIJESH KUMAR VERMA 17

1.3 Diagram in the UML

BRIJESH KUMAR VERMA 18

BRIJESH KUMAR VERMA 19

BRIJESH KUMAR VERMA 20

Purpose of Class Diagrams

BRIJESH KUMAR VERMA 21

Terms and Concepts

An icon representing several objects of type BankAccount

BRIJESH KUMAR VERMA 22

An object diagram with linked objects

A class diagram for a college information system

BRIJESH KUMAR VERMA 23

An object diagram representing part of a college information system

BRIJESH KUMAR VERMA 24

• Include - An include relationship specifies how the behavior for the

BRIJESH KUMAR VERMA 25

Interaction Diagram: Terms and concepts

BRIJESH KUMAR VERMA 26

• Activation or Execution Occurrence: Activation boxes represent the time

BRIJESH KUMAR VERMA 27

BRIJESH KUMAR VERMA 28

How to Draw a Sequence Diagram

BRIJESH KUMAR VERMA 29

BRIJESH KUMAR VERMA 30

Benefits of sequence diagrams

BRIJESH KUMAR VERMA 31

State Chart Diagram

BRIJESH KUMAR VERMA 32

Steps to draw a state diagram –

BRIJESH KUMAR VERMA 33

Activity diagram for a login page

BRIJESH KUMAR VERMA 34

Dependencies -Draw dependencies among components using dashed arrows.

How to draw a component diagram

BRIJESH KUMAR VERMA 35