About Modelling

When you want to communicate something to another person, what kind of principles do you use - e.g., how to describe a unicorn?

Understanding by Analogy “all meaning is mapping-mediated, which is to say, all meaning comes from analogies.” [1] Math terms: A homomorphism is a map from one structure to another preserving selected structures. Isomorphism is when there is a homomorphic mapping both ways - in a sense isomorphic structures are structurally identical. “Something” can only be Modelled with Analogy I relation to nature mostly homomorphism is appearing.

Descriptive Models Model describedBy given System E.g. physics : - the system under study is nature (which is given) - the mission is to come up with a description (model) that is so good that it can be used to predict and explain natural phenomenon.

What types of Models do we have in software engineering?

Specification (Prescriptive Model) & Descriptive Model The “specifiedBy role” is a specialization of the “describedBy role.” Model describedBy specifiedBy given describedBy specifiedBy specifies System System In physics the system under study is nature (which is given); the mission is to come up with a description (model) that is so good that it can be used to predict and explain natural phenomenon. The specification of a software system; the implementation (system) must conform to the model. A system is a group of interacting, interrelated, or interdependent elements that form a complex whole. Person Car :Person :Car 1 * name name=“Bob” :Car Model A Model Instance snapshot

Features of a Model A model according to Stachowiak exhibits the following features: Mapping feature A model is based on an original (there is a subject). Reduction feature A model only reflects a (relevant) selection of an original's properties. Pragmatic feature A model needs to be usable (in place of an original) with respect to some purpose.

Pragmatic Feature There is some purpose with the model. Often more cost-saving to obtain answers from a model than from the system. E.g., use a small model of a ship to test stability instead of a full scale ship. Pragmatic feature e.g. simulations. A common purpose for a model is that it is used in place of the system. Any answers obtained from the model should then be the same as those given by the system provided the model is adequate / correct. Typically, the motivation for using a model is cost-saving as it is often cheaper and/or quicker to obtain answers from a model than from the system.

What kind of model? What kind of model? Domain Model (an analysis model) What is needed in the system What kind of model? Analysis/Type Model How should the system work What kind of model? Design Model Understand Refine Implementation Model Problem Domain Map to code Code / Implemented System Install

Prescriptive models Descriptive model What is needed in the system Domain Model (an analysis model) What is needed in the system Descriptive model Analysis/Type Model How should the system work Prescriptive models Design Model Understand Refine Implementation Model Problem Domain Map to code Code / Implemented System Install

Perspectives when it comes to diagrams - one possible ways to classify this Conceptual: The concepts of the problem domain are addressed. Analysis class diagrams Platform Independent Models (PIMs). Specification: This perspective is typically employed under (early) design (PIM/Platform Specific Models (PSM)). Interfaces is typically specified, but not the implementation. Implementation: Class diagrams reflects the classes to implement PSMs. closer to the actual software solution

Reality Domain Model The Domain Person Car Concepts From The Domain owner Car DESCRIBE AND UNDERSTAND THE MAIN CONCEPTS WITHIN THE DOMAIN It is a sort of “thinking model”

Domain Model High Level Conceptual Model When you make a domain model you capture/understand the key concepts of the problem domain. A domain model is typically visualized with class diagrams. when you make a design model you specify the software types/classes you need to solve the problem Purpose: Describe and understand the main concepts within the domain and how these concepts relates to each other and the context of the system.

Glossary Often there is a glossary of terms that describes the domain classes and other classes. It is important to have a common vocabulary! E.g., from MagicDraw

Design Deals with objects and functions that will be programmed. Some classes from the Domain Model may be used and extended with operations. Classes necessary for the implementation are added. The operations can be modeled with sequence diagrams – showing responsibility and interaction.

Design / Implementation Model The design ends up with an implementation model. Automatic or manual mapping to code. The implementation model is a full specification of the system. Some tools allows you to trace back from this model to the models on higher levels of abstraction.

Requirements Analysis Static path Requirements Analysis and Capture Design Implementation Testing Use Cases Domain Model Design level Diagrams void func1() {......} ...... Methods class X{ .... } ..... Coding class X class Y use case 1 class X attribut1 .... attribut1 .... attribut1 .... Test Cases method() Sequence Diagrams obj1 met1() Obj2 use case 1 use case 2 Use Case Texts use case 2 <x>does<y> .... Functional path

References [1] Douglas Hofstadter. I Am a Strange Loop (ISBN 0-465-03078-5) (2007)