0% found this document useful (0 votes)
33 views39 pages

Chapter 3

The document provides an overview of the Unified Modeling Language (UML), which is a standard visual modeling language for specifying, visualizing, and documenting software systems. It outlines the key components of UML, including building blocks, relationships, and diagrams, and emphasizes its application in both software and non-software systems. Additionally, it discusses the importance of UML in improving communication among stakeholders and managing complexity in software development.

Uploaded by

Abinet Arba
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views39 pages

Chapter 3

The document provides an overview of the Unified Modeling Language (UML), which is a standard visual modeling language for specifying, visualizing, and documenting software systems. It outlines the key components of UML, including building blocks, relationships, and diagrams, and emphasizes its application in both software and non-software systems. Additionally, it discusses the importance of UML in improving communication among stakeholders and managing complexity in software development.

Uploaded by

Abinet Arba
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Prepared By: Jerusalem Y.

UML 5/9/2019 1
 UML - Overview
 Design using formal methods and UML

UML 5/9/2019 2
 UML is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software
systems.
 UML was created by the Object Management Group (OMG)
and UML 1.0 specification draft was proposed to the OMG in
January 1997.
 OMG is continuously making efforts to create a truly industry
standard.
 UML stands for Unified Modeling Language.
 UML is different from the other common programming
languages such as C++, Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.

UML 5/9/2019 3
 UML can be described as a general purpose visual modeling
language to visualize, specify, construct, and document
software system.
 Although UML is generally used to model software systems, it
is not limited within this boundary.
 It is also used to model non-software systems as well. For
example, the process flow in a manufacturing unit, etc.
 UML is not a programming language but tools can be used to
generate code in various languages using UML diagrams.
 UML has a direct relation with object oriented analysis and
design.
 UML is not “process”. (That is, it doesn’t tell you how to do
things, only what you should do.)

UML 5/9/2019 4
 There are a number of goals for developing UML but the most
important is to define some general purpose modeling
language, which all modelers can use and it also needs to be
made simple to understand and use.
 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 system. Thus it
must be clear that UML is not a development method rather it
accompanies with processes to make it a successful system.
 In conclusion, the goal of UML can be defined as a simple
modeling mechanism to model all possible practical systems
in today’s complex environment.

UML 5/9/2019 5
 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
1. UML building blocks
2. Rules to connect the building blocks
3. Common mechanisms of UML

UML 5/9/2019 6
 The building blocks of UML can be defined as
1. Things
2. Relationships
3. Diagrams

UML 5/9/2019 7
 Things are the most important building blocks of UML.
 Things can be
• Structural
• Behavioral
• Grouping
• Annotational

UML 5/9/2019 8
 Structural things define the static part of the
model. They represent the physical and
conceptual elements.
Following are the brief descriptions of the
structural things.
 Class − Class represents a set of objects having
similar responsibilities.
 Interface − Interface defines a set of operations,
which specify the responsibility of a class.
 Collaboration −Collaboration defines an
interaction between elements.

UML 5/9/2019 9
 Use case −Use case represents a set of actions
performed by a system for a specific goal.
 Component −Component describes the
physical part of a system.
 Node − A node can be defined as a physical
element that exists at run time.

UML 5/9/2019 10
 A behavioral thing consists of the dynamic
parts of UML models. Following are the
behavioral things
 Interaction − Interaction is defined as a
behavior that consists of a group of messages
exchanged among elements to accomplish a
specific task.
 State machine − State machine is useful when
the state of an object in its life cycle is
important. It defines the sequence of states an
object goes through in response to events.
Events are external factors responsible for state
change

UML 5/9/2019 11
 Grouping things can be defined as a
mechanism to group elements of a
UML model together. There is only one
grouping thing available
 Package − Package is the only one
grouping thing available for gathering
structural and behavioral things.

UML 5/9/2019 12
 Annotational things can be defined as a mechanism to
capture remarks, descriptions, and comments of UML model
elements.
 Note - It is the only one Annotational thing available.
 A note is used to render comments, constraints, etc. of an
UML element.

UML 5/9/2019 13
 Relationship is another most important building block
of UML.
 It shows how the elements are associated with each
other and this association describes the functionality of
an application.
 There are four kinds of relationships available.
1. Dependency
 Dependency is a relationship between two things in
which change in one element also affects the other.
2. Association
 Association is basically a set of links that connects the
elements of a UML model. It also describes how many
objects are taking part in that relationship.

UML 5/9/2019 14
3. Generalization
 Generalization can be defined as a relationship which
connects a specialized element with a generalized
element.
 It basically describes the inheritance relationship in the
world of objects.
4. Realization
 Realization can be defined as a relationship in which
two elements are connected.
 One element describes some responsibility, which is
not implemented and the other one implements them.
 This relationship exists in case of interfaces.

UML 5/9/2019 15
 Unified Modeling Language has four common mechanisms
that we can apply throughout the language
i. Specification
ii. Common Divisions
iii. Adornments
iv. Extensibility mechanisms.

UML 5/9/2019 16
i. Specifications:- The UML is more than 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 the building block.
ii. Adornments: – Notes are the most important kind of
adornment that stands alone. A note is a graphical symbol
for rendering constraints attached to an element or a
collection of elements.
iii. Common Division:- In modeling Object Oriented systems,
the world often gets divided in several ways. First, there is
the division of class and object.

UML 5/9/2019 17
 A class is an abstraction; an object is one concrete
manifestation of that abstraction. Graphically, the UML
distinguish an object by using the same symbol as its class and
then simply underlying the objects name.
iv. Extensibility Mechanisms: – UML is open ended language,
making it possible for You to extend the language in
controlled ways:
 There are two Stereotype:-

 Stereotype is used when you are modeling a network, you


