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

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

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

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

5. “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”

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

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

8. 10
A. Context Models

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

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

11. The Context of the MHC-PMS13

12. 14
B. Interaction Models

13. 15
1. USE CASE Diagrams

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

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

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

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

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

19. Generalization 31

20. Generalization 32

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