Software Engineering Chapter 5 Part 1 System Modeling

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

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

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

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.

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

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

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 1000 words”

Classification of UML Models 8 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.

UML diagrams Classification 9 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 to capture it in a model.

10 A. Context Models

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.

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.

The Context of the MHC-PMS 13

14 B. Interaction Models

15 1. USE CASE Diagrams

Use Case Modeling 16 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.

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

Use Case Diagram 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.

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 Student use cases. Actors are not part of the system (EXTERNAL). Actors may represent a human, a machine, or another system.

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

What is a Use Case? 20 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. Register for Courses Use case name

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

Use Case (Example) 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.

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.

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

ATM Machine Example.

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

Use Case Scenario 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 can be executed without the use case extension in extend associations.

Example of use case format 26 Use Case: Report. Emergency Actors: Field. Officer Precondition: The Field. Officer 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 Field. Officer fills the form. . • The Dispatcher reviews the information submitted by the Field. Officer. . . Post condtion: The Field. Officer receives the acknowledgment and the selected response.

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

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

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. Software Engineering 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 UML Use Case Driven Object

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

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

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

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

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

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

Use Case Diagram Relationships. Rest ock <<includes>> ct Colle <<includes>> Open Machine Close Machine 39

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

Self Service Machine Use Case Diagram Buy a product . customer ock Rest Self Service Machine <<includes>> Open Machine Close Machine Restock according to sales ect supplier Coll <<includes>> Open Machine Close Machine

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.

Generalization 31

Generalization 32

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

Use Case Specification Outline 34 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.

Use Case Specification Outline Example 35 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. 5. 2. 1 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 2. S e q u e n c e D i a g r a ms

Sequence Diagrams 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

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.

Sequence Diagram Example 1 39

Explanation of Example 1 40

Objects 41 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 at least one of them should be present. Layered two rectangle used to show a client interacts with the elements of a collection. optional, but

Messages 42 An interaction between two objects is performed as a message sent from one object to another (method call, signal, e-mail). 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. e-mail). The following means either of the above: Return value optionally indicated using a dashed arrow with a label indicating the return value.

Synchronous Vs. Asynchronous 43 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.

Conditional Interaction 44 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

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.

Repeated Interaction 46 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

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.

Example of Sequence 48

6 1 . Restaurant Sequence Diagram

6 2 ATM Machine Sequence Diagram