might want to have symbols for routers and hubs; then we use
stereotype nodes to make these things appear as primitive
building blocks.

UML 5/9/2019 18
1. Tagged value:- A tagged value extends the properties of
UML building blocks ,Allowing user to create new
information in that elements specification.
2. Constraint:– This allows user to add new rules or modify
existing ones.

UML 5/9/2019 19
 UML diagrams are the ultimate output of the entire discussion.
All the elements, relationships are used to make a complete
system model.
 UML diagram represents a system.
 The visual effect of the UML diagram is the most important
part of the entire process.
 UML includes the following nine diagrams

UML 5/9/2019 20
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Activity diagram
7. State chart diagram
8. Deployment diagram
9. Component diagram

UML 5/9/2019 21
 Gives an overview of a system by showing its classes and the
relationships among them.
• Class diagrams are static
• They display what interacts but not what happens when they
do interact
 Also shows attributes and operations of each class
 Good way to describe the overall architecture of system
components
 We draw Class Diagrams under three perspectives
• Conceptual
 Software independent
 Language independent
• Specification
 Focus on the interfaces of the software
• Implementation
 Focus on the implementation of the software
TariffSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TariffSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations

 A class represent a concept


 A class encapsulates state (attributes) and behavior
(operations).
 Each attribute has a type.
 Each operation has a signature.
 The class name is the only mandatory information.
tarif_1974:TariffSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

 An instance represents an object.


 The name of an instance is underlined and can contain the
class of the instance.
 The attributes are represented with their values.
 A class is a rectangle divided into three parts
◦ Class name
◦ Class attributes (i.e. data members, variables)
◦ Class operations (i.e. methods)
 Modifiers
◦ Private: -
◦ Public: +
◦ Protected: #
◦ Static: Underlined (i.e. shared among all members of the
class)
 Abstract class: Name in italics Employee
-Name : string
+ID : long
#Salary : double
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
 Lines or arrows between classes indicate relationships
◦ Association
 A relationship between instances of two classes, where one
class must know about the other to do its work, e.g. client
communicates to server
 indicated by a straight line or arrow
◦ Aggregation
 An association where one class belongs to a collection, e.g.
instructor part of Faculty
 Indicated by an empty diamond on the side of the collection
◦ Composition
 Strong form of Aggregation
 Components cannot exist without the aggregate
 Indicated by a solid diamond on the side of the collection
◦ Inheritance
 An inheritance link indicating one class a superclass
relationship, e.g. Dog is part of mammal
 Indicated by triangle pointing to superclass

UML 5/9/2019 28
 Shows instances of Class Diagrams and links among them
◦ An object diagram is a snapshot of the objects in a system
with a selected focus
 Interactions – Sequence diagram
 Message passing – Collaboration diagram
 Operation – Deployment diagram
 Format is
◦ Instance name : Class name
◦ Attributes and Values
◦ Example:
 Used during requirements elicitation
to represent external behavior
 Actors represent roles, that is, a type
of user of the system Passenger
 Use cases represent a sequence of
interaction for a type of
functionality; summary of scenarios
 The use case model is the set of all
use cases. It is a complete PurchaseTicket
description of the functionality of the
system and its environment

UML 5/9/2019 32
 An actor models an external entity
which communicates with the
system:
◦ User
◦ External system Passenger
◦ Physical environment
 An actor has a unique name and an
optional description.
 Examples:
◦ Passenger: A person in the train
◦ GPS satellite: Provides the
system with GPS coordinates

UML 5/9/2019 33
A use case represents a class of
functionality provided by the
system as an event flow.
A use case consists of:
 Unique name PurchaseTicket
 Participating actors

 Entry conditions

 Flow of events

 Exit conditions

 Special requirements

UML 5/9/2019 34
Name: Purchase ticket Event flow:
Participating actor: Passenger 1. Passenger selects the
Entry condition: number of zones to be traveled.
2. Distributor displays the
 Passenger standing in front of
amount due.
ticket distributor.
3. Passenger inserts money, of
 Passenger has sufficient
at least the amount due.
money to purchase ticket.
4. Distributor returns change.
Exit condition: 5. Distributor issues ticket.
 Passenger has ticket.

UML 5/9/2019 35
 Determining requirements
◦ New use cases often generate new requirements as the
system is analyzed and the design takes shape.
 Communicating with clients
◦ Their notational simplicity makes use case diagrams a good
way for developers to communicate with clients.
 Generating test cases
◦ The collection of scenarios for a use case may suggest a
suite of test cases for those scenarios.

UML 5/9/2019 36
 Formal methods have the potential to improve both quality
and productivity in software development
• to enhance early error detection
• to develop safe, reliable, secure software-intensive systems
• to facilitate verifiability of implementation
• to enable simulation, animation, proof, execution,
transformation
 Formal methods are on the border of becoming best practice
and/or required practice for developing safety-critical and
mission-critical software systems
 To avoid problem consequences
 To ensure that systems meet regulations and standards

UML 5/9/2019 37
 If software is complex
 If a system is developed by hundreds of People there is also
need of model for smooth communication and understanding
the software system
 Mange complexity in design
 Build and design architecture
 Visualize the implementation
 Design secure , scalable and extendable system

UML 5/9/2019 38
1. Briefly describe Sequence diagram, Collaboration diagram,
Activity diagram, State chart diagram, Deployment diagram,
Component diagram.
2. Briefly describe about Implementation coding standards and
stepwise refinement
3. Imagine one system and draw the use case diagram of the
system

UML 5/9/2019 39

You might also like