Seminar

1

• Seminar
• The Unified Modeling Language (UML)

2
Code as a representation of a piece of software

• package codemodel
• public class Guitarist extends Person implements
  MusicPlayer
• Guitar favoriteGuitar
• public Guitarist (String name) super(name)
• // A couple of local methods for accessing the
  class's properties
• public void setInstrument(Instrument instrument)
  
• if (instrument instanceof Guitar)
• this.favoriteGuitar (Guitar) instrument
• else
• System.out.println("I'm not playing that
  thing!")
• public Instrument getInstrument( ) return
  this.favoriteGuitar

• It represents only the logic of its behavior,
  nothing else.
• It is caught by humans very slowly
• It does not help to reuse the design decisions

3
Natural language for representing software
Guitarist is a class that contains six members
one static and five non-static. Guitarist uses,
and so needs an instance of, Guitar however,
since this might be shared with other classes in
its package, the Guitar instance variable, called
favoriteGuitar, is declared as default. Five of
the members within Guitarist are methods. Four
are not static. One of these methods is a
constructor that takes one argument, and
instances of String are called name, which
removes the default constructor. Three regular
methods are then provided. The first is called
setInstrument, and it takes one parameter, an
instance of Instrument called instrument, and has
no return type. The second is called
getInstrument and it has no parameters, but its
return type is Instrument. The final method is
called play. The play method is actually enforced
by the MusicPlayer interface that the Guitarist
class implements. The play method takes no
parameters, and its return type is void.

• It is ambiguous and even confusing
• It takes a while to catch and reason about it
• It is difficult to process.

4
Visual models for representing a piece of software
5
Unified Modeling Language

• The Unified Modeling Language (UML) is a
  conceptual modeling language based on an object
  oriented methodology.
• The objective of UML is enabling the
  representation of models for systems in general
  but in particular for software applications.
• A model is a set of abstractions that represents
  a system in order to cope with its complexities
  in a given domain.
• A UML model is formed by
• A set of modeling elements and rules that define
  the structure and functionality of the system
  collected in a common repository.
• The presentation of those concepts by means of
  multiple graphical views, which formalize the
  creation and edition of the models according to
  the rules of the language and the purpose of the
  model.

6
Advantages of UML

• It is based on a metamodel with a defined
  semantics.
• Proposes a concrete graphical notation easy to
  use and learn.
• It is an international standard supported and
  maintained by a solid standardization board, the
  Object Management Group (OMG).
• It is independent of any concrete commercial tool
  vendor.
• It is quite scalable, it allows the
  representation and management of massive as well
  as small systems models.
• It is a language that was originally conceived
  and has evolved mainly as a development tool for
  software applications.

7
Basic semantic aspects of a system in UML

• Functional aspects It describes the functional
  specification of a system, independently of its
  implementation. It covers the usage of the system
  and the ways it is expected to react.
• Structural aspects It describes the elements
  that form the model as well as the parameters
  that characterize them in a quiantitaive way, and
  the relationships among them.
• Behavioral aspects It describes the inner
  behavior of the elements, concrete scenarios for
  their dynamics, and the externally visible
  interaction between groups of them.

8
UML diagrams

• Static Organizational/structural modeling
  resources
• For modeling systems functionality
• Use Case diagrams
• For modeling systems architecture
• Class diagrams
• Components diagrams
• Dynamic Behavioral modeling resources
• For the dynamics of an element
• State charts (event driven model)
• Activity diagrams (operational model/flow charts)
• For concrete execution scenarios
• Sequence diagrams
• Collaboration diagrams

9
Views of a UML model.

• A UML model may target different levels of
  detail
• Architectural models they express high level
  qualitative information.
• Detailed models they contain information for the
  validation of certain properties of the system,
  the code generation or other model
  transformations.
• There is not just one graphical view that
  expresses the whole semantics of the system. The
  full semantics is stored in the repository.
• Having multiple views allows the modeler to
  focus attention on specific aspects with the
  proper level of detail
• Use case view
• Classes view
• Deployment view
• Components view
• Graphical views are the mean to introduce the
  model in the repository.
• The management of a UML model requires a specific
  tool that keeps the model consistent along the
  development process.

10
Basic structural modeling elements

• The basic structure of a system is described
  using a reduced set of low level modeling
  elements
• Object it is a run time concept that keeps
  linked a data structure with the set of
  operations that act on them.
• The data stored in the object define its state
  and are called attributes or properties.
• The procedures and/or functions that expose the
  behavior and/or the interaction protocol of the
  object and act over its data are called methods
  or operations..
• Class it is a design time concept that describes
  the common characteristics of all objects of a
  kind. Objects are individual instances of a
  class.
• Interface it holds the signature of a set of
  operations, which as a whole defines a service, a
  protocol, or a behavior disregarding the way them
  may be implemented. It is meant for reusability
  of conceptual behaviors. An interface may not
  have objects, it has to be implemented by a
  class, which in turn may have objects exposing
  such functionality.

11
Class

• It models the commonalities of a set of objects
  that share
• The same kinds of properties (Attributes)
• The same behavioral units (Operations)
• The same relations with other objects
  (Associations)
• A common basic semantics (eventually common
  Stereotypes)
• The analysis tries to identify the types of
  objects (classes) that are key to understand the
  problem that is to be solved.
• To identify the relevant classes, the analysis
  process encompasses
• Identify names of objects that appear in the
  problem description.
• Simple characteristics may indicate attributes
  while complex elements may indicate objects of
  other classes.
• Classes may be categorized by generalization by
  defining abstract classes.
• Classes are described identifying their
  attributes, the operations they offer to other
  classes objects, and the behavior they hold.
• The systems behavior is described by
  collaborations among classes.

12
Graphical representation of a class in UML
13
Class Diagrams
14
Declaration of Interfaces
SensorClient
ltltActivegtgt
PreassureSensor
acquire getValue setCalibrationConstant
I_Sensor
ltltdependgtgt
ltltrealizesgtgt
ltltInterfacegtgt
I_Filter
LowPassFilter
filterValue(valueInteger)Integer
-lowPassParam Integer
filterValue(valueInteger)Integer
init(lpInteger)
15
High-level structural modeling elements

• These elements describe the system architecture
  from a high level of abstraction point of view
• Package It is a container, used to manage
  modeling elements in an organized way.
• Subsystem This is a very high-level structural
  element, used to decompose the whole system into
  complementary blocks usually with a clearly
  distinctive functional interaction among them.
• Component A set of modeling elements that group
  them as a replaceable whole. This implies the
  need to specify its offered as well as its
  required interfaces.
• Node It models a physical computational element
  on which software elements can be executed.

16
Example of packages
Medical Stuff
Temperature
Patient Parameter
Heart Rate

PVC Count
Patient
User Interface Stuff
view
ltltdomaingtgt
Window Control
Window
Histogram Control
Waveform Control
Scrollbar
Icon Control
17
Subsystems
ltltinterfacegtgt
I_Power
ltltsubsystemgtgt
Power Subsystem
requestPower(ampsFloat)
Switch
ltltrealizesgt
Battery
Power Source
Solar Panel
Voltmeter
I_Battery
18
Components and nodes
Physician
ECG Acquisition Module
Display Computer
TC/IP Stack
Patient Data Base
GUI
Ethernet
Data Adquisition
Medical Monitoring
Patient
TC/IP Stack
Math Library
19
Structural elements hierarchy
ltltsystemgtgt
ltltsubsystemgtgt
ltltsubsystemgtgt
ltltsubsystemgtgt
ltltsubsystemgtgt
ltltcomponentgtgt
ltltcomponentgtgt
ltltcomponentgtgt
ltltcomponentgtgt
ltltactivegtgt
ltltactivegtgt
ltltpasivegtgt
20
Associations

• They abstract relationships like
• Aggregation It is part of
• Simple aggregation It is contained in
• Composition It is composed of...
• Generalization It is a kind of...
• Inheritance It extends...
• Specialization It specializes...
• Dependency
• Link Have access to
• Abstraction (ltltrefinegtgt, ltltrealizegtgt,...)
• Bind (Between generic and concrete classes)
• Usage (Make use of..., Have visibility to...)
• Permission (ltltfriendgtgt, ltltsongtgt,...)

Clase A
Clase B
Clase A
Clase B
Clase A
Clase B
21
Examples of associations
Base
Lámpara
Pantalla
Incandescencia
Conmutador
Fluorescente
Cables
Reactancia
Casquillo
Cebador
Base_bayoneta
22
Associations multiplicity
Grade
1 One and only one
0..1 Zero or one
0..n Zero or more
1..n One or more
Unspecified
Assignment
Diplome
Student
1..n
0..n
Title
Name
Mark
1
Do
0..n
0..1
1
Room
Number
23
Constraints on associations
0..n
1
Person
Account
Ordered
Professor
University
Person
1..n
exclusive OR
1..n
Student
Person
Parent
1..2
Son
0..n
24
Examples of associations in a class diagram
25
Modeling the behavior

• The resources offered by UML to describe the
  dinamic behavior of structural elements like
  objects, classes, systems, subsystems and
  components at run time are presented in
• State charts They are used to describe the
  internal evolution of a class or method due to
  the occurrence of external o internal events. It
  exposes the states in which the element can be
  and the events that trigger transitions between
  them..
• Activity diagrams Represent the flow of
  execution of a method.
• Sequence diagrams They show concrete
  interactions between objects formulated as
  sequences of events or messages organized in
  time.
• Collaboration diagrams They work as sequence
  diagrams but highlight the concrete elements that
  participate and their links instead of the
  evolution of the interactions in time.

26
Actions and Activities

• Action It abstracts an executable primitive that
  is able to cause a change in the system state
  generation of an event, change in the value of an
  attribute or link, etc.
• It models a simple statement with the run to
  completion semantics (It runs disregarding
  others until it finishes)
• Some kinds of actions
• CreateAction (constructor) or Destroy Action
  (deletion of an object).
• CallAction (synchronous invocation of an
  operation).
• ReturnAction (return of control from an
  operation) or TerminateAction (return of control
  signaling the end of a sequence of actions)
• SendAction (asynchronous transference of an
  event)
• ActionSequence) (an action composed by a sequence
  of them)
