unified modeling language i. · unified modeling language i. ... outline software engineering...

Unified Modeling Language I.

Software engineering

Szoftvertechnológia

Dr. Balázs Simon

BME, IIT

Outline


Modeling

Unified Modeling Language (UML)

UML Diagrams: Use Case Diagram

Activity Diagram

Component Diagram

Deployment Diagram

2Dr. Balázs Simon, BME, IIT


Dr. Balázs Simon, BME, IIT 3


Software is everywhere: operating systems (Windows, Unix, Android, iOS, etc.) office tools (Word, Excel, Chrome, Firefox, Photoshop, etc.) entertainment (YouTube, Facebook, etc.) everyday tools (hairdryer, washing machine, etc.) safety critical systems (cars, airplanes, rockets, nuclear power

plants, robotic surgery, etc.)

“Software engineering is the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”Systems and software engineering - Vocabulary, ISO/IEC/IEEE std 24765:2010(E), 2010.


Why is software engineering hard?

Software can be very large Windows 10: ~50 million lines of code the complete Google software codebase in 2015: ~2 billion lines of

code, 45000 changes a day large software cannot be written by a single person

The software industry is young (~50 years old) we have had roads, bridges and buildings for thousands of years we have widely accepted standards and prebuilt parts in the

construction industry the software industry doesn’t have the range of prebuilt standard

components that other industries have

Most of the software is custom built since there are no prebuilt components for everything constructing the software is a creative process most parts of a software are new and unproven, hence they must be

tested but the inherent complexity of the software makes it hard to test


Why is software engineering hard?

Custom built software is ordered by the users of the software, who don’t know what they want users do not have the expertise of a software engineer, they can’t

specify exactly what they want users usually don’t know what they really want until they can see it

and try it out the time and money resources assigned to develop the software can

easily run out due to the changing requirements estimating the time and money for a software development project is

an art, not a science software engineers must prepare for changing requirements in

advance

Software engineer ≠ programmer software engineers design the software before they start coding in the design they have to take into account the needs of the users

and the changing requirements software engineers must know which algorithm to apply and when experienced software engineers do things quicker and better, with less

code and with fewer defects


Software development processes

Software development consists of the following processes: Requirements analysis and specification: finding out what the user wants Design: designing the architecture, components and behavior of the

software Implementation: developing and integrating the components Testing: systematic discovery and debugging of defects Delivery: installing the software for end users, education of users Maintenance: keeping the software running, fixing bugs

These are not steps! These are processes that follow the development of the software throughout its entire life cycle!

Software is usually developed in multiple iterations all of the above processes can be involved in each iteration, usually in the

following order:

each process may have a different importance depending on the iteration, e.g. requirements analysis is more important in the first iteration, while maintenance is more important in the later iterations


Requirements Design Implementation Testing Delivery Maintenance

Modeling

A model is a simplified reflection of reality

A good model emphasizes essential details and omits irrelevant ones

Example: Budapest underground map essential details:

names of stops

order of stops

transfer points

irrelevant details: streets

distances between stops

color of the tunnel


Other modeling examples

Model of the solar system: essential details: mass, speed and distance of planets

irrelevant details: e.g. atoms the planets are built of

Wind tunnel model of a plane: essential details: shape, aerodynamics

irrelevant details: e.g. number of seats, food served, pilot

Ticket reservation model of a plane: essential details: number of seats, food served

irrelevant details: e.g. shape, aerodynamics, pilot


Views

The essential and irrelevant details depend on: what the model is used for who will read the model

The more information the model has to cover the more complex it becomes

Sometimes the same model is used for multiple purposes and viewed by different target audiences we can create many views of the same model each view shows only the relevant details for the given purpose and to the

given target audience

Example: same model with different views:


UML

Unified Modeling Language

Standard for modeling software systems standardized by Object Management Group (OMG)

The UML standard defines multiple diagram types: each diagram provides one view of a model of a system

The UML standard specifies: syntax: how the elements of a diagram (view) look like

semantics: what the model shown in a diagram means

Both the syntax and the semantics are important

The semantics shown in different diagrams must be consistent with each other, otherwise, the underlying model is meaningless and useless


UML semantics

