Diagramet UML

MSc. FLORINDA IMERI, ASS

 Component-Based Development Model
2

 An iterative, reminiscent of the spiral model

 The applied framework for design &
implementation: object orientation
 Reuse existing class libraries (an 84% reduction in
project cost)
 Object Orientation
3

 The basis for OOP started in the early 1960s.

 The first programming language to use objects was
Simula 67.
 It was designed for the purpose of creating
simulations, and was developed by Kristen Nygaard
and Ole-Johan Dahl in Norway
 Later C++ (1985), Java (1995), .NET
 UML History
4

 Identifiable object-oriented modeling languages

began to appear between mid-1970 and the late
1980s as various methodologists experimented with
different approaches to object-oriented analysis and
design.
 In the 90’s: Booch, Rumbaugh & Jacobson together
coined UML (Unified Modeling Language)
 1997: UML 1.0 submitted to OMG (Object
Management Group) for standardization
 Overview of UML
5

 Unified Modeling Language (UML) is a

standardized general-purpose modeling language in
the field of software engineering.
 UML includes a set of graphical notation techniques
to create abstract models of specific systems.
 The Unified Modeling Language (UML) is an open
method used to specify, visualize, construct and
document the artifacts of an object-
oriented software.
 UML
6

 UML offers a standard way to write a system’s

blueprints (plan), including conceptual components
such as:
 actors,

 business processes and system's components, and

 activities

 As well as concrete things such as:

 programming language statements,

 database schemas, and

 reusable software components.

 UML
7

 UML combines the best practice from data

modeling concepts such as:
 entity relationship diagrams,
 business modeling
 object modeling and
 component modeling.
 It can be used with all processes, throughout
the software development life cycle, and across
different implementation technologies.
 UML
8

 UML has succeeded the concepts of the

 Booch method,
 A technique used in software engineering. It is an object modeling
language and methodology that was widely used in object-oriented
analysis and design. It was developed by Grady Booch
 Object-modeling technique (OMT) and
 Object-oriented software engineering (OOSE)
 by fusing them into a single, common and widely
usable modeling language.
 UML
9

 UML aims to be a standard modeling language which

can model concurrent(njekohshme) and distributed
systems.
 UML is not an industry standard, but is taking shape
under the auspices of the Object Management
Group (OMG).
 Structure diagrams
10

 Structure diagrams emphasize what things must be

in the system being modeled:
 Class diagram: describes the structure of a system by
showing the system's classes, their attributes, and the
relationships among the classes.
 Component diagram: depicts how a software system is
split up into components and shows the dependencies
among these components.
 Composite structure diagram: describes the internal
structure of a class and the collaborations that this
structure makes possible.
 Structure diagrams
11

 Deployment diagram serves to model the hardware

used in system implementations, and the execution
environments and artifacts(mjetet) deployed on the
hardware.
 Object diagram: shows a complete or partial view of
the structure of a modeled system at a specific time.
 Package diagram: depicts how a system is split up
into logical groupings by showing the dependencies
among these groupings.
 Behavior diagrams
12

 Behavior diagrams emphasize what must happen in

the system being modeled:
 Activity diagram: represents the business and
operational step-by-step workflows of components in a
system. An activity diagram shows the overall flow of
control.
 State machine diagram: standardized notation to
describe many systems, from computer programs to
business processes.
 Use case diagram: shows the functionality provided by
a system in terms of actors, their goals represented as use
cases, and any dependencies among those use cases.
 Interaction diagrams
13

 Interaction diagrams, a subset of behavior diagrams,

emphasize the flow of control and data among the
things in the system being modeled:

 Communication diagram: shows the interactions

between objects or parts in terms of sequenced messages.
They represent a combination of information taken from
Class, Sequence, and Use Case Diagrams describing both
the static structure and dynamic behavior of a system.
 Interaction diagrams
14

 Sequence diagram: shows how objects

communicate with each other in terms of a sequence
of messages.
 Timing diagrams: are a specific type of interaction
diagram, where the focus is on timing constraints.
 Most in-Use UML Diagrams
15

 Use case diagrams

 Class diagrams
 Sequence diagrams
 State diagrams
 Activity diagrams

Examples taken from [Miller at www.borland.com]

 Use Case Diagrams
16

 Describe the system as a black box – what to do from

the user’s perspective, not how to do it
 Are a set of scenarios, e.g. examples of what happens
when a given task is to be performed
 Elements:
 Actors - people with assigned roles
 Use cases- is a summary of scenarios for a single task or goal
 Communications - connections between actors & use cases
Use Case Diagrams: A Medical Clinic
17
 Where the Use for Use-Cases?
18

Use case diagrams are helpful in three areas.

 determining features (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.
 Class Diagrams
19

 Class diagrams describes the structure of a system by

showing the system's classes, their attributes, and
the relationships among the classes
 Class diagrams are static - they display what
interacts but not what happens when they do
interact.
Class Diagrams: Customer Order
20
 Class Diagrams: Relationships
21

 Association: A relationship between two objects

 Aggregation: An association in which one class
belongs to a collection
 Generalization: A hierarchy indicating the
inheritance

 Every class diagram has classes, associations, and

multiplicities.
 Class Diagrams: Relationships
22

Navigability (optional): Shows which direction the association

can be queried, e.g., the owner of the association (notation:
an arrow; default: bi-directional)

Multiplicity: A number of possible instances of the class

associated with a single instance of the other end (notation: a
number or a range of numbers)
 Sequence Diagrams
23

 Class diagram is a static model.

 Interaction diagrams including sequence
diagram are dynamic.
 Is an interaction diagram that describes how
operations are carried out, and consists of two
main components:
 messages sent (left-to-right arrows)
 time (top-down)
Sequence Diagrams: A Hotel Reservation
24
 More on Sequence Diagrams
25

 Lifetime: the time that an object exists (vertical

dotted line)
 Activation bar: the duration of execution of the
message
 Self call: the sender and receiver of the message are
the same (notation: a cyclic arrow)
 Iteration: an asterisk
 Condition: within square brackets ’[]’
 Note: clarifying text, can be put into any kind of
UML diagrams
 Statechart Diagrams
26

 States are rounded rectangles.

 Transitions are arrows from one state to another.
 Events or conditions that trigger transitions are
written beside the arrows.
 Our diagram has two self-transition, one on Getting SSN and
another on Getting PIN.
 The initial state (black circle) is a dummy to start the
action.
 Final states are also dummy states that terminate the
action.
Statechart Diagrams: On-line Bank Login
27
 Activity Diagrams
28

 Activity diagrams and statechart diagrams are

related.
 An activity diagram focuses on the flow of activities
involved in a single process.
 Activities (notation: rounded rectangles)
 Start/end of a process (notation: black circle,
white/black circle)
 Transitions- connections between activities
 Branch guard expressions (notation: inside ’[]’)
 fork, join (notation: solid bars)
 Activity Diagrams
29

 Activity diagrams can be divided into

object swimlanes that determine which object is
responsible for which activity.
 A single transition comes out of each activity,
connecting it to the next activity.
 A transition may branch(dege) into two or more
mutually exclusive transitions.
Activity Diagrams: Withdraw Money
30
 Summary of UML
31

 Integrated view: thanks to the class concept, data &

operations can be held in one common unit
 A common language thanks to the same
representation
 formalism throughout requirements, specs, design and
implementation, the feedback communication over the
subsequent steps easily maintainable
 Widely spread: by users, programmers, software
vendors
 32

 http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/
UML_tutorial/what_is_uml.htm