Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu university Tell: February – July 2016 SOFTWARE ENGINEERING (CS3529) TARGET CLASSES: CS14: A,B

CHAPTER 5 – SYSTEM MODELING CHAPTER 5 SYSTEM MODELING 2

TOPICS COVERED CHAPTER 5 SYSTEM MODELING 3 System modeling overview Context models Interaction models Use Case Diagram Sequence Diagram Structural models Class Diagram Behaviour models State diagram Activity diagram Model-driven engineering (MDE) Model-driven architecture (MDA)

SYSTEM MODELING CHAPTER 5 SYSTEM MODELING 4 A model is an abstract view of a system that ignores some system details. 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. Each model presents a different view or perspective of the system. You may develop different models to represent the system from different perspectives. For example: 1.An external perspective, where you model the context or environment of the system. 2.An interaction perspective where you model the interactions between a system and its environment or between the components of a system. 3.A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. 4. A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

SOME UML DIAGRAMS CHAPTER 5 SYSTEM MODELING 5 UML Unified Model Language is: A graphical language used in object-oriented development that includes several types of system models that provide different views of a system. The UML has become a standard for object-oriented modeling. UML diagram types those may be used to represent the essential features of a system are: Activity diagrams, Use case diagrams, Sequence diagrams, Class diagrams and State diagrams

CONTEXT MODELS = FUNCTIONAL DECOMPOSITION DIAGRAM = WORK BREAK DOWN STRUCTURE CHAPTER 5 SYSTEM MODELING 6 Context model is described as: The immediate external environment of the system defining the systems’ context and the dependencies that a system has on its environment. The context model shows what is outside of the system boundary. Figure 5.1 The context of the MHC-PMS (Mental Health Care Patient Management System)

INTERACTION MODELS CHAPTER 5 SYSTEM MODELING 7 Modeling user interaction is important as it helps to identify user requirements. Modeling system-to-system interaction highlights the communication problems that may arise. Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. Use case diagrams and sequence diagrams may be used for interaction modelling.

INTERACTION MODELS 1.USE CASE MODELING CHAPTER 5 SYSTEM MODELING 8 Use case diagrams, which show the interactions between a system and its environment. Use cases were developed originally to support requirements elicitation and now incorporated into the UML. 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.

INTERACTION MODELS 1.USE CASE MODELING CHAPTER 5 SYSTEM MODELING 9 The principal components of a textual use-case description 1.The actors involved 2.A description of the interactions 3.The data that is exchanged 4.The stimulus that triggers the use case 5.The response of the system 6.Comments and other information

INTERACTION MODELS 1.USE CASE MODELING CHAPTER 5 SYSTEM MODELING 10 Use cases of the MHC-PMS involving the role ‘Medical Receptionist’

INTERACTION MODELS 1.USE CASE MODELING CHAPTER 5 SYSTEM MODELING 11 USE CASE FOR A WEB SITE SHOPPING APPLICATION

INTERACTION MODELS 2.SEQUENCE DIAGRAMS CHAPTER 5 SYSTEM MODELING 12 Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. Sequence diagrams, which show interactions between actors and the system and between system components. A sequence of interactions between the actors in a system's environment and the objects in the system itself. The sequence of interactions describes the implementation of a system feature or function. When and why is used Sequence Diagrams? To specify how instances interact To show what happens before the other To show the relationships/dependencies between interactions To clarify each object requirements for all the possible scenarios of the system

INTERACTION MODELS 2- SEQUENCE DIAGRAM

INTERACTION MODELS 2- SEQUENCE DIAGRAMS Messages can be Simple One object sends a message to a passive object The sender does not care what happens to the message Useful when the recipient can not be controlled Messages can be Synchronous The sender sends the message The recipient accepts the message, and notifies the sender with a message result. The sender accepts the message result. If the sender does not accept the message result, then the whole operation will not continue. Synchronous messages are useful to represent procedure calls or modal dialogs.

INTERACTION MODELS 2- SEQUENCE DIAGRAMS Messages can be Asynchronous The sender sends the message The sender does not wait for the return of the message, it immediately continues execution. The recipient may or may not send a reply. Messages can be Timeouts The sender sends the message The sender waits for the return of the message for some time. Execution continues when the recipient replies, or after the timeout period if the recipient does not reply The recipient may or may not send a reply. Messages can be Return messages Results of procedure calls

STRUCTURAL MODELS CHAPTER 5 SYSTEM MODELING 16 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.

STRUCTURAL MODELS 1.CLASS DIAGRAMS CHAPTER 5 SYSTEM MODELING 17 Class diagrams, which show the object classes in the system and the associations between these classes. Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. Figure 5.9 Classes and associations in the MHC-PMS

STRUCTURAL MODELS 1.CLASS DIAGRAMS GENERALIZATION Base sub Class2Class1Class2Class1 ASSOCIATION DEPENDENCY CLASS RELATIONSHIPS:

