The process of creating abstract representations (named models) of a system. Each model shows a different perspective. UML is used to illustrate the model. Models help clarify system functionality and communicate design to stakeholders.
Models serve 2 roles:
- Analysis
Clarifying what the system must do. - Design
Specifying how the system will be structured and behave.
No model is fully accurate. Each is a selective simplification. Omitted details may be critical.
Perspectives
- External
Shows system context. - Interaction
Shows interactions between system components or external entities. - Structural
Shows system organization and data structure. - Behavioral
Shows system behavior over time.
Context Modeling
Describes the environment in which a system operates. Shows system boundaries, external actors and relationships.
Often represented using system context diagrams.
System Boundary
Defines what is inside the system and what lies outside it.
- Show other systems that interact with the system.
- Influence system requirements.
- Boundary decisions may involve organizational or political considerations.
Interaction Modeling
Describes how users or system components interact with the system. Illustrated using use case diagrams and sequence diagrams.
Used to:
- Identify user requirements.
- Detect communication issues between systems.
- Evaluate system structure performance.
Structural Modeling
Models class relationships in object-oriented systems.
Generalization
A modeling technique where common features of multiple classes are abstracted into a superclass.
- Implements inheritance in object-oriented systems.
- Subclasses inherit attributes and methods from the superclass.
Aggregation
Represents a whole-part relationship between classes.
- Shows that a class is composed of other classes.
- Similar to part-of relationship in semantic models.
Behavioral Modeling
Models system behavior driven by data or events.
Data-Driven Modeling
Represents systems where processing is controlled mainly by incoming data.
- Focus on data processing workflows.
- Represent end-to-end processing.
Event-Driven Modeling
Describes systems where internal or external events trigger state changes. Used in real-time and embedded systems.
State Machine Models
Represent system behavior using states and transitions triggered by events.
- States
System conditions. - Transitions
Changes triggered by events.
Complementary Models
No single model is sufficient. Each excludes some aspect of reality:
- Context models exclude internal behaviour.
- Use case models exclude non-functional properties.
- Class diagrams exclude time and concurrency.
- Sequence diagrams exclude exceptional flows.
- Architectural diagrams exclude platform specifics.
- State models exclude cross-object concurrency.
Effective practice requires multiple complementary models at each lifecycle stage. Gaps between models are where defects most commonly reside.