Lecture 4: System Modeling and Model-Driven Engineering Study Guide

Introduction to System Modeling

• System modeling is defined as the process of developing abstract models of a system, where each model presents a distinct view or perspective of that system.

• Current practices in system modeling involve representing a system using graphical notation, which is almost exclusively based on the notations provided in the Unified Modeling Language (UML).

• Modeling serves two primary functional purposes:

  • It helps the analyst understand the system's functionality.
  • It provides a communication medium for discussing the system with customers.

• Models are utilized differently depending on whether they represent existing or planned systems:

  • Models of the existing system are used during requirements engineering to clarify current functionality, analyze strengths and weaknesses, and establish a basis for new system requirements.
  • Models of the new system are used during requirements engineering to explain proposed requirements to stakeholders. Engineers use these to discuss design proposals and provide documentation for implementation.
  • In model-driven engineering processes, system models can be used to generate complete or partial system implementations.

System Modeling Perspectives

• System modeling is organized into four primary perspectives:
  • External perspective: Modeling the context or environment in which the system operates.
  • Interaction perspective: Modeling the interactions between a system and its environment, or between internal system components.
  • Structural perspective: Modeling the organization of the system or the structure of the data processed by the system.
  • Behavioral perspective: Modeling the dynamic behavior of the system and its responses to internal or external events.

UML Diagram Types

• There are five main UML diagram types utilized in system modeling:
  • Activity diagrams: Show the activities involved in a process or data processing.
  • Use case diagrams: Show the interactions between a system and environmental actors.
  • Sequence diagrams: Show the temporal sequence of interactions between actors and the system, and between system components.
  • Class diagrams: Show object classes and the associations between them.
  • State diagrams: Show how the system reacts to internal and external events.

Context Models and System Boundaries

• Context models illustrate the operational context of a system by showing what lies outside the system boundaries.

• Architectural models are used to show the system and its specific relationships with other external systems.

• System boundaries are established to define what is inside and what is outside the system being developed. They explicitly show other systems that are used by or depend on the target system.

• Defining the system boundary is often a political judgment. Pressures may exist to move boundaries to increase or decrease the influence or workload of specific organizational units.

• The position of the system boundary has a profound effect on the system requirements.

• The Mentcare system context includes interactions with several external systems:

  • Management reporting system
  • Patient record system
  • Admissions system
  • HC statistics system
  • Appointments system
  • Prescription system

Process Perspective and Activity Models

• While context models show other systems in the environment, they do not show how the system is used. Process models identify how the system is utilized within broader business processes.

• UML activity diagrams are commonly used to define these business process models.

• Example: Process model of involuntary detention:

  • The process begins with the "Confirm detention decision."
  • Parallel to the decision, the "Inform patient of rights" activity occurs.
  • Based on a check for a secure place: If [available], the patient is "Transfer to secure hospital"; if [not available], the patient is "Transfer to police station."
  • Based on a danger assessment: If [dangerous], the patient is "Transfer to secure hospital"; if [not dangerous], the patient is "Admit to hospital."
  • Following these, the "Record detention decision" is performed via the Mentcare system.
  • Closing activities include "Inform social care," "Inform next of kin," and "Update register" via the Admissions system.

Interaction Models and Use Case Diagrams

• Interaction modeling helps identify user requirements, highlights potential communication problems in system-to-system interactions, and helps verify if a proposed structure can deliver required performance and dependability.

• Use cases represent discrete tasks involving external interaction with a system. Actors can be people or other systems.

• Detailed Tabular Description of the 'Transfer data' use-case (MHC-PMS):

  • Actors: Medical receptionist, patient records system (PRS).
  • Description: A receptionist may transfer data from the Mentcare system to a general patient record database maintained by a health authority. This include updated personal info or treatment summaries.
  • 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.

• Common use cases for a Medical Receptionist include:

  • Register patient
  • Unregister patient
  • View patient info.
  • Transfer data
  • Contact patient

Sequence Diagrams

• Sequence diagrams model interactions between actors and objects within a system for a particular use case instance.

• Diagram structure:

  • Objects and actors are listed at the top.
  • Dotted vertical lines represent lifelines.
  • Annotated arrows indicate interactions.

• Example: View Patient Information sequence:

  • Medical Receptionist sends $ViewInfo(PID)$ to PatientInfo (P).
  • P sends $report(Info, PID, UID)$ to Authorization (AS).
  • AS performs $authorize(Info, UID)$.
  • If [authorization OK], the system returns Patient info to the Receptionist.
  • If [authorization fail], the system returns Error (no access).

Structural Models and Class Diagrams

• Structural models display the organization of a system in terms of components and their relationships.

• Static models show the system design structure, while dynamic models show the organization during execution.

