Chapter 1

What’s in a name:
 Modelling
 Information System
 Language

www.unamur.be
 1.1 Modelling

www.unamur.be
 In Software Engineering people
often believe that a state is a
node in a graph and do not even
care about what a state means
in reality.

David L. Parnas
Albert Einstein

Concern for man himself and his fate

must always form the chief interest
of all technical endeavors. […]
Never forget this in the midst
of your diagrams and equations.

www.unamur.be 3
 What is modelling?

 modelling ≠ drawing
 modelling ≠ writing
documentation because the
boss asked so
 modelling ≠ stupidly sticking
to conventions
 modelling = understanding &
communicating efficiently
through models !

www.unamur.be 4
 What is modelling?
“Modelling, in the broadest sense, is the cost-effective use of
something in place of something else for some cognitive
purpose. It allows us to use something that is simpler, safer or
cheaper than reality instead of reality for some purpose.
A model represents reality for the given purpose; the model is
an abstraction of reality in the sense that it cannot represent all
aspects of reality. This allows us to deal with the world in a
simplified manner, avoiding the complexity, danger and
irreversibility of reality.”

J. Rothenberg. “The Nature of Modeling” in

Artificial Intelligence, Simulation, and Modeling,
John Wiley and Sons, Inc., 1989, pp. 75-92

www.unamur.be 5
 Summary
A model is…
 …a simplification of reality…
 …but captures its essence…
 …to help us understand it…
 … regarding an usage range and a context
(cognitive purpose)
 Must possess/retain some of the original’s qualities, to
 enables reasoning/actions regarding the system
(analysis, generation…)

www.unamur.be 6
 Models are everywhere…

Carte Routière Belgique & Luxembourg Représentation éclatée

http://www.carto-mondo.fr d’une molécule d’eau
http://www.wikimedia.org

Schéma anatomique de
la circulation sanguine
Schéma de circuit pour processeur Intel

www.unamur.be 7
 Models in Engineering…
Usual way to
 Communicate with customers
 Mitigate risks [Selic03]
 Plan work
Engineers create
models
Before building… and learn from
them…

www.unamur.be
 1.2 Information Systems

www.unamur.be
 Information Systems (IS)

“Information systems (IS) are combinations of hardware,

software, and telecommunications networks that people
build and use to collect, create, and distribute useful
data, typically in organizational settings”

Source: Joseph Valacich, Christoph Schneider Information Systems Today: Managing in

the Digital World (6th Edition), Prentice Hall, January 2013

www.unamur.be 10
 Models in IS Engineering
(Conceptual) Model = Abstract IS representation using
a standard formalism

4 ways to describe (part of) IS

 Natural language (i.e. English) Informal

 Ad-hoc notations
 Semi-formal notations
 Formal notations
Formal
Conceptual Modelling

www.unamur.be 11
 1.3 (Computer) Languages

www.unamur.be
 Natural Language (NL)
Customers buy
books.
A book has a title,
author, ISBN…

 No need to learn*
 Accessible to all kinds of stakeholders

 Verbose
 “7 deadly sins”

* = If all terms are well understood.

www.unamur.be 13
 The 7 “Deadly Sins” of NL
Ambiguity
 Several interpretations for the same text

« Customers can order the SAME books on the different Amazon

websites (.com, .co.uk, .fr, ...) »

What does “same” mean ?

 Books are stored by different regional sites: each website
can offer books stored on another regional site.
• Same = identity
 Regional sites own a copy of each book.
• Same = similarity

www.unamur.be 14
 NL: The 7 “Deadly Sins”
Noise
 Useless elements
(e.g. redundancy)
Silence (aka. Underspec.)
 Unspecified part of the
problem
Overspecification
 Describing the solution,
not the problem; or
describing irrelevant parts
regarding abstractions
www.unamur.be
Contradiction
 Incompatible statements
Forward Reference
 Mentioning something
before it is defined
Remorse
 Lately or superficially
defining something
15
 Ad-hoc Notations

 No need to
learn*

 No well-defined syntax
 No common interpretation (semantics)
=> risk of ambiguity

* = If all symbols are well understood

www.unamur.be 16
 Semi-Formal Notations

 Well-defined syntax
 Usually visual
