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. 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

21. 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

22. 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.

23. 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.

24. Use Case Notation  Example: ATM banking system. 24 System boundary
Actor ATM
Withdraw cash
Check balance
Customer
Use cases

25. 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.

26. 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.

27. <<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.

28. <<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

29. <<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.

30. 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.

31. Generalization 31

32. Generalization 32

33. 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.

34. 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.

35. 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.

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

37. 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.

38. 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.

39. Sequence Diagram Example 139

40. Explanation of Example 140

41. 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.

42. 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.

43. 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.

44. 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

45. 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.

46. 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

47. 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.

48. Example of Sequence 48