50% found this document useful (2 votes)
471 views

Com 213 Uml Lecture Note

The document discusses system modeling and the Unified Modeling Language (UML). System modeling is the process of developing abstract models of a system using graphical notations, mainly based on UML. UML is an industry-standard modeling language that uses graphical notations to specify, visualize, and document software systems.

Uploaded by

kudabank815
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
50% found this document useful (2 votes)
471 views

Com 213 Uml Lecture Note

The document discusses system modeling and the Unified Modeling Language (UML). System modeling is the process of developing abstract models of a system using graphical notations, mainly based on UML. UML is an industry-standard modeling language that uses graphical notations to specify, visualize, and document software systems.

Uploaded by

kudabank815
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 35

COM 213 - Unified Modeling Language (UML)

Explain System Modeling, types and its importance


A system as a group of components or subsystems that integrate and function together in order to
achieve a specific goal. E.g. biological system, computer system, university system etc.
Examples of system: healthcare system, political system and educational system, transport
system
A model is a simplification at some level of abstraction. We build models to better understand
the systems we are developing.
Models help the analyst to understand the functionality of the system and models are used to
communicate with customers.
Systems Model is collection of elements that are interconnected in specific way.
Definition: System modeling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system. It is about representing a system
using some kind of graphical notations which is now almost based on notations in the UML.
Existing and planned system models
Models of the existing system are used to clarify what the existing system does and can be used
as a basis for discussion of strengths and weaknesses. These can lead to requirements for the new
system.
Models of the new system are used to help explain the proposed requirements to other system
stakeholders. Engineers use these models to discuss design proposals and to document the
system for implementation.
In a model-driven engineering process, it is possible to generate a complete or partial system
implementation from the system model.
System perspectives
External/Context perspectives: where you model the context or environment of the system
Interaction perspective: where you model the interactions between a system and its environment
or between the components of a system.
Structural perspective: where you model the organization of a system or the structure of the data
this is processed by the system.
Behavioral perspective: where you model the dynamic behavior of the system and how it
responds to events.

1
Importance of modeling
Why do we model?

 To help us visualize
 To specify structure or behavior
 To provide template for building system
 To document decisions we have made
Principles of modeling
Four basic principles of modeling
1. The models we choose have a profound influence on the solution we provide
2. Every model may be expressed at different levels of abstraction
3. The best models are connected to reality
4. No single model is sufficient, a set of models needed to solve any nontrivial system
Types of system model

External Interaction Structural Behavioural


Perspectives Perspectives Perspectives Perspectives

Context Interaction Structural Behavioural


model model model model

Define System Modeling Tool with examples

2
What is UML?

UML stands for Unified Modeling Language. It is an industry-standard graphical language for
specifying, visualizing, constructing and documenting the artifacts of software systems.

UML uses mostly graphical notations to express the Object Oriented Analysis and Design of
software projects. It simplifies the complex process of software design.

Purpose of UML

- It uses graphical notation to communicate more clearly than natural language and code
- It helps acquire an overall view of a system

- It is not dependent on any one language or technology

- It moves projects from fragmentation to standardization

- It simplifies software design process

UML diagrams are not only made for developers but also for business users, common people and
anybody interested to understand the system. The system can be a software or non-software

UML is not a development method rather it accompanies with processes to make it a successful
system

UML is a simple modeling mechanism to model all possible systems in todays’ complex
environment

Origin of UML
The 1990s was the era of development of object-oriented languages such as C++. These object-
oriented languages were used to create complex but compelling systems.

As the systems developed were complicated to understand, it led to the design and analysis
problems which were faced after the deployment of the system. It was difficult to explain the
system to others.

As soon as the UML was introduced, many game-changing experiments and approaches were
made for simplifying such difficult tasks of analyzing the system.

UML is an object-oriented unified modeling language. It was invented by brilliant software


engineers Grady Booch, Ivar Jacobson, and James Rumbaugh of Rational software during 1994
and 1995. It was under development until 1996.

3
Each of UML inventors, viz, Grady Booch, Ivar Jacobson, and James Rumbaugh had a fantastic
idea for designing a language which will reduce the complexity.

 Booch’s method was very flexible to work with during the design and construction of
objects.
 Jacobson’s method provided a great way to work around use-cases. It also has a powerful
approach for high-level design.
 Rumbaugh’s method turned out to be very useful while handling sensitive systems.

Later on, behavioral models and state-charts were introduced in the UML which were invented
by David Harel.