How is generalization used to simplify the models of a system with many similar objects? Assuming that the similar objects have attributes and methods in common, these common attributes and methods are associated with a ‘super-class' which generalizes all of the objects sharing these attributes/methods. The specific object classes only declare the attributes/methods specific to that class and they inherit the general attributes/methods from the super-class. Generalization is converted into inheritance when generating application code. STRUCTURAL MODELS 1.CLASS DIAGRAMS GENERALIZATION/SPECIALIZATION

STRUCTURAL MODELS 1.CLASS DIAGRAMS ASSOCIATION Associations have a navigational direction A Customer’s Payment Payment of a customer Navigational direction is a design issue, not an analysis issue. If no navigation is given, this may indicate a bidirectional navigation or that it is not specified. PaymentCustomer Payment

STRUCTURAL MODELS 1.CLASS DIAGRAMS DEPENDENCY Dependency means “One class uses the other” Could be used to show that one method of a class uses some objects of the other class. Programmers use Dependency to include the definition of a class in the other. Basic Class Dependent Class Depends on

BEHAVIORAL MODELS CHAPTER 5 SYSTEM MODELING 22 Behavioral models are models of the dynamic behavior of the system as it is executing. They show what happens or what is supposed to happen when a system responds to a reason from its environment. You can think of these stimuli as being of two types: 1.Data Some data arrives that has to be processed by the system. 2. Events Some event happens that triggers system processing. Events may have associated data but this is not always the case

BEHAVIORAL MODELS 1- DATA-DRIVEN MODELING CHAPTER 5 SYSTEM MODELING 23 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. Activity diagram is an example of data driven modeling. Activity diagrams, which show the activities involved in a process or in data processing

BEHAVIORAL MODELS 2-EVENT-DRIVEN MODELING CHAPTER 5 SYSTEM MODELING 24 Event-driven modeling shows how a system responds to external and internal events. It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another. The basic assumption that underlies event-driven modeling is that the system can be represented as a model with a finite number of discrete states and external and internal events trigger a transition from one state to another. State diagram is an example of Event-driven modeling. State diagrams are used to model a system’s behavior in response to internal or external events.

MODEL-DRIVEN ENGINEERING CHAPTER 5 SYSTEM MODELING 25 Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code. The claimed benefits of model-driven engineering are: 1.Engineers can work at a high level of abstraction without concern for implementation details. 2.Errors are reduced and the design and implementation process is speeded up. 3.By using powerful generation tools, implementations of the same system can be automatically generated for different platforms Model-driven engineering has its roots in model-driven architecture (MDA) which was proposed by the Object Management Group (OMG) in 2001 as a new software development paradigm

MODEL-DRIVEN ENGINEERING A) MODEL-DRIVEN ARCHITECTURE CHAPTER 5 SYSTEM MODELING 26 Model-driven engineering and model-driven architecture are often seen as the same thing. However, I think that MDE has a wider scope than MDA. MDA focuses on the design and implementation stages of software development whereas MDE is concerned with all aspects of the software engineering process. MDA has been in use since 2001, model-based engineering is still at an early stage of development and it is unclear whether or not it will have a significant effect on software engineering practice. The MDA method recommends that three types of abstract system model should be produced: 1.A computation independent model (CIM) that models the important domain abstractions used in the system. For example, there may be a security CIM in which you identify important security abstractions such as an asset and a role and a patient record CIM, in which you describe abstractions such as patients, consultations, etc. 2.A platform independent model (PIM) that models the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events. 3.Platform specific models (PSM) which are transformations of the platform independent model with a separate PSM for each application platform. So, the first-level PSM could be middleware- specific but database independent. When a specific database has been chosen, a database specific PSM can then be generated

MODEL-DRIVEN ENGINEERING B) EXECUTABLE UML CHAPTER 5 SYSTEM MODELING 27 The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible. To achieve this, you have to be able to construct graphical models whose semantics are well defined. You also need a way of adding information to graphical models about the ways in which the operations defined in the model are implemented. This is possible using a subset of UML 2, called Executable UML or xUML. UML was designed as a language for supporting and documenting software design, not as a programming language. The designers of UML were not concerned with semantic details of the language but with its expressiveness. They introduced useful notions such as use case diagrams that help with the design but which are too informal to support execution.

KEY POINTS CHAPTER 5 SYSTEM MODELING 28 A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions and structure. Context models show how a system that is being modeled is positioned in an environment with other systems and processes. Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects. Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations. Behavioral models are used to describe the dynamic behavior of an executing system. This can be modeled from the perspective of the data processed by the system or by the events that stimulate responses from a system. Activity diagrams may be used to model the processing of data, where each activity represents one process step. State diagrams are used to model a system’s behavior in response to internal or external events. Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code.