(supposedly more intuitive)
 Common partial interpretation
 Partial automation: reasoning
and generation
 Short learning curve

 Ambiguities remain possible…

www.unamur.be 17
 Formal Notations

 Well-defined syntax
 Common interpretation (mathematically sound)
 Greater automation: reasoning and generation

 Hard to read
 Long learning curve (unavoidable?)

www.unamur.be 18
 In summary, for IS languages
1. Is the syntax (aka. the language’s
symbols and vocabulary) formally
defined?
 e.g., with a BNF, a metamodel, an Syntax
Formally
UML Class Diagram Defined?

2. Is the semantics (aka. the language’s Semantics

meaning, or interpretation) formally Formally
Defined?
defined?
 e.g., with an SOS, a translation
(compilation) to another language Informal Semi- Formal
Formal
3. Find balance between
 Difficulty to learn the language; and
 Potentiality of automation

www.unamur.be 19
 1.4 Model Qualities

www.unamur.be
 Model Qualities

To be useful a model should be [Selic03]

 Abstract
 and understandable
 and precise
 and predictive
 and inexpensive « Essentially, all models are
wrong, but some are useful »,
George E.P. Box

www.unamur.be 21
 Model Qualities
Abstract
 Focus on important aspects
 …while ignoring others
 A model is always a simplification, caricature or
viewpoint
 … that need to be conservative wrt.
properties/analysis one wants to perform

Abstraction is the most effective way to deal with always

increasing complexity of IS
www.unamur.be 22
 Model Qualities
Understandable
Syntax should be intuitive for the intended
audience (domain expert, developer, etc.)

Depends on expressiveness and syntax

 Ability to communicate a complex idea
 … with few well-chosen symbols

Example: Diagram vs. SQL code

www.unamur.be 23
 Models Qualities
Precise
 Precision is only measurable if there is no ambiguity in
the representation (i.e. well-defined syntax/semantics)

 A model must tell:

• The truth (correctness)
• The whole truth (complete)
• Nothing but the truth (no noise or overspecification)

 Lack of ambiguity does not guarantee precision, but is a

pre-requisite!
www.unamur.be 24
 Model Qualities: Precise
Meh
x. bird(x)  fly(x)
Formal (= non ambiguous)
Fly
Bird fly
Bird

…but imprecise (incorrect)!

From oxford dictionary: a warm-blooded egg-laying vertebrate
animal distinguished by the possession of feathers, wings, a beak,
and typically by being able to fly

www.unamur.be 25
 Model Qualities: Precise

``The bridge is 2700m long. It will be supported by seven piers. The distance
between two piers is always 350m. The distance between an outer pier and
the edge of the bridge is 300m, and must not be longer than the distance
between piers.’’

www.unamur.be 26
 Model Qualities
Predictive

 Model can be used to deduce correct and non-trivial

properties
 Greatly depends on abstractions, precision and
representation…
(See further “how to learn from models?”)

www.unamur.be 27
 Model Qualities
Predictive
x. Bird(x)  Ostrich(x)  Fly(x)
Bird(tweety)
Ostrich(tweety)

Fly(tweety)

www.unamur.be 28
 Model Qualities
Predictive

In the Amazon IS as specified:

Can an order be delivered

without payment ?

www.unamur.be 29
 Model Qualities
Predictive

In the Amazon IS as specified:

Can an order be delivered

without payment ?

www.unamur.be 30
 Model Qualities
Predictive

In the Amazon IS as specified:

Can an order be delivered

without payment ?

www.unamur.be 31
 Model Qualities
Predictive

In the Amazon IS as specified:

Can an order be delivered

without payment ?

www.unamur.be 32
 Model Qualities
Inexpensive
A model should be drastically less expensive than the real
system – regardless of the actual existence of the latter

[Selic03]

400 M€
Few k€

www.unamur.be 33
1.5 Business and Functional Analysis

www.unamur.be
 How
Build
to learn from Models ?
 Questions remain valid for the
construction of the actual system

Inspect
 Mental execution
 Reliability?

Formally Analyse
 Require formal languages
 Reliable (in theory)
 Costly?
 Verification (≠ validation)