UML was recognized as a standard by Object Management Group (OMG) in 1997. Object
Management Group is responsible for managing UML ever since it was adopted as a standard.

In 2005, the International Organization for Standardization approved UML as an ISO standard. It
is used in various industries for creating object-oriented models.

The latest UML version is 2.5.1 which was released in December 2017.

UML Versions
Date Version About

UML was adopted by Object Management Group. This was the first
November 1997 1.1
version of UML.

A minor upgrade was done to the existing model with notable changes
March 2000 1.3
in semantics, notations, and meta-models of UML.

This was the period of the major update to the UML. It scaled UML by
September 2001 1.4 providing various extensions. Visibility, artifact, stereotypes were
introduced in diagrams.

Features such as procedures, data flow mechanism were added to the


March 2003 1.5
UML.

January 2005 1.4.2 UML was accepted as a standard by ISO.

August 2005 2.0 New diagrams such as the object, package, timing, interaction were
added to the UML. New features were added to the activity and
sequence diagrams. Collaboration diagram was renamed as
communication diagram. Multiple features and changes were introduced

4
Date Version About

in the existing diagrams.

April 2006 2.1 Corrections were made to the UML 2.0.

February 2007 2.1.1 Upgrades were introduced in the UML 2.1.

November 2007 2.1.2 UML 2.1.1 was redefined.

February 2009 2.2 UML 2.1.2 bugs were fixed.

UML 2.2 was revised, and minor changes were made to the component
May 2010 2.3
diagrams.

Classes, packages, and stereotypes changes were made. UML 2.3 was
August 2011 2.4.1
revised with enhancement features.

UML 2.4.1 was revised with minor changes. UML was made simple
than it was before. Rapid functioning and the generation of more
June 2015 2.5
effective models were introduced. Outdated features were eliminated.
Models, templates were eliminated as auxiliary constructs.

Characteristics of UML
1. It is a generalized modeling language.
2. It is different from software programming languages such as Python, C, C++, etc.
3. It is a pictorial language which can be used to generate powerful modeling elements.
4. It is related to object-oriented designs and analysis.
5. It has unlimited applications even outside the software industry. It can be used to
visualize the workflow of a factory.

Importance of UML Diagram

UML diagrams can be used as a way to visualize a project before it takes place or as
documentation for a project afterward. But the overall goal of UML diagrams is to allow teams
to visualize how a project is or will be working, and they can be used in any field, not
just software engineering.

Also, it can provide new ideas for how the team needs to collaborate to achieve the goal of the
workflow process.

5
What is UML Diagram?

UML Diagrams are the output of the Unified Modeling Language. It is a pictorial representation
of classes, objects, and relationships between them. UML diagram is a model that describes a
part of a system. It is used to define the functionality or a design of a system. A diagram must be
clear and concise so that the viewer will readily understand it.
UML diagrams are divided into three different categories such as,

 Structural diagram
 Behavioral diagram
 Interaction diagram

Structural diagrams in UML


Structural diagrams are used to represent a static view of a system. It represents a part of a
system that makes up the structure of a system. A structural diagram shows various objects
within the system.

Following are the various structural diagrams in UML:

 Class diagram
 Object diagram
 Package diagram
 Component diagram
 Deployment diagram

Behavioral diagrams in UML


Any real-world system can be represented in either a static form or a dynamic form. A system is
said to be complete if it is expressed in both the static and dynamic ways. The behavioral
diagram represents the functioning of a system.

UML diagrams that deals with the static part of a system are called structural diagrams. UML
diagrams that deals with the moving or dynamic parts of the system are called behavioral
diagrams.

Following are the various behavioral diagrams in UML:

 Activity diagram
 Use case diagram
 State machine diagram

6
Interaction diagrams in UML
Interaction diagram is nothing but a subset of behavioral diagrams. It is used to visualize the
flow between various use case elements of a system. Interaction diagrams are used to show an
interaction between two entities and how data flows within them.

Following are the various interaction diagrams in UML:

 Timing diagram
 Sequence diagram
 Collaboration diagram

UML Diagrams overview

Types of UML Software

Gliffy

Gliffy is an open-source software that designs UML diagrams, floor plans, Venn diagrams,
flowcharts, and much more. It allows the user to share and edit Gliffy diagrams dynamically.

Features:
o It constitutes a drag and drop interface.

7
o It exports diagrams in various formats that are; PDF, JPEG, PNG, and SVG.
o It is supported by all web browsers such as Google Chrome, Firefox, Safari, and Internet
Explorer 9+.

Download link: https://www.gliffy.com

Lucidchart

