Software Engineering

1. UML
CSE 470 : Software Engineering

2. • Unified Modeling Language
• UML is a modeling language to
express and design documents,
software
– Particularly useful for OO design
– Not a process
– Independent of implementation language
What is UML?

3. Types of UML Diagrams
1. Use Case Diagram: capture requirements.
Clarify exactly what the system is supposed to do
2. Class Diagram: static relationships between classes.
Describe the types of objects in the system and various
kinds of static relationship that exist among them.
3. Sequence Diagram: Displays the time sequence of
the objects participating in the interaction.

4. Use Case Diagram

5. Use Case Diagrams:
A series of actions performed by user
Use case diagrams represent external behavior
Use case diagrams are useful as an index into the use
cases

6. Actor
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
Passenger

7. Actor
Primary actor:
interact to achieve required system function and
derive the intended
Secondary actor:
support the system so that primary actors can do
their work.
It is important to note that an actor and an end user
are not necessarily the same thing.

8. Use case
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
PurchaseTicket

9. Use Case Diagrams
Library System
Borrow
Order Title
Fine Remittance
Client
Employee
Supervisor
• A generalized description of how a system will be used.
• Provides an overview of the intended functionality of the system
Boundary
Actor
Use Case

10. Object oriented approach?

11. Use Case Diagram(core relationship)
Include: a dotted line labeled <<include>> beginning at base use case
and ending with an arrows pointing to the include use case. An “Include”
relationship is used to indicate that a particular Use Case must include
another use case to perform its function.
<<include>>
or in MS Visio
A Use Case may be included by one or more Use Cases, so it reduces
duplication of functionality.
Example: the <list orders> Use Case may be included
every time when the <modify order> Use Case is run.

12. Use Case Diagram (core relationship)
Extend: a dotted line labeled <<extend>> with an arrow toward the
base case. The extending use case may add behavior to the base use case.
The base class declares “extension points”.
<<extend>>
Used when exceptional circumstances are encountered. For example, the
<get approval> Use Case may optionally extend the regular <modify
order> Use Case.
Note: other expressions. For example, in MS Visio

13. Example
Problem:
Develop a system where a patient can make an
appointment, cancel his appointment and pay bill to
the corresponding authority

14. Example
At first, try to define your actors
List the set of user cases
Connect each user cases to an actor
Show the relation between each user cases

15. An approach of Jacobson
 Who is the primary actor, the secondary actor(s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What exceptions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

16. Practice yourself

17. Solution

18. Use Case Diagrams(cont.)
•Pay Bill is a parent use case and Bill Insurance is the child use
case. (generalization)
•Both Make Appointment and Request Medication include
Check Patient Record as a subtask.(include)
•The extension point is written inside the base case
Pay bill; the extending class Defer payment adds the behavior
of this extension point. (extend)

19. Use Case Diagram: Example
Name: Purchase ticket
Participating actor: Passenger
Entry condition:
• Passenger standing in front of
ticket distributor.
• Passenger has sufficient
money to purchase ticket.
Exit condition:
• Passenger has 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.
Anything missing?
Exceptional cases!

20. Use Cases are useful to…
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.

21. Class Diagram

22. A class is a description of a set of objects
Each class is represented by a rectangle subdivided
into three compartments
 Name
 Attributes
 Operations
Class Diagram

23. Notation: Classes
Window
origin
size
open()
close()
move()
display()
name
attributes
operations

24. The "Hello, World" Example
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString ("Hello, World!", 10, 10);
}
}
Example from: BJR

25. HelloWorld
paint()
class
name
operations
The "Hello, World" Example

26. HelloWorld
paint()
g.drawString ("HelloWorld", 0,
10)"
class
name
operations
annotation
The "Hello, World" Example

27. UML Class Notation
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
Abstract class: Name in italics

28. UML Class Notation

29. UML Class Notation
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
 Lifetime control; 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.
bird is part of mammal
 Indicated by triangle pointing to superclass

30. Binary Association
myB.service(); myA.doSomething()
;
Binary Association: Both entities “Know About” each other
Optionally, may create an Associate Class

31. Unary Association
A knows about B, but B knows nothing about A
Arrow points in direction
of the dependency
myB.service();

32. Aggregation
Aggregation is an association with a “collection-member” relationship
void
doSomething()
aModule.service();
Hollow diamond on
the Collection side
No sole ownership implied

33. Composition
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on side of
the Collection
members[0] =
new
Employee();
…
delete
members[0];

34. Inheritance
Standard concept of inheritance
class B() extends
A
…
Base Class
Derived Class

35. UML Multiplicities
Multiplicities Meaning
0..1
zero or one instance. The notation n . . m
indicates n to m instances.
0..* or *
no limit on the number of instances
(including none).
1 exactly one instance
1..* at least one instance
Links on associations to specify more details about the relationship

36. UML Class Example

37. Sequence / Activity Diagram

38. Activity diagram
Activity diagram supplements the use case by
providing a graphical representation of the flow of
interaction within a specific scenario
Similar to the flowchart

39. Activity diagram: notation
Rounded rectangles to imply a specific system
function,
Arrows to represent flow through the system,
Decision diamonds to depict a branching decision
Solid horizontal lines to indicate that parallel
activities are occurring

40. Activity diagram for
Access camera
surveillance via the
Internet—display
camera views function

41. Thank you

42. References
Cornell University, USA
http://www.cs.cornell.edu/courses/cs501/2000fa/slides.html
Shiyuan Jin, Fall 2006 (Student in UCR)Shiyuan Jin, Fall 2006 (Student in UCR)
Roger s. pressman, Software Engineering a
practitioners approach, 7th
ed