1. Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Modified from Sommerville’s originals

2. Objectives  Represent SW systems using graphical models.2
 Represent SW systems using graphical models.
 Show different types of required models.
 Explain fundamental system modeling perspectives: context, interaction, structure, and behavior.
 Introduce some types of diagrams in UML.
 Understand the ideas underlying model-driven engineering.

3. Modeling  A model is a system abstraction.
 A model abstracts from irrelevant system details to simplify its description.
 We can identify following kinds of models:
 Descriptive models: model real systems.
 Prescriptive models: plan for new systems.
 Each model presenting a different view or perspective of the system. 3

4. Modeling Cont. 4
 Code is often hard to understand even by those who participate in the development.
 We need simpler representations for complex systems: Modeling is a mean for dealing with complexity.
 The most important aspect of a system model is that it leaves out detail.
 A model is an abstraction of the system being studied rather than an alternative representation of that system.

5. System Perspectives context or environment.5
 An external perspective  showing the systems’
context or environment.
 An interaction perspective  showing the
interactions between a system and its environment,
or between the components of a system.
 A structural perspective  showing the system organization or the structure of the data that is processed by the system.
 A behavioral perspective  showing the dynamic behavior of the system and how it responds to events.

6. OMG international, open membership, not-for-profit6
 The Object Management Group OMG™ is an
international, open membership, not-for-profit
computer industry consortium since 1989.
 It is now focused on some of modelling standards
such as UML,OCL, XMI … etc.

7. “A picture is worth 1000 words”
What is UML? 7
 Unified Modeling Language (UML) is a general-
purpose modeling language to specify, visualize,
modify, construct and document software systems.
 UML includes a set of graphic notation to create visual model of object-oriented software systems.
 Using a standard modeling language such as the UML (the Unified Modeling Language), different members of development team can communicate their decisions unambiguously to one another.
“A picture is worth words”

8. Classification of UML Models8
A. Context Models: A type of diagrams that illustrate the operational context of a system - they show what lies outside the system boundaries.
B. Interaction Models: Emphasize the interactions. Involves user inputs and outputs, interaction between the system being developed and other systems or interaction between the components of the system.

9. UML diagrams Classification9
C. Structural Models: A type of diagrams that display the organization of a system in terms of the components that make up that system and their relationships.
D. Behavioral Models: Describe the dynamic behavior of the system as it is executing, and show how to capture it in a model.

10. 10
A. Context Models

11. Context Models 11
 Definition of system boundary is not a value-free judgment.
 The position of the system boundary has a profound effect on the system requirements.
 Context models normally show that the environment includes several other automated systems. However, they do not show types of relationships between the systems in the environment and the system that is being specified.
 Normally, producing a simple architectural model is the first step in this activity.

12. Context Models (Example)12
 In developing the specification for MHC-PMS system, you have to decide if the system should focus exclusively on collecting information about consultations (using other systems) or it should collect personal patient information.
 Advantage of relying on other systems for patient information is that you avoid duplicating data.
 Disadvantage is that using other systems may make it slower to access information. MHC-PMS cannot be used if these systems are unavailable.

13. The Context of the MHC-PMS13

14. 14
B. Interaction Models

15. 15
1. USE CASE Diagrams

16. Use Case Modeling  It provides a high-level view of what the system16
 Use case diagrams were developed originally to support the requirements elicitation. Now, incorporated into the UML.
 They describe the functional requirements of the system in terms of use cases.
 It provides a high-level view of what the system
does (use case) and who uses it (actor).
 An actor represents anything that interacts with the system
People or System.
 Each use case represents a separated task that involves
external interaction with a system.

17. Use Case  Use case includes:17
 Use case includes:
 Use-case diagrams.
 Use-case specifications outline.
 The textual specification is more important than diagrams.

18. Use Case Diagram actors and their relationships.18
 Any use case diagram shows a set of use cases and
actors and their relationships.
 Defines clear boundaries of a system.
 Identifies who or what interacts with the system.
 Summarizes the behavior of the system.

19. What is an Actor? 19
 Actors are drawn as stick persons with the role of the actor written below.
 Actor role names are unique typically represent the role that an actor plays with the system.
 Each actor participates in one or more use cases.
 Actors are not part of the system (EXTERNAL).
 Actors may represent a human, a machine, or another system.
Student

20. Use Case Diagram: Actor
Primary Actor - an entity external to the system that uses system services in a direct manner.
Supporting Actor- an actor that provides services to the system being built.
Hardware, software applications, individual processes, can all be actors.
Software Engineering
UML Use Case Driven Object

