On Methodology
from Domain to System Descriptions
by
Rolv Bræk
NTNU
Workshop on
Philosophy and Applicablitiy of Formal Languages
Geneve 15. September 2001
FDT
Foil no 1
Topics
Methods and Methodology
 Languages for system modelling
UML, MSC, SDL, ASN.1, TTCN
Approaches
 Domain and Architecture issues
FDT
Foil no 2
Methodology and Methods
A methodology is a system of methods and principles.
A method defines a systematic way to produce given results.
The main results of systems engineering are target systems and
descriptions expressed using languages.
Without any methods there would be no systems engineering discipline!
Which is the way to quality
results?
Methods provide a kind of
“roadmap” with guidelines
and rules
FDT
Foil no 3
The systems engineering cycle/spiral
has needs
Domain
Model
Domain
descriptions
Install
System
Develop
Manufacture
System
descriptions
quality =
satisfaction of needs
FDT
Foil no 4
How to describe complex realities?
Domain
descriptions
System
descriptions
Combine two golden rules:
•Separation of concerns.
Identify aspects that are as independent as
possible and describe them separately.
•Conceptual abstraction.
Replace low level concepts representing
technical detail by more abstract concepts
better suited to describe and study some
aspects, i.e. by some kind of model.
First we separate domain from system; then what to separate?
Can user aspects be separated from realisation aspects?
FDT
Foil no 5
The main separations
Since the purpose of ICT systems is to provide functionality
(perform logical behaviour and handle information);
and the functionality may be realised in many ways:
• separate functionality from realisation
• describe the deployment mapping separately
Reality
Structure
Descriptions
Behaviour
Functionality
Deployment
Realisation
mechanics
FDT
Foil no 6
electronics
software
Functionality
Structure
Descriptions
Behaviour
Functionality
Deployment
Realisation
Is a conceptual abstraction intended to describes logical behaviour and
mechanics
electronics
software
information
as clearly as possible
It should enable users and developers:
• to communicate precisely
• to establish a common understanding
• to ensure that the descriptions of functionality correctly represents the
existing domain and/or the system being developed
It provides a view where the system may be seen as a whole,
independently of realisation and technology
Is normally described in terms of structures of active and passive objects
with associated object behaviours
FDT
Foil no 7
Realisation
Structure
Descriptions
Behaviour
Functionality
Deployment
Realisation
mechanics
electronics
software
Is a precise technical definition of the realisation in terms of the technologies
used, such as mechanics, electronics and software
Is necessary to actually produce a working system
The choice of realisation depends on what properties are desired from the
realisation itself (often called non-functional properties)
FDT
Foil no 8
Deployment and configuration descriptions
Structure
Descriptions
Behaviour
Functionality
Deployment
Realisation
mechanics
electronics
–configuration data;
–priorities;
–versions;
–etc.
software
Describes aspects that come in addition to the functionality, such as distribution,
hardware/software allocation and use of middleware and defines a mapping
between functionality and realisation by:
• describing the realisation (the physical system) on a high level
• identifying the technologies used
• describing how and where the functionality is realised
• describes configurations
Serves together with functionality as the main documentation.
FDT
Foil no 9
RM-ODP viewpoints
Structure
Domain Descriptions
Behaviour
Functionality
Deployment
• Enterprise
Realisation
mechanics
Structure
electronics
software
System Descriptions
Behaviour
Functionality
Deployment
Realisation
mechanics
FDT
Foil no 10
electronics
software
• Information
• Computation
• Engineering
• Technology
Objects and properties
Descriptions
Objects
Properties
Services …
Performance …
Dependability
….
mechanics
FDT
Foil no 11
electronics
software
Tests…
Measurements
Functionality
(Structure Behaviour)
Deployment
Realisation
General description pattern
objects
properties
context
content
•••
•••
•••
FDT
Foil no 12
specification
•••
•••
component types
(follow same pattern)
design
Coverage of the ITU-T languages and UML
ITU-T
Objects Properties
UMLsdl,
MSC,
SDL,
ASN.1
TTCN,
MSC
CHILL,
ASN.1
TTCN,
MSC
Foil no 13
Functionality
OCL,
Activity
ODL
FDT
UML
Objects
Properties
UseCase,
Class,
Sequence,
StateCollaboration,
Machines
Deployment,
Component,
Class
Sequence,
Collaboration,
OCL
Deployment
Sequence,
Collaboration,
OCL
Realisation
Two main approaches:
• Elaboration approach: the functionality description is incomplete and
expressed using languages with incomplete semantics
=> the realisation description ends up as the only complete view of
the system and the functionality description is not maintained
Most UML use including the Rational Unified Process, RUP, follows
the elaboration approach
• Translation approach: the functionality description is complete and
expressed using languages with well-defined and realistic semantics
=> the functionality description is valid for the realisation, serve as
documentation and is maintained
Realisation is by (manual or automatic) translation of the
functionality description. Deployment is orthogonal to the
functionality (using the principle of distribution transparency).
Most SDL use follow this approach.
FDT
Foil no 14
Quality assurance
Techniques:
• Corrective techniques: defect detection, with subsequent correction,
e.g. formal verification, simulation, testing and inspection.
• Constructive techniques: defect avoidance, i.e. to avoid introducing
errors in the first place, e.g. synthesis and automatic program
generation, languages and methods that help to improve
the most
understanding and communication.
effective
Aspects
• Quality of functionality: related to the main purposes, i.e. the needs of
the domain.
separated
• Quality of realisation, i.e. way the functionality is realised.
in the
translation
approach
FDT
Foil no 15
Which is your preferred approach?
Implementation
oriented
The UML approach
Design oriented
The ITU-T approach
FDT
Foil no 16
Languages for functionality should
•
Support human comprehension so that human beings may fully
understand and communicate precisely about the functionality
=> build on concepts that are suitable, well defined, and easy to
understand.
• Provide analytical possibilities so that one may reason about
behaviours in order to compare systems, to validate interfaces, and
to verify properties.
=> have a semantic foundation suitable for analysis.
• Be realistic. Although overlooked in many cases, this requirement is
essential for two main reasons:
1. That it shall be possible to implement the functionality
2. That the description of the functionality can serve as valid
documentation of the real system.
=> build on concepts that can be effectively realised in the real
world.
FDT
Foil no 17
Macro Methodology
Domain
Model Domain
Install System
system
FDT
Foil no 18
Domain
description
Develop System
Produce System
System
description
Develop system
FDT
Foil no 19
Specify
functionality
Design
functionality
Specify
deployment
Design
deployment
Specify
realisation
and tests
Realise and
test
Features of existing telematics systems
Functionality:
•Highly parallel behaviour
•Time dependency/real time
Adressed by SDL, MSC,
•Sessions – stateful behaviour
TTCN and ASN.1
•Object interaction orientation
•Robust
•Highly complex
•Contention for shared resources
Quality
•A lot of operation and maintenance support
first!
•Adaptability to new contexts and services
(partly on-the-fly)
Realisation:
•Physical distribution
Adressed by CHILL
•High performance
•Scalability
FDT•Replication/fault tolerance
Foil no 20
Some trends
Functionality
•More focus on classes, associations and
inheritance
Addressed by UML
•More data and object-action-orientation
•Horizontal integration/interfacing with legacy
and 3rd party
Addressed by
•More hacker mentality (and quality problems)
combining and aligning
•The classical features remain unchanged!
UML and ITU-T languages
Realisation/technology
•IP connectivity
•Web based access
•Middleware
functionality
•3rd party service platforms
before quality
•More Java and Mobile code
FDT
Foil no 21
Is it true that:
• specifications describe implementations?
•no – they specify properties and functionality, i.e. another view
• specification languages are modeling approaches?
•no – they are just languages, but may be used for modeling
• specification languages are description techniques?
•yes/no – they may be used to describe a valid view
FDT
Foil no 22