There are two main important aspects of a model in UML: Structural semantics (static semantics): defines the meaning of

model elements about individuals in the domain being modeled, which may be true at some specific point in time

Behavioral semantics (dynamic semantics): defines the meaning of model elements that make statements about how individuals in the domain being modeled change over time

Different diagram types show different aspects of a model


UML diagram types


Use case diagram

Deployment diagram

Component diagram

Class diagram Package diagram

Object diagramComposite

structure diagramProfile diagram

Activity diagram Sequence diagramCommunication

diagram

State diagram Timing diagramInteraction

overview diagram

Structural UML diagrams:

Behavioral UML diagrams:

Use Case Diagram


Use Case Diagram

Captures the functional requirements of the system what the system is supposed to do and how the system is used

models the users and the scope of the system

simple enough for stakeholders to understand it

Example: Pac-Man game


Player

Control Pac-Man

View Maze


Player

Control Pac-Man

View Maze

Use Case Diagram

Actor: a role of a user that interacts with the system can be a person or an outside system (a physical user can interact with the system in multiple roles)

Use case: represents a dialog between users and the system from the users’ point of view a specific sequence of actions and interactions between the actors and the

system

Association: connects an actor with a use case he/she/it is involved in


ActorUse case

Association

Use case description example: Buy item


Use case: Buy item

Actors: Customer, Cashier

Main Success Scenario: 1. The Customer picks the item 2. The Customer hands the item to the Cashier 3. The Cashier records the item 4. The Cashier asks for money from the Customer 5. The Customer pays the amount to the Cashier 6. The Cashier gives the item and the receipt to the Customer

Alternative 5.A: 5.A.1. The Customer has not enough money 5.A.2. The Customer leaves empty handed

Customer

Buy item

Cashier

Use Case Diagram: Relationships

Between an actor and a use case: Association:

connects an actor with a use case he/she/it is involved in

Between actors: Generalization:

the special actor is a kind of general actor the special actor can do all the use cases the general actor can

Between use cases: Generalization:

the special use case is a kind of general use case the special use case makes the behavior of the general use case more

specific <<extend>>:

the extending use case provides some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more extended use cases at their extension points

<<include>>: the behavior of the included use case is inserted at some point into the

including use case


Customer

Admin

Login

Place order

Manage user privileges

Login via GoogleLogin via Facebook

Modify order

<<extend>>

Make payment

<<include>>

Relationship examples


Association

Generalization

Generalization

Include

Extend

Use case description template (not defined in UML)

Title: goal the use case is trying to satisfy usually: verb + noun

Actors: the participants of the use case

Main Success Scenario: numbered list of steps step: <a simple statement of the interaction between the actor

and the system>

Alternate Scenarios: separately numbered lists, one per Alternative Alternative: <a condition that results in different interactions

from .. the main success scenario>

an alternative deviating from main step 7 is numbered 7.A., etc.


Use case description example: Buy item


Use case: Buy item




Customer

Buy item

Cashier

More detailed use case description

There is no standard way to write the content of a use case

The template from the previous slides shows the most common form

But there can be many more fields in a use case description (Cockburn’s fully dressed use case): Title, Primary Actor, Goal in Context, Scope, Level, Stakeholders

and Interests, Pre-conditions, Post-conditions (Minimal Guarantees, Success Guarantees), Trigger, Main Success Scenario, Extensions, Technology & Data Variations List

Possible other fields: Unique identifier, Frequency of use, Exceptional cases, Covered

requirements


Webshop

Customer

Admin

Login

Place order


Login via Google

Login via Facebook

Modify order

<<extend>>

Make payment

<<include>>

Use Case Diagram: System boundary box (optional)

System boundary box: a box that sets a system scope to use cases all use cases outside the box are outside the scope of that system


System boundary

System name

Order management

User management

Customer

Admin

Login

Place order


Login via Google

Login via Facebook

Modify order

<<extend>>

Make payment

<<include>>

Use Case Diagram: Package (optional)

Package: allows putting different elements in a group


Package

Package name

UML diagram types


Use case diagram

Deployment diagram

Component diagram





diagram


overview diagram



Activity Diagram


Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency

Activity diagrams are typically used for modeling: the behavior captured by a single use case

a business process or workflow between users and the system

