1. About Modelling

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

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

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

5. What types of Models do we have in software engineering?

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

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

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

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

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

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

12. 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”

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

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

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

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

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

18. References
[1] Douglas Hofstadter. I Am a Strange Loop (ISBN ) (2007)