Introduction to the UML

8/11/2019 Introduction to the UML

1/23

Introduction to the UML


2/23


3/23


4/23

History of the UML

Used for both database and software modeling

version 1.1 was adopted in November 1997 by theObject Management Group (OMG) as a standardlanguage for object-oriented analysis and design

Initially based on a combination of the Booch, OMT(Object Modeling Technique) and OOSE (Object-Oriented Software Engineering) methods, UML wasrefined and extended by a consortium of several

companies, and is undergoing minor revisions by theOMG Revision Task Force.

Ivar Jacobsonis known as the father of Use Cases.


5/23

Foundation of the UML


6/23


7/23

Language

The UML is a language for :

Visualizing:It makes it easier to understand and workthrough the problem.

Specifying:We must communicate our softwaresystem using some common, precise, andunambiguous communication mechanism.

Constructing:we can create tools that interpret ourmodels, so they can map the elements to aprogramming language, such as Java.

Documenting:produces a set of documentation thatcan serve as a blueprint of our system.


8/23

The Unified Modeling Language

Specify

Visualize

Construct

Document

Unification

ProgrammingLanguage

Tools / RepositorySpecification

Process

The UMLGoal


9/23

Models and Views

The UML is more than a set of disjointed

diagrams.

Instead of examining the UML from a

diagram-centric perspective, let's turn our

attention to an illustration of the UML from

three different perspectives.


10/23


11/23

Fundamental Elements

These basic building blocks are the elements

of which diagrams are composed.

These elements contribute little to the

specification of a software system.

Understanding the intent of each element

enables us to create precise diagrams because

each of the elements has a very unambiguous

meaning


12/23

Diagrams

The individual diagrams contribute more tothe specification of a software system than asingle building block.

We can think of a diagram as the compositionof many of the fundamental elements.

These diagrams are the mechanism that

developers use to communicate and solveproblems in the complex aspects of thesystem.


13/23

Views

We begin to realize that using a combinationof diagrams to communicate is most effective.

For instance, a class diagram is valuable in

communicating the structural relationshipsthat exist between the individual classeswithin our application, but a class diagramsays nothing about the ordering of messagessent between the objects within ourapplication.


14/23

UML Concepts-The 4+1 view

Use Case view

Understandability

Logical View

Functionality

Process View

Performance Scalable

Throughput

Development View

Software management

Physical View System topology

Delivery

Installation


15/23

Use case

This view documents the system from the

customer's perspective.

Terminology used in this view should be

domain specific.

Diagrams most common in this view are the

use case diagramsand, less common, activity

diagrams.


16/23

Logic (Design)

This view documents the system from

designer's and architect's perspective.

Diagrams most common in this view are class

and interaction diagrams(either sequence or

collaboration), as well as

package diagrams illustrating

the package structure of our

Java application.


17/23

Development

This view documents the components that the

system is composed of.

This view typically contains component

diagrams.

Except for the most complex Java applications,

this view is optional.


18/23

Process

This view documents the processes and

threads that compose our application.

These processes and threads typically are

captured on class diagramsusing an active

class.


19/23

Physical

This view documents the system topology.

Deployment diagrams that compose this view

illustrate the physical nodes and devices that

make up the application, as well as the

connections that exist between them.


20/23

Core Diagrams

We can combine diagrams that form models

and that can serve as views into our system.

We see that each falls into one of two

categories:

Behavioral diagramsdepict the dynamic aspects

of our system.

Structural diagrams depict the static aspect of oursystem.


21/23

Core Diagrams


22/23

Behavioral Diagrams

Behavioral diagrams communicate the aspects of thesystem that contribute to satisfying the system'srequirements, typically captured in the form of usecases.

Five diagrams that fall into this category: Use case: Shows a set of actors and use cases, and the

relationships between them.

Activity: Models the flow of activity between processes.

State: Illustrates internal state-related behavior of an

object. Sequence: type of interaction diagram that describes time

ordering of messages sent between objects.

Collaboration: type of interaction diagram that describesthe organizational layout of the objects that send and

receive messages.


23/23

Structural Diagrams

Diagrams in this category are focused onspecifying the static aspects of our system.

Four diagrams that fall into this category: Class: Illustrates a set of classes, packages, and

relationships detailing a particular aspect of a system.

Object: Provides a snapshot of the system illustratingthe static relationships that exist between objects.

Component: Addresses the static relationships

existing between the deployable softwarecomponents.

Deployment: Describes the physical topology of asystem.

Date post:	02-Jun-2018
Category:	Documents
Upload:	mahisa-dyan-diptya
View:	232 times
Download:	0 times

Introduction to the UML

Documents