Lucidchart is an HTML-5 based UML tool that allows user interaction while drawing, editing,
and sharing diagrams and charts. With Lucidchart, you can create simple flowcharts as well as
complex technical diagrams.

Features:
o It works faster with keyboard shortcuts.
o It constitutes the concept of containerization as the complex diagram involves several
steps and people.
o It manages user account by increasing security.
o It is platform-independent.

Download link: https://www.lucidchart.com/pages/

MagicDraw

Magic Draw is used to model UML diagrams, SysML, BPMN, and UPDM that supports the
dynamic collaboration of the team. This tool is meant for business analysts, software analysts,
programmers, and QA engineers. It facilitates analyzing and designing object-oriented systems
and databases.

Features:
o It provides round-trip support for programming languages (J2EE, C#, C++, COBRA
IDL), .NET, XML Schema, DDL generation, and database schema.
o It incorporates the concept of reverse engineering.
o It is a domain-specific language.
o It constitutes model decomposition that categorizes the main project into several distinct
independents parts.
o It encompasses model refactoring to improve the existing model.

Download link: https://www.nomagic.com/products/magicdraw

MS Visio

8
Visio is a part of the Microsoft family, which is a diagramming software. It is helpful in drawing
building plans, floor charts, data flow diagrams, process flow diagrams, business process
modeling, swimlane diagrams, and many more.

Features:
o It connects the diagrams and the flowcharts to real-time data.
o Since it is a platform-independent, it can be accessed from anywhere.

Download link: https://products.office.com/en-in/visio/flowchart-software

Modelio

Modelio is an open-source UML tool that amalgamates UML2 and BPMN standards to support
an inclusive range of models and diagrams.

Features:
o It provides support to Jython, which is a scripting language.
o It provides a BPMN integrated support with UML.
o It offers XMI import/export.

Download link: https://www.modelio.org

Nclass

Nclass is an open-source tool, used to create class diagrams that support #C and Java. It requires
a framework of .NET 4.0. It has designed a simple and user-friendly user interface for fast and
easy development.

Features:
o It provides a simple and easy user interface.
o It offers a multilingual user interface.
o It provides mono support for the non-windows user.
o It has come up with inline class editors for fast and easy editing.
o It incorporates source code generation and reverse engineering from .Net assemblies.

Download link: http://nclass.sourceforge.net

9
StarUML
StarUML is a UML diagram modeling tool. It is one of the best UML software that provides
eleven types of diagram. StartUML 2 is compatible with UML 2.x versions.

Features:

 This UML diagram software allows you to discover and install third-party extensions.
 No limit to using this commercial software for evaluation.
 Offers pre-built templates for Class Diagram
 It provides multiple diagram options cloud storage
 Supports JSON, PNG, HTML and JPEG file formats
 It Provides import/export options for PDF, XML, PNG, JPEG, HTML and SVG
 Support programming language like C, C++, C#, Java and Python
 Provides Custom Uml Profile, Auto Update, Model-driven Development, Fast Modeling,
Dark And Light Themes and Code Markdown Support
 Offers Multi-file support, Drag and Drop, and Print option
 It provides customer support via Email
 Supported Platforms: MacOS, Windows and Linux

Download link: http://staruml.io/

Visual Paradigm
Visual Paradigm is a software design tool that is tailored for engine software projects. This UML
editor tool helps the software development team to model business information systems and
development processes.

Features:

 It offers a complete tool like for process analysis, system design, database design, etc.
 Offers user story feature to capture and maintain users’ needs.
 Offers pre-built templates for Social Media, Events, Business, Marketing, Documents,
School, Personal, Infographics, Posters and Gift Card
 Seamlessly integrates with Eclipse, NetBeans, IntelliJ IDEA, Visual Studio and Android
Studio
 Free plan offers 1GB cloud storage

10
 It provides multiple diagram options 1GB cloud storage
 Supports JPG, PNG, SVG, TIFF, EMF, PDF and DOC file formats
 It Provides import/export options for JPG, PNG, SVG, TIFF, EMF, PDF and XML
 Offers 256-bit SSL encryption
 Provides Visual Modeling, Enterprise Architecture, Business Analysis & Design, Project
Management, Agile & Scrum Development, Online Diagram Tool, Spreadsheet Tool, and
Team Collaboration
 Offers Multi-file support, Drag and Drop, and Print option
 It provides customer support via Contact form
 Supported Platforms: MacOS, Windows, iOS and Linux

Download link: https://www.visual-paradigm.com/

