1. CS410 – Software Engineering Lecture #17: UML I
Homework Assignment #3
Please take a look at the Simple and Fast Multimedia Library and install it on your system:
We will use this library for our final homework programming task.
I will present the task on Thursday.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

2. CS410 – Software Engineering Lecture #17: UML I
Modeling
Abstraction is the classification of phenomena into concepts.
Modeling is the development of abstractions that can be used to answer specific questions about a set of phenomena.
Modeling is what you do as a software engineer when designing a software system.
You abstract concepts from the application domain (the system’s environment) and from the solution domain (technologies) to derive a simple model that is easy to understand.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

3. CS410 – Software Engineering Lecture #17: UML I
UML Basics
UML is a standard modeling language, particularly for object-oriented modeling.
For system development, we use UML to represent three different models of the system:
the functional model, represented with use case diagrams (system from the user’s perspective),
the object model, represented with class diagrams (structure of the system),
the dynamic model, represented with sequence diagrams, statechart diagrams, and activity diagrams (internal behavior of the system).
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

4. CS410 – Software Engineering Lecture #17: UML I
Use Case Diagrams
Use case diagrams represent the functionality of the system.
A use case is a function of the system that yields a visible result for an actor.
An actor is any person or object outside the system that interacts with the system.
In use case diagrams, the actors are outside the boundary of the system, and the use cases are inside.
We indicate use cases with ovals (ellipses).
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

5. CS410 – Software Engineering Lecture #17: UML I
Use Case Diagrams
Example: Use case diagram for a simple watch.
SimpleWatch
ReadTime
WatchRepairPerson
WatchUser
SetTime
ChangeBattery
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

6. CS410 – Software Engineering Lecture #17: UML I
Actors
An actor models an external entity which communicates with the system:
User
External system
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
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

7. CS410 – Software Engineering Lecture #17: UML I
Use Cases
A use case represents a class of functionality provided by the system as an event flow.
A use case consists of:
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

8. CS410 – Software Engineering Lecture #17: UML I
Use Cases: Example
Name:
Purchase ticket
Participating actor: Passenger
Entry conditions:
Passenger standing in front of ticket distributor.
Passenger has sufficient money to purchase ticket.
Event flow:
1. Passenger selects the number of zones to be traveled.
2. Distributor displays the amount due.
3. Passenger inserts money, of at least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

9. The <<extend>> Relationship
<<extend>> relationships represent exceptional or rarely invoked cases.
The exceptional event flows are factored out of the main event flow for clarity.
Use cases representing exceptional flows can extend more than one use case.
The direction of a <<extend>> relationship is towards the extended use case.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

10. The <<extend>> Relationship
Passenger
PurchaseTicket
<<extend>>
<<extend>>
<<extend>>
<<extend>>
OutOfOrder
TimeOut
Cancel
NoChange
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

11. The <<include>> Relationship
An <<include>> relationship represents behavior that is factored out of the use case.
An <<include>> represents behavior that is factored out for reuse, not because it is an exception.
An <<include>> relationship arrow starts from the including use case (unlike <<extend>> relationships).
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

12. The <<include>> Relationship
Passenger
PurchaseMultiCard
PurchaseSingleTicket
<<include>>
<<include>>
CollectMoney
<<extend>>
<<extend>>
NoChange
Cancel
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

13. Data Types and Instances
In programming languages, data types are used as concepts:
A data types has a name for identification,
a data type has a purpose (structure and operations on its members),
a data type has members.
An abstract data type is a data type whose structure and implementation is hidden from the rest of the system.
An instance is any member of a specific data type.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

14. CS410 – Software Engineering Lecture #17: UML I
Classes
In object-oriented programming languages, classes are used as concepts (abstractions).
Classes are like abstract data types in terms of encapsulating structure and behavior.
But unlike abstract data types, classes can be derived from other classes by using generalization.
Imagine that you developed a watch that can also be used to surf the web.
Then the class WebWatch would be a refinement of the class Watch.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

15. CS410 – Software Engineering Lecture #17: UML I
Classes
This type of relationship between two classes is called generalization.
The base class (Watch) is called the superclass, and the refined class is called the subclass (WebWatch).
The subclass refines the superclass by adding attributes and operations (or modifying existing ones).
In UML class diagrams, classes and objects are shown as boxes with three compartments containing
the name of the class or object (object:Class),
its attributes,
its operations.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

16. CS410 – Software Engineering Lecture #17: UML I
Classes
Watch
time
date
WebWatch
SetDate(d)
currentURL
EnterURL(u)
VirusScan()
In UML class diagrams, the triangle points to the superclass, and the other end is attached to the subclass.
The second and third compartments can be omitted.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

17. CS410 – Software Engineering Lecture #17: UML I
Classes
An object is an instance of a class; each object belongs to exactly one class.
In UML, names of instances are underlined.
<<instanceOf>>
myWatch:Watch
Watch
<<instanceOf>>
myCoolNewWatch:WebWatch
WebWatch
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

