System Modeling and Boundaries

System Modeling

• System modeling is the process of creating abstract models of a system.
• Each model provides a different perspective of the system.
• System modeling now primarily uses graphical notations based on the Unified Modeling Language (UML).
• Models help analysts understand system functionality.
• Models facilitate communication with customers during requirements engineering.
• Models are used to derive requirements for a system.
• They help engineers understand the system during the design process.
• Post-implementation, models document the system's structure and operation.

Context Models

• Context models illustrate a system's operational context.
• They depict what lies outside the system's boundaries.
• Social and organizational concerns influence system boundary placement.
• Architectural models show the system's relation to other systems.

System Boundaries

• System boundaries define the system's scope.
• They indicate other systems used or dependent on the system being developed.
• Placing the system boundary affects system requirements significantly.
• Defining system boundaries involves a judgment call.
• External pressures might influence the decisions about system boundaries.

UML Diagram types

• UML has 13 diagram types, but five are essential for system understanding.
• Activity diagrams depict the activities in a process or data processing.
• Use case diagrams illustrate interactions between systems and their environment.
• Sequence diagrams show interactions between system components and actors.
• Class diagrams depict object classes and their associations.
• State diagrams show system responses to internal and external events.

Process Perspective

• Context models merely show the surrounding systems, not how the targeted system is used.
• Process models explain how the targeted system works within broader business processes.
• UML activity diagrams assist in defining business process models.

Interaction Models

• Modeling user interaction helps identify user requirements.
• Modeling system-to-system interactions highlights potential communication issues.
• Modeling component interactions helps understand if the proposed system can deliver required performance and dependability.
• Use case diagrams and sequence diagrams are used for interaction modeling.
• Use case modeling focuses on interactions between the system and external actors.
• Sequence diagrams detail interactions amongst system components.

Use Case Modeling

• A use case describes the user's actions and expectations from the system during an interaction.
• Initially, use cases supported requirements elicitation and are now part of UML.
• Each use case represents a specific task involving external system interaction.
• Actors in a use case represent users or other systems interacting with the system.
• Use cases are represented both diagrammatically and through textual descriptions.

Sequence Diagrams

• Sequence diagrams are part of UML.
• They show interactions between actors and objects in a system.
• They illustrate the sequence of interactions during use cases or instances.
• The diagram lists actors and objects at the top with vertical lines extending from each.
• Interactions are depicted using annotated arrows.

Structural Models

• Structural models illustrate the organization and relationships within a system of software components.
• Static models show the design-level structure.
• Dynamic models demonstrate system structure during execution.
• These models are used when addressing system architecture.

Class Diagrams

• Class diagrams focus on object classes and their associations.
• Object classes represent general definitions for system objects.
• Associations show relationships between classes.
• In early software stages, objects in models represent real-world entities such as patients and prescriptions.
• Class modeling emphasizes real-world objects for requirements and design.

UML Classes and Associations

• The example shows a relationship between 'Patient' and 'Patient record,' represented in a class diagram.

Classes and Associations in Mentcare

• This section provides a class diagram showing various classes and their relationships—example classes: 'Consultant,' 'Patient,' 'Condition,' 'General practitioner,' 'Consultation,' 'Medication,' 'Treatment,' 'Hospital doctor'.

The Consultation Class

• This is a detailed description of the 'Consultation' class with particular attributes, including doctors, dates, times, and reasons for consultation.

Generalisation

• Generalization is a technique to manage complexity by grouping similar entities into broader classes.
• This is often used in object-oriented languages via inheritance.

A Generalisation Hierarchy

• Shows a hierarchy of doctor types (e.g., hospital doctor, consultant, general practitioner, etc.).

A Generalization Hierarchy (with Detail)

• Extends the previous hierarchy with specific attributes for each doctor type (e.g., staff number, pager number, address for general practitioner).

Object Class Aggregation Models

• Aggregation shows how collections of classes are composed of other classes.
• This is particularly useful to model the relationship between classes for a 'part-of' relationship in data models.
• In the example, the 'Patient record' is composed of a 'Patient' and multiple 'Consultations'.

Behavioral Models

• Behavioral models focus on the dynamic behavior of a system, illustrating what occurs when the system responds to stimuli.
• Stimuli can be events or data.

Data-Driven Modeling

• Many business systems are data-driven, responding primarily to data input for processing.
• Data-driven models show the sequence of actions involved in processing input data, leading to an output.
• Useful during software requirement analysis.

Event-Driven Modeling

• Real-time systems are often event-driven, with minimal data processing, responding to external and internal events.
• They rely on states and transitions caused by events.

State Machine Models

• These models represent a system's behavior in response to external/internal events.
• They show system responses as transitions between states.
• State machine models represent system states as nodes, transitions as arcs, and an event to move from state to state.
• State charts are a type of UML diagram for representing state machine models

Model-Driven Engineering (MDE)

• MDE is an approach to software development.
• Models, not code, are primary outputs of development.
• Platforms (hardware/software) use models to generate automatically.
• MDE promotes higher-level abstraction regarding programming and execution specifics. MDE is still relatively new and its effectiveness is yet unknown.

Usage of Model-Driven Engineering

• MDE is still in its early stages of development.
• Its use for software engineering remains uncertain; there are advantages and disadvantages that might need to be considered.