Draw.IO
Draw.IO is a free online UML tool. It is one of the best UML tools that allows users to create
and manage the drawing easily these tools. A lot of the wide and early share is available with this
tool.

Features:

 No limit on the number of sizes


 Templates are present in the software design itself.
 This free UML diagram tool allows you to save the model in your preferred location
 Offers pre-built templates for diagram
 Seamlessly integrates with Aha, Atom, Bioiocons, BookStack, Docstell, FOSWiki,
Grafana, Growi, JupyterLab, Lark, LumApps, Nextcloud, Nuclino, Redmine and
Sandstorm
 It provides multiple diagram options cloud storage
 Supports PNG, JPEG, SVG, JSON, XML, CSV and PDF file formats
 It Provides import/export options for PNG, JPEG, SVG, JSON, XML, CSV and PDF
 Offers firewall based encryption
 Provides Keep your diagram data secure, Diagram wherever you want, Collaborate in
real-time with shared cursors, Easy-to-use diagram editor, and Many advanced tools
 Offers Version history, Drag and Drop, and Print option

11
 It provides customer support via Email and Phone
 Supported Platforms: Android, MacOS, Windows, iOS and Linux

Download link: https://www.draw.io/

12
Conceptual Model

Before beginning with the UML concept, one must understand the basics of the conceptual
model.

A conceptual model is made up of various concepts which are interrelated. It helps us to


understand

 What are the objects?


 How interaction takes place to execute a process?

A conceptual model is required in UML. You have to understand the entities and relationships
between them before actually modeling the system.

The following object-oriented concepts are required to begin with UML:

 Object: It is a real-world entity. There are multiple objects available within a single
system. It is a fundamental building block of UML.
 Class: A class is nothing but a container where objects and their relationships are
maintained.
 Abstraction: It is a mechanism of representing an entity without showing the
implementation details. It is used to visualize the behavior of an object.
 Inheritance: It is a mechanism of extending an existing class to create a new class.
 Polymorphism: It is a mechanism of representing an object having multiple forms which
are used for different purposes.
 Encapsulation: It is a method of binding the object and the data together as a single unit.
It ensures tight coupling between the object and the data.

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a conceptual model
and why a conceptual model is required?
 A conceptual model can be defined as a model which is made of concepts and their
relationships.
 A conceptual model is the first step before drawing a UML diagram. It helps to
understand the entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements −
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML

13
Conceptual Model of UML

Building Blocks Rules Common Mechanisms

Things Relationships Diagrams 4) Specifications


1) Adornments
1. Class Diagram. 2) Common Divisions
1) Association 2. Object Diagram. 3) Extensibility Mechanisms
2) Dependency 3. Use Case Diagram.
3) Generalization 4. Sequence Diagram. *Stereotypes

14
4) Realization 5. Collaboration Diagram. *Tagged Values
6. State Chart Diagram. 1) Names *Constraints
7. Activity Diagram. 2) Scope
9. Deployment Diagram. 3) Visibility
4) Integrity
5) Execution

Structural Things Behavioral Things Grouping Things Annotational Things

*Classes *Interaction *Packages *notes


*Interfaces *State machines
*Collaborations *States
*Use Case
*Component
*Node

UML Building Blocks


UML stands for unified modeling language which revolves around various blocks to generate a
single model. Building blocks are the things required to develop one full UML model diagram. It
is an essential part of every UML diagram. Following are the basic building blocks of UML:

1. Things
2. Relationships
3. Diagrams

Things
A thing can be described as any real-world entity or an object. Things are divided into various
categories in UML as follows,

 Structural things
 Behavioral things
 Grouping things
 Annotational things

Structural things
A structural thing is used to describe the static part of a model. It is used to represent the things
that are visible to human eyes. Structural things in UML are all about the physical part of a
system. It is the noun of a UML model, such as a class, object, interface, collaboration, use case,
component, and a node.

Class:

A class is used to represent various objects. It is used to define the properties and operations of
an object. In UML, we can also represent an abstract class. A class whose functionalities are not
defined is called an abstract class. Any UML class diagram notations are generally expressed as
below UML class diagrams example,

UML Class Symbol

Object:

An object is an entity which is used to describe the behavior and functions of a system. The class
and object have the same notations. The only difference is that an object name is always
underlined in UML.

The UML notation of any object is given below.


UML Object Symbol

Interface:

An interface is similar to a template without implementation details. A circle notation represents


it. When a class implements an interface, its functionality is also implemented.

UML Interface Symbol

Collaboration:

It is represented by a dotted ellipse with a name written inside it.