21. What is a Use Case? deliver something of value to the actor. Use case20
 A use case describes the actions the system takes to
deliver something of value to the actor.
 A use case models a dialog (scenario) between actors and the system.
 Use cases are drawn as ellipses with the name of the use case written inside the ellipse.
 Use case name typically consists of an active verb and one or more nouns that concisely describe the system function modeled.
Use case
name
Register for Courses

22. 1- Actor based 2- Event based
Identifying Use Cases 21
 Using one way of:
1- Actor based Event based
• Identify the actors related to an • Identify the external events
organization that a system must respond to.
•For each actor, identify the • Relate the events to actors
processes they initiate or and use cases.
participate in processes.
Example :
Cashier Log in, Cash out
Customer Buy items, refund items

23. Use Case (Example)  In a university management system:22
 In a university management system:
 Students can submit the assignments, the instructor marks those assignments and uploads results. Student are allowed to view results.
 Now, by recalling the definition of use-case, can you identify the use-cases in this System?
Submit Assignments.
Mark Assignments.
Upload Results.
View Results.

24. Association (Relationship)23
Actor(s) connected to use case(s) by a line, which represents the relationship between the actor(s) and the use case(s).
 One actor may be associated with one or more use cases.
 One use case may be associated with one or more actors.
 A use case is initiated by an actor to invoke a certain
functionality in the system.

25. Example: ATM Use Cases
Develop a set of use cases and a use case diagram for a simple ATM (simple means you can just consider two kinds of accounts, savings and checking, and two transactions, deposits and withdrawals)
Software Engineering
UML Use Case Driven Object

26. ATM Machine Example .

27. Use Cases for the MHC-PMS
Chapter 4 Requirements engineering

28. Use Case Scenario to one of its end points. works as normal, such as:25
 An ordered set of flows from the start of a use case
to one of its end points.
 Each use case is likely to have several scenarios.
 The ideal or “happy” scenario is when the process
works as normal, such as:
 money is withdrawn from ATM.
 “Unhappy” scenarios, or “extensions” are when
things don’t go so well, such as:
 wrong pin number entered.
 The base use case can be executed without the use case extension in extend associations.

29. Example of use case format26
Use Case: ReportEmergency
Actors: FieldOfficer
Precondition: The FieldOfficer activates the “Report Emergency”
function of her terminal.
Trigger: customer entered its username and password
Main success scenario :
•The terminal responds by presenting a form to the officer...
•The FieldOfficer fills the form....
•The Dispatcher reviews the information submitted by the FieldOfficer ...
Post condtion: The FieldOfficer receives the acknowledgment and
the selected response.

30. Example: LIBSYS use cases
Article search
Library User
Article printing
Library Staff
Supplier
Catalogue services
S.H
2010
Software Engineering
UML Use Case Driven Object

31. A Library Example . client employee supervisor library system borrow
reserve
Order title
Fine payment
supervisor

32. Example: Rent Videos Use Cases●
Rent Videos. A Customer arrives with videos to rent. The Clerk enters their ID, and each video ID. The System outputs information on each.
The Clerk requests the rental report. The System outputs it, which is given to the Customer with their videos.
Show computer system actors with an alternate notation to human actors.
Video Store Information System
«actor» Credit
Authorization Service
Rent Videos
. . .
primary actors on the left
supporting actors on the right
Software Engineering
UML Use Case Driven Object

33. Example: Point of Sale – Use Case Diagram
Process sale
Payment Authorization service
Handle returns
Cashier
<<actor>>
Tax calculator
Process rental
Manage security
<<actor>> Accounting system
System administrator
Manage users
Use Case Diagram: illustrates a set of use cases for a system.
Software Engineering
UML Use Case Driven Object

34. Use case diagram for Movie Ticket Machine
Set title
# of tickets
Set price
Buy tickets
Give change
Set seats
Manager
Customer
TicketMachine
Software Engineering
UML Use Case Driven Object

35. <<extend>>27
 An extension is a significant exception to the normal case.
 Use an extend link to show that one use case may add functionality to another use case under certain circumstances.
 Major variation: If you have an alternative path in the use
case, especially when something goes different from what
does plan.
 Optional sub-goal: If you have parts of the use case that
would be optional to implement or execute to meet the actor’s
goals. Doing so clarifies the relationships between actors and
their goals. It also emphasizes that you may deliver these
optional goals in later releases.

36. <<extend>>28
 The arrow should point at the main, extended use case.
 For example, the Login use case of a typical Web site
can involve Register New User - but only when the
user does not already have an account

