fdt foil no 1 on methodology from domain to system descriptions by rolv bræk ntnu workshop on...
TRANSCRIPT
FDTFoil no 1
On Methodologyfrom Domain to System Descriptions
byRolv Bræk
NTNU
Workshop on Philosophy and Applicablitiy of Formal Languages
Geneve 15. September 2001
FDTFoil no 2
Topics
Methods and MethodologyLanguages for system modelling
UML, MSC, SDL, ASN.1, TTCNApproachesDomain and Architecture issues
Methods and MethodologyLanguages for system modelling
UML, MSC, SDL, ASN.1, TTCNApproachesDomain and Architecture issues
FDTFoil no 3
Methodology and Methods
A methodology is a system of methods and principles.
A method defines a systematic way to produce given results.
A methodology is a system of methods and principles.
A method defines a systematic way to produce given results.
Which is the way to quality results?
Methods provide a kind of “roadmap” with guidelines and rules
Which is the way to quality results?
Methods provide a kind of “roadmap” with guidelines and rules
The main results of systems engineering are target systems and descriptions expressed using languages.
Without any methods there would be no systems engineering discipline!
The main results of systems engineering are target systems and descriptions expressed using languages.
Without any methods there would be no systems engineering discipline!
FDTFoil no 4
The systems engineering cycle/spiral
Domain
Systemdescriptions
DevelopInstall
SystemManufacture
Domaindescriptions
Model
has needs
quality =
satisfaction of needs
FDTFoil no 5
How to describe complex realities?
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.
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.
Domaindescriptions
Systemdescriptions
First we separate domain from system; then what to separate?
Can user aspects be separated from realisation aspects?
First we separate domain from system; then what to separate?
Can user aspects be separated from realisation aspects?
FDTFoil no 6
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
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
Realisation
sof tware electronics mechanics
Deployment
Functionality
Reality
Descriptions Structure Behaviour
FDTFoil no 7
Realisation
sof tware electronics mechanics
Deployment
Functionality
Descriptions Structure Behaviour
Functionality
Is a conceptual abstraction intended to describes logical behaviour and 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
Is a conceptual abstraction intended to describes logical behaviour and 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
FDTFoil no 8
Realisation
sof tware electronics mechanics
Deployment
Functionality
Descriptions Structure Behaviour
Realisation
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)
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)
FDTFoil no 9
Realisation
sof tware electronics mechanics
Deployment
Functionality
Descriptions Structure Behaviour
Deployment and configuration descriptions
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.
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.
–configuration data;
–priorities;
–versions;
–etc.
FDTFoil no 10
RM-ODP viewpoints
• Enterprise• Enterprise
Realisation
sof tware electronics mechanics
Deployment
Functionality
Domain Descriptions Structure Behaviour
Realisation
sof tware electronics mechanics
Deployment
Functionality
System Descriptions Structure Behaviour
• Information
• Computation
• Information
• Computation
• Engineering
• Technology
• Engineering
• Technology
FDTFoil no 11
Objects and properties
Realisation sof tware electronics mechanics
Deployment
Functionality (Structure Behaviour)
Descriptions
Performance … Dependability ….
Objects Properties
Tests… Measurements
Services …
FDTFoil no 12
General description pattern
objects properties
context
content
•••component types
(follow same pattern)
•••
•••
•••
•••
design
specification
FDTFoil no 13
Coverage of the ITU-T languages and UML
Class, State- Machines
UseCase, Sequence, Collaboration,OCL, Activity
Deployment, Component, Class
Sequence, Collaboration, OCL
Sequence, Collaboration, OCL
Objects Properties
Realisation
Deployment
Functionality
UMLsdl, SDL, ASN.1 ODL
MSC,
TTCN, MSC
CHILL, ASN.1
TTCN, MSC
Objects Properties
I TU-T UML
FDTFoil no 14
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.
• 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.
FDTFoil no 15
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 understanding and communication.
Aspects
• Quality of functionality: related to the main purposes, i.e. the needs of the domain.
• Quality of realisation, i.e. way the functionality is realised.
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 understanding and communication.
Aspects
• Quality of functionality: related to the main purposes, i.e. the needs of the domain.
• Quality of realisation, i.e. way the functionality is realised.
the most effective
separated
in the translation approach
FDTFoil no 16
Which is your preferred approach?
Elabortion approach
Translation approach
Functionality
Deployment
Realisation
Initial development
New service
New realisation
Effort spent
Functionality
Deployment
Realisation
Implementation oriented
Implementation oriented
Design orientedDesign oriented
The UML approachThe UML approach
The ITU-T approachThe ITU-T approach
FDTFoil no 17
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.
• 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.
FDTFoil no 18
Macro Methodology
Develop System
Model Domain
Produce System
Install System
Domain
system
Domaindescription
Systemdescription
FDTFoil no 19
Develop system
Specify functionality
Design deployment
Specify realisation and tests
Design functionality
Specify deployment
Realise and test
FDTFoil no 20
Features of existing telematics systems
Functionality:
•Highly parallel behaviour
•Time dependency/real time
•Sessions – stateful behaviour
•Object interaction orientation
•Robust
•Highly complex
•Contention for shared resources
•A lot of operation and maintenance support
•Adaptability to new contexts and services (partly on-the-fly)
Realisation:
•Physical distribution
•High performance
•Scalability
•Replication/fault tolerance
Functionality:
•Highly parallel behaviour
•Time dependency/real time
•Sessions – stateful behaviour
•Object interaction orientation
•Robust
•Highly complex
•Contention for shared resources
•A lot of operation and maintenance support
•Adaptability to new contexts and services (partly on-the-fly)
Realisation:
•Physical distribution
•High performance
•Scalability
•Replication/fault tolerance
Adressed by CHILL
Adressed by SDL, MSC,
TTCN and ASN.1
Quality first!
FDTFoil no 21
Some trends
Functionality
•More focus on classes, associations and inheritance
•More data and object-action-orientation
•Horizontal integration/interfacing with legacy and 3rd party
•More hacker mentality (and quality problems)
•The classical features remain unchanged!
Realisation/technology
• IP connectivity
•Web based access
•Middleware
•3rd party service platforms
•More Java and Mobile code
Functionality
•More focus on classes, associations and inheritance
•More data and object-action-orientation
•Horizontal integration/interfacing with legacy and 3rd party
•More hacker mentality (and quality problems)
•The classical features remain unchanged!
Realisation/technology
• IP connectivity
•Web based access
•Middleware
•3rd party service platforms
•More Java and Mobile code
functionality
before quality
Addressed by UML
Addressed by
combining and aligning
UML and ITU-T languages
FDTFoil no 22
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
• 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