• Activity It is a sequence of actions that
  execute in the context of a particular state of
  an object. It finishes when the object changes
  its state, which may occur due to the arrival of
  an external or timed event, or because the
  sequence finishes.
• It does not imply the assumption of a run to
  completion semantics

27
State charts

• They are used to describe the behavior of
  structural elements or methods in a finite state
  machine. This implies to represent the possible
  states of the element and the potential
  transitions among them.
• The actual behavior is specified by actions
  linked to
• Transitions between states
• The entry to each state
• The exit of each state
• The staying in a state may have an activity
  associated.
• UML State charts have significant expressive
  power and scalability
• A state may have an aggregated state chart.
• They can express concurrency by introducing AND
  states.
• Dynamic semantics is supported by using
  pseudo-states.
• Transitions may be guarded and synchronized.

28
Example Garage door
External events - PushBotton - FullyOpen -
FullyClosed - ObstacleFound
Actions - StartUp - StartDown - Stop
Activities - MotorUP - MotorDown -
MotorStop
29
State chart notation
operating
processing
Working
Filtering
Acquiring
evDataReady
entry/dfilterData() do/xXdata(d) do/yYdata(d)

entry/enableSensor() do/DGetData() exit/disable
Sensor()
evAbort
Idle
dataBad
Controlling
Verifying
dataOk
entry/enableMotor() do/SetAxis(x,y) do/DisableM
otor()
entry/CheckData() do/CheckPosition()
testing
evOK
Handling
Checking
tm(CheckTime)
evError
entry/LogError() do/if HANDABLE then
GEN(evOK) else GEN(evBAD)
Waiting
do/ if FAILED then GEN(CheckData()
UnrecoverableError
evBad/GEN(evAbort)
30
Activity diagram

• It might by considered as a special case of a
  state machine used to describe the flow of
  control inherent to the execution of an
  operation.
• It models sequential as well as concurrent flows
  of control.
• The transition between two consecutive states is
  triggered by the end of the activity associate to
  the previous state.
• They are used to describe the internals of the
  algorithms.

31
Elements of the activity diagrams.
Decision
Event_1
Wait event
Activity_C
Activity_A
Tgt20º
Tlt20º
Activity_A finished
Activity_D
Activity_E
State
Activity_B
Activity_F
Event_2
Raise event
32
A usual representation for concurrency.
Activity_A
Swimlane
Generation of concurrent flows (fork)
Thread_3
Thread_2
Thread_1
Activity_D
Activity_C
Activity_B
Activity_E
Convergence of concurrent flows (joint)
Activity_F
33
Additional example of activity diagram.
GraspAt(x,y,z)
Proximity Sensor
evIsNear
Alarm System
area not clear
AnnunciateAlarm
area clear
ComputeJointAngles(a,b)
OpenGrip
Joint 1 to a
Joint 2 to b
RotateGrip
Grasp Object
34
Interaction diagrams

• They serve to model the collaborative behavior of
  groups of structural elements.
• They are formulated as partial/typical/expected
  scenarios with the exchange of messages that
  express the interaction between objects. The
  messages are in practice events, the invocation
  of operations, or the creation/destruction of
  objects.
• There are two behaviorally equivalent
  presentations
• Collaboration diagrams These show concrete
  objects and links, and add to them the messages
  that they interchange ordered by means of a
  numbering notation.
• Sequence diagrams These diagrams present the
  interacting objects, and show the messages they
  exchange as arrows ordered graphically in a
  top-down way, indicating the partial order
  between them.

35
Sequence charts

• This is used to express graphically time ordered
  interactions between objects.
• Such interactions occur between them as an
  expression of their collaborate behavior to
  accomplish the responsibilities of the whole
• Only one of the possible execution scenarios is
  shown. This corresponds to a particular execution
  of a function or use case of the system
• It is the basic mechanism used by a non-expert to
  describe interactions
• A sufficiently large set of sequence charts may
  actually bring the description of the whole
  system behavior, but this is tedious and
  significantly error prone. Other behavioral
  diagrams are used for such specification purposes
  instead.

36
Example A phone call
Time
Caller lifts receiver
Dial tone begins
Dial
Dial tone ends
Dial
Phone rings
Ringing tone
Answer phone
Ringing stops
Tone stops
Hello?
37
Interactions are between objects
Different object may play The same role
Class or role
Anonymous object
Object
38
Timing marks
A.sendgtA.Receive
A
B
A.sendgtB.Send??
C
A.ReceivegtC.Send
A.ReseivegtD.Send
D
E
Partition line
B.SendgtE.Send??
G
F
D.ReceivedgtF.Send
H
G.SendgtI.Send
J
I
G.ReceivegtJ.Send??
39
Synchronization of messages
Object_A
Object_C
Object_B
Object creation
Asynchronous message
Asynchronous message
Object_D
Conditional message
Wait
Message with timeout
Synchronous message
Self message
Explicit return
Stereotyped message
ltltStereotypegtgt
Object deletion
Notation deprecated in UML 2
40
Additional syntax in sequence charts
Object_2
Object_1
Condition Message_1
if Condition then message_1 else message_2
not Condition Message_2
X Message_1
case Variable of Xgt message_1 Ygt message_2
Y Message_2
X Message
While X do Message
41
Timing Constraints
Object_C
Object_B
Object_A
a
PERIOD(a)10 s
e
AVERAGE(b-a)5 s
f
f-elt1s
b
a
b
42
Collaborations (UML1.x)

• They model interactions between objects that
  collaborate to implement a given functionality or
  use case.
• They refer mainly to the links between objects.
  They are specially useful to describe protocols.
• They describe concrete scenarios for particular
  situations, not general behaviors.
• The expressive power is similar to sequence
  charts. The emphasis here is in the communication
  links, while in the other is on the order of
  occurrence.

43
A collaboration diagram example.
9. Display Message That selection is empty
CokeRackRack
MessagerDisplay
Can
7. Release
8. Light on
ButtonPanel
6. Push
CokeButtonButton
CokeLedLed
10. Push
FantaButtonButton
11. Release
5. Enable Buttons
12. Disable button
FantaRackRack
13. Reset
Coin
Can
1. Insert 50 c. 2. Insert 50 c. 3. Insert 20 c.
CoinReceptacle
FantaLedLed
4. Return 10 c.
User
44
The order is expressed explicitly as an index
45
A sequence chart example
Coin Receptacle
CokeButton Button
Button Panel
CokeRack Rack
CokeLed Led
FantaButton Button
FantaRack Rack
Message Display
User
Insert 50 c.
Insert 50 c.
Insert 20 c.
Return 10 c.
Enable button
Push
Release
Light On
Display Message
Push
Release
Disable buttons
Reset
46
Use case diagrams

• A use case describes an interaction between the
  system and an external agent called actor
• A use case capture a functionality that is
  visible for the user (actor).
• A use case represent a concrete objective of the
  system for a user.
• A use case may correspond to a very simple as
  well as to a quite complex function. In the later
  case it may be formulated in terms or simpler use
  cases.
• Use case diagrams are used in UML to
• Delimit parts that belong to the system from
  those that are external to it.
• Capture the functional elements of the system.
• Identify and classify external elements with
  which the system interacts.
• Formulate the protocols fo rthe interactions
  between the system and the actors..
• Use case diagrams encompass the systems
  functionality, not its implementation.
• Use case diagrams are an alternative to the
  context diagram and complement it to formulate
  the systems requirements.
• The functionality of the system expressed in the
  use cases is used as a guide along the rest of
  the phases in the development process (analysis,
  design, coding, tests, and deployment).

47
Use cases Modeling requirements

• A use case describes a concrete capacity or
  functionality required for the system that is
  offered to a concrete actor .
• It specifies a function of the system as a whole,
  disregarding its internal parts or the concrete
  mechanisms used to deliver it.
• It acts as a container for the diagrams or texts
  that are needed to describe its functionality and
  the quality of service required from the system.
• Among use cases can be established relations
  like
• Generalization.
• Inclusion.
• Extension.

48
Elements in UML use case diagrams
49
Actors

• It represents an entity that is external to the
  system but interacts with it
• Actors may be
• Main actors Users utilizing the system
  functions.
• Secondary actors Users that make administrative
  or maintenance system tasks.
• External elements Equipment or devices that are
  related to or in the environment of the
  application but are not developed with it.
• Other systems Systems external to the one under
  development that interact with it.
• An object may implement several actors, and an
  actor may have several implementations.

50
Use Case diagram for an e-commerce web service
51
Packages to organize use cases
52
Timed interactions/activities

• Some activities must occur at predefined time
  instants and are triggered by the internal clock.
• These kinds of activities may be seen in two
  ways
• Time may be considered as an actor that launches
  the use case.
• The pass of time is part of the system and the
  associated actor reacts motivated by it.
• Only the first situation can modeled with
  use cases since it preserves the principle that
  the use case is triggered by the will of an actor.

53
Information that describes the use case.

• A use case identify a concrete functionality and
  relate it to the actor/s that trigger it.
• It must be documented in such a way that its
  functionality gets fully formalized for the
  necessary stakeholders.
• In the regular practice there are several textual
  and graphical styles accepted to document use
  cases.
• The necessary information for a use case
  includes
• An identifier
• Actor or actors that can trigger it.
• Pre- and post- conditions that are applicable.
• Its basic functionality (text or graph).
• Alternative paths for its execution, and errors
  or exceptions that it may rise.

54
The use case Order as an example
Identifier Order
Actors that
trigger it Client and Agent. Pre-conditions A
registered client has successfully logged-in into
the system. Sequential flow of events 1. The
client enters name and address. 2. Once the
client inserts the zip code the system retrieves
the county, town, and state. 3. The client type
the codes of the products that form the order. 4.
The system reacts by providing the description
and price of each product. 5. The system stores
temporarily the list of products included in the
order. 6. The client enters the payment card
data. 7. The client click on the control button
labeled as Send Order. 8. The system verifies
that all required data is provided, store the
order in a temporary location and request
confirmation of the payment to the bank. If the
information provided is not correct the system
request corrections to the client. 9. When the
payment is complete, the order is accepted, it
gets an identification (ID) number, an this ID is
returned to the client. Post-conditions If the
order is not canceled it ends being recorded in
the system and its ID confirmed to the client.
55
Relationships between use cases

• The analysis of requirements gets simplified when
  some use cases can be formulated as a function of
  others previously defined.
• There are three kinds of relationships between
  use cases
• Inclusion ltltincludesgtgt o ltltusesgtgt This implies a
  simple functional dependency. Occurs when a use
  case includes the content (semantics and
  implementation) of another one by calling it in
  the description of its own flow. This helps to
  avoid repeating functional segments that appear
  in multiples contexts.
• Extension ltltextendsgtgt The extended use case is
  used as a basis to derive others by extension of
  its predefined extension points. Then creating
  new functionality.
• Inheritance When a use case is more general than
  other and the derivate one inherits the features
  from the parent specializing or overwriting some
  of its functionality

56
Example of an inclusion relationship
57
An extension relationship example.
Order
Extension Points
ltltextendgtgt (Special client) client in the list
of special clients
Sales before step 5 Special client before step
5
Discount for preferential clients
1 Start in the point called Sales 2 The system
makes a discount on the order 3 Calculates the
products discount 4 Subtracts the discount from
the total
ltltextendgtgt (Sales) product in the list of season
sales

• 1 Start in the point called Special Client
• 2 The system shows discount on the order
• 3 It calculates the discount on the total of the
  order
• 4 Subtract the discount from the total

Season sales
58
Example of inheritance between use cases
WEB -Order
Order
Phone order
Client
Order status
Selling report
Agent