18. CS410 – Software Engineering Lecture #17: UML I
Class Diagrams
Class diagrams represent the structure of the system.
Classes specify the common structure and behavior of a set of objects.
Objects
are instances of classes,
are created, modified, and destroyed during the execution of the system,
have a state.
Class diagrams describe the system in terms of objects, classes, attributes, operations, and their associations.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

19. CS410 – Software Engineering Lecture #17: UML I
Classes
A class represents a concept.
A class encapsulates states (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature
(the tuple made out of the types of its parameters and the type of the return value)
The class name is the only mandatory information.
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
zone2price
getZones()
getPrice()
TariffSchedule
TariffSchedule
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

20. tariff_1974:TariffSchedule
Instances
An instance represents a phenomenon.
The name of an instance is underlined and can contain the class of the instance.
The attributes are represented with their values.
zone2price = {
{‘1’, .20}, {‘2’, .40},
{‘3’, .60}}
tariff_1974:TariffSchedule
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

21. CS410 – Software Engineering Lecture #17: UML I
Associations
Associations denote relationships between classes.
The multiplicity of an association end denotes how many objects the source object can legitimately reference.
Has-capital
name:String
Country
name:String
City 1 1
1-to-1
association
draw()
Polygon
x:Integer
y:Integer
Point 1 *
1-to-many
association
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

22. CS410 – Software Engineering Lecture #17: UML I
Class Diagrams
Example: Class diagram for a simple watch.
SimpleWatch 1 1 1 1 2 1 2 1
PushButton
Display
Battery
Time
The numbers on the ends of associations indicate the number of links that each object has with an object of a given class.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

23. CS410 – Software Engineering Lecture #17: UML I
Aggregation
An aggregation is a special case of association denoting a “consists of” hierarchy.
The aggregate is the parent class, the components are the children class.
Exhaust System 1
Muffler
Tailpipe
0..2
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

24. CS410 – Software Engineering Lecture #17: UML I
Generalization
Generalization relationships denote inheritance between classes.
The child classes inherit the attributes and operations of the parent class.
Generalization simplifies the model by eliminating redundancy.
Button
CancelButton
ZoneButton
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

25. CS410 – Software Engineering Lecture #17: UML I
Class Diagram Example
MapSite
Enter()
Maze
Room
Wall
Door
1..n
roomNum
isOpen
AddRoom()
RoomNo()
SetSide()
GetSide()
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

26. CS410 – Software Engineering Lecture #17: UML I
Sequence Diagrams
Sequence diagrams show the communication among objects.
The objects involved in a use case are called participating objects.
A sequence diagram represents the interactions that take place among these objects.
In a sequence diagram,
columns represent timelines of actors and objects,
labeled arrows represent stimuli (messages) that are sent from an actor to an object or between objects.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

27. CS410 – Software Engineering Lecture #17: UML I
Sequence Diagrams
Example: Sequence diagram for the SetTime use case.
:WatchUser
:SimpleWatch
:Display
:Time
pressButton1()
blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

28. CS410 – Software Engineering Lecture #17: UML I
Sequence Diagrams
Used during requirements analysis
to refine use case descriptions,
to find additional objects (“participating objects”)
Used during system design to refine subsystem interfaces.
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

29. Sequence Diagram Observations
UML sequence diagrams represent behavior in terms of interactions.
Complement the class diagrams which represent structure.
Useful to find participating objects.
Time consuming to build but worth the investment.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

30. CS410 – Software Engineering Lecture #17: UML I
Statechart Diagrams
Statechart diagrams describe the behavior of an individual object like a finite state automaton, that is,
a finite number of states that the object can assume,
transitions between these states.
Here, a state is a particular set of values for an object.
States are represented by ovals.
A transition represents a state change that occurs under a particular condition.
Transitions are represented by arrows that are labeled with the corresponding condition.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

31. Statechart Diagrams Example: Statechart diagram for SimpleWatch.
button2Pressed
button1&2Pressed
BlinkHours
IncrementHours
button1Pressed
button2Pressed
button1&2Pressed
BlinkMinutes
IncrementMinutes
button1Pressed
button1&2Pressed
button2Pressed
StopBlinking
BlinkSeconds
IncrementSeconds
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

32. CS410 – Software Engineering Lecture #17: UML I
Activity Diagrams
An activity diagram describes a system in terms of activities.
Activities are shown as states that represent the execution of a set of operations.
After the completion of one or more activities, other activities are started.
Activity diagrams are similar to flowchart diagrams. They represent activities as ovals and transitions between activities as arrows.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I

33. CS410 – Software Engineering Lecture #17: UML I
Activity Diagrams
Example: Activity diagram for incident management
Allocate Resources
Open Incident
Coordinate Resources
Archive Incident
Document Incident
Thick bars represent the synchronization of the control flow.
November 8, 2016
CS410 – Software Engineering Lecture #17: UML I