the steps of an algorithm

Activity diagrams provide a formal way of describing functionalrequirements as workflows

Activity diagrams can be developed in various levels of detail e.g. first at a high abstraction level, then at a lower abstraction level

by refining the stepsDr. Balázs Simon, BME, IIT 28


Reminder from earlier: Buy item use case


Use case: Buy item




Customer

Buy item

Cashier

Customer Cashier

Hand item over

Pick an item

Record item

Ask money

Leave empty handed Pay money

Accept money

Give item and receipt

[ not enough money ] [ has enough money ]

Activity Diagram example: Buy item use case I.


Partition

Partition

Initial node

Activity

Control flow

Partition name

item

money

Object

Object flow

Hand item over

Pick an item

Record item

Ask money

Leave empty handed Pay money

Accept money

Give item and receipt

Leave with item and receipt

[ not enough money ] [ has enough money ]

Activity Diagram example: Buy item use case II.


Final node

item

money

Final node

Decision nodeGuard

condition

item and

receipt

Activity Diagram

Activity: used to model the individual steps in the behavior specified by the Activity

Diagram

Initial node: acts as a starting point for executing an activity has no incoming edges an activity can have multiple initial nodes: in this case several flows start in this

activity

Control flow: directed connection between two activities (source and target) designates flow of execution: the target activity is started when the source

activity is completed

Final node: at the final node the execution flow is stopped

Decision: chooses between outgoing control flows based on their guard conditions at most one outgoing flow is executed

Guard condition: condition attached to a control flow the flow can only become active if the guard condition evaluates to true


Activity Diagram

Partition: a user (role) or part of the system along a dimension drawn as a swimlane activities inside the swimlane are performed by the

corresponding user (role) or system part partitions can be hierarchic: they can have subpartitions

Partition name: name of the user (role) or part of the system corresponding to

the given partition shown in the header of the swimlane notation

Object: represents data that can be passed between activities

Object flow: carries data between activities


Select item

Retrieve item

Make item

[ item in stock ]

[ out of stock ]

Send item

Activity Diagram: decision and merge

Decision: chooses between outgoing flows

at most one outgoing flow is executed based on the guard conditions

Merge: brings together multiple flows without synchronization

if multiple incoming flows are active, merge is executed multiple times


Guard condition

Merge

Decision

Guard condition

Activity Diagram: fork and join

Fork: flow is split into multiple concurrent (parallel) flows

Join: synchronizes (awaits) multiple flows

by default all incoming flows must complete so that the Join can be executed(this behavior can be overridden through a join expression)


Select destination Select departure and return time

Reserve flight

Reserve hotel

Rent a car

Print reservations

Fork Join

Activity Diagram: call activity

Call activity: a call activity invokes another activity

the behavior of the invoked activity can also be described by an Activity Diagram

hence, activities can be nested within each other

Activity Diagrams can show different levels of detail


Call activity

Take time off work Make travel reservations Travel

Activity Diagram: final nodes

Two kinds of final node: Activity final node: ends the entire behavior shown in the

Activity Diagram, all the flows are stopped

Flow final node: only the given flow is stopped, other flows in the diagram continue to execute


Make rocket part

Build part into rocket

[ more parts to be built ]

[ no more parts to be built ] [ parts missing ]

Launch rocket[ rocket complete ]

Activity final node

Flow final node

Initial node

Activity Diagram: signals

Activities can also be started by events (signals) instead of an initial node

Events can be accepted at the beginning or even in the middle of a behavior described by an Activity Diagram

Actions related to signals: Accept event action: waits for an event (signal) to occur, and starts a

new flow when it does Send signal action: sends a signal, which can be accepted by an accept

event action


Process orderReceive order Request payment Payment confirmed Ship order

Accept event action Accept event action

Send signal action

Activity Diagram: time events

Accept time event action: starts a flow in the activity diagram at a definite point in time

Examples:


Make ice cream Put the ice cream into the freezer Eat the ice cream

Wait 2 hours

Create monthly report

End of month

Accept time event action

Accept time event action

UML diagram types


Use case diagram

Deployment diagram

Component diagram





diagram


overview diagram



Component Diagram


Component Diagram

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. (Szyperski)

