System Modeling Lecture (2) PDF

System Modeling Lecture (2) Dania Mohamed Ahmed  System modeling  System modeling is the process of creating abstract representations of complex systems to understand, analyze, and predict their behavior. It involves defining the components of a system, their interactions,...

System Modeling Lecture (2) Dania Mohamed Ahmed  System modeling  System modeling is the process of creating abstract representations of complex systems to understand, analyze, and predict their behavior. It involves defining the components of a system, their interactions, and their relationships to one another  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).  Benefits of system modeling: 1. Understanding Functionality: Models help analysts and developers grasp the system's functionality and how different components interact. 2. Communication Tool: They serve as effective communication tools for discussing the system’s design and requirements with customers, stakeholders, and team members.  Existing and planned system models  In system modeling, both existing and planned system models play vital roles throughout the development lifecycle. 1. Models of the Existing System: Models of the existing system represent the current state of a system, capturing its structure, behavior, and interactions as they are implemented or observed in reality. Purpose in Requirements Engineering:   Clarification: These models help understand what the current system does. They provide a clear picture of its functionality, structure, and interactions.  Strengths and Weaknesses: By analyzing these models, stakeholders can identify the system’s strengths and weaknesses. This insight is crucial for determining areas that need improvement or redesign.  Basis for New System Requirements:  Foundation for New Requirements: The understanding gained from modeling the existing system helps in formulating requirements for the new system. It ensures that new requirements address existing issues and enhance functionality. Existing and planned system models 2. Models of the New System: Models of the new system are representations of a proposed or future system, designed to outline and plan how the system will be structured and how it will behave once implemented. 1. Purpose in Requirements Engineering:  Explaining Requirements: Models of the new system are used to illustrate and clarify proposed requirements to stakeholders. They help ensure that everyone has a shared understanding of what the new system is intended to achieve.  Design Proposals: Engineers use these models to discuss and validate design proposals, ensuring that the design aligns with the requirements and objectives. 2. Documentation for Implementation:  Implementation Guide: These models serve as documentation for the system’s design, guiding the implementation process and providing a reference for developers. Existing and planned system models 3. Model-Driven Engineering (MDE): is an approach to software and systems development that uses models as the primary means of specifying, designing, and implementing systems. MDE focuses on the creation and manipulation of models to drive the development process, often involving automatic code generation and model transformations.  Generating System Implementations:  Automatic Generation: In a model-driven engineering process, it is possible to generate a complete or partial implementation of the system directly from the system models. This approach leverages models to produce code or other artifacts, potentially accelerating the development process and reducing errors.  These models are essential tools in the system development lifecycle, providing clarity, facilitating communication, and supporting both analysis and implementation. System perspectives  System perspectives provide different viewpoints on a system, each highlighting various aspects crucial for comprehensive understanding and design. 1. External Perspective  Focus: The external perspective models the context or environment in which the system operates. This perspective is concerned with how the system interacts with external entities such as users, other systems, or external data sources.  Purpose:  Context Understanding: Helps in understanding the system's boundaries, its role within a larger ecosystem, and external factors influencing its functionality.  Stakeholder Interaction: Clarifies the system’s interaction with external stakeholders and systems, which is essential for defining requirements and integration points.  Common Models: Use Case Diagrams, Context Diagrams. System perspectives 2. Interaction Perspective  Focus: The interaction perspective models how the system components or the system and its environment interact. It emphasizes the flow of data and control between different entities.  Purpose:  Interaction Analysis: Helps in understanding and designing the communication and data exchange processes within the system and with external systems.  Dynamic Behavior: Provides insight into how different components or entities collaborate to achieve system objectives.  Common Models: Sequence Diagrams, Communication Diagrams, Activity Diagrams. System perspectives 3. Structural Perspective  Focus: The structural perspective models the organization of the system or the structure of data processed by the system. It details how the system is composed and how its components are arranged.  Purpose:  System Organization: Helps in understanding the static structure of the system, including components, their relationships, and the hierarchy.  Data Organization: Provides a clear view of how data is structured, stored, and managed within the system.  Common Models: Class Diagrams, Component Diagrams, Deployment Diagrams, Entity-Relationship Diagrams. System perspectives 4. Behavioral Perspective  Focus: The behavioral perspective models the dynamic aspects of the system, including how it responds to events and changes over time.  Purpose:  Dynamic Behavior: Captures how the system behaves in response to various inputs, changes, or events. This is crucial for understanding and designing the system’s response mechanisms.  Event Handling: Helps in defining how the system should handle different scenarios and transitions between states.  Common Models: State Diagrams, Sequence Diagrams, Activity Diagrams.  UML diagram types 1. Activity Diagrams: Illustrate the activities and workflows involved in a process or data processing. 2. Use Case Diagrams: Depict interactions between the system and external entities (actors), focusing on the system's functionality. 3. Sequence Diagrams: Show the sequence of interactions between actors and the system, as well as between system components. 4. Class Diagrams: Represent the object classes in the system and their relationships or associations. 5. State Diagrams: Model the system’s response to internal and external events, capturing state changes over time. Use of Graphical Models  Graphical models are essential tools in various phases of system development, providing visual representations that aid in understanding, documenting, and implementing systems. Graphical models serve multiple purposes throughout the lifecycle of a system: 1. Facilitating Discussion: They help stakeholders communicate and explore system concepts and requirements, even if the models are not fully accurate or complete. 2. Documenting Systems: They provide a structured and accurate representation of existing systems, useful for reference, analysis, and communication. 3. Generating System Implementation: For detailed implementation, models must be precise and complete, guiding the actual development and ensuring that the final system aligns with the design.  Context models  Context models are a type of system model used in requirements engineering to provide a high-level view of the system and its environment. They help in understanding the boundaries of the system, its interactions with external entities, and the overall context in which it operates  Purpose of Context Models: 1. Define System Boundaries: context models illustrate what is inside and outside the system's boundaries. They help identify which elements are part of the system and which are external to it. 2. Clarify Interactions: they show how the system interacts with external entities, such as users, other systems, and external data sources. This helps in understanding the system’s interfaces and communication points. 3. Facilitate Stakeholder Understanding: by providing a clear picture of the system's environment and its interactions, context models help stakeholders understand the scope and constraints of the system. 4. Identify Requirements: they aid in identifying requirements related to system interactions, dependencies, and external interfaces. This can help in specifying what the system should do and how it should behave in its operational environment. The context of the Mental Health Care Patient Management System (MHC-PMS) Process perspective 1. Context Models:  Scope: Context models provide a high-level view of other systems in the environment but do not show how the system being developed interacts or is used within that environment. 2. Process Models:  Detailed View: Process models illustrate how the system is utilized within broader business processes. They detail the interactions and flow of activities involving the system. 3. UML Activity Diagrams:  Usage: UML activity diagrams are commonly used to create business process models. They define the sequence of activities, control flow, and interactions involved in specific processes, highlighting the system’s role and integration into larger workflows.  Interaction models  Interaction models are a type of system model used to represent how different components of a system interact with each other or with external entities. These models are crucial for understanding the dynamic behavior of a system and how it responds to various inputs and stimuli. They focus on the flow of information, control, or communication between different parts of the system.  Purpose of Interaction models: 1. Illustrate Communication: Show how components or entities exchange information and control signals. 2. Describe Behavior: Help in understanding how the system behaves in response to events and interactions. 3. Facilitate Design: Aid in designing and specifying the interactions between system components, which is crucial for integration and functionality. Use case modeling  Use cases were developed originally to support requirements elicitation and are 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. Transfer-data use case  A use case in the MHC-PMS  This table explains the description of the ‘Transfer data’ use-case MHC-PMS: Transfer data Actors Medical receptionist, patient records system (PRS). Description A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment. Data Patient’s personal information, treatment summary. Stimulus User command issued by medical receptionist. Response Confirmation that PRS has been updated. Comments The receptionist must have appropriate security permissions to access the patient information and the PRS. Use cases in the MHC-PMS involving the role ‘Medical Receptionist’ Sequence diagrams  Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system.  A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.  The 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 by annotated arrows. Sequence diagram for View patient information Structural models  Structural models are used in system modelling to represent the organization and composition of a system, including its components and their relationships. These models focus on the static aspects of a system, illustrating how different elements are arranged and how they interact at a structural level.  Purpose of structural model: 1. Visualize System Architecture:  Components and Relationships: Display the organization and interconnections of system components.  Hierarchy and Composition: Illustrate the system’s structure and how its elements are arranged. 2. Facilitate Design and Implementation:  Design Blueprint: Act as a guide for designing the system’s architecture.  Component Interaction: Clarify how components interact and integrate to ensure effective implementation. Structural models 3. Documentation and Maintenance:  System Documentation: Provide detailed documentation of the system’s structure for development, testing, and maintenance.  Change Management: Help manage changes by clearly showing the impact on system components. 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.  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. Classes and associations in the MHC-PMS The Consultation class Generalization  Generalization is a technique used to simplify and manage complexity by grouping entities into broader classes rather than focusing on their individual details.  Application:  Daily Life: We categorize experiences into general classes (e.g., animals, cars) and learn the characteristics of these classes, which helps us infer common traits (e.g., squirrels and rats are both rodents).  System Modeling: Generalization in system design helps identify common attributes and operations among classes, making it easier to manage changes. You only need to update the general class rather than every specific class.  Object-Oriented Programming:  Implementation: In languages like Java, generalization is achieved through class inheritance. Higher-level classes (superclasses) define common attributes and operations, which are inherited by lower-level classes (subclasses).  Subclassing: Subclasses inherit features from superclasses and can introduce additional, more specific attributes and operations. A generalization hierarchy A generalization hierarchy with added detail  Aggregation models  Aggregation models are used to represent the relationships between components or elements within a system, focusing on how they are grouped or composed. Aggregation is a specific type of association in which one component (the whole) is made up of one or more other components (the parts), but the parts can exist independently of the whole. This concept is crucial for understanding and designing the structure of complex systems.  Purpose of Aggregation Models: 1. Illustrate Component Relationships:  Part-Whole Relationships: Show how components are grouped into larger structures and how these structures are composed of smaller, interrelated parts.  Hierarchical Structure: Provide a clear view of the hierarchical organization and dependencies between components. 2. Support System Design:  Design Organization: Help design systems by organizing components into meaningful groups or modules.  Component Integration: Facilitate understanding of how different parts of the system fit together and interact. 3. Enhance Understanding:  Complexity Management: Simplify the understanding of complex systems by breaking them down into aggregated components.  Modularization: Aid in modular design by grouping related components into aggregates, improving manageability and scalability.  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.  Purpose of Behavioral models : 1. Understanding Behavior: They reveal the mechanisms behind human actions by examining environmental, psychological, and social factors. 2. Predicting Behavior: They help forecast how people might respond to different situations based on observed patterns. 3. Designing Interventions: They inform the creation of programs aimed at promoting positive behaviors and reducing negative ones, such as in health or education. 4. Improving User Experience: In UX design, these models are used to create systems and interfaces that better meet users' needs and enhance their satisfaction. 5. Personal Development: They help individuals understand and improve their own behaviors and motivations through tailored strategies.  Behavioral models  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, although this is not always the case. Data-driven modelling (DDM)  Data-driven modeling focuses on systems that operate based on the data they receive, with minimal reliance on external events. Key points include: 1. Action Sequence: These models illustrate the step-by-step processes involved in handling input data to produce output. They highlight how data flows through the system and the actions taken at each stage. 2. Requirement Analysis: Data-driven models are valuable for analyzing system requirements, as they map out the entire process from data input to output, providing a clear picture of how the system processes information. 3. System Control: The behavior and functionality of data-driven systems are largely dictated by the data they process rather than external triggers or events. An activity model of the insulin pump’s operation Order processing Event-driven modelling (EDM)  Event-driven modeling focuses on systems that respond to various events, often in real- time. Key aspects include:  Event Response: These models depict how systems react to external or internal events. For instance, a landline phone switching system reacts to the 'receiver off hook' event by generating a dial tone.  Finite States: The model assumes the system has a limited number of states. Events trigger transitions between these states, influencing the system's behavior.  Minimal Data Processing: In event-driven systems, the primary focus is on handling events rather than extensive data processing. The system's actions are directly linked to event occurrences. State machine models  State machine models are used to represent how systems behave in response to events, both external and internal. Key features include:  Behavior Modeling: They illustrate how a system transitions between states based on events, making them suitable for real-time systems where timely responses to stimuli are crucial.  States and Transitions: The model consists of nodes representing different states and arcs that show transitions between these states triggered by events. When an event occurs, the system shifts from one state to another.  Statecharts in UML: State machine models are represented using statecharts, which are part of the Unified Modeling Language (UML). Statecharts provide a visual framework for detailing the states and transitions within a system. A state diagram of a microwave oven Microwave oven operation Model-driven engineering  Model-Driven Engineering (MDE) is a software development methodology focused on creating and using models as the primary output of the development process. Key aspects include:  Model-Centric Approach: In MDE, models are the central artifacts, representing the design and structure of the system rather than focusing directly on programming code.  Automatic Code Generation: Programs are generated automatically from these models, which means the actual coding is largely handled by tools rather than manually by developers.  Higher Abstraction: MDE proponents argue that this approach elevates the level of abstraction in software engineering. It allows engineers to concentrate on design and functionality without being bogged down by the intricacies of programming languages or specific execution platforms. Model-Driven Architecture (MDA)  Model-Driven Architecture (MDA) is an earlier approach that laid the groundwork for broader Model-Driven Engineering (MDE). Key features include:  Model-Centric Design: MDA emphasizes using models to guide software design and implementation. It relies on a subset of Unified Modeling Language (UML) models to describe the system.  Levels of Abstraction: MDA involves creating models at various levels of abstraction. Starting from a high-level, platform-independent model, it is theoretically possible to automatically generate a functioning program from these models without manual coding.  Precursor to MDE: MDA served as a foundational approach, influencing the development of more comprehensive MDE practices by focusing on the use of models to manage complexity and automate development processes.  Types of model  The MDA method recommends that three types of abstract system model should be produced: 1. Computation Independent Model (CIM):  Purpose: Models the essential domain abstractions relevant to the system.  Also Known As: Domain models.  Focus: Captures high-level concepts and relationships within the problem domain without concern for how these abstractions will be implemented. 2. Platform Independent Model (PIM):  Purpose: Models the system's functionality and behavior without being tied to any specific platform or technology.  Description: Typically represented using UML, showing the system’s static structure and its responses to events.  Focus: Provides a general view of the system’s design, applicable across various platforms.  Types of model 3. Platform Specific Model (PSM):  Purpose: Represents the system with details tailored to a specific platform or technology.  Description: Derived from the PIM, adapting the model to accommodate platform-specific requirements and constraints.  Layers: There can be multiple layers of PSMs, each adding more platform- specific details to the base PIM model. MDA transformations Multiple platform-specific models Agile Methods and MDA  Support for Iteration: MDA proponents argue it can support iterative development, which is a key aspect of agile methods.  Conflict with Agile Principles: Extensive up-front modeling in MDA often conflicts with agile principles that favor minimal initial design and flexibility. This tension means many agile developers may find MDA challenging.  Automated Transformations: If MDA can fully automate the generation of executable code from Platform Independent Models (PIMs), it could align with agile practices by reducing manual coding and supporting rapid iterations. Executable UML  The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible.  This is possible using a subset of UML 2, called Executable UML or xUML.  Features of Executable UML  Reduced Model Types: Executable UML simplifies the modeling process by focusing on three key types: 1. Domain Models: Identify principal concerns in a system, using UML class diagrams to represent objects, attributes, and associations. 2. Class Models: Define classes, their attributes, and operations. 3. State Models: Include state diagrams for each class to describe its life cycle.  Dynamic Behavior Specification: The system's dynamic behavior can be specified either declaratively with the Object Constraint Language (OCL) or through UML’s action language.