UML Collaboration Notation

Use-case:

Use-cases are one of the core concepts of object-oriented modeling. They are used to represent
high-level functionalities and how the user will handle the system.
UML Use Case

Actor:

It is used inside use case diagrams. The Actor notation is used to denote an entity that interacts
with the system. A user is the best example of an actor. The actor notation in UML is given
below.

UML Actor

Component:

A component notation is used to represent a part of the system. It is denoted in UML like given
below,

UML Component

Node:

A node is used to describe the physical part of a system. A node can be used to represent a
network, server, routers, etc. Its notation is given below.
UML Node

Deployment diagram:

It represents the physical hardware on which system is installed. A deployment diagram


represents the physical view of a system. It denotes the communication and interaction between
various parts of the system.

A deployment diagram consists of the following notations:

1. A node
2. A component
3. An artifact
4. An interface

Deployment Diagram
Behavioral things
They are the verbs of a UML model, such as interactions, activities and state machines.
Behavioral things in UML are used to represent the behavior of a system.

Behavioral things consist of:

State machine:

It used to describe various states of a single component throughout the software development life
cycle. It is used to capture different states of a system component.
State Machine

Activity diagram:

An activity diagram is used to represent various activities carried out by different components of
a system. It is denoted the same as that of the state machine diagram.

Activity diagram mainly contains initial state, final state, a decision box, and an action notation.

Activity Diagram

Interaction diagram:

Interaction diagrams are used to visualize the message flow between various components of a
system.

 Sequence diagram: A sequence diagram shows interactions between one or more lifelines
within real time.
The notation of a sequence diagram is given below,

Interaction Diagram

Grouping things
It is the package which is used to group semantically related modeling elements into a single
cohesive unit. The package is the only grouping thing available in the UML.

UML Package
Annotational things
It is like a note, which may be written to the model to capture some vital information. It is
similar to the yellow sticky note. Here is an example for annotation things in UML:

UML Annotation
Relationships
The relationship allows you to show on a model how two or more things relate to each other. The
relationship in UML will enable you to capture meaningful connections between things. It shows
how each element is associated with each other and how this association describes the
functionality of an application.

Relationships in UML are categorized as follows,

 Association relationship
 Dependency relationship
 Generalization relationship
 Realization relationship

Association relationship
It is a set of links that connect elements of the UML model. It also defines how many objects are
taking part in that relation. It illustrates how many elements are participating in a particular
interaction.

It is denoted as a dotted line with arrowheads on both sides. Both the sides contain an element
which describes the relationship. A new term multiplicity is introduced that tells us how many
objects of a particular element are associated.

Association relationship is denoted as follows,

INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation15.png"
\* MERGEFORMATINET

UML Association Relationship


Dependency relationship
In this kind of a relationship, the source element is dependent upon the target element and may
be affected by changes to it. It is one of the most important notations of UML. It defines the
direction of a dependency from one object to another.

It is denoted by a dotted line with an arrow at one side.

Dependency relationship is denoted as follows,

INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation16.png"
\* MERGEFORMATINET

UML Dependency Relationship


Generalization relationship
It is also called as a parent-child relationship. It is a relationship between a general thing and a
more specific kind of a thing. This type of relationship is used to represent the inheritance
concept.

It is denoted by a straight line with a hollow arrowhead at one side.

Generalization relationship is denoted as follows,

INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation17.png"
\* MERGEFORMATINET

UML Generalization Relationship


Realization relationship
In this, one element describes some responsibility which is not implemented and the other
elements implement the functionality mentioned by the first element. Realization relationship is
widely used while denoting interfaces.

It is denoted as a dotted line with a hollow arrowhead at one end.

Realization relationship is denoted as follows:

INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation18.png"
\* MERGEFORMATINET

UML Realization Relationship

Diagrams in the UML

A diagram is the graphical presentation of a set of elements, most often rendered as a


connected graph of vertices (things) and paths (relationships). You draw diagrams to visualize
a system from different perspectives, so a diagram is a projection into a system. The UML
includes thirteen kinds of diagrams:

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

A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. These diagrams are the most common diagram found in modeling object-oriented
systems. Class diagrams address the static design view of a system. Class diagrams that include
active classes address the static process view of a system. Component diagrams are variants of
class diagrams.

An object diagram shows a set of objects and their relationships. Object diagrams
represent static snapshots of instances of the things found in class diagrams. These diagrams
address the static design view or static process view of a system as do class diagrams, but from
the perspective of real or prototypical cases.