37. <<include>>29
 Used to indicate that one use case includes the
functionality of another use case.
 Some use cases may share one or more common steps
 The arrow should point at the more detailed, included use case.

38. Use Case Diagram Modeling the Context of a System
Software Engineering
UML Use Case Driven Object

39. Use Case Diagram Relationships.
<<includes>>
Open Machine
Restock
Close Machine
<<includes>>
<<includes>>
Open Machine
Collect
Close Machine
<<includes>>

40. Use Case Diagram Relationships.
Restock
Close Machine
Open Machine
<<includes>>
Restock According
to Sales
<<extends>>

41. Self Service Machine Use Case Diagram.
Buy a product
Self Service Machine
<<includes>>
Open Machine
customer
Restock
Close Machine
<<includes>>
Restock according to sales
<<includes>>
Open Machine
Collect
<<includes>>
supplier
Close Machine

42. Generalization 30
 Generalization between Use Cases means that the
child is a more specific than the parent; the child use case inherits all attributes and associations of the parent use case, but may add new features.
 Children of the same parent are all specializations of the parent.

43. Generalization 31

44. Generalization 32

45. Example  Customer uses bank ATM to make an ATM transaction as33
 Customer uses bank ATM to make an ATM transaction as
check balances of his/her bank account, deposit funds,
withdraw cash and/or transfer funds.
 VIP customers can make ATM transaction and print account statement.
 The customer is authenticated by inserting a plastic ATM card and entering a personal identification number (PIN).
 The customer requests help by selecting Help menu item.
 Bank employee updates ATM balance.

46. Use Case Specification Outline34
 A requirements document that contains the text of
a use case, including:
A description of the flow of events describing the interaction between actors and the system.
Other information, such as:
 Preconditions.
 Trigger.
 Flow of events.
 Post conditions.

47. Use Case Specification Outline Example35
Use Case: Withdraw Money Actors: system user Precondition:
1. The Customer has selected a language to use.
2. The Customer is a member of a bank.
3. The Customer has placed their credit card into the ATM machine.
4. The Customer has verified their account with PIN number.
Trigger: Customer selects withdraw money from the transaction options list.
Flow of events:
1. The use case starts when the Customer selects withdraw money from the transaction options list..
2. The system then checks this chosen amount against Customer’s current account balance.
3. The system shows a confirmation message that the withdraw money transaction was successful.
3.1. If the Customer does not have sufficient funds for the withdraw amount a message is displayed and they are requested to supply a different withdraw money amount.
4. The system then counts up money notes to the value of the withdraw amount and places it in the cash dispenser.
5. The system ask the user if they need a receipt
5.1. If the Customer selects “No” then a transaction receipt is not printed.
5.2. If the Customer selects “yes” then a transaction receipt is printed.
if there is no papers, a message is displayed “Sorry receipt cannot be printed”.
Post condition:
1. The system has updated the Customer’s account balance if a transaction was successfully completed.
2. The system has ejected the Customer’s account card if no other transactions were required.

48. 36
2. S e q u e n c e D i a g r a ms

49. Sequence Diagrams objects within a system.37
 Sequence diagrams are part of the UML and are used to model the interactions between the actors and the
objects within a system.
 It shows the sequence of interactions that take place
during a particular use case.
 Objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.
 Interactions between objects are indicated using the
annotated arrows.
 An important characteristic of a sequence diagram is that time passes from top to bottom.

50. Sequence Diagrams Cont.38
 Consists of:
 Objects represented by rectangles with the name underlined.
 Messages represented as a solid line and arrows with the
name of message on it.
 Time represented as a vertical progression.
 The rectangle on the dotted lines indicates the lifeline of the object.

51. Sequence Diagram Syntax
Software Engineering
Behavioral Diagrams

52. Sequence Diagram Example 139

53. Explanation of Example 140

54. Objects object and 'Type' indicates the type41
 Where 'name' is the name of the
object and 'Type' indicates the type
of which the object is an instance.
 Both name and type are optional, but at least one of them should be present.
 Layered two rectangle used to
show how a client interacts with
the elements of a collection.

