Post on 02-Aug-2020
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 1
Modelling Software Systemsand Engineering their Requirements:
Why should we care?
Axel van LamsweerdeUniversity of Louvain
B-1348 Louvain-la-Neuve
Inaugural LectureBelgian Francqui Chair 2006-2007
Vrije Universiteit Brussel
A serious problem ...
u US survey: 8000 software projects, 350 companies
– success: 16 %
– failure: 33 %– so so: 51 % (partial functionalities, excessive costs, big delays)
major source of failure: requirements-related causes ≅ 50% responses
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 2
A serious problem ... (2)
Major source of failure: requirements-related causes ≅ 50% responses:
– lack of user involvement 13%
– incomplete requirements 13%– changing requirements 9%
– unrealistic expectations 10%– unclear goals 5%
(www.standishgroup.com/chaos.html, 1995)
A serious problem ... (3)
u EU survey: 3800 organizations, 17 countries
Main perceived software problems are in...
– requirements specification
> 50% responses
– requirements management
50% responses
(European Software Institute, 1996)
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 3
A serious problem ... (4)
u ... perceived to persist in spite of progress in software technology
(J. Maresco, IBM developersWork, 2007)
Failure %
1994 2000 2003
100
50
other causes
requirements-related
0
Outline
u Requirements engineering (RE)– What it is– Why it is difficult– Why it is important
u Models for RE– Why models, what models?
u Goal-oriented RE– Goal-based model building
– Model analysis
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 4
What RE is, roughly ...
u Analyze problems with an existing system (system-as-is),
u Identify objectives & opportunities for new system(system-to-be),
u Define functionalities of, constraints on,responsibilities in system-to-be,
u Specify all of these in a requirements document
System = software + environment (humans, devices, other software)
Requirements in the software lifecycle
Requirements engineering
Software design
Software implementation
Software evolution
Gettingthe
rightsystem
Gettingthe
softwareright
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 5
What is RE about ?
goalsWHY ?
WHAT ?
operationalization
requirements,assumptions
domainknowledge
What is RE about ?
goalsWHY ?
WHAT ?
WHO ?
operationalization
responsibilityassignment
requirements,assumptions
domainknowledge
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 6
What is RE about ? (2)
u System requirements vs. software requirements– some phenomena are shared by the software
and its environment– other phenomena are owned by the environment– other phenomena are owned by the software
Environment Sofware
E ∩ S
TrainMoving
TrainAtStation
DoorsClosed
measuredSpeed ≠ 0
doorsState = ’closed'
errorCode = 013
What is RE about ? (3)
u System requirements: prescriptive assertionsformulated in terms of environment phenomena
TrainMoving ⇒ DoorsClosed
u Software requirements: prescriptive assertionsformulated in terms of shared phenomena
measuredSpeed ≠ 0 ⇒ doorsState = 'closed'
u Domain properties: descriptive assertions aboutenvironment, needed for mapping SysReq to SoftReq
TrainMoving ⇔ measuredSpeed ≠ 0
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 7
Requirements vs. assumptions and domain properties
u RE involves satisfaction arguments
SoftReq, Ass, Dom |— SysReq
“ in view of properties Dom & assumptions Ass, the software requirements SoftReq meet the system requirements SysReq”
SoftReq: doors get open at station
Dom: passenger can get out when doors are open
Ass: passenger gets out if doors open at destination
SysReq: passenger gets out at destination station
The RE process
start
domain analysis& elicitation
alternative proposals
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 8
The RE process
start
domain analysis& elicitation
evaluation& negotiation
alternative proposals
agreedrequirements
The RE process
start
domain analysis& elicitation
evaluation& negotiation
alternative proposals
agreedrequirements
documented requirements
specification& documentation
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 9
The RE process
start
domain analysis& elicitation
evaluation& negotiation
alternative proposals
agreedrequirements
documented requirements
consolidatedrequirements
specification& documentation
validation& verification
RE: an iterative process
start
domain analysis& elicitation
evaluation& negotiation
alternative proposals
agreedrequirements
documented requirements
consolidatedrequirements
specification& documentation
validation& verification
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 10
Why RE is hard
u Broad scope– two systems: system-as-is, system-to-be– system-to-be = software + environment– hybrid environment:
human organizations, policiesdevices, physical laws
Multiple concernsfunctional, quality, development concerns
Multiple abstraction levelsstrategic objectives, operational details
Why RE is hard
u Broad scope– two systems: system-as-is, system-to-be– system-to-be = software + environment– hybrid environment:
human organizations, policiesdevices, physical laws
u Multiple concerns– functional, quality, development concerns
u Multiple abstraction levels– strategic objectives, operational details
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 11
Why RE is hard (2)
u Multiple stakeholders
– with different background
– with different interests and conflicting viewpointsproject managersdomain expertsusers, clientssubcontractorsdecision makersanalysts, developers...
Why RE is hard (3)
u Multiple intertwined activities during iterative elicitation-evaluation-specification-consolidation
– conflict managementfunctionality vs. quality vs. costdiverging viewpoints among stakeholders
– risk managementanticipation of hazards and threats
evaluation of alternatives, prioritizationquality assurancechange anticipation
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 12
Why RE is hard (3)
u Multiple intertwined activities during iterative elicitation-evaluation-specification-consolidation
– conflict managementfunctionality vs. quality vs. costdiverging viewpoints among stakeholders
– risk managementanticipation of hazards and threats
– evaluation of alternatives, prioritization– quality assurance– change anticipation
Why RE is important
u Legal impact– contractual commitment client-provider
u Social impact– from user satisfaction
to degradation of working conditions to system rejection
u Technical impact– on many software-related artefacts
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 13
Requirements impact on many software artefacts
requirements& assumptions
project estimations & planning(size, cost, schedules)
software prototype,mockup
softwarearchitecture
call for tenders,proposal evaluation
qualityassurance checklists
projectcontract
software evolutiondirectives
software documentationuser manual
acceptancetest data
implementationdirectives
impact
Why RE is important (2)
u Impact on certification– mastered RE process required by many quality
standards & certification authorities
u Impact on economy, security, and safety– cost and consequences of errors in ...
requirements on softwareassumptions about environment
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 14
Wide variety of errors & flaws in requirements, assumptions, and domain properties
– Incompleteness critical !– Inconsistency critical !– Inadequacy critical ! – Ambiguity critical ! – Unintelligibility– Unmeasurability– Poor structure– Overspecification– Noise
Errors in requirements/assumptions are ...
u the most numerous– ± 40% of software errors
u the most persistent– often found very late, after software delivery
the most expensivecosts ... 5x more if fixed during design 10x more if fixed during implementation
20x more if fixed during integration testing 200x more if fixed after delivery66% of software error costs(Boehm, Jones, Lutz, Hooks & Farry, ...)
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 15
Errors in requirements/assumptions are ...
u the most numerous– ± 40% of software errors
u the most persistent– often found very late, after software delivery
u the most expensive– cost ... 5x more if fixed during design 10x more if fixed during implementation
20x more if fixed during integration testing 200x more if fixed after delivery– account for 66% of software error costs(Boehm, Jones, Lutz, Hooks & Farry, ...)
Requirements errors are the most dangerous
u US Aegis/Vincennes (1988): shooting of IranAir airbus– missing timing between 2 threat events in
requirements on alarm softwareu Patriot anti-missile system (1st Gulf war)
– hidden assumption on maximum usage time
London Ambulance System: fatal intervention delayswrong assumptions on crew behavior, ambulance
localization system, radio communication, ...Boeing 757 crash, Cali
wrong timing/localization assumption on flapextension point
etc
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 16
Requirements errors are the most dangerous
u US Aegis/Vincennes (1988): shooting of IranAir airbus– missing timing between 2 threat events in
requirements on alarm softwareu Patriot anti-missile system (1st Gulf war)
– hidden assumption on maximum usage time
u London Ambulance System (1993): fatal delays– wrong assumptions on crew behavior, ambulance
localization system, radio communication, ...u Boeing 757 crash, Cali (1995)
– autopilot ’s wrong timing/localization assumptionon flap extension point
u ...
Example: a fatal error in A320 braking logic
MotorReversed ⇔ MovingOnRunway
MotorReversed⇔ WheelsTurning
MovingOnRunway⇔ WheelsTurning
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 17
Finding the error by obstacle analysis
NOTMovingOnRunway ⇔ WheelsTurning
NOTMotorReversed ⇔ WheelsTurning
MotorReversed ⇔ MovingOnRunway
MotorReversed⇔ WheelsTurning
MovingOnRunway⇔ WheelsTurning
obstruction
Detecting the error by obstacle analysis
NOTMovingOnRunway ⇔ WheelsTurning
NOTMotorReversed ⇔ WheelsTurning
MotorReversed And NotWheelsTurning
Aquaplaning ...
MotorReversed ⇔ MovingOnRunway
MotorReversed⇔ WheelsTurning
MovingOnRunway⇔ WheelsTurning
obstruction
WheelsTurning And NotMotorReversed
MovingOnRunway And Not WheelsTurning
WheelsTurning And NotMovingOnRunway
WheelsNotOut WheelsBroken ...
...
...
Lufthansa crashin Warsaw
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 18
A similar fatal error in the handbraking logicof an “intelligent” car
BrakeReleased ⇔ DriverWantsToStart
BrakeReleased⇔ MotorRaised
MotorRaised ⇔AccelerPedalPressed
AccelerPedalPressed⇔ DriverWantsToStart
A similar fatal error in the handbraking logicof an “intelligent” car
BrakeReleased ⇔ DriverWantsToStart
BrakeReleased⇔ MotorRaised
MotorRaised ⇔AccelerPedalPressed
AccelerPedalPressed⇔ DriverWantsToStart
MotorRaised And NotAccelerPedalPressed
AirConditioningRaised
...
... ...
...
Driver killed by hisluxurious car on a hot summerday
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 19
Outline
u Requirements engineering (RE)– What it is– Why it is difficult– Why it is important
u Models for RE– Why models, what models?
u Goal-oriented RE– model building
– model analysis
Model-based RE
u Model =– abstract representation of complex system
(as-is or to-be)– highlights, specifies, inter-relates key
system features– facilitates analysis
u Provides focus & structure for RE activities– target for what must be elicited, evaluated,
specified, consolidated, modified
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 20
Why models for RE ?
u Abstraction from multiple details: focus on keyaspects
u Support for early detection and fix of errors
u Interface among RE activities: produce or consumemodel items
Support for understanding and explanation tostakeholders
Basis for making decisions: multiple options madeexplicit
Basis for generating requirements document
Why models for RE ?
u Abstraction from multiple details: focus on keyaspects
u Support for early detection and fix of errors
u Interface among RE activities: produce or consumemodel items
u Support for understanding and explanation tostakeholders
u Basis for making decisions: multiple options madeexplicit
u Basis for generating requirements document
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 21
Requirements on models for RE
u Adequate: close reflection of system whileabstracting from unnecessary details
u Complete & pertinent: capture of all relevant systemfacets along WHY-, WHAT-, WHO-dimensions
⇒ multi-view model
Precise & analyzable: for error detection/fix⇒ formal specification when & where needed
Multi-level: capture of different levels of abstraction& precision for incremental analysis
⇒ refinement mechanism
Requirements on models for RE
u Adequate: close reflection of system whileabstracting from unnecessary details
u Complete & pertinent: capture of all relevant systemfacets along WHY-, WHAT-, WHO-dimensions
⇒ multi-view model
u Precise & analyzable: for error detection/fix⇒ formal specification when & where needed
u Multi-level: capture of different levels ofabstraction & precision for incremental analysis
⇒ mechanism for model refinement
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 22
Requirements on models for RE (2)
u Open & evolvable⇒ highlighting of alternative options
u Traceable: easy retrieval of source, rationale,impact of modeling decisions
⇒ rich traceability links
Comprehensible by stakeholders for furtherelicitation, evaluation, validation, modification
⇒ diagrammatic representation
Requirements on models for RE (2)
u Open & evolvable⇒ highlighting of alternative options
u Traceable: easy retrieval of source, rationale,impact of modeling decisions
⇒ rich traceability links
u Comprehensible by stakeholders for furtherelicitation, evaluation, validation, modification
⇒ diagrammatic representation
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 23
KAOS: goal-oriented, model-driven RE
modeling
generation of RE deliverables
interviews documents
.html
.rtf.pdf.mif
existing systems
analysis
What models ?
Goals Agents, responsibilities
Objects Operations
on what?
who ?why ?how ?
what ?
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 24
What models ? (2)
Interaction scenarios Behaviors
Hazards Threats
I
Multiple languages are integrated forspecification of model components
u Diagrammatic, for comprehension
– AND/OR graphs
– simple subset of UML
u Formal, for analysis (optional) based on mathematical logic and automata
– Real-time linear temporal logic
– Labeled Transition Systems (LTS)
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 25
Goals
Specifying goals in RT-LTL for formal analysis
Goal Maintain [DoorsClosedUntilNextStation]
FormalSpec ∀ tr: Train, s: Station
At (tr, st) ∧ o ¬ At (tr, st) ⇒ tr.Doors = "closed" W At (tr, next(st))
Goal Achieve [FastJourneyBetweenStations]
FormalSpec ∀ tr: Train, s: StationAt (tr, st) ⇒ ◊≤T At (tr, next(st))
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 26
Objects
Responsibilities
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 27
Hazards,responses
Operationalizations
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 28
What kind of model-based reasoning ?
u Checking / deriving goal refinements &operationalizations
u Goal-oriented model animation
u Conflict analysis
Hazard analysis: generating & resolving obstacles to goals
Threat analysis for more complete model withcountermeasures - generating attack graphs
Synthesis of behavior models from scenarios & goals
What kind of model-based reasoning ?
u Checking / deriving goal refinements &operationalizations
u Goal-oriented model animation
u Conflict analysis
u Hazard analysis: generating & resolving obstacles to goals
u Threat analysis for more complete model withcountermeasures - generating attack graphs
u Synthesis of behavior models from scenarios & goals
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 29
Animation
Check demo
Refinement checking
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 30
Threat analysis for more complete model
ItemOrderedByBuyer ⇒ ◊≤7d ItemReceivedByBuyer
ItemOrdered ⇒◊≤2d ItemPaid
ItemPaid ⇒◊≤2d ItemSent
ItemPaid⇒ ◊≤1d BELIEFS(ItemPaid)
ItemSent ⇒ ◊≤3d ItemReceived
BELIEFS(ItemPaid) ⇒ ◊≤1d ItemSent
Seller
ItemPaid ⇒◊≤8h PaymentReceived
PaymentReceived ⇒◊≤8h NotificationSent
NotificationSent ⇒◊≤8h NotificationReceived
NotificationReceived ⇒BELIEFS(ItemPaid)
Seller
ShippingCo
Threat analysis for more complete model
ItemOrderedByBuyer ⇒ ◊≤7dItemReceivedByBuyer
ItemOrdered ⇒◊≤2d ItemPaid
ItemPaid ⇒◊≤2d ItemSent
ItemPaid⇒ ◊≤1d BELIEFS(ItemPaid)
ItemSent ⇒ ◊≤3d ItemReceived
BELIEFS(ItemPaid) ⇒ ◊≤1d ItemSent
Seller
ItemPaid ⇒◊≤8h PaymentReceived
PaymentReceived ⇒◊≤8h NotificationSent
NotificationSent ⇒◊≤8h NotificationReceived
NotificationReceived ⇒BELIEFS(ItemPaid)
Seller
ShippingCo
◊≤2d ItemSent∧ ¬ ItemPaid
◊≤1d BELIEFS(ItemPaid)¬ ItemPaid
ײ1d NotificationReceived
Attackerײ16h FakeNotificSent
anti-model
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 31
• Modeling terrorist threats (anti-goal model)• RE for on-board detection & reaction system
Application:Security of Aircraft in the Future European Environment
(External threats)
Threats against crew & passengers
Threats from baggage area
Synthesis of state machines from scenarios & goals
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 32
The next lectures...
u L2-L3: Model-based RE– goals, objects, agents, operations– a systematic model building method
u L4-L6: Reasoning about system models– Checking goal refinements– Deriving goal operationalizations– Obstacle analysis– Threat analysis– Conflict analysis– Goal-oriented model animation– Synthesizing behavior models from scenarios/goals
Conclusion
u Engineering high-quality requirements is difficultand critical ...– do requirements meet the system ’s goals ? under realistic assumptions ?– are such goals, requirements, assumptions
complete, adequate, consistent, non-ambiguous ?
The earliest requirements errors are found, the best
For requirements completeness: be pessimistic frombeginning about software and environmenthazards, threats, conflicts
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 33
Conclusion
u Engineering high-quality requirements is difficultand critical ...– do requirements meet the system ’s goals ? under realistic assumptions ?– are such goals, requirements, assumptions
complete, adequate, consistent, non-ambiguous ?
u The earliest requirements errors are found, the best
u For requirements completeness: be pessimisticfrom beginning about software and environment– hazards, threats, conflicts
Conclusion (2)
u Rich models facilitate the RE process and increasethe quality of the resulting product ...
– software + environment (humans, devices, othersoftware, mother Nature, attacker, attackee)
– multiple dimensions: intentional, structural,responsibility, operational, behavioral
– analyzability for early error detection & fix
– seamless transition from high-level concerns tooperational requirements
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 34
Conclusion (3)
u Goal-based reasoning is central to RE for ...
– model building & elaboration of requirements
– exploration & evaluation of alternative options(refinements, assignments)
– conflict management
– anticipation of abnormal behaviors
– optimization of model synthesis
Thanks ...
u to the KAOS crew at UCL, CEDITI and CETIC asresearchers, consultants, or tool developers
E. Letier, R. Darimont,
C. Damas, A. Dardenne, R. De Landtsheer,E. Delor, D. Janssens, B. Lambeau,P. Massonet, C. Ponsard, A. Rifaut, H. Tran Van
u to Steve Fickas and his group at Univ. Oregon
u to the EU & Region of Wallonia for significantfunding of research
Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?
Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel
© A. van Lamsweerde 35
More information ...
u ... on the method & associated techniques
A. van Lamsweerde, Requirements Engineering -From System Goals to UML Models to SoftwareSpecifications. Wiley, 2007.
www.info.ucl.ac.be/~avl
u ... on the tools:http://objectiver.comhttp://faust.cetic.be