Software Engineering System Modeling (Context models)

System Modeling
Context models
System boundaries
Context models diagram
Examples
Example diagram

1. Context models Interaction models Structural models Behavioral models

2. System Boundaries & Context Models ng visual aids

3. What Are System Boundaries? Defines what is inside and outside the system. Helps decide system functions. Avoids unnecessary complexity. Example: A hospital management system includes patient data but not pharmacy management.

4. Why Are System Boundaries Important? • Helps in defining system scope. • Avoids duplication of work. • Reduces system costs and complexity. • Ensures clear system interactions with external components.

5. What is a Context Model ? A visual representation of a system and its external entities Shows how the system interacts with users, databases, and other systems Helps in defining system dependencies

6. Example: Mentcare System Context Model Manages patient data in mental health clinics Interacts with hospital admission, patient records, and prescription systems Ensures secure and efficient data sharing

7. Conclusion System boundaries help define what a system includes Context models show system interactions with external components UML diagrams help in process visualization Helps in better system design and implementation

8. Structural models

9. 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. Helps in designing, understanding, and documenting software architecture .

10. Class Diagram A class diagram is used in object-oriented system modeling to represent classes and their relationships. It helps us understand how different parts of the system are connected. Helps in visualizing system structure before implementation .

11. Behavioral models

12. 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. These stimuli may be either data or events.

13. Data-driven modeling Event-driven modeling Model-driven engineering

14. Data-driven modeling Data-driven models show the sequence of actions involved in processing input data and generating an associated output. They can be used during the analysis of requirements as they show end-to-end processing in a system. That is, they show the entire sequence of actions that takes place from an initial input being processed to the corresponding output, which is the system’s response.

15. Event-driven modeling 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.

16. Interaction models

17. Interaction models 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 modeling.

18. Use case modelling Sequence diagrams

19. Use case modeling 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.

20. 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.