Transcription
A Model-Based EngineeringMethod for System, Software andHardware Architectural DesignA method best-supported nuary 15th, 2015
ForewordThis set of slides is a light introduction to Arcadia. The method is today extensively detailed through different Thalesdocuments which are not publicly available: Reference guide, practitioner’s guide, encyclopedia of concepts, etc.Fully publishing publicly the detailed Arcadia method is a major objective of the 3-years Clarity consortium. This willhowever not be immediate, as a significant work is necessary to remove Thales references and find the best support(books, standardization technical reports, etc.).The public publishing process will also probably lead to an adaptation of some of the Arcadia existing terminology.Without changing the goals and semantics of the Arcadia current content, a few concepts will most likely berenamed.For any question about the method and its usage within Thales or to directly exchange with us, please contactarcadia-contact@thalesgroup.comCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.1 /
Current Engineering Practices and Gaps ARCADIA Goals and Action Means ARCADIA Concepts Examples Capella, a workbench supporting the method Engineering Steps Focus on Functional Analysis Focus on Justification and Impact Analysis Focus on Early Validation ARCADIA OASALAMethodological ApproachesTransitions, Requirements, IV&V ARCADIA Benefitswrt Standards: xAF, SysML, AADL of ARCADIAPAEPBSCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Contents2 /
Current Engineering Practices and GapsEngineering practices and their limits
Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.4 /The System Engineering « Ecosystem » Challenge: Collaboration* RAMT: Reliability Availability Maintainability Testability
Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.5 /The System Engineering « Ecosystem » Challenge: Collaboration* RAMT: Reliability Availability Maintainability Testability
“Full Requirements driven approach weaknesses” Bad understanding of CONOPS/CONUSE** Incoherent reference & decisions between engineering specialties Poor continuity between engineering levels Late discovery of problems in definition & architecture Underestimated Architectural Design impact / benefit No anticipation of IV&V, no functional mastering No justification, no capitalisation for reuse/product line* Deadly Sins: Péchés capitaux** CONcepts of OPerationS, CONcepts of USE*** IV&V : integration, verification, validationCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Seven Deadly Sins* in System Engineering6 /
Limits of Textual Requirements-Driven Engineering7 / Textual requirements are today the main vector of technical managementcontract with the customerHowever they have significant limitations: Informally described and not adapted to validation by formal methodsInadequate to support DesignUnable to describe a solutionTraceability links Creation processunclear and hard to formalizeRequirementsTraceability links unverifiableDifficulties to securely reuserequirements alone ?ProductBreakdownTestsdescriptionChangeRequestsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.
Requirement-Based ApproachDefinition and subsystem t validation ntsIV&V ManagementTestCampaignUn-formalised DesignTest ResultsText ReqCoherency?ProductBreakdownText tsSubsystemDesignIV&V : integration, verification, validation Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.8 /
No solution is described, only requirements allocationDefinition of suppliers delivery is weak and not sufficientChecking quality of the definition is not possible before IV&VThus, justification of definition is poor and unreliable Examples of consequences in IV&V : Components functional contents, behaviour, interface definition Poor control of versioning and complexityMissing components when verifying a requirementNo mastering of the consequences of non-maturities (PCR .)Poor mastering of behaviour(startup, non nominal states .)Difficulty in organizing / optimizing regression testsDifficulty of locating faults and impact analysis .These problems increase along with system or project complexityIVV : integration, verification, validationCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Some Consequences on Engineering9 /
ARCADIA Goals and Action MeansSolving the walls issue
A tooled method devoted to systems, software and hardwareArchitecture Engineering ToToToTounderstand the real customer need,define and share the system architecture among stakeholders,early validate system design and justify it,ease and master IVVQ (Integration, Validation, Verification, Qualification).Improve efficiency and quality of System EngineeringMaster complexity of productsFoster and secure collaborative work of engineering stakeholdersReduce development Costs & ScheduleCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.What ARCADIA Is11 /
Specialities know-howconfronted to architectureOne NeedDefinitionfor allNeed &Architecturedriving IVVQSpecialtyengineering:safety, perf,security, One global method,adaptable/adapted to each domainCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.ARCADIA Action Means – Engineering Collaboration12 /
Bad understanding ofoperational use Incoherent reference &decisions betweenengineering specialties Poor continuity betweenengineering levels Late discovery ofdefinition & architectureproblems UnderestimatedJLVArchitecture impact /benefitSeven Cardinal Virtues in System EngineeringAnalyse and formalise stakeholders need:operational scenarios & processes, functional & non-functional needDrive specialties through a unique, shared reference;coordinate and evaluate global impact of decisions on itShare reference between engineering levels;secure its application for impact analysisEarly check the technical solutionagainst Oper/Funct/NF need as well as against engineering constraintsUse architecture to strengthen engineeringaccording to engineering stakes No anticipation of IVVQ,no functional masteringManage IV&V using the common functionalreference to schedule, define and master it No justification, noCapitalise by formalising definition and design,capitalisation forreuse/product linedecisions & justificationsincludingCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.13 /
ARCADIA is NOT ARCADIA is An academic work or a tool-A set of practices specified and tested by real projectsengineers wanting to address their top priority needs Designed for traditional, top-down, waterfall or « V »lifecycleDesigned for adaptation to most processes and lifecycleconstraints : bottom-up, legacy reuse, incremental,iterative, partial Only for large / complexUsed for bids and partial problems, down-scalable Only for projects starting fromDealing with reuse, reverse engineering, evolutionmastering, hot spots addressing Only for software dominant, orUsed for thermal and power as well as information systemsor software architectures Costly and complex to set andAdjustable: Focus on your major problems first andyou will get ROI Restricted to system definitionAlso addressing & easing IV&V (integration verificationvalidation)Tested in tens of operational contextsvendor offer; Tested on toyproblemsprojectsscratchlarge system engineering, or usephase Too un-mature to be used yetCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.What Arcadia Is and Is Not14 /
Needs to Support Collaborative Architecture Building1. Common unified concepts tostructure engineering :Product-centric description& capitalisation2. Collaborative workflowBased on shared descriptionand unique referenceRequirementsManagerSupport EngineersCustomersSystemArchitectsSW/HW Designers& Developers3. Architecture AnalysisCapability & ToolsSharedArchitectureModelsOthersIVVQ ManagerCAPELLASPECIALTY TOOLCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.15 /
From Requirements Allocation to Architecture Need« Requirementto Boxallocation »Late discovery of designissues during IVV(Integration, chitecture building & JustificationArchitectureTradeoffEarly validation of the architectureMastering and optimisation ofproduct and IV&VCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.16 /
while major challengesand benefits lie hereAdaptationto Real LifeDomain-SpecificKnow-HowMany focustoo muchon this rmalism,LanguageComplex Systems Design & Management 2011Common SolutionUsabilityFlexibilityCostSafetySecurityand here17Perf.Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.The Long Way to Master Complexity 17 /
ARCADIA ConceptsExamples
1. What the users of thesystem need to accomplishFrequency tuningReceiveradio signalRadiosignalFrequencyPlay radiosignalEM wavesSound levelSelect radiofrequencySelect SoundvolumeVolumeAudio soundExtract radioRDS nameEnvironmentRadio nameFrequency tuningReceiveradio signalRadiosignalPlay radiosignalRadio ReceiverEM wavesEnvironmentDisplay radionameFrequencyUserRadio control3. How the systemwill work so as tofulfil expectationsRadio nameSelect radiofrequency4. How the systemwill be developed &builtFrequencyRCA audio cableSound levelSelect SoundvolumeVolumeAudio soundExtract radioRDS name2. What the systemhas to accomplish forthe usersFrequencyRadio nameDisplay radionameSerial RS232Play radiosignalUserRadio nameHF ReceiverRCA audio cableAudio processingAudio processorSelect radiofrequencySerialRS232User input processingSpeakerKeyboard processorSerial RS232User interfaceUserdemodulatorSerial RS232Discrete I/OAnalog board5. What is expectedfrom each designer /sub-contractorExtract radionameRDS managerDisplay radionameDisplay generationMicro controllerVGAvideocableDisplayCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.ARCADIA Concepts: Radio Set Example19 /
User NeedFrequencyFrequency tuningtuningReceiveReceiveradioradio cyPlayPlay radioradiosignalsignalEMEM waveswavesEnvironmentEnvironmentSoundSound levellevelSelectSelect radioradiofrequencyfrequencySelectSelect meSystem NeedAudioAudio soundsound UserUserExtractExtract radioradioRDSRDS namenameRadioRadio namenameDisplayDisplay radioradionamenameRadioRadio namenameNotional SolutionFinal SolutionSub-contractorsinputEPBS – End Product Breakdown StructureCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Method Steps20 /
An Example ofModelling & Early Validation:In-Flight Entertainment SystemPlaying videos on demandListening to musicSurfing the webGaming Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.21 /
Operational Analysis: ExampleActor/userUser nsionsNonfunctionalSystem NeedConstraintsAnalysisCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.22 /NonfunctionalPhysical ViewpointsArchitecture Trade-offEPBSTransition to sub-,SW,HWWhat the usersof the systemneed to accomplishActors & UsersActivities, missions,capabilitiesDynamic behaviourInteraction
Functional Need Analysis - ExampleWhat the systemhas to accomplishfor the UsersActors & SystemFunctional dataflowinterfacesDynamic behaviourModes & StatesDynamic BehaviourScenariosSystem functionSystemData exchangeOperationalAnalysisNonfunctionalSystem nsActor/userNonfunctionalPhysical ViewpointsArchitecture Trade-offEPBSTransition to sub-,SW,HWCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.23 /
Logical Architecture - Example24 /Functional allocationto componentsFirst trade-off analysis(see multi-viewpoints)System componentSub-componentsAllocated functionsLogicalArchitectureExtensionsHow the system will workso as to fulfil expectationsNonfunctionalSystem NeedConstraintsAnalysisNonfunctionalPhysical ViewpointsArchitecture Trade-offEPBSTransition to sub-,SW,HWCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.OperationalAnalysis
Physical ArchitectureImplementation componentsOperationalAnalysis(e.g. hardware)How the systemwill be developed and builtLogicalArchitectureNonfunctionalPhysical ViewpointsArchitecture Trade-offEPBSTransition to sub-,SW,HWSoftware Vs Hardware allocationFunctional allocation checkInterface definition/justificationTrade-off analysis (see multi-viewpoints)Behavioural components(e.g. software)Allocated functionsEPBS: End Product Breakdown StructureExtensionsNonfunctionalSystem NeedConstraintsAnalysisCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.25 /
EPBS and Components Integration Contracts26 /OperationalAnalysisWhat is expected fromeach designer / sub-contractorSubContractEPBS: End Product Breakdown lPhysical ViewpointsArchitecture Trade-offEPBSTransition to sub-,SW,HWSubContract Requirements Interfaces Operational use case scenarios Expected behaviour & functional dataflow Allocated non-functional constraints (latency, criticality ) Allowed implementation resources Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.NonfunctionalSystem NeedConstraintsAnalysis
Data & Interface AnalysisOperationalAnalysisSystem AnalysisJune 2010:Logical & Physical ArchitecturesCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Self-Protection System Example (Bird Eye)27 /40 op. act.150 functions400 components130 diagrams4 men.months
Part of Physical ArchitectureCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.28 /Exampe of Physical Architecture Overview
ARCADIA ConceptsIntroduction to Arcadia engineering steps
Operational Analysis ModelSystem Functional andNon-Functional Need ModelLogical Architecture ModelActivities(and Entities)layerFunctionslayerFunctionslayer« Logical »componentlayerPhysical ArchitectureModelFunctionslayer« Behavioural »componentlayer« Implementation »component layerProduct BreakdownCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Concepts, Shared Assets and Justification Links30 /
Behaviour Description Means31 /Operational AnalysisForkDATA MODELdecisionSound profileTuning ValueValues: From 0 to 100Joinis composed ofSystem Functional & NF ay radioradiosignalsignalEMEM waveswavesEnvironmentEnvironmenttrebble levelFrequency BandusesValues: 0.1, 0.2, 3.0, 6.0Unit: KHzbass levelFrequencyFrequency tuningtuningReceiveReceiveradioradio signalsignalloudnessSoundSound levellevelSelectSelect radioradiofrequencyfrequencySelectSelect meAudioAudio soundsound UserUserExtractExtract radioradioRDSRDS namenameRadioRadio namenameDisplayDisplay radioradionamenameRadioRadio namenameDataflow: Functions, op. activitiesinteractions & exchangesForkLogical ArchitecturePhysical ArchitecturedecisionJoinis kind ofFilter valueValues: From –50 to 50Unit: dBFrequencyValues: From 88 to 108Unit: MHzData model: Dataflow& scenario contents;Definition & justificationof interfacesFunctional chains,Operational processesthrough functions & op. activitiesStartMode1Mode3Mode2Product BreakdownEndModes & states: Of actors,system, componentsScenarios: Actors,system, componentsinteractions &exchangesCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Function
Behaviour Description Means32 /System Functional & NF NeedFrequencyFrequency tuningtuningReceiveReceiveradioradio cyPlayPlay radioradiosignalsignalEMEM waveswavesEnvironmentEnvironmentSoundSound levellevelSelectSelect radioradiofrequencyfrequencySelectSelect AudioAudio soundsound UserUserExtractExtract radioradioRDSRDS namenameRadioRadio namenameDisplayDisplay quencyModeRadioRadio namenameLogical Datasame exchangePhysical ArchitectureProduct BreakdownChangevalueMode or StatetransitionData or aSystemChangevalueCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Operational Analysis
Architecture Description Means33 /Dataflow: Functions, op. activitiesinteractions & exchangesSystem Functional & NF NeedFrequencyFrequency tuningtuningReceiveReceiveradioradio cyPlayPlay radioradiosignalsignalEMEM waveswavesEnvironmentEnvironmentSoundSound levellevelSelectSelect radioradiofrequencyfrequencySelectSelect meAudioAudio soundsound UserUserExtractExtract radioradioRDSRDS namenameRadioRadio namenameDisplayDisplay radioradionamenameRadioRadio namenameLogical ArchitectureComponentwiring: All kindsof componentsPhysical ArchitectureProduct BreakdownBreakdown: Of allconceptsAllocation: op. activities to actors, functions to components, behav. Components to impl.Components dataflows to interfaces, elements to configuration itemsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Operational Analysis
RequirementsManagementNeed Analysis& perationalCapabilities stificationUser llocationEPBS – End Product Breakdown StructureCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.The Engineering Triptych, ‘Three Legs Better Than One’Traceability/justification34 /
ARCADIA ConceptsCapella workbench, a tooledsupporting the method
Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.36 /ARCADIA Support by Capella Workbench (1/2)
Capella solves some of the weaknesses of COTS* or OSS*: ARCADIA Method support & guidance for modelling Method Steps, encyclopaedia, rules, diagrams User-oriented Semantics Engineer concepts rather than abstract/profiled languageSupport for « modelling in the large » Performance on large models, ergonomics, modelling aids Support for viewpoint extensions, modelling & analysis Modelextensions, diagrams extensions, viewpoint management « Semantic » Import/export capabilities (excel, SysML, AF, ) Yet ARCADIA is also deployed using other tools Excel/Access,Rhapsody, System Architect/DoDAF with reduced capabilities, however* COTS: Commercial Off The Shelf* OSS: Open Source SoftwareCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.ARCADIA Support by Capella Workbench (2/2)37 /
ARCADIA ConceptsOperational Analysis
Focuses on analysing the needs and goals, expected missions &activitiesIs expected to ensure good adequacy of System definition withregards to its real operational use – and define IVVQ conditionsOutputs : Operational Needs AnalysisNeeds, in terms of actors/users, Operational capabilities and activities, Operational use scenarios (dimensioning parameters, operational constraintsincluding safety, security, system life cycle .) Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Operational Analysis - Overview39 /
Operational Capability A capability is the ability of an organisation to provide a service thatsupports the achievement of high-level operational goals.Operational ActivityProcess step or function performed toward achieving some objective, byentities that could necessitate to use the future system for this e.g. Control traffic, go along a place, detect a threat Operational Entity An operational Entity is a real world entity (other system, device, group ororganisation ), interacting with the system (or software, equipment,hardware ) under study, or with its usersOperational Actor An actor is a [usually human] non decomposable operational EntityCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Operational Analysis: Main Concepts (1/2)40 /
Operational Interaction Operational Process Set of Operational services invocations or flows exchangedbetween Operational Activities, (e.g. Operational Interactionscan be composed of Operational data, events.).A logical organization of Interactions and Activities to fulfil anOperational CapabilityOperational Scenario A scenario describes the behaviour of a given OperationalCapabilityCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Operational Analysis: Main Concepts (2/2)41 /
Operational Analysis Workflow and Main DiagramsDefine theOperationalActivitiesDefine theInteractionsbetween Define theOperational ScenariosAllocateOperational Activitiesto iosDefine OperationalProcessesCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.42 /
ARCADIA ConceptsSystem Need Analysis
Define how the system can satisfy the former operationalneeds: Systemfunctions to be supported & related exchanges Non functional constraints (safety, security ) Performances allocated to system functional chains Role sharing and interactions between system and operators Checks for feasibility (including cost, schedule and technologyreadiness) of customer requirementsOutputs: System Functional Analysis description Interoperabilityand interaction with the users and external systems(functions, exchanges plus non-functional constraints), and systemrequirementsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.System Analysis - Overview44 /
System Analysis: Main Concepts (1/2)45 /SystemAn organized set of elements functioning as a unit. An aggregation of end products and enabling products to achieve a givenpurpose. System Actor External actor interacting with the system via its interfacesSystem MissionA mission describes a major functionality of the system from a very high levelpoint of view. It is a reason why the system is developed. high-level operational goal System Capability A capability is the ability of a system to provide a service that supports theachievement of high-level operational goalsSystem FunctionFunction at System level A function is an action, an operation or a service fulfilled by the system or byan actor when interacting with the system e.g. ‘measure the altitude’, ‘provide the position’ Ce document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.
Exchange and PortAn Exchange is an interaction between some entities such as actors, thesystem, functions or components, which is likely to influence theirbehaviour. e.g. tuning frequency, radio selection command The connection point of an exchange on an entity is called a port. Functional Exchange Piece of interaction between functions that is composed of data, events,signals, etc. A Flow Port is an interaction point between a Function and itsenvironment that supports Exchanges with other portsScenarioA scenario describes the behaviour of the system in a given Capability. Scenarios permit to specify the dynamical behaviour of the system byshowing interaction sequences performed by the actors and by the system State a physical and operational environment conditionMode a type of operation in a given state of the system, or the performance levelwithin a stateCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.System Analysis: Main Concepts (2/2)46 /
System Analysis Workflow and Main DiagramsDefine the DataModelTransition fromOperationalAnalysisDefine the Statesand lysisDefine SystemCapabilitiesDefine FunctionalChainsDescribeFunctionData FlowsAssignFunctionsTo Systemand ActorsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.47 /
ARCADIA ConceptsLogical Architecture
Intends to identify the system components, their contents,relationships and properties, excluding implementation ortechnical/technological issues. This constitutes the system logicalarchitecture.All major [non-functional] constraints (safety, security, performance,IVV ) are taken into account so as to find the best compromisebetween them.Outputs : selected logical architecture: Components& interfaces definition, including formalisation of all viewpointsand the way they are taken into account in the components design. Links with requirements and operational scenarios are also producedCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Logical Architecture - Overview49 /
Logical Function Function applied at Logical levelLogical ComponentLogical Components are the artefacts enabling a notional decomposition ofthe system as a "white box", independently from any technologicalsolutions, but dealing with major system decomposition constraints Logical components are identified according to logical abstractions (i.e.functional grouping, logical interfaces) Functional Exchange Piece of interaction between functions that is composed of data, events,signals, etc. A Flow Port is an interaction point between a Function and itsenvironment that supports Exchanges with other portsComponent Exchange Represent the interactions between Logical ComponentsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.Logical Architecture Design: Managed Entities50 /
Logical Architecture Workflow and Main DiagramsTransition fromSystemAnalysisDescribeData FlowScenariosAssignFunctionsTo ribeLogicalData FlowsCe document est la propriété de Thales Group et il ne peut être reproduit ou communiqué sans autorisation écrite de Thales S.A.51 /
ARCADIA ConceptsPhysical Architecture
Intends to identify the system components, their contents, relationships andproperties, including implementation or technical/technological issuesIntroduces rationalisation, architectural patterns, new technicalservices and componentsMakes the logical architecture evolve according to implementation, technical& technological constraints & choices (at this level of engineering)The same ‘Viewpoints-driven’ method as for logical architecture design isused for physical architecture definitionOutputs : selected Physical Architecture:Physical Components, including formalisation of all viewpoints and the way theyare taken into account in the components design Links with requirements and operational scenarios Ce d
7 / . A. Limits of Textual Requirements-Driven Engineering Textual requirements are today the main vector of technical management contract with the customer However they have significant limitations: Informally described and not adapted to validation by formal methods Inadequate to support Design Unable to describe a solution Traceability links Creation process