A component diagram is shows an encapsulated class and its interfaces, ports, and internal
structure consisting of nested components and connectors. Component diagrams address the
static design implementation view of a system. They are important for building large systems
from smaller parts. (UML distinguishes a composite structure diagram, applicable to any class,
from a component diagram, but we combine the discussion because the distinction between a
component and a structured class is unnecessarily subtle.)

A use case diagram shows a set of use cases and actors (a special kind of class) and their
relationships. Use case diagrams address the static use case view of a system. These diagrams
are especially important in organizing and modeling the behaviors of a system.

Both sequence diagrams and communication diagrams are kinds of interaction diagrams. An
interaction diagram shows an interaction, consisting of a set of objects or roles, including the
messages that may be dispatched among them. Interaction diagrams address the dynamic view
of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering
of messages; a communication diagram is an interaction diagram that emphasizes the
structural organization of the objects or roles that send and receive messages. Sequence
diagrams and communication diagrams represent similar basic concepts, but each diagram
emphasizes a different view of the concepts. Sequence diagrams emphasize temporal
ordering, and communication diagrams emphasize the data structure through which messages
flow. A timing diagram (not covered in this book) shows the actual times at which messages
are exchanged.

A state diagram shows a state machine, consisting of states, transitions, events, and activities.
A state diagrams shows the dynamic view of an object. They are especially important in
modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered
behavior of an object, which is especially useful in modeling reactive systems.
An activity diagram shows the structure of a process or other computation as the flow of
control and data from step to step within the computation. Activity diagrams address the
dynamic view of a system. They are especially important in modeling the function of a system
and emphasize the flow of control among objects.

A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them. Deployment diagrams address the static deployment view of an
architecture. A node typically hosts one or more artifacts.

An artifact diagram shows the physical constituents of a system on the computer. Artifacts
include files, databases, and similar physical collections of bits. Artifacts are often used in
conjunction with deployment diagrams. Artifacts also show the classes and components that
they implement. (UML treats artifact diagrams as a variety of deployment diagram, but we
discuss them separately.)

A package diagram shows the decomposition of the model itself into organization units and
their dependencies.

A timing diagram is an interaction diagram that shows actual times across different objects or
roles, as opposed to just relative sequences of messages. An interaction overview diagram is a
hybrid of an activity diagram and a sequence diagram. These diagrams have specialized uses
and so are not discussed in this book. See the UML Reference Manual for more details.
This is not a closed list of diagrams. Tools may use the UML to provide other kinds of
diagrams, although these are the most common ones that you will encounter in practice.

Rules of the UML

The UML's building blocks can't simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony with all
its related models.

The UML has syntactic and semantic rules for

Names What you can call things, relationships, and diagrams

Scope The context that gives specific meaning to a name


Visibility How those names can be seen and used by others
Integrity How things properly and consistently relate to one another
Execution What it means to run or simulate a dynamic model

Models built during the development of a software-intensive system tend to evolve and may be
viewed by many stakeholders in different ways and at different times. For this reason, it is
common for the development team to not only build models that are well-formed, but also to
build models that are

Elided -- Certain elements are hidden to simplify the view


Incomplete -- Certain elements may be missing
Inconsistent -- The integrity of the model is not guaranteed

These less-than-well-formed models are unavoidable as the details of a system unfold and
churn during the software development life cycle. The rules of the UML encourage you but do
not force you to address the most important analysis, design, and implementation questions
that push such models to become well-formed over time.

Common Mechanisms in the UML


A building is made simpler and more harmonious by the conformance to a pattern of common
features. A house may be built in the Victorian or French country style largely by using certain
architectural patterns that define those styles. The same is true of the UML. It is made simpler
by the presence of four common mechanisms that apply consistently throughout the language.

1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

Specifications
The UML is more than just a graphical language. Rather, behind every part of its graphical
notation there is a specification that provides a textual statement of the syntax and semantics of
that building block. For example, behind a class icon is a specification that provides the full
set of attributes, operations (including their full signatures), and behaviors that the class
embodies; visually, that class icon might only show a small part of this specification.
Furthermore, there might be another view of that class that presents a completely different set
of parts yet is still consistent with the class's underlying specification. You use the UML's
graphical notation to
visualize a system; you use the UML's specification to state the system's details. Given this
split, it's possible to build up a model incrementally by drawing diagrams and then adding
semantics to the model's specifications, or directly by creating a specification, perhaps by
reverse engineering an existing system, and then creating diagrams that are projections into
those specifications.