Experiment
 Execution, simulation, animation…
 More reliable than inspection
[Selic03]
 Concrete “grasp”
www.unamur.be 35
 Modelling and the IS Lifecycle

Course scope = IS Analysis

Problem Solution
What ? Why ? How ?
"Building the right system ?" "Building the system right ?"
www.unamur.be 36
 Importance of Analysis
Common sense: “if we are unable to identify and
communicate precisely about the problem that the IS is
intended to solve, there is little chance of solving it!”

“The most fundamental quality of software is its

compliance with the requirements”

Unfortunately these arguments do not always affect

practice as they should…

www.unamur.be 37
 State of the Art

www.unamur.be 38
 A Huuuuuuuuge Waste…
IT expenses (incl. software, hardware, services)
 1.2 B$ in 2006 [source IDC]
 3,875 (3.8 T !) B$ (planned 2014) [source Gartner]
Software project success rates (352 org / 8380 proj.)
 Type 1: success, Type 2: challenged, Type 3: failed

Type 3 Type 1 Type 3 Type 1

31% 16% 24% 32%

Type 2 Type 2
53% 44%
Source: Standish Group
www.unamur.be 39
 Why Do Projects Fail?
Healthcare.gov
 Underestimation of performance requirements
 Underestimation of complexity [Source Calleam]

More generally
 54% of errors are discovered during system operation
 45 % of errors are introduced during analysis
 77% of analysis errors are caused by misunderstanding
(not syntax)
 An analysis error may cost 100 times the price of an
implementation error… if not discovered early
[ME04]

www.unamur.be 40
 Error Correction Costs
63 projects (IBM, GE, TRW,…) [Source: Boehm]

.1-.2 RE

.5 Design

1 Implementation

2 Unit/Integration Testing

Acceptance
5 Testing

20 Maintenance

www.unamur.be 41
 Importance of Analysis
Analysis errors are thus
 The most frequent
 The hardest to fix
 The most expensive to fix

Also
 First cause of failure in IS projects
 Fixing them represent 25-45% of total project costs

[Boehm81, CHAOS94, Davis93, ESPITI96, LW00, NIST02]

www.unamur.be 42
 Importance of Modelling

Organisation Requirements What (vs. how) the system

Objectives & Requirements Specification should do to meet objectives

I would like...

Customers, Analyst Developer

Users,
Domain Experts

Models = Main means of communication amongst IS stakeholders!

www.unamur.be 43
 References
[Boehm81] B.Boehm, "Software Engineering Economics", Prentice-Hall, 1981.

[CHAOS94] Standish Group Int'l, "The CHAOS report",

http://www.pm2go.com/sample_research/chaos_1994_1.asp

[Davis93] A. Davis, "Software Requirements: Objects, Functions, and States", Prentice

Hall, 1993.

[DO90] Dorfmann, M & Thayer R, "Standards, Guidelines and Examples of System

and Software Requirements Engineering", IEEE Computer Society Press, 1990

[ESPITI96] European Software Institute (ESI), "ESPITI: European User Survey Analysis",
Février 1996, http://www.esi.es/ESSI/Reports/All/11000/Download.html

[Jackson95] M. Jackson "Software Requirements and Specification: A Lexicon of

Practice, Principles and Prejudices", Addison-Wesley 1995.

www.unamur.be 44
 References
[Jackson01] M. Jackson "Problem Frames: Analysing and Structuring Software
Development Problems", Addison-Wesley 2001.

[KO98] Kotonya, G, Sommerville, I, "Requirements Engineering: processes and

techniques", Wiley, 1998

[LW00] D. Leffingwell & D. Widrig, "Managing Software Requirements: A Unified

Approach", Addison-Wesley, 2000.

[ME04] John Mylopoulos and Steve Easterbrook, "Information Systems Analysis and
Design", lecture notes 2003-2004, University of Toronto.

[NIST02] National Institute of Standards and Technology (NIST), USA

[Selic03] Bran Selic, "The pragmatics of model-driven development", IEEE Software,

september/october 2003.

[Wieringa02] R. Wieringa. "Design Methods for Reactive Systems", Elsevier Science

2002.

www.unamur.be 45