O On a Specific Model-Based Architectu ure Description Language: - PowerPoint PPT Presentation

O On a Specific Model-Based Architectu ure Description Language: An Appr roach Based on Standards Sébastien Gérard, Bran Selic Sébastien Gérard, Bran Selic † CEA-LI ST Labo oratory of m odel driven engineering for em bedded system s for em bedded system s † ( Malina Softw are Corp and Zeligsoft Lim ited) Sebastien.Gerard@cea.fr @ selic@acm .org

Thesis: A Stan ndards-Based ADL Approach • The CEA-LI ST approach to com The CEA LI ST app oach to com m plex system of system s design m ple s stem of s stem s design Component Paradigm Paradigm e3 S1 S3 e1 e1 e2 S2 Archite Archite ectural ectural Computer Computer- -Based Based Model-Based Specific Specific Specific Specific cations cations cations cations Tools Tools Tools Tools Engineering Engineering Archite Archite ectural ectural Descri Descri iption iption Langu Langu uage uage St Standards d d

The Problem : Real-Tim m e System of System s Developm ent • Com plex heterogeneous system s res sponding to real-w orld events � Multiple engineering disciplines Software system y � � Many different methods and Many different methods and tools � Resource, energy, and time constraints � Complex and often contradictory requirements Mechanical system System System m Electronics system

Requirem e ent: System -Level Approach • Design the system as a w hole rather than as an aggregate of separately designed sub-system s � Ensures system integrity � Requires a “big picture” approach; i.e R i “bi i t ” h i e., an architecture hit t • ARCHI TECTURE [ I EEE Standard 1 4 7 1 1 ] : “The fundamental organization of a s system embodied in its components, their relationships to each other, and to th relationships to each other and to th he environment, and the principles guiding he environment and the principles guiding its design and evolution” How architecture helps: • � Facilitates communications between s Facilitates communications between s stakeholders and resolution of conflicting stakeholders and resolution of conflicting requirements � Facilitates prediction of key system q qualities (e.g., performance, robustness) � Identifies technological domains � Provides basis for work partitioning � Guides finer-grained decision making g and implementation (architecture as a pervasive artifact) � Guides evolutionary development

Requirem ent: Sup porting an I terative Process • Com plex system s cannot be adequat tely in one pass � Too many unknowns, too many confl icting design choices � Requires architectural exploration to gain understanding and intuition Functionality End-user Technology Process System .etc Qualities Sales and field operator support Organization and Organization and Skills Skills culture Business Concerns Development Comp1 manager Architect Comp2 Arbiter Display Comp3 Developer Architectural Exploration Exploration Automation Automation Tester Support Support

How Architectur ral Exploration Reduces Risk • Repeated evaluation of architectural m odels ( using sim ulation, form al and inform al analyses) � Early experience with the design aws ⇒ less expensive to fix � Early detection of potential design fla E l d t ti f t ti l d i fl l i t fi Critical understanding g Critical understanding g threshold reached through threshold reached through model evaluation implementation evaluation Problem Understanding/Confidence Cost of Design g Change Design Risk t t T2 T1

Arch hitectures, Models, and ADLs • ARCHI TECTURE [ I EEE 1 4 7 1 ] : “The fu undam ental organization…” ⇒ architectural specifications abstrac ct out non-fundam ental detail ⇒ i.e., they are m odels � � “To architect is to model” To architect is to model • Characteristics of useful engineering g m odels � Purposeful (i.e., intended for specific Purposeful (i.e., intended for specific purposes/ viewpoints/ domains/ audiences) purposes/ viewpoints/ domains/ audiences) � Abstract (i.e., they leave out inessen tial detail) � Understandable (easy to comprehe end for intended audience) � Accurate (i.e., faithfully represent e Accurate (i.e., faithfully represent e lements of interest) lements of interest) � Predictive (i.e., can be used to predic ct key system characteristics) � Significantly easier and cheaper to co onstruct than the system they represent • Accuracy and understandability, in p articular, im pose im portant requirem ents on m odeling languages s for describing architectures ( architectural description languages ( ADLs ) ) � Wh t h What should an ADL for real-time sys ld ADL f l ti stems of systems look like? t f t l k lik ?

Key I ngredients fo or a Successful Real-Tim e ADL [1] Component Paradigm e3 S1 S3 RT Architectural RT Architectural e1 e2 Description Description Description Description S2 Language Language [2] Model-Based Engineering [3] Standards

[ 1 1 ] The Com ponent Paradigm Component Paradigm • Specifically: Object-oriented com pon nents � Motivation: Direct representation of b both physical and logical elements, which generally have identity and may have e state «flowPort» «flowPort» Pressure pressure : Real in : Pressure Sensor Port: Distinct interaction point for particular types of [p measured (t)] events/flows Compone ent: Responds to and generate t es events/flows, t /fl possibly based on its state • Com ponent assem blies ( configuratio ons) «flowPort» «clientServerPort» «flowPort» pressure : Real alarmOut : Binary in : Pressure Pressure Threshold Sensor Sensor Detector Detector «flowPort» pressure : Real Connector: Represents C nn t : R p nt physical coupling or a communication path

Extending the Com ponent Paradigm for Real-Tim e Component Paradigm • The functionality and quality of softw w are com ponents are a function of � the application program logic, � the properties of the underlying platf form stack (e.g., performance, reliability) and, d � the deployment of the components to o elements of the platform ality of service of our system s ⇒ these • Architects should care about the qua factors m ust be accounted for during factors m ust be accounted for during g design g design Deployment: allocation of components to platform components to platform CompA CompA Co Co mpB mpB elements Thread1 Th d1 Socket S k t Th Thread2 T T d2 Operating System/SW Framewo ork Hardware Platform Hardware Platform Platform: combination of software and hardware required to execute an q application

[ 2 ] Model-B ased Engineering ( MBE) e3 S1 S3 e1 e2 S2 Model-Based Engineering g g • An approach to system and softw a re developm ent in w hich softw are m odels play an indispensable role • Based on tw o tim e-proven ideas: (1) ABSTRACTION (2) AUTOMATION S1 S1 e3/action3 e3/action3 Realm of Realm of S3 S3 Realm of Realm of modeling tools e1/action1 e1/action1 e2/action2 languages e2/action2 S2 S2 switch (state) { switch (state) { case‘1:action1; case‘1:action1; newState(‘2’); newState(‘2’); break; break; case 2:action2; case‘2:action2; case‘2:action2; case 2:action2; newState(‘3’); newState(‘3’); break; break; case’3:action3; case’3:action3; newState(‘1’); newState(‘1’); break;} break;}

Autom ation in MBE e3 S1 S3 e1 e2 S2 Model-Based Engineering g g • Autom ated analyses, transform a ations, code generation � Example: performance analysis of U p p y ML models using queueing theory g q g y Automated model transformation Modeling Modeling Tool Tool Performance Performance A A Analysis Tool Analysis Tool l l i i T T l l 4 μ 2.5 2.5 3.1 3.1 5 Automated Performance Performance inverse transformation f annotations

[ 3 ] Standards Standards Standards Standards have traditionally provided d the m ost dram atic boosts to • technological progress technological progress • Standards are useful because: � They support specialization y pp p � Standards are interfaces between dif fferent specialization domains � Specialization is beneficial since it all ows complex topics to receive due attention (no need to worry too much about ot ther specialties) � E.g., a vendor specializing in analyzin ng UML models need not worry about providing a UML editing tool Standards enable vendor independen nce • � Users have a choice of different vend Users have a choice of different vend dors (no vendor “tie in”) dors (no vendor “tie-in”) � Forces vendors into competing and im mproving their products