The Component Diagram shows the components of a system and the connections between them

The Component Diagram is usually used during design, but can be successively refined in deployment and run-time



Component Diagram example: Mobile+web application


Mobile client<<component>>

Website<<component>>

Business logic<<component>>

Data<<component>>

An overview Component Diagram shows components related by dependencies

Dependency: “A” depends on “B” means that if “B” changes then the change may affect “A”, too

The kind of the dependency is not specified

Lack of dependency where there are no dependency arrows

Component

Dependency(Website depends on Business logic)

Component notation

Three possible notations, they are equivalent: rectangle with icon

rectangle with component keyword (stereotype)

rectangle with component keyword (stereotype) and icon


WebsiteWebsite

<<component>>Website

<<component>>

Stereotype Stereotype IconIcon

Component Diagram example: Computer

A more detailed Component Diagram shows components with their provided and required interfaces and the connections between them



Website

<<component>>

Data<<component>>

Mobile client

<<component>>

IWeb

IData

Component

Provided interface

Required interface

Interface name

IClient

Component Diagram example: Computer

Provided and required interfaces can be wired through dependencies



Website

<<component>>

Data<<component>>


IWeb

IData

IClient

Component

Provided interface

Required interface

Interface nameIClient

IWeb IData Dependency

Business logic

<<component>>

IData<<interface>>

IClient<<interface>>

IWeb<<interface>>

<<use>>

47

Provided and required interfaces

Three possible notations, they are equivalent: component with lollipops and sockets

component with compartments

component with realizations and dependencies

Dr. Balázs Simon, BME, IIT

Business logic

<<component>>

IData

IWebBusiness logic<<component>>

provided interfaces

IWeb

required interfaces

IClient

IData

IClient

Required interface(socket)

Provided interface(lollipop)

Provided interfacescompartment

Required interfacescompartment

Interface(see later...)

Realization

Dependency

Composite component

A composite component is implemented by other components

Externally provided and required interfaces are exposed through ports

Delegation connectors connect externally provided and required interfaces to internal components that realize or require them



Save and load

<<component>>

Game logic<<component>>

IDataIWeb

IData

IWeb ISaveLoad

Port

Delegationconnector

Delegationconnector

Port

internal structure

IClientIClient

UML diagram types


Use case diagram

Deployment diagram

Component diagram





diagram


overview diagram



Deployment Diagram


Deployment Diagram

The Deployment Diagram specifies constructs that can be used to define the execution architecture of a system and the assignment of software artifacts to system elements

Deployment Diagrams can be used to model the hardware and software topology of the system

The Deployment Diagram is usually used during delivery for planning the deployment architecture



Deployment Diagram example: Mobile+Web application

The architecture of the system is shown as nodes and communication paths between them


:Android

:IBM server

:MySQL server

NodeCommunication path

Artifacts example: Mobile+web application


An artifact represents some (usually reifiable) item of information that is used or produced by a software development process or by operation of a system e.g. executable file, script, database table, document, etc.

An artifact can be a manifestation of a component


Website<<component>>


Data<<component>>

Data.sql<<artifact>>

Business.jar<<artifact>>

Website.jar<<artifact>>

client.apk<<artifact>>

<<manifest>>

<<manifest>>

<<manifest>> <<manifest>>

Artifact

Component

Manifestation


Artifacts can be deployed to nodes

Dependencies can also be shown between artifacts



:IBM server

:MySQL server:Android

Website.jar

<<artifact>>




ArtifactDependency


The deployed artifacts can also be assigned to nodes using dashed arrows with deploy keyword (stereotype) (this diagram is equivalent with the one on the previous slide)



:IBM server :MySQL server:Android

Website.jar<<artifact>>




<<deploy>> <<deploy>> <<deploy>> <<deploy>>

Artifact Dependency

Deployment

UML diagram types


Use case diagram

Deployment diagram

Component diagram





diagram


overview diagram



Summary


Summary


Modeling


UML Diagrams: Use Case Diagram

Activity Diagram

Component Diagram

Deployment Diagram


UML diagram types


Use case diagram

Deployment diagram

Component diagram





diagram


overview diagram



unified modeling language i. · unified modeling language i. ... outline software engineering...

Documents