Module 4: The Modelling Method
Why "just having a language" is not enough — viewpoints, views, model organisation, and a preview of the major MBSE frameworks.
Language is Not Enough
In Module 3 we explored the first pillar of MBSE — the modelling language. You now understand what SysML, UML, and domain-specific languages offer: a vocabulary and grammar for describing systems. But having a language is like having a dictionary — you still need grammar rules, essay structure, and a writing process to produce a coherent piece of writing.
Owning a piano does not make you a pianist. You also need a method — a practice routine, music theory, scales, and a structured approach to learning pieces. Without a method, two people with the same piano will produce very different (and possibly incompatible) music. MBSE works the same way: the language is the piano; the method is the discipline that makes the music coherent.
Without an agreed modelling method, different engineers using the same language will produce inconsistent, incompatible models. One engineer might start with requirements, another with structure, a third with behaviour — and the resulting models will not fit together. The method provides the discipline that turns individual modelling efforts into a coherent system description.
What goes wrong without a method?
- Inconsistent structure: Models are organised differently by each team, making integration painful.
- Missing viewpoints: Important stakeholder perspectives are overlooked because no one prescribed them.
- Redundant work: Engineers duplicate effort because they do not know what models already exist or how to reuse them.
- Traceability gaps: Without prescribed relationships between model elements, it becomes impossible to trace requirements through design to verification.
What is a Modelling Method?
A modelling method is a prescribed sequence of modelling activities, the viewpoints and views to create, and the rules for organising and relating model elements. It answers three fundamental questions:
- What models do I create? — Which diagrams, views, and artefacts are required?
- In what order? — Which modelling activities come first, and which depend on earlier outputs?
- How do they relate? — How are model elements traced and linked across different views?
A well-defined method provides a repeatable process that any qualified engineer can follow to produce a consistent, complete system model. It bridges the gap between having a language (the notation) and having a usable, coherent model (the result).
ISO 42010 (formally ISO/IEC/IEEE 42010:2022) is the international standard for architecture description. It defines the concepts of architecture framework, viewpoint, view, and model kind — providing a rigorous vocabulary for describing how system architectures should be documented. Most MBSE methods align with ISO 42010 concepts, even if they do not reference the standard explicitly.
Components of a modelling method
- Viewpoint definitions: What perspectives on the system are needed (functional, structural, behavioural, etc.).
- View specifications: What each view contains, its notation, and its purpose.
- Process steps: The sequence of activities — e.g., "first capture stakeholder needs, then define use cases, then allocate functions to structure."
- Model organisation rules: How packages, namespaces, and directories should be structured.
- Consistency rules: How to ensure that elements defined in one view are correctly referenced in another.
Viewpoints and Views
A complex system cannot be fully understood from a single perspective. Different stakeholders care about different aspects: the customer cares about functionality, the safety engineer cares about hazards, the manufacturing team cares about physical structure. Viewpoints and views provide a disciplined way to present multiple perspectives on the same system.
Consider a building. It has floor plans (structural view), electrical diagrams (electrical view), and evacuation routes (safety view). All three describe the same building, but from different stakeholder perspectives. An architect reads the floor plan; an electrician reads the wiring diagram; a fire marshal reads the evacuation plan. No single diagram tells the whole story — but together they provide a complete picture.
ISO 42010 core concepts
ISO 42010 defines a precise vocabulary for architecture description:
- Architecture Framework: A coordinated set of viewpoints, conventions, and practices for architecture description within a specific domain or community.
- Viewpoint: A specification of the conventions for constructing and interpreting a particular type of view. It defines what to model and how.
- View: A concrete representation of the system from a particular viewpoint. It is an instance of the viewpoint's specification.
- Model Kind: The conventions for a particular type of model within a view (e.g., "a SysML block definition diagram" is a model kind).
Stakeholder-driven viewpoints
The choice of viewpoints should be driven by stakeholder concerns. The table below illustrates how different stakeholders lead to different viewpoints:
| Stakeholder | Concern | Viewpoint | Example View |
|---|---|---|---|
| Customer | What does the system do? | Functional | Use case diagram, operational scenarios |
| Systems Architect | How is the system structured? | Structural | Block definition diagram, internal block diagram |
| Safety Engineer | What can go wrong? | Safety | Fault tree, hazard analysis view |
| Software Developer | What behaviour must be implemented? | Behavioural | State machine, activity diagram |
| Test Engineer | How do we verify the system? | Verification | Test case matrix, requirements traceability |
| Project Manager | What is the schedule and cost? | Project | Work breakdown structure, milestone view |
A good modelling method prescribes which viewpoints are mandatory, which are optional, and how views from different viewpoints relate to one another through traceability.
The Major MBSE Frameworks — A Preview
Over the past two decades, several MBSE frameworks (methods) have emerged, each with a different philosophy, origin, and focus. This section provides a brief overview — Modules 6, 7, and 8 will deep-dive into OOSEM, MagicGrid, and IBM Harmony respectively.
OOSEM (Object-Oriented SE Method)
Developed by INCOSE, OOSEM follows a top-down approach: stakeholder needs → use cases → logical architecture → physical architecture. It is language-agnostic in principle but closely associated with SysML. OOSEM emphasises requirements traceability and iterative refinement.
MagicGrid
Created by No Magic (now Dassault Systèmes), MagicGrid organises modelling into a matrix of rows (problem domain, solution domain, implementation) and columns (requirements, structure, behaviour, parameters). Its strength is a clear, visual roadmap that tells engineers exactly which cell to fill in next.
IBM Harmony
A use-case-driven, architecture-centric method developed by IBM Rational. Harmony places strong emphasis on behavioural modelling — state machines and activity diagrams are central. It follows a "specify → design → verify" cycle within each iteration.
UAF (Unified Architecture Framework)
Designed for defence and enterprise architectures, UAF provides a comprehensive set of viewpoints covering strategic, operational, service, and resource perspectives. It is more complex than the methods above and is typically used in large-scale governmental and military programmes.
CESAM (CESAMES Systems Architecting Method)
Developed by the French CESAMES institute, CESAM focuses on systems architecting with an emphasis on operational, functional, and constructional viewpoints. It is particularly popular in French aerospace and transportation industries.
| Framework | Origin | Primary Focus | Language Dependency | Complexity Level |
|---|---|---|---|---|
| OOSEM | INCOSE | Requirements-driven, top-down decomposition | Language-agnostic (often SysML) | Medium |
| MagicGrid | No Magic / Dassault | Matrix-based model organisation | SysML (tightly coupled) | Medium |
| IBM Harmony | IBM Rational | Use-case-driven, behaviour-centric | SysML / UML | Medium–High |
| UAF | OMG / NATO | Enterprise & defence architecture | UAF Profile (SysML/UML) | High |
| CESAM | CESAMES (France) | Systems architecting, operational focus | Language-agnostic | Medium |
No single framework is "best." The right choice depends on your domain (aerospace, automotive, defence), your organisation's maturity, and the modelling language you have adopted. Many organisations adapt and tailor a framework rather than adopting one verbatim. Start with the one that best fits your context and evolve it over time.
Method-Language-Tool Alignment
The three pillars of MBSE — language, method, and tool — must work in harmony. Each pillar has a distinct role:
- The method prescribes what to model and in what order.
- The language provides the constructs (keywords, diagrams, semantics) to express the models.
- The tool provides the environment to create, store, navigate, and analyse the models.
When these three are aligned, engineers can follow the method's prescribed steps, express each step using the language's constructs, and use the tool to efficiently create and manage the resulting artefacts. When they are misaligned, the result is wasted effort, workarounds, and frustration.
Examples of good alignment
- MagicGrid + SysML + Cameo Systems Modeler: The method was designed for SysML, and the tool natively supports MagicGrid templates.
- OOSEM + SysML v2 + Eclipse SysML v2 Pilot: OOSEM's process maps naturally to SysML v2 constructs, and the pilot tool supports the textual notation.
Examples of misalignment
- A method that prescribes parametric analysis, but the tool does not support constraint blocks.
- A method that requires traceability matrices, but the language has no formal trace relationship.
- A tool that supports rich behavioural modelling, but the method never prescribes behavioural views.
Common misalignment scenarios:
1. Over-powered tool, no method: The team buys an expensive MBSE tool but has no agreed method. Engineers create ad-hoc models with no consistency — the tool becomes a glorified drawing application.
2. Method-language mismatch: The method prescribes views that the chosen language cannot express (e.g., requiring cost modelling in a language with no parametric support).
3. Tool lock-in: The method is so tightly coupled to one tool's proprietary features that switching tools means abandoning the method entirely.
Always verify that your method, language, and tool form a coherent triad before committing to an MBSE adoption programme.