Chapter 5 – System Modeling

1. Chapter 5 – System Modeling Chapter 5 System modeling

2. System modeling • System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. • System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). • System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Chapter 5 System modeling

3. Existing and planned system models • Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system. • Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation. • In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model. Chapter 5 System modeling

4. System perspectives You may develop different models to represent the system from different perspectives. For example: • An external perspective, where you model the context or environment of the system. • An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system. • A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. • A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events. Chapter 5 System modeling

5. Use of graphical models • There are three ways in which graphical models are commonly used: • As a means of facilitating discussion about an existing or proposed system • Incomplete and incorrect models are OK as their role is to support discussion. • As a way of documenting an existing system • Models should be an accurate representation of the system but need not be complete. (Because you may only wish to develop models for some parts of a system). • As a detailed system description that can be used to generate a system implementation • Models have to be both correct and complete.

6. Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. Social and organisational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. Context models Chapter 5 System modeling

7. System boundaries • System boundaries are established to define what is inside and what is outside the system. • They show other systems that are used or depend on the system being developed. • The position of the system boundary has a profound effect on the system requirements. Chapter 5 System modeling

8. The context of the MHC-PMS Chapter 5 System modeling

9. Process perspective • Context models simply show the other systems in the environment, not how the system being developed is used in that environment. • Process models reveal how the system being developed is used in broader business processes. • UML activity diagrams may be used to define business process models. Chapter 5 System modeling

10. Process model of involuntary detention Chapter 5 System modeling

11. UML diagram types Chapter 5 System modeling

12. UML diagram types Behavioral Diagrams (Dynamic): • Use case diagrams, which show the interactions between a system and its environment. • Activity diagrams, which show the activities involved in a process or in data processing . • Sequence diagrams, which show interactions between actors and the system and between system components. • State diagrams, which show how the system reacts to internal and external events. • Structural Diagrams (Static): • Class diagrams, which show the object classes in the system and the associations between these classes. Chapter 5 System modeling

13. Use Case Diagram • Describes what the system does, without describing how the system does it • Each use case represents a discrete task that involves external interaction with a system. • Actors in a use case may be people or other systems. • Represented diagrammatically to provide an overview of the use case and in a more detailed textual form. Chapter 5 System modeling

14. A set of ACTORS : roles users can play in interacting with the system. An actor is used to represent something that users our system. A set of USE CASES: each describes a possible kind of interaction between an actor and the system. Uses cases are actions that a user takes on a system A number of RELATIONSHIPS between these entities (Actors and Use Cases). Relationships are simply illustrated with a line connecting actors to use cases. Use case name Use Case Diagrams Chapter 5 System modeling

15. Use Case Relations Chapter 5 System modeling

16. Examples of Use Cases, Behavioral Relationships for Student Enrollment Both Enroll in Course and Arrange Housing include Pay Student Fees in both cases students must pay their fees The extended use case Student Health Insurance extends the basic use case Pay Student Fees.

17. Extend and Include relationship Include Relationship • Includes • You have a piece of behavior that is similar across many use cases • Break this out as a separate use-case and let the other ones “include” it Extend Relationship • Extends A use-case is similar to another one but does a little bit more

18. Transfer-data use case • A use case in the MHC-PMS Chapter 5 System modeling

19. Tabular description of the ‘Transfer data’ use-case

20. Use cases in the MHC-PMS involving the role ‘Medical Receptionist’ Chapter 5 System modeling

21. A Use Case Example of Student Enrollment Use case diagrams provide the basis for creating other types of diagrams, such as class diagrams and activity diagrams

22. Activity Diagram Show the sequence of activities in a process, including sequential and parallel activities, and decisions that are made. It is usually created for one use case. Symbols • Rectangle with rounded ends represents an activity. • Arrow represents an event. • Diamond represents either decision (also called a branch) or a merge. • Long, flat rectangle represents a synchronization bar. These are used to show parallel activities, and may have one event going into the synchronization bar and several events going out of it, called a fork. A synchronization in which several events merge into one event is called a join. • Filled-in circle represents the initial state. • Black circle surrounded by a white circle represents the final state. • Swimlanes(Rectangles surrounding other symbols) indicate partitioning and are used to show which activities are done on which platform, such as a browser, server, or to show activities done by different user groups. Chapter 5 System modeling

23. Activity Diagram (Generic Symbols). Chapter 5 System modeling

24. Simple activity Diagram example Chapter 5 System modeling

25. Activity Diagram example Change Student Information use case. Chapter 5 System modeling

26. Sequence diagrams • Illustrate a succession of interactions between classes or object instances over time. • Often used to show the processing described in use case scenarios. • Each use case scenario may create one sequence diagram. • Used to show the overall pattern of the activities or interactions in a use case. • A sequence diagram emphasizes the time ordering (sequence) of messages. Chapter 5 System modeling