55. Messages message sent from one object to another (method42
 An interaction between two objects is performed as a
message sent from one object to another (method
call, signal, ).
 A message is labeled with the message name.
 There are two kinds of messages:
 Synchronous: the caller/sender waits for return/replay (e.g.
method call).
 Asynchronous: the sender proceeds without waiting for a replay (e.g. ).
 The following means either of the above:
 Return value optionally indicated using a dashed arrow with a label indicating the return value.

56. Synchronous Vs. Asynchronous43
 Synchronous Messages: The routine that handles the message is completed before the calling routine resumes execution.
 Asynchronous Messages: Calling routine does not wait for the message to be handled before it continues to execute.

57. Conditional Interaction44
 A message can include a guard, which signifies that
the message is only sent if a certain condition is met.
The guard is simply that condition between brackets

58. Conditional Interaction Cont.45
 If you want to show that several messages are
conditionally sent under the same guard, you'll
have to use an 'opt' combined fragment. The
combined fragment is shown as a large rectangle
with an 'opt' operator plus a guard, and contains all
the conditional messages under that guard.

59. Repeated Interaction '*'symbol), it means that the message is sent46
 When a message is prefixed with an asterisk (the
'*'symbol), it means that the message is sent
repeatedly. A guard indicates the condition that
determines whether or not the message should be
sent (again). As long as the condition holds, the
message is repeated

60. Repeated Interaction Cont.47
 If you want to show that multiple messages are
sent in the same iteration, a 'loop' combined
fragment can be used. The operator of the
combined fragment is 'loop' and the guard
represents the condition to control the repetition.

61. Example of Sequence 48

62. Restaurant Sequence Diagram.

63. ATM Machine Sequence Diagram

64. Example of Sequence Diagram
Software Engineering
Behavioral Diagrams

65. Example: use cases to SSD
Software Engineering
Behavioral Diagrams

66. Request Appointment SD
Software Engineering
Behavioral Diagrams

67. Collaboration Diagrams
Semantically equivalent to sequence diagrams.
Objects are shown as icons, and can be placed anywhere on the page/screen.
Sequence of message firings is shown by numbering the messages.
Easier to depict object links and layout with collaboration diagrams; they’re also more compact.
Easier to see sequence with sequence diagrams.
S.H
2009
Software Engineering
Behavioral Diagrams

68. Collaboration Diagrams
Software Engineering
Behavioral Diagrams

69. Collaboration Diagrams
A collaboration diagram describes a pattern of interaction among objects.
Client Object
Link
Supplier Object
It shows objects participating in the interaction by their links to each other and the
:Client
messages that they send to
each other.
:Supplier
An object is represented in three ways: Objectname:Classname, Objectname,
1: PerformResponsibility
and :Classname
Message
A link is a relationship among objects across which messages can be sent.
In a collaboration diagram, a link is shown as a solid line between two objects.
A link can be an instance of an association, or it can be anonymous – meaning that its association is unspecified.
Software Engineering
Behavioral Diagrams

70. Collaboration Diagrams
A message is a communication between objects that conveys information with the expectation that activity will ensue.
In collaboration diagrams, a message is shown as a labeled arrow placed near a link.
This means that the link is used to transport, or otherwise implement the delivery of the message to the target object.
The arrow points along the link in the direction of the target object (the one that receives the message).
The arrow is labeled with the name of the message, and its parameters.
Software Engineering
Behavioral Diagrams

71. Collaboration Diagrams
The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction.
Sequence numbers are often used in collaboration diagrams, because they are the only way of describing the relative sequencing of messages.
(A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message, like //get_schedule(). You can later assign the message by specifying the operation of the message's destination object.
The specified operation will then replace the name of the message.
Frequently locked in upon further analysis
Software Engineering
Behavioral Diagrams

72. collaboration diagram notation
Software Engineering
Behavioral Diagrams

73. Example: Collaboration Diagrams
Software Engineering
Behavioral Diagrams

74. Example: Collaboration Diagrams
This example shows the collaboration of objects to support the Request Appointment
use case: Create a Schedule subflow. It is the “collaboration diagram equivalent” of the sequence diagram shown earlier.
Software Engineering
Behavioral Diagrams

75. Collaboration Diagrams Vs Sequence Diagrams
Same information expressed in different ways…
Collaboration Diagrams
Show relationships in addition to interactions
Better for visualizing patterns of collaboration
Better for visualizing all of the effects on a given object
Easier to use for brainstorming sessions
Sequence Diagrams
Show the explicit sequence of messages
Better for visualizing overall flow
Better for real-time specifications and for complex scenarios
S.H
2009
Software Engineering
Behavioral Diagrams

76. Collaboration Diagrams Vs Object Diagrams
A collaboration diagram without messages is also known as an object diagram.
The relationships between objects are called links.
An object diagram must be a valid instantiation of a static class diagram.
Objects must have classes.
Links between objects must be instances of associations between classes.
Use this as a quick consistency check.
Software Engineering
Behavioral Diagrams