• Class diagrams define the system in terms of object classes and associations.

• The Consultation class in the MHC-PMS includes:

  • Attributes: Doctors, Date, Time, Clinic, Reason, Medication prescribed, Treatment prescribed, Voice notes, Transcript.
  • Operations: $New()$, $Prescribe()$, $RecordNotes()$, $Transcribe()$.

• MHC-PMS Associations and Multiplicities:

  • A Patient attends $1..*$ Consultation(s).
  • A Doctor runs $1..*$ Consultation(s).
  • A Hospital employs $1..4$ Doctor(s).
  • A Patient is diagnosed with $1..*$ Condition(s).
  • A Patient record contains consultation and treatment data.

Generalization and Aggregation

• Generalization is a technique used to manage complexity by placing entities into general classes to share common characteristics.

• In object-oriented languages like Java, this is implemented using class inheritance. Subclasses inherit attributes and operations from superclasses and add their own specific details.

• Generalization hierarchy example:

  • Higher level: Doctor (Attributes: Name, Phone #, Email; Operations: $register()$, $de-register()$).
  • Lower levels: Hospital doctor (Staff #, Pager #) and General practitioner (Practice, Address).
  • Specific roles: Consultant, Team doctor, Trainee doctor, Qualified doctor.

• Aggregation models show how classes that represent collections are composed of other smaller classes, representing a "part-of" relationship.

  • Example: A Patient Record ($1$) is an aggregate of Patient ($1$) and Consultation ($1..*$).

Behavioral Models: Data-Driven and Event-Driven

• Behavioral models capture the dynamic behavior of an executing system in response to stimuli.

• Data-driven modeling:

  • Controlled by input data with minimal external event processing.
  • Useful for showing end-to-end processing in a system.
  • Example: Insulin pump activity model includes process steps like "Get sensor value," "Compute sugar level," "Calculate insulin requirement," "Calculate pump commands," and "Control pump."

• Event-driven modeling:

  • Typically used for real-time systems where events trigger state transitions.
  • Based on the assumption of a finite number of states.

State Machine Models: Microwave Oven Case Study

• State machine models show system states as nodes and events/stimuli as arcs. UML Statecharts are used for this representation.

• Microwave States:

  • Waiting: Oven waits for input; display shows current time.
  • Half power: Power set to $300$ watts; display shows 'Half power'.
  • Full power: Power set to $600$ watts; display shows 'Full power'.
  • Set time: Cooking time is set; display shows selected time.
  • Disabled: Operation disabled for safety; interior light is on; display shows 'Not ready'.
  • Enabled: Operation enabled; interior light off; display shows 'Ready to cook'.
  • Operation: Oven in operation; light on; display shows countdown. At completion, buzzer sounds for $5$ seconds and display shows 'Cooking complete'.

• Microwave Stimuli:

  • Half power / Full power buttons.
  • Timer button.
  • Number keys.
  • Door open / Door closed sensor switches.
  • Start / Cancel buttons.

Model-Driven Engineering (MDE)

• MDE is an approach where models, rather than programs, are the principal outputs of development.

• Programs are generated automatically from these models for specific platforms.

• Advantages:

  • Allows systems to be viewed at higher levels of abstraction.
  • Cheaper to adapt systems to new platforms through automatic code generation.

• Disadvantages:

  • Models optimized for abstraction may not be suitable for implementation.
  • Costs of developing translators for new platforms may outweigh the code-generation savings.

Model-Driven Architecture (MDA)

• MDA is a model-focused subset of MDE that uses UML models at varying levels of abstraction:

  • Computation Independent Model (CIM): Models important domain abstractions (domain models).
  • Platform Independent Model (PIM): Models system operation without reference to implementation details; shows static structure and responses to events.
  • Platform Specific Models (PSM): Transformations of the PIM for a specific application platform.

• MDA Transformations involve using a Translator guided by domain-specific guidelines, platform-specific patterns, and language-specific rules to move from CIM -> PIM -> PSM -> Executable code.

• Adoption Challenges:

  • Specialized tool support and customization are required.
  • Organizations fear reliance on small tool companies for long-lifetime systems.
  • Abstractions useful for discussion aren't always right for implementation.
  • Implementation is often less problematic than requirements engineering, security, and legacy integration.
  • Widespread adoption of agile methods has diverted attention from MDE/MDA, as agile developers may find the extensive up-front modeling of MDA contradictory to the agile manifesto.

Summary of Key Points

• Models are abstract views that ignore process details in favor of context, interaction, structure, and behavior.
• Context models position the system within its environment.
• Use cases and sequence diagrams handle system interactions.
• Class diagrams define the static structure of classes and associations.
• Behavioral models are either data-driven (activity diagrams) or event-driven (state diagrams).