The UML's specifications provide a semantic backplane that contains all the parts of all the
models of a system, each part related to one another in a consistent fashion. The UML's
diagrams are thus simply visual projections into that backplane, each diagram revealing a
specific interesting aspect of the system.

Adornments
Most elements in the UML have a unique and direct graphical notation that provides a visual
representation of the most important aspects of the element. For example, the notation for a
class is intentionally designed to be easy to draw, because classes are the most common
element found in modeling object-oriented systems. The class notation also exposes the most
important aspects of a class, namely its name, attributes, and operations.

A class's specification may include other details, such as whether it is abstract or the visibility
of its attributes and operations. Many of these details can be rendered as graphical or textual
adornments to the class's basic rectangular notation. For example, Figure 2-18 shows a class,
adorned to indicate that it is an abstract class with two public, one protected, and one private
operation.

Adornments

Every element in the UML's notation starts with a basic symbol, to which can be added a
variety of adornments specific to that symbol.

Common Divisions

In modeling object-oriented systems, the world often gets divided in several ways.

First, there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, you can model classes as well as
objects, as shown in Figure 2-19. Graphically, the UML distinguishes an object by using the
same symbol as its class and then simply underlying the object's name.
Figure 2-19. Classes and Objects

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

Almost every building block in the UML has this same kind of class/object dichotomy. For
example, you can have use cases and use case executions, components and component
instances, nodes and node instances, and so on.

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


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

Figure 2-20. Interfaces and Implementations

In this figure, there is one component named SpellingWizard.dll that provides (implements)
two interfaces, IUnknown and ISpelling. It also requires an interface, IDictionary, that must be
provided by another component.
Almost every building block in the UML has this same kind of interface/implementation
dichotomy. For example, you can have use cases and the collaborations that realize them, as
well as operations and the methods that implement them.

Third, there is the separation of type and role. The type declares the class of an entity, such as
an object, an attribute, or a parameter. A role describes the meaning of an entity within its
context, such as a class, component, or collaboration. Any entity that forms part of the
structure of another entity, such as an attribute, has both characteristics: It derives some of its
meaning from its inherent type and some of its meaning from its role within its context (Figure
2-21).

Figure 2-21. Part with role and type

Extensibility Mechanisms

The UML provides a standard language for writing software blueprints, but it is not possible
for one closed language to ever be sufficient to express all possible nuances of all models
across all domains across all time. For this reason, the UML is opened-ended, making it
possible for you to extend the language in controlled ways. The UML's extensibility
mechanisms include

Stereotypes
Tagged
values
Constraints

A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem. For example,
if you are working in a programming language, such as Java or C++, you will often want to
model exceptions. In these languages, exceptions are just classes, although they are treated in
very special ways. Typically, you only want to allow them to be thrown and caught, nothing
else. You can make exceptions first-class citizens in your modelsmeaning that they are treated
like basic building blocksby marking them with an appropriate stereotype, as for the class
Overflow in Figure 2-19.

A tagged value extends the properties of a UML stereotype, allowing you to create new
information in the stereotype's specification. For example, if you are working on a
shrink-
wrapped product that undergoes many releases over time, you often want to track the version
and author of certain critical abstractions. Version and author are not primitive UML concepts.
They can be added to any building block, such as a class, by introducing new tagged values to
that building block. In Figure 2-19, for example, the class EventQueue is extended by marking
its version and author explicitly.

A constraint extends the semantics of a UML building block, allowing you to add new rules or
modify existing ones. For example, you might want to constrain the EventQueue class so that
all additions are done in order. As Figure 2-22 shows, you can add a constraint that explicitly
marks these for the operation add.

Figure 2-22. Extensibility Mechanisms

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

Architecture:

Any real world system is used by different users. The users can be developers, testers, business
people, analysts and many more. So before designing a system the architecture is made with
different perspectives in mind. The most important part is to visualize the system from
different viewer.s perspective. The better we understand the better we make the system.

UML plays an important role in defining different perspectives of a system. These


perspectives are:

Design View ,Implementation view, Process View, Deployment View and Usecase
View
And the centre is the Use Case view which connects all these four. A Use case represents
the functionality of the system. So the other perspectives are connected with use case.

Design of a system consists of classes, interfaces and collaboration. UML provides


class diagram, object diagram to support this.
Implementation defines the components assembled together to make a complete
physical system. UML component diagram is used to support implementation
perspective.
Process defines the flow of the system. So the same elements as used in Design are
also used to support this perspective.
Deployment represents the physical nodes of the system that forms the hardware.
UML deployment diagram is used to support this perspective.
Object-Oriented Concepts