27. Specialized Symbols Used to Draw a Sequence Diagram Actors and classes or object instances are shown in boxes along the top of the diagram The leftmost object is the starting object and may be a person (for which a use case actor symbol is used), window, dialog box, or other user interface. A vertical dashed line represents the lifeline for the class or object. While the vertical rectangle on the lifeline shows the focus of control when the object is busy doing things Horizontal arrows show messages or signals that are sent between the classes. Solid arrowheads represent synchronous calls, which are the most common. These are used when the sending class waits for a response from the receiving class, and control is returned to the sending class when the class receiving the message finishes executing. Half (or open) arrowheads represent asynchronous calls, or those that are sent without an expectation of returning to the sending class. Chapter 5 System modeling

28. A Sequence Diagram for Student Admission: Sequence Diagrams Emphasize the Time Ordering of Messages Chapter 5 System modeling

29. Sequence diagram for View patient information Chapter 5 System modeling

30. Sequence diagram for Transfer Data Chapter 5 System modeling

31. Structural models • Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. • Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. • You create structural models of a system when you are discussing and designing the system architecture. Chapter 5 System modeling

32. Class diagrams • Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. • An object class can be thought of as a general definition of one kind of system object. • An association is a link between classes that indicates that there is some relationship between these classes. Chapter 5 System modeling

33. Class diagrams..A Class Diagram for Course Offerings Chapter 5 System modeling

34. UML classes and association Chapter 5 System modeling

35. Classes and associations in the MHC-PMS Chapter 5 System modeling

36. The Consultation class Chapter 5 System modeling

37. An associationis a relationship among object classes. The simplest type of relationship Associations are shown as a simple line on a class diagram. It has the same as cardinality on an entity-relationship diagram. Class diagrams..Associations (Multiplicity Constraints)

38. Class diagrams..Associations Examples Chapter 5 System modeling

39. Class diagrams..Associations Examples Chapter 5 System modeling

40. Class diagrams..Whole/Part Relationships • When one class represents the whole object, and other classes represent parts. • The whole acts as a container for the parts. These relationships are shown on a class diagram by a line with a diamond on one end. • The diamond is connected to the object that is the whole. • Categories • Aggregation • Composition Chapter 5 System modeling

41. Class diagrams..Aggregation • Described as a “hasa” relationship • Provides a means of showing that the whole object is composed of the sum of its parts (other objects). • Example: the department has a course and the course is for a department. • This is a weaker relationship, because a department may be changed or removed and the course may still exist. • The diamond at the end of the relationship line is not filled in.. Chapter 5 System modeling

42. Class diagrams..Composition • Composition, a whole/part relationship in which the whole has a responsibility for the part. • It is a stronger relationship, and is usually shown with a filled-in diamond. • Keywords for composition are one class “always contains” another class. If the whole is deleted, all parts are deleted. • Think of composition as a stronger form of aggregation. Composition means something is a part of the whole, but cannot survive on it’s own. Chapter 5 System modeling

43. Class diagrams..Composition Example.. • In a university there is a compositionrelationship between a course andan assignment as well as betweena course and an exam. If the courseis deleted, assignments and examsare deleted as well. Chapter 5 System modeling

44. Class diagrams..Example of aggregation and composition • A Library contains students and books. • Relationship between library and student is aggregation as a student can exist without a library and therefore it is aggregation. • Relationship between library and book is composition as a book cannot exist without a library and therefore its a composition. Chapter 5 System modeling

45. Class diagrams..General example of Class relations Chapter 5 System modeling

46. Class diagrams..Generalization/Specialization Diagrams • Describes a relationship between a general kind of thing and a more specific kind of thing • Described as an “is a” relationship • Used for modeling class inheritance and specialization • General class is a parent, base, or superclass • Specialized class is a child, derived, or subclass. • For example, a car is a vehicle and a truck is a vehicle. In this case, vehicle is the general thing, whereas car and truck are the more specific things. • Generalization relationships are used for modeling class inheritance Chapter 5 System modeling

47. Class diagrams..Inheritance example

48. Behavioral models • Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment. • You can think of these stimuli as being of two types: • Data-driven models: Some data arrives that has to be processed by the system. • Events-driven models: Some event happens that triggers system processing. Events may have associated data, although this is not always the case. Chapter 5 System modeling

49. Data-driven modeling • Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing. • Data-driven models show the sequence of actions involved in processing input data and generating an associated output. • They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system. Chapter 5 System modeling

50. Sequence diagram is of illustrating the processing steps in a system Chapter 5 System modeling