UML can be described as the successor of object-oriented (OO) analysis and design.
An object contains both data and methods that control the data. The data represents the state of
the object. A class describes an object and they also form a hierarchy to model the real-world
system. The hierarchy is represented as inheritance and the classes can also be associated in
different ways as per the requirement.
Objects are the real-world entities that exist around us and the basic concepts such as abstraction,
encapsulation, inheritance, and polymorphism all can be represented using UML.
UML is powerful enough to represent all the concepts that exist in object-oriented analysis and
design. UML diagrams are representation of object-oriented concepts only. Thus, before learning
UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
 Objects − Objects represent an entity and the basic building block.
 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real world entity.
 Encapsulation − Encapsulation is the mechanism of binding the data together and hiding
them from the outside world.
 Inheritance − Inheritance is the mechanism of making new classes from existing ones.
 Polymorphism − It defines the mechanism to exists in different forms.

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the investigation of objects.


Design means collaboration of identified objects.
Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also
done for an existing system. Now an efficient analysis is only possible when we are able to start
thinking in a way where objects can be identified. After identifying the objects, their
relationships are identified and finally the design is produced.
The purpose of OO analysis and design can described as −
 Identifying the objects of a system.
 Identifying their relationships.
 Making a design, which can be converted to executables using OO languages.
There are three basic steps where the OO concepts are applied and implemented. The steps can
be defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −
 During OO analysis, the most important purpose is to identify objects and describe them
in a proper way. If these objects are identified efficiently, then the next job of design is
easy. The objects should be identified with responsibilities. Responsibilities are the
functions performed by the object. Each and every object has some type of
responsibilities to be performed. When these responsibilities are collaborated, the purpose
of the system is fulfilled.
 The second phase is OO design. During this phase, emphasis is placed on the
requirements and their fulfilment. In this stage, the objects are collaborated according to
their intended association. After the association is complete, the design is also complete.
 The third phase is OO implementation. In this phase, the design is implemented using OO
languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML
is used for non-software systems, the emphasis is on modeling OO software applications. Most
of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before understanding
the UML in detail, the OO concept should be learned properly. Once the OO analysis and design
is done, the next step is very easy. The input from OO analysis and design is the input to UML
diagrams.
Object-Oriented Concepts

UML can be described as the successor of object-oriented (OO) analysis and design.
An object contains both data and methods that control the data. The data represents the state of
the object. A class describes an object and they also form a hierarchy to model the real-world
system. The hierarchy is represented as inheritance and the classes can also be associated in
different ways as per the requirement.
Objects are the real-world entities that exist around us and the basic concepts such as abstraction,
encapsulation, inheritance, and polymorphism all can be represented using UML.
UML is powerful enough to represent all the concepts that exist in object-oriented analysis and
design. UML diagrams are representation of object-oriented concepts only. Thus, before learning
UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
 Objects − Objects represent an entity and the basic building block.
 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real world entity.
 Encapsulation − Encapsulation is the mechanism of binding the data together and hiding
them from the outside world.
 Inheritance − Inheritance is the mechanism of making new classes from existing ones.
 Polymorphism − It defines the mechanism to exists in different forms.

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the investigation of objects.


Design means collaboration of identified objects.
Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also
done for an existing system. Now an efficient analysis is only possible when we are able to start
thinking in a way where objects can be identified. After identifying the objects, their
relationships are identified and finally the design is produced.
The purpose of OO analysis and design can described as −
 Identifying the objects of a system.
 Identifying their relationships.
 Making a design, which can be converted to executable using OO languages.
There are three basic steps where the OO concepts are applied and implemented. The steps can
be defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −
 During OO analysis, the most important purpose is to identify objects and describe them
in a proper way. If these objects are identified efficiently, then the next job of design is
easy. The objects should be identified with responsibilities. Responsibilities are the
functions performed by the object. Each and every object has some type of
responsibilities to be performed. When these responsibilities are collaborated, the purpose
of the system is fulfilled.
 The second phase is OO design. During this phase, emphasis is placed on the
requirements and their fulfilment. In this stage, the objects are collaborated according to
their intended association. After the association is complete, the design is also complete.
 The third phase is OO implementation. In this phase, the design is implemented using OO
languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML
is used for non-software systems, the emphasis is on modeling OO software applications. Most
of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before understanding
the UML in detail, the OO concept should be learned properly. Once the OO analysis and design
is done, the next step is very easy. The input from OO analysis and design is the input to UML
diagrams.

You might also like