Home

HOOD USER MANUAL - the Ellidiss Technologies web site

Contents

1. Copyright 1995 96 by HOOD Users Group page 133 page 134 P 0 0 I HOOD USER MANUAL 1 0 by HUM Working Group F J 9 2 10 5 SUMMARY ON HOOD amp REUSE As a conclusion to this section we shall summarize some of our conclusions based on our expe rience one reuse and addressing the most important questions when wanting to go reuse e what is reusable e how do reusable 2 10 5 1 What to Reuse From our experience we have identified the following kind of reusable entities applicative domain entities where a number of reusable entities can be found but their re use is never straight forward For a domain like compilation one might for example find a simple lexical analyser up to the full Ada compiler but a reuser will never find the right com ponent just suited to its last syntactic analysis problem Briefly speaking and according to the domain the reuser may often be in trouble for choosing some component the one very suitable but very difficult to Adapt in the target environment the one possibly suitable but whose properties are hard to find or not available the one that his colleague has already flagged as bugged the one which is to be fully completed but also a heavy piece for the job the one easy to understand but not flexible to support any extension e utilities and small programming utilities such as data structure management modules I O handling modules
2. ss 243 Figure 170 STACK with protocol constraints without tasking e eeeeeeeeeeeeeeee een 244 Figure 171 STACKwith protocol constraints without tasking 00 eee eee eeeeeseeeeeeeeseeceecseecaeenaeeaee 244 Figure 172 STACK 1 with protocol constraints without tasking 000 0 eee eee eseeeeeseeeeeceeeaeeaeeaes 246 Figure 173 Client Server Code structure for class TStack 247 Copyright 1995 96 by HOOD Users Group page xxi page xxii A OO l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page xxii page 1 i HOOD USER MANUAL 1 0 HUM 1 0 I 9 1 GETTING STARTED 1 1 GENERAL PRESENTATION HOOD Hierarchical Object Oriented Design is a design method which is used after the re guirement analysis activities and covers architectural design detailed design and coding The method resulted from merging methods known as abstract machines and object oriented design and was further adapted to the needs of European Software Industry as an attempt to unify and integrate object orientation and advanced software engineering concepts and notations 2 1 1 1 HISTORY AND OBJECTIVES In September 1989 HOOD3 0 was released by the HOOD Technical Group founded by ESA In July 1992 an evolution of the design method HOOD release 3 1 incorporating feed back over two years experience on var
3. e a constant formal parameter in BOUNDED_GENERIC_STACK see figure 98 MAX STACK STZE is a formal constant parameter used in the same way Copyright 1995 96 by HOOD Users Group page 128 page 129 HOOD USER MANUAL 1 0 HUM 1 0 OBJECT BOUNDED_GENERIC_STACK is CLASS ACTIV DESCRIPTION a protected stack as an abstract data object FORMAL PARAMETERS TYPES Elements is limited private CONSTANTS AX STACK SIZE NATURAL 100 OPERATIONS Assign From i Elements To out Elements PROVIDED INTERFACE OPERATIONS Push Item in Elements Pop Item out Elements EXCEPTIONS X OverFlow X UnderFlow Figure 98 Generalization of the simple ADO BOUNDED STACK e a discriminant of a private type in BOUNDED GENERIC STACKS see figure 99 MAX STACK SIZE is a discriminant used for constraining the array component of the in ternal stack record OBJECT BOUNDED GENERIC STACKS is CLASS PASSIVE DESCRIPTION a simple generic stack as an abstract data type FORMAL PARAMETERS TYPES Elements is limited private OPERATIONS Assign From i Elements To out Elements PROVIDED_INTERFACE TYPES Stacks MAX_STACK_SIZE Natural 100 is limited private OPERATIONS Push Stack in out Stacks Item in Elements Pop Stack in out Stacks Item out Elements EXCEPTIONS OverFlow UnderFlow INT
4. 142 Copyright 1995 96 by HOOD Users Group page xi page xii j HOOD USER MANUAL 1 0 by HUM Working Group a De 2 11 3 2 Requirements for selecting control expression notations 145 2 11 3 3 Defining an Associated Verification Process 146 2 11 3 4 Synchronous Automata Code for Predicate Transition nets 148 2 11 4 Performance Evaluation 149 2 11 4 1 Annotating a HOOD design for automatic performance analysis 149 2 11 4 2 Kinds of performance related data 149 2 11 4 3 Inserting annotations into a HOOD design 150 2 11 4 4 Performance Annotations fora HOOD design cc cece cece wees 150 2 11 4 5 Building a performance model from an annotated HOOD design 152 2 11 5 Timing estimation and schedulability analysis 153 2 12 TARGET LANGUAGES ccc cee cece cece cree 155 2 12 1 HOOD to targets Implementation principles 155 2 12 2 HOOD to Ada Code Generation 155 2 12 3 Sequential Languages C C Fortran and Assemblers 156 2 12 3 1 Operation Signatures ses 156 2 12 32 Exception Ss STO dame eg otre Steed eus oldie SE K O OC 156 2 12 3 3 Generation rules for passive object
5. eee eee een 67 Figure 45 Structure and ODS of object ADT STACK eee eee eee eee en 67 Figure 46 Objects exchanging a complex data Image 68 Figure 47 interface object ADT image associated to data Image 68 Figure 48 Objects of initial HOOD model exchanging a complex data Message 69 Figure 49 HADT object ADT MESSAGE providing a MESSAGE class 70 Figure 50 ADT object ADT MESSAGE providing a MESSAGE class 000 ee eee eee eee 70 Figure 51 HOOD Method of decomposition and refinement 20 0 cele eseeeeceeceeeceeeeeeeeeeeeeseneeaeeens 71 Figure 52 Typical Layered Model of a on board Application 73 Figure 53 Typical System Information Model partitioned through Technological Components 74 Figure 54 Modular and ADT Refinement ss 76 Figure 55 Principle of specifying Interfaces through ADTS 00 0 eee cece eee ee eee eee eee eee eee 76 Figure 56 Combining Modular with ADT Refinement ee0ee eee eee eee eee een 77 Figure 57 Refinement Techniques of a HOOD model ss 79 Figure 58 Relationships between parent and child ODS description sections 81 Figure 59 States in the ODS production life cycle ss 81 Figure 60 Design Step activities and associated documentation section 85 Figure 61 Representations of tasks with HOOD siennes 88 Figure 62 Representations Of cyclic tasks
6. 173 2 14 1 Code for State Constraints 173 2 14 2 Code Generation for Protocol Constraints 175 3 GETTING THROUGH 181 3 1 HANDLING DOCUMENTATION STANDARDS 181 3 1 1 ADD st ndard ei oia Saad pend ond gel eek Vee tet et ee 182 3 1 1 1 Introduction ses ss cesse dass serie eee esters eave eee eve 182 3 1 1 2 Example of ADD Contents s ss s 182 342 DDDStandard pR Foe eet EA OR Oe Renee oad Aie Cathe Dons LE 186 3121 Introductions sis sans danse ge Soke Sao ee eae ed asd eee 186 3 1 2 2 Example of DDD Contents ccc cc esis ccc cece cere renee cece 186 Copyright 1995 96 by HOOD Users Group page xii page xiii HOOD USER MANUAL 1 0 HUM 1 0 CODE unes de re is en ee 187 3 2 1 Problem Definition sant ae SER pln Rea Obed eh Re en ee eh Se eet 187 3 2 2 Mastering the relationship between ODs and CODE files 187 3 2 2 1 Maintaining Code definition within the ODS 188 3 2 2 2 Maintaining consistency between Code and ODSs 188 3 3 REUSING ENVIRONMENTAL SOFTWARE NON HOOD CODE so eee date sean ee Salas 189 3 4 MANAGING HOOD PROJECTS 190 3 4 1 Overview 3 hank 3 budo debate dobu kte lbu tains E i a hah Seine bie yet 190 3 4 2 Subcontract Ge sss Sess drame uo a le Ohare asad teak aes ewe a denta
7. separate STACK procedure PUSH item in T_Item is begin OPCS_HEADER HRTS SEMAPHORE P STACK mutex still need since another client may start stop in the meantime begin HRTS FSMS FIRE STACK PUSH X BAD EXECUTION ERQUEST possibly raised exception when X BAD EXECUTION REOUEST gt EXCEPTIONS LOG STACK Push X BAD EXECUTION REGOUEST EXCEPTIONS raise so as to propagated to client when Others gt EXCEPTIONS LOG STACK Push Others EXCEPTIONS raise end end OPCS HEADER 20 222 22202225 OPCS BODY CODE extracted from the ODS field if TOP max then possibly force object s state to FULL HRTS FSMS SET STACK FULL where OPCS code can still interact on state endif begin OPCS FOOTER HRTS SEMAPHORE V STACK release mutex semaphore for STACK end OPCS_FOOTER end PUSH function Status is non constrained operations have empty HEADER or FOOTER code begin STACK STatus end STatus Figure 168 STACK with state constraints code Sample Comments e Including OPCS_BODY directly in the procedure bodies avoids efficiency losses with pa 7 When used for active class instances the contructor in ADA and C shall have to call the OSTM Copyright 1995 96 by HOOD Users Group page 241
8. Thanks to Ada syntax and semantics a HOOD code generator has then all information for gener ating highly reliable and readable code associated to operation signatures 2 12 3 2 Exceptions When the target language does not support exceptions we recommend first to limit the use of ex ceptions in those HOOD designs and to use a specific EXCEPTIONS module of a HOOD RUN TIME LIBRARY to mimic the Ada exceptions handling An implementation of a HOOD RUNTIME module has been defined for C and C targets by some projects and have now been included in HOOD4 definition One of such solution requires a renaming by means of C macros of all operations able to propagate exceptions to their clients e Implementation of EXCEPTIONS For each HOOD exception declaration an enumerated value is defined oftypeT X VALUE which is provided by an environment object called EXCEPTIONS Raising an exception is by calling EXCEPTIONS RAISE X EXCEPTION NAME an operation that updates the exception current global value Testing an exception is done by a call to EXCEPTIONS SET with a possible branching to an exception handler by GOTO exception In C these constraints may be transparent through use of predefined macros like the fol lowing define procedure redefine a procedure name raising exceptions EXCEPTIONS Reset set current exceptions to OK X_Procedure effective call renamed by prefixing it with X_ if EXCEPTI
9. Types HOOD enforces a flat typing structure as supported by most target languages Types are declared either e inthe Provided Interface of the current object In that case they must be related to parameters of provided operations An object should not provide any type which is not an operation pa rameter type e inits Internals or they are provided by another object environment or HADT ones Data or variable Data may only be declared in e the Internal parts of a terminal object This restriction prohibits the definition of architectures with global data recognized as poorly reliable and maintainable ones e the local data part of an OPCS or OBCS in which case this data is a temporary one and only exists during the execution of the OPCS For example a state data shall be declared as much as possible locally within the OBCS in order to not be used by the OPCS Attributes Attributes of an object are data that define invariant properties of an object While some object models define attributes as a valued data readable by clients HOOD unifies all access to an ob ject through operations Hence attributes of an object in HOOD are modelled as provided oper ations possibly returning an attribute value 1 1 3 5 Class Objects A HOOD class object is defined as a template for objects which may be parameterized by ser vices types constants and or operations and allowing to factor the descriptions of identical or sim
10. 2 5 1 A DEVELOPMENT APPROACH Putting the principles of the overall HOOD design process for complex systems into work for the development of real time or distributed applications leads to a phased development approach comprising three phases e Logical definition and refinement phase elaborating a logical solution non distributed as described above e allocation phase where Virtual Nodes are defined as grouping of objects by allocation de fining potential distributable units or memory partitions 7 The allocation process starts by defining a possible physical model either by modelling the physical architecture when processors are numerous and must be abstracted into processing nodes according to the characteristics of their communication links either as a model of a planned physical architecture if not yet defined or available at that stage of the project oras a representation of the physical heavyweight processes or partitions 7 if the hard ware architecture was already frozen e configuration phase where grouping and restructuring of VNs is done for allocating them onto physical processors The configuration must deal with network constraints and target inter processors links and communication features 2 5 2 VN IMPLEMENTATION APPROACH The implementation approach is based on principles enforcing the reuse of the code developed in the logical model as is also called Post Partitioning Approach in the litera
11. 80 2 2 4 Documentation Elaboration 81 2 3 EVALUATING A HOOD DESIGN 82 2 3 1 DEFINITIONS sn toed eo nn odes asides sus aud ace oh ORS en lett 82 2 3 1 1 Goal of HOOD design verification s s s 82 2 3 1 2 Means for HOOD design verification 83 2 3 2 DOCUMENTATION FOR VERIFICATION AND REVIEWS 83 2 3 2 1 Preliminary Design and Detailed Design Documents 83 2 3 2 2 Documentation for Verifications sssss s 84 2 3 2 3 Summary on Documentation and Reviews 85 2 3 3 DESIGN STEP VALIDATION 86 234 DESIGN PROTOTYPING 2 coe eek ea ek Neh Cea Pet Se bbe Bea Bonn 87 2 3 5 LEVEL VALIDATION eet ibe ee deb a eek 87 2 3 6 DESIGN VERIFICATION IN THE DEVELOPMENT 87 Copyright 1995 96 by HOOD Users Group page x page xi A 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 a J et 24 REAL TIME ss n eba ey nude eee ces 88 2 4 1 Development Approaches 88 2 4 2 Current Development Approaches 89 2 4 2 1 Representing Common Real Time Mechanisms 89 2 4 2 2 Establishing a Real Time architecture 91 2 4 3 Advanced Deve
12. Figure 102 an Object with explicit dependency As shown in Figure 103 it is sufficient to move the required constants types and operations from the required interface see figure 102 to the formal parameters see figure 104 Copyright 1995 96 by HOOD Users Group page 131 f page 132 j HOOD USER MANUAL 1 0 by HUM Working Group J d operation1 i TORE class a c npt coupled reusable class Y gt P J 4 operation Insert Remove Insert Remove coupled reusable object coupled reused instand Figure 103 de coupling a reusable object OBJECT EXEMPLE is CLASS PASSIVE FORMAL PARAMETERS TYPES Lists is limited private OPERATIONS Insert List in out Lists Item in Elements Remove List in out Lists Item out Elements REQUIRED_INTERFACE NONE INTERNALS Exactly the same a the coupled Objects unless that the dotted notation t be used with Insert amp Remove operations Figure 104 Transformation of the above Example into a class This is not possible in any situation due to constraints on formal parameter format But this kind of practice is very easy when the required objects have an interface corresponding to standard ADOs and ADTs only private provided types and operations on them This technique when correctly applied gives a lot of benefits For instance when the reusable components library contains different forms of the same r
13. functions to terminal child types But a standard solution is to make parent unit have visibility on terminal child types through with clauses See also recommendations of HADA Copyright 1995 96 by HOOD Users Group page 15 page 16 HOOD USER MANUAL 1 0 by HUM Working Group F I 9 Figure 15 and Figure 16 CHILD1 CHILD2 ig Figure 15 Code generation principle for Parent object with CHILD1 visibility on CHILD1 generated as a library unit with CHILD2 visibility on CHILD2 generated as a library unit package PARENT is specification unit associated to object PARENT procedure X renames CHILD1 X procedure Y renames CHILD2 Y end Parent Figure 16 Code generation principle for Parent object standard generation An alternative solution is to nest the child packages into the body of the parent package whose specifications are then implemented by extra code mapping child ones what might become rather inefficient as illustrated in Figure 17 package body PARENT is body associated to object PARENT package CHILD1 is specification unit associated to object CHILD1 procedure X end CHILD1 package CHILD2 is specification unit associated to object CHILD2 procedure Y end CHILD2 procedure X is begin CHILD1 X call to CHILD operation end X end PARENT Figure 17 Code generation principle for Parent object Nesting Child packages in parent Body This solution has ho
14. impossible case end if END of opcs POP OPERATION PUSH is code similar to that of POP END_OBJECT STACKS Figure 144 Internals of ODS for active object STACKS Note that this design could still be improved at the level of the OPCS code since the operations are constrained state conditions should only be computed within the OBCS code and the excep tions should be raised within the OBCS gt code here we do the work twice 5 This may lead in troubles in ADA83 because an exception raised in an Ada task and not hanlded stops a task activity thus OBCS code should have exception handlers by default in each accept statement and at the end of the task body IT was not made here since this makes the OBCS code highly unreadable Copyright 1995 96 by HOOD Users Group page 170 page 171 HOOD USER MANUAL 1 0 HUM 1 0 OU 2 13 2 2 Ada code generation for ACTIVE OBJECT STACKS 2 13 2 2 a Ada Specification Unit with ADT_ELEMENT visibility on type T Element REQUIRED OBJECTS with PROJECT_ENV visibility on type T Status package STACKs is type T_DATA is array integer lt gt of ADT_Element T_Element type T STACK MAX integer is record DATA T DATA 1 MAX TOP integer 1 SIZE integer MAX STATUS PROJECT_ENV T_Status end record procedure Status STACK in T STACK return T Status task OBCS is OBCS task handling active constraint operations entries entry PUSH STACK in out T STACK E
15. page 243 HOOD USER MANUAL 1 0 HUM 1 0 State constrained supporting code Procedure Start HRST FSMs Procedure Stop Procedure POP HRST SEMAPHORES Procedure PUSH Procedure STATUS Procedure OSTM START STOP PUSH POP STATUS SERVER SPACE and THREAD CLIENT SPACE and THREAD package body STACK Procedure Start Procedure POP Procedure PUSH Procedure STATUS Figure 169 STACK with protocol constraints Copyright 1995 96 by HOOD Users Group page 243 page 244 HOOD USER MANUAL 1 0 HUM 1 0 OO g J A3 2 2 1 STACK with protocol constrained operations Client code with Items use Items package spec as for passive object package STACK is procedure start procedure stop procedure PUSH item in T_Item procedure POP Item out T_Item function Status return T_Status end STACK Figure 170 STACK with protocol constraints without tasking with HRTS IPCMSG InterProcessCommunication Message Handling with HRTS OBCSs Module for Client And Server OBCS code package body STACK is not any data here since all deported in the STACK_SERVER object in server partition package ClientObcs is new HRTS OBCSs ClientObcs STACK procedure PUSH item in T Item is OPCS ER code MSG IPCMSG T MSG begin MSG IPCMSG create initialise an IPC MSG data structure MSG sender S
16. Figure 79 Illustration of the representation of the physical model at terminal level Copyright 1995 by HOOD User s Group page 104 page 105 HOOD USER MANUAL 1 0 HUM 1 0 oof g J 2 6 MAN MACHINE INTERFACES 2 6 1 DEVELOPMENT APPROACH FOR COMPLEX MMIS SYS TEMS A common recommended approach for the development of Man Machine Interface MMI is to define an architecture allowing e separated development of the interactive software which is handled by specialized window ing systems such as X_WINDOWS MOTIF and the applicative software in a way that is independent of the technologies used for these developments Moreover the interactive soft ware may itself be spitted in a static part now more an more automatically generated from MMI generator tools and a dynamic part mainly consisting in the code associated to the callbacks triggered by the window gadgets e the use of ad hoc technologies people and tools with the best efficiency and productivity Although numerous developments have tried to follow this goals effective separation of appli cative and interactive parts has so far to our knowledge never or very few been performed hence the resulting software are complex and costly to maintain The reason is that the interface between a software and a windowing system comprises both stat ic and dynamic entities and data and according to the two possible control strategies event driven recommended by the MOT
17. A design document is structured according to the three spaces of hierarchies objects classes and Virtual Nodes the parent child relationships associated to each hierarchy a documentation standard for the project is mandated DO2167 ESA the standard documentation is produced from the HOOD one and is defined according to the following principles Extraction of documentation part from ODS fields Tuning of the standard in accordance with prime QA team in order to avoid redun dancies in the documentation Implementation of such approaches on industrial projects already exist see HOOD and DOD2167 standards SEXTANT92 In order to build a complete documentation as defined by a standard it is neces sary to add infor mation to the ODS during the HOOD design process such as Justification of Design Choices part That information may generally not be included in the ODS and HOOD tools handle it dif ferently Each type of document ADD ICD DDD needs so to extract a sub set of HOOD infor mation included or not in the ODS related to the life cycle phase to be documented A design document particularly ADD needs to explain the design and does not necessary in clude all information coming from the design process For example an ADD does not include the identification of nouns and verbs from the informal strategy text In the same way the process defining a method to build the system first through the logical archit
18. CONSTANTS DESCRIPTION Text in natural language giving all information for understanding and maintaining the object IMPLEMENTATION_CONSTRAINTS Natural language text giving constraints memory limits cpu performances for the object PROVIDED INTERFACE Set of element provided to client objects They are followed by a description in natural language TYPES HOOD identifier CONSTANTS HOOD identifier OPERATION SETS HOOD identifier OPERATIONS signature in Ada EXCEPTIONS HOOD identifier OBCS Only for active objects DESCRIPTION Text in natural language describing the behaviour of the object CONSTRAINED OPERATIONS Sub set of provided operations which are constrained DATA_FLOWS Textual Description of Data labels along the use relationship EXCEPTION_FLOWS Textual Description of Exceptions labels along the use relationship REQUIRED INTERFACE For each Required Object the subset of elements provided by the server object and really used in the current object TYPES CONSTANTS OPERATIONS EXCEPTIONS INTERNALS OBJECTS List all child objects implementing the object TYPES CONSTANTS DATA EXCEPTIONS definition in target language of both provided elements if not defined in the visible part and internal one OPERATIONS list of operation with their signature in Ada internal to the object OBCS Only for active objects PSEUDO CODE with suitable notation CODE in target langua
19. May 88 CAR89 Integrated Support for Requirements Analysis HOOD Design and Implementa tion A R Carmichael UNICOM HOOD Tutorials and Demonstrations Londres 28 29 novembre 1989 GIOVA89 HOOD and Z for the development of Complex Software Systems R Di Giovan ni P L Iachini Lecture Notes in Computer Science n 428 VDM 90 VDM and Z FORMAL METHODS in SOFTWARE DEVELOPMENTS HEI 89 1 Hierarchical Object Oriented Design for Ada development of large technical and realtime software M HEITZ technical Note CISI INGENIERIE 3 pages 21 06 89 HEI 89 2 Hierarchical Object Oriented Design Une m thode de conception orient e Ada pour le d veloppement de logiciels techniques et temps r els M HEITZ Note technique CISI INGENIERIE 3 pages 08 12 89 HEI 89 Hierarchical Object Oriented Design A Summary M HEITZ CISI INGE NIERIE a 10 page summary 13 11 89 HRM 89 H_OOD Reference Manual V3 0 produced by HOOD Working Group edited by ESA Noordwijk The Netherlands 09 89 HUM 89 H_OOD User Manual V3 0 produced by HOOD Working Group edited by ESA Noordwijk The Netherlands 12 89 IS 89 An Extended Algebraic Approach for Methods Formalisation Application to the HOOD Method Deuxi mes Journ es Internationales Le G nie Logiciel et ses Applications I SNEED M HEITZ B RAYNAUD Proceedings of Journ es du G nie Logiciel Toulouse 4 8 D cembre 1989 VIEL 89 H_OOD Design method and control command tech
20. Nantes Wil 91 Building a system for screening ERS 1 satellite data using the HOOD method and Ada M Eineder H J Wilhelms P Coppola A Paganone 28me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 6 2 6 ARTICLES AND PAPERS PUBLISHED IN 1990 Auton90 Use of HOOD in the Design of a Multiprocessor Real Time System I Auton Thorn Emi Proceedings of Hood conference April 1990 Manchester Airport Copyright 1995 96 by HOOD Users Group page 211 Hoo page 212 HOOD USER MANUAL 1 0 by HUM Working Group BARCE90 BARCE90 BING90 BL90 GEN90 GIOV90 IS 90 JOCT90 LAFEU90 Lai 90 LARR90 Mell90 MH90a MH90b MU90 Ne1190 MSLIB Ada a library for spatial mechanics computing JC BERGES CNES C COMPE L MALLET SIMULOG F DUCRET AEROSPATIALE Pro ceedings of the Ada Eurospace Conference Barcelona december 1990 Prototyping in Ada experience in developing the HERMES on board mission software mockup A BARCELLONA A SANTARELLI Proceedings of the Ada Eurospace Conference Barcelona december 1990 Ada realization for the process computers of the DOEL1 amp nuclera power plants M BINGEN J BEAUFAYS Proceedings of the Ada Eurospace Conference Barcelona december 1990 HOOD A Design Method for Space Industry JF Muller B Labreuille MATRA ESPACE Proceedings of American Institute of Aeronautics and Astronautics Conference Sept 1990
21. STACK_RB CODE with Items use Items with STACK_SERVER visibility need to have access to real operations and data package STACK_RB is procedure start renames STACK_SERVER Start procedure stop procedure PUSH item in T_Item procedure POP Item out T_Item function Status return T Status renames STACK_SERVER Status end STACK_SER end STACK_SER with HRTS IPCMSG InterProcessCommunicationMEssage Handling with HRTS OBCSs Module for Client And Server OBCS code package body STACK_SER is procedure PUSH MSG in IPCMSG T_MSG is OPCS_SER code Item Items T_Items begin begin item MSG INFO MSG X OK if MSG CSTRNT LSERILSER_TOER then ServerObcs insert MSG insert in return queue end if STACK_SERVER PUSH Item exception when X_BAD_EXECUTION_REQUEST gt EXCEPTIONS LOG STACK_SER PUSH X_BAD_EXECUTION_REQUEST MSG X string X_BAD_EXECUTION_REQUEST when Others gt EXCEPTIONS LOG STACK_SER PUSH Others MSG X string OTHERS end of begin if MSG CSTRNT HSERIHSER_TOER then ServerObcs insert MSG insert in return queue end if end PUSH similar code for POP_SER and STOP_SER procedure start is OPCS_SER code also for STatus begin begin MSG X OK STACK_SERVER start exception when X_BAD_EXECUTION_REQUEST gt e e e e exceptions handling as in procedure PUSH end of begin ServerObcs insert MSG insert in return queue as treated as HSER end
22. Such configuration may be thoroughly reviewed inspections authors reader cycles and more formally by automated generation of target code From that point only the design will be put under change control and every code modification shall lead to a change within an ODS and a regeneration with replay of test to validate the mod ification Copyright 1995 96 by HOOD Users Group page 195 page 196 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group De 3 4 4 REVIEWING A HOOD DESIGN 3 4 4 1 Warning When one has to evaluate a design one may face with two figures e AI verification et validation recommended by HOOD as described in section 2 3 werereg ularly performed during the development and can be traced through validation reports and minutes In this case a documentation is provided allowing to check that the solution works properly and implements the requirements Such documentation can be summarized as a description of the system configuration for each hierarchy of the system configuration e the design tree e for each object or class its description sections H1 H2 H3 its provided interface its dataflows and its behaviour e a validation report about verification along the design process e Only a minimal verifications have been preformed or no validation trace is available In this second case all validation activities have to be done as the design is evaluated In the following we set up such an
23. define the interactions with APPLICATION and or MMI on readings and updating of informations stored in the DBMS the object ADT_DBMS_DATA groups the definition of abstract data type support HOOD objects associated to data exchanges between MMI and or APPLICATION with the DBMS Copyright 1995 by HOOD User s Group page 112 page 113 HOOD USER MANUAL 1 0 HUM 1 0 oof g J 2 8 FAULT TOLERANT SYSTEMS In case where systems have additional fault tolerant constraints a similar approach can be put into work e first by developing a logical solution where the fault tolerance constraints are not taken into account but allowing validation of the essential properties of the solution e then by refining this solution to tune adapt ruggedizing it to handle specification or design faults supposing that for each HOOD object its environment is fault tolerant e finally by adapting and ruggedizing this latter solution towards a physical solution where en vironment objects of all previously ruggedized objects are now considered non fault toler ant Copyright 1995 by HOOD User s Group page 113 page 114 HOOD USER MANUAL 1 0 by HUM Working Group Copyright 1995 by HOOD User s Group page 114 page l15 i HOOD USER MANUAL 1 0 HUM 1 0 a De 2 9 ERROR AND EXCEPTIONS HANDLING 2 9 1 THE EXCEPTION CONCEPT HOOD takes the exception concept from Ada at the design level This concept allows to express smar
24. eeeeeeeeee Figure 100 A class violating Advice 29 2 in Figure 101 The same class respecting Advice 29 Figure 102 an Object with explicit dependency ss Figure 103 de coupling a reusable object Figure 104 Transformation of the above Example into a class Figure 105 level decomposition of a terminal Virtual Node Figure 106 Models and Components of a complex software architecture Figure 107 HOOD Architectural Model of a complex information system Figure 108 Target Code architecture associated to OBCS and OPCSS eee Figure 109 Extended Execution model for constrained operations Figure 110 Automata Code modelling an Object OBCS we eee eee Figure 111 Principle of I INTERFACE procedure Code Figure 112 Principle of O INTERFACE procedure Code ss Figure 113 I INTERFACE Code for HSER constraint eee eee eee eee Figure 114 O INTERFACE Code for HSER constraint 000 cee eeceesceeereeeeeceeeeeeeeeeeeeee Figure 115 I INTERFACE Code for LSER constraint 200 0 cece eeeeeseeereeeseceeeeceeeeneeeeee Figure 116 O INTERFACE Code for LSER constraint Figure 117 I INTERFACE Code for HSER constraint 0 cece eeceeeneeeeeeesseceeeecneeeneeeeee Figure 118 I INTERFACE Code for TOER_LSER constraint eee Figure 119 I INTERFACE Code for TOER HSER constraint eee Copyr
25. 0 by HUM Working Group 2 1 1 4 Defining Logical Interfaces with ADT support The use and definition of HADT object allows to define an object as the interface between two others which exchange complex data SYSTEM_1 SYSTEM 2 E l a Figure 46 Objects exchanging a complex data Image The addition of this object can be made without any change in the object provided interface of the two others and thus is a technique of refinement of an initial HOOD model Figure 47 below shows that the object ADT_Image is the interface object associated to the exchanges of image data between SYSTEM_1 and SYSTEM_2 objects The object ADT_ Image can be defined as an implementation of an abstract data type image and as environment object for the current hierarchy dealing with SYSTEM_1 and SYSTEM_2 objects SYSTEM_1 s a ADT_Image Update_image_infos Read_image_infos SYSTEM 2 Get Image Image Infos Figure 47 interface object ADT image associated to data Image however changes have to be made in the Reguired Interfaces Copyright 1995 by HOOD User s Group page 68 page 69 HOOD USER MANUAL 1 0 HUM 1 0 O0 a JD 2115 ADT Refinement Technigues Associating additional HADT objects to formalize the exchange of data between two ob jects of initial model is thus a technigue of refinement leaving the initial model invariant from the point of view of its provi
26. 3 1 OBJECT Timers_Driver IS ENVIRONMENT ACTIVE 219 A1 3 2 OBJECT Sensors IS ACTIVE 219 A1 3 3 OBJECT Bargraphs IS PASSIVE 222 A1 3 4 OBJECT Alarm IS ACTIVE 0 0 00 ccc ene eens 225 A2 EXAMPLE OF ADA CODE IMPLEMENTATION 228 A3 HOOD4 TARGET IMPLEMENTATION AND ILLUSTRATIONS 233 A3 1 HOOD4 TO TARGET IMPLEMENTATION PRINCIPLES 233 A3 1 1 Implementing state constraints with standard Ada 234 A3 1 2 Implementing state constraints without Ada tasking 234 A3 1 3 Implementing protocol constraints in Ada 235 A3 1 3 1 Implementing protocol constraints without Ada tasking 235 A3 2 HOOD4 ADA CODE ILLUSTRATION 238 A3 2 1 HOODA State Constraint Support 238 AS Zk STACK OST Ds core heee sers sen eee ee etes eyeing sO ae ces 238 A3 2 1 2 STACK OSTM cece ecceccccc rec ccc cen cec cesses 0 0 E 0 S 239 A3 2 1 3 STACK with state constraints in Ada 239 A3 2 2 Protocol constraints SUPPORT ILLUSTRATION 242 Copyright 1995 96 by HOOD Users Group page xiv page xv HOOD USER MANUAL 1 0 HUM 1 0 7 A3 2 2 1 STACK with protocol constrained operations Client code 244 A3 2 2 2 STACK with protocol constra
27. Control Structure OPCS one by service operation which describes how a sequential process executes within an operation Example For a FILE object with read and write constraints operations the OPCS of the read operation consists in reading a file contents e the OBject Control Structure OBCS one per object which controls the activation and trig gering of constrained operations whereas non constrained operation execute directly under the client requesting process see Figure 4 O B CS interprocess ASER by IT communication F Op_1 and synchronisation Tr 4 Operation_1 HA Ex cution Mode Op_1 OPCS Op 2 Op 2 OPCS p Operation 2 Ex cution Mode e Other Reguired Internal OPCS Operations Operation 3 Op 3 OPCS Operation 4 mlj Op 4 OPCS Figure 4 HOOD Object execution model Copyright 1995 96 by HOOD Users Group page 5 page 6 HOOD USER MANUAL 1 0 by HUM Working Group De MOOR This model supports e A complete separation of reactive and transformational parts e Aneasy mapping to ADA tasking e The possibility of prototyping the dynamics e The possibility of expressing the dynamic behaviour using other formalism e The definition of execution mode at server level not at client side 1 1 3 3 The Include relationship An object called a parent or a non terminal object may itself be defined as the composition of other obje
28. DESCRIPTION Implementation of an abstract Data Type STACK and provides all operations to manipulate values of that type creation included IMPLEMENTATION CONSTRAINTS Dynamic heap memory is limited to 1 MB PROVIDED_INTERFACE TYPES T Status is BUSY IDLE UNDEFINED definition of a type T STACK the type structure is hidden is array lt gt of T ELEMENT or visible to clients OPERATIONS PUSH STACK out T_STACK Element in T_Element POP STACK in T_STACK Element out T_Element STATUS STACK in T_STACK Status out T_Status EXCEPTIONS none REQUIRED_INTERFACE OBJECT ADT_ELEMENT TYPES T Element requires type T Element provided by the HADT object ADT ELEMENT INTERNALS hidden part of the object not described here END OBJECT ADT STACK Figure 45 Structure and ODS of object ADT STACK The declaration of a STACK object in the DATA field of a client ODS would then be the fol lowing INTERNALS DATA STACK1 ADT STACK T STACK 200 creates a STACK of 200 elements STACK value will stored in the associated data structure within client s memory space Note an implementation of the above ADT_STACK object groups common execution code all type instances it is an implementation of the object oriented class concept grouping code and class instances only whereas object data instances are declared in client module memory space Copyright 1995 by HOOD User s Group page 67 page 68 HOOD USER MANUAL 1
29. He can try to imagine every context where the object could be reused find exceptional cases and try to solve them although it has nothing to do with his current system design This is a risk to spend too much time and energy on this object forgetting actual purposes all the system design being delayed for non tangible future advantages Furthermore the object being created has good chances to become a kind of monster willing to do everything but doing nothing correctly Advice 3 Use Simple Abstract Objects for higher level objects and active objects Comments This is detailed in advice 27 The next section exemplified the fact that high level objects fit often better with Simple Abstract Objects Advice4 Prefer Abstract Data Types for passive terminal objects Comments This is detailed in advice 26 Advice 5 Take care of the direction of the USE relationship between objects Copyright 1995 96 by HOOD Users Group page 121 page 122 j HOOD USER MANUAL 1 0 by HUM Working Group a De Comments There is often a design choice consisting in deciding when two objects need to communicate which one will be the client and which one will be the server It may be a difficult choice and this decision has to be taken carefully see advice 20 and advice 21 Advice 6 Do not use more than three or four levels of INCLUDE relationships in the archi tectural design Comments In general two till three levels is enough for the architectur
30. However HOOD refinement properties provide support for a development approach that goes across the different design phases and helps support consistency of a design solution from the initial approved solution down to the implementation one and that is still specific and adapted to particular target systems These issues may be more refined in dedicated sections of this document see Section 2 1 2 or Section 2 1 3 but what the reader should already point out now is that e HOOD is not a requirement analysis method e HOOD handles design requirement analysis activities in transitioning from requirements analysis to design see Section 1 3 below e HOOD is an architectural design method helping a designer to partition the software into modules or objects of well defined interfaces that can either be directly implemented or fur ther partitioned with HOOD into modules of lower complexity e HOOD concepts looking for integration of design with the other development activities Es pecially HOOD object properties having been defined in order to ease interface mastering testing and integration in the context of parallel multi people team developments 1 1 3 BASIC CONCEPTS HOOD is a method based on e a formalism the graphical notation allows to express an abstraction of a solution in a clear high level and easy to understand notation the textual notation allows formal expression and refinement of the object s characteris tics
31. On board Software for SILEX Space Communication System P NANDE Matra Marconi Space Proceedings of the Ada Eurospace Confer ence Vienna November 1992 HOOD amp ADA Quality Engineering in french Aerospace Industry M PA PAIX M HEITZ CNES Proceedings of the Ada Eurospace Conference Vien na November 1992 EUROSPACE 16bis avenue Bosquet 75007 PARIS Customizable MODULAR SOFTWARE J POUDRET P GUEDOU T GOHON SEXTANT Proceedings of the Ada Eurospace Conference Vienna November 1992 HIERARCHICAL OBJECT ORIENTED DESIGN PJ ROBINSON Prentice Copyright 1995 96 by HOOD Users Group page 209 page 210 j HOOD USER MANUAL 1 0 by HUM Working Group a De HALL RUN92 A control system forthe X SAR Precision Processor H Runge P Secchi DLR A Paganone Intecs Sistemi Proceedings of the Ada Eurospace Conference Vi enna November 1992 6 2 5 ARTICLES AND PAPERS PUBLISHED IN 1991 And 91 Relations entre l environnement HOOD et les autres composants de l atelier CONCERTO P Andrieux E Andr Conf rence LIANA 1991 Pratique et out ils logiciels d aide a la conception de syst mes d information Nantes Ander9 1 Object Oriented and Ada lifecycle reuse J Anderson 28me conf rence EU ROSPACE Ada in Aerospace Rome Novembre 1991 Bar 91 El ments de la m thode HOOD Pour une composition ascendante d objets M Bari C Rolland Conf rence LIANA 1991 Pratique et outils logiciels d aide a la conception d
32. STACK Internals Copyright 1995 96 by HOOD Users Group page 13 page 14 HOOD USER MANUAL 1 0 by HUM Working Group OPERATION POP is OPCS of POP DESCRIPTION Remove an Element from the data structure T DATA USED_OPERATIONS None PROPAGATED EXCEPTIONS X STACK UNDEFINED PSEUDO CODE if the STACK is not EMPTY then put STACK in BUSY state remove Element from STACK DATA put STACK in IDLE state else put STACK in UNDEFINED state end if CODE OPCS body is begin if STACK TOP gt 0 then STATUS busy STACK code is BUSY Element STACK_DATA STACK TOP STACK TOP STACK TOP 1 STATUS idle STACK code is IDLE else STATUS undefined STACK code UNDEFINED raise X EMPTY impossible case end if END of opcs POP OPERATION PUSH is OPCS of operation PUSH DESCRIPTION Put an element onto STACK USED_OPERATIONS None PROPAGATED_EXCEPTIONS X_STACK_UNDEFINED PSEUDO_CODE if the STACK is not FULL then put STACK in BUSY state PUT Element in STACK put STACK in IDLE state else put STACK in UNDFINED state end if CODE OPCS body begin if STACK TOP lt STACK SIZE_STACK then STATUS busy class code in BUSY state STACK TOP STACK TOP 1 STACK _DATA STACK TOP Element STATUS idle class code in IDLE state else STATUS undefined class code in UNDEFINED state raise X FULL impossible case end if END of opcs POP END_OBJECT STACK Figure 13 ODS for STACKs Internals contin
33. STACK TOP 1 STATUS idle STACK code is IDLE else STATUS undefined STACK code UNDEFINED raise X_EMPTY impossible case end if END of opcs POP OPERATION PUSH is OPCS of operation PUSH DESCRIPTION Put an l ment onto STACK USED OPERATIONS None PROPAGATED EXCEPTIONS X STACK UNDEFINED PSEUDO CODE none CODE t Ada begin if STACK TOP lt STACK SIZE then STATUS busy class code in BUSY state STACK TOP STACK TOP 1 STACK_DATA STACK TOP Element STATUS idle class code in IDLE state else STATUS undefined class code in UNDEFINEDstate raise X_FULL impossible case end if END de OPCS de PUSH END_OBJECT STACKS Figure 137 ODS of passive STACK S Copyright 1995 96 by HOOD Users Group page 165 page 166 HOOD USER MANUAL 1 0 by HUM Working Group OU In the above ODS the type T_STACK is provided as a private type whose full declaration is only given in the INTERNALS The associated package can be the following 2 13 1 4 Ada code generation for passive object STACKS 2 13 1 4 a Ada Specification Unit REQUIRED OBJECTS with ADT ELEMENT visibility on type T Element with PROJECT ENV visibility on type T Status package STACKs is procedure Status STACK in T STACK return T Status procedure PUSH STACK out T STACK Element in T Element procedure POP STACK in T STACK Element out T Element X FULL exception raised by PUSH X EMPTY exception raised
34. Start On IT from Start push button Stop On IT from Stop push button Acknowledge On IT from Ack push button implemented by ALAR Bargraphs Display value oil water fuel IN Set colour colour red green IN Flash Switch off Sensors Sample value oil water fuel OUT every 1 10 second Tim Acquire value oil water fuel OUT Stop sensor_failure exception Switch_on Stop Acknowledge On IT from Ack push button implements EMS Reset Ctrl EMS Monitor every second by Timer signal Is value out of range internal operation value IN limited oil value CONST limited water value CONST limited fuel value CONST This section is given for illustration only Its added value is a matter of discussion and taste and depends highly of the toolset being used experience and project reviewing standards Copyright 1995 96 by HOOD Users Group page 50 f page 51 HOOD USER MANUAL 1 0 HUM 1 0 7 1 5 2 5 Structuring the design Analysis of reusable objects Analysis of reused object Analysis of distribution aspects gt Building system configuration SYSTEM_CONFIGURATION ROOT OBJECTS EMS Timers_ Driver IO Driver CLASSES Sensors Bargraphs END j Uses gt Is allocated to Class space Tv mm Bargraphs Is instance of of m grap Pa Sensors System To Design EMS System Distribution space Figure 33 EMS objects and Design Views Copyrig
35. TBD CODE TBD END_OPERATION Start OPERATION Sample DESCRIPTION This operation is in charge of the Sensors sampling It gets the current values of each hardware sensor and stores them into an internal database l USED OPERATIONS Input Output Driver Get Store Value PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Sample OPERATION Acguire SENSOR in T SENSOR return POSITIVE DESCRIPTION This operation gets the ten last stored values of a sensor calculates and returns their mean In case of the corresponding hardware sensor is failed for the ten stored values this operation returns a sensor_failure exception In the other cases a momentaneous hardware sensor failure is ignored and the mean value is calculated on the correct values USED OPERATIONS Get Last Value PROPAGATED EXCEPTIONS SENSOR FAILURE HANDLED EXCEPTIONS NONE PSEUDO CODE TBD CODE Copyright 1995 96 by HOOD Users Group page 221 page 222 HOOD USER MANUAL 1 0 HUM 1 0 OO g J TBD END OPERATION Acguire OPERATION Stop DESCRIPTION This operation stops the hardware sensors and resets the sampling timer The sensors status is set to STOPPED USED OPERATIONS Timers Driver Delete Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OP
36. UNDEFINED definition of provided type to hold the status of the stack code type T_DATA is array integer lt gt of ADT_Element T_Element data structure to hold values of the type type T STACK MAX integer is type STACK implementation record DATA T DATA 1 MAX only needed space is declared TOP integer 0 SIZE integer MAX ETAT PROJECT_ENV T_STATES end record a client declares stack objects as Client Stack T STACK 150 OPERATIONS PUSH STACK in out T STACK Element in T Element POP STACK in out T STACK Element out T Element STATUS STACK in out T STACK return T Status EXCEPTIONS X FULL raised by PUSH when more then MAX elements in the STACK X EMPTY raised by POP when no elements in the STACK OBJECT CONTROL STRUCTURE visible part of OBCS DESCRIPTION PUSH and POP operations should only be activated when the state of STACK is non EMPTY for POP or n FULL for PUSH CONSTRAINED OPERATIONS PUSH is constrained by HSER HSER is additional to state constraints POP is constrained by HSER because the access must be protected in a multi client multi thread context REOUIRED INTERFACE OBJECT ADT ELEMENT TYPES T Element l STACK requires type T Element provided by object ADT ELEMENT OBJECT ADT SEM TYPES T SEM STACK requires type T SEM provided by object ADT SEM OPERATIONS P V OBJECT PROJECT_ENV TYPES T States STACK requires type T STATES provided by object PROJECT ENV stores
37. a target language The integration of object properties and supporting notations which is achieved in the ODS con cept together with the unique properties of the include relationship provide HOOD with power ful modelling and design features Copyright 1995 96 by HOOD Users Group page 140 page 141 i HOOD USER MANUAL 1 0 HUM 1 0 a J te 2 11 3 DYNAMIC BEHAVIOUR MODELLING Dynamic behaviour modelling and evaluation is an important issue for real time and critical soft ware especially when one knows that most of errors detected on such systems come for bad mas tering of dynamic behaviour The clear separation enforced by HOOD for the description of OBCS and OPCS structures makes it possible to e use suitable notation to capture possibly formally the behaviour associated to states and transitions defining the semantics of an object e use classical sequential languages to describe the semantics associated to sequential process ing within the OPCss Note however that formal notations can also be used namely algebraic specifications or mathematically based notations as illustrated using Z GIOV A89 e apply a development approach where the two lines of development are separated The separation of OBCS and OPCS parts can even be enforced down to the implementation into a target languages and systems The code generation rules defined in the HOOD Reference Man ual HRM 1 recommend to group the OBCS implementation associ
38. a virtual machine and can be seen as defining a memory partition with hardware protection on its boundaries memory trap violation or remote machines Interrupt driven tasks are also heavyweight processes be cause their scheduling is constrained by real time constraints e The granularity of heavyweight processes will be the concern of real time architects and can be supported efficiently by the concept of HOOD VNs Hence the HOOD development ap proach for RTS should follow closely the phased approach recommended for complex sys tems with logical definition and refinement phase elaborating a logical solution non partitioned as described above allocation phase where Virtual Nodes are defined as grouping of objects by allocation de fining potential memory partitions 7 The allocation process starts by defining a possible Copyright 1995 by HOOD User s Group page 88 page 89 HOOD USER MANUAL 1 0 HUM 1 0 O0 a JD target architecture of the RTS as a network of VNs either by modelling the physical architecture when processes threads are numerous and must be abstracted into less heavyweight ones according to the potential power of the target e g max 127 process schedulable but only 40 allowed in order to reduce scheduling load either as a model of a planned architecture if not yet defined or available since feasi bility studies are still in progress at that stage of the project or as a representat
39. allows to put or to get information of these devices excepted the push buttons Malfunction from a hardware device is returned as an exception of the put or get operation Pushing a push button generates an interruption A1 2 OBJECT AND OPERATION IDENTIFICATION THROUGH TEXTUAL ANALYSIS TECH NIQUES A1 2 1 IDENTIFICATION OF NOUNS On IT reception from the Start push button the EMS is started if it was not Then the sensors of the EMS are sampled every 1 10 second by a signal from the timer Every second the mean values of oil pressure fuel level and water temperature are acquired from sensors and then displayed on the appropriate bargraphs If a mean value is out of range the alarm is switched on and the corresponding bargraph is displayed in red light If there is a sensor failure the alarm is switched on and the corresponding bargraph flashes in red light In the other cases the bargraphs are displayed in green light On IT reception from the Ack push button the alarm is acknowledged if it was not On IT reception from the Stop push button the EMS is stopped if it was not the alarm the timer and the sensors are stopped and the bargraphs are switched off Copyright 1995 96 by HOOD Users Group page 217 page 218 HUM 1 0 HOOD USER MANUAL 1 0 COMMENTS EMS sensors timer mean value of oil pressure mean value of water temperature mean value of fuel level appropriate bargra
40. also be handled as guards applied to the entry or accept X State constraint and ASER constraint return without execution if State is not OK state can also be handled as guards applied to the entry OPCS_X ASER is roughly implemented in Ada or accept Y do LSER constraint save parameters end Y release client process OPCS_Y or accept W do State constraint and HSER constraint return without execution if State is not OK state can also be handled as guards applied to the entry OPCS_W end W release client process end select end loop end OBCS end O Figure 19 Code generation principles for terminal active object Copyright 1995 96 by HOOD Users Group page 18 f page 19 j HOOD USER MANUAL 1 0 HUM 1 0 a D a 1 2 THE HOOD DESIGN MODEL The HOOD method gives a framework for the project design organisation Principles of that or ganisation are developed in that section They will be the basis for the HOOD design process pre sentation 1 2 1 SYSTEM TO DESIGN Before going into the HOOD design process we first introduce the System To Design notion STD This is the System in the large sense which has to be designed from a given specifica tion It may be a part of the whole project A HOOD System To Design STD may be first seen as an object defined by its interface with its environment The environment is considered as an other part of the project not designed for the purpose of the c
41. and controls the monitor ing IMPLEMENTATION CONSTRAINTS The Ctrl EMS must perform the monitor operation in less than 1 second PROVIDED INTERFACE TYPES NONE CONSTANTS NONE OPERATION SETS NONE OPERATIONS Start The Start operation creates the monitoring timer initialises the alarm the sensors and the bargraphs which are used during the monitoring Stop The Stop operation stops the monitoring timer and switches off the alarm and the bargraphs and stops the sensors Monitor The Monitor operation acguires the values of each sensor Those values are displayed on the appropriate bargraph In case of a value is out of range this operation switches the alarm on and gives the red colour to the bargraph If there is a sensor failure the alarm is switched on and the bargraph flashes in red colour In other cases the values are displayed in green colour EXCEPTIONS NONE OBJECT CONTROL STRUCTURE DESCRIPTION The Ctrl EMS accepts start stop and monitor operations at any time A start is not significant after a start A stop or a mon itor are not significant after a stop Acknowledge EMS alarmed BASE slam EMS comes Stop Start CONSTRAINED BY ASER by IT Start push button Stop CONSTRAINED BY ASER by IT Stop push button Monitor CONSTRAINED BY ASER by IT Timer 1Hz REOUIRED INTERFACE OBJECT Sensors TYPES T SENSOR OPERATIONS Start Acguire Stop EXCEPTIONS SENSOR FAILURE OBJECT Alarm TYPES T ALARM OPERA
42. and properties by means of an Object Description Skeleton ODS This concept helps to structure the descriptions into separate fields which support appropriate control and program description notations Finally these descriptions may be fully translated into a target language Ada C C or Fortran e a process describing and refining a software model from abstract structures and concepts to wards target machine code Copyright 1995 96 by HOOD Users Group page 2 page 3 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 J 9 e rules coming from industrial experiences These notations allow to use powerful structuring concepts for describing and organising a sys tem as a set of interconnected hierarchies of objects The principles supported are threefold e the notations allow hierarchic representation supporting both global and local views of com ponents Furthermore the concept of uncle and environment object supports formal represen tation of a context of a model with full consistency checking e the graphical notation is an abstraction of a fully detailed model offering reduced but con sistent views and allowing hierarchical refinement of representations and understanding e the textual notations leave provisions for both informal and formal texts allowing the defi nition of a documentation skeleton as a framework for a step by step integration of advanced notations to capture and formally verify the characteristics of an
43. application software on WIDGET events associated to an re action at widg et these triggering are called call back in the X_WINDOW system Thus the interaction logic between an application part and the window manager can be summa rized as e initialisation of graphical interface through calls to the window manager services e management of events mostly associated to user interactions by the window manager e triggering of execution of applicative part through call back which are represented as HOOD ASER_BY_IT constrained operations INTERACTIVE_APPLICATION Aser by ItX Call Back Ne i Acti Widget3_Actions a X WINDOWS LIB Figure 83 HOOD Representation of callbacks Figure 83 above illustrates interactions between an applicative object and the X WINDOWS window manager represented as a HOOD environment object ASER by UNIX Shell Aser by lt Aba gt 2 6 3 FACTORISING INTERACTIONS WITH WINDOW MANAG ERS In order to structure and isolate the X WINDOWS interface thus rendering the architecture more portable and independent from the window manager a general interface can be defined Such an architecture brings more control and flexibility on associated developments since the application can be developed tested and pre integrated in parallel to the development of the GUI Copyright 1995 by HOOD User s Group page 109 page 110 HOOD USER MANUAL 1 0 by HUM Working Group INTERACTIVE_A
44. assessment of the system under design 2 3 3 DESIGN STEP VALIDATION Verification is primarily fulfilled by informal quality assurance techniques such as inspections walk throughs and reviews over HOOD documentation produced during a basic design step Since HOOD allows a designer to produce informal textual descriptions in natural language to gether with semi formal graphical descriptions these can be easily reviewed through walk throughs author reader cycles Experience has shown that those informal parts of design descrip tions can be successfully reviewed before the formalisation into HOOD ODS and Ada_PDL be gins ODS formalised descriptions are very difficult to review by human readers and must be verified by specialized people with the help of design checking tools Hence the verification process onto HOOD designs must be carefully planned and must be performed all along the de sign process At the end of a basic design step design evaluation and design metrics computation can be ap plied for evaluation of a design solution with respect to alternative ones see KAFURA fan in and fan out concepts applied to the object model Consistency checks can be performed with the support of tools ensuring verifiable transformations to the target language and allowing early execution and testing of the solution model corresponding to a given parent Within an Ada en vironment early verifications of interfaces is possible especially parent child
45. be activated when the state of STACK is non EMPTY for POP or non FULL for PUSH CONSTRAINED_OPERATIONS PUSH constrained by HSER POP constrained by HSER REQUIRED_INTERFACE OBJECT ADT_ELEMENT TYPES T_Element STACKS requires type T_Element provided by ADT_ELEMENT OBJECT PROJECT_ENV TYPES T Status STACK requires type T Status provided byt PROJECT ENV Figure 143 ODS Illustration of STACKS The INTERNALS part of the STACKS ODS in Figure 144 shows the declaration of internal types data and OBCS code INTERNALS hidden part of the object OBJECTS None NO CHILD OBJECTS no internal types constants or data OPERATIONS IS FULL STACK in T STACK return boolean IS EMPTYL STACK in T STACK return boolean OBCS PSEUDO CODE loop ADA translateion of the state transition diagram in Figure 141 select when not IS FULL gt accept POP or when not IS EMPTY gt accept PUSH end select end loop CODE code of OBCS task body OBCS is begin loop code OBCS Ada de STACK select choice according to current state of the Stack given as parameter when not IS EMPTY Stack In T Stack gt accept POP Stack In Out T Stack An Element out T Element do OPCS POP Stack An Element associated OPCS body end POP or when not IS FULL Stack In T Stack gt accept PUSH Stack In Out T Stack An Element in T Element do OPCS PUSH Stack An Element associated OPCS body end PUSH release caller process e
46. by HUM Working Group a De e Analysis of Functional Requirements The function to performed by the EMS are acquire the data from the sensors gt handle ACQUISITION compute the mean value compare it the limit values of pressure temperature and level gt handle LIMITS display the values in green if ok in red if not flashing it failure gt handle DISPLAY trigger the alarm gt handle the ALARM handle sensors or display faults gt handle the ERRORS e Analysis of Behavioural Requirements The EMS can be started and stopped at any time independently of the car engine The EMS can be started and stopped at any moment by pushing the associated push buttons in dependently of the car engine A start when the EMS is running shall have no impact on the EMS A stop when the EMS is stopped yet shall have no impact on the EMS An acknowledge when the alarm is switched off or the EMS stopped shall have no impact on the EMS When the Alarm is set it remains displayed until the ack push button is pushed or until the corresponding fault has disappeared The Alarm shall be set only for a new fault when the same fault has previously disap peared Alarm is restarted after a start an ack before the previous stop shall be ignored Figure 31 below summarizes the behaviour of the EMS system Acknowledge EMS nominal Sensor failure Bad value EMS alarmed includes HW alarm valid value ON or OFF to EMS sto
47. byt PROJECT ENV because a procedure may declare local data in which case a generator may not know it and may misplace the begin statement Copyright 1995 96 by HOOD Users Group page 164 page 165 HOOD USER MANUAL 1 0 HUM 1 0 D ed INTERNALS hidden part of the object OBJECTS None NO CHILD OBJECTS TYPES private and internal types type T DATA is array integer lt gt of ADT_Element T_Element data structure to hold values of the type ne type T STACK MAX integer is definition of private type T STACK record DATA T DATA 1 MAX only needed space is declared TOP integer 1 SIZE integer MAX STATUS PROJECT_ENV T_Status end record a client declares stack objects as Client Stack T STACK 150 CONSTANTS None no internal constants DATA None because this is an abstract type implementation with no data OPERATIONS None no internal operations OPERATION CONTROL STRUCTURES OPERATION Status return T Status is OPCS of POP DESCRIPTION Get status of class STACK code USED OPERATIONS None PROPAGATED EXCEPTIONS None CODE in Ada begin return STATUS END of opcs STATUS OPERATION POP is OPCS of POP DESCRIPTION Remove an Element from the data structure STACK DATA USED OPERATIONSNone PROPAGATED EXCEPTIONS X STACK UNDEFINED PSEUDO CODE none CODE Ada begin if STACK TOP gt 0 then STATUS busy STACK code is BUSY Element STACK DATA STACK TOP STACK TOP
48. communication system either simple UNIX sockets or higher level tools On the remote VN side a local server the ServerObcs tailored to each VN recognizes the messages that come from the network and performs the effective call to the operation code When the operation has executed a return message is sent back through the ServerObcs to the call ing VN and object Three solutions may be used to achieve such an implementation and leaving the original code unchanged e using a HOOD toolset that supports fully the implementation for VN e generation of additional code outside from HOOD and depending of the allocation of objects onto VNs and building of a suitable executable by doing the appropriate linking of the object code e generation of additional code from a HOOD additional representation that shows the allo cated objects in a VN design This solution will be further developed in section 2 6 1 below as today no HOOD toolset supports fully VN code generation local allocated Object remote OBJEC OPCS effective OPCS_BODY Parameters P arameters ServerStub Object Software Communication mechanism Figure 72 Principle of additional code to the logical model one in the physical model 2 5 2 1 Implementing protocol constraints for VNs Figure 73 gives the principle of code generation for VN reusing and leaving unchanged the functional code generated of the logical model with no prot
49. current activity is essential When starting during the design from a child ODS the designer has to understand information described within the parent ODS visible part Object description provided and required interfac es OBCS description Requirements are already reorganized and are at a lower more detailed level Copyright 1995 96 by HOOD Users Group page 24 page 25 HOOD USER MANUAL 1 0 HUM 1 0 Understand the problem to solve before jumping on a solution Design Oriented Analysis The goal of this phase is to integrate all facets of the problem before devising a solution Rec ommendations here are to make the designer state himself the problem and to analyse and re structure the requirements with respect to his own designers perception Statement of the Problem SOP The designer states the problem in one correct sentence giving a clear and precise definition of the problem as well as the context of the system to design He must identify objectives of the current design in terms of portability reusability etc Analysis and Structuring of the Reguirement Data The designer gathers analyses and or ganises all the information relevant to his problem clarifying all points which are not yet clear When starting from high level requirements his first task is to define the environment of the system to design provided and reguired interfaces Then he organizes the reguire ments into functional behavi
50. decomposition has been chosen it is also necessary for the architecture to be detailed efficiently to have a technique for refining the associated interfaces By refining the in terfaces according to standard communication and implementation models the designer can achieve e the definition of reusable components with well established interfaces e the definition of generic architecture e the definition of application domain specific frameworks possibly evolving towards stand ard ones The interfaces between the different subsystems or software layers associated to the develop ment activity lines can moreover be formalised as HADT objects that factor the exchanged data and provide for a common representation whatever the activity and technology context The above concepts have been synthesized after feedback and trials on numerous projects built into principles and refinement techniques for integrating multiple technology developments These principles must be applied all together within a development and list as e Modular and ADT Refinement Principles e Technology Component Architecture Principles e General Refinement Approach for Complex Systems 2 1 3 4 Modular and ADT Refinement Principles Break down rules associated to the HOOD include relationship have as principle to hold the properties of the parent object with the ones of the child objects Figure 54 illustrate this mod ular refinement technique of a given parent obje
51. definition as ordi nary with visible structure type e we also introduced two internal operations IS FULL and IS EMPTY checking the variable TOP of the T_STACK structure and used for computing the state of the object and the as sociated the guards in the accept statements of the OBCS code parts 4 HOOD3 had never distinguished between pure state constraint operations and protocol ones This ambi guity is now resolved in HOOD4 Copyright 1995 96 by HOOD Users Group page 168 2 page 169 Hoo HOOD USER MANUAL 1 0 HUM 1 0 J 9 OBJECT STACKS IS ACTIVE 1 DESCRIPTION Implementation of an abstract data type STACK with no encapsulation of data instances IMPLEMENTATION_CONSTRAINTS use of full Ada PROVIDED_INTERFACE TYPES type T_DATA is array integer lt gt of ADT_Element T_Element data structure to hold values of the type type T STACK MAX integer is definition of type T STACK record DATA T DATA 1 MAX only needed space is declared TOP integer 0 SIZE integer MAX STATUS PROJECT_ENV T_Status STATE end record a client declares stack objects as Client Stack T STACK 150 OPERATIONS Push Stack In Out T stack Element In T element Pop Stack In Out T stack Element Out T element Status STACK in out T STACK return T Status EXCEPTIONS X EMPTY raised by POP X FULL raised by PUSH OBJECT CONTROL STRUCTURE visible part of OBCS DESCRIPTION PUSH and POP operations should only
52. description of the initial model is left unchanged during the remaining refinement activity This concept of initial invariant model development is fundamental and specific to HOOD a de velopment step will thus be a step allowing to freeze prototype and validate a model refinement still consistent and equivalent to a initial one Figure 154 and Figure 155 hereafter illustrate this process with e a first level of description elaborated at a date say T1 is composed of three objects and rep resented by a design tree that s 4 objects LEVEL 1 DATE T1 D Figure 154 Example of a HOOD initial model at levell of decomposition e a second level of description more refined and detailed in Figure 155 elaborated at a date T2 T2 gt T1 is described as design tree with 9 objects LEVEL 1 DATE T1 Figure 155 Example of Refinement of initial HOOD model Copyright 1995 96 by HOOD Users Group page 190 LEVEL 2 DATE T2 n page 191 HOOD USER MANUAL 1 0 HUM 1 0 7 Putting into work such an approach for a full project leads into technical activities organized ac cording to an incremental life cycle whereas current development standards generally consider only the classical waterfall model or V life cycle Hence definition of architectural and detailed design activities became difficult with HOOD A first shot technical categorization of design activities following HOOD properti
53. effectively flow through the inter process communication mechanism which is in our case implemented us ing the primitives IPC services of the VMS OS In order to refine the definition of these com munication the next HOOD refinement should explicit the use of theses mechanisms in order to Copyright 1995 by HOOD User s Group page 91 page 92 HOOD USER MANUAL 1 0 by HUM Working Group better control these resources and adapt code generation e g if a mailbox MB was defined two objects may communicate data through HSER by MB protocol constrained operations Figure below illustrates the HOOD refinement making VMS IPC communication services and PROJECT tools explicit Figure 68 Explicating inter process communications From now on the initial objects can be refined and developed as in a classical real time develop ment All interfaces are explicitly specified by means of ADT objects 2 4 3 ADVANCED DEVELOPMENT APPROACHES The main question here is should a designer consider the software of a system to design a set of task or as a set of OS processes programs first The answer is it depends on the importance of the non functional constraints of the given projects e If heavyweight process architecture can be easily established only a few OS process estab lished already from requirements analysis then an initial architecture can be directly estab lished first e If however the requirements analysis id
54. exception events raise transmit to caller when others gt EXCEPTIONS LOG appel FSM FIRE STACK PUSH others logg event raise transmit to caller end code as entered in the CODE Section of the ODS end PUSH procedure POP STACK inT STACK Element out T_Element is begin begin additional HEADER code to the OPCS body code to hanlde state conditions FSM FIRE STACKS POP execution request for POP exception when X_UNW gt EXCEPTIONS LOG appel FSM FIRE STACK POP X UNW logg in an file exception events raise transmit to caller when others gt G_EXCEPTIONS LOG appel FSM FIRE STACK POP others raise transmit to caller end code as entered in the CODE Section of the ODS end POP procedure Status STACK in T STACK return T Status is begin return STACK STATUS end STATUS end STACKS Figure 149 Ada Body Unit for Constrained Operations without tasking LOSTM stands for Object State Machine Copyright 1995 96 by HOOD Users Group page 174 page 175 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 2 14 2 CODE GENERATION FOR PROTOCOL CONSTRAINTS Figure 151 and Figure 152 below give an example of Ada OBCS implementation code with no tasking according to the principles detailed in Appendix A3 1 3 for protocol constrained op eration support with ADT_ELEMENT visibility sur le type T Element with OSTM acc
55. from one application to another in a giv en domain thus reusable for a similar project e the identification of abstract data type implementations is also a way to achieve good logical grouping of data and related operation with strong logical cohesion thus enforcing software engineering principles and going as well towards full object oriented structure that is sys tems structured with only ADTs Furthermore we stress here again that HOOD emphasizes structuring through modules whose interfaces can be mastered subcontracted rather than on inheritance structures which expresses implementation factorising At the worst i e when two ADTs objects inherits from a third one and are allocated to different work package modules it means that allocation work should be reconsidered not the design Hence the importance of a phased approach in the development process see section 2 1 2 below where logical conceptual design solutions are produced first and physical implementation solutions including work package allocation are defined second 2 1 1 STRUCTURING BASED ON ADTS The definition of abstract data types is based on the principle of extending and building complex types from primitives ones directly supported by the target language This technique allows a designer to structure and enforce type properties on complex data handled in a solution In HOOD an implementation of an abstract data type is defined through
56. hypothesis Hence all validation activities must be performed and the documentation delivered must be a full documentation 3 4 4 2 Documentation Structure Evaluation a design goes through the reading of ODSs describing fully the architecture The or ganisation and layout of these ODSs is important and should try to ease the reading and the un derstanding of the design The set of ODSs associated to a design is generally presented as a top level hierarchy of objects If the designer has chosen to present the design tree in a vertical way branch after branch one may find the ODS of a child of the root object of the system to design at page 3000 of the document Hence we recommend to have a presentation of ODSs following an horizontal organisation level by level Furthermore it is important that in a same document submitted to a review an ODS appears only once otherwise the reader would be very confused abou which ODS to be considered as a ref erence 3 4 4 3 Starting reading a Design 3 4 4 3 a Navigation Although a HOOD documentation tends to produce auto sufficient documents for an object references to required objects lead often a reader to navigate in the different associated ODS Copyright 1995 96 by HOOD Users Group page 196 page 197 i HOOD USER MANUAL 1 0 HUM 1 0 a De hence it is always necessary to have a map of the object organisation the system configuration allows thus to define the context
57. if any explaining the synchronisation and relationships between constrained operations e describe the provided operations and Operation set what the operation does and error cas es e refine the subset of operations really required required interfaces e define parameters of provided operations and deduce provided types and exceptions e define and describe provided types and deduce potential provided constants e describe provided constants and exceptions Informal comments may be added to describe the semantic behaviour to provide useful informa tion for further implementation or to justify possibly implementation decisions Activity Outputs H4 Note The way the ODS are completed will depend of the functionalities of the toolset used In the worst case one has only a textual ODS editor and the designer has to complete the fields of an ODS skeleton text However a HOOD toolset provides facilities that help and automate the filling of the ODS fields that were already created as the graphical description was elaborated Some toolsets even gener ate automatically some fields REQUIRED INTERFACE as they analyse relevant fields of the ODS At the end of this phase the ODS of the parent object is fully and formally described ODS in ternals part is completed and child ODSs are preliminary filled ODS visible part is completed Copyright 1995 96 by HOOD Users Group page 29 page 30 P 0 0 I HOOD USER MANUAL 1 0
58. ither the implementation is polling MSG events on I O channel either this procedure is called back directly by the communication software as a MSG was received from the network Copyright 1995 by HOOD User s Group page 101 page 102 HOOD USER MANUAL 1 0 by HUM Working Group OO g JD procedure ServerObcs is ServerObcs code illustration MSG IPCMSG T_MSG begin loop ServerOBCS remove MSG remove a message from a clientOBCS if MSG CSTRNT ASER then MSG X OK return OK EXCEPTION VALUE VNCS Message_oput MSG send MSG back end if case MSG OPERATION is when start gt START call procedure START of currentobject when stop gt STOP parameters accessed through global MSG structure when PUSH gt PUSH when POP gt POP when Status gt Status when others gt EXCEPTIONS LOG MSGS String MSG OBJECT amp SERVER INCONSISTENT OPERATION NAME MSG X COMMUNICATION_ERROR ServerObcs insert MSG release client process immediately end case end loop end ServerObcs Figure 78 Illustration of ServerObcs code of an allocated object in a remote VN Copyright 1995 by HOOD User s Group page 102 oof g J page 103 HOOD USER MANUAL 1 0 HUM 1 0 2 5 2 2 Managing VNS as HOOD OBJECTS In the following we present an approach to define VN implementation according to the princi ples given above and allowing to use of the code generation defined for non Ada protocol con strain
59. itself on a timer ASER_BY_IT 10 ms ASER_BY_IT p a OPCS start OPCS compute loop make the calculation make the calculation end compute sleep 0 01 call to an OS service end loop end start Figure 62 Representations of cyclic tasks Copyright 1995 by HOOD User s Group page 89 page 90 HOOD USER MANUAL 1 0 by HUM Working Group oof JD 2 4 2 1 b Semaphores A semaphore will be represented as an environment HADT object providing the operations to create delete a semaphore and to take a resource P or release a resource V SYSTEM_TO_DESIGN Object ADT_SEM is provided_interface Type T_Sem is private Create return T_Sem Delete S T_Sem P S T_Sem V S T_Sem ADT_SEM Figure 63 Representation of semaphores 2 4 2 1 c MAIL BOXES A mail box will be represented as an environment HADT object providing the operations to cre ate delete a mail box and to take a message GET or put one PUT SYSTEM_TO_DESIGN Object ADT_SEM is provided_interface Type T_MLBX is private Create return T_MLBX Delete B T MLBX Put B T MLBX into Get S T MLBX info ADT_MLBX Figure 64 Representation of mail boxes 2 4 2 1 d SHARED DATA A shared data will be represented as an environment HADT object providing the operations to create delete a shared area and to write WRITE or read information from that area READ SYSTEM_TO_DESIGN Object ADT_SHARED is provid
60. m thode HOOD et quelques autres H HABRIAS Conf rence LIANA 1991 Pratigue et outils logiciels d aide a la conception de syst mes d information Nantes Kou 91 Implantation de HOOD 3 0 dans un outil de g nie logiciel existant A Kouri P Gendre Conf rence LIANA 1991 Pratique et outils logiciels d aide a la concep tion de syst mes d information Nantes Lai9 1 M LAI Conception Orient e Objet la m thode HOOD Editions A COL Copyright 1995 96 by HOOD Users Group page 210 page 211 j HOOD USER MANUAL 1 0 HUM 1 0 a De IN 1991 MH9 la HOOD3 1 the Adult Age BDELATTE CNES JF MULLER MATRA MAR CONI SPACE M HEITZ CISI INGENIERIE Proceedings of the Ada Eu rospace Conference Roma November 1991 MH9 1b Structuration des Classes Objets Types et Donn es dans HOOD M HEITZ CISI INGENIERIE Numero Sp cial AFCET sur les Objets juin 1991 MH9 1c Structuring Classes Objects Types and Data within HOOD M HEITZ CISI INGENIERIE Special Issue AFCET journal on objects june 1991 MH91d D veloppement d applications r parties avec ADA et HOOD M HEITZ CISI INGENIERIE Conf rence ADA FRANCE Nov 1991 Paris Mic 91 Objets et automates un essai de mise en ceuvre de Grafcet en conception HOOD M Micouin Conf rence LIANA 1991 Pratique et outils logiciels d aide a la con ception de syst mes d information Nantes Mon 91 The process of developping Ada software for large scale real time and embe
61. mu nl Aes Mein nn eme ee ee muet nt But bisa 39 Figure 28 The different models in the Z life cycle 39 Figure 29 Test environment generation ss 40 Figure 30 Phased Incremental Development Approach For Complex Systems 43 Figure 31 State Transition Diagram modelling the behaviour of the EMS system eee 46 Figure 32 EMS HOOD DIAGRAM H3 4 ae ai ana EEn e E EE aa aa 49 Figure 33 EMS objects and Design Views 51 Figure 34 Ada Specification associated to EMS ODS ss 58 Figure 35 Ada Specification associated to Ctrl EMS ODS eee eee eee eee eee nene 58 Figure 36 Ada Body associated to Ctrl EMS ODS eee eee eee eee eee eee eee eee een 58 Figure 37 Ada Specification associated to EMS ODS Continued 000 cece eeeeeeeeeeeeeeeeseeene 59 Figure 38 HOOD Diagram of a Bounded Stack ss 63 Figure 39 Textual view of a Bounded Stack defined as an ADO 000 eee eee eee eee eee eee 63 Copyright 1995 96 by HOOD Users Group page xvii page xviii i HOOD USER MANUAL 1 0 by HUM Working Group a De Figure 40 An alternative to the previous Stack ss 64 Figure 41 A bounded stack defined as an ADT ss 65 Figure 42 Graphical representation of object ADT_STACK eee eee eee een 66 Figure 43 Structure and ODS of HOOD object ADT STACK encapsulating Data Instances 66 Figure 44 Graphical representation of object ADT_STACK
62. object 1 1 3 1 HOOD Objects Within HOOD everything is an object but the term object does have the general meaning of MODULE encapsulating a number of properties However a number of modules may be charac terized more precisely In order to ease the understanding of the method one can group objects different into different categories according to three perspectives e decomposition characterizes objects according to the way they are structured e behaviour characterizes objects according to their behavioural properties e organization characterizes objects according to their role in the system development A synthetic view of this classification is provided in Figure 2 below decomposition behaviour organisation Object Figure 2 Classification of the different HOOD Objects lbe careful those views are not facets in other words each HOOD object must not be characterized by a term in each of those views and some of these types are exclusive Copyright 1995 96 by HOOD Users Group page 3 page 4 F a P 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group a J a In the following we give a more detailed description of the HOOD object concept as a summary of its description in the HRM The object is the unit of modularity and is defined by the services that it provides encapsulating a state and a set of services that it requires from other objects To require a service a client object must identify the se
63. of operation execution hence procedure I OP LSER is begin AUTOMATA Set Event Object OP wait for Object Begin OP suspends client until Begin of operation end I OP LSER Figure 115 I INTERFACE Code for LSER constraint and procedure O OP LSER is begin no Set event Begin Op gt AUTOMATA sends it back to waitfor OBJECT OP OPCS defined by a same unconstrained operation end O OP LSER Figure 116 O INTERFACE Code for LSER constraint e ASER constraint the client process must resume as soon as the requested operation has been performed hence procedure I OP ASER is begin AUTOMATA Set Event Object OP end I OP ASER Figure 117 I INTERFACE Code for HSER constraint and an associated O OP ASER procedure as for O OP LSER e TOER_LSER constraint the client process must resume on time out overrun or on begin of Copyright 1995 96 by HOOD Users Group page 144 page 145 i HOOD USER MANUAL 1 0 HUM 1 0 J 9 operation procedure I OP LSER time out in false is begin TIMER Set Time out Value sets a timer AUTOMATA Set Event LSER TOER OP loop if AUTOMATA Event TO OP then time out overrun event timed out true exit end if if AUTOMATA Event Begin OP TOER OP then timed out false exit end if end loop TIMER Reset resets timer end I OP LSER Figure 118 I INTERFACE Code for TOER LSER constraint and an associated O OP LSER procedure as for LSER without
64. of operation request and associated parameters towards a network data structure and accord ing to OP_ER template code ensuring the good behaviour with respect to protocol con straints Such a design is represented in Figure 79 below The conventions for this representation are objects allocated to the VN appear as objects of same name but where all code generated shall be SERCODE Environment object of same name which generated code is the effective code remotely called operations are highlighted by the implemented by links between VN op erations and allocated objects Such operations are eventually called by the VNCS object objects remotely called required from the VN appear as objects of same name but where all code generated shall be ERCODE Such object even tually use the VNCS objects objects requiring remote VN that appear as Environment VNS Note a VN object can exclusively be decomposed either in child VNs or in HOOD objects Copyright 1995 by HOOD User s Group page 103 page 104 HOOD USER MANUAL 1 0 by HUM Working Group I implemented_by links that are resolved by the local server Allocated OBJECTS not requiring remote operations ASER Shell essage_in Insert remove ETAZ Mes _Objet3 7 Op_Obj3 SOCKET TCP_IP dataflows remote Environment ease required Vns object required understanding as effective code of the exchanges
65. of the COLUMBUS Operating System Ker nel R CHIAVERINI S TRIVELLINI G DELLARTE S SABINA INTECS Proceedings of the Ada Eurospace Conference Vienna November 1992 An Xview application and the HOOD Ada lifecycle BDEMEUSE O LANGH ENDRIES G PAQUET SPACEBEL Proceedings of the Ada Eurospace Con ference Vienna November 1992 CASE and HOOD Ada in the development of embedded systems U DENSKAT D COATES D WEBER DORNIER Proceedings of the Ada Eurospace Confer ence Vienna November 1992 A HOOD Ada Application for an Object Oriented Simulation Library for On board Space System Payload Simulation M GAJETTI W RAVETTO Alenia Spazio Proceedings of the Ada Eurospace Conference Vienna November 1992 Use of the HOOD Metgod in the HERMES Onboard Software P LA CAN P COLANGELI Aerospatiale Proceedings of the Ada Eurospace Confer ence Vienna November 1992 The VICOS Software Development U MARON ERNO Proceedings of the Ada Eurospace Conference Vienna November 1992 The Use of Ada and HOOD in the Design of an Autonomous Spacecraft Data Management System L MARRADI F CICERI D MASOTTI LABEN Pro ceedings of the Ada Eurospace Conference Vienna November 1992 Specification et Conception en technologie Objet l approche HOOD M HEITZ Conf rence DECUS France Avril 1992 Towards more formal developments using HOOD M HEITZ CISI INGE NIERIE Proceedings of the International Conference on Software Engineering Toulouse dec 1992 Real Time
66. overview of the ODS is given in Figure 7 below Copyright 1995 96 by HOOD Users Group page 8 n page 9 HOOD USER MANUAL 1 0 HUM 1 0 ODS Structure Visible Part May be an active or passive object a virtual node or a class Object Declaration Informal text describing what the object does Object functional specification Implementation Describe any target implementation constraints Constraints Provided Resources provided TO other objects I nterface Types Constants Operations sets Exceptions Description Resources required FROM other objects Types Constants Operations sets Exceptions Data flows coming from required objects Exception flows coming from required objects Informal description of object behaviour list of constrained operations Internals Implementation of Private or incomplete provided Provided types and constants constants and types are defined Definition ofin ternal Those definitions are not visible types data amp operations from outside Describes implementation of the object behaviour OBCS Describes implementations for provided and internal operations OPCS Figure 7 Structure of a HOOD Object Copyright 1995 96 by HOOD Users Group page 9 page 10 HOOD USER MANUAL 1 0 by HUM Working Group OBJECT lt Object_Name gt is lt Object_Type gt PARAMETERS Only for Class instances TYPES OPERATIONS
67. page 242 HOOD USER MANUAL 1 0 HUM 1 0 oof g J rameter pushing on and back memory frames e MUTEX semaphores are needed for ensuring state integrity in a concurent context and are generated by default Optional rules shall specify under which conditions they can be sup pressed for e g if all operations are HSER or LSER in which case the SERVEROBCS warrants mutual exclusion because it is its own flow executing OPCS_OP code A3 2 2 PROTOCOL CONSTRAINTS SUPPORT ILLUSTRATION Protocol constraints implementation leads to interprocess communication pure synchronisation and or data communication between at least one client process and one server process which execute each in their own memory partition The target architecture principle applied to the STACK example with protocol constrained operations leads to the following Ada code structure For one active object the target code is structured into three packages of which code samples are given below This code structure may be directly mapped in C modules and shall be op timised when using Ada tasking or thread supported OS marshalling 10 in OPCS_ER code and unmarshalling in OPCS_SER code as well as InterProcessCommunication IPC message handling is not needed when threads or task share parameters in the same memory partition 8 Should probably be supported by ADA code generators since users are hungry for efficient code Copyright 1995 96 by HOOD Users Group page 242
68. possibly user defined and provided shall trigger a Message in operation of e of the remote ServerOBCS which shall process the MSG and dispatch it to the appropriate OPCS SER operation e of the local ServerOBCS which shall process the RTN_MSG and dispatch it by calling RT NO insert to the appropriate RTNqueue thus releasing the blocked client process procedure Message In MSG in T MSG is ServerVNCS code illustration begin loop case MSG type is when RTN_MSG gt MSG RTNQ insert MSG insert in RTNQ will release client when IPC_MSG gt just launch local OPCS_SER code MSG IPCO insert MSG insert inIPCQ will launch ServerOBCS of called Object when others gt EXCEPTIONS LOG VN ID Message IN INCONSISTENT MSG type MSG X COMMUNICATION_ERROR Message out MSG send messageback end case end loop exception when Others gt EXCEPTIONS LOG VN ID Message In Others end Message In Figure 77 Illustration of ServerVNCS Message in code 2 marshalling 1s the action of transforming remote subprogram parameters used a stream oriented repre sentation which is suitable for transmission between remote processes Unmarshalling is the reverse ac tion ADA9X languages libraries shall provide two supporting type attribute functions for a type S S write and S read In C classes to be exchanged should inherit from a virtual stream one with two IO function gt gt and lt lt 3
69. projects needs or standards or even company internal standards ESA PSS 05 DOD 2167a 3 1 1 ADD STANDARD 3 1 1 1 Introduction Before building a document standard it is necessary to think about the reader For an ADD many kinds of readers may have to review it the specifier the reviewer the designer the developer the maintainer All those people need different design information For example a specifier may be more interested by the global organisation and external interfaces even though a devel oper is interested by the complete ODS he has to develop Hence we suggest to organise the ADD in order to answer to all those people an ODS may be put in appendix of the ADD and may not be provided to all readers Nevertheless it is always possible to introduce ODS directly at the level where an object is defined i e at the end of the related section An ADD covers the whole system configuration or a part of it If the ADD is related to a system it will includes the VNTs and all HDTs and the related CDTs allocated into terminal virtual nodes If an ADD is related to an object of a HDT it will only describe the decomposition of that object and the used environment objects Finally in order to build a readable ADD a table of contents is fundamental to retrieve objects Moreover we recommend to add an index at the end of the ADD allowing to list objects types operations and constants with for each of them pages where
70. representation for the active object Stacks eee eeeeeeeeeeeeeen 164 Figure 137 ODS of passive STACK Sn eiees eat aS EE EE Eaa ese oby EEES 165 Figure 138 Ada specification Unit for passive STACKS eee eee eee en 166 Figure 139 Ada body Unit for passive STACKS ss 166 Figure 140 Graphical representation for the active object Stack eee eeeeeseseeeseeseeeneceecaeensenaes 167 Figure 141 Object behaviour for STACK issue 167 Figure 142 Ada OBCS code for stack sise 168 Figure 143 ODS Illustration of STACKS ss 169 Figure 144 Internals of ODS for active object STACKS eee eee en 170 Figure 145 Ada specification Unit for active object STACKS eee eee eee 171 Figure 146 Ada Body Unit for Active STACKS ss 171 Figure 147 Additional HEADER code to the OPCS for state constraint support with an FSM 173 Figure 148 Ada Specification Unit for State Constrained Operations without tasking 173 Figure 149 Ada Body Unit for Constrained Operations without tasking 0 0 0 ee eee eee eee 174 Figure 150 Ada Specification Unit for Constrained Operations without tasking ee 175 Figure 151 Ada body code generation with no tasking protocol constraints r 176 Figure 152 OBCS body code with no tasking protocol constraints eeeeeeeeeee 00000 een 178 Figure 153 Separate part of OBCS b
71. service Two kinds of constraints are defined e state constraints service activation constraints relying on the semantics and internal state of the object are represented through non labelled trigger arrows protocol execution constraints represented by text labels attached to a trigger arrow which define that the client requesting process execution is suspended after its request until full completion of the requested service Highly Synchronous Execution Request or HSER protocol Copyright 1995 96 by HOOD Users Group page 4 f page 5 i HOOD USER MANUAL 1 0 HUM 1 0 a J te until completion of the request processing by a server process Loosely Synchronous Ex ecution Request or LSER protocol until runoff of a time delay or until full completion of the requested service TOER_HSER protocol until runoff of a time delay or until completion of the request processing by a server pro cess TOER_LSER protocol or not suspended ASynchronous Execution Request or ASER protocol This kind of ex ecution request corresponds to classical message passing communication 1 1 3 2 Control Structures HOOD allows the precise description of the dynamical behaviour attached to the execution of services with or without attached execution constraints through processes which are ultimately implemented on target machine processors The behaviour of processes is captured through two orthogonal concepts e the OPeration
72. signatures checks can be performed and the mappings of requirement behavioural models into object control struc ture descriptions can be traced 10 otherwise it is sure that reader will not have enough time to integrate the information and hence will not do an efficient job 11 Author reader cycles on H2 may help a designer but are globally less efficient because reader are involved in the elaboration process However the H2 section may be checked by all design team leaders of a distributed team project for the first top level decomposition for instance people which will have to elaborate tests plans 13 When a design is expressed textually in a clear readable form by the designer it often means a well mastered solution cryptic non understandable texts shows complicated non mastered solution in the mind of the designer Copyright 1995 by HOOD User s Group page 86 page 87 HOOD USER MANUAL 1 0 HUM 1 0 oof g J 2 3 4 DESIGN PROTOTYPING Design prototyping can be performed at the end of a basic design step by producing executable models of children on behalf of their OBCS descriptions By comparing the behaviour of the parent upper level prototype with the resulting one of current design step and when applying the same test cases one can validate the current parent child decomposition 2 3 5 LEVEL VALIDATION When all validation step of a given level have been performed level validation may be per form
73. sive development of objects by modelling and their decomposition into software objects and ab stract data types Although some HOOD users already push for new improvements such as refinement of links between objects as new HOOD objects or integration of inheritance the HOOD 3 1 will be sta ble until the industrial spreading of Ada 9X and the publication of a standard for C 9 In the meantime HOOD extensions prototyping and experimentation rely on the SIF The main extension work conducted so far is aiming at e defining methodological approaches for integrating different notations and methods espe cially Object Oriented Languages such as C and Ada9X A HOOD4 proposal was widely under discussion and adopted by the HUG e extending HOOD application towards system design where more formal representation of in terfaces and behaviour for simulation and evaluation are strong requirements The HOOD development approach allows to combine both a design representation target to wards flat type structure and object oriented class structure Whereas several methods for identi fication of classes are based on analysis techniques that were mainly derived from the Entity Relationship model extended with inheritance the HOOD design approach leads naturally to the identification of class structures from the definition of logical interfaces and applicative abstract data types The resulting structure reflects the top down design trade off partiti
74. skeletons to implement associated visibility relationships from HOOD required interface descriptions e ODS code fields inserted in the associated code skeletons Another principle is the one of preserving the identifiers used in the HOOD ODS descriptions within the target code This may raise some difficulties especially when the target is not Ada In order to limit these difficulties it is recommended to follow project defined coding standards in documenting target dependent fields 2 12 2 HOOD TO ADA CODE GENERATION Since HOOD was initially developed for Ada targets doing Ada within HOOD should not be too troublesome Difficulties however have been experienced e the implementation of provided TYPES of a parent object since there is no means for renam ing Ada types The HOOD Ada HADA study recommends to use as far as possible a trans lation scheme through derived types or subtyping with automatic generation of lost declarations when the former scheme is not possible e the standard schemes for active object support uses heavily tasking what is often felt as non efficient or even not possible when dynamic behaviour is to be supported by non Ada or RT OS The general principle is then to have a clear separation between the sequential code of the OPCS and all additional code needed to implement state and protocol constraints This has major impacts on the way a system can be developed and tested since sequential devel opment
75. start procedure SerDispatcher Name T_Operation is Local STACK T STACK local Data for client server code Local_Element ADT_ELMENT T_ELEMENT begin case Name is when PUSH gt begin PUSH exception when gt MSG X VALUE X eee Copyright 1995 96 by HOOD Users Group page 245 page 246 HOOD USER MANUAL 1 0 HUM 1 0 ool g J when X_UNW gt MSG X_VALUE X_UNW when others gt EXCEPTIONS LOG SerDispatcher OPCS_PUSH Others MSG X VALUE X OTHERS end when POP gt begin POP exception when X UNW gt MSG X VALUE X UNW when others gt EXCEPTIONS LOG SerDispatcher OPCS_POP Others MSG X VALUE X OTHERS end when others gt EXCEPTIONS LOG OBCS OPCS NAME NO SUCH NAME end case exception when others gt EXCEPTIONS LOG OBCS OPCS NAME Others raise end SerDispatcher procedure STACKSERVER is object IPC message server MSG IPCMSG T_MSG local MSG data begin OBCS INIT_POOL init of QUEUE pool loop QUEUES Remove R_Q MSG get a request from R_Q Queue case MSG CSTRNT is process the MSG when HSERI HSER_TOER gt SerDispatcher MSG OPERATION execution du code concern QUEUES Insert MSG RTN_Q MSG renvoi MSG au client when LSER ILSER_TOER gt QUEUES Insert MSG RTN_Q MSG renvoi MSG au client SerDispatcher MSG OPERATION execution du code concern when ASER gt SerDispatcher MSG OPERATION execution du code concern when others gt EXCEPT
76. sys tem It is then possible to reason about instrument prototype about the constraints Thus de sign decisions can be justified and the testing process can be made more efficient e it provides a logical model possibly defining a generic architecture that can be reused on similar applications Copyright 1995 96 by HOOD Users Group page 33 f page 34 I HOOD USER MANUAL 1 0 by HUM Working Group a J a The HOOD development approach producing first logical models reflecting pertinent abstrac tions of a solution domain in target independent way is at our knowledge the only one leading to solutions that take into account the following set of constraints e independence with respect to target hardware configuration a requirement which is more an more expressed on large projects e portability for several targets also a growing demand on large projects where identical soft ware pieces are running on different targets and sites e reusability on frozen parts of a given application domain reuse of high level architecture and or parts of the designs e maintainability which is most improved when the design is easily understandable This process allows to define the system configuration and associated elements Associated ac tivities may be further grouped into phases according to the technical area of concern e phase 1 Logical architecture By logical one should understand non physical that means that a HOO
77. target host system e rendez vous e RPC e semaphores e mailboxes and queues e signals e shared areas How can a designer used to express inter process communications with these mechanisms ex press them in HOOD In fact there are two possibilities e expressing a HOOD design that directly reflects the implementation e In this case the used mechanisms should be represented as HADT objects e expressing logical communication at HOOD level knowing that code generation of HSER LSER may achieve the same effect as for example two object communicating through a third one modelling a QUEUE allocating objects on VN that define inter VN communications whose communication mechanisms will be expressed with target communication mechanisms Depending on the target system chosen either Ada tasking supported or not and according to the code generation principles one can state the following rules l such constraints are not in current HOOD definition but are a proposal that came out from the Hard Real Time study funded by ESA Copyright 1995 by HOOD User s Group page 95 page 96 HOOD USER MANUAL 1 0 by HUM Working Group oof g J 2 4 4 1 Use of Ada tasking e state constraint applied to an operation gt one task to ensure state constraints protocol constraint applied on a operation gt 2 process at least implied a client task performs a calls to the OBCS entry via the call to the OBJECT Operation an OB
78. the HOOD TECHNICAL GROUP Maurice provided several contributions to Ada Europe and software engineering conferences about HOOD and its application to distrib uted fault tolerant systems reuse and integration with formal methods Jean Francois Muller is an engineer in automatics and electronics and is responsible for the def inition of software engineering tools at MATRA MARCONI SPACE 1 rue des Cosmonautes 31400 TOULOUSE Phone 33 61 39 68 12 Fax 33 62 24 77 80 e mail muller so leil matra espace fr Since 1982 Jean Francois was responsible for the development of the HIPPARCOS on board software OS and later for the COLUMBUS Software Development En vironment Jean Francois was then project leader for the EUREKA ESF FERESA and the space FIP subprojects dealing with distributed software developments Jean Francois was one of the codesigners of HOOD and he is now an active member of the HOOD TECHNICAL GROUP Christophe Pinaud is a software engineer and is responsible for the definition and use of the software engineering methods at MATRA MARCONI SPACE 1 rue des Cosmonautes 31400 TOULOUSE Phone 33 61 39 65 40 Fax 33 62 24 77 80 e mail pinaud christo phe mms matra espace fr Since 1987 Christophe has worked on software engineering tools and methods evaluation and application and on Man Machine Interface development methods and tools He then participated to the Hermes Software Development Environment definition and development and h
79. the timer in Hz IT ADDRESS in ADDRESS reception address of the sent IT The Create operation allows to create a new timer which can send IT at the address of reception and at the specified frequency The timer is not started The created timer is returned Start TIMER in T TIMER timer to be started The Start operation allows to start the given timer l Stop TIMER in T_TIMER timer to be stopped The Stop operation allows to stop the given timer Delete TIMER in T_TIMER timer to be deleted The Delete operation allows to suppress the given timer of the list of available timers This operation stops the timer if it is running before to delete it EXCEPTIONS NONE OBJECT_CONTROL_STRUCTURE DESCRIPTION Start Stop and Delete operations may arrive at any moment as soon as the timer exists A Start operation is of no effect if the timer is still running or is not created A Stop operation is of no effect if the timer is still stopped or is not created A Delete operation is of no effect if the timer is not created CONSTRAINED_OPERATIONS Start CONSTRAINED_BY ASER Stop CONSTRAINED_BY ASER Delete CONSTRAINED_BY ASER END_OBJECT Timers_Driver A1 3 2 OBJECT SENSORS IS ACTIVE DESCRIPTION This object samples oil pressure water temperature and fuel level at 10Hz and stores the read values of the three sensors at any moment It may provide the mean of stored values of a sensor It also prov
80. to the definition of the data model supported by the DBMS either dataflows are build from abstract data types and define formally the interface be tween APPLICATION and or MMI and the DBMS INFORMATION _SYSTEM APPLICATION Operator_Ops Applis_data Start Put_Ops ta Mngt_Ops DBMS Items Start Put_Ops Get_Ops Start Sgbd iteihs Mngt_Ops Put Ops Get Ops Mngt Ops Applis dat Knowledge Iteihs Sgl data herSystem Knowledge data DBMS Items Applis data Figure 107 HOOD Architectural Model of a complex information system Copyright 1995 96 by HOOD Users Group page 139 page 140 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group F J 9 2 11 2 CONCEPTUAL AND BEHAVIOURS MODELLING The features and properties of HOOD3 1 designs allow the implementation of a phased develop ment approach relying on the following principles e definition of an initial solution model by abstracting away from implementation with well separated descriptions associated to the different characteristics of the model the structural properties are described in terms of HOOD objects and relationships within the scope of a system configuration the functional properties describing what a HOOD software does in terms of sequential executions are described in OPCSs the dynamical properties describing the significant state transitions of a system within OBCS of objects e Consistent refinement leaving in
81. type structure is hidden to clients OPERATIONS CREATE STACK out T_STACK Size in integer constructor PUSH STACK out T_STACK Element in T_Element POP STACK in T_STACK Element out T_Element STATUS STACK in T_STACK Status out T_Status DELETE STACK in T_STACK destructor EXCEPTIONS X_OUT_OF_MEMORY raised by create when memory limits REQUIRED_INTERFACE OBJECT ADT_ELEMENT TYPES T_Element ADT_STACK requires type T_Element provided by the HADT object ADT_ELEMENT INTERNALS hidden part of the object not described here END_OBJECT ADT_STACK Figure 43 Structure and ODS of HOOD object ADT_STACK encapsulating Data Instances The declaration of a STACK object in the DATA field of a client ODS would then be the follow ing INTERNALS DATA STACK1 ADT_STACK T_STACK creates a STACK Identifier initialisation is done by calling ADT STACK CREATE STACKI all values of STACKI will be located within the ADT STACK memory space Copyright 1995 by HOOD User s Group page 66 page 67 HOOD USER MANUAL 1 0 HUM 1 0 Note the implementation of HADT STACK groups both execution code and STACK values Holo 2 1 1 3 b HADT Object encapsulating no DATA INSTANCES ADT_STACK PUSH POP STATUS Figure 44 Graphical representation of object ADT_STACK The description skeleton of a HOOD object implementing the abstract data type stack could be the following OBJECT ADT_STACK IS PASSIVE
82. using the special Observation Report OR form given on the following page to HOOD TECHNICAL GROUP at the following ad dress Attn HTG Chairman Maurice HEITZ CISI 13 rue Villet 31400 TOULOUSE FRANCE fax 33 61 17 66 96 Copyright 1995 96 by HOOD Users Group page v P 00 I HOOD USER MANUAL 1 0 D a page vi by HUM Working Group Observation report FORM OBSERVATION REPORT OR From Document under review HOOD USER MANUAL Para Page Subject Discrepancy Recommendation Copyright 1995 96 by HOOD Users Group page vi page vii i HOOD USER MANUAL 1 0 HUM 1 0 a De ACKNOWLEDGMENTS The assistance provided for meetings of the HOOD TECHNICAL GROUP by CISI CRI AS ESA ESTEC INTECS LOGICA MATRA MARCONI SPACE and SEMA GROUP is grate fully acknowledged without their support this work could not have been undertaken We are also grateful for the support of the employers of the HOOD TECHNICAL GROUP members and other organisations that provided valuable feedbacks for the HOOD definition Particular thanks are due to MATRA MARCONI SPACE CISI and CNES whose support made possible the production of this book A number of ideas and advices have been borrowed from studies funded by the ESPRIT or EUREKA programmes and projects We gratefully acknowl edge the work done in the TOOL USE COMPLEMENT ESF and PROTEUS projects Other significant inputs were taken from HOOD training c
83. values to zero through the I O driver Stopping the alarm stops the hardware alarm through the I O driver Stopping the sen sors stops the hardware sensors through the I O driver and stops the sampling timer 2 Note that this strategy is the ultimate one found after refinement of earlier outlines as the candidate child objects and associated operations were described and refined in Formalization of the Strategy activities Copyright 1995 96 by HOOD Users Group page 47 page 48 j HOOD USER MANUAL 1 0 by HUM Working Group a De 1 5 2 4 Formalization of the Strategy H3 1 5 2 4 a Identification of objects H3 1 Object BARGRAPHS The bargraphs object allow to display values in red or green with or without flashing on appro priate display devices It also provides all means to start and stop the hardware display device Object CTRL_EMS This object is the controller of the EMS It starts and stops all the constituents objects of the EMS and controls the monitoring The Ctrl_EMS inits the bargraphs starts the alarm and the sensors and creates and starts a timer which triggers the monitoring each second monitoring timer Object SENSORS This object samples oil pressure water temperature and fuel level at 10Hz and stores the read values of the three sensors at any moment It may provide the mean of stored values of a sensor It also provides all means to start and stop the hardware sensors Object ALARM The Ala
84. worked out and Adapted to the specific application domain As an example the MMI Man Machine Interfaces are developed more and more using an UIMS User Interface Management System and the data management systems with the help of appli cation generators or 4th generation tools Hence a development of such a system is rather a set of more or less parallel lines of technology independent activities These latter must be scheduled synchronised and interface mastered to support the associated management activities in a life cycle framework The interfaces between the different subsystems or sometimes software layers associated to the activity lines can be formalised as abstract data types that factor the exchanged data and provide for a common representation whatever the activity context The use of HOOD as the common representation formalism for the different lines jumps in naturally and brings several benefits e external representation defining formally the interfaces of a component standardised through HADT concepts e use for the internals of the component of the best suited formalism according to the tech nology supported by each activity line whereas the relationship towards the other external technologies are always captured by HADT descriptions e definition of transformation rules from the common representation formalism towards an im plementation formalism allowing final code merging for example ADT towards Object pro g
85. 0 below In this case the development is conducted as usually down to the identification of terminal objects The associated OBCSs are expressed in the chosen notation and the associated code contains as many automata as terminal OBCSs The final tuning must be done automata by autom ata during integration activities one unique synchronous automata defined as the code composition of all the elemen tary ones This is obtained by merging all states and events of elementary automata into one new set thus reducing the minimal number of processes from N 3 to 3 The new au tomaton is not the product of the others but only the union allowing better mastering and tuning of the units I INTERFACE O INTERFACE and AUTOMATA a centralized Copyright 1995 96 by HOOD Users Group page 146 T page 147 HOOD USER MANUAL 1 0 HUM 1 0 a De strategy particularly suited to embedded cyclic systems one unique synchronous automata defined as the formal composition of all the others This can only be done with very specific notations and under given hypothesis For e g ES TEREL is able to compute a compositional automata from several others however one must check that the synchronism hypothesis is still valid Also there is a lot of trouble to expect due to combinatory explosions of states when doing the cartesian product of the el ementary automata MCTL Modular Control and Temporal Logic HEI91 is a promising technique but with poor to
86. 1 5 3 3 TERMINAL CHILD OBJECT CTRL EMS 54 1 5 4 Example of Ada code implementation 58 2 ADVANCED CONCEPTS 61 2 1 ARCHITECTURAL GUIDELINES 61 2 1 1 STRUCTURING BASED ON ADTS 62 2 1 1 1 Object Abstraction ss ses 62 2 1 1 2 Abstract Data Type Abstraction 64 2 1 1 3 ADT implementations as HADT objects 65 2 1 1 4 Defining Logical Interfaces with ADT support 68 2 1 1 5 ADT Refinement Techniques 69 2 1 1 6 Deriving HADT objects from DataFlows 69 2 1 2 THE HOOD DESIGN PROCESS AS SEVEN DESIGN RULES 71 2 1 3 OTHER GUIDELINES FOR IDENTIFYING OBJECTS 73 2 1 3 1 Structuring based on layered models 73 2 1 3 2 Structuring based on Technological Components 73 2 1 3 3 Structuring and Refinement cece cece eee ss 75 2 1 3 4 Modular and ADT Refinement Principles 75 2 2 THE HOOD DESIGN DOCUMENTATION 80 2 21 Objectiv sr zs SS eh ed ol eG Pe ge ne Re Zein 80 22 2 Documentation Concepts 80 2 2 3 Documentation Management
87. 1 HOOD4 TO TARGET IMPLEMENTATION PRINCIPLES By convention there is one OBCS per active object which shall handle all dynamivc process task ineteractions associated to the dynamic i e the way the operations are executed behaviour of the object In case of resource shortage its is always possible to group several OBCS into one HOOD standard generation rules HRM define the OBCS as an Ada package nested or not in the package associated to the current object possibly reduced to one OBCS task unit and the OPCS header code as rename of an OBCS entry hiding the OBCS to clients whereas the OPCS body code is defined in a procedure called OPCS_ lt OP_NAME This solution the standard code generation schema in HOOD3 is however not always matching the needs of real time programming for example one may want to execute an operation in mu tual exclusion A solution for such problems has been proposed to the HTG and may be included in the next evolution of HOOD named HOOD4 This solution is briefly outlined below In order to solve the problems associated to non supported execution request and protocols and based on several attempts to conceptualize and formalize the behavior of process upon con strained operations a general solution has been achieved which splits the code associated to an OPCS into several LOGICAL PARTS which redefine the OBCS code Code generation rules are then easily derived by defining the source code which may be empty assoc
88. 5 477 498 HEI91 A G Heibig Control Machines a new model of parallelism for compositional specifications and their effective compilation Theoretical Computer Science El sevier 1991 43 80 HRM91 HOOD Reference Manual issue 3 1 HOOD User Group edited by MASSON and PRENTICE HALL available December1992 HUG91 HOOD USER GROUP HUG C O SPACEBEL INFORMATIQUE Chauss e de la Hulpe B 1140 BRUSSELS BELGIUM Tel 32 2 730 46 50 fax 32 2 726 85 13 HRT ESA ESTEC Hard Real Time Operating System Kernal Study Task1 Over view and Selection of Hard real Time Scheduling Model ESTEC conttract n9198 90 NL SF also on the HOOD WEB site LECMP89 V Lecompte Verification Automatigue de Programmes Esterel Th se de doc torat de Universit de Paris 7 Juin 1989 MHIS90 M Heitz I Sneed HOOD Esterel A Methodology for Formal Design and De velopment of Real Time Systems Proceedings of EuroSpace Conference Barce lona december 1990 Mic 91 M Micouin Objets et automates un essai de mise en ceuvre de Grafcet en con ception HOOD Conf rence LIANA 1991 Pratique et outils logiciels d aide la conception de syst mes d information Nantes Mull89 S Mullender Distributed Systems ACM PRESS ADDISON WESLEY 1991 MEYER90 Meyer B 1990 Object Oriented Software Construction in ISBN 0 8053 0091 Benjamin Cummings OMG91 OMG 1991 The Common Object request Broker Architec
89. 6 1 General Implementation Rules 15 1 1 6 2 Implementation of Constrained Operations 17 1 2 THE HOOD DESIGN MODEL 19 1 2 1 System to Designs es soupe eho Se es WEE de ok Le Gee bar dy a 19 1 2 2 System Configuration 338638 see eae eh Cl OE MON SAE ABLE Be eT 20 13 THE HOOD DESIGN PROCESS 22 1 3 1 The Basic HOOD DESIGN PROCESS 22 1 3 1 1 The Basic Design Step 23 1 3 1 2 The Basic design step applied to a root Object 31 1 3 1 3 The Basic design step applied to terminal object 31 1 3 1 4 The Basic design step applied to the other types of object 32 1 3 2 The Overall HOOD DESIGN PROCESS 32 1 3 3 PHASE 1 Logical Architecture 36 1 3 4 PHASE 2 Infrastructure Architecture 36 1 3 5 PHASE 33 Distribution 34 25 dace kok en Bosne dl hee ar ee Pha ee 37 1 3 6 PHASE 4 Physical Architecture 37 14 INTEGRATING HOOD IN THE LIFE CYCLE ACTIVITIES 38 1 4 1 OVERVIEW gt pos n a T an RS Lo ens Sete Mee AE Sates Date eee qu 38 1 4 2 Specification to design issus sites hgh bea dss Eee Eda ee lado dl k 38 1 4 3 Design to code y Liste See ea e
90. 6 by HOOD Users Group page 238 page 239 HOOD USER MANUAL 1 0 HUM 1 0 OO g J A3 2 1 2 STACK OSTM Figure 165 illustrates the OSTM Object State Machine an implementation of the STACK OSTD which could be generated automatically from the OSTD by a HOOD toolset Such code is standardised using the HRTS FSM module Finite State Machine where transitions are only triggered by operation execution requests associated to an object or class instance This FSM is initialised either at initialisation or when procedure FIRE for that object FSM is called for the first time with HRTS use HRTS visibility to FSMs handling module of HRTS procedure OSTM is OSTM for stack HRTS FSMs CREATE STACK 4 3 EMPTY 4 possible ER and 3 states initial state is EMPTY HRTS FSMs TRANS STACK EMPTY Start EMPTY HRTS FSMs TRANS STACK EMPTY Push NON_E_F HRTS FSMs TRANS STACK EMPTY Stop EXIT HRTS FSMs TRANS STACK NON_E_F Start EMPTY HRTS FSMs TRANS STACK NON_E_F Push NON_E_F HRTS FSMs TRANS STACK NON_E_F Pop NON_E_F HRTS FSMs TRANS STACK NON E F Pop EMPTY if stack top 1 HRTS FSMs TRANS STACK NON_E_F Stop EXIT HRTS FSMs TRANS STACK NON_E_F Push FULL if stack top max 1 HRTS FSMs TRANS STACK FULL Pop NON_E_F HRTS FSMs TRANS STACK FULL Start EMPTY HRTS FSMs TRANS STACK FULL Stop EXIT end Figure 165 OSTD Implementation Example A3 2 1 3 STACK with state constraints in Ada For conciseness w
91. A set of PRAGMA Ss is defined to give the designer a better control of the translation scheme This allows a development process in which the detailed design is a stepwise refinement of the archi tectural design then the code editing is the refinement of the detailed design So the designer and the coder see only the HOOD structure and the ODSs the final translation into Ada being done just at the end of the code phase or for design prototyping purposes With a such approach code and design are always consistent 1 4 4 TESTS AND VALIDATION 1 4 4 1 Unit and integration tests The unit and integration tests of parts of code developed using HOOD are done respectively against the detailed design and the architectural design The HOOD object concept has obvious benefits for testing e from the definition of object interfaces provided required it is possible to set up a test en vironment e information hiding inherent to objects insures to have limited interaction with the test envi ronment A typical HOOD object test environment Figure 29 will be composed of e atest monitor in charge to trigger accessible operations defined in the provided interface e atest simulator in charge to simulate the operations defined in the required interface 5 o 2 m Objects to be Tested Provided interfaces Reguired interfaces Simulator Test Simulator B Co Figure 29 Test environmen
92. CRIPTION Put an l ment onto STACK USED OPERATIONS None PROPAGATED EXCEPTIONS X STACK UNDEFINED PSEUDO CODE none see the code CODE Ada begin if TOP lt STACK SIZE then STATUS busy class code in BUSY state TOP TOP 1 STACK DATA TOP Element STATUS idle class code in IDLE state else STATUS undefined class code in UNDEFINEDstate raise X FULL impossible case end if END de OPCS de PUSH END OBJECT STACKS Figure 133 ODS of passive STACK object Copyright 1995 96 by HOOD Users Group page 162 page 163 HOOD USER MANUAL 1 0 HUM 1 0 pea 2 13 1 2 Ada code generation for passive STACK object 2 13 1 2 a Ada Specification Unit REQUIRED OBJECTS with ADT ELEMENT visibility on type T Element package STACK is procedure Status return T Status procedure PUSH Element in T Element procedure POP Element out T Element X FULL exception raised by PUSH X EMPTY exception raised by POP end STACK Figure 134 Ada specification Unit for passive object STACK We can note that the provided operations are translated into procedure or function specification keeping the parameters and the return type unchanged and provided exception declarations are translated in exception declarations 2 13 1 2 b Ada Body Unit with TEXT_IO USED OBJECTS package body STACKS is internal Types type T_Status is BUSY IDLE UNDEFINED type T_DATA is array integer lt gt of ADT_Elemen
93. CS body code containing the dedicated SerDispatcher code Copyright 1995 96 by HOOD Users Group page 178 page 179 I HOOD USER MANUAL 1 0 HUM 1 0 J 9 F separate STACK OBCS SerDispatcher STACK server code procedure OPCS_POP STACK in T_STACK Element out T_Element is same code as Figure 149 end OPCS_POP procedure OPCS PUSH STACK in out T STACK Element in T_Element is same code as Figure 149 end OPCS_PUSH We can see that the principle of translating the code of protocol constrained operation OPCS in to OPCS_op_Name still holds in that most of the code OPCS_ER code can still be automatically generated The OBCS implementation may slightly vary according to queuing inter process queuing mech anisms available for the target Copyright 1995 96 by HOOD Users Group page 179 page 180 00 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page 180 page 181 i HOOD USER MANUAL 1 0 HUM 1 0 a De 3 GETTING THROUGH 3 1 HANDLING DOCUMENTATION STANDARDS The HOOD method does not mandate any documentation standard neither for Architectural Design Document ADD nor for Interface Control Document ICD nor for Detailed Design Document DDD Two cases may take place no mandated documentation standard for the project the design documentation is sim ply defined around the ODS concept as a set of ODSs An ODS is unique in a document
94. CS task server or more if needed that accepts operation entry requests according to the protocol constraint and performs effective call to the an OPCS procedure named OPCS lt OP Name gt that in cludes opcs header handling possibly state constraints and opcs body with the core op eration and return parameters within the accept statement 2 4 4 2 No use of Ada tasking e state constraint applied to an operation gt one FSM to ensure check STD description but possibly call to an OS semaphore to ensure protected access need to have an implementation of exceptions in language other than Ada protocol constraint applied on a operation gt 2 process at least implied one FSM to ensure check STD description but aclient task performs an OP_ER procedure part commuting the message request and decommuting the return parameters and exception handling aserver or more if needed that consumes messages requests and performs effective call to the OPCS procedure that includes opcs header handling possibly state constraints and opcs_body with the core operation and e commutes return parameters in a MSG back to client task S Note that ASER constraints are badly supported in Ada83 and need additional server and consumer task to perform according to the HOOD semantic Copyright 1995 by HOOD User s Group page 96 page 97 HOOD USER MANUAL 1 0 HUM 1 0 oof g J 2 5 DISTRIBUTED SYSTEMS
95. Ctrl EMS is entry Start entry Stop entry Monitor end OBCS Ctrl EMS PROVIDED INTERFACE OPERATIONS procedure Start renames OBCS Ctrl EMS Start Copyright 1995 96 by HOOD Users Group page 228 page 229 HOOD USER MANUAL 1 0 HUM 1 0 OO g J The Start operation initialises the monitoring timer the alarm the sensors and the bargraphs which are used during the mon itoring procedure Stop renames OBCS_Ctrl_EMS Stop The Stop operation stops the monitoring timer and switches off the alarm and the bargraphs and stops the sensors procedure Monitor renames OBCS Ctrl EMS Monitor The Monitor operation acquires the values of each sensor Those values are displayed on the appropriate bargraph In case of a value is out of range this operation switches the alarm on and gives the red colour to the bargraph If there is a sensor failure the alarm is switched on and the bargraph flashes in red colour In other cases the values are displayed in green colour DATAFLOWS mean_value lt Sensors mean_value gt Bargraphs color gt Bargraphs initial_frequency gt Timers_Driver EXCEPTION_FLOWS sensor_failure lt Sensors END OBJECT Cul EMS end Ctrl EMS OBJECT Ctrl EMS IS ACTIVE REOUIRED INTERFACE OBJECT Sensors with Sensors TYPES T SENSOR OPERATIONS Start Acguire Stop EXCEPTIONS SENSOR FAILURE OBJECT Alarm with Alarm TYPES T A
96. Ctrl_EMS Start The Start operation starts the EMS The EMS environment will be initialised procedure Stop renames Ctrl EMS Stop The Stop operation stops the EMS procedure Acknowledge renames Alarm Acknowledge The Acknowledge operation stops the Alarm for the faults which have switched on it OBJECT_CONTROL_STRUCTURE DESCRIPTION The EMS accepts start stop and acknowledge operations at any time Start is not significant after a start Stop or acknowledge are not significant after a stop CONSTRAINED_OPERATIONS Start CONSTRAINED BY ASER by IT Start push button Stop CONSTRAINED BY ASER by IT Stop push button Acknowledge CONSTRAINED BY ASER by IT Ack push button IMPLEMENTED BY Ctrl EMS Alarm end EMS OBJECT Ctrl EMS IS ACTIVE package Ctrl EMS is DESCRIPTION This object is the controller of the EMS It starts and stops all the constituents objects of the EMS and controls the moni toring IMPLEMENTATION_OR_SYNCHRONISATION_CONSTRAINTS The Ctrl_EMS must perform the monitor operation in less than 1 second OBJECT_CONTROL_STRUCTURE DESCRIPTION The Ctrl EMS accepts start stop and monitor operations at any time A start is not significant after a start A stop or a mon itor are not significant after a stop CONSTRAINED OPERATIONS Start CONSTRAINED BY ASER by IT Start push button Stop CONSTRAINED BY ASER by IT Stop push button Monitor CONSTRAINED BY ASER by IT Timer 1Hz task OBCS
97. D design shall first be produced ignoring all physical and implementation details and constraints The principle of the approach is to produce first a solution as if non constrained supposing we have an ide al with unlimited power reliable target and then rework it to add complexity for dealing with specific non functional constraints such as performance reliability distribution e phase 2 Infrastructure By Infrastructure one should understand the support software associated to the logical archi tecture e g communication services operating system archiving system e phase 3 Distribution One should understand distributing the software associated to previous architectures and HOOD objects over a physical network of logical processors or VNs e phase 4 Physical architecture One should understand here the allocation of the logical processors identified in phase 3 onto the physical architecture consisting of physical processors inter connected through commu nication channels The four activities of that process are shown in Figure 25 below LOGICAL ARCHITECTURE DISTRIBUTION l Functional requirements Non Functional Requirements INFRASTRUCTURE Data sharing DISTRIBUTED Performance constraints ARCHITECTURE Physical constraints Implementation constraints Communication means PHYSICAL WHERE ARCHITECTURE Figure 25 Full Design Activities Overview Copyright 1995 96 by HOOD Users Group pag
98. ERATION Monitor procedure OPCS Monitor is DESCRIPTION This operation is in charge of the EMS monitoring It acguires the mean values of each sensor controls them against limit values with respect to each category of sensors converts those mean values into displaying values according to min and max infor mation and displays them on the corresponding bargraph It sets the alarm if the mean value is out of range or if there is a sensor failure It also set the green colour of a bargraph when the value is correct the red colour when the Copyright 1995 96 by HOOD Users Group page 231 page 232 HOOD USER MANUAL 1 0 HUM 1 0 OO g J value is out of range and the red flashing colour when the corresponding sensor is failed The Monitor operation switched the alarm on for each out of range value and each failed sensor and switched the alarm off for each correct value and running sensor USED_OPERATIONS Alarm Switch_On Alarm Switch_Off Bargraphs Display Bargraphs Flash Bargraphs Set_Colour Sensors Acquire Is_Value_out_of_Range HANDLED_EXCEPTIONS Sensors SENSOR_FAILURE PSEUDO_CODE TBD CODE begin null TBD end OPCS_Monitor END_OPERATION OPCS_Monitor END_OBJECT Ctrl_EMS end Ctrl EMS Copyright 1995 96 by HOOD Users Group page 232 page 233 HOOD USER MANUAL 1 0 HUM 1 0 oof g J A3 HOOD4 TARGET IMPLEMENTA TION AND ILLUSTRATIONS A3
99. ERATION Stop OPERATION Store Value SENSOR inT SENSOR VALUE in POSITIVE STATUS in T HARDWARE SENSOR STATUS DESCRIPTION TBD USED OPERATIONS TBD PROPAGATED_EXCEPTIONS TBD HANDLED EXCEPTIONS TBD PSEUDO_CODE TBD CODE END OPERATION Store VAlue OPERATION Get Last Value SENSOR in T SENSOR VALUE out POSITIVE STATUS out T HARDWARE SENSOR STATUS DESCRIPTION TBD USED OPERATIONS TBD PROPAGATED_EXCEPTIONS TBD HANDLED EXCEPTIONS TBD PSEUDO_CODE TBD CODE END OPERATION Get Last Value END OBJECT Sensors A1 3 3 OBJECT BARGRAPHS IS PASSIVE DESCRIPTION The bargraphs object allow to display values in red or green with or without flashing on appropriate display devices It also provides all means to start and stop the hardware display_device l IMPLEMENTATION_CONSTRAINTS NONEI PROVIDED_INTERFACE TYPES Copyright 1995 96 by HOOD Users Group page 222 page 223 HOOD USER MANUAL 1 0 HUM 1 0 OO g J T_BARGRAPH is OIL_PRESSURE_BARGRAPH WATER_TEMPERATURE_BARGRAPH FUEL LEVEL BARGRAPH Defines the type of bargraphs which are taken into account in this object l T COLOUR is RED GREEN Enumerated type giving the different displaying colours l T FLASHING is ON OFF Status of the displaying Flashing or not l T_PERCENTAGE isRANGE 0 100 Type of the values which are displayed on the bargraphs l OPERATIONS Ini
100. ERNALS TYPES Stack_Body is array Positive range lt gt of Items Stacks MAX_STACK_SIZE Natural 100 is record Top Natural 0 Body Stack Body 1 nd record MAX STACK SIZl Figure 99 Generalization of the simple ADT BOUNDED STACKS These three cases imply to choose the actual size of the structure at different moments e in the first case the decision is taken when designing the object itself Changing this value means changing the object and it may have important consequences re code generation re compilation re validation etc e inthe second case the decision is taken when instantiating the class The class definition has Copyright 1995 96 by HOOD Users Group page 129 page 130 HOOD USER MANUAL 1 0 by HUM Working Group not to be modified e inthe third case the decision is taken when designing the object using the stack for examples by declaring a value of the provided type In particular the actual size may only be known at run time the same instance of the class is able to produce values of different sizes Advice 29 Use limited private types not only private for Class formal types parameters ex plicitly importing assignment and equality operations if required Comments For a class to be usable in as many contexts as possible it should minimize the assumptions that it makes about its environment and should make explicit any assumptions that are necessary A for
101. HEI91 However synchronous code generation for Predicate transitions Petri nets could be easily defined see Fig ure 122 Copyright 1995 96 by HOOD Users Group page 145 page 146 i HOOD USER MANUAL 1 0 by HUM Working Group a De As more formal notations are used we would like to rely directly on their formal basis to verify directly the properties of the models produced without generating code and testing This re quires supporting tools for e checking consistency of one given model the checks will rely on intrinsic properties de fined by the semantic definition of the notation and or language use to model an OBCS e checking consistency of composition of models as a full system behaviour is the compo sition of elementary object behaviours the ability of composing OBCS would be useful e validation of behavioural descriptions against models from requirements analysis or models produced at another level of description e g equivalence of a model describing a HOOD parent object would be checked against the composition of behaviours of its child objects e Validation is currently relying on simulation of behavioural descriptions and pragmatic com parison of equivalence through test scenarios A formalism based on a strong mathematical model of concurrence would allow to perform formal calculi and proofs on the described behaviours Some notations such as synchronous languages ESTEREL SIGNAL have now tools to suppo
102. HOOD USER MANUAL RELEASE 1 0 HOOD USERs GROUP HOOD USER sMANUAL Issue Working Document 1 0 Created July 27 1994 Reference HUM3 1 Prepared by HUM Working Group Approved by HOOD Technical Group Diffusion HOOD USERs Group Doc Ref HUM 1 0 Printed July 11 1996 1 38 pm page ii I HOOD USER MANUAL HUM 1 0 a De HOOD USER MANUAL Technical Document property of the HUG Document No HUM Issue No 1 0 Last Modified July 11 1996 1 38 pm Abstract HOOD Hierarchical Object Oriented Design a trademark of The Hood User Group is the industrial design method chosen by the European Space Agency ESA as the com mon method for European software projects HOOD is a design method supporting the definition of interfaces reusable modules as well as architecture models It allows to represent systems and software architecture as a set of interconnected hierarchies of objects HOOD is therefore supporting programming in the large relying on code generator technology from high level or formal notations HOOD is thus primarily aiming to better fill the needs of the prime contractor and integrator than those of the low level programmer Although HOOD puts the emphasis on interface and behaviour mastering these benefits have been rather neglected by today users of graphical programming notations for object oriented programming languages This document presents the HOOD development approach and gives examples f
103. HOOD USER MANUAL 1 0 HUM 1 0 OO g J package body STACK is any common data to be included here with HRTS use HRTS procedure OSTM is code as illustrated in figure A1 1 above end OSTM procedure start is separate procedure stop is separate procedure PUSH item in T_Item is separate procedure POP Item out T_Item is separate function Status return T_Status is separate begin OTSM initialisation of FSM at package elaboration end STACK separate STACK procedure start is begin OPCS_HEADER HRTS SEMAPHORE P STACK there is one mutex semaphore for STACK begin HRTS FSMS FIRE STACK START X_BAD_EXECUTION_REQUEST possibly raised exception when X BAD EXECUTION REGOUEST gt EXCEPTIONS LOG STACK Start X BAD EXECUTION REOUEST EXCEPTIONS raise shall work in ADA and in C when Others gt EXCEPTIONS LOG STACK Start Others EXCEPTIONS raise so as to propagate to client end end OPCS HEADER 2 0 222 2222 225 OPCS BODY CODE extracted from the ODS field begin OPCS FOOTER HRTS SEMAPHORE V STACK release mutex semaphore for STACK end OPCS_FOOTER end start
104. IF standard and application driven recommended for reliable and critical systems the associated code is distributed within the different objects modules of the applicative or interactive part and leading to high efforts in testing and maintenance HOOD allows to represent easily interactive programs as separated objects exchanging data e g APPLICATION and MMI objects in an initial model Those data may then be specified and re fined as abstract data instances described in other HOOD objects hierarchies following princi ples described in section 2 1 above The clear separation formulated in this initial model allows to define three development lines development of the application part by HOOD decomposition of object APPLICATION The associated refinement may also provide for identification of operations provided of ab stract data type objects associated to the data exchanged with the MMI part The application object should provide the operations defining an API Application Programming Interface thus allowing to define application that can be interfaced either to other applications batch network oriented IO or any windowing system e development of man machine part by using suitable graphical interface generators and prototyping tools and by re engineering some of the associated software namely all user defined procedures associated to call backs into HOOD objects A call back is simply represented in HOOD as an ASER_
105. INTEGER Table OPERATIONS Swap U INTEGER Swap Figure 96 Instance for sorting integer an instance for sorting strings see figure 97 OBJECT SORT_STRING is INSTANCE_OF SORT_SE PARAMETERS TYPES Element gt UTIL_STRING Line Data gt UTIL STRING Table of Line OPERATIONS Swap gt UTIL STRING Swap Line Figure 97 Instance for sorting string Advice 26 For passive objects use Abstract Data Types in preference to Abstract Data Ob Copyright 1995 96 by HOOD Users Group page 127 page 128 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group I 9 Jects Comments The biggest advantage of an ADT over an ADO is that the user can declare as many objects as desired with an ADT These objects can be used as part of other objects they can be declared as components of arrays or records They can be used to instantiate classes with formal type parameters Finally this is the only way to cope with a dynamic number of objects Advice 27 For active objects use Abstract Data Objects in preference to Abstract Data Types Comments The problem with ADT in HOOD is that there is only one HOOD Object defined and visible in the design and maybe a lot of real objects instantiated from this ADT hidden in the internal part of terminal HOOD objects Since the object is passive this is not a real problem but as soon as the object become
106. IONS LOG STACK OBCS INIT PROCESS LOOP BAD constraints raise X_MSG_INCONSISTENCY end case end loop exception when others gt EXCEPTIONS LOG STACK OBCS INIT PROCESS LOOP EXCEPTION NAME end START end STACKSERVER Figure 172 STACK I with protocol constraints without tasking Note how the protocol constraints are solved e ASER constraint are treated directly in the STACKSERVER loop before the operation re quest is processed e TOER requests are treated at the client side using only local time e LSER request are treated as incoming parameters have been extracted e HSER request are treated after lt OBJECT gt _SERVER operatiojn execution A3 2 2 3 STACK with protocol constrained operations STACK SERVER CODE same code as for state constrained STACK Copyright 1995 96 by HOOD Users Group page 246 page 247 HOOD USER MANUAL 1 0 HUM 1 0 A3 2 3 CLIENT SERVER ILLUSTRATION FOR CLASSES The above principles are adapted for defining code generation rules for an active class of name lt CLASS gt to whom three target class units are associated client_class module of name lt CLASS gt request broker for the class of name lt CLASS_RB gt and the original class named lt CLASS gt _server Client of such classes shall only instanciate client_class target unit as illustrated inFigure 173 with one server instance of server_class for all instances of a given client thus enforcing Client_Server archite
107. J 9 6 2 HOOD BIBLIOGRAPHY 6 2 1 ARTICLES AND PAPERS PUBLISHED IN 1995 MH95b Achieving Reusable and Reliable Client Server Code using HOOD automated code generation for ADA95 and C targets M HEITZ Lecture Notes In Com puter Science SPRINGER VERLAG Proceedings of the Ada Eurospace Con ference Frankfurt October 1995 MH95a Automated Client Server Code Generation from HOOD4 Object Oriented Desigsn M HEITZ Proceedings of the IFAC Workshop on Distributed Compu ter Control Systems Conference Blagnac September 1995 6 2 2 ARTICLES AND PAPERS PUBLISHED IN 1994 MH94c Integrating Modular Object Oriented Programming and Application generator technologies in large Real Time and distributed Developments M HEITZ the Ada Eurospace Conference Copenhagen September 1994 MH94b EXPERIMENTING REUSE with HOOD and Ada M HEITZ B DELATTE Proceedings of the Ada Eurospace Conference Brussels November 1993 MH94a Analyse et Conception Orient e Objet avec HOOD M HEITZ Journ e Rencon tres Industrielles ENSIMAG Grenoble juin 1993 6 2 3 ARTICLES AND PAPERS PUBLISHED IN 1993 HRM93 HOOD Reference Manual 3 1 HOOD Technical Group B DELATTE M HEITZ JF MULLER Editions MASSON et PRENTICE HALL 1993 MH93b EXPERIMENTING REUSE with HOOD and Ada M HEITZ B DELATTE Proceedings of the Ada Eurospace Conference Brussels November 1993 MH93a Analyse et Conception Orient e Objet avec HOOD M HEITZ Proceedings de la conf
108. K vesssccsssssssistas ssstes csassacecdshashewcodsnsegescobedsssessabsesesssaseedssuacssndesenses 11 Figure 11 ODS for STACK User Manual 12 Figure 12 ODS tor STACK intertial s seisena caabeepeisncusencuses ter de pet dh v P 13 Figure 13 ODS for STACKs Internals continued s 14 Figure 14 Mapping between HOOD and Ada entities ss 15 Figure 15 Code generation principle for Parent object 16 Figure 16 Code generation principle for Parent object standard generation 16 Figure 17 Code generation principle for Parent object Nesting Child packages in parent Body 16 Figure 18 HOOD 3 Code structure for constraint Operations 0 eee ceteeeeceeeeeeceeeeeeeeeeeeeeeeeeaeeeae 17 Figure 19 Code generation principles for terminal active object 18 Figure 20 A System To Design within a whole project Client server use relationships are not shown 19 Figure 21 The HOOD design model into a set of spaces and hierarchies 0 eee eeeeeeeeeeeeereeeeeeee 21 Figure 22 HOOD Design Tree as decomposed from the ROOT object 22 Figure 23 The HOOD design activities and associated outputs 20 0 leet eteeteceeceeeceeeeeeeeeeeeeeeneeaeeens 24 Figure 24 Application of Basic Design Steps to the system configuration 33 Figure 25 Full Design Activities Overview ses 34 Figure 26 Full Design Activities applied on the HOOD Architecture 35 Figure 27 The ZT Strates ste ste
109. KS object A3 1 2 IMPLEMENTING STATE CONSTRAINTS WITHOUT ADA TASKING In case of resources shortage or when Ada tasking should not be used an alternative implemen tation based on Finite State Machines FSM may be used simulating the code structure as il lustrated in figure above up to standardization within HOOD and support by the toolsets The OPCS code shall then be structured in three parts e OPCS_HEADER part for handling state constraints The associated header code as illustrat ed in Figure 147 is reduced to a simple call to an FSM module This code attached to the Copyright 1995 96 by HOOD Users Group page 234 page 235 HOOD USER MANUAL 1 0 HUM 1 0 oof g J constraint resolution generally needs not an additional process a simple test may implement the state constraint Thus we implement the constraint using an FSM The code of that FSM could be generated automatically from an appropriate STD so that the designer has just to express the possible sequences of an object class by drawing a STD See Appendix A3 2 1 2 for an example of such code gt Additionaly the OPCS_HEADER could contain code to set a semaphore when the operation is to be executed in mutual exclusion this is done by a call to the target OS services e Core body part containing the functional transformational code not dealing with states and behaviours e OPCS_FOOTER part code needed only to release a semaphore in case of mutual exclusi
110. LARM OPERATIONS Start Switch On Switch Off Stop OBJECT Bargraphs with Bargraphs TYPES T COLOUR T BARGRAPH T FLASHING T PERCENTAGE OPERATIONS Init Display Set_Colour Flash Switch_Off OBJECT Timers_Driver with Timers_Driver REQUIRED TYPES T TIMER REOUIRED OPERATIONS Create Start Copyright 1995 96 by HOOD Users Group page 229 page 230 HOOD USER MANUAL 1 0 HUM 1 0 OO g J Delete package body Ctrl_EMS is INTERNALS TYPES TBD CONSTANTS IT_1HZ_ADDRESS constant Monitor ADDRESS MONITORING_FREQUENCY constant 1 TBD OPERATIONS procedure Is_Value_out_of_Range procedure OPCS_Start procedure OPCS_Stop procedure OPCS Monitor TBD EXCEPTIONS TBD DATA MONITORING TIMER Timers Driver T TIMER TBD OBJECT CONTROL STRUCTURE PSEUDO CODE TBD CODE task body OBCS Ctrl EMS is begin loop loop select accept Start OPCS Start exit or accept Stop empties Stop queue or accept Monitor empties Monitor queue end select end loop loop select accept Start empties Start queue or accept Stop OPCS_Stop exit only when monitoring is completely finished or accept Monitor OPCS_Monitor end select end loop end loop end OBCS Ctrl EMS OPERATION CONTROL STRUCTURES OPERATION OPCS Start procedure OPCS Start is DESCRIPTION This operation initiali
111. MANUAL 1 0 HUM 1 0 OO De It seems that reusable components and even reusable structures of any type should have three fundamental and orthogonal properties modularity components should be self documented and self handable entities whose de pendencies should be limited and or systematically stated As such the concepts of object orientation enforcing abstraction and encapsulation of provided interface as well as specifi cation of required interface are of primary importance Their application can lead to better understandibility of modules hiding complexity and where consistency is still verifiable through controlled dependency and visibility rules Especially these rules should banish any implicit visibility what would increase the understanding effort In any case the associated documentation must be self content and shall not have any for ward or aside references invariance which characterises the ability of a structure to resemble an ideal one or and a standard one It is easy to imagine that for an application domain where systems with similar functionalities are developed there exist in theory an ideal organisation and structures that performs the best trends achieving the best properties Such an architecture and associated definition of its components can be progressively refined through capitalisation of the design experience when the system is refined version after version Also such an architecture coul
112. Note that the implementation of the protocol constraints HSER LSER ASER is performed ac cording to calls to the OPCS_op_name within or without the accept statement Copyright 1995 96 by HOOD Users Group page 172 J 9 f page 173 HOOD USER MANUAL 1 0 HUM 1 0 2 14 NO TASKING ADA CODE ILLUSTRATION 2 14 1 CODE FOR STATE CONSTRAINTS Implementation rules for OBCS tasking code do not apply any more instead the code of a HOOD RUN TIME library appearing as environment objects EXCEPTIONS FSM and OBCS shall be used according to principles detailed in Appendix A3 1 and illustrated in figure below EXECUTING CLIENT THREAD OPCSs FIRE Op gt 7X OPCS HEADER code sample begin FSM FIRE CurrentObject OP reguest exception when X UNW gt unawaited operation trigger in that state EXCEPTIONS LOG From FSM FIRE X UNW logging raise transmit to client when others gt EXCEPTIONS LOG From FSM FIRE others raise end Figure 147 Additional HEADER code to the OPCS for state constraint support with an FSM Figure 148 and Figure 149 give the associated code with ADT ELEMENT visibility sur le type T Element with FSM visibility on type T Status defining all states of the FSM package STACKs is type T Status is BUSY IDLE UNDEFINED definition du type T Status type T DATA is array integer lt gt of ADT Element T Element useful data type T STACK MAX integer is record DATA T DA
113. OD USER MANUAL 1 0 by HUM Working Group J d Activity 2 Elaboration of an Informal Solution Strategy ISS Activity Inputs At this stage all necessary elements are well organized either in a note coming from the previous phase or in the child ODS coming from the previous design step and the design activity may really start Outline a solution put it down as a text and work it out This phase has as goals the expression of a solution that the designer should have started to imag ine to phantasm about from the earlier phases The designer shall identify the main abstractions and actions and give a scenario of solution accordingly Such a strategy shall be expressed in natural language in order to explicit clearly how the solu tion will work without requiring any organisation don t speak about objects in a first issue The purpose is to explain what happens when the current object services are required in terms of data and actions on those data Good example On IT reception from the Start push button the EMS inits bargraphs creates and starts a timer which triggers the monitoring each second Bad example 0 The EMS is composed of a Sensor object which encapsulate all actions on the physical sensors This activity will not allow to build the final design but a first issue of that design The designer has mainly to consider the quality of the design more than its efficiency this will be the purpose of the next acti
114. ON PSEUDO CODE TBD CODE TBD END OPERATION Flash OPERATION Switch Off DESCRIPTION This operation switches the hardware bargraphs off Copyright 1995 96 by HOOD Users Group page 224 page 225 HOOD USER MANUAL 1 0 HUM 1 0 OO g J USED_OPERATIONS Input_Output_Driver Put PROPAGATED_EXCEPTIONS NONE HANDLED_EXCEPTIONS Input_Output_Driver MALFUNCTION PSEUDO_CODE TBD CODE TBD END_OPERATION Switch_Off END_OBJECT Bargraphs A1 3 4 OBJECT ALARM IS ACTIVE DESCRIPTION The Alarm object manages a set of software alarms One hardware alarm is associated to those software alarms It is pos sible to switch a software alarm on or off at each time The hardware alarm is started when an unset software alarm is switched on set The hardware alarm is stopped when the set of software alarms are switched off unset or when acknowl edged by the user In that case the status of the set software alarms are not modified IMPLEMENTATION_CONSTRAINTS 255 software alarms may be simultaneously l PROVIDED_INTERFACE TYPES T ALARM is integer range 1 255 This type defines a software alarm identified by an integer rangel to 255 I OPERATIONS Start The Start operation switches the hardware alarm and the software alarms off Acknowledge This operation stops the hardware alarm without unset the set software alarms Switch On ALARM inT ALARM This operation switched
115. ONS SET goto exception return test for branching to the exception handler endef if omitted an error will be detected by the C compilerr Figure 131 Sample code of testing exceptions in client code ln C raise is replaced by a throw statement and testing by a catch statements Copyright 1995 96 by HOOD Users Group page 156 page 157 0 0 l HOOD USER MANUAL 1 0 HUM 1 0 J 9 2 12 3 3 Generation rules for passive objects Passive object implementation presents no difficulties and the encapsulation mechanisms of the languages will be extensively used FORTRAN libraries PASCAL module C programs and modules assembler compilation units 2 12 3 4 Generation rules for active objects HOOD3 1 defines support of constrained operation by means of an OBCS unit tone or several tasks that handle control and communication protocol between client and server threads When target with no ADA tasking are used protocol constraint operation can only be implement ed by using a HOOD RUN TIME library that implements inter process communications associ ated to the definition of HOOD protocol constraints Such implementation rules and illustrations can be found in Appendix A3 of present document and have been standardised through use of HOOD runtime environments objects such as OBCS FSM and EXCEPTIONS and proposed for inclusion in the HOOD4 definition 2 12 3 5 Entity Naming Since a number of target languages restrain the i
116. OOD Users Group page 123 page 124 H O0 i HOOD USER MANUAL 1 0 by HUM Working Group F D ed Comments This is the best way of defining reusable operations on arrays The local variables are correctly dimensioned in any case Example Figure 91 gives an example of defining an array INTERNALS TYPES Vector is array Index range lt gt of Element Matrix is array Index range lt gt Index range lt gt of Element OPERATION_CONTROL_STRUCTURES OPERATION Matrix_Op A in Matrix IS CODE Workspace Matrix A RANGE 1 A RANGE 2 TEMP V Vector A FIRST 1 2 A Last 1 Figure 91 defining an array Advice 14 Be careful about overloading the names of provided operations in a HOOD Class Example Figure 92 is an example of an INPUT OUTPUT class If this class is instantiated in a IO INTEGER object see figure 93 the two Put operations have identical interfaces and all calls to Put are ambiguous Therefore this class cannot be used with the type Integer and its sub types OBJECT INPUT OUTPUT is CLASS PASSIVE FORMAL PARAMETERS TYPES Items is limited private PROVIDED INTERFACE OPERATIONS Put Item in Integer Put Item in Items Figure 92 two different put operations OBJECT IO_INTEGER is INSTANCE_OF INPUT_OUTPUT PARAMETERS TYPES Items gt Integer Figure 93 instantiation of INPUT OUTPUT In such a case it is better to give unambiguous names to a
117. OOD design components e Itis interesting for traceability reasons to annotate HOOD design components with the per formance constraints which either constrain or impact them The relationships con strain and impact are two different kinds of traceability links between performance constraints and design components To explain the difference between them we can say that constrain identifies design components which are explicitly constrained these components implement the function which is identified in the performance constraint and impact iden tifies components which may interact with the constrained ones e Execution profiles can be attached to HOOD design components for describing the way software accesses hardware resources 2 11 4 3 Inserting annotations into a HOOD design The simplest way of associating annotations with HOOD design components is to insert them in HOOD object descriptions via structured comments A brief description of the Object Description Skeleton is provided below We have emphasized in this ODS description what parts of the ODS need to be identified before the insertion of anno tations 2 11 4 4 Performance Annotations for a HOOD design 2 11 4 4 a Annotating a HOOD design with performance requirements e Annotation by duration and throughput constraints For each HOOD operation constrained by a constraint we propose to associate the con straint with the operation in
118. OPERATION Operation1 DESCRIPTION This field contains the description of the operation It may also contain an execution profile such as the following one WCET 10 ms estimated or computed worst case execution time 10 Read File1 10 KB LOOP 10 WCET 1 ms CALL Operation2 SEND 1 KB GET 2 KB SEND_LOOP USED OPERATIONS END_OPERATION Operation1 Figure 130 Example of HOOD annotations for performance and timing estimations Copyright 1995 96 by HOOD Users Group page 154 page 155 i HOOD USER MANUAL 1 0 HUM 1 0 J 9 2 12 TARGET LANGUAGES In Appendix 1 1 6 of present document the general principles for code generation are given and the current section will not present them again However we shall bring here complementary in formation and illustrations 2 12 1 HOOD TO TARGETS IMPLEMENTATION PRINCIPLES HOOD ODSs are formatted texts grouping object properties including a number of target de pendent fields directly entered as target code HOOD code generation principles are then to generate e a software architecture in terms of target modules units INCLUDE relationships are implemented by target encapsulation mechanisms if they ex ist or by simple file inclusion USE relationships are implemented through target mechanims to control visibility intra and inter units For some targets an include strategy with EXTERN and REF clauses may have to be defined e target code
119. OPERATIONS TBD EXCEPTIONS TBD DATA HARDWARE ALARM Input Output Driver T DEVICE ALARM HARDWARE ALARM STATUS T HARDWARE ALARM STATUS OFF SOFTWARE ALARMS T SOFTWARE ALARMS TBD OBJECT_CONTROL_STRUCTURE PSEUDO_CODE TBD CODE TBD OPERATION_CONTROL_STRUCTURES OPERATION Start DESCRIPTION The Start operation switches the hardware and the software alarm off l USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Start OPERATION Acknowledge DESCRIPTION This operation stops the hardware alarm USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END_OPERATION Acknowledge OPERATION Switch On ALARM inT ALARM DESCRIPTION Copyright 1995 96 by HOOD Users Group page 226 page 227 HOOD USER MANUAL 1 0 HUM 1 0 OO g J This operation sets the specified software alarm to ON if it was not If it was OFF it starts the hardware alarm if it was not and sets the hardware alarm status to ON I USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Switch On OPERATION Switch Off ALARM inT ALARM DESCRIPTION This opera
120. Operation_Name gt Figure 19 below illustrates these principles for an active object O with four constrained opera tions S X Y and W By convention there is one such OBCS per object but in case of resource shortage its is always possible to group several OBCS into one HOOD standard generation rules define the OBCS as an Ada package possibly reduced to one task unit and the OPCS header code as a rename of an OBCS entry hiding the OBCS to clients whereas the OPCS body code is defined in a proce dure called OPCS_OpName The standard scheme may be quite resource consuming especially when guards are used to handle state constraints accordingly a schema based on FSM Finite State Machine has been defined and detailed in Appendix A3 2 1 Copyright 1995 96 by HOOD Users Group page 17 page 18 HOOD USER MANUAL 1 0 by HUM Working Group package O is task OBCS is entry S state constrained operation entry X ASER constrained operation entry Y LSER constrained operation entry W HSER constrained operation end OBCS procedure S renames OBCS S procedure X renames OBCS X procedure Y renames OBCS Y procedure W renames OBCS W end O package body O is procedure OPCS_S is separate procedure OPCS_X is separate procedure OPCS_Y is separate procedure OPCS_W is separate task body OBCS is begin loop select accept S State constraint OPCS_S return with operation executed if State was OK state can
121. PASEDENA HOOD version 3 0 l ge de raison P Gendre et H Bitteur G nie Logiciel et Syst me Expert Vol n 19 pp 44 48 juin 1990 On the translation of HOOD Nest into Ada R Di Giovanni PRISMA Proceed ings of ADA Europe Dublin 1990 Cambridge University Press ADA Compan ion series Integration of HOOD Est rel and Ada for the development of safe and reliable Real Time Systems I SNEED M HEITZ CISI INGENIERIE Proceedings of the Ada Eurospace Conference Barcelona december 1990 La m thode HOOD compte rendu du groupe de travail AFCET H JOCTEUR AFCET INTERFACES n 93 Juillet 90 Contribution of Ada to an improved Software Development Approach Y LA FEUILLADE F COURJARET MATRA MS2I Proceedings of the Ada Eu rospace Conference Barcelona december 1990 An overview of several French Navy projects using HOOD and Ada M Lai Pro ceedings of the Ada Europe conference 1990 Dublin ADA Companion Series Ada Cambridge University Press 1989 A Baseline fora HOOD method Assistant JR Larre N Alfaro JJ GAlan J Gar baosa GMV Spain Proceedings of the Ada Eurospace Conference Barcelona december 1990 A Pragmatic Application of OOD to the Development of Ada Using the Team work Toolset P Mellor Proceedings of Hood conference April 1990 Manches ter Airport La m thode de conception HOOD dans le cycle de d veloppement et ses outils M Heitz Proceedings des Journ es Internationales de l Informatique et de
122. PPLICATION ASER_by_UNIX_Shell Aser by ItX INTERFACE START X CALL BACKS X INTERACTIONS APPLIGATION X CALL BACKS LOGICAL OPERATIONS E X_INTERFACE Figure 84 Isolating the application from GUIMS code The object X_INTERACTIONS handles fully interactions with the GUIMS and may almost be fully developed within a GUI generator environment Communication with the APPLICATION object are performed according to functional protocols allowing to isolated it completely from the GUI Copyright 1995 by HOOD User s Group page 110 page 111 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J 2 7 INFORMATION SYSTEMS Development of Information Systems IS may be categorized into e those dealing solely with the definition of a database In this case the use of dedicated tools Data Base Management Systems DBMS development Environments 4G languages is required and the use of HOOD is not relevant e those dealing with the definition of an application on top of a DBMS with or without devel opment of the latter In this case the development will obey to the separation principle of e the applicative part defining the supporting architecture interactions between the main components possibly developed with the most suitable tools amp environments e the MMI part often a key part in the system e the interface to the DBMS and or the DBPMS itself Using HOOD such a separation is easily supported by defining an initi
123. R OK return from server end if if not MSG CSTRNT ASER then ClientObcs FREE MSG deallocate MSG and queues after processing return parameters end if exception when X_BAD_EXECUTION_REQUEST gt EXCEPTIONS LOG STACK PUSH X BAD EXECUTION REOUEST EXCEPTIONS raise so as to propagated to client when Others gt EXCEPTIONS LOG STACK PUSH Others EXCEPTIONS raise end PUSH if the request is also TOER then we would insert here a call to TIMER SET delay as well as a TIMER TimeOut call after return MSG ClientObcs remove remove return IPCMSG Figure 74 OPCS ER code Sample for STACK PUSH client stub operation Copyright 1995 by HOOD User s Group page 99 page 100 HOOD USER MANUAL 1 0 by HUM Working Group 0 0 g g The ServerStub object of Figure 72 above is implemented as a set of objects as many as allo cated objects to the remote VN that are required by other remote VNs and whose OPCS code contains only OPCS_SER code as illustrated in Figure 75 below procedure PUSH MSG in IPCMSG T_MSG is OPCS_SER code Item Items T_Items begin begin item MSG INFO MSG X OK if MSG CSTRNT LSERILSER_TOER then ServerObcs insert MSG insert in return queue end if STACK_SERVER PUSH Item exception when X_BAD_EXECUTION_REQUEST gt EXCEPTIONS LOG STACK SER PUSH X BAD EXECUTION REOUEST MSG X string X BAD EXECUTION REGOUEST when Others
124. RDBMS is used the implementation of the abstract data type support HOOD object will use the SOL primitives to handle fine access to the data In case an Object Oriented DBMS OODBMS is used the abstract data type implementa tions may directly be the classes associated to the object oriented database schema An example of an IS initial HOOD model is given in Figure 85 below SER Entity relationships models Modern models support inheritance to factor relationships and description see OMT for ex ample Some tools are now able to automatically generate C or C interface modules for manipulation of the schema and access data associated to a MERISE or E_R data models extended with inheritance Copyright 1995 by HOOD User s Group page 111 page 112 HOOD USER MANUAL 1 0 by HUM Working Group oof p J 2 7 2 EXAMPLE OF A HOOD INITIAL INFORMATION SYSTEM MODEL Three objects associated to the three development lines and exchange data which are implement ed by HADT environment objects INFORMATION_SYSTEM ASER by Host_Q start Data elem_data E ADT Data I Put OPs Get OPs E X_INTERFACE Ext_data f t Put_OPs Mngt_Ops Applis_Data Get_OPs OTHER_System E hor vems dat E OO_DBMS ADT_Applis_data Figure 85 Typical architecture of an Information System initial HOOD model the object I_DBMS provides a Start operation required by APPLICATION for initialisation Operation sets Put_Ops et Get_Ops
125. S of the current environment object Copyright 1995 96 by HOOD Users Group page 184 page 185 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 For each Class instanciated into the Design or Class Trees Y lt Class gt Class Design This chapter describes the Design Tree of the class Y 1 Overview Y 2 Environment This section defines the class environment that means all environment objects used by the class to be designed Y 2 1 Overview Y 2 2 Functioning This section explains the following graphical description in terms of data handling through operations of the class and the used environment objects Y 2 3 Graphical Description This section gives a context diagram of the class It is defined with a HOOD diagram including the class to be designed and all used environment objects Y 3 Static Design This section gives the static decomposition of the class into child objects include relationship until terminal objects Y 3 1 Overview Y 3 2 Design Tree This section gives a synthetic view of the class hierarchy from the class until terminal objects For each class object or object instance of the Design Tree Y 4 x lt Object gt Object X 4 y 1 Overview See above X 3 x 1 Y 4 x 2 Functioning Only for Non Terminal Object See above X 3 x 2 Y 4 x 3 Graphical Description Only for Non Terminal Object This section gives the HOOD diagram of the current object defining the decomposition of it int
126. SG allocate a RETURN QUEUE access into MSG QUEUES Remove MSG RTN_Q MSG wait on return of operation executionr exception when others gt EXCEPTIONS LOG de OBCS INSERT Others raise end INSERT procedure SerDispatcher Name T_Operation is separate dedicated procedure for each object Copyright 1995 96 by HOOD Users Group page 177 page 178 HOOD USER MANUAL 1 0 by HUM Working Group OU procedure START is MAIN OBCSServer process MSG ADT MSG T MSG local MSG data begin OBCS INIT POOL init of OUEUE pool loop OUEUES Remove R O MSG get a reguest from R O Oueue case MSG CSTRNT is process the MSG when HSER HSER TOER gt SerDispatcher MSG OPERATION execution du code concern QUEUES Insert MSG RTN_Q MSG renvoi MSG au client when LSER ILSER TOER gt QUEUES Insert MSG RTN_Q MSG renvoi MSG au client SerDispatcher MSG OPERATION execution du code concern when ASER gt SerDispatcher MSG OPERATION execution du code concern when others gt EXCEPTIONS LOG STACK OBCS INIT PROCESS LOOP BAD constraints raise X_MSG_INCONSISTENCY end case end loop exception when others gt EXCEPTIONS LOG STACK OBCS INIT PROCESS LOOP EXCEPTION NAME end START end OBCS Figure 152 OBCS body code with no tasking protocol constraints separate STACK OBCS procedure OPCS_POP STACK inT STACK Element out T_Element is separate effective STACK server code pro
127. Set_Event Object_Name_E_OPname end O OP HSER Figure 112 Principle of O INTERFACE procedure Code This model is only an illustration of implementation principles but may easily be tuned accord ing to particular constraints of the target e active waiting strategy polling sleep or wake ups on events for HSER LSER or TOER ex ecution requests e step by step execution of the synchronous automata on event arrival or cyclic execution on timer interrupts at a frequency which is compatible with the one of event processing e execution of procedure O_OPi by the OBCS process or autonomous execution by active waiting processes or execution triggered by event handling In the following we give the INTERFACE procedure for different protocol constraint operations e HSER constraint the client process must be blocked until end of operation execution thus Copyright 1995 96 by HOOD Users Group page 143 page 144 HOOD USER MANUAL 1 0 by HUM Working Group procedure I OP HSER is begin AUTOMATA Set Event Object OP wait for Object End OP suspends client until End of operation end I OP HSER Figure 113 I INTERFACE Code for HSER constraint and procedure O OP HSER is begin OBJECT OP OPCS defined by a standard unconstrained operation AUTOMATA Set Event Object End OP end O OP HSER Figure 114 O INTERFACE Code for HSER constraint e LSER constraint the client process must be blocked until begin
128. State Automata Esterel etc e informal documentation texts in natural language Evaluation techniques of these products are of two kinds static verification and dynamic verifi cations but are mainly informal techniques and consists in the following activities e inspections sampling of product or documentation pieces and evaluation with respect to qualitative criteria e walk throughs assessment of technical contents with error underpinning e reader writer cycles formal checking of documentation against qualitative and technical criteria with configuration management of errors remarks and modifications e reviews checking of product submitted to review with respect to qualitative and technical criteria e Automatic or semi automatic checking can added to these manual means e use of design checkers and cross reference tables that are part of most HOOD toolsets e compilation syntactic checking and or execution of fields expressed with a formal nota tion Design validation and verification procedures in HOOD will be based on the separation in time of the descriptions of first an external description of an object and then the description of its implementation Step verification and validation ensuring consistency of one object decom position at the end of a basic design step is distinguished from level validation ensuring con sistency of a complete level decomposition i e several objects together 2 3 2 DOC
129. TA 1 MAX TOP integer 1 SIZE integer MAX STATUS PROJECT_ENV T_StatuS end record OPERATIONS procedure Status STACK in T STACK return T Status State CONSTRAINED OPERATIONS procedure PUSH STACK out T STACK Element in T Element procedure POP STACK in T STACK Element out T Element end STACKS Figure 148 Ada Specification Unit for State Constrained Operations without tasking Copyright 1995 96 by HOOD Users Group page 173 page 174 HOOD USER MANUAL 1 0 by HUM Working Group OUI When comparing to the standard generation scheme ones sees that the additional code to call the OBCS entries has disappeared in the specification unit Instead we have now to reference an ad ditional package named OSTM Object State Machine holding the code supporting the state transition diagram as defined in Appendix A3 2 of present document gives a sample code for the OSTM code implementing the state transition diagram defining the behaviour of the Object as defined in Figure 140 with TEXT_IO USED OBJECTS with OSTM acces to code handling FSM with EXCEPTIONS interface for exceptions package body STACKS is procedure PUSH STACK in out T STACK Element in T Element is begin additional HEADER code to the OPCS body code to hanlde state conditions FSM FIRE STACKS PUSH execution reguest for PUSH exception when X UNW gt EXCEPTIONS LOG appel FSM FIRE STACK PUSH X UNW logg in an file
130. TACK MSG OPERATION PUSH MSG CNSTRNT HSER MSG INFO Item ClientObcs insert MSG insert in request queue MSG ClientObcs remove remove return IPCMSG if not MSG X OK then EXCEPTIONS raise MSG X raise exception according to Xvalue else EXCEPTIONS LOG STACK PUSH ER OK return from server end if if not MSG CSTRNT ASER then ClientObcs FREE MSG deallocate MSG and queues end if exception when X_BAD_EXECUTION_REQUEST gt EXCEPTIONS LOG STACK PUSH X BAD EXECUTION REOUEST EXCEPTIONS raise so as to propagated to client when Others gt EXCEPTIONS LOG STACK PUSH Others EXCEPTIONS raise similar code for POP STOP and START and Status procedure start is separate code of state constrained operation are treated as HSER on client side HSER is needed in order to get back the results of FSM firing function Status return T_Status is separate non constrained operation become HSER constrained operations since return parameters must be accessed from the lt OBJECT gt _SERVER code Figure 171 STACKwith protocol constraints without tasking if the request is also TOER then we would insert here a call to TIMER SET delay as well as a TIMER TimeOut call after return MSG ClientObcs remove remove return IPCMSG Copyright 1995 96 by HOOD Users Group page 244 page 245 HOOD USER MANUAL 1 0 HUM 1 0 OO g J A3 2 2 2 STACK with protocol constrained operations
131. TIONS Copyright 1995 96 by HOOD Users Group page 54 HOOD USER MANUAL 1 0 page 55 HUM 1 0 Start Switch_On Switch Off Stop OBJECT Bargraphs TYPES T COLOUR T BARGRAPH T FLASHING T PERCENTAGE OPERATIONS Init Display Set_Colour Flash Switch Off OBJECT Timers Driver TYPES T TIMER OPERATIONS Create Start Delete DATAFLOWS mean value lt Sensors mean value gt Bargraphs colour gt Bargraphs initial freguency gt Timers Driver EXCEPTION FLOWS sensor failure lt Sensors Copyright 1995 96 by HOOD Users Group page 55 Hoo D HOOD USER MANUAL 1 0 D le page 56 by HUM Working Group INTERNALS OBJECTS NONE TYPES TBD CONSTANTS IT IHZ ADDRESS constant Monitor ADDRESS MONITORING FREGOUENCY constant 1 TBD OPERATIONS Is Value out of Range TBD EXCEPTIONS TBD DATA MONITORING TIMER Timers Driver T TIMER TBD OBJECT CONTROL STRUCTURE PSEUDO CODE TBD CODE TBD OPERATION CONTROL STRUCTURES OPERATION Start DESCRIPTION This operation initialises the system the alarm the bargraphs the sensors and then creates and starts a timer for it triggers the monitoring every 1 second USED OPERATIONS Timers Driver Create Timers_Driver Start Sensors Start Alarm Start Bargraphs Init PROPAGATED EXCEPTIONSNONE HANDLED EXCEPTIONSNONE PSEUDO CODE TBD CODE TBD END OPERATION Start OPERATION Stop DESCRIPTION This operation stops a
132. TOER e TOER_HSER constraint the client process must resume on time out overrun or on comple tion of operation procedure I OP HSER time out in false is begin TIMER Set Time out Value sets a timer AUTOMATA Set Event OP HSER TOER OP loop if AUTOMATA Event HSER TOER OP then time out overrun event timed out true exit end if if AUTOMATA Event End OP HSER TOER OP then timed out false exit end if end loop TIMER Reset resets timer end I OP HSER Figure 119 I INTERFACE Code for TOER HSER constraint and an associated O OP HSER procedure as for HSER without TOER 2 11 3 2 Requirements for selecting control expression notations In the above section we have outlined an approach where a primary condition for use of a nota tion to express control was its ability to express State transitions Note that a designer needs only to define the behaviour of an object with respect to its internal functional semantics using possibly formal notations the burden of handling execution requests processing can be sup ported through automatic code generation as illustrated below Although use of formal notations would help capture and verify unambiguously the semantics namely by using associated environment and tools it is also fundamental to be able to imple ment this semantics straight down in the code We have found only few notations and languag es supporting such features ESTEREL LUSTRE SIGNAL SDL MCTL
133. T_Element provided by ADT_ELEMENT Copyright 1995 96 by HOOD Users Group page 161 page 162 HOOD USER MANUAL 1 0 by HUM Working Group D ed INTERNALS hidden part of the object OBJECTS None NO CHILD OBJECTS TYPES type T_Status is BUSY IDLE UNDEFINED definition of provided type to hold the status of the stack code type T_DATA is array integer lt gt of ADT_Element T_Element data structure to hold values of the type DATA TOP integer 1 SIZE integer 100 DATA T_DATA 1 SIZE STATUS T_Status CONSTANTS None no internal constants OPERATIONS None no internal operations OPERATION CONTROL STRUCTURES OPERATION Status return T_Status is OPCS of POP DESCRIPTION Get status of class STACK code USED_OPERATIONS None PROPAGATED_EXCEPTIONS None CODE in Ada begin return STATUS END of opcs STATUS ne OPERATION POP is OPCS of POP DESCRIPTION Remove an Element from the data structure STACK DATA USED_OPERATIONSNone PROPAGATED_EXCEPTIONS X STACK UNDEFINED PSEUDO CODE if the stack is full then raise X FULL else push the element on the stack end if CODE Ada begin if TOP gt 0 then STATUS busy STACK code is BUSY Element STACK DATA TOP TOP TOP 1 STATUS idle STACK code is IDLE else STATUS undefined STACK code UNDEFINED raise X EMPTY impossible case end if END of opcs POP OPERATION PUSH is OPCS of operation PUSH DES
134. This technique allows designers to organize a reuse activity at different level of granularity Copyright 1995 96 by HOOD Users Group page 119 f page 120 HOOD USER MANUAL 1 0 by HUM Working Group 7 Architectural Design Figure 89 Mixed Approach This mixed approach imposes some constraints in the development process First of all the previous phases reguirements analysis have to be modified in order to provide two types of information as usual the general reguirements of the system as a whole in order to achieve the architectural design but also another analysis of these reguirements in order to iden tify the low level objects constituting the environment of the system Note that the integration step can be tricky It is recommended that the architectural design team has a correct idea of what it can get from the reusable libraries and on the other hand even through reusable components should be created as independent as possible it is preferable that the team in charge of it has a correct understanding of the context where they will be used 2 10 3 GENERAL GUIDELINES This section gives general guidelines for producing good HOOD design i e designs encour aging reuse and making evolution easier It is a hard work to give a complete list of all the advice that can help a designer in charge of building a highly reusable and evolutionary software It is even harder to find a good way of pre s
135. UAL 1 0 HUM 1 0 DESCRIPTION This operation initializes the hardware bargraphs Bargraphs are switched on in green colour without flashing and with a null value USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION lnit OPERATION Display BARGRAPH inT BARGRAPH VALUE inT PERCENTAGE DESCRIPTION This operation sets the input percentage value in the Input Output Descriptor related to the specified bargraph The colour and flashing are the current one l USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Display OPERATION Set Colour BARGRAPH inT BARGRAPH COLOUR in T COLOUR DESCRIPTION This operation displays the bargraph in the specified colour The value and flashing are the current one l USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Set Colour OPERATION Flash BARGRAPH inT BARGRAPH STATUS inT FLASHING DESCRIPTION This operation sets the specified bargraph to flash The colour and the value are the current one l USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTI
136. UMENTATION FOR VERIFICATION AND REVIEWS Documents for reviews may be build by extracting information and texts from ODSs of con cern associated to the model under evaluation at a given date or for a visible point in the project Some HOOD toolsets allow to build document templates and associated outputs may be pro duced in PostScript and or MIF RTF formats and so fed in text processing systems for produc tion of quality documentation according to project documentation standards ESA or DOD2167 Documents for specific development activities Quality control Unit test Definition Pseudo code reviews code reviews may be directly build with a HOOD toolset provided it allows to select relevant ODS and relevant fields for inclusion in a given document 2 3 2 1 Preliminary Design and Detailed Design Documents Preliminary design document will only include ODSs in state PARENT and CHILD Detailed design documentation will at least comprise the set of ODS that went from state CHILD to state TERMINAL In order to simplify documentation management detailed de 9 Copyright 1995 by HOOD User s Group page 83 page 84 HOOD USER MANUAL 1 0 by HUM Working Group oof g J sign documents may also be defined as preliminary design documents where all ODS of state CHILD have been replaced by ODS in state TERMINAL 2 3 2 2 Documentation for Verifications Every document taken as input of a development ac
137. We recommend to navigate horizontally level by level down to a level near the terminal objects At that time it may be suitable to finish by vertical navigation since low level objects have very little to do one with another if they belong to distinct hierarchies Moreover it may be interesting to look globally at subsystems in certain designs subsystems are highly related and it may useful to shift on vertical navigation The analysis of the design tree may also highlight some problems with respect to the quality of the design One may observe for example that some similar objects have been developed several times they could have be shifted to an upper level as common objects or defined as environ ment objects of the current tree Also errors in understanding the HOOD method can be detected such as useless objects or de composition levels d composition of an object into a sole object or into only OP_CONTROL ones Finally examining the structure of a design tree may highlight a very strange partitioning that needs for the least a well justified design decisions Copyright 1995 96 by HOOD Users Group page 197 page 198 I HOOD USER MANUAL 1 0 by HUM Working Group a De 3 4 4 4 ODSs Readings When reading an ODS some simple rules may be applied e ODS analysis should be done tree by tree e the evaluation should start at level 0 e an evaluation should first check the implementation of a parent spec
138. a reusable component exception handling must be done carefully and seriously It is generally not possible to handle exceptions internally because the environment may vary a lot from one case to another especially when it occurs during the evaluation of a formal operation So exceptions have to be propagated But before propagating the exceptions designers must be sure that the object is left in a correct state Figure 94 shows how to handle an exception in order the regenerate a correct state before propagating the error OBJECT PRINTABLE STACK is CLASS PASSIVE FORMAL PARAMETERS TYPES Items is limited private CONSTANTS SIZE Integer OPERATIONS Put Item in Items PROVIDED INTERFACE OPERATIONS Push Item in Items Pop Item out Items Print EXCEPTIONS X Stack full INTERNALS TYPES Stack Range is Integer range 1 SIZE Stack is array Integer range lt gt of Items DATA Top Integer 0 The_Stack Stack Stack_Range OPERATION CONTROL STRUCTURES OPERATION Print is PROPAGATED EXCEPTIONS others all the exceptions raised during the formal operation Put are propagated CODE begin begin Put The Stack i exception when others gt COME BACK TO A CORRECT STATE raise propagation outside end Figure 94 A generic stack providing a print operation Copyright 1995 96 by HOOD Users Group page 125 page 126 i HOOD USER MANUAL 1 0 by HUM Working Group 7 JS 2 10 3 2 c Adaptabil
139. ach of them requires particular procedures as detailed in sections below Copyright 1995 96 by HOOD Users Group page 187 page 188 I HOOD USER MANUAL 1 0 by HUM Working Group a Ded 3 2 2 1 Maintaining Code definition within the ODS When the development is terminating end of integration or unit testing and before putting the product under configuration management and before each design modification e Generate code from ODSs with the HOOD toolset and save previous code versions e Modify that code only the one associated to ODS internal fields during coding and unit testing using the full power of usual development environment code editors browsers de buggers e Update terminal ODS fields from achieved actual target code Such update requires using particular sofwatre which can defined using UNIX tools such as diff and sed and awk for example using a dedicated software program and commenting rules that would analyze the fianl ized target code recognize code include from ods fields and rewite that code back in the HOOD ODSs database Such a practice was used in several projects using a HOOD tool having an simple ODS database schema based on UNIX file system e In case target code modificationswould have impacted the design architecture two updates must be performed one before the other according to the scope of the modifications updating the architecture by updateing the ODS provided fields u
140. ade enormous progress in this fields Copyright 1995 96 by HOOD Users Group page 157 page 158 j HOOD USER MANUAL 1 0 by HUM Working Group a De figuration shall be generated e HOOD objects modelling environmental software shall have naming rules compatible with the code identification or interface of the real code as provided by third parties For example all references to standard packages provided by the Ada development environ ments must enforce the naming associated to identification of provided services Naming of TEXT IO is standard but not the attributes of SYSTEM e When modelling OS interfaces the HOOD naming scheme shall be the one of the existing interface library e g SYSTEM_CALLS 2 12 4 OBJECT ORIENTED LANGUAGE TARGETS OOPL languages can be introduced smoothly into current HOOD3 1 definition HOOD can in tegrate OOP designs and implementations with minor extensions In the following we first present how to use OOP with current HOOD definition and then the extension that has been pro posed to the HTG for HOOD4 definition 2 12 4 1 Designing for OOPL implementation HOOD3 1 HOOD may first been used as a software partitioning tool defining module interfaces These modules may define class interfaces and their implementation and may be directly coded using target OOPL e g C or Eiffel These classes are seen as TYPES by other HOOD clients ob jects which declare DATA INSTANCES of that classes types
141. aking use of the VMS inter process mechanism to implement protocol constraints attached to the VN OS processes e explicit the use of theses mechanisms in order to better control these resources and adapt code generation of allocated HOOD objects onto VNs to effectively use these mechanisms e g if a mailbox MB was defined two objects may communicate data through HSER by MB protocol constrained operations PROJECT Figure 70 Explicit inter VN communications Copyright 1995 by HOOD User s Group page 93 page 94 HOOD USER MANUAL 1 0 by HUM Working Group oof JD 2 4 3 2 Implementing INTER VNs communications The implementation principle inter VN OS processes communication is based on leaving state constraints implementation always within the server process executing a constrained operation Hence the code structure for a VN becomes V VN Name ASER by host OS gt ej a Inter Vn dataflows Remote VN2 Start Server Stop Server Message In tart S ASER by hot OS oo Stop Server ASER by Communication proto Zp Message In P InterVn Messages parameters lt gt Allocated Objects Remote_call_Mesgages R Return Messag CE ADT GUEUE Figure 71 Implementation of a VN The figure above shows that all allocated objects that required remote operations should in fact require a VNCS Message_in operation that
142. al design when applying the mixed bottom up amp top down approach previously presented Advice 7 Define the most obvious reusable parts as independent designs or classes Comments The mixed bottom up amp top down approach leads to split designs where reusable parts are designed independently allowing a relatively low number of levels as said in advice 6 2 10 3 2 Classified guidelines for reuse and evolution This section presents advice for professional HOOD designers This advice is intended to enforce the potential reuse of the object being designed It is grouped by themes e understanding and clarity how to follow a good naming strategy robustness how to design objects that can be used even under unexpected conditions e Adaptability how to design objects so that evolutions are easy and as localized as possible Some of the following advice is inspired by a guide for Professional Ada Programmers and Adapted to the HOOD context 2 10 3 2 a Understanding and Clarity Advice 8 Select the least restrictive names possible for the reusable objects and their identi fiers Comments nobody really knows the context of future reuse Advice9 Reserve the best name for the Instance Object and the second best name for the Class itself Comments When there is an obvious choice for a simple and clear name for the reusable object it is a good idea to keep this name for the instance choosing a longer more descriptive name for the cl
143. al model comprising a MMI object an APPLICATION object and an DBMS_IF object which exchange data Those data should be implemented as instances of ADTs and defined in abstract data type support ob jects according to principles of section 2 1 above 2 7 1 PARALLEL DEVELOPMENT OF INFORMATION SYSTEMS The separation between these three kinds of components can be formally expressed with HOOD in the initial model allows to develop in parallel e the applicative part through HOOD decomposition see figure 5 3 2 below the MMI part according to the principles outlined above see section 3 5 2 above e the interface to the DBMS where several cases have to be handled only informal descriptions upon a information data model have been established in requirement analysis The formalization of associated data structures must be performed during the HOOD design by means of E_R models typing features of the target lan guage and or through HADT objects a formal conceptual data model has been established and verified the model has been captured using a tool and or notation such as Entity_Relationship E_R or OMT formal ism The use of appropriate tools may provide for automatic generation of software for access and management of the associated implementation model in terms of modules as implementations of abstract data types Otherwise the associated software can also be developed using HADT objects Incase a relational DBMS
144. an implementation limit The X_UnderF low exception is raised when the user tries to pop an empty stack which is clearly an error in the implemented algorithm This exception can be useful during the debugging phase but has no more interest in the final system where this error is not likely to appear Copyright 1995 by HOOD User s Group page 63 page 64 HOOD USER MANUAL 1 0 by HUM Working Group Anyway it could be still better not to use exceptions except for predefined exceptions In the above example a control parameter could be used for pop and push operations as a return parameter This is a typical example of avoiding using exceptions An alternative to the bounded stack with no exception is given in figure 40 OBJECT UNBOUNDED_STACK is ACTIVE DESCRIPTION The stack is now unbounded that is to say the constant MAX_STACK_SIZE disappears as well as the X_OverFlow exception PROVIDED_INTERFACE CONSTANTS none OPERATIONS Push Item in Integer Pop Item out Integer is Empty return Boolean is_on_the_Top return Integer EXCEPTIONS none OBJECT_CONTROL_STRUCTURE DESCRIPTION Pop is constrained and protected by a guard condition so that it blocks a client when this one tries to pop an empty stack Figure 40 An alternative to the previous stack The next point concerns the provided operations as it is defined the interface is very small and in particular there is no access function i e there i
145. an object that encapsu late the definition of the type and associated operations Such objects are just normal HOOD ob jects encapsulating all what is related to an abstract data or process type implementation and in order to distinguish them from non abstract data type support ones 3we shall in the following refer to such objects as HADT HOOD Abstract Data Type objects 2 1 1 1 Object Abstraction There are two ways for capturing abstractions Abstract Object ADO and Abstract Data Types ADT ADO allows to define one and only one object at a time This object has an internal state which is represented by internal data This data is not directly accessible by the user of the object it is hidden as stated in the previous section but it can be manipulated in a correct way thanks to the provided operations Note that HOOD graphical view only shows the provided operations see figure 38 the rest of the provided interface types constants and exceptions are only appearing in the textual ODS see figure 39 may not the best ones but good ones 2 whether these ADTS belong to an inheritance hierarchy is rather a detailed design implementation aspect 3 sorry not everything in a system can be modelled as an abstract data or process type implementation Copyright 1995 by HOOD User s Group page 62 page 63 HOOD USER MANUAL 1 0 HUM 1 0 Push ltem in Integer Pop Item out Integer Figure 38 HOOD Diagram
146. and the scope of that verification 3 4 4 3 b System_configuration A root object is defined by its interface with its environment The latter should itself be defined as a partition of environment objects in the system_configuration Such environment objects may themselves be hierarchies This allows e to factor the objects commons to several hierarchies as objects environment hierarchies common software environmental software preexisting to the system to design are thus modelled and integrated in the HOOD model e represent the different subsystem of a subsystem at homogeneous abstraction levels through different hierarchies a hierarchy representing a view point being selected other related entities are defined as environment objects hierarchies It is thus important to start the analysis and review of a design by the system configuration It allows a first understanding of the partitioning of an architecture of system and of its environe ment The system to design being itself described through several hierarchies 3 4 4 3 c The Design Tree For each hierarchy of objects or classes the design tree represents the break down of the root ob ject in child objects on a variable number of decomposition levels The analysis of the tree structure gives thus a global view point on an architecture A design reviewer shall always have in mind the design tree in order to follow its own navigation philosophy
147. arm off If the hard ware alarm is yet started and all the other software alarms are unset the hardware alarm is stopped e Stop switches the hardware alarm off 1 5 2 4 c HOOD DIAGRAM of EMS DECOMPOSITION H3 4 EMS ASER_by_IT start push button ASER_by_IT stop push button initial_frequency ASER_by_IT J z start push button ASER by IT E Timers ASER b pian i ucan_value s stop push button sensor failure Stop colour ASER by IT ack push button Acknowledge ASER_by_IT Timer_10Hz Set_Colour Flash Switch Off ASER by IT ack push button Start Acknowledge data in Switch On f Switch_Off malfunction malfunction Stop E Input Output_Driver Figure 32 EMS HOOD DIAGRAM H3 4 Copyright 1995 96 by HOOD Users Group page 49 page 50 00 j HOOD USER MANUAL 1 0 by HUM Working Group F I 9 1 5 2 4 d Justification of Design Decisions H3 5 Object BARGRAPHS implements the display functional constraints It is able to display addi tional values Object ALARM implements the interface with the alarm system Any change in the alarm system will only affect the alarm object Object SENSORS handles the acquisition function it is designed so as to be able to handle ad ditional sensors Object CTRL_EMS handles initialisation and stop of timers interrupts as well as push button It 1 5 2 4 e Grouping Operations k Objects H3 3 OBJECTS OPERATIONS COMMENTS
148. art initializes the hardware sensors e Sample is in charge of the Sensors sampling It gets the current values of each hardware sen sor and stores them into an internal database e Acquire returns the mean of the ten last stored values of a sensor It returns a Copyright 1995 96 by HOOD Users Group page 48 page 49 P 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 I 9 SENSOR FAILURE exception in case of hardware sensor problem e Stop stops the hardware sensors Object BARGRAPHS e Init initializes the hardware bargraphs Bargraphs are switched on in green colour without flashing and with a null value e Display displays the input percentage value in the corresponding hardware bargraph The colour and the flashing are not modified e Set_Colour sets the corresponding hardware bargraph in the specified colour The displayed value and the flashing are not modified e Flash allows to flash the corresponding hardware bargraph The colour and the displayed value are not modified e Switch_Off switches the hardware bargraphs off Object ALARM e Start switches the hardware alarm and the software alarms off e Acknowledge stops the hardware alarm without unset the set software alarms e Switch_On switched the specified software alarm on If this alarm was not yet set the hard ware alarm is started if it was not In the other cases nothing is modified e Switch_Off The Switch Off operation switched the specified software al
149. ary to perform a succession of basic design steps to build the whole HDT root OBJECT system to design OBJECT G OBJECT H OBJECT I OBJECT J OBJECT K Figure 22 HOOD Design Tree as decomposed from the ROOT object Copyright 1995 96 by HOOD Users Group page 22 page 23 P 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 a De 1 3 1 1 The Basic Design Step Originally inspired from OOD techniques BERARD85 BOO86 BERARD85 The basic de sign step allows to decompose a well defined object in term of provided and required services behaviour and functions into children It comprises a set of elementary activities allowing to continuously transform an object from its definition up to its implementation Some results of those activities textual and or graphical pieces will later be assembled to setup ODS and design documents The basic design step activities are structured according to life cycle phases The method discussed hereafter will not find a design solution but will help the designer to build the best one if any according to project constraints The basic design step consists in a set of initially consecutive and different activities e Activity 1 Definition and Analysis of the Problem This activity consists in well understand ing the requirements before starting the design e Activity 2 Elaboration of an Informal Solution Strategy This activity consists in describing how the system is w
150. as supported more than thirteen projects using HOOD for on board and ground systems using mainly Ada and C langages from the training to the design and implemen tation within toolsets He is now an active member of the HOOD TECHNICAL GROUP Copyright 1995 96 by HOOD Users Group page viii page ix 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 a De OBSERVATION REPORTS eso esse oteseuesecate V ACKNOWLEDGMENTS s ve ees esses eevee VH 1 GETTING STARTED 1 1 1 GENERAL PRESENTATION cee ee eee eee l 1 1 1 History and Objectives 152 435 ats mine asad ek ese Me ee klon ete ER k no 60 1 1 1 2 HOOD in the development activities 1 1 1 3 BASIC CONCEPT dct betes tae heehee de tab gat body abe talented eases 2 1 131 HOOD Objects or iae 6 ei 6 se wien vs ones Be bd de Pew ere bee Nees 3 1 1 3 2 Control Structures sesane aaas a ses 5 1 1 3 3 The Include relationship 6 1 1 3 4 Types Data and Attributes cece cece ce cee cece ss 7 11635 Class Objects essees bod rise sans Din de dS tare sp lire l gee da t stare es bt 7 1 1 3 6 Virtual Node Objects 4 44 4 eee e eens 8 1 14 TEXTUAL FORMALIM 0 cece ccc cent beeen eneene 8 1 1 5 An ODS Illustration the STACK Object 11 1 1 6 From Architecture to Target Implementation 15 1 1
151. ass Thus GENERIC_STACK is a better name than STACK for the class because it leaves the simplest name STACK available to be used for an instantiation Advice 10 Do not use any abbreviations in reusable objects and their identifiers Comments If the object is really reusable nobody can ensure that an abbreviation makes sense in any context of future reuse 2 10 3 2 b Robustness Advice 11 Use symbolic constants to allow multiple dependencies to be linked to a small number of symbols Copyright 1995 96 by HOOD Users Group page 122 page 123 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 Comments The evolution process often implies small changes in dependencies The possibility to map the new dependencies just by changing few constants greatly improves the ease of reuse and greatly reduces the number of opportunities for errors Example Figure 90 is an example of using constants Some of the symbols those which are likely to evolve and thus have to be changed in future systems may be declared and defined in the provided interface The other ones may only be declared in the provided interface and defined in the internals HOOD gives this possibility to enforce information hiding at the design level When implementing such a design you may or may not have a direct mapping depending on the target language you use For example Ada gives the possibility to define private types even if it forces the definition to be in the spec
152. ate the data of the type are still vague create de lete update but this is not a problem at this stage When the refinement of objects identified in steps 2 and 3 is performed new operations on the data will be found and the provided interface of the HADT object will then be updated in parallel g Resume the refinement of objects identified in 2 and 3 following the same principles un til they can be directly coded and always trying to identify as much HADT objects as possi ble h Refine each HADT object unless it is already terminal by applying step 2 and 3 and again identify new objects exchanging data and possibly new HADT ones i Document target language ODS fields or resume HADT refinement using the specifics of the target language Since HADT objects can be directly implemented or refined into OOP target languages see sec tion 2 12 below for details the HOOD development approach allows thus to combine both a de sign representation target towards flat type structure and object oriented class structure Whereas several methods for identification of classes are based on analysis techniques that were mainly derived from the Entity Relationship model extended with inheritance the HOOD design ap proach leads naturally to the identification of classes from the definition of logical interfaces and applicative abstract data types The resulting structure reflects the top down design trade off par tition of the software r
153. ated to constrained operation into a dedicated target unit e incase of an Ada target this unit is named lt object Name gt OBCS and may implement both execution request and internal state constraints using the Ada tasking semantics e in case of non Ada targets or when a non Ada executive is used the unit lt object Name gt OBCS may implement the operation constraints through calls to a real time library or OS services providing the synchronization mechanisms needed Semaphores mailboxes wait for event or wake up event services NAMEN Representation of a HOOD OBJECT with constrained operations WAARVAAARAAWAAVR RWTANRDBAWARNBWAARMNBWAANMNRBARMNABARDAARAARAARAAAARAAAAAAAAAAAAAAAAAAAAAAAABAAT NAME_SPEC C a b pos eo Required_NAME b m OBCS Implementation REPRESENTATION of associated Implementation of OBCS target code units behaviour through synchronisations on OBCY entries and call to O OS Services services and calls to OPCSs Figure 108 Target Code architecture associated to OBCS and OPCSs Copyright 1995 96 by HOOD Users Group page 141 page 142 i HOOD USER MANUAL 1 0 by HUM Working Group a De Figure 108 gives a block diagram of such a target architecture Target units may represent Ada package specification and body units Note that constrained operations are mapped into OBCS entries and that non constrained operation are mapped directly i
154. ather than a bottom up approach derived from implementation data struc tures Taking into account both the natural client server relationship between objects and classes or thogonal to the composition relationships this approach proves to be a powerful structuring tool is Note that the refinement takes place on several hierarchies at the same time This is one of the most noticeable new feature of HOOD3 1 over the earlier definition HOOD3 0 Copyright 1995 by HOOD User s Group page 72 page 73 HOOD USER MANUAL 1 0 HUM 1 0 oof a JD It appears today for us as the only viable integration support for both modular and full object oriented approaches Furthermore by integrating both abstract data typing and process concepts HOOD3 1 is the software engineering tool of choice supporting the transition from classical de velopment practice into full object oriented one 2 1 3 OTHER GUIDELINES FOR IDENTIFYING OBJECTS Abstraction techniques are the basics for defining objects however as designer s experience goes larger other design patterns can be used for the early definition of a system architecture the top level architecture is defined as a partition of HOOD objects which may abstract e a layered architecture model possibly hierarchically structured or e technological development criteria Furthermore the refinement of the top levels components are constrained by mapping into com munication and implementation mode
155. avour the last HADT object solution that defines a reusable module of high logical cohesion dealing only with message han dling operations code see Figure 50 Copyright 1995 by HOOD User s Group page 69 page 70 HOOD USER MANUAL 1 0 by HUM Working Group PARENT nen nos Message j Infos gt ADT_Message Create Build Extract Op1 Figure 49 HADT object ADT MESSAGE providing a MESSAGE class ADT Message PARENT ASER By Unix Shell Message Message Lser By P1 Message t Infos Message ADT Message Figure 50 ADT object ADT MESSAGE providing a MESSAGE class Copyright 1995 by HOOD User s Group page 70 page 71 HOOD USER MANUAL 1 0 HUM 1 0 2 1 2 THE HOOD DESIGN PROCESS AS SEVEN DESIGN RULES The HOOD decomposition approach may eventually be summarized into seven design rules where the system to design is first represented as an object related to its environment and then broken down into objects according to three refinement lines as represented in Figure 51 below ASER By Unix Shell Message MODULAR REFINEMENT V Figure 51 HOOD Method of decomposition and refinement e modular decomposition line this refinement line tries to find a modular structure in terms of object component exchanging data For each level of parent child decomposition one ap plies standard decomposition criteria based on allocation of functions to ob
156. basic type definitions for this project alittle more than the Ada standard package INTERNALS not shown here see below Figure 11 ODS for STACK User Manual Copyright 1995 96 by HOOD Users Group page 12 page 13 HOOD USER MANUAL 1 0 HUM 1 0 F J ke The INTERNALS part of the STACK ODS in Figure 12 shows the declaration of internal types data and OBCS code INTERNALS hidden part of the object OBJECTS None NO CHILD OBJECTS TYPES None no internal types CONSTANTS None no internal constants DATA GARDE ADT_SEM T_SEM FREE exclusion semaphore STATUS T_Status class variable OPERATIONS None no internal operations OBCS PSEUDO_CODE see OBCS STD in figure A2 2 CODE of OBCS task body OBCS is begin loop select choice according to current state see Figure 10 above when Not_EMPTY FULL gt accept POP One_Element out T_Element do OPCS_POP One_Element associated OPCS body end POP or when not FULL gt accept PUSH One_Element in T_Element do OPCS_PUSH One_Element associated OPCS body end PUSH end select end loop end OBCS OPERATION CONTROL STRUCTURES OPERATION STATUS return T_Status is OPCS of POP DESCRIPTION Get status of class STACK code USED_OPERATIONS None PROPAGATED_EXCEPTIONS None PSEUDO_CODE None see code CODE in Ada begin return STATUS END of opcs STATUS see other OPCS on next page Figure 12 ODS for
157. body OBCS is begin loop code OBCS Ada de STACK select choice according to current state of the Stack given as parameter when not IS_EMPTY Stack In T_Stack gt accept POP Stack In Out T_Stack An_Element out T_Element do OPCS_POP Stack An_Element associated OPCS body end POP or when not IS FULL Stack In T Stack gt accept PUSH Stack In Out T_Stack An_Element in T_Element do OPCS PUSH Stack An_Element associated OPCS body end PUSH release caller process end select end loop end OBCS Figure 142 Ada OBCS code for stack In case no STATE constraints were associated to the operations one would simply suppress the guards in the accept statements of the OBCS code In case we would only handle state constrained operations with no HSER protocol then e HOOD3 proposes a standard translation rules as with HSER constraint e this was unacceptable by users because of tasking overhead That is why we have proposed a solution with no ADA tasking using a simple finite state machine as detailed and illus trated in section 2 14 1 and in Appendix A3 1 2 This approach has been adopted by the HTG for the HOOD4 definition which now clearly separates the state constraints from the protocol constraints The ODS below shows the declarations associated to the OBCS and declarations of provided and required types where e the T_STACK is nomore declared private thus illsutrating the T STACK
158. by HUM Working Group F J 9 Activity 6 Analysis of the Solution Activity Inputs Any outputs of the previous phases Activity Critically Review the solution This phase is the key for quality insurance After each decomposition one have to verify the cor rectness of the solution Different activities are foreseen Design Justification Re structure the solution for a best design quality minimize top level objects not used maximize bottom objects highly used maximize consistency and minimize coupling avoid cycles etc Consistency and Completeness Validation Identification of Re usable Objects Identification of Potentially Generic Objects Post Analysis Design Update possible updates in design step M and M 1 Traceability entries this is the right time to define which requirement the current design is fulfilling The designer can thus define entries in a traceability matrix or directly within the ODS Risk analysis in order to identify critical issues in the solution in terms of technical and man agement risks For technical risks concerning failure management detection means and re covery actions have to be studied and the solution have eventually to be updated Activity Outputs Associated texts may be put in the DESCRIPTION ODS fields as informal text Activity 7 Continue the decomposition For each identified child object analyse if it has to be decomposed and then restart the activity 1 I
159. by POP private type T DATA is array integer lt gt of ADT Element T Element type T STACK MAX integer is record DATA T DATA 1 MAX TOP integer 1 SIZE integer MAX STATUS PROJECT_ENV T_Status end record end STACKS Figure 138 Ada specification Unit for passive STACKS 2 13 1 4 b Ada Body Unit with TEXT_IO USED OBJECTS package body STACKS is procedure PUSH STACK in out T STACK Element in T_Element is begin TOP STACK LAST use of Ada Attribute functions if TOP lt STACK RANGE then STACK STATUS busy STACKis used by some one TOP TOP 1 STACK DATA TOP Element put Element STACK STATUS idle STACK code is idle else STACK STATUS undefined STACK code is in undefined state raise X_FULL end if end PUSH procedure POP STACK in out T STACK Element out T_Element is code as entered in the code section of the OPCS similar to that of PUSH seen above end OPCS_POP procedure Status STACK in T STACK return T Status is begin return STACK STATUS end STATUS end STACKS Figure 139 Ada body Unit for passive STACKS The translation rules for the generation of the package body have not changed except that the declaration associatde to the private part of the type have not to appear in the package body 3 Copyright 1995 96 by HOOD Users Group page 166 n page 167 HOOD USER MANUAL 1 0 HUM 1 0 7 So far we hav
160. by_IT constrained operation In order to manage the code associated to window widgets call backs the designer can structure it into objects map ping either all the call back of one widget hierarchy e g a window and all menus and at tached buttons or one specific wet of widgets one HOOD object for an whole editor interface widgets e development of data representation support by defining abstract data type HOOD objects and target language type structures as the data and operations on those data are identified through refinement of APPLICATION and MMI objects The associated formal definition of data allows to synchronize the development progress with the two other lines Copyright 1995 by HOOD User s Group page 105 page 106 HOOD USER MANUAL 1 0 by HUM Working Group OO g J A recommended HOOD development approach suggest the definition of a generic architecture where these interfaces are clearly identified as illustrated in Figure 80 hereafter This architec ture is moreover in line with the so called Seeheim model PFA85 where e presentation software is implemented_by the Windowing INTERFACE and MMI_DATAs objects e Application interface is implemented_by ADT_DATA e DIALOG control is implemented_by DIALOG AUTOMATA objects The Windowing INTERFACE object handle all interactions between APPLICATION and the target WINDOWING system including behavioural execution according to finite state automata modelling the dialogue beha
161. can be conducted in parallel with the development of the dynamic architecture and supporting code In the following we shall illustrate application of such solutions both for full Ada targets and for targets using no Ada tasking e Finally due to the variety of targets and project constraints a number of code generation pragmas are often used to drive the code generation away from standard schemes These pragmas may be useful but care shall be taken to avoid destructuring of the code architecture Copyright 1995 96 by HOOD Users Group page 155 page 156 j HOOD USER MANUAL 1 0 by HUM Working Group a De making it difficult if not impossible to maintain them from HOOD ODS or reverse back into HOOD descriptions 2 12 3 SEQUENTIAL LANGUAGES C C FORTRAN AND ASSEM BLERS 2 12 3 1 Operation Signatures A first convention has been adopted by all toolset builders in using the Ada syntax to describe operations signatures whatever the target language this greatly helped in the SIF definition Standard InterChange Format In order to deal with syntactic specificities such as the C pointer marker or the C reference marker amp we recommend however to use additional associated HOOD type definition and nam ing conventions In order to stress operation attached to an OOP class an additional parameter of type the class may be added in the operation signature the name of this additional parameter is me in HOOD4
162. cedure OPCS PUSH STACK in T_STACK Element out T_Element is separate procedure SerDispatcher Name T_Operation is if we want CLIENT_SERVER code then we would have to suppress the STACK object in the parametre list and declare it here as a local data of the server Local STACK T_STACK local Data for client server code such code generation schema could be triggered by a pragma Local_Element ADT_ELMENT T_ELEMENT begin case Name is when PUSH gt begin ADT MSG READ MSG Local STACK Extract MSG unmarshall parametres ADT MSG READ MSG Local Element Opcs_PUSH Local_STACK Local_Element effective local server execution of the operation MSG X VALUE OK set MSG return MSG info exception when gt MSG X VALUE X s when X UNW gt MSG X VALUE X UNW when others gt EXCEPTIONS LOG SerDispatcher OPCS PUSH Others MSG X VALUE X OTHERS end when POP gt begin ADT MSG READ MSG Local STACK Extract MSG sunmarshall parametres Opcs_POP Local_STACK Local_Element appel effectif ADT MSG WRITE MSG Local lement build MSG marshall parametress MSG X VALUE OK exception when X UNW gt MSG X VALUE X UNW when others gt EXCEPTIONS LOG SerDispatcher OPCS POP Others MSG X VALUE X OTHERS end when others gt EXCEPTIONS LOG OBCS OPCS NAME NO SUCH NAME end case exception when others gt EXCEPTIONS LOG OBCS OPCS NAME Others raise end SerDispatcher Figure 153 Separate part of OB
163. chitectural design method of choice With more than thousand engineers trained in Europe and the availability of several toolsets and companies providing support for using the method HOOD is spreading continuously within the industry The HUG 4 has been set up as an international non profit organisation and is in charge of controlling the method evolution 1 1 2 HOOD IN THE DEVELOPMENT ACTIVITIES HOOD supports identification of a software architecture after requirement analysis activities and leads naturally into detailed design where operations of objects are further designed using a Pro gram Description Language PDL inspired from Ada This detailed design description may be further refined into target language descriptions up to a point where the target code can be gen Copyright 1995 96 by HOOD Users Group page 1 f page 2 j HOOD USER MANUAL 1 0 by HUM Working Group a J te erated The figure hereafter Figure 1 indicates HOOD applicability within a simplified life cycle model Requirement definition Architectural design Detailed design Testing Figure 1 HOOD in the development activities Due to the complexity and duration of activities in a large project HOOD design activities may take place several times in a real development life cycle Traceability with requirement analysis as they are refined followed by refined solutions is still a problem in the management of large projects
164. chy HDTs and CDTs defined in the ADD X lt Root Object gt Design Tree This chapter includes all ODS of terminal objects and OP_control ODS of other objects are of no interest for they are de scribed in the ADD and redundancies between those two documents is not recommended X 1 Design Tree This section gives an overview of the current object decomposition This representation allows to easily identify location of objects For each terminal object or OP_control of the current design tree may by classified in alphabetic order X x lt Object gt ODS OD Sshall not include code fields for OPCS and OBCS Copyright 1995 96 by HOOD Users Group page 186 page 187 j HOOD USER MANUAL 1 0 HUM 1 0 J 9 3 2 MAINTENAINING CONSISTENCY BETWEEN DESIGN AND CODE A particular problem of consistency arises from descriptions elaborated during detailed design phase within the HOOD ODS and the generated target code units which may have to be modified after generation according to debugging and target specific constraints 3 2 1 PROBLEM DEFINITION HOOD3 1 defines ODS CODE FIELDS that are copied into an architecture of target code units skeletons and that are correctly related according to HOOD required and provided interfaces re lationships When target code is generated from a full system configuration two cases may hap pen e the generated code is correct and compiles fine e the generated code is not correct and mus
165. communicates with remote VNS by means of ADT_QUEUE In case code generation is not fully automated in a given toolset or even not implemented the designer would have to explicit every VN in his VN architecture This solution gives full control including over the generated code bases on standard HOOD objects over the design of the com munication mechanism between VNs Copyright 1995 by HOOD User s Group page 94 page 95 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J 2 4 4 EXPRESSING INTER PROCESS COMMUNICATION WITH OPERATION CONSTRAINTS HOOD allows to expresses communication protocols upon service execution of objects by as signing protocol execution constraints to operations HOOD has only defined the following log ical communication protocols e ASER the client process is not suspended at all after a request e HSER the client process is suspended up to the end of requested service execution e LSER the client process is suspended up to the begin of requested service execution e TOER the client wants to know if a request was executed within a time delay e ASER_BY_IT the client is the hardware and this is the way to model interrupts e PROTECTED the client executes in mutual exclusion A designer must notice that these are basically logical communication schemes between two processes and that associated implementations code generated may furthermore use the most common communication mechanisms available from the
166. cond X 8 following actions monitor T acquired mean value Sensors acquire displayed_mean_val Bargraphs display is out of range or Filter is value outof range switch on displayed Bargraphs set colour there is sensor failure Sensor is there sensor fail flashes Bargraphs flash U displayed Bargraphs set colour acknowledged EMS Alarm acknowledge stopped EMS stop stopped Alarm stop stopped Timers Driver stop environment stopped Sensors stop switched off Bargraphs switch off lt switched on Alarm in red light in red light in green light on IT from Ack button on IT from Stop button Copyright 1995 96 by HOOD Users Group page 218 page 219 HOOD USER MANUAL 1 0 HUM 1 0 OO g J A1 3 OTHER ODS OF EMS SYSTEM A1 3 1 OBJECT TIMERS DRIVER IS ENVIRONMENT ACTIVE DESCRIPTION The Timers_Driver manages a set of timers which send cyclic interruptions at a specified address A timer is created with a given frequency and may be started re started or stopped at any moment A timer then may be deleted from the list of available timers IMPLEMENTATION_CONSTRAINTS 255 timers may be consecutively used at a same time l PROVIDED_INTERFACE TYPES T TIMER This type defines a timer T_IT_ADDRESS is SYSTEM ADDRESS This type defines the address of an IT I CONSTANTS NONE OPERATION_SETS NONE OPERATIONS Create TIMER out T TIMER new timer FREOUENCY in POSITIVE cyclic freguency of
167. ct into child objects that exchange data 2 1 3 4 a ADTs Identification and Interface Refinement Once components and their data exchanges have been defined at one level their interfaces can be formally expressed through ADTs see Figure 55 e operations of OBJECTS have parameters that implement dataflows e dataflows may be seen as ADT or instances Hence associated HADT define the data flows Copyright 1995 by HOOD User s Group page 75 page 76 HOOD USER MANUAL 1 0 by HUM Working Group Producer Consumers Figure 55 Principle of specifying Interfaces through ADTs Each dataflow identified in the decomposition may thus itself be implemented e either as an instance of a primitive type directly supported in the target language or e as an instance of an ADT or a basic type of the target language The operations on the data are identified as the client objects are further refined in parallel with the modular refinement When an ADT provided interface is fully defined it can in turn be refined following a mod ular decomposition and or be directly coded in a target language class Figure 54 below summarizes these principles Copyright 1995 by HOOD User s Group page 76 page 77 HOOD USER MANUAL 1 0 HUM 1 0 An ADT implementation is defined as an encapsulation in a HOOD object of operation working on data of that types For best identification of the type on which the operation works the r
168. cts called child objects Provided services are then implemented_by child provided services The implemented_by relationship is represented by a dashed one to one arrow e Child objects are represented as objects within the parent internals and may require services provided by uncles objects which are used by their parents represented as a connection port attached to the parent boundaries Terminal objects are objects that are not further decom posed into child objects e Environment objects are objects that do not belong to the current parent child hierarchy and are represented as uncle objects with an E in left side Parent Object Operation1 a A Operation2 Child ops s s gt un es 7 Operation3 Operation Lp fopes 1 iii opes_2 Operation4 ae Dataflow2 Operation2 Operation3 Figure 5 Representation of Parent Child Uncle and Environment objects Copyright 1995 96 by HOOD Users Group page 6 page 7 I HOOD USER MANUAL 1 0 HUM 1 0 a De 1 1 3 4 Types Data and Attributes Data can only be exchanged between objects which are related by a USE relationship Data may be e either instances of target language types Ada C Fortran or Assemblers e or instances of abstract data types which are defined in another HOOD object from which the type definition is then required Appendix3 gives a detailed illustration of a Stack imple mentation as a HOOD Abstract Data Type HADT object
169. cture principles K package STA TSTACK START STOP PUSH POP STATUS Protocol label Original TStack Class code package body STACK S HRST FSMs Procedure Stop HRST SEMAPHORES pro POH Procedure STATUS Procedure OSTM NNNN TStack class visible to CLIENTS ackage body STACK package body STACK SER ocedure Start Procedure Stdp ocedure Stob Procedure POJP Procedure PGP Procedure PUBH i SH Procedure STATUS Procedure STATUS package ClientOBCS Rare aree package ServerOBCS ClientOBCS eee ees TStack Server Return_Queue Figure 173 Client Server Code structure for class TStack By default there is only one instance of a server_class and lt class gt _server which are located within the TStack Server space Copyright 1995 96 by HOOD Users Group page 247 page 248 HOOD USER MANUAL 1 0 HUM 1 0 OUD A4 ODS CONTENTS ILLUSTRATION A4 1 ODS CONTENT IN STATE CHILD Textual Description of the object Signature of provided operations associated Textual Description Declaration of provided Types and Exceptions associated Textual Description Description of required interface Textual Description of execution constraints and OBCS A4 2 ODS CONTENT IN STATE PARENT Textual Description of the object Signature of provided operations associated Textual Description Declaration of provided Types and Exceptions associated Textual Description Description of requ
170. current system to design and associated environment hierarchies of objects Classes define templates of objects Classes are not objects and cannot be used Thus the class hierarchies Class Design Tree or CDT cannot be defined within the object space The CDT are described in an other space the class object space Following similar description principles the Virtual Node hierarchies VNT are defined in a separated Virtual Node space allowing to define distributable entities memory partitions or heavyweight processes as defined in 3 Finally VNs have to be allocated to physical nodes of the physical architecture This architecture 1s defined as the Physical space A whole project organisation may thus be defined through the HOOD design model see Figure 21 as e A system to design hierarchy HDT associated to the STD which is an emphasised part of the object space and which defines orthogonal client server and composition relationships between objects Instantiation relationships to class objects may exist in this HDT as some objects may be defined as replication of templates e A set of hierarchies of HDTs appearing as environment to the current STD and which are part of the object space and allow to describe formally in an homogeneous framework and notation the external used entities by the STD e A set of class hierarchies or CDTs which are part of the class space and which define param eterized reusable structures a
171. d be defined after a conceptual analysis into a logical functional architecture which is elaborated independently of any non functional and target constraints that is by sup posing an ideal environment An architecture that supports e g structuring principles by grouping code implementing log ically related properties especially by defining components as implementation of abstract data types allows the definition of interfaces that are invariant between some parts say applicative ones and some others say the target support environment This latter may itself be implemented as a set of implementations of abstract data types whose properties define a virtual ideal machine and define formally the separation of the applicative part from the underlying target system independence with respect to environment and or target systems allowing definition of port able components or not dependent from target characteristics One sees that such prop erty can be gained by construction if the architectural principles outlined above have been satisfied The availability of a number of basic components is a condition for the building of larger scope components by using composition mechanisms according to the same architectural principles It is even possible in the future to come to a definition of components with high abstraction and reuse value and still having these three fundamental properties Copyright 1995 96 by HOOD Users Gro
172. d HOOD design Copyright 1995 96 by HOOD Users Group page 152 page 153 0 0 l HOOD USER MANUAL 1 0 HUM 1 0 J 9 211 5 TIMING ESTIMATION AND SCHEDULABILITY ANALYSIS A timing estimation approach may be used to verify the schedulability of an application and to perform CPU time budget analysis via structured annotations within the HOOD design This approach is based on the HRT theory defined in HRT The HRT theory implies an identifi cation of all threads and the definition of their execution constraints in terms of priority dead lines From these information it is possible to analyse the schedulability of the application and or to simulate it The idea is to annotate HOOD objects with timing estimations called worst case execution time WCET schedulability informations e g priority deadlines and to specify operation flow graphs based on nominal and selected critical operational scenarios WCETs may latter on be consolidated by real estimations based on the code inserted within the OPCSs In such a case special features of a compiler may used The operation flowgraphs defined in each objects are consolidated and reduced i e via a max imisation of the different branches depending of the overall operation calling tree These information may used both to generate CPU budgets by extraction of relevant informa tion from the ODSs and to perform schedulabity analysis by extraction and computation of exe cution
173. d development approach The process of defining the work breakdown and the allocation to subcontractors is complex de pends on multiple factors as well as on the industrial organisation defined to support a project However the task definition work will generally include one or several of the following activities e Elaboration of a HOOD initial model Child objects of the top level system define as much subsystems that can be developed in parallel Elaboration of the HOOD initial model may correspond itself to a sub project and depending of the validation effort may consume from 30 to 40 of the project resources Definition of HOOD system_configurations associated to subcontracted objects The development contexts of each subcontractor are defined enforcing whenever needed confi dentiality constraints e Definition of the VN architecture This task is performed either in parallel or in the follow up of the elaboration of the initial model The architecture which is set up and possibly pro totyped should be compliant in terms of performances target system and eventually to a do main application generic model extracted through capitalisation of the know how in the domain e Allocation of objects onto Vns This task allows grouping objects of the initial model ac cording to physical and or organisational constraints e Elaboration of associated technical Requirement Specifications STB eventually extract ing information from
174. d development teams non encapsulating data instances leads to a grouping of common code to manipulate values Copyright 1995 by HOOD User s Group page 65 page 66 HOOD USER MANUAL 1 0 by HUM Working Group Holo j of same type it is an implementation of the object oriented class concept This implemen tation is the preferred one especially when the target language is an object oriented one like C Since data instances values of the type are separated from the execution operation code this implementation must also be used each time the target is to be distributed across several memory partitions or is planned to evolve towards a distributed one When the type can furthermore be parameterized by other more primitive types one can define a HOOD class object or GENERIC whose instantiation will provide the final type 2 1 1 3 a HADT Object encapsulating DATA INSTANCES ADT_STACK CREATE DELETE PUSH POP STATUS Figure 42 Graphical representation of object ADT_STACK The description skeleton of a HOOD object implementing the abstract data type stack could be the following OBJECT ADT_STACK IS PASSIVE DESCRIPTION Implementation of an abstract Data Type STACK and provides all operations to manipulate values of that type creation included IMPLEMENTATION CONSTRAINTS Dynamic heap memory is limited to 1 MB PROVIDED_INTERFACE TYPES T Status is BUSY IDLE UNDEFINED definition of a type T STACK the
175. d evaluates its response Testing and or prototyping are verification by sim ulation e Verification by proofs is making some mathematical proofs on intrinsic properties of a sys tem and or on the behaviour invariants of a system when going toward its final implementa tion These proofs can be done only if one uses a formal language which allows logic calculi These two kinds of verification are complementary ones Simulation is interesting to reveal un expected behaviour of a system clean up bugs and get a better understanding of the system Com pletely proven developments are quite too costly to put into practice but must be planned for critical RT amp E systems The HOOD design process decomposes the design activity into basic design steps which facili tates the implementation of the V amp V activities After each step a validation of the design is pos sible through informal techniques such as inspection walk through and reviews or verification techniques such as design prototyping and design simulation Design validation and verification procedures in HOOD should be based on the separation in time between the external description of an object and the availability of its implementation Two complementary activities are performed e step verification ensuring consistency of one object decomposition e level verification and validation ensuring consistency of a complete level decomposition i e several objects together Step v
176. d of OPCS 620 TON Enabling OPCE 8 cution Figure 109 Extended Execution model for constrained operations Copyright 1995 96 by HOOD Users Group page 142 page 143 0 0 i HOOD USER MANUAL 1 0 HUM 1 0 I 9 Associated target models for the above units can be defined in defining the OBCS as a synchro nous implementation of state transition system associated to a set or I INTERFACE and O INTERFACE procedures for an OBCS automata loop Capture and store EVTS events handling since last step Compute next STATE Execute associated actions execute OPCS emit new signals end loop Figure 110 Automata Code modelling an Object OBCS Such a synchronous approach is supported by notations ESTEREL LUSTRE SIG NAL BERRY88 and can be an implementation approach for other notations and techniques such as SDL and Petri nets e for an I INTERFACE procedure the implementation can be summarized as procedure I OP HSER is call to a constrained operation begin SEMAPHORE lock for exclusive access OBCS_AUTOMATA Set_Event Object_Name_OPname wait for Object Name End OPname wait until End of Execution SEMAPHORE V unlock end I OP Figure 111 Principle ofI INTERFACE procedure Code e for an O INTERFACE procedure the implementation can be summarized as procedure O_OP_HSER is associated to the operation requested begin OPCS_OP_HSER OPCS described in standard HOOD OBCS_AUTOMATA
177. dded systems with distributed and redundant architecture Ph Monseu 2 me con f rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Mul 91 El ments de comparaison entre la m thode HOOD et les langage par objets N Cam J F Muller Conf rence LIANA 1991 Pratique et outils logiciels d aide la conception de syst mes d information Nantes Ponc91 De HOOD a HOOK une m thode de conception uniforme pour ADA et les Bas es de Donn es Orient es Objet P Poncelet M Teisseire A Cavarero S Miran da Rapport K I2S HOOK Janvier 1991 Sch 91 Using the HOOD virtual node concept for the COLUMBUS DMS Software ar chitectural design F Feck B Labreuille J F Muller H Schindler 2 me con f rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Seh 91 Prototyping for the basic management computer in helicopter project Tiger H Sehmer 2 me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Ser 91 Prototyping the CPF Hermes software with Ada R Serrao M Manigrasso 2 me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Tem 91 Some critical comments on HOOD T Tempelmeier 2 me conf rence EU ROSPACE EUROSPACE Ada in Aerospace Rome Novembre 1991 Tra 91 Mise en ceuvre de la m thode HOOD pour la simulation discr te de systemes dis tribu s avec le langage Ada M K Traore Conf rence LIANA 1991 Pratique et outils logiciels d aide la conception de syst mes d information
178. ded interfaces Thus e logical initial architectural models can be expressed and refined according to specific project and target constraints e formal definition of interfaces can be achieved at a high level of abstraction Furthermore the intensive use of this refinement technique allows to serialize the problems at tached to an implementation Separate descriptions can be attached to different level of abstrac tions and the definition of libraries of reusable objects defining a high level abstract interface and different implementations for different targets is supported 2 1 1 6 Deriving HADT objects from DataFlows Figure 48 Figure 49 and illustrate how a complex data message may be defined as a data instance of an abstract data type The associated type MESSAGE is either provided by the BUFFER object or e provided by one of its brother object However such a solution would introduced additional visibility relationships achieving a less structured and maintainable code provided by another HOOD environment object e provided by a HADT object defined as an object of the current hierarchy e provided by a HADT object defined as an environment HADT fully reusable from other hi erarchies and or designs ASER By Unix_Shell Message C7 sa BUFFER LSER By P1 Figure 48 Objects of initial HOOD model exchanging a complex data Message It is clear following software engineering principles that we shall f
179. dentifier size and do not support dotted notation problems may come up about the naming of identifiers The solution is a strict naming policy for HOOD Designs targeting language other than Ada e g Fortran 2 12 3 6 Conventions for C targets C references to HOOD entities by dotted notation can be replaced by an appropriate global name One convention could be to replace each prefix of a dotted chain by ObjectName__ the double avoiding conflicts with a C identifier including already one The code architecture into C modules enforces the following rules e provided and exported resources to client modules especially operation signatures are gen erated in h files e Associated implementation are specified in c files e visibility relationships are implemented through INCLUDE clause that recall required re sources from associated h files The only constraint for the HOOD designer will be to make explicit references to required oper ations in following these conventions at OPCS code level only 2 12 3 7 Code generation for Environments objects The following code generation rules shall apply for environment objects e fora code generation of a HDT no environment code should be generated e Code generation for a full system shall consist in generating code for all HDT or CDT of a system configuration No code associated to Environment object outside of the System con gt FORTRAN 90 is said to have m
180. dure OPCS_POP STACK in out T_STACK Element out T Element is similar to that of PUSH seen above procedure Status STACK in T STACK return T Status is begin return STACK STATUS end STATUS task body OBCS is separate end STACKS end package body Figure 146 Ada Body Unit for Active STACKS Copyright 1995 96 by HOOD Users Group page 171 page 172 HOOD USER MANUAL 1 0 by HUM Working Group F J 9 2 13 2 2 c Separated Units separate STACKS directement extrait de la section OBCS CODE de ODS task body OBCS is begin loop code OBCS Ada de STACK select choice according to current state of the Stack given as parameter when not IS_EMPTY gt accept POP Stack In Out T_stack An_Element out T_Element do OPCS_POP Stack An_Element associated OPCS body end POP release caller thread or when not IS_ FULL gt accept PUSH Stack In Out T_stack An_Element in T_Element do OPCS_PUSH Stack An_Element associated OPCS body end PUSH release caller thread end select end loop end OBCS OBCS body associated to constraint support It can be noted that the OPCS code of the constrained operations has been put into subprograms names OPCS_op_name that have the same interface as the provided operations and which are called from within the OBCS code We are thus also achieving separation between the core functional code of the operations and the behavioural one at code level
181. e 34 f page 35 HOOD USER MANUAL 1 0 HUM 1 0 a D te The phase 2 may become insignificant if an existing OS for example or reused infrastructure real time monitor is used These Full Design Activities are summarized in Figure 26 and more detailed in the following sections Functional constraints 3 Non Functional constraints n ab Logical Architecture Infrastructure Distributi Physical A Figure 26 Full Design Activities applied on the HOOD Architecture Copyright 1995 96 by HOOD Users Group page 35 page 36 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 1 3 3 PHASE 1 LOGICAL ARCHITECTURE This phase is done by the application of HOOD design steps where the decomposition is pro duced as a grouping of HOOD objects directly supporting the system to design functionalities without taking into account the non functional constraints The resulting design defines the main HOOD Design Tree These steps are specification application driven Implementation constraints should not be con sidered during this phase At the end of each design steps similar objects reusable objects serv ers or sub systems are identified Similar objects or reusable objects may be implemented as Classes Each class is then decom posed by the application of HOOD design steps The different Class Design Trees are built Servers or sub systems may be implemented as other r
182. e is modified by executing the modification procedure MPUGC if any extracted from the ODS e Target Code Evolution During coding and unit testing this code may evolve as the developer uses the full features of the development environment Editiors Browsers Compilers Debuggers TestBenche setc However it will have to keep a list of all modifications he made on the generated code e Archive and re setting configuration The developer must now update the target code and possibly associated generation proce dures according to the list of traet code modifications since the last stable state For this he will either manually or using a dedicated tool Update CODE fields of ODSs Update code modification procedures Such procedures may be a set of the batch editor commands such as SED under UNIX environments Regenerate for validation 3 4 3 4 Evolution of the Project Configurations A configuration definition at the end of the detailed design does not seem to be needed the evo lution with respect to the first configuration definition may be performed in terms of added HOOD objects and states transitions from CHILD state to TERMINAL state Moreover experience showed that the state obtained at the end of the detailed design is often not to much stable what has also leaded to the suppression of formal Detailed Design Review We suggest rather to handle a second configuration at the end of the coding and unit testing phase
183. e seen how to translate provided interface reguired interface and internals let us now introduce constraints on the operations PUSH and POP 2 13 2 TERMINAL ACTIVE OBJECT 2 13 2 1 ODS Definition for active object STACKS An active STACKS object implementing an Abstract Data Type for STACK data may be rep resented as in Figure 140 with operations PUSH and POP HSER and STATE constrained thus enforcing e HSER delegation of execution of the operations by a server thread the client resuming its execution only when PUSH or POP are completed by the server e operation PUSH and POP activation conditions according to the behaviour specified in Fig ure 14 g ADT Element PROJECT ENV Figure 140 Graphical representation for the active object Stack The STACKS object behaviour can be described by a state transition diagram as in Figure 141 where transitions are exclusively associated to operation execution last POP POP Figure 141 Object behaviour for STACK Copyright 1995 96 by HOOD Users Group page 167 page 168 P 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group F J 9 The OBCS can be reduced in this case into one Ada task implementing both the HSER protocol between the client thread and the server OBCS thread by means of rendez vous entries and the state transition diagram of Figure 142 by means of guards computed from the state of the ob ject The associated Ada code could be task
184. e syst mes d information Nantes BD9 1a La d marche HOOD au CNES B Delatte Conf rence LIANA 1991 Pratique et outils logiciels d aide a la conception de syst mes d information Nantes BD91b Experimenting Reuse in French Aerospace Industry B Delatte 7M Heitz 2 me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Bea 91 Practical application of the rate monotonic scheduling theory with Ada J Beau fays Ph Bocquillon Th Dubois E Germeyn H Gilman E Snyers 2 me con f rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Bir 91 EASAMS Arianes on board software experience S A Birnie 2 me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Car 91 Unifying the concepts of HOOD with Object Oriented Programming A R Car michael 28me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Deb 91 Description d un g n rateur Ada d objets HyperHood Debceuf Gatineau Con f rence LIANA 1991 Pratique et outils logiciels d aide a la conception de sys t mes d information Nantes Do 91 A new approach to HOOD A link between the design and the implementation T N Do 2 me conf rence EUROSPACE Ada in Aerospace Rome Novembre 1991 Dona 91 Experience in using an object oriented method and Ada for the development of a Flight Management System JDONAGHY EUROCONTROD Object Orient ed Software Engineering Conference Campus THOMSON PARIS sept 1991 Habri 91 la
185. e take the STACK object example for illustrating the associated target code in Ada95 STACK has operations PUSH and POP HSER constrained and operation STOP state and ASER constrained and operation START only state constrained semantically correct only when the behaviour expressed in OSTD in Figure 163 is enforced 4 Any suggestion that works reliably both in ADA and c and for both objects and classes very well come 5 Target ADA units are represented as squared boxes with its kind and name represented in the top and required units represen tented as attached small boxes 6 Translation into C is straight forward since we do not use here any tasking feature As thread supporting UNIX targets are available translation from ADA95to C would also become straight Copyright 1995 96 by HOOD Users Group page 239 page 240 HOOD USER MANUAL 1 0 HUM 1 0 package STACK START STOP PUSH Procedure START rs HRSTESMs HRST FSMs HRST SEMAPHORES package body STACK Procedure OSTM Figure 166 STACK object with state constraints operations with Items use Items visibility on STACK items package STACK is procedure start only state constraint procedure stop procedure PUSH item in T_Item procedure POP Item out T_Item function Status return T_Status end STACK Figure 167 STACK with state constraints code Sample Copyright 1995 96 by HOOD Users Group page 240 page 241
186. e this latter comprises a tasking model thus making the generated code as an executable model on Ada targets but also a specification model for alternative implementations on other targets Specific rules for target systems other than Ada are described in Section 2 12 OBJECTS Ada Units OBJECTS passive package OBJECTS active package OBJECTS active terminal package which includes one or more task unit Operation non constraint procedure or function Operation constraint task entry Exception exception CLASS OBJECTADT package or generic package CLASS OBJECT INSTANCES package instantiation RELATIONSHIPS USE with clauses at the lower level of visibility INCLUDE nested or withed packages Figure 14 Mapping between HOOD and Ada entities 1 1 6 1 General Implementation Rules The code generation rules differ for parent or for terminal objects e for parent objects the associated code is generally a specification unit mapping the provided interface of the object These specifications are implemented using renames Ada clauses onto specification units associated to child terminal objects as illustrated in Figure 16 e for child objects by default are generated as flat Ada packages not included in parent pack ages As a result parent packages with those associated to their children as illustrated in except for type renaming which is not supported in Ada Parent types may be implemented as subtypes and attribute access
187. eceiv er of the operation is indicated by the reserver parameter me allowing to distinguish the main type from other parameters The difference between an ADT implementation and a target language class are the following e an ADT implementation is not necessarily terminal and may be easily broken down into child object possibly defining as many sub ADTs e a class may inherit from another or may be inherited what is not the case of ADT imple mentations e a target language class is defined as a HOOD type However a class may be refined by de fining adding attributes or by extending existing properties through inheritance A class al lows thus complex data structures to be defined step wise leaving possibly provided interface frozen Refinement Figure 56 Combining Modular with ADT Refinement 8 we mean the ADT Copyright 1995 by HOOD User s Group page 77 page 78 HOOD USER MANUAL 1 0 by HUM Working Group oof g J 2 1 3 4 b Target Language Class Refinement through Attribution and Inheritance In the detailed design or coding of HOOD object implementing an HADT three cases may show up e either the HADT is a complex type which operations are groupings of operations on sub types and which can thus be broken down in as many HADT objects e either a subset of these operations lead directly to a target language class identification e either all provided operations of the HADT lead to a target lang
188. ecture and then through the physical one is also not present in the ADD The ADD is seen as a result of this process If need ed intermediate results of the process may be traced in specific technical notes or in the sections allowing to justify particular design choices Redundancies may be produced to ease readability of documentation Those redundancies shall be generated by tools in order to keep consistency For example it could be interesting to print an operation description in all places where that operation is referenced Provided interface of the server object and all Required interfaces of client objects At last even if all objects are not completely identified across the architectural design phase we recommend to build an ADD which includes all objects and hierarchies Thus the ADD may simply be updated after the detailed design phase in order to reflect the final whole system de Otherwise a reader would be confused gt This chapter does not describe parts of the design not covered by the HOOD method such as Database tables description Dy namic architecture etc Copyright 1995 96 by HOOD Users Group page 181 page 182 0 0 l HOOD USER MANUAL 1 0 by HUM Working Group F J 9 sign note also that a DDD should only include pseudo code and internal description of terminal objects The following sections provide standards for each type of document These are only examples which will be customised according to the
189. ed at the top level comprising e a dedicated application part e an MMI Man Machine Interface part e a DataBase or Storage interface part e possibly a rule system interface part Figure 53 gives an example of a technology component decomposition defined for a large in formation system INFORMATION _SYSTEM Start Put_Ops Mngt_Ops Start Put_Ops Get_Ops Sgbd_iteips Mngt_Ops Applis_datp Knowledge Iteihs Sal data A Knowledge_data DBMS Items Applis_data Figure 53 Typical System Information Model partitioned through Technological Components Four objects are associated to four development lines and partition the system into technology component objects that exchange data The latter are again described through HADT objects rep resented as uncle objects and where e the access interface to a datum with all services provided to its clients is formalised by the Copyright 1995 by HOOD User s Group page 74 page 75 HOOD USER MANUAL 1 0 HUM 1 0 oof g J set of operations that manipulated the associated type creation update of a sub field read delete checks etc in a HADT object e further refinement of those HADT may produce objects classes HADTs of less complexity up to terminal specification directly rewritable in a target possibly OO language is based on the graphical extension and refinement rules see below 2 1 3 3 Structuring and Refinement Once a top level
190. ed in order to check the consistency over several basic design steps together This allows early identification of possible common objects in different branches of the design process tree The definition of a design prototype by implementing each current terminal objects allows on another hand to set up a test and pre integration environment for each object with respect to its brothers 2 3 6 DESIGN VERIFICATION IN THE DEVELOPMENT The above validation procedures enable efficient distribution of the design and development since e The scope of a given design step is limited to its nearest levels of decomposition according to the parent child relationships Each design steps produces specifications of objects which define as much new problems and can possibly be validated by prototyping against either a behavioural requirement model and or together with their brother s ones against their parent behavioural model e Level validation prototype can be reused as test and pre integration environment for all the objects of a same level i e for all brothers of a same parent Production of validated specifications of both the objects and their test environment 1 e the brothers prototypes allows to subcontract their design and development to other teams Copyright 1995 by HOOD User s Group page 87 page 88 HOOD USER MANUAL 1 0 by HUM Working Group oof JD 2 4 REAL TIME 2 4 1 DEVELOPMENT APPROACHES The classical development ap
191. ed_interface Type T_SHARED is private Create return T SHARED Delete S T SHARED READ S T_SHARED info WRITE S T_SHARED info E ADT_SHARED Figure 65 Representation of shared areas Copyright 1995 by HOOD User s Group page 90 page 91 HOOD USER MANUAL 1 0 HUM 1 0 2 4 2 1 e EVENT An event will be represented as an environment HADT object providing the operations to create delete an event and to set SET or reset RESET or wait for WAITFOR an event SYSTEM PO DESIGN Object ADT EVENT is provided interface Type T EVENT is private Create return T EVENT Delete e T EVENT Set e T EVENT Reset e T EVENT Waitfor e T EVENT E ADT_EVENT Figure 66 Representation of events 2 4 2 2 Establishing a Real Time architecture Let us take an example of a system of a three process system targeted say to the VMS OS A HOOD architecture can be established according to e the allocation of functionalities and activities logically related to a process e process definition depending on efficiency considerations e g fast acquisition process batch data processing asynchronous MMI process asynchronous Database servers etc PROJECT Figure 67 Initial representation of a RT architecture Figure 67 gives an initial representation of a the HOOD architecture as a set three abstract proc ess implementations One sees at once that data flowing between two objects will
192. ee Design Requirement Functional mode Analysis Behavioural mode Behavioural model STD Rene TD Pear nets ELABORATION o textual Solution a SOLUTION Strateg STRATEGY Textual Description of OBJECTS READINGS Revi w8 by gt readers SOLUTION Figure 60 Design Step activities and associated documentation section Figure 60 above summarizes the activities of a basic design step and illustrates the associated documentation sections to be produced and checked We thing that the important things to recall and to enforce by guality assurance are good performance of the H1 activities which allows then to a designer to both integrate the requirements and to outline associated solutions or parts of strategies in its mind Note that the elaboration of H2 and H3 sections are not seguential activities even if associ ated documentation sections are always presented as seguential ones The description of a solution strategy can be produced in parallel and or after an elaboration of a graphical out line and vice versa The refinement of textual descriptions of operations and or objects in section H3 allows to gain a better understanding of the solution and hence and refinement of the earlier solution strategy produced as H2 e the central importance of an author reader cycle at the end of H3 activities At that time a textual and graphical description of the solution is available in a form that is understandable b
193. ee figure 41 Implementation issues discussing the localization of data instances is further dis cussed in section 2 1 1 3 below 4 imagine you want to pop the stack you verify before proceeding that it is not empty but nobody can insure that another task has not emptied the stack in between the call of is_empty and the call of pop Copyright 1995 by HOOD User s Group page 64 page 65 HOOD USER MANUAL 1 0 HUM 1 0 O0 a JD The real objects derived from this definition are data values of the defined ADT They are not graphically represented on the HOOD diagrams But they will appear as part internal data of the terminal HOOD objects using this type As a matter of fact objects encapsulating ADT are useful for defining the low level objects of the problem those which are likely to be found at several places in the decomposition tree and those sufficiently general to be stored in reuse libraries OBJECT STACKS is PASSIVE DESCRIPTION A simple integer stack as an abstract data type IMPLEMENTATION_CONSTRAINTS constraints PROVIDED_INTERFACE TYPES T_Stack is limited private CONSTANTS MAX STACK SIZE constant 100 OPERATIONS Push Stack in out T_Stack Item in Integer Pop Stack in out T_Stack Item out Integer EXCEPTIONS X_OverFlow X_UnderFlow INTERNALS TYPES Stack Range is Integer range 1 MAX_STACK_SIZE Stack_Body is array Stack_Range of Items T_Stack is record Top Integ
194. efined range First the EMS shall be started IMPLEMENTATION_CONSTRAINTS Start Stop and Acknowledge operations are mutually exclusive each of those operations shall wait the end of an other one before to be started PROVIDED_INTERFACE OPERATIONS Start The Start operation starts the EMS The EMS environment will be initialised Stop The Stop operation stops the EMS Acknowledge This operation stops the Alarm for the faults which have switched on it EXCEPTIONS NONE OBJECT_CONTROL_STRUCTURE DESCRIPTION The EMS accepts start stop and acknowledge operations at any time Start is not significant after a start Stop or acknowl edge are not significant after a stop CONSTRAINED_OPERATIONS Start CONSTRAINED_BY ASER_by_IT Start_push button Stop CONSTRAINED_BY ASER_by_IT Stop_push button Acknowledge CONSTRAINED_BY ASER_by_IT Ack_push button REQUIRED_INTERFACE INTERNALS OBJECTS Ctrl_EMS Sensors Bargraphs Alarm OPERATIONS Start IMPLEMENTED BY Ctrl EMS Start Stop IMPLEMENTED BY Ctrl EMS Stop Acknowledge IMPLEMENTED BY Alarm Acknowledge EXCEPTIONS NONE OBJECT CONTROL STRUCTURE IMPLEMENTED BY Ctrl EMS Alarm END OBJECT EMS Copyright 1995 96 by HOOD Users Group page 53 page 54 HOOD USER MANUAL 1 0 by HUM Working Group F J 9 1 5 3 3 TERMINAL CHILD OBJECT CTRL EMS OBJECT Ctrl EMS IS ACTIVE DESCRIPTION This object is the controller of the EMS It starts and stops all the constituents objects of the EMS
195. entifies numerous tasks whose grouping is not obvi ous the VN architecture should only be established after a definition of a logical solution de fined as a set of HOOD objects 2 4 3 1 Establishing a VN architecture Let us take our example of a system of a three VMS process system A HOOD VN architecture can be established according to e the allocation of functionalities and activities logically related to a VN If a logical solution has already be produced activities are allocated to objects and can be mapped into a VN by allocating the objects e the allocation of functionalities which are quite independent of others already mapped into Copyright 1995 by HOOD User s Group page 92 page 93 HOOD USER MANUAL 1 0 HUM 1 0 others VNs this allows to define VNs as work package for parallel developments e VNs definition depending on efficiency considerations e g fast acquisition process batch data processing asynchronous MMI process asynchronous Database servers etc PROJECT Figure 69 initial representation of a VN architecture Figure 69 gives an initial representation of a VN Architecture One sees at once that data flow ing between two VNs will effectively flow through the inter VN communication mechanism which is in our case VMS There are two possibilities for refining the definition of these com munication e leave the code generator for VN do its work and generate appropriate code m
196. enting it One can either provide very general rules that give the spirit of design with reuse or offer a plethora of very precise guidelines well documented and easy to understand The main drawback of the first solution is its difficulty to be applied to a particular case The last solution implies some experience to know where and when to apply a precise guideline and a good mem ory to remember so many rules As these two ways form a well balanced whole both are presented In a first part the very few fundamental rules are expressed They are taken up again completed detailed and exemplified in a second part These guidelines are provided with the following template e advice an advice number e g advice i and a short sentence summarizing the advice Copyright 1995 96 by HOOD Users Group page 120 page 121 j HOOD USER MANUAL 1 0 HUM 1 0 a De e comments detailed comments on the advice including an explanation of why giving the ad vice details on how to apply it e example if necessary an example illustrating the advice 2 10 3 1 General design techniques This section contains the fundamental statements designers must have in mind during all the de sign process Advice 1 Design objects as independent as possible from their context Comments While creating a design designers have in mind the specification of the problem to be solved One of the most common un reusable and anti evolutionary practice consi
197. er 0 Body Stack_Body end record Figure 41 A bounded stack defined as an ADT 2 1 1 3 ADT implementations as HADT objects Two kind of implementations may be developed and are illustrated below e Implementation encapsulating data instances Values of the type This is where the provid ed interface of the module groups all operations manipulating the type including a create operation Figure 42 and Figure 43 illustrate such a module for STACK The provided type T_STACK is not a type able to store full values of that type but simply an identifier of such value in our case a stack object Hence clients of such a module can require this type and may only instantiate identifier values on the type Full type instances are then produced by executing a STACK create operation e Implementation encapsulating types only Such an implementation is directly supported by a number of target languages especially Ada and does not provide a create operation The associated module rather provides a type defining a data structure able to store values of the type Hence clients of such a module can require the type and instantiate full data instances Figure 44 and Figure 45 illustrate such a HADT implementation The impacts of these implementation choices must be clearly expressed e encapsulating data instances allows a strong grouping easing test and integration with non object oriented programming targets and with distribute
198. er than redoing a similar job giving similar results at an extra charge Two parts of the last sentences are of interest e pick up parts of previous designs this implies the possibility to easily isolate parts of a de sign e an area more or less similar the notion of similarity plays a extremely important role for what concerns reuse First let us speak about theses parts that shall be easily separated from their original context and easily integrated in a new one This is one of the definitions of object a part of a software clear ly delimited which provides clear interfaces with the external world The HOOD object orienta tion is the starting point of the whole reuse methodology Second what about similarity It does not mean equality hence it seems clear that even if a cer tain number of objects may be picked up directly and reused as they are it is not the general case and some others should be Adapted to their new context There is mainly two different techniques to achieve this purpose e genericity the object to be reused is generalized and transformed in a template which may be instantiated for each specific context This technique is covered by the Ada generics the C templates the Eiffel parameterized classes and the HOOD3 Classes inheritance the object to be reused does not change but the new Adapted object is defined by means of enhancement of the former It automatically inherits all its pro
199. erface standard pour la gestion des exceptions with ADT MSG Abstract Data Type defining INTER PROCESS MESSAGES package OBCS is separate see sample code below package body OBCS is separate see sample code belown procedure PUSH STACK in out T STACK Element in T_Element is OPCS ER code MSG ADT MSG T MSG local client MSG structure begin ADT MSG create MSG get acces to MSGs MSG SENDER STACK update MSG fields MSG OPERATION PUSH update MSG fields ADT MSG WRITE MSG STACK build MSG according to parameter list OBCS INSERT MSG send in regue4st gueue and wait for operation excution and return of parameters case MSG X VALUE is analysis of return parametre possibly with exceptions when OK gt Extract_MSGs according to parameter lists when others gt EXCEPTIONS Raise MSG X FIELD ne end case if MSG CSTRNT ASER then OBCS FREE MSG lib ration de la queue end if exception when others gt EXCEPTIONS LOG de O OP PUSH Others raise end PUSH procedure POP STACK in out T STACK Element outT_Element is OPCS_ER code code very similar to the one of POP non described here end STACK Figure 151 Ada body code generation with no tasking protocol constraints Copyright 1995 96 by HOOD Users Group page 176 page 177 HOOD USER MANUAL 1 0 HUM 1 0 separate STACK OBCS Sample OBCS Ada code with noTasking with EXCEPTIONS access to EXCEPTIONShandlin
200. erification mainly consist of e checking the object interfaces e checking parent child signatures e tracing the mapping of requirements behavioural models into Object Control Structure de scriptions Copyright 1995 96 by HOOD Users Group page 41 page 42 j HOOD USER MANUAL 1 0 by HUM Working Group a De Level validation is performed in order to check the consistency over several design steps togeth er The definition of a design prototyping by implementing each terminal object allows to set up a test and pre integration environment for each object with respect to its brothers 1 4 5 HOOD AND REUSE Reusability is today a topic of primary practical importance In this area it appears that reusabil ity of design is the most realistic approach since reuse of code is often to much target computers and data management systems dependant The use of HOOD greatly facilitates the software reusing process at the design stage Studies are being conducted in the ESPRIT and EUREKA research programs to enhance the strategy of de sign in that direction and to develop relevant environments Reuse consists of two major activities e design a current system to be reusable in other projects e reuse parts of previous projects during the current system design HOOD is a globally top down process while reuse is globally bottom up So the reuse process is included in the basic design step by the definition of different scenarios for reuse
201. es may how ever be achieved in considering the object as a unit of configuration thus e architectural design is a set of refinement activities by decomposition e detailed design is a set of refinement activities by enrichment of descriptions of termi nal objects using step wise refinement on pseudo code and or code descriptions A parent object is fully defined by its children If all children are specified then the parent is also de fined However the definition of an architectural design review ADR still has to apply to a model where the architectural definition choices have been made and been validated ADR should only be applied to significant HOOD models i e where some validation has been performed Moreover after a ADR more objects may still be added even this leads to an update of the ADD an possibly to another treview of the ADD Figure 156 hereafter illustrates several design trees associated to a HOOD development and a significant one reviewed at ADR A decomposition level Figure 156 HOOD Design trees states in the development life cycle Copyright 1995 96 by HOOD Users Group page 191 page 192 P 00 l HOOD USER MANUAL 1 0 by HUM Working Group F J 9 3 4 2 SUBCONTRACTING As development activities associated to a HOOD development will be spread over several devel opment teams the management of these activities shall be tuned and adapted to the HOOD mod els an
202. es to code handling FSM package STACKs is type T Status is BUSY IDLE UNDEFINED d finition du type T Status type T DATA is array integer lt gt of ADT Element T Element donn es utiles type T STACK MAX integer is record DATA T DATA 1 MAX TOP integer 1 SIZE integer MAX STATUS PROJECT ENV T StatuS end record OPERATIONS procedure STATUS STACK in T_STACK return T Status STATE AND HSER CONSTRAINED OPERATIONS procedure PUSH STACK out T STACK Element in T_Element procedure POP STACK in T_STACK Element out T_Element end STACKS Figure 150 Ada Specification Unit for Constrained Operations without tasking Note that this specification is unchanged with respect to one associated to non constrained oper ations Only the ADA body unit is affected Such translation rules allow to fully e separate the functional code from the behavioural one e develop test and integrate the functional code in parallel with the behavioural one ZOSTM stands for Object State Machine Copyright 1995 96 by HOOD Users Group page 175 page 176 HOOD USER MANUAL 1 0 by HUM Working Group 0 with TEXT IO USED OBJECTS with EXCEPTIONS visibility for exceptions package body STACKS is procedure STATUS STACK in T STACK return T Status is begin return STACK STATUS end STATUS internal package OBCS sp cifigue pour viter conflits de noms avec autres objets actifs with EXCEPTIONS int
203. esign ex choco late does not provide service It is a data coming from the vending machine to the user e identifying verbs All verbs are operations Those operations use and or return data Ex re quires verb allow to define the require operation It returns chocolate data e grouping operations and verbs This task started from the two previous lists of objects and operations gives a structured representation of the strategy and helps completing a graphical description of the solution ex The require operation is provided by the vending ma chine object In certain cases it is difficult to join operations to objects and it could be in teresting to add objects such as controller monitor scheduler to encapsulate those operations e drawing graphical representation of the design This task consists into drawing within the parent object objects identified during this activity with their operations using the HOOD graphical formalism Use links between child objects and potentially uncles or en vironment objects and implemented_by links between parent operations and children oper ations are identified Dataflow or exception flows along the use links should also be identified according to the understanding of the activities functions allocated to the objects 1 Activity Outputs H3 The produced graphical HOOD diagram must be consistent with the ISS text H2 11 This understanding can be gained if the ISS te
204. esign meets the performance requirements The description of this method is divided into 3 parts e description of the different kinds of performance related data which must be inserted into a HOOD design e description of the way performance data can be inserted into a HOOD design e description of the techniques used to annotate with the different kinds of performance data 2 11 4 2 Kinds of performance related data The Figure 123 describes entities used for performance specification design modelling includ ing hardware aspects and performance evaluation together with relationships between these en tities Performance Evaluation elements Performance Design Annotation Requirements Elements Elements Performance Constraint provides inputs for evaluating verification of Design component Duration constrains is modelled in Constraint ai Execution profile Performance Model Design Throughput component Constraint Perf constraints runs on impacts Utilization hardware annotations Rate Constraint hardware Component is modelled in Scenario U is an input of Figure 123 from performance requirements and design elements to performance model Copyright 1995 96 by HOOD Users Group page 149 page 150 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group F I 9 The Figure 123 shows that two different kinds of data have to be inserted into H
205. etely consistent Figure 28 and parts of the system to design mod el The traceability of requirements through the design is much easier as it is made level by level Requirements Design a LET LES LTS v LT IR CE LS i w gt Specification Process Design Process Include Relation TL M ET 2 ZT m a a Figure 28 The different models in the Z life cycle Copyright 1995 96 by HOOD Users Group page 39 f page 40 j HOOD USER MANUAL 1 0 by HUM Working Group a J d 1 4 3 DESIGN TO CODE HOOD provides translation rules which allow to make more easier the design to code mapping specially when the coding language is Ada HOOD does not remove the programming phase but helps the programmer by giving him the possibility to concentrate on local algorithmic and cod ing problems within the scope of well defined Ada units whose the interfaces and the body skel eton are directly derived from the design objects The apparent equivalence of the concepts in the HOOD method and Ada constructs does not im ply passive object and active object are just another word for package and task Indeed objects are implemented by an Ada package but in a very well defined form with precise properties When the coding is not done in Ada specific translation rules must be defined for the target lan guage but the overall approach remains the same
206. eusable object bounded and unbound ed protected and unprotected managed and unmanaged list you are not obliged to bind your new reusable object with one particular form the choice can be delayed until the reuse stage Moreover it is a good way to reduce dependency between objects enabling to reuse in different and unpredictable contexts in the above example only one insert and one remove operations were required on a certain abstract type thus whatever object providing this functionality may be used to instantiate the class even when it has been designed for something absolutely different 2 10 4 2 Using Virtual nodes A feature of HOOD which should be more used is the concept of virtual node A virtual node is a collection of HOOD objects defining a unit of distribution This unit of distri bution is allocated later onto a physical node The activities of a virtual node consists of local operations and communications as well as remote ones with other virtual nodes Copyright 1995 96 by HOOD Users Group page 132 page 133 PSC QU 0 j HOOD USER MANUAL 1 0 HUM 1 0 J d Simulation_Unit A Controller lt gt Manage Real Services 7 Simulation_Application l l l l i gt Real Services P Operator Station Interface gt Operator Station Services i TCP_IP_Interface Send Receive Operato
207. f physical nodes PNS e identification of communication channels and of the associated communication protocols e allocation of VNs to PNs e verification of compatibility between channels and use relation between VNs e performance evaluation e g estimation of communication overload response time and throughputs CPU overload Specific performance evaluation support such as queuing net works temporised Petri nets worst case execution time estimation techniques can be used during that phase Most of the time the physical architecture is imposed In that case this phase consists only in the allocation of VNs to PNs and in the verification of performances constraints Copyright 1995 96 by HOOD Users Group page 37 page 38 j HOOD USER MANUAL 1 0 by HUM Working Group a De 1 4 INTEGRATING HOOD IN THE LIFE_CYCLE ACTIVITIES 1 4 1 OVERVIEW From requirement to design the HOOD basic design step identifies a sub step which is the anal ysis and structuring of the requirements This phase allows to trace the requirements implement ed in the design and leads to the concept of Z life cycle In this life cycle the design starts with a high level specification then each terminal object is specified before a further breakdown is ap plied on the object and so on until the detailed design may be performed on the object From design to code the HOOD textual formalism allows possibly automatic translation into Ada C o
208. f the current object corresponding to the related ODS description part When non terminal object it could be an output of the Statement of the Problem part of the HOOD design step It may also include a synthesis of the requirements covered by that object In that sense it is an output of the Analysis and Structuring of the Requirements Data part of the HOOD design step When non terminal object it may also include particular design principles followed in the decomposition of that object such as portability reusability etc X 3 x 2 Functioning Only for Non Terminal Object This section explains the following graphical description in terms of data handling through operations of the different child objects It is an output of the Informal Solution Strategy part of the HOOD design step X 3 x 3 Graphical Description Only for Non Terminal Object This section gives the HOOD diagram of the current object defining the decomposition of it into child objects X 3 x 4 Justification of Design Choices Only for Non Terminal Object See above 2 6 x 4 For each non decomposed object of the Virtual Node Tree or Environment object of the previous design trees Y lt Object gt Environment Object Y 1 Overview This part explains the reason why that object is external to the system to be designed It may also include a synthesis of the requirements covered by that object Y 2 Object Description This section gives the OD
209. fixes the activity with an H e identify activity outputs as H1 for Problem Definition H2 for Informal Solution Strategy H3 for Formalisation of the Strategy e identify subsections activities as H1 1 H1 2 H3 1 H3 2 etc 5H for HOOD Design Step Copyright 1995 96 by HOOD Users Group page 23 f page 24 I HOOD USER MANUAL 1 0 by HUM Working Group a J te SRD or ODS SRD Requirements Functions SADT SA PROBLEM Behaviour SDL Petri Structures E A DERM Parent ODS visible part Rewritten and completed ELABORATION of an requirements INFORMAL SOLUTION designer point of view STRATEGY Textual Description Textual Description of Operations of Operations FORMALISATION of the STRATEGY Objects List I Operations List First HOOD Diagram sowuTion REFINEMENT Actual Operationsg FORMALISATION Final HOOD Diagram f the SOLUTION k ce J Parent ODS completed SF Children ODSs visible part SOLUTION ANALYSIS Figure 23 The HOOD design activities and associated outputs Activity 1 Problem Definition Activity Inputs A basic design step may start either after a specification phase beginning of the design phase or after a previous design step during the design phase When starting from a specification SRD the designer has to understand and classify require ments functional behavioural structural and interfaces and the
210. ftware to controls sensors and display associated values of a car engine 1 5 2 2 Analysis and Structuring of Requirement Data H1 2 Ji e Analysis and definition of the EMS Environment The EMS software is running on the CPU using an Input Output and a Timers drivers The EMS is defined as an interface to its environment Start Stop Acknowledge are provided operations which are triggered by IT handled by the ADA Real Time Monitor as the driver operator will push the associated buttons The interface to the ADA RTS is represented as two environment objects associated to the TIMER and the I O boards ASER by IT start push button ASER by IT P Start Timers Driver stop push button ee ack push button Acknowledge O Driver l Questions raised and answered during this activities How to take into account the hardware interfaces from push buttons sensor failure Which is the EMS software environment Which is the range for oil fuel and water How to display a fault sensor failure or value out of range How to take into account several sensor failures or several values out of range How to stop the Alarm with Ack push button when fault has disappeared What about an existing Alarm after a start How and When to start and stop the system The Acknowledge shall stop the Alarm for all faults which have set it Copyright 1995 96 by HOOD Users Group page 45 page 46 j HOOD USER MANUAL 1 0
211. g B 1140 BRUSSELS Belgium Tel 32 2 730 46 50 Fax 32 2 726 85 13 e mail hug spacebel be http www spacebel be The HOOD REFERENCE MANUAL Issue 3 1 was developed in 1991 by the HOOD TECHNI CAL GROUP and approved for two years by vote by the HOOD USER GROUP at the Pisa It aly april 3rd 1992 HUG meeting and published by MASSON and PRENTICE HALL in 1993 The HOOD Manual Issue 3 0 has been further developed in 1989 in response to user experience by the HOOD Working Group comprising representatives of ESTEC COLUMBUS and HERMES projects The present document is the HOOD USER S MANUAL and has as goals to illustrate how to use the HOOD method for the design and development of large complex and reliable software The material of this book shows usage of HOOD in various application domains but avoids too much arguing on how the thing is done The authors have tried to leave each part self document ed so that there is no precise rule to read the book and that readers can jump from one chapter to another according to their present needs on information about HOOD usage There is however a general line followed by the contents e chapter one is a summary of the method concepts including some terminology and some HOOD examples and illustrations e chapter two describes the HOOD ideal usage in the ideal project you have time man power and tools It gives advanced hints and techniques on how to produce HOOD designs and models
212. g with QUEUES access to QUEUES handled by the local OS package OBCS is procedure START MAIN procedure started at initialisation procedure INSERT MSG in T MSG procedure INIT POOL MAX integer 10 d faut 10 pending calls procedure ALLOC MSG in T MSG procedure FREE MSG in T MSG end OBCS package body OBCS is type T Pool Status is FREE ALLOCATED local types internal to the OBCS type T Data is array integer lt gt of OUEUES T OUEUE environmental OUEING library type T Pool MAX integer 10 is recordData T Data 1 MAX Status T Pool Status FREE end record POOLMAX constant integer 10 10 pending calls local data R O OUEUES T QUEUE execution request queue POOL T POOL POOLMAX procedure Init pool Max in integer 10 is begin for iin 1 MAX loop QUEUES INITIALIZE Pool DATA 1 Pool status i FREE end loop end init_pool procedure ALLOC MSG in out T MSG is begin for iin 1 POOLMAX loop if Pool Status i FREE then Pool Status i ALLOCATED MSG RTN_Q Pool data i return end loop raise X_OBCS_NOMORE_RTN_QUEUES end ALLOC procedure FREE MSG in T_MSG is FREE a QUEUE begin for iin 1 POOLMAX loop if Pool Data i MSG RTN_Q then Pool Status i FREE return end if end loop raise X_OBCS_FREE_INCONSISTENT end FREE procedure INSERT MSG in T_MSG is insert Requests begin QUEUES Insert R_Q MSG insert in Request QUEUE OBCS ALLOC M
213. g reasons of design decisions scenario and organisation which may be questionable or is not obvious This allows to justify the design choices and to achieve reasons of those choices Activity Outputs Outputs of this activity are a consistent e textual description of the solution scenario e graphical description of the solution organisation e justification of design decisions Copyright 1995 96 by HOOD Users Group page 28 page 29 l HOOD USER MANUAL 1 0 HUM 1 0 J 9 Activity 5 Formalisation of the solution Activity Inputs Once the formalisation of the strategy has been completed the solution is well defined through the textual ISS the objects provided and reguired interfaces identified through the HOOD dia gram the designer can formally capture his solution Activity Detail the solution through ODS The goal of this phase is to achieve a description of the solution with the detailed characteristics of the objects being formalised in the ODS fields The capture of this formal description consists in filling each field of the Object Description Skeleton see Section 1 1 4 above In order to have knowledge of the environment of the ODS to be filled it is important to fill ODS from bot tom objects which does not use other objects to top objects which are not used The designer should e describe the object in terms of what the object does e define constraints operations and describe the OBCS
214. ge OPERATION CONTROL STRUCTURES Only for terminal objects For each OPCS Description Used Operations Operations internal or external used by that operation Exceptions Propagated Exceptions Handled PSEUDO CODE in PDL CODE in target language END lt Object_Name gt Signature syntactic specification of an operation By default it is expressed in Ada syntax what ever target language gt This field is empty for terminal objects These fields provide for definition of implementation of associated structures in terminal objects and for definition of implemented by relationship for non terminal ones 4 This field only exists for terminal objects 5 This field declares the ippleme jed by Jinks of parent operations down to child ones For terminal objects additional internal operations may be declared here in the process of step wise refinement of provided operation control structures 6 i a ane g tomta Esterel temporal Posie and provide tor automatic gener hior of code ce PS Yor mo e det re state Au 7 These subfields are filled for each operation internal or provided ones Figure 8 ODS Outline Copyright 1995 96 by HOOD Users Group page 10 M page 11 HOOD USER MANUAL 1 0 HUM 1 0 J te The different descriptions fields of the ODS allow to capture and refine object properties and can be processed by dedicated toolsets in order to e generate target code units automatically e ge
215. gn Tree Hierarchical Object Oriented Design HOOD Reference Manual HOOD RUN TIME SUPPORT or Virtual Machine Highly Synchronous Execution Request HOOD Technical Group HOOD User Manual HOOD User Group Hardware HOOD Working Group Interrupt Service Routine Loosely Synchronous Execution Request Mutual Exclusion constraint OBject Control Structure Object Description Skeleton Object Oriented Design OPeration Control Structure Observation Report Operating System Copyright 1995 96 by HOOD Users Group page 249 page 250 HOOD USER MANUAL 1 0 HUM 1 0 e OSTD Object State Transition Diagram e OSTM Object State Transition Machine e PDL Program Design Language e RASER Reporting Asynchronous Execution Request e RLSER Reporting Loosely Synchronous Execution Request e SIF Standard Interchange Format e STD State Transition Diagram e TOER Timed Out Execution Request VN Virtual Node e VNT Virtual Node Tree Copyright 1995 96 by HOOD Users Group page 250
216. gt EXCEPTIONS LOG STACK_SER PUSH Others MSG X string OTHERS end of begin if MSG CSTRNT HSERIHSER_TOER then ServerObcs insert MSG insert in return queue end if end PUSH Figure 75 OPCS_SER codefor STACK PUSH RB operation The communication software between the VNs in Figure 72 is encapsulated within a VNCS which is part of each VN This allows to have OPCS ER or OPCS_SER code that abstracts from the specificities of different target OS or communication software Since a VN may be both a server and a Client the VN may be partitioned in at least two sub objects ClientObcs and ServerObcs as illustrated in Figure 76 VNCS 7 MSG parameters ClientVNCS gt insert gt insert remove remove Message in alloc free ao a da Netwrk JT ServerVNCS insert remove Message_in MSG MSG E Ware Communication pana possibly user defined Figure 76 Architecture Principle of the VNCS software Copyright 1995 by HOOD User s Group page 100 page 101 HOOD USER MANUAL 1 0 HUM 1 0 OO g J The operation ClientObcs Insert builds up the IPC MSG Structure especially does the marshal ling converting the parameters structure into streams allocates a RTNQUEUE and puts its identification in the MSG and is blocked on the return MSG by calling RTNQUEUE remove operation Messages incoming through the communication software
217. h eae Ma Gee R TE 40 1 4 4 Tests and Validation sec cog sci as SAA a dS Shs OB aa bs bg HG par labia 40 1 4 4 1 Unit and integration tests ss 40 1 4 4 2 Verification and Validation cece ccc cece cere ses 41 1 4 5 HOOD and Reuse 4 nA pines Sie ts E E dag Sk eh Mee WO Hee case ees gr 42 1 4 6 HOOD and subcontracting 42 1 4 7 Phased Incremental Life Cycle 43 Copyright 1995 96 by HOOD Users Group page ix page x P 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group I 9 1 5 A HOOD EXAMPLE so e eus 0 e 6 winds Opes olej as 1 51 Presentation of the EMS system 45 1 52 EMS Solution ss e203 Ieee tee ka dne tense ited of Re be by E ced ote Dry eo 45 1 5 2 1 Statement of the Problem H1 1 45 1 5 2 2 Analysis and Structuring of Requirement Data H1 2 45 1 5 2 3 Informal Solution Strategy H2 47 1 5 2 4 Formalization of the Strategy H3 48 1 5 2 5 Structuring the design 51 1 5 3 ODS examples of EMS system 52 1 5 3 1 ENVIRONMENT OBJECT Input Output _Driver 52 1 5 3 2 PARENT OBJECT EMS 0000000000000 AEA 53
218. h protocol constrained operations Some projects have used the VN concept to design a system where software hardware and human ac tivities have to contribute In the same way than objects a man or a hardware may provide ser vices in response to requests A VN hierarchy or Virtual Node Tree VNT gives the decomposition of a system into elements providing services and which constitute the whole system Thus a parent VN may be decomposed into child VNs At the lower level a terminal virtual node consists in a system element which may either implemented by software hardware or human actions In case of software the HOOD method allows to present the set of objects which are necessary to build that VN Thus a terminal virtual node implemented by software is decomposed into those objects We say that those objects are allocated to the terminal VN This is not an include relationship but an allocation relationship We can thus say that a terminal virtual node may map an executable a UNIX process for example built after compilation and link of all allocated objects Finally several VNs can be allocated to a physical processor but one terminal VN cannot be dis tributed across several ones 1 1 4 TEXTUAL FORMALIM Each HOOD object is described in an associated Object Description Skeleton ODS which structures its properties into both informal and formal descriptions Formal notations can be checked against informal descriptions and by tools An
219. he SYSTEM_CONFIGURATION must be associated to a given hierarchy of objects hence the SYSTEM_CONFIGURATION is also a configuration item Finally the choice of the granularity of the configuration items of lower granularity than the ODS or not will depend of the constraints and means of a project In all what follows and to simplify we illustrate this principles with the hypothesis of the ODS as the basic unit of configuration 3 4 3 2 Configuration of a Development The ODS is a set of text sections that contain all information needed by the developer including the code One can define specific development states according to two point of views technical and organisational e From the technical point of view the development states correspond to the three states of ODS CHILD state PARENT state and TERMINAL state as defined in section 2 2 4 e From the organisational point of view the states correspond to project milestones the end of the architectural design phase the end of the detailed design phase the end of the coding phase The first configuration of a project may be defined at the end of the architectural design phase it corresponds to the definition and optionally to the prototyping of an initial HOOD model de fining a contractual reference state From this configuration on test specification and plan will be derived as well as traceability activities Such a configuration is defined asone system configurat
220. he operations associated to transitions For each operation appearing on the transitions of the net a procedure EXECUTE B_OP will be defined in the AUTOMATA package associated to the object see Figure 122 below Also for each condition associated to a transition in the net a function returning a boolean must be associated see function Cond inFigure 122 below package AUTOMATA is procedure SET_EVENT procedure reset procedure RUN end OBJET package body AUTOMATA is BO1 BO2 EO1 EOk NATURAL Declaration of net places function Cond return BOOLEAN is Implementation of predicates associated to transitions end Cond procedure EXECUTE B_OP is associated to OP Implementation of operations associated to transitions end Op procedure runis if BO1 0 and and BOn 0 and Cond PETRI NET then OBCS BO1 BO1 1 ses Marking input places BOn BOn 1 EXECUTE B_OP Execution of OPCS EO1 EO1 1 i Marking output places EOk EOk 1 Figure 122 Ada Code generation for PTN Copyright 1995 96 by HOOD Users Group page 148 page 149 i HOOD USER MANUAL 1 0 HUM 1 0 a De 2 11 4 PERFORMANCE EVALUATION 2 11 4 1 Annotating a HOOD design for automatic performance analysis Our purpose is to define a method for inserting performance data into a HOOD design in order to generate a performance model which can be used to check that the proposed d
221. ht 1995 96 by HOOD Users Group page 51 page 52 HOOD USER MANUAL 1 0 by HUM Working Group F I 9 1 5 3 ODS EXAMPLES OF EMS SYSTEM 1 5 3 1 ENVIRONMENT OBJECT Input Output Driver OBJECT Input Output Driver is ENVIRONEMENT PASSIVE DESCRIPTION The Input Output Driver object provides means to exchange information with hardware devices It allows to put or to set information of these devices IMPLEMENTATION CONSTRAINTS NONE PROVIDED INTERFACE CONSTANTS MAX BARGRAPHS NUMBER constant 3 Number of hardware bargraphs managed by the Input Output Driver object MAX SENSORS NUMBER constant 3 Number of hardware sensors managed by the Input Output Driver object MAX ALARMS NUMBER constant 1 Number of hardware alarms managed by the Input Output Driver object TYPES T DEVICE is ALARM BARGRAPH SENSOR The T DEVICE type defines the set of devices which are taken into account by the Input Output Driver T DEVICE STATUS is ON OFF Defines the status of a a device ON the hardware device is running OFF the hardware device is stopped T BARGRAPH COLOUR is RED GREEN This type defines the two different colours of a bargraph T BARGRAPH FLASH STATUS is ON OFF This type defines the two different displaying status of a hardware bargraph T DESCRIPTOR DEVICE T DEVICE is record STATUS T DEVICE STATUS OFF case DEVICE is when BARGRAPH gt NUMBER INTEGER range 1 MAX BARGRAPHS NUMBER 1 VALUE INTEGER
222. i i HOOD USER MANUAL 1 0 by HUM Working Group I 9 About the Authors Bernard Delatte is an engineer in computer science and is responsible for Object Oriented meth ods support at CNES 18 av Edouard Belin 31055 TOULOUSE FRANCE Phone 33 61 27 49 51 Fax 33 61 27 30 84 e mail bdelatte cst cnes fr Bernard joined CNES in 1984 as a software quality assurance engineer on the SPOTI project and then moved onto software engineering Ada and HOOD support activities Bernard is an active member of the HOOD TECHNICAL GROUP and is publisher of the HOOD NEWS letters 2 issues a year He is also involved in introducing OOA methods into space soft ware developments and is conducting research activities on the co operation of OOA methods and HOOD Maurice Heitz is an engineer in energetics and mechanics and is consultant on software engi neering within the CISI GROUP 13 rue Villet 31400 TOULOUSE Phone 33 61 17 66 66 Fax 33 61 17 66 96 e mail heitz cisi cnes fr Since 1983 Maurice developed the company s Ada education programme and was technical manager of several Ada projects for the French Na tional Space Agency and the European Space Agency before working on formal methods within ESPRIT projects He is currently involved in system engineering software engineering research development and training activities Maurice was one of the lead designers for the definition of HOOD and he is now an active mem ber and chairman of
223. iated to each LOGICAL PART and depending on the type of constraints attached to an operation e OPCS_ERcode associated to an execution request for protocol constrained operation e OPCS_HEADER code associated to a protected and or state constrained operation e OPCS_BODY the real functional code of the operation e OPCS FOOTER code associated to a protected constrained e OBCS client part executed code for queuing and execution request and waiting return pa rameters e OBCS server part executed code for dequeing Op requests processing them and return pa rameters Copyright 1995 96 by HOOD Users Group page 233 page 234 HOOD USER MANUAL 1 0 HUM 1 0 Protocol constraint operations p OPCS_ER CLIENT Thread Execution space U OBGSClient OBCSServer Ze constraint operations 7 OPCS HEADER OPCS SER OPCS BODY part A OPCS_ FOOTER SERVER Thread Execution space Figure 160 Suggested Target Code structure for constraint operations A3 1 1 IMPLEMENTING STATE CONSTRAINTS WITH STANDARD ADA Constraints on operations may most of the time be described using a state transition diagram where states are those of the object and transitions only triggered by operation execution The OBCS is then reduced to a correct implementation of the state diagram which is defined as an Ada task according to standard generation rules HRM section 2 13 2 gives a full illustration of the Ada code for a the STAC
224. icated a general process driving the development approach called Overall HOOD Design Process in the following This process describes the approach and activities to perform along the architectural design phase in order to organise the system according to the devel opment constraints of the project sub contracting for example It allows to define several models of the system down to the system configuration This approach is more detailed in Section 1 3 2 below e the basic HOOD Design Process which defines the activities to decompose a given object into children from a top object to all terminal objects and to get thus a HOOD Design Tree HDT or CDT This process is applicable for all objects and classes and is more detailed in Section 1 3 1 below 1 3 1 THE BASIC HOOD DESIGN PROCESS The basic HOOD design process consists in building a HOOD Design Tree HDT or CDT It is globally top down The system to design is first defined as a high level object called root object and then is broken down into several lower level objects up to they can be directly implemented by target language units and environment services As seen in Section 1 2 the system to design can be represented by a HOOD design tree where branches represent parent objects broken in children and leaves represent terminal objects which are no more decomposed The process of decomposing one object into child objects is called the basic design step Thus it is necess
225. ication resource consumption because data are always ex changed through use relations between operations Copyright 1995 96 by HOOD Users Group page 151 page 152 HOOD USER MANUAL 1 0 by HUM Working Group F I 9 2 11 4 5 Building a performance model from an annotated HOOD design The purpose of this chapter is to describe how an annotated HOOD design could be used to build a performance model The main steps of the derivation process are shown on Figure 127 Annotated HOOD Design Annotated Call trees Minimum operation durations Figure 126 Estimating worst case execution time iO mappings List of user defined allocations Logical unit name physical unit name Scenarios List of user defined allocations Operation_name timing_parameter 1 Generic Filtered HDT Performance Model of Software VN_mappings List of Virtual Nodes allocations Virtual_Node_name physical processor VN allocated objects Lists of objects allocated to each Virtual Node Filtered VNT r Virtual_Node_name list of allocated objects list of VN operations implementations by operations of allocated objects VN operations accesses List of VN operations accesses Operation name network name 1 timing parameter activation rate or user thinking time Figure 127 Generation of a performance model from an annotate
226. ides all means to start and stop the hardware sensors l IMPLEMENTATION_CONSTRAINTS Buffering capacity for each sensor is of ten values PROVIDED_INTERFACE TYPES Copyright 1995 96 by HOOD Users Group page 219 OO g J HOOD USER MANUAL 1 0 page 220 HUM 1 0 T_SENSOR is OIL_PRESSURE_SENSOR WATER_TEMPERATURE_SENSOR FUEL LEVEL SENSOR This type defines the types of sensors which are taken into account in this object OPERATIONS Start This operation initializes the hardware sensors Sample This operation is in charge of the Sensors sampling It gets the current values of each hardware sensor and stores them into an internal database Acquire SENSOR in T SENSOR return POSITIVE This operation returns the mean of the ten last stored values of a sensor It returns a SENSOR_FAILURE exception in case of hardware sensor problem l Stop This operation stops the hardware sensors l EXCEPTIONS SENSOR_FAILURE RAISED_BY Acquire OBJECT_CONTROL_STRUCTURE DESCRIPTION The Sensors object accepts to sample as soon as it has been initialized The Sample operation is not significant before a Start or after a Stop l CONSTRAINED_OPERATIONS Sample CONSTRAINED_BY ASER_by_IT Timer_10Hz REQUIRED_INTERFACE OBJECT Input_Output_Driver TYPES T_DEVICE T_DEVICE_STATUS T_DESCRIPTOR CONSTANTS MAX_SENSORS_NUMBER OPERATIONS Get Put EXCEPTIONS MALFUNCTION OBJECT Timer
227. ification part Other target languages such as C pascal Fortran do not offer this possibility But in any case the principle remains the same at design level OBJECT Disk_Driver is ACTIVE DESCRIPTION description IMPLEMENTATION_CONSTRAINTS constraints PROVIDED_INTERFACE TYPES provided amp hidden types SectorRange TrackRange SurfaceRange provided amp visible types Track_Map is array Sector R nge of Surface_Map i k Range of Track Map Disk Map i Surface Range of Surface Map CONSTANTS mber Sectors constant Integer 4 mber Tracks constant Integer 200 mber Surfaces Integer 18 Sector Capacity Integer 4096 Track_Capacity Surface_Capacity Disk_Capacity provided amp visible constants INTERNALS a TYPES provided amp hidden constants SectorRange is range 1 Number Sectors TrackRange is range 1 Number Tracks SurfaceRange is range 1 Number Surfaces CONSTANTS Track Capacity constant Number Sectors Sector Capacity Surface Capacity constant Number Tracks Track Capacity Disk Capacity constant Number Surfaces Surface Capacity Figure 90 Definition of a disk driver and its associate properties Advice 12 Use unconstrained array types for formal parameters and array return value Advice 13 Make the size of the local variables depend on actual parameter size where appro priate Copyright 1995 96 by H
228. ifications into child ob jects e an evaluation shall than trace requirement support child by child It is also recommended to check the REQUIRED_INTERFACE since this allows also to detect inconsistencies in the use of the HOOD method such as e g the call by a parent object of an op eration provided by a child 3 4 4 5 Redundancy Management When reading a HOOD documentation one may have some difficulties due some time to redun dant parts between the descriptions appearing in the parent ODS and the ones appearing in child ODSs Such redundancy may rather add volume to the documentation to read understand or to evaluate One acceptable compromise may be to allow within a child ODS field to make references in stead of copy to a parent ODS field thus avoiding duplicated textual descriptions However such referencing shall not be systematic it should only be allowed for the parent infor mation which is not distributed among several children Moreover it should not be used between several level of decomposition since this would render the reading of a child at level4 very un comfortable Knowing that the information contained in the fields of a parent ODS is generally distributed in some child ODS fields such type of redundancy is unavoidable it is necessary to check its con sistency e If the text elaborated in the parent ODS fields is refined in the child ODS fields and is no more consistent compatible with the parent ones
229. ight 1995 96 by HOOD Users Group page xix page xx I HOOD USER MANUAL 1 0 by HUM Working Group a De Figure 120 Integration based on several concurrent AUTOMATA 000 eee eee 147 Figure 121 Integration based on merge of AUTOMATA eee eee eee eee en 147 Figure 122 Ada Code generation for PIN is 90990 eo eee neon ee eee 148 Figure 123 from performance requirements and design elements to performance model 149 Figure 124 Annotation with performance Constraint 150 Figure 125 Annotation with an execution profile ss 151 Figure 126 Estimating worst case execution time see 152 Figure 127 Generation of a performance model from an annotated HOOD design 152 Figure 128 Timing estimations Analysis of each HOOD object 153 Figure 129 Timing estimations Build overall execution skeleton eeeeeeeeeeeeeeeee eee 154 Figure 130 Example of HOOD annotations for performance and timing estimations 154 Figure 131 Sample code of testing exceptions in client code 156 Figure 132 Graphical representation for the object Stack ss 161 Figure 133 ODS of passive STACK object siennes 162 Figure 134 Ada specification Unit for passive object STACK oo eee eee en 163 Figure 135 Ada body Unit for passive object STACK eee eeee en 163 Figure 136 Graphical
230. ilar objects gt The term class object came out as the OOP terminology was not well established HOOD CLASS object shall not be confused with OOP classes but are templates or generic objects similar to generic Ada packages A HOOD object has always the mean ing of module In order to avoid misunderstanding with OOP terminology the terms class instance should always be used to designate an OOP object instance Copyright 1995 96 by HOOD Users Group page 7 page 8 0 0 j HOOD USER MANUAL 1 0 by HUM Working Group F J 9 A class object is defined as a separate root object top level object of a parent child hierarchy and may itself be decomposed only into objects and or instances of other class objects see Fig ure 6 A_CLASS LIST LIST MNGT _ an object instance of another class TABLE a child object data_out D Oi TEXT_IO Formal_Parameters Figure 6 A class as root object using environment and formal parameters object 1 1 3 6 Virtual Node Objects The Virtual Node VN concept is the extension of the object concept meaning a software mod ule to the system level i e an executable a process a sub system a system The VN defines an indivisible partition of the memory space and software units for distribution Links between objects map procedures calls even though links between VN map communication protocol Communication between VN is only throug
231. ill also be standardised using ef ficient communication standards such as those promised between threads and already available on the most recent UNIX releases Figure 161 gives the HOOD execution model associated to a protocol constrained implementation where e the code executed by the client thread comprises the OPCS_ER see below and the ClientObcsPart which sends a request MSG to the server process and waits for a re turn MSG e the code executed by the server thgread comprises aServerObcsPart which waits for a request MSG and dispatches the request to the as sociated local operation that is the OPCS_SER which executes the effective OPCS body code and returns back a return Copyright 1995 96 by HOOD Users Group page 235 page 236 HOOD USER MANUAL 1 0 HUM 1 0 MSG to the client When the gueuing mechanisms used also supporting distribution this solution can be di rectly used for VN code generation In that case ClientObcs parts may be grouped into a common VNCS module VN Control Structure CLIENT THREAD SPACE SERVER THREAD SPACE OPCS SER 5 parameters receiving TTTI sending gueue gueue ServerObcsPart ClientObcsPart Hope ifoqueues Figure 161 Principle of Code for Protocol onstrained operation support Since such a schema is not yet supported by HOOD tools the code for OPCS_ER OPCS_SER and client part and server parts should be structured in such a way as to isolate the original f
232. in several common areas in the data processing domain These hints are given from a pure technical point of view ignoring any project and support environment constraints e chapter three tries to help HOOD designers trapped in the constraints of a particular context and project It gives advice on how to cope and integrating HOOD techniques within given Copyright 1995 96 by HOOD Users Group page iii page iv 0 0 i HOOD USER MANUAL 1 0 by HUM Working Group F J 9 constraints standards and toolsets This book is not a HOOD study nor a pedagogic manual we hope that despite of the different backgrounds of the readers they will manage to understand the HOOD spirit that the authors have tried to put down along the different sections The current version is a working document intended only to be distributed among HOOD User Group members only It has to be considered as set of technical notes providing a synthesis of the industrial experience of the authors and various contributors A further version will take into account new concepts introduced within the HOOD4 evolution Copyright 1995 96 by HOOD Users Group page iv page v j HOOD USER MANUAL 1 0 HUM 1 0 J 9 OBSERVATION REPORTS For submission of comments for modification or extension to this manual we would appreciate them being sent via e mail to the following address heitz cisi cnes fr If you do not have e mail access please send the comments
233. in the DATA field of their ODS OPCSs are code including call to methods that apply on that HOOD DATA 2 12 4 2 Other Conventions for C Naming conventions for HADT C classes we recommend to adopt a naming schema for classes and types in order to distinguish between classes and types e g the following naming schema has been found useful in several projects e all class names are prefixed by T all type names are prefixed by T_ e all exception names are prefixed by X_ Exceptions support is similar as the one suggested for C 2 12 4 3 Implementation of state constrained operations An OOP class implementing sate constrained operations could be coded with an additional at tribute FSM as an instance of the class TFSM handling a finite state machine for each instance of that class The construction of that class should initialize the machine states according to data describing the allowed state transitions See Appendix A3 2 1 for a full illustration in Ada and note that it would be just a matter of rewriting that code in an OOP language Copyright 1995 96 by HOOD Users Group page 158 page 159 j HOOD USER MANUAL 1 0 HUM 1 0 a De 2 12 4 4 Implementation of protocol constrained operations See Appendix A3 2 2 for a full illustration in Ada of the implementation principles of protocol constrained operation Inter process communication primitives would also have to be provided by means of a RUNTIME library for a give
234. ined operations STACK RB CODE 245 A3 2 2 3 STACK with protocol constrained operations STACK SERVER CODE 246 A3 2 3 Client Server illustration for classes 247 A4 ODS CONTENTS ILLUSTRATION 248 A4 1 ODS CONTENT IN STATE CHILD 248 A4 2 ODS CONTENT IN STATE PARENT 248 A4 3 ODS CONTENT IN STATE TERMINAL 248 A5 ABBREVIATION LIST 249 Copyright 1995 96 by HOOD Users Group page xv page xvi 00 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page xvi page xvii i HOOD USER MANUAL 1 0 HUM 1 0 J 9 LIST of FIGURES Figure HOOD in the development activities ss 2 Figure 2 Classification of the different HOOD Objects 3 Figure 3 Objects providing and requiring services and exchanging information items 4 Figure 4 HOOD Object execution model ss 5 Figure 5 Representation of Parent Child Uncle and Environment objects er 6 Figure 6 A class as root object using environment and formal parameters object 8 Figure 7 Structure of a HOOD Object sise 9 Figure 8 ODS Outline she Rent vas dsou kod ena E E ake us deeds bule EE E nt tentes 10 Figure 9 Graphical representation for the active object Stack 00 ec sessecseeseeseeseceseecsseeeeeeceeenaeaeeees 11 Figure 10 Object behaviour for STAC
235. ing the development process even during the maintenance phase Within a top down approach a small modification in the specification of a high level object may induce a complete redesign of the internal objects As we have seen that both approaches have advantages and drawbacks we suggest an interme diate path between these two opposite ways of thinking see figure 89 Two activities can be led in parallel the first one is in charge of building the architectural design in a traditional top down manner while the second one is in charge of the construction or enhancement of reusable librar ies The first activity shall not overcome a depth of 2 or 3 for big projects levels of decomposition Every object produced in this phase has a good chance to become a non terminal object Thus it can be considered as a good design practice to design them as simple abstract objects For de scribing these objects emphasis shall be put on the H2 Informal Solution Strategy and H3 Formalization of the strategy chapters of the HOOD Chapter Skeleton The HOOD informal graphical description takes all its sense at this level The second activity can lead to the creation of a lot of terminal objects It is important for the feasibility of this phase to rely on a good managing tool for libraries of reusable components However some possibilities of structuring the reusable objects by grouping them into non termi nal objects will be explained later
236. ion bottlenecks objects will be allocated to one or the other processor ac cording to the functions they support and at the same time trying to avoid heavy remote induced dataflow This grouping can be formally stated through the definition of a physical model in terms of HOOD virtual nodes matching the target processors and then allocating objects from the logical model to these VNS Hence the designer gains advantages of auto mated code generation that have as principle not to modify the logical code of allocated ob jects According to the principles summarised above on can identify seven rules to find the objects which are as follows a Start defining the system to design as an interface set of provided and required services to its environment possibly modelled as a partition of environment objects b Define the key objects abstracting invariants of the system Such definition may be done ac cording to c functions allocated to the child objects of the system to design identification of associated dataflows between these objects note that dataflows are related to allocated functions e Define the implementation of the communication and dataflows between these objects and environment objects f For each data previously identified define associated abstract data type as HADT ob jects unless the data can be directly defined as an instance of a type of the target language It may happen that operations that manipul
237. ion defining a set of objects and class hi erarchies and described by e ODSs in state CHILD e ODSs in state PARENT possibly some ODS in state TERMINAL namely those associated to a prototype 3 4 3 3 Configuration Management of Code versus ODS HOOD3 1 integrates in the ODSs CODE description fields which are copied as is in target unit modules When code is generated from the ODS information two cases may take place Copyright 1995 96 by HOOD Users Group page 194 page 195 I HOOD USER MANUAL 1 0 HUM 1 0 a De e code is correct e code is incorrect either because of a bug in the code generator of the HOOD toolsets used either because the developer had to bring modifications in the generated code to adapt it to particular target constraints add of Ada pragmas such as pragma in line SUPPRESS CHECKS representation clauses etc From the feedback of early HOOD projects where there was a separation between ODS and tar get code we think that ODSs must handled in configuration with the target code This can be im plemented by adding modification procedures upon generated code MPUGC Such MPUGCs may be stored as additional description fields of a given ODS pragma HOOD ODS e g as a subset of the IMPLEMENTATION CONSTRAINTS field As a result additional operational constraints are brought to the project e Code generation from the ODS using a standard HOOD toolset For each object generated cod
238. ion of the heavyweight processes or partitions 7 if the hardware architecture was already frozen This representation takes into account efficiency re quirements such as high acquisition rate processes computing time asynchronous be haviours MMI DBMS CENTRAL PROCESSS high priority tasks interfaces to existing systems interrupt driven processes etc configuration phase where grouping and restructuring of VNs is done for allocating them the chosen configuration of heavyweight processes 2 4 2 CURRENT DEVELOPMENT APPROACHES 2 4 2 1 Representing Common Real Time Mechanisms Representing real time mechanisms was often a problem since these mechanisms are not explic it in Ada and are generally used as services provides by real time libraries In order to have an homogeneous representation of these mechanisms whatever the target features we recommend to model them through HADT objects These latter define a logical interface invariant from one target to another and from one project to another Moreover these interfaces may directly map those provided by standard executive service packages such as EXTRA or CIFO proposals 2 4 2 l a Tasks and Cyclic task A task is an implementation of an abstract process type providing start stop create and delete operations Cyclic task may be represented through e either by a ASER_BY_IT cycle duration triggering the main activity operation e either through a looping code that suspends
239. ious projects was adopted by the HOOD User s Group HUG 4 as the method official release see HRM After an evaluation phase on small pilot projects the method was chosen for the COLUMBUS Manned Space and ARIANES programs Since it has been adopted by EUROCOPTER the French NAVY and by several other large projects in aerospace defence transport energy and nuclear applications HOOD is an object based method that supports a modular technology centered on client server and composition relationships where minor emphasis is put on inheritance This is why beside the recent blossoming of Object Oriented methods HOOD has evolved slowly and a new release is only planned to be compatible with Ada95 7 Experience has proven that inheritance in re quirement analysis is not the same as inheritance used for implementation thus there is a need for an intermediate method in design The advantages promised by full inheritance based object oriented methods are currently not balancing the drawbacks of introducing them straight on large scale projects Furthermore we are convinced that industrial use of inheritance will be limited to data modelling and detailed design programming support Today OOP is only made possible through powerful programming and debugging support environments and limited to very small integrated teams HOOD on the other side has been recently worked out to integrate both modular and inheritance programming thus making HOOD the ar
240. ired interface Textual Description of execution constraints and OBCS Declaration of child objects i enfant s Declaration of Type Exception and Operration implementation A4 3 ODS CONTENT IN STATE TERMINAL Textual Description of the object Signature of provided operations associated Textual Description Declaration of provided Types and Exceptions associated Textual Description Description of required interface Textual Description of execution constraints and OBCS Implementation of OBCS Declaration and Implementation of internal Types associated Textual Description Declaration and Implementation of Data associated Textual Description Declaration of internal Ope rations associated Textual Description Impementationof operations provided and internals Copyright 1995 96 by HOOD Users Group page 248 0 0 g J page 249 HOOD USER MANUAL 1 0 HUM 1 0 AS ABBREVIATION LIST e ADT e AM e APSE e ASER e ASCII e BNF e CDT e FSM e ER e FIFO e HDL e HCS e HDT e HOOD e HRM e HRTS e HSER e HTG e HUM e HUG e HW e HWG e ISR e LSER e MTEX e OBCS e ODS e OOD e OPCS e OR e OS Abstract Data Type Abstract Machine Ada Programming Support Environment ASynchronous Execution Request American Standard Code for Interchange of Information Backus Naur Form Class Design Tree Finite State Machine Execution Request First In First Out HOOD Design Language HOOD Chapter Skeleton HOOD Desi
241. ists in building simple components which are supposed to simplify problem definition and then building more sophis ticated components on the top of them until the solution appears as a trivial application of the ultimately developed tools Copyright 1995 96 by HOOD Users Group page 118 page 119 i HOOD USER MANUAL 1 0 HUM 1 0 a De u o o c o 7 a Figure 88 Layered Bottom Up Approach At a first glance the bottom up method may look like risky since nobody can insure that this process actually leads to a correct solution A great amount of time may be spent to develop com plex components that will never or very partially be used during the current project On the other hand as components are developed more or less independently of the current project they are more naturally reusable for new projects Hence after a starting period a great number of low level objects can be picked up from related projects formerly developed As far as we are con cerned this point is very important Another point is to be mentioned The top down approach has been presented as the fastest way to elaborate the architecture of a system provided that clear and unambiguous specifications of the problem have been given Unfortunately this is almost never the case as specifications are often not entirely clarified before the delivery of the project The common case shows the client needs evolving dur
242. it has to be pointed and correct the infor mation in the parent ODS e if the text elaborated in the parent ODS fields refers to the child ODS fields this indicates in general that the documentation of the parent object has been produced after the one of the child ODSs such a documentation should not be accepted since it indicates that the method has generally not be applied in the top down way may be even that the code was produced first the documentation has been purely produced because it was requested but it was for no help in the elaboration of the design and hence we do not need to spend any time in checking it Copyright 1995 96 by HOOD Users Group page 198 page 199 I HOOD USER MANUAL 1 0 HUM 1 0 a De 3 4 4 6 Evaluation Process The general evaluation process follows roughly the three following steps e check consistency of decomposition are parent child descriptions consistent e check traceability have all requirements been taken into account and where e evaluate the design with respect to software engineering quality criteria do we have ae good design According to the background of the reader the way these steps are performed may vary A meth od consultant will primarily check for errors in understanding the method and with regard to soft ware engineering quality criteria The customer will first check out requirements implementation and support and testability Finally quality c
243. iterator handling modules possibly implementing abstract data types which are always present in most software These are components which can be fully mas tered by the reuser and should provide for merely direct selection thanks to their low com plexity However at least in the beginning of reuse due to previous reuse blind development these components when not properly designed as implementation of abstract data types require still too often a real Adaptation effort to make them work in their new use environment e Lessons learned here are that for a component to be reusable it should be designed as an implementation of an ADT Abstract Data Type and possibly built on top of other ADT implementations as the only criteria which reduces significantly Adaptation effort and at the same time increasing testability required environment entities Documentation tests test sets Besides the source code it appeared as important to be able to get access to a component required environment in or der to allow Adaptation Although we could only get code components in our experimenta tion we think this feature as most necessary for making reuse effective 2 10 5 2 How to Do Reusable Practising reuse highlights problems related to e understandibility of potential components tuning work of a selected component within its new working environment Copyright 1995 96 by HOOD Users Group page 134 it page 135 HOOD USER
244. itial models invariant The invariance of an initial HOOD model is obtained through use and include relationship properties the include relationship allows to refine a HOOD model by addition of new child objects leaving their parent external specifications unchanged the use relationship allows to refine the implementation of internals OBCS and OPCs and Types and Data by requiring services provided by Environment objects The consistency between different model descriptions at different levels of details is ensured by the formalization of the ODS into external public specifications and properties which are frozen as soon as the object is identified as a child within its parent internal properties which can be refined without impacting on external specifications and either as in an implementation of a child service or in a target language implemen tation description the ODS documentation concept which integrates the different characteristics of an object within description fields where natural language or more formal notations can be used The ODS into descriptions fields comprising informal textual description parts allowing expression of characteristics allowing the use of informal verification techniques more formal description parts PSEUDO_CODE CODE allowing the use of specific notations to capture formally associated properties code description parts which directly reflect the translation of the properties into
245. ity Advice 20 Minimize the number of objects a reusable object uses Comments A good reusable stable object is used by a lot of other objects but uses as few other objects as possible No object used is perfect but only applies to a limited type of objects Advice 21 Minimize the number of objects using objects that may vary Comments this is similar to the previous advice This is related to the principle of low coupling enforced by the notion of variabilities The objective is to minimize the impact of changes propagating following the USE relationship by minimising the USE relationships to objects which have been identified as potentially variant Example a simulator simulates or is connected to a certain number of satellite sub systems of different types for instance power subsystem attitude and orbit control subsystem One to N specific objects of this type may be present in a Simulation object In that case it is good to minimize the number of objects using this kind of Sub systems objects this avoids changing the Required Interface in the object s using them Advice 22 Provide complete functionality in objects Provide initialization reset and termina tion operations when appropriate Comments This is particularly important when designing an abstraction The essence of Object Based Design is the design of complete abstraction even if it is not required in the current application When possible an abstractio
246. jects and that de fine loosely coupled objects with minimised provided interfaces e abstract data type refinement line this refinement line tries to specify groupings of data ma nipulation operations into associated HADT supporting objects Each dataflow identified in previous line can be implemented as an instance of an abstract data type or a basic type of the target language The operations on the data are identified as the client objects are further refined thus this refinement is performed in parallel with the modular refinement When an HADT object provided interface is fully defined it can in turn be designed following a modular decomposition refinement and ADT refinement e logical to physical refinement line this refinement line is not really a refinement but rather a restructuring of the logical objects into groupings of objects that fit and map into target constraints It corresponds to the distribution phase identified described in section 1 3 5 above For example a grouping of the logical objects is needed when the target system is this figure shows the process for the decomposition of one root object but for large projects this process may be performed in parallel on several root objects Copyright 1995 by HOOD User s Group page 71 page 72 HOOD USER MANUAL 1 0 by HUM Working Group 0 0 g J distributed over two processors or heavyweight processes tasks 3 In order to avoid net work communicat
247. ken for enforcing the state of an object or a class is to raise an exception if the state was not OK for the operation to execute Figure 163 illustrates the associated target pro cedure code associated to a state constrained operation procedure lt State_Constrained_Operation gt is target code structure begin OPCS_HEADER part automatically generated HRTS SEMAPHORE P lt object Name gt seize MUTEX Semaphore HRTS FSMs FIRE operation try to fire operation transition if execution allowed in current state exception BAD_EXECUTION REQUEST is raised end OPCS HEADER OPCS_FOOTER part automatically generated HRTS SEMAPHORE V lt object Name release MUTEX Semaphore end OPCS_FOOTER end Figure 163 State Constraints Implementation Schema A3 2 1 1 STACK OSTD This seems well founded and pragmatic since automatically enforcing a state according to a specification given in an Object State Transition Diagram OSTD as illustrated in Figure 164 could lead to uncontrollable and less understandable code Legend O initial state EXIT state operation execution request Figure 164 OSTD for STACK object gt to abort the operation request 3 see the paper 18 showing the difficulty of enforcing correct state wrt a state specification Copyright 1995 9
248. l 192 3 4 2 1 Allocation of objects to subcontractors 193 3 4 2 2 Managing the CONSIStENCY cece eee ew cw ee ses 193 3 4 3 Configuration Management 194 3 SL PRINCIPLES eee Mn o oo nsw ober nor ata Ser Bats VA datent ee orne sente are 194 3 4 3 2 Configuration of a Development 194 3 4 3 3 Configuration Management of Code versus ODS 194 3 4 3 4 Evolution of the Project Configurations 195 3 4 4 Reviewing a HOOD Design 196 3441 Warner sero cose nimes nie sine scecevsla sed silo E E eo eee re ace aes 196 3 4 4 2 Documentation Structure ss 196 3 4 4 3 Starting reading a Design ss 196 3 4 44 ODSS REAMINES ere ere siens E Save BiG ere ne eV dd 0 5 Ne weasels ea 198 3 4 4 5 Redundancy Management ss 198 3 4 4 6 Evaluation Process esse 199 3 4 4 7 Managing Author Reader Cycles 199 3 4 5 T tor G2 iris FA a Sanaa ee STS ete We gets Age ahs adi Gb dr a 200 4 METHOD SUPPORT AND EVOLUTION 201 4 1 THE HOOD USER GROUP 2 cece ewe eee 201 42 THE STANDARD INTERCHANGE FORMAT 201 AS FOOERSETS ss oo la ewer r u nts eos 202 5 CONCLUSIONS 203 6 BIBLIOGRAPHY 204 6 1 JREFERENCES same ea inerek ases
249. l Au tomatisme JITA 90 Integration of HOOD in the Lifecycle M Heitz Proceedings of Hood confer ence April 1990 Manchester Airport HOOD A Method to Support Real Time and Embedded Systems Design JF Muller MATRA ESPACE Jochen DERISSEN GEI M Heitz and I SNEED Cisi Ingenierie Proceedings of Journees du Genie Logiciel Toulouse D cembre 1990 Editions EC2 Use of Yourdon for Reguirements Analysis in combination with HOOD for Ar chitectural Design J van Neil Proceedings of Hood conference April 1990 Copyright 1995 96 by HOOD Users Group page 212 page 213 j HOOD USER MANUAL 1 0 HUM 1 0 J 9 Manchester Airport NIEL90 Extension of Communication Facilities in Ada HJ Goedman amp J Van NIEL HCS Proceedings of HOOD conference April 1990 Manchester Airport PALU90 Generation de code Ada en conception orient e Objects HOOD R seaux de Petri VALLETTE PALUDETTO et COURVOISIER LAAS Proceedings des Journ es Internationales Le G nie Logiciel et ses Applications Toulouse D cembre 90 6 2 7 ARTICLES AND PAPERS PUBLISHED IN 1989 1988 ET 1987 AUX89 Prometh e Designing a Process Control System G Auxiette TOTAL JF CABADI P Rehbinder Cisi Ing nierie Proceedings of ADA EUROPE Confer ence 89 Madrid BL 88 Design and Development of Distributed Software using Hierarchical Object Ori ented Design and ADA M HEITZ B LABREUILLE CISI INGENIERIE Pro ceedings Ada Europe Conference Miinchen
250. l parameter part gt DESCRIPTION EXECUTION PROFILE Structured annotations providing data needed to build performance models Figure 125 Annotation with an execution profile Three kinds of statements may be used to describe an execution profile e Resource oriented statements these statements describe resources consumption Three statements corresponding to three kinds of resources have been defined WCET statement processing resource consumption in terms of worst case execution time IO statement I O resource consumption CALL statement Communication resource consumption e Control oriented statements these statements describe control structures including se quences of resource oriented statements Three kinds of statements corresponding to the more classical control structures have been defined LOOP statement to build a loop in the execution profile BRANCH to build a selection statement similar to the switch statement of the C language WAIT statement to wait for a timer expiration e Measurement oriented statements these statements are used to put measurement points in an execution profile DURATION_MEASUREMENT_POINT to measure the execution duration of a software component THROUGHPUT_MEASUREMENT_POINT to measure the throughput at a particular point in an execu tion profile An example of such annotations is provided in Figure 130 We use call statements to describe commun
251. lement in T Element entry POP STACK in out T STACK Element out T Element end OBCS procedure PUSH STACK out T STACK Element in T Element renames OBCS PUSH procedure POP STACK in T STACK Element out T Element renames OBCS POP X FULL exception raised by PUSH X EMPTY exception raised by POP end STACKS Figure 145 Ada specification Unit for active object STACKS It has to be noted that an OBCS task has been introduced that provides an entry for each con strained operation Each such constrained operation is translated into a subprogram declaration that renames that entry 2 13 2 2 b Ada Body Unit with TEXT_IO USED OBJECTS package body STACKS is function IS FULL STACK in T_STACK return boolean is begin if STACK TOP STACK SIZE then return true else return false end if end function IS EMPTY STACK in T STACK return booleanis begin if STACK TOP 0 then return true else return false end if end procedure OPCS PUSH STACK in out T STACK Element in T Element is begin code as entered in the code section of the OPCS TOP STACK LAST call to Attribute function if TOP lt STACK RANGE then STACK STATUS busy STACKS code now busy TOP TOP 1 STACK DATA TOP Element push Element STACK STATUS idle STACKScode now idle again else STATUS undefined STACK code Status UNDEFINED raise X_FULL impossible case end if end OPCS_PUSH proce
252. lism code generation rules and Standard Inter change Format in the reference manual 1 e definition of a Method User Manual 5 released in 1994 e definition of method evolution draft HOOD revision 4 integrating inheritance currently pro totyped 4 2 THE STANDARD INTERCHANGE FORMAT The HOOD Reference Manual 1 defines a standard exchange format for the design description associated to HOOD design models and called SIF Standard Interchange Format This format now supported by the HOOD toolsets benefits to HOOD users as e a standardised ASCII exchange format for HOOD designs which is supported by HOOD toolsets e a mean of reuse and preserve the investment in producing a HOOD design since HOOD de scriptions will be able to be processed by current tools or by future tools e acommunication vehicle and exchange mean for the different teams in a large project Teams may not have the same tools and still share their designs e abridge towards a variety of other development tools performance evaluation traceability analysis documentation or reuse tools 6 Copyright 1995 96 by HOOD Users Group page 201 page 202 i HOOD USER MANUAL 1 0 by HUM Working Group a De 4 3 TOOLSETS The tools supporting the method should enable graphical representation textual edition docu mentation edition and management design checking and automatic production of code and test unit skeletons There are now several toolsets a
253. ll operations Advice 15 Use exceptions carefully Use exceptions only for uncontrolled errors and handle anticipated errors specifically in the object Comments There are problems in using freely exceptions The first point is that using exceptions is not fully compliant with the encapsulation principle On another hand using exceptions may lead to problems while coding depending on Ada comSTACKrs There are two types of error processing uncontrolled and anticipated Uncontrolled errors may be managed by using exceptions This include Ada predefined exceptions Uncontrolled means errors can occur at any moment and are not specific to an object Anticipated exceptions are for instance the example of Copyright 1995 96 by HOOD Users Group page 124 page 125 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 the stack with the is empty operation they are part of the object All which is specific to an object has to be treated as an error processing specifically in the object otherwise use carefully exceptions Advice 16 Propagate exceptions out of reusable parts Handle exceptions internally only when you are certain that the handling is appropriate in any circumstance Advice 17 Always propagate exceptions raised by class formal operations Advice 18 Always come back to the last correct state of the object when raising an exception Advice 19 Always leave parameters unmodified when raising an exception Comments When designing
254. ll the system the alarm the bargraphs the sensors and resets the monitoring timer USED OPERATIONS Timers Driver Delete Alarm Stop Bargraphs Switch Off Sensors Stop PROPAGATED EXCEPTIONSNONE HANDLED EXCEPTIONSNONE PSEUDO CODE TBD CODE TBD END OPERATION Stop Copyright 1995 96 by HOOD Users Group page 56 Hoo D HOOD USER MANUAL 1 0 D te page 57 HUM 1 0 OPERATION Is Value out of Range DESCRIPTION TBD USED OPERATIONS TBD PROPAGATED EXCEPTIONS TBD HANDLED EXCEPTIONS TBD PSEUDO CODE TBD CODE END OPERATION Is Value out of Range OPERATION Monitor DESCRIPTION This operation is in charge of the EMS monitoring It acguires the mean values of each sensor controls them against limit values with respect to each category of sensors converts those mean values into displaying values according to min and max information and displays them on the corresponding bargraph It sets the alarm if the mean value is out of range or if there is a sensor failure It also set the green colour of a bargraph when the value is correct the red colour when the value is out of range and the red flashing colour when the corresponding sensor is failed The Monitor operation switched the alarm on for each out of range value and each failed sensor and switched the alarm off for each correct value and running sensor USED OPERATIONS Alarm Switch On Alarm Switch Off Bargraphs Display Bargraphs Flash Bargraphs Set Colou
255. ll these models a limited number of methods could be identified for a project where HOOD could a central method to capture the reference representation of the sys tem to be developed CONCEPTUAL ARCHITECTURAL MODELLING IMPLEMENTATION M MODELLING REFINEMENT MODELLING Development activities of Tools amp Environments KIS line KB Support Environment C C LISP Tools amp Environments RDBMS O DBMS OOP C OSTORE Development activities of DBMS line Development activities of Tools amp Environments MMI line UIMS MOTIF X WINDOW OOP C C Tools amp Environments OS Distributed OS amp vice REQUIREMENT Development activities of C_ ANALYSIS APPLICATION line Target MACHIN activities distributed parallel specialized Figure 106 Models and Components of a complex software architecture Copyright 1995 96 by HOOD Users Group page 136 page 137 j HOOD USER MANUAL 1 0 HUM 1 0 a De Figure 106 above summarizes the modelling activities of a development classified in three groups each of which being supported by specific methods and tools e Conceptual modelling activities tent to grasp problem entities and try to give a formal mod el of them In these activities one finds techniques and methods of requirement analysis and engineering e Architectural modelling activities tent to formalize associated solutions items In these ac tivities one finds design techniques and methods e Implementati
256. llocated objects For each Virtual Node or allocated Object of the Virtual Node Tree 2 6 x lt Virtual Node gt Virtual Node lt Object gt Object 2 6 x 1 Overview This section gives a presentation of the virtual node or object corresponding to the related ODS description part When virtual node it could be an output of the Statement of the Problem part of the HOOD design step It may also include a synthesis of the requirements covered by that virtual node or object In that sense it is an output of the Analysis and Structuring of the Requirements Data part of the HOOD design step When virtual node it may also include particular design principles followed in the decomposition of that virtual node 2 6 x 2 Functioning Only for Virtual Node This section explains the following graphical description in terms of data handling through operations of the different child virtual nodes or allocated objects It is an output of the Informal Solution Strategy part of the HOOD design step 2 6 x 3 Graphical Description Only for Virtual Node This section gives the HOOD diagram of the current virtual node defining the decomposition of that node into virtual nodes or into allocated objects 2 6 x 4 Justification of Design Choices Only for Virtual Node This section facultative includes the set of design decisions made for the current decomposition It may include reason of particular choices rejected choices etc It is an outp
257. loop select accept Start OPCS Start or accept Stop empties Stop gueue OPCS Stop or accept Monitor empties Monitor gueue OPCS Monitor end select Figure 36 Ada Body associated to Ctrl EMS ODS Copyright 1995 96 by HOOD Users Group page 58 page 59 HOOD USER MANUAL 1 0 HUM 1 0 procedure OPCS Start is begin Timers_Driver Create MONITORING_TIMER MONITORING_FREQUENCY IT_1HZ_ADDRESS Alarm Start Bargraphs Init Sensors Start Timers_Driver Start MONITORING TIMER end OPCS Start procedure OPCS Stop is begin Timers Driver Delete MONITORING TIMER Sensors Stop Alarm Stop Bargraphs Switch Off end OPCS Stop procedure Is Value out of Range is begin null TBD end Is Value out of Range procedure OPCS Monitor is begin null TBD end OPCS_Monitor end Ctrl_EMS end body of package Ctrl EMS Figure 37 Ada Specification associated to EMS ODS Continued Copyright 1995 96 by HOOD Users Group page 59 page 60 00 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page 60 page 61 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J 2 ADVANCED CONCEPTS 2 1 ARCHITECTURAL GUIDELINES In this section we shall give some guidelines for identifying HOOD objects There are however no strong principles if any for finding objects straight away for a HOOD design The Basic design Step describes how the software requiremen
258. lopment Approaches 92 2 4 3 1 Establishing a VN architecture 92 2 4 3 2 Implementing INTER VNs communications ssssssssssss 94 2 4 4 Expressing inter process communication with operation constraints 95 2 44 1 Use of Ada tasking 4444000000000 00 0 e 96 2 4 42 Nouseof Adatasking cc ee cece cree cece eee ee 96 2 5 DISTRIBUTED SYSTEMS 3 56s s ee asd 97 2 5 1 A Development Approach 97 2 5 2 VN Implementation Approach 97 2 5 2 1 Implementing protocol constraints for VNS 98 2 5 2 2 Managing VNS as HOOD OBJECTS 103 2 6 MAN MACHINE INTERFACES 105 2 6 1 Development Approach for complex MMIs Systems 105 2 6 2 Modelling interactions with Window Managers 109 2 6 3 Factorising interactions with Window Managers 109 2 7 INFORMATION SYSTEMS ce secersoesesseosecsee 11 2 7 1 PARALLEL DEVELOPMENT of Information Systems 111 2 7 2 Example of a HOOD initial Information System Model 112 2 8 FAULT TOLERANT SYSTEMS 113 2 9 ERROR AND EXCEPTIONS HANDLING 115 2 9 1 The Excep
259. ls 2 1 3 1 Structuring based on layered models Every software can be seen as an implementation of a layered model in which the application part are on the upper levels whereas general purpose services and execution infrastructure serv ices OS services communication services are located at the lower level of the model APPLICATION LAYER THERMAL AOCS PAYLOAD GENERAL SERVICES LAYER TARGET SYSTEM E Coa baa SERVICES LAYER E C Figure 52 Typical Layered Model of a on board Application 2 1 3 2 Structuring based on Technological Components HOOD modular decomposition principles may simultaneously be used to find a modular struc ture in terms of components exchanging data These components should be first identified ac cording to the technology with which they are developed For each level of parent child decomposition one applies decomposition criteria based either on allocation of functions to HOOD top level objects or on component developed using a specific technology Thus loosely coupled modules with minimised provided interfaces may be defined and interfaces between the different development technologies will be highlighted Copyright 1995 by HOOD User s Group page 73 page 74 HOOD USER MANUAL 1 0 by HUM Working Group The partitioning of a software can thus be made according to development and technological cri teria As a result a general architecture model of information systems can be defin
260. m hierarchies Copyright 1995 96 by HOOD Users Group page 192 f page 193 HOOD USER MANUAL 1 0 HUM 1 0 7 3 4 2 1 Allocation of objec s to subcontractors Allocating objects to subcontractors shall make trade offs between constraints induced by e a fine breakdown of the technical model at several decomposition levels Such a breakdown should not have a too fine granularity there are serious risks of doing the work of the sub contractors but at the same time should be significant enough to allow a trusty evaluation of the effort and further allocation without impacting changes to the initial model e the allocation of associated resources for the definition of the breakdown The more the initial breakdown is fine the more the resources necessary Moreover the allocation of resources is often made before the effort needed to do the system is really known 3 4 2 2 Managing the consistency The prime shall foresee a number of reviews in order to synchronise the parallel developments by its subcontractors The system configuration of the subcontractors will be updated at the time of these reviews since root objects of each local system configuration are likely to be common resources at the global system configuration level Thus early identification of common resources is a matter of efficiency and of resource optimi zation Figure 157 below tries to illustrate the relationships between local and global system_config
261. mal limited private type prevents the class from making any assumptions about the structure of objects of the type or about operations defined for such objects A private formal type non limited allows the assumption that assignment and equality are defined for the type Thus a limited private type can not be specified as the actual parameter for a private formal type Example Figure 100 is an example of what not to do whereas Figure 101 is an illustration of the advice OBJECT H_LIST is CLASS PASSIVE TYPES Items is private Keys is private OPERATIONS Key_Of Item in Items return Keys PROVIDED_INTERFACE TYPES ists is limited private OPERATIONS Insert List in out Lists Item in Items Retrieve List inoutLists Key inKeys Item inout Items Figure 100 A class violating Advice 29 OBJECT H_LIST is CLASS PASSIVE TYPES Items is limited private Keys is limited private OPERATIONS Key_Of Item in Items return Keys Assign From in Items To in out Items Na Left in Keys Right in Keys return boolean PROVIDED_INTERFACE TYPES Lists is limited private OPERATIONS Insert List in out Lists Item in Items Retrieve List in out Lists Key in Keys Item in out Items Figure 101 The same class respecting Advice 29 Copyright 1995 96 by HOOD Users Group page 130 page 131 j HOOD USER MANUAL 1 0 HUM 1 0 a De Note that the first exam
262. men 204 6 2 HOOD BIBLIOGRAPHY 208 Copyright 1995 96 by HOOD Users Group page xiii page xiv j HOOD USER MANUAL 1 0 by HUM Working Group De 6 2 1 Articles and Papers published in 1995 208 6 2 2 Articles and Papers published in 1994 208 6 2 3 Articles and Papers published in 1993 208 6 2 4 Articles and Papers published in 1992 208 6 2 5 Articles and Papers published in 1991 210 6 2 6 Articles and Papers published in 1990 211 6 2 7 Articles and Papers published in 1989 1988 et 1987 213 A APPENDIXES 215 A1 MORE ON THE EMS EXAMPLE 216 A1 1 EMS REQUIREMENTS 0000 216 Al 1 1 Presentation of the EMS system 216 A112 Chent Requirements 3553453345356 het ete yds Wu hee le PAE oa 217 A1 1 3 Software Environment 217 A1 2 OBJECT AND OPERATION IDENTIFICATION THROUGH TEXTUAL ANALYSIS TECHNIQUES 217 A1 2 1 Identification of Nouns 217 A1 2 2 Identification of Verbs continue 218 A1 3 OTHER ODS OF EMS SYSTEM 219 A1
263. n should be initialized automatically Probing operations may be provided to determine limit cases so that the user can avoid causing exceptions to be raised Advice 23 Use HOOD Classes to avoid code duplication Advice 24 Parameterize Classes for maximum Adaptability Advice 25 Use Classes to encapsulate algorithms independently of data type Example Figure 95 is an example of a class representing an object to sort data independently of data type Copyright 1995 96 by HOOD Users Group page 126 page 127 HOOD USER MANUAL 1 0 HUM 1 0 OBJECT SORT_SERVER is CLASS PASSIVE FORMAL PARAMETERS TYPES Element is limited private Data is array Integer range lt gt of Element OPERATIONS lt Left in Element Right in Element return Boolean is Swap Left in out Element Right in out Element PROVIDED INTERFACE OPERATIONS Sort Data to Sort in out Data INTERNALS OPERATION CONTROL STRUCTURES OPERATION Sort Data to Sort in out Data IS CODE begin for I in Data to Sort range loop if Data to Sort I lt Data to Sort J then use of formal lt swap Data to Sort I Data to Sort J use of formal swap end if end loop Figure 95 an object to sort data There can be different instances an instance for sorting integers see figure 96 OBJECT SORT_INTEGER is INSTANCE_OF SORT_S PARAMETERS TYPES Element gt Integer Data gt UTIL_
264. n target system host OS Such a run time library is already provided by some HOOD toolset vendors targeting C and is now specified in the HOOD4 definition Copyright 1995 96 by HOOD Users Group page 159 page 160 00 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page 160 page 161 j HOOD USER MANUAL 1 0 HUM 1 0 a De 2 13 FULL ADA CODE ILLUSTRATION 2 13 1 TERMINAL PASSIVE OBJECT Let us consider a simple terminal passive object that implements a STACK as an abstract data encapsulating the data that represent the stack and providing operations to manipulate them 2 13 1 1 ODS Definition for passive STACK object A passive STACK object implementing an Abstract Data for a STACK may be represented as in Figure 132 with two operations PUSH and POP ADT_Element E CE POP STATUS Figure 132 Graphical representation for the object Stack The ODS of Figure 133 shows the ODS declarations of provided and required types and oper ations and exceptions OBJECT STACK IS PASSIVE 1 DESCRIPTION Implementation of a abstract Data STACK with no encapsulation of associated data IMPLEMENTATION_CONSTRAINT S none PROVIDED_INTERFACE OPERATIONS Push Element In T_element Pop Element Out T_element Status return T_Status EXCEPTIONS X_EMPTY raised by POP X_FULL raised by PUSH REQUIRED_INTERFACE OBJECT ADT_ELEMENT TYPES T_Element STACK requires type
265. n the other cases see Section 1 3 1 3 below Copyright 1995 96 by HOOD Users Group page 30 page 31 I HOOD USER MANUAL 1 0 HUM 1 0 a De 1 3 1 2 The Basic design step applied to a root object Unlike the other objects the root object STD must be defined prior to be decomposed Thus the Problem Definition activity needs to define the interfaces provided and required of the root object The designer puts the emphasis on the environment of the System To Design STD he has to produce a diagram showing the STD within its environment 1 3 1 3 The Basic design step applied to terminal object The basic design step applied to the terminal objects is shorter and consists in detailing the inter nals with declarations internal operations and pseudo code Each basic design step activity is re stricted as follows Activity 1 Problem Definition The designer should gather all the information related to the terminal object Activity 2 Elaboration of an Informal Strategy The purpose of this activity is to provide a short description for the internals OBCS and OPCS s of the object derived from their description in the ODS visible part Those description are im plementation oriented The designer has also to give internal declaration not defined in the ODS visible part The goal defined in the general scheme of creating a solution strategy is not applicable here as the terminal object is not decomposed any more Activit
266. n trying to apply strong author reader cycles to all sub sections of an ODS DESCRIP TION field one may hinder the creative process and responsibilities of the designer e when receiving ODS parts on which you as a reader almost fully agree you may not even respond Such regulating rules tend to reduce dramatically the exchange rate of design documentation for author reader cycles and rendering globally to a better process Moreover as experience becomes larger there are some particular sections of the ODS which are highly important for readers namely the informal strategy and the operations descriptions A Copyright 1995 96 by HOOD Users Group page 199 page 200 j HOOD USER MANUAL 1 0 by HUM Working Group a De project should thus organize and plan the author reader cycles so that the readers go prepared to give their best effort according to a planned delivery of these sections e either they receive continuous information from the writers and they may foresee when the real thing will be ready for review e either they have to be ready to respond as soon as they receive the important sections 3 4 5 TUTORING Tutoring is supporting on line a project team just trained in a new technology e by looking over their shoulders to check that the new technology is well used and applied e by providing thus additional support and training at points where it is needed Tutoring should be applied to HOOD projects especially
267. n used from within a HOOD design tree as HOOD Environments objects what requires modelling all resources used or reused as provided items of such a HOOD object A problem might occur if one has to reuse global data since those data are not allowed in provided interfaces of HOOD objects the solution is then simply to model such data as a HOOD object with two operations readata and writedata A HOOD toolset will thus ne able to check interfaces with reused code and the effective module may simply replace the associated body part generated by the HOOD toolset Copyright 1995 96 by HOOD Users Group page 189 ANg page 190 HOOD USER MANUAL 1 0 by HUM Working Group 7 3 4 MANAGING HOOD PROJECTS 3 4 1 OVERVIEW HOOD is a design method allowing to produce modular and hierarchical descriptions of soft ware as a set of interconnected objects The specifics of a HOOD development is that the refine ment of such a model is performed along through two kind of activities refinement by adding more details to object descriptions the activity proceeds by enrich ing the descriptions of an object by adding more details to an existing description using step wise refinement techniques within the INTERNALS framework of an ODS Object Description Skeleton refinement by decomposition according to the properties of the include relationship a HOOD model can be refined by adding more objects to an initial model Thus the
268. nd reuse it is recommended to centralize error handling so as to have an homogeneous and standardized treatment Another advantage of this approach is a better maintainability since the error handling object should group together all recoveries operations 2 9 3 SUGGESTED SOLUTION A good strategy for error handling could be e Use of one unique object in the system providing logging services for errors and exceptions and allowing to apply a minimal standard code to each error and or recovery processing Fig ure 86 below gives an example of a specialized object in the logging of error and exception handling either within files and or and a dedicated screen window e Recovery strategy on a local priority basis Copyright 1995 96 by HOOD Users Group page 115 page 116 I HOOD USER MANUAL 1 0 by HUM Working Group a De EXCEPTIONS Init Put Sender string why string Set Logg STDIO FILE Figure 86 Dedicated Object to handle Error and exceptions Copyright 1995 96 by HOOD Users Group page 116 page 117 A 0 0 I HOOD USER MANUAL 1 0 HUM 1 0 J 9 2 10 REUSING HOOD DESIGNS 2 10 1 OVERVIEW What is the exact meaning of reuse in our context It can simply be stated that it is the ability to pick up parts of previous designs in order to build a new one Some work is supposed to have already been done in an area more or less similar to those of the new project and the problem is to get this work back rath
269. nd select end loop end OBCS Copyright 1995 96 by HOOD Users Group page 169 HOOD USER MANUAL 1 0 page 170 by HUM Working Group OPERATION CONTROL STRUCTURES OPERATION IS_FULL return boolean is DESCRIPTION check current object state USED_OPERATIONS None PROPAGATED EXCEPTIONS None CODE in Ada begin if STACK TOP STACK SIZE then return true else return false end if END of opcs IS FULL OPERATION IS EMPTY return boolean is DESCRIPTION check current object state USED OPERATIONS None PROPAGATED EXCEPTIONS None CODE in Ada begin if STACK TOP o then return true else return false end if END of opcs IS EMPTY OPERATION Status return T Status is OPCS of POP DESCRIPTION Get status of class STACK code USED OPERATIONS None PROPAGATED EXCEPTIONS None CODE in Ada begin return STACK STATUS END of opcs STATUS OPERATION POP is OPCS of POP DESCRIPTION Remove an Element from the data structure USED_OPERATIONSNone PROPAGATED_EXCEPTIONS X_STACK_UNDEFINED PSEUDO_CODE if Ihe STACK is not EMPTY then put STACK in BUSY state remove Element from STACK_DATA put STACK in IDLE state else raise X_EMPTY put STACK in UNDEFINED state end if CODE Ada begin if STACK TOP gt 0 then STATUS busy STACK code is BUSY Element STACK_DATA STACK TOP STACK TOP STACK TOP 1 STATUS idle STACK code is IDLE else STATUS undefined STACK code UNDEFINED raise X_EMPTY
270. nd templates organised and structured by client server and in clude relationships as defined above The class space includes all class which are instantiated within the HDTs of the object space e A set of VN hierarchies or VNTs which are part of the Virtual Node space and which define the potential granularity for partitioning onto a physical architecture of processes or ma chines e The Physical architecture on which terminal virtual nodes are allocated The scope of a HOOD design model is controlled through the concept of System Configuration which defines all root of hierarchies describing the system Object hierarchies Class hierarchies and Virtual Nodes hierarchies 4 Classes in HOOD4 are termed GENERICS thus avoiding a clash with the OO terminology Copyright 1995 96 by HOOD Users Group page 20 page 21 HUM 1 0 HOOD USER MANUAL 1 0 Hoon Class Hierarchy SN E Df ff SalyoesdiH 199 q0 Virtual Node Hierarchy The HOOD design model into a set of spaces and hierarchies Figure 21 page 21 Copyright 1995 96 by HOOD Users Group f page 22 j HOOD USER MANUAL 1 0 by HUM Working Group a D a 1 3 THE HOOD DESIGN PROCESS The HOOD method proposes a process to guide the designer in his job This process allows to get a good design what ever the size and the complexity of the project This approach orients to the best choices Two different processes are imbr
271. nerate various documents for verification cross reference tables dictionaries indexes 1 1 5 AN ODS ILLUSTRATION THE STACK OBJECT In the following we give an illustration of an ODS associated to a terminal object called STACK modelling a STACK abstract data type and which is represented as Figure 9 with two opera tions PUSH and POP constrained by the object s internal state STATUS Figure 9 Graphical representation for the active object Stack The STACK object behaviour can be modelled by a state transition diagram as in Figure 10 where transitions are exclusively associated to operation execution first PUSH last POP not_empty_not_full last PUSH POP Or PUSH POP Figure 10 Object behaviour for STACK The OBCS implementation can be reduced in this case into one Ada task implementing the state transition diagram and the associated Ada code could be described in the OBCS CODE field see Figure 11 Copyright 1995 96 by HOOD Users Group page 11 page 12 HOOD USER MANUAL 1 0 by HUM Working Group F I 9 The ODS of Figure 11 shows the declarations of OBCS and declaration of provided and re quired types of object STACK OBJECT STACK IS ACTIVE DESCRIPTION abstract data type STACK with no encapsulation of data instances IMPLEMENTATION_CONSTRAINTS The target system shall be an Ada system with full Ada83 tasking PROVIDED_INTERFACE TYPES T_Status is BUSY IDLE
272. niques for the development of realtime software P VIELCANET CISI INGENIERIE Proceedings of ADA Conference Washington 06 89 HEI 88 Hierarchical Object Oriented Design for Ada La Lettre ADA n 8 M HEITZ CISI INGENIERIE 2 pages 10 88 VAL 88 R seaux de P tri pour la conception de logiciels temps r els VALLETTE Copyright 1995 96 by HOOD Users Group page 213 page 214 j HOOD USER MANUAL 1 0 by HUM Working Group a De PALUDETTO du LAAS et LABREUILLE CISI INGENIERIE Proceedings des Premi res Journ es Internationales Le G nie Logiciel et ses Applications Toulouse D cembre 88 HEI 87 H_OOD Une M thode de Conception Hierarchis e Orient e Objects pour les d veloppements des logiciels techniques et Temps r els M HEITZ Proceedings Journ es ADA AFCET 12 87 Copyright 1995 96 by HOOD Users Group page 214 page 215 HOOD USER MANUAL 1 0 HUM 1 0 OUD A APPENDIXES Copyright 1995 96 by HOOD Users Group page 215 page 216 HOOD USER MANUAL 1 0 HUM 1 0 voon A1 MORE ON THE EMS EXAMPLE A1 1 EMS REQUIREMENTS A1 1 1 PRESENTATION OF THE EMS SYSTEM The EMS is a software to monitor a motor engine variables to display them on a bargraph and trigger an alarm if associoated values are out of range A detailed requirement of the EMS is giv en hereafter Displays A La n N M y Alarm m Ack Alarm B mm Start SENSORS Sto O P
273. nto OPCS bodies 2 11 3 1 Extended Object Execution Model In the above section we gave the code generation principles for basic execution constraints at tached to operations However the implementation of more complex execution requests associ ated to communication protocols must also be defined In Figure 109 below an extended execution model in terms of HOOD objects defines a standard architecture for implementation of any execution constraints where e I INTERFACE defines a set of interface units tasked with handling the execution requests ASER HSER LSER TOER from clients and to transmit these request to the OBCS as standardized events OP_execution request event or OP execution with time out e OBCS is a target unit implementing a state transition model and which allows to control the triggering of OPCSs according to incoming requests and the internal state of the object as defined by the designer and using a suitable notation formalism e O INTERFACE is a target unit tasked with handling the execution of OPCSs on OBCS en able signals and to acknowledge back when OPCS has completed The three units define possible process spaces and in case data such parameters exchanges are involved we suggest to store and access it through an associated abstract data type implementa tion ina HOOD environment object Such an implementation is either defined by the designer or may be generated automatically by HOOD toolsets En
274. o child objects It particularly highlights use links with formal parameters Y 4 x 4 Justification of Design Choices Only for Non Terminal Object See above 2 6 x 4 APPENDIX A Textual Descriptions of Objects For each Virtual Node Object or Class defined in the previous chapters this appendix gives the related ODS We suggest to classify all those ODS in alphabetic order A x lt Virtual Node gt Virtual Node ODS lt Object gt Object ODS lt Class gt Class ODS ODS are complete for non terminal objects virtual node and class ODS for terminal objects and OP_control only include the visible part Indeed the ADD does not include information about pseudo code and code APPENDIX B Traceability Matrix with SRD This matrix traces each requirement of the SRD by an object of the design Copyright 1995 96 by HOOD Users Group page 185 page 186 HOOD USER MANUAL 1 0 by HUM Working Group F D ed 3 1 2 DDD STANDARD 3 1 2 1 Introduction According to the suggested standard one DDD is required for the whole ADD or for each object of the ADD For simplicity reasons we recommend to have one DDD for each ADD 3 1 2 2 Example of DDD Contents 1 System Software General Overview This chapter introduces the main functions of the system or software to be designed its aim and mission It may also include a HOOD tool presentation and give particular development constraints See section 3 1 1 2 For each hierar
275. ocol constrained operations The ClientStub object of Figure 72 above is implemented as a set of objects as many as allo cated objects to the VN that require remote operations and whose OPCS code contains only OPCS_ER code as illustrated in Figure 74 below This implementation is heavily based on FIFO queues of which efficient implementations are now available for most targets Queues al low to handle the problem of global time network and process contention synchronisation etc Copyright 1995 by HOOD User s Group page 98 page 99 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J in the most modular way Furthermore it allows to have a layered implementation decoupling fully the HOOD application of any implementation infrastructure and communication software Local allocated OBJECTS allocated OBJECTS Parameters sf A Parameters Figure 73 Execution Model for protocol constrained operations for VN procedure PUSH item in T_Item is OPCS_ER code MSG IPCMSG T_MSG begin MSG IPCMSG create initialise an IPC MSG data structure MSG sender STACK MSG OPERATION PUSH MSG CNSTRNT HSER MSG INFO Item ClientObcs insert MSG insert in request queue if firstimeCall queues are allocated MSG ClientObcs remove remove return IPCMSG and process return parameters if not MSG X OK then EXCEPTIONS raise MSG X raise exception according to Xvalue else EXCEPTIONS LOG STACK PUSH E
276. ody code containing the dedicated SerDispatcher code 178 Figure 154 Example of a HOOD initial model at levell of decomposition 000 0 ee eee eee 190 Figure 155 Example of Refinement of initial HOOD model 190 Figure 156 HOOD Design trees states in the development life cycle eeeee eee 191 Figure 157 Consistency of multi System Configurations 0 0 0c eee ceceeeeeeceeeeeeceseeeaseseeeaecsaecaeenaenaes 193 Figure 158 The EMS Syst me eas ea neal ee eo eave aust 216 Figure 159 The EMS Hardware Block Diagram 00 0 eee ese ceseeeeceseeeeceeceeeseeeeeeeeaeeseeesessaecaeenaesaes 216 Figure 160 Suggested Target Code structure for constraint Operations cc esse eeeeeceteeeeeeeeeeneenees 234 Copyright 1995 96 by HOOD Users Group page xx F J 9 page xxi i HOOD USER MANUAL 1 0 HUM 1 0 LIST of FIGURES Figure 161 Principle of Code for Protocol onstrained operation support 236 Figure 162 Principle of Code for Protocol Constrained operation support 237 Figure 163 State Constraints Implementation Schema 238 Figure 164 OSTD for STACK object iii 238 Figure 165 OSTD Implementation Example ss 239 Figure 166 STACK object with state constraints Operations e 4 2e 4ere2ee2eee0ee0e00e een 240 Figure 167 STACK with state constraints code Sample 240 Figure 168 STACK with state constraints code Sample 241 Figure 169 STACK with protocol constraints
277. of a Bounded Stack In order to illustrate the importance of the provided interface which may give a lot of indirect information let us try to understand what implicit assumptions may be contained in the provid ed interface of an example see figure 39 First the presence of a provided constant indicates a static memory allocation scheme The ex istence of the exception X OverF low tends to corroborate this hypothesis OBJECT STACK is ACTIVE DESCRIPTION A protected integer stack as an abstract Data Object IMPLEMENTATION_CONSTRAINTS constraints PROVIDED_INTERFACE CONSTANTS MAX STACK SIZE constant 100 OPERATIONS Push Item in Integer Pop Item out Integer EXCEPTIONS X_OverFlow raised_by Push X_UnderFlow raised_by Pop OBJECT_CONTROL_STRUCTURE DESCRIPTION pop and push are simple constrained operations CONSTRAINED_OPERATIONS Push CONSTRAINED by HSER Pop CONSTRAINED by HSER INTERNALS TYPES Stack Range is Integer range 1 MAX_STACK_SIZE Stack is array Stack Range of Items DATA Top Integer 0 The_Stack Stack Figure 39 Textual view of a Bounded Stack defined as an ADO The two provided exceptions seem to be very similar in the sense that they are raised when the use of the stack leads to violate its boundaries But they differ fundamentally An abstract stack is infinite and the X_OverF low exception is raised when the concrete stack is not big enough to simulate the abstract one what is
278. of design After the formalization of the solution one can identify the possible areas in which reusable designs i e objects could be reused Then the designer researches in a component library the objects which could solve his problem This search gives a short list of candidates and a design to tar get tries to include those candidates in the current design This process is similar to the design process for hardware components including commercial chips IC VLSI The encapsulation principles in HOOD fit quite well on this scenario in the sense that the user does not need to know the internals of an object and is only concerned with its provided interface which describes how to use the object and its required interface which describes the context and the environment requested by the object to provide the services More details on these topics are given in Section 2 10 of this document 1 4 6 HOOD AND SUBCONTRACTING There is a clear need to properly manage SW development in the context of large systems involv ing many contractors and subcontractors In this context HOOD may be used according either to the prime point of view or to the subcontractor point of view The prime HOOD activities are mainly concerned with e responsibility of high level design e interface validation e identification of HOOD sub trees subject to subcontracting e prototyping activities by simulating subcontracted software parts mainl
279. ogical partitioning that highlights relevant abstractions of the solu tion phase 1 e refine down the logical model and start to build the infrastructure model and the distribution model to a verifiable executable model on a ideal target phase 2 e adapt refine further and tune on the final target by refinement of both model taking into ac count the physical model phase 3 PHASE1 PHASE2 PHASE3 Phase 1 i delivery A Time Figure 30 Phased Incremental Development Approach For Complex Systems 2 Experience has shown that an appropriate duration for such phases should be less than one year Copyright 1995 96 by HOOD Users Group page 43 page 44 00 l HOOD USER MANUAL 1 0 by HUM Working Group J 9 Copyright 1995 96 by HOOD Users Group page 44 page 45 j HOOD USER MANUAL 1 0 HUM 1 0 De 1 5 A HOOD EXAMPLE In this section we shall illustrate a HOOD design not a full fledged one but trying merely to il lustrate a full design step 1 5 1 PRESENTATION OF THE EMS SYSTEM The EMS is a software to monitor car engine parameters to display them on a bargraph and trigger an alarm if associated values are out of range A detailed requirement of the EMS is given in APPENDIX A1 of this document 1 5 2 EMS SOLUTION A solution of the EMS software is defined by applying a basic design step 1 5 2 1 Statement of the Problem H1 1 Design and develop a so
280. ol support and practically no real case study feedback Petri net based techniques are also promising since composition of Petri nets is well mas tered GIOVA89 PALU90 VIEL89 Package associated to a Package associated to a terminal object terminal object 1 Interface 1 Interface O Interface Interface Package associated to a terminal object I Interface O Interface Figure 120 Integration based on several concurrent AUTOMATA Package associated to a Package associated to a erminal obje erminal obje i I Interface Package associated to a e ie obie O Interface Figure 121 Integration based on merge of AUTOMATA The advantage of such approaches is that the full system behaviour could be modelled expressed and verified formally with HOOD bringing structure and decomposition support and formal no tations a sound mathematical support Copyright 1995 96 by HOOD Users Group page 147 n page 148 HOOD USER MANUAL 1 0 by HUM Working Group 7 2 11 3 4 Synchronous Automata Code for Predicate Transition nets Begin_ OP and End_OP variables are associated to places in order to store the number of tokens SET EVENT procedures increment Begin_OP or End_OP variables as token are created The OBCS automata is implemented as one execution flow which examines all transitions of the network and eventually fires some of them Interpreting is reduced to evaluation of the condi tions and execution of t
281. ommends reviews at the end of a basic design step as well as at the end of a level i e when all branches of a tree have been decomposed Moreover when a HOOD model is produced feasibility of the target implementation may to be checked traceability to requirements should be ensured and the overall quality of the model should be estimated e organisational goals The work progress must be evaluated in order to help management of a project The end of design activities through documentation delivery and or reviews at the end of notice able basic design steps provide candidate milestones for work progress evaluation We shall not take into account here other QA activities here This is because QA activities goal is to verify that technical activities have been correctly executed Depending on projects where QA procedures are defined and adapted in a QA plan QA defines proce dure that constraint technical verification activities to produce traces of their activity doc umentation verification reports tests results etc And QA procedures check activity by examining these traces Copyright 1995 by HOOD User s Group page 82 page 83 HOOD USER MANUAL 1 0 HUM 1 0 oof g J 2 3 1 2 Means for HOOD design verification Products associated to the design process and activities are of two kinds e formal documentation graphical notations and or textual ones that compilable or executa ble Ada Petri nets Finite
282. on constraint The semantics of state constrained operations of HOOD HRM is thus enforced since the re turn to the client is made either with the OPCS executed the state was OK at the operation re quest or with OPCS non executed the state was not OK at calling time Appendix A3 2 gives a full illustration of such ADA code A3 1 3 IMPLEMENTING PROTOCOL CONSTRAINTS IN ADA Protocol constraint operations are specified through trigger labels expressed in text structured with keywords such as HSER LSER TOER_HSER TOER_LSER or ASER that may apply together with state constraints These protocols specified in HRM are used to express inter process communications as well as inter node communication in case of virtual nodes defining distributed code or memory partitions Using the queuing and mutual exclusion mechanisms supported by the Ada select and accept statements standard code generation rules HRM for constraint protocols are rather straightfor ward but always involving a server OBCS task and often with the need of copying parameters inside the accept statement An example of such generated code is given in section 2 13 2 A3 1 3 1 Implementing protocol constraints without Ada tasking In case of resources shortage or when Ada tasking should not be used generation rules again rely on queuing synchronisation and message passing mechanisms but this time using classical operating services We hope that in the near future this code w
283. on modelling activities are refinement techniques leading to implementation on specific targets In these activities one finds coding techniques manual or automated through 4th generation tolls and languages All these different activities may be composed according to the understanding and the level of mastering of the development Activities are however chained and triggered according to the fol lowing principles e COMPLEXITY and PROBLEM SOLVING REFINEMENT going from conceptual models towards implementation through design and architectural ones e TECHNOLOGICAL REFINEMENT along specialized lines of activities the development of a data processing system may involve an MMI development line focusing on the development of the Man Machine Inter face that uses the technology of UIMS User Interface Management System or Generator and windowing management standards a DBMS development line focusing on the data handling and storing possibly tied to the knowledge that are manipulated These activities are dealing with the definition of data models Database schemes and rely on Relational and Object DBMS tools an APPLICATION development line concerned with the development of the core ap plication and interfaces that corresponds to classical software engineering activities and which rely on host OS services and target system features a KBS line when the system comprises a Knowledge System and Inference system asso ciated to the devel
284. on of the software rather than a bottom up approach derived from implementation data structures Taking into account both the natural client server relationship between objects and classes or thogonal to the composition relationships this approach proves to be a powerful structuring tool It appears today for us as the only viable integration support for both modular and full object oriented approaches Furthermore by integrating both abstract data typing and process concepts HOOD3 1 is the soft ware engineering tool of choice supporting a smooth transition from classical development prac tice into full object oriented one Copyright 1995 96 by HOOD Users Group page 203 Hoo page 204 HOOD USER MANUAL 1 0 by HUM Working Group 6 6 1 1 3 7 8 9 ACM89 BIBLIOGRAPHY REFERENCES HOOD Technical Group B DELATTE M HEITZ JF MULLER editors HOOD Reference Manual Prentice Hall and Masson 1993 M HEITZ Cisi Ingenierie Towards more formal developments through inte gration of behaviour expression notations and methods within HOOD develop ments in Proceedings of 5th International Conference on Software Engineering Toulouse December 1992 Editions EC2 S Mullender Distributed Systems ACM PRESS ADDISON WESLEY 1991 HOOD USERs GROUP C O SPACEBEL INFORMATIQUE 111 rue Colo nel BOURG B 1140 BRUSSELS BELGIUM Tel 32 2 730 46 50 fax 32 2 726 85 13 HOOD Technical G
285. ons allowed for the current object state Copyright 1995 by HOOD User s Group page 107 page 108 HOOD USER MANUAL 1 0 by HUM Working Group 0 0 g J e design of screens and widgets under the UIMS in parallel HOOD design of the interface between the application using HADTS objects to formalise the data structures and the interactions with the non MMI part e Prototyping and unit testing e evaluation of the MMI modifications e integration testing DIALOG LOG_IN_SCREEN start exit Actions FUNCT2_SCREEN FUNCT1_SCREEN start start exit exit action1 action1 action2 action2 help help Windowing_INTERFACE Figure 82 Modelling DIALOG AUTOMATA with HOOD object Copyright 1995 by HOOD User s Group page 108 page 109 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J 2 6 2 MODELLING INTERACTIONS WITH WINDOW MANAGERS Graphical and interactive handling principles have been defined and summarized for implemen tation with windowing management systems Sunview Dialogue Manager X Windows and MOTIF These latter provide Graphical User Interface Management Services GUIMS by means of libraries of routines allowing a client software to e manage graphical objects creation external representation attributes behaviours reac tions to operator stimuli of WIDGETS contraction of window gadget a graphical ob ject whose is fully handled by the GUIMS e triggering of
286. ontrol people will first check the consistency of parent child descriptions But it is clear that a customer should also validate the quality of the design which is delivered to him Based on the three steps described above we suggest and recommend an approach like the following e Evaluate the design through successive validation steps i e by checking one after another the decompositions of parent objects into child ones level after level Although it is not al ways the case at a given level the abstraction power used is the same e Before going in the next level of decomposition and for the such prevalidated ODSs check the traceability analyses e Finally evaluate the decompositions through quality criteria reuse testability Software En gineering quality HOOD rules All these activities may be done in a collaborative way by people having different backgrounds But all must have some knowledge of the HOOD method rather high for people evaluating de sign quality as well as a good knowledge of the requirements and its environment rather high for people checking traceability 3 4 4 7 Managing Author Reader Cycles Author readers cycles have always been a problem due to schedule constraints and delays A HOOD document should be submitted to a reader with comments given backs within a given week Otherwise the delay is too important and the process may hinder the design elaboration The idea here is also that e whe
287. oot objects environment objects for the main HOOD design tree These root objects are decomposed into other HDTs The corresponding System Configuration is built step by step with the different HDTs and CDTs built during that phase they constitute the Applicative Environment of the system configura tion 1 3 4 PHASE 2 INFRASTRUCTURE ARCHITECTURE This phase may begin shortly after the logical architecture from the needs identified during that phase or from some non functional requirements such as implementation constraints or perfor mances requirements It consists of the following activities e Creation of the VN tree not necessary at the beginning The root VNs may be identified from the analysis of some project structure constraints such as partitioning into assemblies or sub systems some implementation constraints channel throughout onto predefined physical nodes e Identification of communication protocols needs between the different VNs These protocols are implemented in specific root objects HDT and considered as environment objects for the applicative environment e Depending on the project these root objects are part of the system to design In that case they are decomposed by the application of HOOD design steps which define new HOOD Design Trees This decomposition is implementation driven e Identification during each design steps of similar objects or reusable objects these objects may be implemented into cla
288. opment of KBS In Figure 106 the sequence of the different methods is not defined but one can see that differ ent methods shall be used for the conceptual modelling of the requirements SA methods were intensively used but now more and object oriented analysis methods jump in Using a standardized representation such as the HOOD one allows the developer to have a per tinent representation of both the top level decomposition of the system as well as for each of each component This is an important progress towards the full mastering of the development process because the actors of the development are now provided with a reference and communication framework that is independent of the use of a specific technologies Moreover HOOD representations can be used as the communication and synchronisation tool for mastering the different development lines and ensuring proper final integration Copyright 1995 96 by HOOD Users Group page 137 page 138 I HOOD USER MANUAL 1 0 by HUM Working Group a De 2 11 1 INTEGRATION OF MULTIPLE DEVELOPMENT TECHNOL OGIES The modelling activity of an architecture is a main activity in the development of complex sys tems and must allow a smooth transition from e the conceptual models produced by the analysts e to the implementation models and associated constraints Such developments may in fact include several lines of activities each of which is relying on a different technical approach but
289. or both master ing architecture definition and integration of components developed with different technologies and teams in the area of large and complex real time critical and distributed data processing sys tems Index Terms Method Integration HOOD Object Design Formal Verification Control Ex pression Real Time Reliability Distribution Test page iii j HOOD USER MANUAL 1 0 HUM 1 0 a De PREFACE The HOOD method was developed in 1987 under European Space Agency ESA contract A0O 1 1890 86 NL MA by a consortium of Cisi CRI A S and Matra Marconi Space HOOD is a registered Trademark of the HOOD User Group This fact must be stated in any publication referencing the name of HOOD in the context of the HOOD method as the basis of the publica tion HOOD has been selected by ESA projects including Columbus and Hermes as the design method for the Architectural Design phase Since HOOD was selected by several large long lived project from aerospace and industry In 1991 the HOOD USER GROUP HUG was setup as a non profit organisation aiming to pro vide support for sharing experience and to control the evolution of the method The HUG is or ganized in a STEERING GROUP HSG in charge of administrative issues and in a TECHNICAL GROUP HTG in charge of all technical issues possibly delegating work to spe cific WORKING GROUPs The HUG is officially based at C O Spacebel Informatique attn HUG 11 rue Colonel Bour
290. or defining the user MMI interactions where the animation may be thrown away or reused for pre integration testing but where DIALOG_AUTOMATA and Windowing INTERFACE will be fully reused in the final software ANIMATION DIALOG_AUTOMATA ADT_DATA a ASER by a Module_IN fa Window_INTERFACR ASER by X ASER by X Events X callbacks UIMS init kN get action dependent code get widget fcurseur ops fsereen ops widget ops E X WND WINDOWS amp WIDGETS ETATEU DY UNV Device_actions UIMS generated code E x WNDS Figure 81 Animation and prototyping of MMIs The MMI development process should then comprise the following steps e analysis of OPERATOR behaviours and tasks where requirements should be detailed enough to become the user guide of the future system Besides a prototype of the MMI may be develop in order to get early feedback and acceptance by the user e establishment of associated dialogue and screen definitions by means of hierarchies of fi nite state automata A HOOD toolset can be used be used to capture this states as HOOD objects where see Figure 82 below start would be the object to enter the initial state exit would make the object go back to the calling state amp automata help would make launch a contextual help widget object actions are applicative actions to be triggered by the Windowing INTERFACE as the user activates the widgets representing the acti
291. ore that is used within the design without an external in terface is a logistic abstraction Examples are stack list and tables At the top level of the design in decomposing the root object candidate objects are generally real world problem domain objects e g hardware devices input devices that drive system ac tivity output devices that respond to system activity or are data files as collections of input or output data either transient data such as messages or commands or data stores such as stacks lists or tables etc At lower levels of design decomposition further general types of object may appear such as states data pools data records In the early time of HOOD there has been numerous attempts to define what is a good object and we shall not try to do it again Rather we shall recommend to define HOOD objects along two main principles identification of root objects from conceptual abstractions and HOOD parent child re finement to reduce complexity e identification of abstract data type implementations Copyright 1995 by HOOD User s Group page 61 page 62 HOOD USER MANUAL 1 0 by HUM Working Group 0 0 g g Enforcing these two guidelines in object identification is a good start at our experience to come 1 to good solutions e the identification of objects based on conceptual modelling and abstraction allows to catch the good structure 1 e one that is possibly invariant
292. orking e Activity 3 Formalisation of the Strategy This activity consists in organising through a HOOD diagram the design of the solution previously described e Activity 4 Solution Refinement This activity consists in refining the previous solution tak ing into account particular project constraints e Activity 5 Formalisation of the Solution When the previous refinement is finished this ac tivity consists in detailing the solution in terms of textual descriptions ODS e Activity 6 Solution Analysis and Justification Main ideas of that process are to quickly build a first solution end of third activity which is the basis for a refinement activity 4 The method will constrain this solution according to good soft ware engineering and design principles in order to achieve a better solution The fourth activity then consists in modifying this solution according to other constraints in order to get the final so lution Figure 23 below gives a summary of activities of the basic design step and main outputs where as a detailed discussion is given below Outputs of activities are produced during the basic design step as text sections but may not all be included in a relevant ADD It is generally interesting to keep that information for the project history of for design justification Activity 6 In order to ease readability of the design documentation each activity output is numbered A pos sible numbering convention pre
293. oup page xviii Hoo j HOOD USER MANUAL 1 0 o J 9 page xix HUM 1 0 LIST of FIGURES Figure 81 Animation and prototyping Of MMIsS ou eee eeeeeeeeeeeeeeeeeseecaeeseecneenaeeaes Figure 82 Modelling DIALOG AUTOMATA with HOOD object Figure 83 HOOD Representation of callbacks oo lee ee eceeeeeeeeeeeeeeeeeseecneeseecaecnaeaes Figure 84 Isolating the application from GUIMS code eee Figure 85 Typical architecture of an Information System initial HOOD model Figure 86 Dedicated Object to handle Error and exceptions eeree Figure 87 Classical Top Down Approach Figure 88 Layered Bottom Up Approach Figure 89 Mixed Approa h rene are sesh sess sve east ss vtec opens ai eat tree S Figure 90 Definition of a disk driver and its associate properties Figure 91 defining an Array Needed ile atte neon dace Mie BS Figure 92 two different put operations Figure 93 instantiation of INPUT OUTPUT ins Figure 94 A generic stack providing a print Operation oe eee eeeeeeeseeeeeeetaeeneeenes Figure 95 an obj ct 1O SOLE data isoce on roie EE EE EEE EE R EEEE Somes iso douane Figure 96 Instance for sorting IteEgef ee eee ees eeeeseeseeeceeceeneesecnecaeeseesecaecaeeeceaeeaseeees Figure 97 Instance for Sorting String Figure 98 Generalization of the simple ADO BOUNDED_STACK Figure 99 Generalization of the simple ADT BOUNDED_STACKS
294. oural and non functional ones such as performances and pro duces a synthesis He performs design sensitive analysis upon them and possibly produces a user manual outline of the system to design NB It is here that the transition between reguirement analysis description of the WHAT and the design description of the HOW is made Activity Outputs H1 Statement of the Problem H1 1 Description of the problem and its context in a few sentences List of main design objectives Analysis and Structuring of the Requirement Data H1 2 analysis and definition of interfaces HOOD context diagram analysis of functional constraints analysis of behavioural constraints analysis of structural constraints analysis of non functional constraints user manual outline Only the System to design environment and the statement of the problem may have to be included in a relevant ADD 6 Functional constraints are constraints not related to any implementation they are just a result of the pure functional analysis T behavioural constraints are mostly analysed expressed using state transition models 8 data model constraints define all relationships between data identified at analysis level these are all constraints related to the particular target and context of the project performances reliability distribution main tainability etc Copyright 1995 96 by HOOD Users Group page 25 f page 26 HO
295. ourse materials developed by CISI and MMS On a more personal note we are especially grateful to the authors of observation reports on ear lier definition of the HOOD method and to all members of the HOOD TECHNICAL GROUP who contributed with many technical notes and to multiple and detailed discussions Special thanks for contributions from Giancarlo SAVOIA Rainer GERLICH Peter J ROBINSON and Andy CARMICHAEL The authors want also to thank all early readers for their comments and discussions which con tributed significantly on the elaboration of this manual Attendees of HOOD TECHNICAL GROUP included Edouard ANDRE Sema Group Jorge AMADOR ESA ESTEC Andy CARMICHAEL Systematica Javier CAMPOS GMV Bernard DELATTE CNES Jean Marie WALLUT CNES Pierre DISSAUX TNI Antony ELLIOT IPSYS Rainer GERLICH Dornier Winfried BOELKE ERNO Patrice Micouin Steria Alain Paul Andry Trasys Maurice HEITZ Cisi HTG chairman Jean Francois MULLER MMS HTG secretary Christophe PINAUD MMS Peter JROBINSON CANA Giancarlo SAVOIA Intecs We also acknowledge gratefully the support of Jardine BARRINGTON COOK chairman of the HOOD STEERING GROUP and the HSG secretariesPatrick Van der DONCKTand Guy PAQUET who provided the necessary liaison between the HOOD TECHNICAL GROUP and the HOOD USERs GROUP B DELATTE M HEITZ J F MULLER C PINAUD Editors Copyright 1995 96 by HOOD Users Group page vii page vii
296. ows the spaces defined by the object class and VN hierarchies the parent child hierarchical relationship DESCRIPTION Section H1 Section H2 Section H3 description Object CHILD1 description Object CHILD2 ODS CHILD1 ODSCHILD2 ODS CHILD3 DESCRIPTION DESCRIPTION DESCRIPTION Section H1 Figure 58 Relationships between parent and child ODS description sections 2 2 4 DOCUMENTATION ELABORATION Three states may be distinguished in the ODS life cycle see figure below e ODS CHILD only ODS fields associated to the interface or user manual are documented e ODS PARENT all fields of the ODS are completed Internal parts only have description of the implemented_by relationship between provided resources of the parent and the asso ciated ones of child objects e ODS TERMINAL all fields of the ODS are completed and refined in details especially the fields of the internals that hold the pseudo code and code parts Design step REFINEMENTS Design Step Verification Due Verification design step 2 Le ode Code Generation STEP VERIFICATION A STEP VALIDATION Figure 59 States in the ODS production life cycle Copyright 1995 by HOOD User s Group page 81 page 82 HOOD USER MANUAL 1 0 by HUM Working Group oof g J 2 3 EVALUATING A HOOD DESIGN When the design activities have produced HOOD designs taking shape with associated docu mentation verification activities shall take place to ensure
297. pdating the code fields of the ODS e Set the ODS under configuration 3 2 2 2 Maintaining consistency between Code and ODSs When the development is terminating end of integration or unit testing and before putting the product under configuration management and after a design modification e Generate code from ODSs with the HOOD toolset and save previous code versions e Modify that code only the one associated to ODS internal fields during coding and unit testing using the full power of usual development environment code editors browsers de buggers e Update terminal ODS fields from achieved actual targt code Such update requires using particular sofwatre which can defined using UNIX tools such as diff and sed and awk for example using a dedicated software program and commenting rules that would analyze the fianl ized target code recognize code include from ods fields and rewite that code back in the HOOD ODSs database Such a practice was used in several projects using a HOOD tool having an simple ODS database schema based on UNIX file system e Set the ODS under configuration 3 for example if an operation has been added in an HOOD object one should firts modify the design and then the ODS code field updates Copyright 1995 96 by HOOD Users Group page 188 page 189 I HOOD USER MANUAL 1 0 HUM 1 0 a De 3 3 REUSING ENVIRONMENTAL SOFTWARE NON HOOD CODE Environmental code should be specified whe
298. perties and oper ations one has just to redefine the methods which differ from the original This very powerful mechanism is known as inheritance and is supported by most Object Oriented program ming languages As the HOOD3 method does not support direct inheritance only the first method will be present ed in this part The reader shall be aware of the existence and the importance of the other tech nique which is known as the best reuse support technique at the programming level Studies in this direction are in progress in the context of ESPRIT PROTEUS project to allow the mapping into C a language providing inheritance mechanisms see part II of this document HOOD means Hierarchical Object Oriented Design We presented Object Orientation as a key point about the reusability Curiously the name of the method in itself contains all its advantag es and its drawbacks From the reuse point of view the Hierarchical aspect of the method is an important hindering The objects are distributed all over the design tree and one may be led to reuse a complete sub tree whether a linear design would have led to reuse just a couple of inter related objects Furthermore if a non terminal object has to be Adapted the modifications will be propagated to lower level objects and the repercussions may be difficult to evaluate In order to achieve this goal one must be aware of the fact that it is quite impossible to design from scratch a perfec
299. phs mean value range alarm red light EMS Sensors Timers_ Driver value value value Bargraphs value limited_value Alarm colour IDENTIFIERS OBJECT DATA X System to be designed 3 sensors environment 3 bargraphs system parameters sensor failure sensor failure XXX XX OK KX green light colour A1 2 2 IDENTIFICATION OF VERBS CONTINUE On IT reception from the Start push button the EMS is started if it was not Then the sensors of the EMS are sampled every 1 10 second by a signal from the timer Every second the mean values of oil pressure fuel level and water temperature are acguired from sensors and then displayed on the appropriate bargraphs If a mean value is out of range the alarm is switched on and the corresponding bargraph is displayed in red light If there is a sensor failure the alarm is switched on and the corresponding bargraph flashes in red light In the other cases the bargraphs are displayed in green light On IT reception from the Ack push button the alarm is acknowledged if it was not On IT reception from the Stop push button the EMS is stopped if it was not the alarm the timer and the sensors are stopped and the bargraphs are switched off Grouping Operations and Objects continue Server COMMENTS VERBS OBJECT IDENTIFIERS execution request par started EMS start on IT from Start button sampled Sensors sample every 1 10 second by a signal from timer every se
300. ple implicitly defines equality and assignment for both formal types items and keys even though the second example only defines assignment for items and equality for keys which is sufficient Although the first example seems shorter it makes too much assumptions on its formal parameters and is then less reusable 2 10 4 ADVANCED TECHNIQUES This section contains details on HOOD specific advanced techniques which are to be known by designers to build reusable and easily evolving designs Among these techniques are the use of classes and virtual nodes 2 10 4 1 Transforming objects into HOOD3 classes Coupling between objects has to be avoided as often as possible principle of weak coupling and especially for reusable objects A potential user is less ready to reuse an object if it requires the use of other parts which seem unnecessary This extra luggage wastes time and space Cou pling between reusable parts should only occur when it provides a strong benefit perceptible to the user A technique to postpone coupling is now presented When a reusable object needs services from some other ones it is possible to transform the direct dependency required interface into gener ic parameters class formal parameters OBJECT EXEMPLE is PASSIVE REQUIRED INTERFACE OBJECT LIST TYPES Lists OPERATIONS Insert List in out Lists Item in Elements Remove List in out Lists Item out Elements
301. pped Figure 31 State Transition Diagram modelling the behaviour of the EMS system Stop Copyright 1995 96 by HOOD Users Group page 46 page 47 j HOOD USER MANUAL 1 0 HUM 1 0 a De e Analysis of Non Functional Requirements The EMS must be reliable More sensors might be handled The EMS system might be connected to a general vehicle control system The values shall be smoothly displayed on the bargraphs particularly in case of sensor failure Thus the display device shall continuously evolve e User Manual Outline The values of water temperature oil pressure and fuel level are displayed in green light on three different bargraphs In case of sensor failure the corresponding bargraph flashes in red light and the alarm is started In case of a value is out of range the bargraph displays the value in red light and triggers the alarm The EMS can be started and stopped by using start and stop push buttons The alarm of the EMS may be switched off by the ack push button 1 5 2 3 Informal Solution Strategy H2 On IT reception from the Start push button the EMS is started the Ctrl_EMS inits the bargraphs starts the alarm and the sensors and creates and starts a timer which triggers the monitoring each second monitoring timer Initialisation of bargraphs switches on the hardware bargraph through the I O driver Starting the alarm switches off the hardware alarm through the I O driver Starting the sen
302. proach for Real Time Systems RTS considers the process as the unit of modularity HOOD on the contrary considers the object a grouping of services executed by processes as the unit of modularity What are then the possible HOOD approaches when faced with a development involving real Time constraints e CURRENT APPROACH e The current approach models processes as HOOD objects and expresses classically a design as a set of HOOD objects processes which interact through OS communication and synchro nisation mechanisms Figure 61 below gives an example of a HOOD object modelling a real time process 7__PROC2 OPCS start ASER_BY_IT loop gt start Po make the calculation Sleep 0 01 call to an OS service end loop end start Figure 61 Representations of tasks with HOOD e ADVANCED APPROACH e This approach tries to reconcile the structuring approach in terms of objects with the struc turing approach in terms of processes by considering a system as a structured set of heavy weight and lightweight processes as suggested in Ada9X and Mull90 Lightweight processes threads in some targets see last revision of UNIX V are imple mentations of logical processes that execute HOOD operations Thus these processes are used to implement light synchronization to access data mutual exclusion or monitors Lightweight processes execute all in a same memory partition Heavyweight processes are OS processes that define
303. producing successive refinements of an initial model down to the operational one with good traceability and high reuse potential The development approach is thus based on the following principles e Elaboration of an initial model or logical solution This model is an abstraction of a solution structured into HOOD object hierarchies where target implementation related elements are ignored Such a solution should be fully independent from target and non functional charac teristics languages targets efficiency distribution e Refinement of initial models HOOD refinement may simply add more details to existing characteristics or may also add new objects and or hierarchies of objects in the models thus allowing refinement trading off with non functional constraints such as existing of the shelf software target constraints as well as bottom up reusing development approaches Although such an approach is the technical way to go designers are generally reluctant to apply it They often fear having to break the initial model when they adapt and refine it according to their specific target or project constraints We believe however that it is always easier to develop a simplified system and possibly redevelop it than to start a system integrating all constraints from scratch Whatever the case developing an initial HOOD model is efficient in that e it provides at hand a prototype of a solution that highlights the logical properties of the
304. ption of the design documentation suitable for describing and checking HOOD designs Be aware that this is a design documentation description not to be con fused with a project documentation which may need additional documentation items depending on the used documentation standard 2 2 1 OBJECTIVES The HOOD design documentation shall favour communication and explication of a solution within a development team Thus it shall describe the software at different levels of details and abstraction Also it shall allow QA teams to check that both HOOD approach and description standards have been enforced during a development 2 2 2 DOCUMENTATION CONCEPTS HOOD models are represented through a data model where the ODS is the main structuring con cept The ODS Object Description Skeleton is a standard grouping of the object s characteristics organised in structured fields Informal textual descriptions are defined Description Interfaces Types Data Exceptions and Control Structures as well as associated semi formal descriptions Operations Types Exceptions Data Code of OBCS and OPCS Note that the ODS is a logical concept a physical representation of an ODS is a piece of text grouping the contents of the fields of an ODS into a human readable form This latter may take different layouts according to the documentation features of the HOOD toolsets and the purpose of the documentation The associated notations and formalisms can in fact be u
305. r Sensors Acguire Is Value out of Range PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Sensors SENSOR FAILURE PSEUDO CODE TBD CODE TBD END OPERATION Monitor END OBJECT Ctrl EMS Copyright 1995 96 by HOOD Users Group page 57 page 58 HOOD USER MANUAL 1 0 by HUM Working Group F J 9 1 5 4 EXAMPLE OF ADA CODE IMPLEMENTATION In the following we give the Ada code generated from the ODS of object EMS and Ctrl_Ems APPENDIX A2 of this document gives the same code where ODS text parts have been gener ated within the code as Ada comments with Ctrl EMS Alarm package EMS is DESCRIPTION procedure Start renames Ctrl_EMS Start procedure Stop renames Ctrl EMS Stop procedure Acknowledge renames Alarm Acknowledge end EMS Figure 34 Ada Specification associated to EMS ODS package Ctrl EMS is task OBCS Ctrl EMS is entry Start entry Stop entry Monitor end OBCS Ctrl EMS procedure Start renames OBCS Ctrl EMS Start procedure Stop renames OBCS Ctrl EMS Stop procedure Monitor renames OBCS Ctrl EMS Monitor end Ctrl EMS Figure 35 Ada Specification associated to Ctrl EMS ODS with Sensors with Alarm with Bargraphs with Timers Driver package body Ctrl EMS is IT 1HZ ADDRESS constant Monitor ADDRESS procedure Is Value out of Range procedure OPCS Start is separate procedure OPCS Stop is separate procedure OPCS Monitor is separate task body OBCS Ctrl EMS is begin
306. r C During the design process HOOD can be easily integrated with a reuse environment For large projects HOOD facilitates the share of work and sub contracting by a clear separation of the interfaces of the objects from their internal 1 4 2 SPECIFICATION TO DESIGN HOOD is not aimed to support requirements analysis It has been recognized that methods as IDEF structured analysis SA OMT OOA are more suitable to establish the functional break down of a system with the customer and user point of view Therefore there is the need to estab lish a mapping between the functional breakdown and the HOOD design objects tree which represents the designer point of view Unfortunately there is no trivial relationship between both representations Although there is no automatic way to find HOOD objects from the functional requirements analysis some heuristics have been established for the case of the IDEF method e the set of IDEF data inputs and outputs may be mapped into the HOOD objects and data flows e the set of the IDEF actions may be mapped into the set of operations of the HOOD design Other methods such as Petri Nets State Transition Diagrams are used for Real Time system spec ification SA RT and may provide essential inputs for describing the behaviour of HOOD active objects through the OBCS For large projects such as space software projects the joint use of functional analysis and archi tectural design approaches is ve
307. r_Station A distributed application is structured into virtual nodes accordingly to HOOD model Thus vir tual nodes are defined in a Virtual Node Tree where terminal virtual nodes are defined by allo cating HOOD objects from different HOOD Design Trees The interest of virtual nodes resides in the fact that they free the designer of the exact hardware configuration while designing software This very useful for reuse and evolution since the logical architecture is independent of distribution choices Within a terminal virtual node it is recommended to identify the different types of logical objects and to separate them in separate levels e the applicative level contains objects defined according to functional requirements They are independent of physical implementation and communication means e the basic level contains objects dealing with physical implementation and communication means independently of the application e the intermediate levels contain objects allowing the two previous levels to communicate An example of such an organisation is given in Figure 105 The applicative level is isolated in Simulation_Application which implements real services TCP_IP_Interface be longs to the basic levels and provides communication with the virtual node Operator_Station Operator_Station_Interface is a virtual server object of the intermediate level Controller manage the application and receive messages from ICP IP Interface
308. ramming language or ADT toward HOOD ODS and Ada or ADT towards HOOD ODS and a sequential language Figure 107 below illustrates such a model represented with HOOD graphical formalism Four objects associated to four development lines partition the system into technological modules that exchange data that are again described through HADT objects represented as uncle objects where e the access interface to a datum with all services provided to its clients is formalised by the set of operations that manipulated the associated type creation update of a sub field read delete checks etc ina HADT object e further refinement of HADTS producing HADTS of less complexity up to terminal specifi cation directly implementable in a target OO language is based on the graphical extension and visibility restrictions outlined in section 4 3 above e ADT_Applis_DATA groups the definition of HADT objects associated to data exchanges be tween MMI and or APPLICATION e ADT_KNW_DATA groups the definition of HADT objects associated to data exchanges be tween the inference system and the DBMS e ADT_DBMS_DATA groups the definition of HADT objects associated to data exchanges be tween MMI and or APPLICATION with the DBMS where either dataflows between DBMS and APPLICATION and or MMI are direct instances of Copyright 1995 96 by HOOD Users Group page 138 page 139 j HOOD USER MANUAL 1 0 HUM 1 0 a J te abstract data types associated
309. range 0 100 0 COLOUR T BARGRAPH COLOUR GREEN FLASH T BARGRAPH FLASH STATUS OFF when SENSOR gt NUMBER INTEGER range 1 MAX SENSORS NUMBER 1 VALUE INTEGER range 0 100 0 when ALARM gt NUMBER INTEGER range 1 MAX_ALARMS_NUMBER 1 end case end record The T_DESCRIPTOR type defines the set of information which may be sent to output devices or received from input de vices OPERATIONS Put DEVICE in T DEVICE Output Device ELEMENT in T_DESCRIPTOR Descriptor to apply to a device The Put operation allows to write information included in the provided descriptor to the hardware device corresponding to the specified one Get DEVICE in T_DEVICE Input Device ELEMENT out T DESCRIPTOR Descriptor including information from device The Get operation allows to copy the current information provided by the hardware device corresponding to the provided one into the provided descriptor EXCEPTIONS MALFUNCTION RAISED_BY Put Get This exception is returned when the hardware device specified in the Put or Get operations is unavailable END OBJECT Input Output Driver Copyright 1995 96 by HOOD Users Group page 52 page 53 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 1 5 3 2 PARENT OBJECT EMS OBJECT EMS IS ACTIVE DESCRIPTION The EMS monitors and displays the oil pressure water temperature and fuel level on the appropriate bargraphs and starts an alarm in case of a value is out of a pred
310. ration t define the system configuration e performing the first basic design step decompose the root STD into child objects t update the system configuration If child objects are similar or reusable If child objects have to be sub contracted they will have to be included in the system config uration t update the system configuration e iterating basic design steps up to a level of detail enough for direct implementation and cod ing The basic design step is applied in the same way whatever the level of design It provides activ ities to be performed by the designer thus allowing for large systems improvement of the man agement procedures by allowing the distribution of design and development as well as the definition of milestones providing unique visibility over work progress Copyright 1995 96 by HOOD Users Group page 32 page 33 0 0 j HOOD USER MANUAL 1 0 HUM 1 0 a De Q Basic Design U Steps Figure 24 Application of Basic Design Steps to the system configuration The general principles of the HOOD design approach are top down in order to reduce and master complexity Moreover HOOD offers to a designer a client server model of representation at dif ferent levels of abstraction and refinement through parent child composition but always keep ing consistency with initial representations of the design Such properties are exploited in the framework of complex system developments by
311. rence des Utilisateurs Informatigue du CEA Grenoble juin 1993 MHULL93 Introducing formal methods to HOOD M E C Hull amp P G o Donoghe Univer sity of Ulster Proceedings of the International Conference on Software Engineer ing Toulouse Nov 1993 FM93 Ensembles de mesures applicables a la m thode HOOD F MAURICE A BEN ZEKRI V VALETTE Proceedings of the International Conference on Software Engineering Toulouse nov 1993 6 2 4 ARTICLES AND PAPERS PUBLISHED IN 1992 ANDER92a HOOD as a basis for OBJECT_ORIENTED PROGRAMMING J A ANDER SON SYNETICS Proceedings of the Ada Eurospace Conference Vienna No Copyright 1995 96 by HOOD Users Group page 208 Hoo page 209 HOOD USER MANUAL 1 0 HUM 1 0 ANDER92b ANDR92 Chand92 CHIA92 DEM92 DENSK92 GAJET92 LAC92 MAR92 MARRD92 MH92a MH92b NAND92 PAPAIX92 POU92 ROB92 vember 1992 INCORPORATING MANAGEMENT INDICATORS INTO HOOD J A AN DERSON SYNETICS Proceedings of the Ada Eurospace Conference Vienna November 1992 Reverse Engineering from Ada to HOOD P ANDRIEU C ALVAREZ JA ES TEBAN SEMA group Proceedings of the Ada Eurospace Conference Vienna November 1992 Risk Reduction on Huygens Programme through Prototyping in the early Life Cycle Phases S CHANDLER P ADVIES J HARBONNE LOGICA Proceed ings of the Ada Eurospace Conference Vienna November 1992 Ada and HOOD for the development
312. rm object manages a set of software alarms One hardware alarm is associated to those software alarms It is possible to switch a software alarm on or off at each time The hardware alarm is started when an unset software alarm is switched on set The hardware alarm is stopped when the set of software alarms are switched off unset or when acknowledged by the user In that case the status of the set software alarms are not modified 1 5 2 4 b Identification of operation H3 2 Object Input_Output_Driver e Put The Put operation allows to write information included in the provided descriptor to the hardware device corresponding to the specified one e Get The Get operation allows to copy the current information provided by the hardware device corresponding to the provided one into the provided descriptor Object CTRL_EMS e Start creates the monitoring timer initialises the alarm the sensors and the bargraphs which are used during the monitoring e Stop stops the monitoring timer and switches off the alarm and the bargraphs and stops the sensors e Monitor acquires the values of each sensor Those values are displayed on the appropriate bargraph In case of a value is out of range this operation switches the alarm on and gives the red colour to the bargraph If there is a sensor failure the alarm is switched on and the bargraph flashes in red colour In other cases the values are displayed in green colour Object SENSORS e St
313. rmal strategy a description of the object is provided In Activity 4 formalisation of the solution the relevant fields of the ODS are filled Environment object If the Environment object does not already exist reuse objects the pro vided interface of the ODS should be created in Activity 4 e Class Each Class should be designed separately as a root object of a new system to design outside the design in which its instances are used There is no basic design step to be per formed for an instance of a Class e Virtual node The basic design step performed for the Virtual Node follows the general schemes of a non terminal object As an illustration of the basic design step activities a simple example is detailed in Section 1 5 below 1 3 2 THE OVERALL HOOD DESIGN PROCESS The previous basic HOOD design process allows to build a unique HDT In order to take into account project management constraints such as subcontracting parallel development reuse system design etc The designer has to include new principles allowing to build the whole sys tem configuration with the different spaces The overall HOOD design process thus consists in see also Figure 24 below e defining the system to design as an interface with respect to its environment t define a root STD object and environment objects If one plans to reuse objects or classes from a previous project they will have to be included in the system configu
314. roup B DELATTE M HEITZ JF MULLER editors HOOD User Manual HUG C O SPACEBEL INFORMATIQUE 111 rue Colonel BOURG B 1140 BRUSSELS BELGIUM Tel 32 2 730 46 50 fax 32 2 726 85 13 B DELATTE M HEITZ Experimenting Reuse with HOOD and Ada in Proceedings of Ada Aerospace Conference BRUSSELS November 1993 ISO IEC JTC1 SC22 N1451 Ada9X Reference MANUAL Version 4 0 Septem ber 1993 ISO IEC JTC1 SC22 N1382 Draft Standard for EXTensions for Real Time Ada version 3 0 october 1993 ANSI X3 J16 Draft proposal for the programming language C AT amp T June 1993 Davis A Comparison of Techniques for the specification of external System Be havior Communications of the ACM Vol 31 n9 1989 Copyright 1995 96 by HOOD Users Group page 204 page 205 l HOOD USER MANUAL 1 0 HUM 1 0 J 9 AQS91 Ada Quality and Style Guidelines froProfessional Ada Programmers Ver sion 02 Software Productivity Consortium 1991 ASX94 Schmidt D ASX 1994 An Object Oriented Framework for Developping Dis tributed Applications Proceedings of the 6th USENIX C Conference Cam bridge MA April 1994 BERARD85 Ed Berard Object Oriented Design Handbook for Ada Software EVB document1985 BERRY 88 G Berry Ph Couronne G Gonthier Synchronous Programming of Reactive Sys tems an introduction to Esterel INRIA Report 647 1988 BOO 87 G Booch Software Componenet with Ada Structures Tools and S
315. rt such checks based on automata behavioural equivalence using the INRIA AUTO tool and or through temporal logic formula as described in LECMP89 Neverthe less such proof systems have exponential complexity for concurrent systems A Heibig HEI91 states that his compositional semantics of control machine have linear complexity Advances in the area of logic checkers and concurrent system evaluation tools will strongly impact on the choice of formal notations for developing critical systems 2 11 3 3 Defining an Associated Verification Process Once the approach has been experimented it can be automated and supported by a selected set of toolsets The verification process is anyway improved and better quality and confidence in the resulting software will be achieved e OBCS behavioural descriptions can be produced verified through simulation if notations used to express OBCS behaviours are supported by simulation environments verified through execution when code is generated Test cases and scenarios elaborated in previous development phases may be reused developed and tested separately from the development of the sequential software As a re sult of this separation more verification and testing effort in terms both of time spent and skills of developers can be allocated to this critical part of the software e Integration will be based on three strategies several synchronous automata working in parallel seeFigure 12
316. rver object to perform it thus every object has a unique identifier and may be referenced unambiguously A service is an abstraction of an operation or an access to an attribute component of the state of an object Each service has a signature expressed using an Ada like syntax which defines the number and type of its arguments The set of signatures constitutes the provided interface similarly the re quired interface comprises the set of signatures of the required services Communication between objects the USE relationship is only possible by service requests which are similar to Small talk method calls or Ada procedure or task entry calls e there is a many to one connection pattern reflected by the naming scheme e the provider of the service must be named by the client e the name of the client is not directly known by the server e aclient object requesting a service from a server object is said to use the server and this re lation is represented by a bold use arrow e information items can be exchanged between communicating objects the associated infor mation flow may be bidirectional and is represented by arrows along the use relationship one see Figure 3 ASER CLIENT by Supervisor Start Stop Put Get Get_Status Figure 3 Objects providing and requiring services and exchanging information items Communication protocols may be achieved by attaching execution requests and constraints to a given
317. ry fruitful For such systems it is useful to establish an overall architectural design which needs to be refined with the help of a functional analysis This is the concept of Z strategy which mixes the func tional and the architectural analysis see Figure 27 Each terminal object of the level 1 which may correspond to a large subsystem will be decomposed according to a functional analysis with a method as IDEF Then a further architectural design step is applied on each object This process is done until the level of complexity of the identified objects allows to start the detailed design One can see that this strategy is fully compliant with the HOOD basic design step Copyright 1995 96 by HOOD Users Group page 38 page 39 HOOD USER MANUAL 1 0 HUM 1 0 SWRD i System Level v Requirement Architectural Analysis Design SRD ADD Requirement il Sub System Level Analysis SRD ADD Assembly Level A unique and Consistent HOOD Design Requirement Analysis SRD i gt Architectural To detailed design Product Level SRD Software Requirement Document ADD Architectural Design Document Figure 27 The Z strategy This strategy leads to establish a set of requirement documents SRDs of a manageable size in cluding some independent specification models whereas the HOOD design models included in the different ADDs are compl
318. s 157 2 12 3 4 Generation rules for active objects 157 2 12 3 5 Entity Naming ss 558 thats k ddd 8 dn 8 dote K Wee EA Us ere nie eo 157 2 12 3 6 Conventions for C targets ss 157 2 12 3 7 Code generation for Environments objects 157 2 12 4 Object Oriented Language Targets 158 2 12 4 1 Designing for OOPL implementation HOOD3 1 158 2 12 4 2 Other Conventions for C ses 158 2 12 4 3 Implementation of state constrained operations 158 2 12 4 4 Implementation of protocol constrained operations 159 2 13 FULL ADA CODE ILLUSTRATION 161 2 13 1 TERMINAL PASSIVE OBJECT 161 2 13 1 1 ODS Definition for passive STACK object 161 2 13 1 2 Ada code generation for passive STACK object 163 2 13 1 3 ODS Definition for passive STACKS 164 2 13 1 4 Ada code generation for passive object STACKS 166 2 13 2 TERMINAL ACTIVE OBJECT 167 2 13 2 1 ODS Definition for active object STACKS 167 2 13 2 2 Ada code generation for ACTIVE OBJECT STACKS 171 2 14 NO TASKING ADA CODE ILLUSTRATION
319. s active it is not recommended The Ada language allows the building of correct concurrent ADT but it is not a simple matter Booch has proposed different models for concurrent ADT in the famous GON 90 the guarded form the concurrent form and the multiple form GON 90 has proved that at least the concurrent form was erroneous because it was depending on the parameter passing semantics which can differ from a compiler to another Finally CAR 91 proposed a seemingly correct form for concurrent ADTs This form relies on a Task type hidden by a private type definition Even if this model seems to be correct and satisfactory it is not easy to use it with the HOOD formalism With HOOD the principle of active objects is that the behaviour is described within the OBCS and typically the OBCS is one task In any case as explained in CAR 90 the use of Abstract State Machine i e Abstract Data Object is a good software engineering practice for concurrent components Advice 28 Use HOOD Classes to implement Abstract Data Types and Abstract Data Objects independently of their component data type Comments this is the standard way of generalizing ADT and ADO Example The example of the bounded stack shows different means to represent the size constraint of a bounded structure e a provided constant in BOUNDED_STACK and BOUNDED STACKS MAX STACK SIZE is a provided constant used in internals as the size of the array implementing the stack
320. s no way to ask information about the state of the object is the stack empty is the stack full what is the value on the top of the stack Such kind of operations is important for the reusability of the object but is less useful in a concurrent context The last point to mention is the fact that operations are constrained It can be in contradiction with the exception declaration pop and push may be guarded by blocking conditions so that the X_OverFlow and X_UnderFlow situations of the stack will never happen In any case we have shown that the only formal information contained in the provided interface is subject to multiple interpretations the informal fields must be used to clarify the designer in tentions 2 1 1 2 Abstract Data Type Abstraction Defining an Abstract Data Type ADT is very similar to Object Abstraction as presented above but instead of designing a single object a general model of similar objects is defined In fact at least in its passive form an ADO can be seen as an instance of an anonymous ADT Instead of only providing operations for manipulating internal hidden data a private type is also provided with the same set of operations Each provided operation has an additional parameter describing which object is manipulated Internally data is not directly declared but the private type is pre cisely defined This type will be used by clients to declare data of this type in their own context s
321. s the Virtual Node Tree VNT of the system 2 1 Overview 2 2 Hardware Physical Environment This section defines the operational physical environment of the system to be designed in terms of processors stations etc on which the system will run 2 3 Resources Allocation This section defines the allocation of the Virtual Nodes to the Physical Nodes 2 4 Software Environment This section defines the operational software environment that means all software in communication with the system to be designed 2 4 1 Overview 2 4 2 Functioning This section explains the following graphical description in terms of data handling through operations of the different virtual nodes 2 4 3 Graphical Description This section gives a context diagram of the root virtual node defining the system to be designed It is defined with a HOOD diagram including the system virtual node and all other virtual nodes communicating with the system 2 5 Dynamic Architecture This section describes general principles of the dynamic architecture such as time management tasks or process organisa tion and synchronisation between them performance principles software starting etc 2 6 Static Design This section gives the static decomposition of the system first in virtual nodes and then into objects allocated in the terminal virtual nodes 2 6 1 Overview 2 6 2 Design Tree This section gives a synthetic view of the virtual nodes hierarchy from the root until a
322. s to gain an understanding of the architecture so that they are confident in the progress of the technical work Thus the doc umentation should target the understanding of the system and provide support for the checking of the object interfaces the level of confidence achieved after the review is such that these are FROZEN and put under change control Such a documentation may contain the description of the system_configuration of concern for each system configuration hierarchy the description of the design tree for each object of the hierarchy Problem definition section H1 1 graphical description of its environment extracted from section H1 2 2 if the current ob ject is a root otherwise from H3 4 of the parent of the current object decomposition into child objects and the textual description of how it works if the current object is non terminal extracted from sections H2 H3 1 H3 2 H3 4 et H3 5 its PROVIDED INTERFACE extracted from ODS Copyright 1995 by HOOD User s Group page 84 page 85 HOOD USER MANUAL 1 0 HUM 1 0 its input and outputs DATAFLOWS et EXCEPTION_FLOWS extracted from ODS description of its dynamical behaviour extracted from ODS OBCS fields verification reports upon the design steps 2 3 2 3 Summary on Documentation and Reviews Basic Design Step Activities Activity Outputs DEFINITION of Problem Textual Description of Requirements Textual Description of Requirements
323. s_Driver TYPES T_TIMER OPERATIONS Create Start Delete DATAFLOWS data_in lt Input_Output_Driver initial_frequency gt Timers_Driver EXCEPTION_FLOWS malfunction lt Input_Output_Driver INTERNALS OBJECTS NONE TYPES T_SENSOR_STATUS is INITIALIZED STOPPED T_HARDWARE_SENSOR_STATUS is FAILED OK TBD CONSTANTS IT 10HZ ADDRESS constant Sample ADDRESS SAMPLING FREOUENCY constant 10 TBD OPERATIONS Store_Value SENSOR in T_SENSOR VALUE in POSITIVE STATUS in THARDWARE_SENSOR_STATUS Get Last Value SENSOR in T SENSOR VALUE out POSITIVE STATUS outT HARDWARE SENSOR STATUS TBD Copyright 1995 96 by HOOD Users Group page 220 page 221 HOOD USER MANUAL 1 0 HUM 1 0 OO g J EXCEPTIONS TBD DATA SAMPLING_TIMER Timers_Driver T_TIMER WATER_SENSOR OIL_SENSOR FUEL SENSOR Input_Output_Driver T_DEVICE SENSOR SENSOR STATUS T SENSOR STATUS STOPPED TBD OBJECT_CONTROL_STRUCTURE PSEUDO_CODE TBD CODE TBD OPERATION_CONTROL_STRUCTURES OPERATION Start DESCRIPTION This operation initializes the hardware sensors and then creates and starts a timer for it triggers the sampling every 10 sec onds The sensors status are set to INITIALIZED I USED OPERATIONS Timers Driver Create Timers Driver Start Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE
324. sed for e informal verification through author reader cycles of textual descriptions e design verification designs checks pseudo code e code generation for prototyping e code generation for final products The SIF Standard Interchange Format is defined for design exchanges with other HOOD tool sets or development tools It defines formally the layout in ASCII format of files containing ODS representation in ASCII TEXTs Hence a SIF representation of an ODS is a valid one but may not be a very readable document 2 2 3 DOCUMENTATION MANAGEMENT The HOOD documentation shall be structured as sets of ODSs where all or part of the ODS fields are present depending on the type of document that is produced For example a design doc umentation for an architectural document shall group together a set of ODSs with text sections associated to the basic design step activities included in the DESCRIPTION field of the ODS of the OBJECTS under review We recommend to structure parent ODS with their DESCRIPTION field structured into H1 H2 and H3 text sections H3 is a text comprising the textual description of child objects and operations that can also be taken again as the H1 texts of the ODS associated to the child objects Copyright 1995 by HOOD User s Group page 80 page 81 HOOD USER MANUAL 1 0 HUM 1 0 A HOOD documentation defines accordingly as e aset of ODS each being unique in the documentation e a structure that foll
325. ses the system the alarm the bargraphs the sensors and then creates and starts a timer for it triggers the mon itoring every 1 second USED OPERATIONS Timers Driver Create Timers Driver Start Sensors Start Alarm Start Copyright 1995 96 by HOOD Users Group page 230 page 231 HOOD USER MANUAL 1 0 HUM 1 0 OO g J Bargraphs Init PSEUDO_CODE TBD CODE begin Timers_Driver Create MONITORING_TIMER MONITORING_FREQUENCY IT_1HZ_ADDRESS Alarm Start Bargraphs Init Sensors Start Timers Driver Start MONITORING TIMER Monitoring Timer is started only when all the hardware devices are initialised end OPCS Start END OPERATION OPCS Start OPERATION OPCS Stop procedure OPCS Stop is DESCRIPTION This operation stops all the system the alarm the bargraphs the sensors and resets the monitoring timer USED_OPERATIONS Timers_Driver Delete Alarm Stop Bargraphs Switch_Off Sensors Stop PSEUDO_CODE TBD CODE begin Timers_Driver Delete MONITORING_TIMER Sensors Stop Alarm Stop Bargraphs Switch Off end OPCS Stop END OPERATION OPCS Stop OPERATION Is Value out of Range procedure Is Value out of Range is DESCRIPTION TBD USED OPERATIONS TBD PROPAGATED_EXCEPTIONS TBD HANDLED EXCEPTIONS TBD PSEUDO CODE TBD CODE begin null TBD end Is Value out of Range END OPERATION Is Value out of Range OP
326. skeletons to be provided to a Schedulability analyser Figure 128 and Figure 129 describe the process model of the building of the threads execu tion skeletons with estimations of worst case execution times to be used for schedulability anal ysis while Figure 130 provides an example of an ODS with such annotations Annotation editor Compiler Builder HOOD objects Annotate HOOD Generate Compile and objects code Build Annotated compilation unit E E lt Unrealistic reduction Reduce flow graph unbounded loops Review reduced graph Operation or thread flowgraph Operation Thread Reduced flow graph Figure 128 Timing estimations Analysis of each HOOD object Copyright 1995 96 by HOOD Users Group page 153 page 154 I HOOD USER MANUAL 1 0 by HUM Working Group a De Reduced flow graphs Replace external calls Develop and reduce defined in conf file Reduced flow threads to obtain thread exec profile graphs Superseded flow graphs Execution skeleton Supersede Operation Review of execution WCET skeleton To schedulability analyser Figure 129 Timing estimations Build overall execution skeleton OBJECT Objet1 IS ACTIVE DESCRIPTION IMPLEMENTATION OR SYNCH RONIZATION CONSTRAINTS Annotation with performance constraints DURATION_CONSTRAINT DC1 The response time of Operation1 shall be less than 5 ms
327. so as e to design an object that implements a STACK abstract data type and exporting the ots type T_STACK e using an external type T Status defined in the environement object PROJECT ENV the associated ODS would be the following 2 13 1 3 ODS Definition for passive STACKS A passive STACKS object implementing an Abstract Data Type for STACK data may be rep resented as in Figure 136 with two operations PUSH and POP We have added also an envi ronement object PROJECT ENV for providing the definition of the type T Status ADT Element I CE POP STATUS g PROJECT_ENV Figure 136 Graphical representation for the active object Stacks The ODS of Figure 137 shows the ODS declarations of provided and required types and oper ations and exceptions OBJECT STACKS IS PASSIVE 1 DESCRIPTION Implementation of a abstract Data Type STACK with no encapsulation of data instances IMPLEMENTATION_CONSTRAINTS none PROVIDED_INTERFACE TYPES type T_STACK MAX integer is private definition of type T_STACK as private OPERATIONS Push Stack In Out T_stack Element In T_element Pop Stack In Out T_stack Element Out T_element Status STACK in out T STACK return T Status EXCEPTIONS X EMPTY raised by POP X FULL raised by PUSH REOUIRED INTERFACE OBJECT ADT ELEMENT TYPES T_Element ISTACK requires type T Element provided by ADT ELEMENT OBJECT PROJECT ENV TYPES T States STACK reguires type T STATES provided
328. sors starts the hardware sensors and creates and starts a timer which triggers the sampling at 10 Hz sampling timer When the sensors are sampled every 1 10 second by a signal from the timer the values and the status malfunction of each sensor are get from the hardware sensors through the I O driver Every second the monitoring activity is triggered by a signal from the timer the Ctrl_EMS ac quires the status and the mean values of oil pressure fuel level and water temperature from sen sors It compares them with the limited values If a mean value is out of range or a sensor has failed the Ctrl EMS switches the alarm on with the type of sensor and the type of failure If there is no failure and the mean value is correct it displays each mean value on the appropriate bargraph sets the colour in green stops flashing and switches the alarm off If a mean value is out of range the corresponding bargraph is displayed in red light If there is a sensor failure the corresponding bargraph flashes in red light An even tual malfunction of the hardware bargraphs or the hardware alarm is of no effect on the Ctrl_EMS On IT reception from the Ack push button the alarm is acknowledged On IT reception from the Stop push button the EMS is stopped if it was not the alarm the mon itoring timer and the sensors are stopped and the bargraphs are switched off Switching the bar graphs off stops the hardware bargraphs switches light off and put
329. ss 89 Figure 63 Representation of semaphores 5eme deep ns tin ins caren iey 90 Figure 64 Representation of mail BOXES ispeci setecseabessibeassscsensoepageacdepes cbse ssbbaes ods oby paie aa ess 90 Figure 65 Representation of shared areas ss 90 Figure 66 Representation of vents 4e nt ANT bn NE ES Te de Sn 91 Figure 67 Initial representation of a RT architecture oe ese ceeceecseeeseceseeseceeceseceeceseeeeeeseeeeseseeees 91 Figure 68 Explicating inter process communications 92 Figure 69 initial representation of a VN architecture 00 lees ceceeeseeceseesececeseceseeseeeeeseeeeeeaeeees 93 Figure 70 Explicit inter VN communications ss 93 Figure 71 Implementation Of a VN iii 94 Figure 72 Principle of additional code to the logical model one in the physical model 98 Figure 73 Execution Model for protocol constrained operations for VN eee 99 Figure 74 OPCS ER code Sample for STACK PUSH client stub operation 99 Figure 75 OPCS_SER codefor STACK PUSH RB operation 100 Figure 76 Architecture Principle of the VNCS software ss 100 Figure 77 Illustration of ServerVNCS Message in code ss 101 Figure 78 Illustration of ServerObcs code of an allocated object in a remote VN 102 Figure 79 Illustration of the representation of the physical model at terminal level 104 Figure 80 Generic Architecture for MMIS ss 106 Copyright 1995 96 by HOOD Users Gr
330. ss objects servers which define new HDTs HDTs and CDTs defined during that phase constitute the Implementation Environment and the System Configuration is completed accordingly Copyright 1995 96 by HOOD Users Group page 36 page 37 i HOOD USER MANUAL 1 0 HUM 1 0 a De 1 3 5 PHASE 3 DISTRIBUTION This phase deals with the distribution aspects The logical architecture has to be mapped to the infrastructure architecture This mapping is mainly driven by performance issues such as com munication overload time constraints It consists in the following activities a further refinement of the VNTs identified in phase 2 e an allocation of objects from HDTs to terminal VNs of the VNT During that phase the analysis of performance constraints may lead to reallocation of objects onto different VNs or to the creation of new VNs The analysis of data sharing conflicts may lead to further decompositions of the objects or to allocation of objects in a same VN Implementation or logical USE links may also be identified Interfaces between the different VNs have to be minimized During that phase some modification on the logical architecture can be foreseen mainly to solve data sharing conflicts or to add new objects in the implementation environment 1 3 6 PHASE 4 PHYSICAL ARCHITECTURE This phase consists in the allocation of the VNs onto the physical architecture It consists in the following activities e identification o
331. sts in defining objects with operations that are not part of their own functionalities but those of the system itself Objects must be understood as servers or tools that help solving the problem but that should not solve a part of the problem by themselves Example Suppose that we want to count the occurrence of each word in a text Objects as Text Word and Occurrence model the problem space Then we need an object Map in order to associate the words with their running occurrence The good design practice is to design or to reuse a general map that associates the keys here words with their values here words occurrences Operations can be for instance Add_a_new_key Change_the_value_of_a_key Retreive_a_value_from_a_key A less correct design solution would have been to define a specific map that automatically increments the value each time the key is used with operations like Add a new key Increment_the_value_of_a_key It would have been interesting but not so much in the context of this particular problem but would have lost its generality and then the opportunity to be reused elsewhere Furthermore the increment operation is quite easy to implement by a simple expression of the general set of operations Change_the_value_of_a_key by the value Retrieved from_the_same_key incremented by one Advice 2 Do not over specify objects Comments In the opposite a well intended designer may want to create real reusable objects
332. t This operation initializes the hardware bargraphs Bargraphs are switched on in green colour without flashing and with a null value Display BARGRAPH in T BARGRAPH VALUE inT PERCENTAGE This operation displays the input percentage value in the corresponding hardware bargraph The colour and the flashing are not modified Set Colour BARGRAPH in T BARGRAPH COLOUR in T COLOUR This operation sets the corresponding hardware bargraph in the specified colour The displayed value and the flashing are not modified Flash BARGRAPH inT BARGRAPH STATUS inT FLASHING This operation allows to flash the corresponding hardware bargraph The colour and the displayed value are not modi fied l Switch Off This operation switches the hardware bargraphs off l REQUIRED_INTERFACE OBJECT Input_Output_Driver TYPES T_DEVICE T_DEVICE_STATUS T_BARGRAPH_COLOUR T_BARGRAPH_FLASH_STATUS T_DESCRIPTOR CONSTANTS MAX_BARGRAPHS_NUMBER OPERATIONS Put EXCEPTIONS MALFUNCTION DATAFLOWS data_out gt Input_Output_Driver EXCEPTION_FLOWS malfunction lt Input_Output_Driver INTERNALS OBJECTS NONE TYPES TBD CONSTANTS TBD OPERATIONS TBD DATA WATER_BARGRAPH OIL_BARGRAPH FUEL_BARGRAPH Input_Output_Driver T_DEVICE BARGRAPH TBD OPERATION CONTROL STRUCTURES OPERATION Init Copyright 1995 96 by HOOD Users Group page 223 ALANS page 224 0 0 HOOD USER MAN
333. t T_Element internal DATA SIZE integer 100 DATA T_DATA 1 SIZE TOP integer 1 STATUS T_Status procedure PUSH Element in T_Element is begin TOP STACK LAST use of Ada Attribute functions SIZE_STACK STACK RANGE if TOP lt SIZE_STACK then STACK STATUS busy STACKis used by some one TOP TOP 1 STACK DATA TOP Element put Element STACK STATUS idle STACK code is idle else STACK STATUS undefined STACK code is in undefined state raise X_FULL end if end PUSH procedure POP Element out T_Element is similar to that of PUSH seen above procedure Status return T_Status is begin returnSTATUS end STATUS end STACK Figure 135 Ada body Unit for passive object STACK In this package body we can see that the following translation rules have been applied e Internal types and constants are mixed together in the order of which they appear in the ODS allowing correct Ada references from each other e internal data are translated without any changes Copyright 1995 96 by HOOD Users Group page 163 page 164 j HOOD USER MANUAL 1 0 by HUM Working Group I 9 e the OPCS of an operation is translated into a procedure of function body as such Note how ever that the user must supply the keyword begin but not the keyword end in the ODS code section To see some more about translation rules and especially about private typ s lets now modify the previous example
334. t be modified Either is it due to syntactic errors or has the code to be adapted to the specific target or it is due to an error in the code gener ation from the toolset 3 2 2 MASTERING THE RELATIONSHIP BETWEEN ODS AND CODE FILES According to our experience on earlier HOOD projects where a complete separation was en forced between code and the ODS descriptions we think that ODS code descriptions fields must be managed in configuration together with the final code Otherwise a gap always exists between HOOD ODS descriptions and the final code and developers tend to rely only on the code con sequently the goal of HOOD to achieve reliable high level descriptions of less complexity and volume than code is missed We may distinguish two types of code e Code corresponding to architectural concepts such as modules in C or packages in Ada WITH clause in Ada or Include in C provided types constants etc e Code defining control structures of operations algorithms corresponding to detailed design and coding activities Any modification on the first point relies from an Architectural Design activity and modification of operations internal code relies from a Coding activity Thus an important rule is that modification performed directly in the source code shall not im pact the design no modification at the interface level for example Two methods may be defined for handling code consistency with design descriptions E
335. t generation Copyright 1995 96 by HOOD Users Group page 40 page 41 j HOOD USER MANUAL 1 0 HUM 1 0 a De The relevant code for the test monitor and test simulator may be automatically generated from the analysis of the design Thus HOOD may support several testing strategies e module testing is defined as the activity of validating the behaviour of an operation with re spect to its interface specification e a bottom up test strategy would start with objects that are only used e atop down test strategy would require main control flows to be completed and stubs provid ed for other operations e asub tree approach would allow parts of the HOOD hierarchy to be developed as sub trees providing successively more functionality across the design 1 4 4 2 Verification and Validation One of the major problem encountered during the development of RT amp E Real Time and Em bedded systems is the V amp V Verification and Validation activity during all the life cycle phases in order to detect errors very early during the development Early verification allows to go further in the development steps from a consolidated and validated basis A key feature of V amp V activity is the verification of the dynamic behaviour of the system under design Techniques in software verification can be classified into two categories e Verification by simulation is running a system or a subset of the system with a selected set of input data an
336. t operations For users of toolsets not supporting VNs the following steps should be performed Elaboration of a logical model with associated code generation and execution For this create a SYSTEM_CONFIGURATION with relevant hierarchies of objects that defines the system_to_design with its environments objects objects common to those of STD hierar chies as well as exiting and environmental software Elaboration of the implementation model by allocating objects with the following con straints only terminal VN can have allocated objects child objects are either the VNCS the remote calling objects generated with ERCODE or the remotely called objects generated with SERCODE Environment objects of this VN are either the local objects allocated or the remotely called VNS For this create a new SYSTEM_CONFIGURATION with its relevant hierarchies that de fine the system_to_design as a hierarchy of VNs When the decomposition of VNs ap pears to be deep enough allocate objects of the logical model to only terminal VNs For each such terminal VN create VNCS ER and SER children and create environment objects that correspond to remotely VNS Finally create within the implementation SYSTEM_CONFIGURATION root objects associated to the previous environment objects through copy to root from objects of the logical SYSTEM_CONFIGURATION Use then an ODS editor and modify the OPCS code fields so as to implement the encoding
337. t reusable object The first version is often a draft and further versions fol low with improvements and modifications A real problem occurs with all the design documents Copyright 1995 96 by HOOD Users Group page 117 page 118 I HOOD USER MANUAL 1 0 by HUM Working Group a De is it possible desirable to rewrite all the stuff at each new version This document will show that there are different kinds of designs some of them are likely to change rapidly some others may be stabilized more rapidly The first category does not need to be to much well documented al though the second one is more ready to this work 2 10 2 TOP DOWN amp BOTTOM UP APPROACHES Traditional software development methods enforce a top down approach see figure 87 This is quite a natural way of thinking and has big advantages for building complex systems it gives a method for breaking down a system in smaller parts easier to tackle directly When those parts are still too big to be treated they can be broken down again Finally this is a good way of build ing rapidly a solution of a given problem child level 2 child level 3 Design process child level 4 a Figure 87 Classical Top Down Approach New development methods based on the object oriented technology tend to renounce to this type of approach and insist more on bottom up processes see figure 88 It cons
338. that the design has been pro duced right and hence is possibly the right design Those verification activities have been to our experience the most troublesome issues so far in the HOOD projects This is because the HOOD design representation may cover several models several objects several system config uration and are possibly constrained to be materialised in enormous linear paper documentation mixing several textual and graphical formalisms In the following we suggest a representation of the HOOD development process as a set of states where the transition from one state to another is triggered after a verification step 2 3 1 DEFINITIONS 2 3 1 1 Goal of HOOD design verification Verification activities take place after design activities and have both technical and organisation al goals e technical goals A HOOD design is a representation of a SYSTEM TO DESIGN which starts with a de scription of a PARENT root object with respect to its Environment and is refined into successive descriptions of child objects In order to ensure consistency of these successive representations up to the detailed design architecture definitions HOOD defines rules and additional verification procedures may be ensured within each object s scope for each par ent child decomposition step and from step to step up to terminal objects are reached Consistency of aHOOD model has to be checked throughout the HOOD process HOOD rec
339. the HOOD documentation associated with the initial model e Definition and contractual allocation of development tasks for subcontractors accord ing to the work breakdown established above e Level validation allowing development factorisation of common resources through for mal reviews Such reviews are only mandatory for developments that produce new objects in their refinements e Pre integration and integration of object subsystems subcontracted Subcontractors can start pre integration on their own sites if they can access to the prototypes developed by their prime on its own site or not e Final Integration and validation This task is mandatory performed on the prime site During all the development consistency and configuration management of the global HOOD model can nevetheless be ensured thanks to the concepts of environment objects and system con figurations Two concepts shall be distinguished see Figure 157 below e the global system configuration of the project at prime level Such a configuration shall be handled at HOOD level and shall define the configuration of the project by integrating all ob ject and class hierarchies e the local system configuration of a subcontractor Such a configuration is at least the one de fining the context of the hierarchy associated to the local development The subcontractor will enrich it with new environment objects and classes as he progress in refinement his ob ject subsyste
340. the element is defined and used This index will be very useful for integration phase and maintenance activity 3 1 1 2 Example of ADD Contents 1 System Software General Overview 1 1 Main Functions This section introduces the main functions of the system or software to be designed its aim and mission 1 2 Overall Organisation This section describes the general system organisation and gives some justification on it 1 2 1 System Configuration This section introduces all the design trees used to define the whole system VNT HDTs CDTs and links between them 1 2 2 Applicative Environment This section describes the HDTs and CDTs defining the Applicative environment 1 2 3 Implementation Environment This section describes the HDTs and CDTs defining the Implementation environment 1 2 4 Justification of Organisation This section gives some explanation about the project organisation 1 3 Development Constraints This section gives some particular development rules or constraints i e the language a real time monitor 1 4 HOOD Tool This section includes the used HOOD tool presentation Copyright 1995 96 by HOOD Users Group page 182 page 183 HOOD USER MANUAL 1 0 HUM 1 0 F J 9 A chapter 2 X and Y is dedicated to each design tree from the VNT to the HDTs and the CDTs covered by the ADD 2 lt System gt Design For the Virtual Node if any describing the system to be designed This chapter describe
341. the field IMPLEMENTATION_CONSTRAINTS of the corre sponding object description see Figure 124 IMPLEMENTATION_OR_SYNCHRONIZATION_CONSTRAINTS PERFORMANCE CONSTRAINTS One description of constraints for each operation impacted by one or several constraints OPERATION Name_op1 One constraint description for each constraint impacting the operation SDURATION CONSTRAINT THROUGHPUT CONSTRAINT constraint_expression END_PERFORMANCE CONSTRAINTS 1 informal expression or semi formal expression based on the use of some attributes defined in the tax onomy of performance requirements Figure 124 Annotation with performance constraints Copyright 1995 96 by HOOD Users Group page 150 page 151 j HOOD USER MANUAL 1 0 HUM 1 0 I d e Annotation by utilization rate constraints As these constraints constrain hardware components it is not possible to associate them with HOOD design components since the method only addresses software components these an notations shall be associated with the description of the physical architecture which identifies hardware components and connections between them 2 11 4 4 b Annotating a HOOD design with execution profiles For each HOOD operation impacted by performance constraints we propose to annotate the DESCRIPTION field of the corresponding OPERATION CONTROL STRUCTURE with the operation execution profile in the way described on Figure 125 OPERATION Name lt
342. the specified software alarm on If this alarm was not yet set the hardware alarm is started if it was not In the other cases nothing is modified Switch Off ALARM in T_ALARM The Switch Off operation switched the specified software alarm off If the hardware alarm is yet started and all the other software alarms are unset the hardware alarm is stopped l Stop The Stop operation switches the hardware alarm off l OBJECT_CONTROL_STRUCTURE DESCRIPTION The Alarm accepts an Acknowledge operation only before a Stop and after a Start The Acknowledge is not significant if the alarm is not previously set l CONSTRAINED_OPERATIONS Acknowledge CONSTRAINED_BY ASER_by_IT Ack_push button REQUIRED_INTERFACE OBJECT Input_Output_Driver TYPES T_DEVICE T_DEVICE_STATUS T_DESCRIPTOR CONSTANTS MAX_ALARMS_NUMBER OPERATIONS Put EXCEPTIONS MALFUNCTION DATAFLOWS Copyright 1995 96 by HOOD Users Group page 225 page 226 HOOD USER MANUAL 1 0 HUM 1 0 OO g J data_out gt Input_Output_Driver EXCEPTION_FLOWS malfunction lt Input_Output_Driver INTERNALS OBJECTS NONE TYPES T_SOFTWARE_ALARM_STATUS is ON OFF Define the two possible status of a software alarm l T_HARDWARE_ALARM_STATUS is ON OFF Define the two possible status of a hardware alarm T_SOFTWARE_ALARMS is array T ALARM RANGE of T_SOFTWARE_ALARM_STATUS Define the set of software alarms TBD CONSTANTS TBD
343. tion Concept cerere piinia e he Pew bbe he tae dat e 115 2 9 2 Errors handling i ei ssf sete nt aerate a Fs Bene ia si aed eae BAe Roe ead a Seed eae 115 2 9 3 Suggested solution 115 2 10 REUSING HOOD DESIGNS 117 ZO OVOrvi w 3 sy nn nn ce v te OAR de AS ES ee eee 117 2 10 2 Top down amp bottom up approaches 118 2 103 General guidelines sisis ori re faune pete use nus eae Eat tendant desire 120 2 10 3 1 General design techniques 121 2 10 3 2 Classified guidelines for reuse and evolution 122 2 10 4 Advanced techniques sss 24348208 ete as BRA OU due et sees 131 2 10 4 1 Transforming objects into HOOD3 classes 131 2 10 42 Using Virtual nodes ses 132 2 10 5 Summary on HOOD amp Reuse 134 2 10 5 1 What to Reuse ss scene 134 2 1052 How to DoiReusable ss sb sean hit ol sn rs see 134 2 11 HOOD AS A COMMON DEVELOPMENT FRAMEWORK 136 2 11 1 Integration of MULTIPLE DEVELOPMENT TECHNOLOGIES 138 2 11 2 Conceptual and behaviours Modelling 140 2 11 3 Dynamic behaviour Modelling 141 2 11 3 1 Extended Object Execution Model
344. tion sets the specified software alarm to OFF if it was not If all the software alarm status are OFF it stops the hardware alarm if it was not and sets the hardware alarm status to OFF I USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Switch Off OPERATION Stop DESCRIPTION The Stop operation switches the hardware alarm off l USED OPERATIONS Input Output Driver Put PROPAGATED EXCEPTIONS NONE HANDLED EXCEPTIONS Input Output Driver MALFUNCTION PSEUDO CODE TBD CODE TBD END OPERATION Stop END OBJECT Alarm Copyright 1995 96 by HOOD Users Group page 227 page 228 HOOD USER MANUAL 1 0 HUM 1 0 OO g J A2 EXAMPLE OF ADA CODE IMPLE MENTATION OBJECT EMS IS ACTIVE INTERNAL OBJECTS Ctrl EMS Alarm Sensors Bargraphs with Ctrl EMS Alarm package EMS is DESCRIPTION The EMS monitors and displays the oil pressure water temperature and fuel level on the appropriate bargraphs and starts an alarm in case of a value is out of a predefined range First the EMS shall be started It may be stopped at any moment IMPLEMENTATION_OR_SYNCHRONISATION_CONSTRAINTS Start Stop and Acknowledge operations are mutually exclusive each of those operations shall wait the end of an other one before to be started PROVIDED_INTERFACE OPERATIONS procedure Start renames
345. tivity should be in a significant state i e con tain only the required information for the activity to be conducted Also the document should be consistent that is information pieces contained shall be in consistent state one with each other e Documents for checking ODS consistency If the object was decomposed the check will look for consistency between parent descriptions and child implementations Information items needed are Foranon refined object its ODS in state CHILD Fora refined object its ODS in state CHILD its ODS in state PARENT if it was decomposed into child objects otherwise its ODS in state TERMINAL The contents of an ODS in state CHILD is given in appendix A4 1 The contents of an ODS in state PARENT is given in appendix A4 2 The contents of an ODS in state TERMINAL is given in appendix A4 3 e Documents for Design Step Checking The goal here is to check consistency between the child and parent descriptions of the decomposed object and between the parent descriptions and child implementations Thus the information items needed are the two ODSs associated to the PARENT i e the ODS in state CHILD and the same ODS in state PARENT the ODSs in state CHILD of the child objects Ifthe verification addresses a set of N basic design steps then a set of N such documents would be reviewed e Documents for REVIEWS The goal here is for reviewer
346. tly and concisely non nominal behaviours However it also presents a number of draw backs which lead us to advice very limited usage e First of all the implementation of exceptions in target other than Ada sets problems of cor rectness and validation of the equivalent software behaviour e Moreover an exception describes an abnormal flow of control in reverse of the use relation ship More precisely an exception is implemented as the asynchronous execution of the exception_handler call within the client code instead of normal return after service call Thus exception execution means asynchronous executions that render very difficult exhaustive testing and hence render difficult maintenance and mastering of all possible states of the software under development Hence we recommend e use only HOOD exceptions when the target language is known to be Ada e limit as much as possible the use of EXCEPTIONS in the design e always treat the exceptions locally in order to avoid propagation and side effects of asyn chronous processing 2 9 2 ERRORS HANDLING When developing large software general principles of error handling must be applied and en forced in order to standardize modularize and reuse error handling code A basic principle is to handle errors locally i e as they are detected since the error context is then available Error handling may be centralized or distributed However for ergonomic reasons complexity decrease a
347. ts are reformulated and how one can go towards an Informal Solution Strategy in informal natural language e g English From this text nouns may be identified as candidate objects and verbs may be identified as corre sponding candidate operations This process is repeated for each object that is decomposed The intent of an object is to represent a problem domain entity either a real world object or a data structure and the object should act as a black box by hiding the data and allowing access only through operations thus allowing easy testing debugging and maintenance The principles of abstraction and information hiding provide the main guidelines for assessing an object thus a good object represents an encapsulation of a problem domain entity and hides internally information that is likely to change if the implementation changes One can define a scale of abstraction ranging from the real world object to purely logistic objects as follows e Entity abstraction represents a useful problem domain entity Such an entity would be as concrete as a hard ware device or more abstract such as a compiler intermediate file e Action abstraction a child object that represents the state of a parent object can be seen as an abstraction of the actions of the parent object This may have a State Transition Diagram and may be Active or Passive according to the type of the parent object e Logistic abstraction an object that represents a data st
348. ture The latter supports a stepwise development and integration approach allowing functional testing and final integration leaving functionally tested code unchanged Hence the execution of a remote opera tion can be implemented by defining e on the local node a client operation stub that encodes the parameters into a network mes sage say MSG and waits operation parameters return according to the communication pro tocols defined between the two remote objects e on the remote node a server will decode the network messages and perform the effective call to the operation and return parameters back through a special return_message network This return message is then processed by a message_server from the original calling node and parameters are send back to the original client object Figure 72 below illustrates the principle of adding code to existing code generated in a non distributed or logical solution and functionally tested When an object is allocated to a VN the generated code associated to the local OPCS consists e OPCS_ER Opcs_Execution Request code and performs the encoding of the request into the l This is done by having the associated process hold on a signal which is sent as soon as the return param eters have been copied back to the client process memory Copyright 1995 by HOOD User s Group page 97 page 98 HOOD USER MANUAL 1 0 by HUM Working Group oof g J network message suitable for the
349. ture and Specifica tion OMG doc PALU90 Vallette Paludetto et Courvoisier LAAS Generation de code Ada en conception orient e Objects HOOD R seaux de Petri Proceedings des Journ es Internation ales Le G nie Logiciel et ses Applications Toulouse D cembre 90 Copyright 1995 96 by HOOD Users Group page 206 page 207 l HOOD USER MANUAL 1 0 HUM 1 0 J 9 Reisig85 W Reisig Petri Nets An Introduction Springer Berlin 1985 SCHMIDT95 Schmidt D Stephenson P 1995 Using Design Patterns to Evolve System Soft ware from Unix to WIndows NT C Report 1995 March 1995 SOUROU9S Sourouille JL H Lecoeuche 1995 Integrating State in an OO Concurrent Mod el Proceedings of TOOLS EUROPE95 Conference Prentice HAII STROUS91 Strousoup B 1991 The Annoted C Reference Manual Addison Wesley Press VIEL89 P Vielcanet HOOD Design Method and Control Command Techniques for the Development of Real Time Software Proceedings of ADA Conference Wash ington June VINO93 Vinoski S 1993 Distributed Object Computing with CORBA C Report vol 5 VINO95 Vinoski S Schmidt D 1995 Comparing Alternative Client Side Distributed Programming Technigues C Report 1995 May June 1995 issues PFA85 G E Pfaff User Interface Management Systems Seeheim 1983 Springer Verlag Copyright 1995 96 by HOOD Users Group page 207 page 208 j HOOD USER MANUAL 1 0 by HUM Working Group
350. uage class definition When a target language class is so identified it is only defined as a HOOD type and through its provided operations and when the detail design is performed the designer may e use attribution for defining properties and data structures common for all instances of the class e use inheritance in order to factor attribute and operations declaration while sharing the asso ciated code with the inherited class 2 1 3 4 c Implementation Refinement This kind of refinement is as the modular refinement we stress it here only to recall that the de signer may elaborate a logical solution that relies on software layers that isolate the system to design from the specificities of the target infrastructure and OS This kind of refinement is illus trated in Figure 57 is one way to take into account the non functional constraints such as e reuse of software architecture or components elaborated project by project in a given appli cation domain e development with unclear requirement or where full target requirement are not yet fixed at the time of the design Copyright 1995 by HOOD User s Group page 78 page 79 HOOD USER MANUAL 1 0 HUM 1 0 Producer_Consumers Figure 57 Refinement Techniques of a HOOD model Copyright 1995 by HOOD User s Group page 79 page 80 HOOD USER MANUAL 1 0 by HUM Working Group 0 0 g J 2 2 THE HOOD DESIGN DOCUMENTATION In the following we give a descri
351. ubsystems The Benjamin Cummings Publishing Company 1987 BOO86 Booch Grady Object Oriented Development IEEE Transactions on Software Engineering Vol SE 12 February 86 BOO 83 G Booch Software Engineering with Ada The Benjamin Cummings Publish ing Company 1983 CAR 91 JR Carter Concurrent Reusable Abstract Data Types ACM Ada Letters Vol XI Number 1 jan 1991 CAR 90 JR Carter The Form of Reusable Ada Componenets for Concurrent Use ACM Ada Letters Vol X Number 1 jan 1990 CCITT89 CCITT International Telecommunication Union Instructions for SDL Users Recommendation Z 100 Annex D Vol X Fasc X 2 Geneva 1989 Clark86 E M Clarke E A Emerson and A P Sistla Automatic verification of finite state concurrent systems using temporal logic specifications ACM Trans Prog Lang Syst 8 1986 244 263 GIOVA89 R Di Giovanni P L Iachini HOOD and Z for the development of Complex Soft ware Systems Lecture Notes in Computer Science n 428 VDM 90 VDM and Z FORMAL METHODS in SOFTWARE DEVELOPMENTS GON 90 D W Gonzalez Multi Tasking Software Components ACM Ada Letters Vol X Number 1 jan 1990 Copyright 1995 96 by HOOD Users Group page 205 page 206 i HOOD USER MANUAL 1 0 by HUM Working Group J 9 Harel85 D Harel and A Pnueli On the development of reactive system in K R Apt ED Logics and Models of Concurrent Systems Springer New York 198
352. ued Copyright 1995 96 by HOOD Users Group page 14 page 15 j HOOD USER MANUAL 1 0 HUM 1 0 J 9 1 1 6 FROM ARCHITECTURE TO TARGET IMPLEMENTATION HOOD defines code generation rules allowing the definition of target units and modules by ex traction of code fields from the ODS e HOOD entities declaration such as OBJECTS PROVIDED REQUIRED INTERFACE TYPES OPERATIONS and EXCEPTIONS are target language independent and can be used to build a target unit architecture using visibility and encapsulation mechanisms as available in the target language system e The associated body fields are target language dependent and are directly included in the right place within the target skeleton architecture mapping HOOD objects to target units Encapsulation mechanisms provided by the lan guage and target environment are used For e g a Ada package or a C or C module de fined by two files with extension h and c is associated to each HOOD object implementation of object relationships INCLUDE relationships will be implemented by encapsulation mechanisms visibility mechanisms such as the use of Ada with clauses and possibly direct file inclusion at source code level USE relationships will be imple mented trough target language mechanisms controlling intra and inter unit visibility and possibly by using code inclusion as e g in C or C HOOD has standard code generation rules for the Ada language sinc
353. unc tional code This could be done by defining for each active object lt NAME gt e the original object of name lt NAME gt _SERVER where constrained operations are reduced to state constrained operation s and OPCS structured into HEADER BODY and FOOTER parts e a client code part as an object named lt NAME gt providing unconstrained operation with same signatures as the protocol constrained one from the original object and having OPCS implementing OPCS_ER code e a request_broker code part as an object named lt NAME gt _RB providing unconstrained op erations with same signatures as the protocol constrained one from the original object and having OPCS implementing OPCS_SER code which require operations provided by lt NAME gt _SERVER Such strategy is illustrated in Figure 162 below generic pacakge BUFFERS of the EXTRA proposal ISO JTC1 SC22 WG9 RRG Work Item Number JTC 1 22 35 31 03 93 gives already specifications of such code Copyright 1995 96 by HOOD Users Group page 236 ALAS page 237 0 0 HOOD USER MANUAL 1 0 HUM 1 0 Original Active Object Associated Objects to support protocol constrainec operation without tasking Figure 162 Principle of Code for Protocol Constrained operation support Copyright 1995 96 by HOOD Users Group page 237 page 238 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J A3 2 HOOD4 ADA CODE ILLUSTRATION A3 2 1 HOOD4 STATE CONSTRAINT SUPPORT The approach ta
354. up page 135 f page 136 j HOOD USER MANUAL 1 0 by HUM Working Group De 2 11 HOOD AS A COMMON DEVELOPMENT FRAMEWORK A commonly agreed observation on software development projects is that a unique method can not cover all development activities This is why HOOD has always to be put in work together with different methods either in the upper or lower phases of the design activities Some projects came even to the conclusion that since the design activities are central in the development life cycle HOOD could be used as the framework for integrating the different development activities and methods Software development consists in fact in producing successive models of the future system using methods and models at different levels of abstraction that are each time better suited to the goals of a current development activity e conceptual analysis models are used in the upper phases and activities to describe the prob lem entities with terms entities abstractions that are from the domain and in a way com pletely independent of any implementation choice e design or architecture models allow to describe the components of a solution that can be associated to a problem description in terms of structures abstractions and behaviours implementation models allow to describe the mapping of previous functional components onto an execution structure that is tools and supporting services of the target system In order to produce a
355. uration PRIME LEVEL SYSTEM_CONFIGURATION GLOBALIS ROOT OBJECTS LOCAL1 SYSTEM CONFIGURATION ROOT OBJECTS A B X UNIX SS1 SS3 CLASS OBJECTS ADT Message Stack List Mngt END SUBCONTRACTOR1 LEVEL LOGAL2 SYSTEM CONFIGURATION ROOT OBJECTS A B X UNIX SS1 SS3 SS2 SA SB SC SS2 SA SB SC Oueues Windows TLMs CLASS OBJECTS ADT_Message Stack List_Mngt LOCAL3 SYSTEM_CONFIGURATION YSTEM CONFIGURATION ROOT OBJECTS XNSSSSNN NS NNNNNNNN NN N KAB Xs UNIX SS1 SS3 SA VS M N amp NN NNN NNN X N N 3 SUBCONTRACTOR2 LEVEL Figure 157 Consistency of multi System Configurations Copyright 1995 96 by HOOD Users Group page 193 page 194 j HOOD USER MANUAL 1 0 by HUM Working Group J 9 3 4 3 CONFIGURATION MANAGEMENT 3 4 3 1 Principles The principles of configuration management are to master the definition of components of a product Within a HOOD development the ODS is the primary unit of configuration and at any moment the configuration of a HOOD development is defined by the associated ODSs If we admit that the code is generated directly from a HOOD toolset with possibly a few addi tional modification procedures all additional procedures shell sed make for building the exe cutable programs should also be configuration items Moreover we have seen that t
356. urrent system and for which the root is seen as an environment object from the STD The object is then decomposed into child objects which can themselves be further de composed until the specifications of child objects can be directly implemented in the target lan guage A STD can thus be represented as a root object of a HOOD design tree HDT where branches represent parent objects decomposed into child objects and where leaves are terminal objects which are no more decomposed Figure 20 hereafter represents a STD as a root of a hierarchy of objects within a whole project including other hierarchies other HDTs PROJECT Element of the system to design IE Element of the system used by the STD through its root Element of an other system of the Project not used by the STD Figure 20 A System To Design within a whole project Client server use relationships are not shown Thus a project is defined by a set of root objects each of them being considered in turn as the STD by a development team all others appearing as potential environment objects for this par ticular system Copyright 1995 96 by HOOD Users Group page 19 page 20 j HOOD USER MANUAL 1 0 by HUM Working Group J 9 1 2 2 SYSTEM CONFIGURATION In order to manage HDTs through interface descriptions still consistent with their environment a HDT is defined within an object space comprising the
357. ush Buttons Figure 158 The EMS System SENSORS gonver ensor failure gt Figure 159 The EMS Hardware Block Diagram Copyright 1995 96 by HOOD Users Group page 216 page 217 HOOD USER MANUAL 1 0 HUM 1 0 0 0 g J A1 1 2 CLIENT REQUIREMENTS e The EMS software is running on the CPU using an Input Output and a Timers drivers e The values of water temperature oil pressure and fuel level are displayed in green light on three different bargraphs each second In case of sensor failure the corresponding bargraph flashes in red light and the alarm is started In case of a value is out of range the bargraph displays the value in red light and triggers the alarm e The EMS can be started and stopped independently of the car engine by using start and stop pushbuttons e The alarm of the EMS may be switched off by the ack push button e More sensors might be handled e The EMS must be reliable e The EMS system might be connected to a general vehicle control system A1 13 SOFTWARE ENVIRONMENT The Timers_Driver object manages a set of timers which send cyclic interruptions at a spec ified address Each timer is first created with given frequency and address A timer then may be started or stopped at any moment It may also be deleted from the list of available timers The Input_Output_Driver object provides means to exchange information with hardware de vices It
358. ut of the Justification of Design Decisions part of the HOOD design step When object is an instance of a class it could be interesting to explain the reason of that choice reusability similar objects Copyright 1995 96 by HOOD Users Group page 183 page 184 HOOD USER MANUAL 1 0 by HUM Working Group F J 9 For each decomposed Object allocated in the previous Virtual Node Tree or the Object to be de signed X lt Object gt Object Design This chapter describes the Design Tree of the object X 1 Overview X 2 Environment This section defines the object environment that means all environment objects used by the object to be designed X 2 1 Overview X 2 2 Functioning This section explains the following graphical description in terms of data handling through operations of the different objects X 2 3 Graphical Description This section gives a context diagram of the root object It is defined with a HOOD diagram including the object to be designed and all used environment objects X 3 Static Design This section gives the static decomposition of the object into child objects include relationship until terminal objects X 3 1 Overview X 3 2 Design Tree This section gives a synthetic view of the objects hierarchy from the root object until terminal objects For each Object or Object Instance of the Design Tree X 3 x lt Object gt Object X 3 x 1 Overview This section gives a presentation o
359. vailable which support more or less all these functions Some tools also offer cross reference generation documentation configuration ac cording to standards ESA COLUMBUS DOD2167 For a potential user and a part from the user interface which is more or less going to standardise according to MOTIF standards an important evaluation criteria is the support of the HOOD 3 1 and especially e generation of object descriptions in SIF format e import of object descriptions in SIF format This enables a user to change toolsets without losing a database of designs produced with the old toolset Also a user may work and develop with the toolset of his choice and finally integrate and deliver on customer HOOD tool e Support of System Configuration allowing easy reuse of existing designs and classes and definition of the scope of the design checking space Copyright 1995 96 by HOOD Users Group page 202 QU O HOOD USER MANUAL 1 0 oe 5 CONCLUSIONS We have shown that the possibilities of the HOOD method allow to set up development strategies with improved support for the production decomposition refinement test and reuse of models Today HOOD offers thus several advantages in terms of contribution to productivity and guality especially when used with integrated tools such as CASE Computer Aided Software Engineer ing environments Productivity is improved thanks to a hierarchical decomposition approach allowing the progres
360. viour and states that was defined in a requirement analysis or MMI prototyping phase The MMI part can then be entirely prototyped using an UIMS User Interface Management System APPLICATION Applicative code independent of the WINDOWING SYSTEM ASER by DIALOG_AUTOMATA Module_INterface start ASER by X Window_INTERFACE ASER by X X_Events X_callbacks UIMS init dependent code get_action get_widget curseur_ops screen ops widget ops E X WND WINDOWS amp WIDGETs D generated by UIMS Device_actions UIMS generated code Figure 80 Generic Architecture for MMIs The DIALOG AUTOMATA object should map the user intercations modelled through a hierar chic state transition diagram the MMI interactions can be structured through states e g log ging identification consultation update supervision administration etc where only specific functions and widgets can be activated Copyright 1995 by HOOD User s Group page 106 page 107 HOOD USER MANUAL 1 0 HUM 1 0 Such modelling and definition may be developed through prototypes or following a hierarchical Dialog structure approach and possibly together with the final user However we consider this modelling is part of the requirement analysis and should be available when the HOOD design is started Also the above generic architecture allows to develop a MMI prototype not to be confused with above one used f
361. vities Design quality relies on ISS text actions and data Activity Outputs H2 A clear and concise text expliciting the solution This text will have to evolve as the design ma tures during the design step as well as to be consistent with the graphical description elaborated during the third activity 10 The structure of the system is described we still do not know how it works Copyright 1995 96 by HOOD Users Group page 26 f page 27 I HOOD USER MANUAL 1 0 HUM 1 0 a J d Activity 3 Formalisation of the strategy Activity Inputs Input of the current activity is an informal textual description of a solution scenario Refine and work out your solution This phase has as goals the extraction of the major concepts of a solution strategy in order to come smoothly to a formalised description of the previous solution through a HOOD diagram The idea is that a solution which can be expressed clearly in natural language is an almost mas tered solution A good set up of the previous activity leads into identification of objects through nouns and op erations provided by those objects though verbs Thus the current activity may consist in e identifying nouns ex The user requires a chocolate from the vending machine nouns which provide services are generally good candidates for objects ex vending ma chine provides services nouns which does not provide services define main dataflows of the d
362. wever to be used for children associated to generic packages in order to give visibility to the formal parameters parameters of generic Ada units Copyright 1995 96 by HOOD Users Group page 16 f page 17 i HOOD USER MANUAL 1 0 HUM 1 0 a J a 1 1 6 2 Implementation of Constrained Operations When an operation execution is constrained its activation is related to the object state and or to a given communication protocol to be enforced between the current object and the client The implementation principle illustrated in Figure 18 is to introduce additional code upon the body of an OPCS which will handle these constraints as the body of the associated operation will ex ecute CLIENT Process OPCS_BODY part Figure 18 HOOD 3 Code structure for constraint operations The idea is that most of the code associated to the constraints could be automatically gener ated and can be defined once for all so that the designer and coder has only to do with the core OPCS body Moreover this separation allows to do feasibility analysis prototyping of real time behaviors completely in parallel with the development of the functional code of a system the pure opcs bodies The implementation schema is that the OBCS is implemented as a or more target unit in Ada it is a package or task generally named OBCS which handles execution requests and operation execution via calls to an associated procedure named by convention OPCS_ lt
363. when the team is new or has very few HOOD practice When launching a HOOD project it is mandatory to allocate a recognized HOOD tutor to the team experience has shown that trying to correct errors late e g at the time of the ADR may cost very more and has fewer chance of success It thus important that the tutor is available right at the elaboration of the top level design and that he injects back all its experience to the new team Area of expertise where the tutor may jump in may vary e launching the project configuring the HOOD toolsets development environment e defining the project approach e author reader cycles on the first informal strategies etc Copyright 1995 96 by HOOD Users Group page 200 page 201 I HOOD USER MANUAL 1 0 HUM 1 0 a De 4 METHOD SUPPORT AND EVOLU TION 4 1 THE HOOD USER GROUP Early HOOD users have founded the HOOD User Group 4 which has as objectives exchanges of experience data and method requirements repository and evolution control of the HOOD method thus e warranting the method stability taking into account users needs e warranting method output and user design perenniality e taking into account technological and standards evolution The HUG means are the set up of HOOD Working Groups and a technical committee HOOD Technical Group which validates and agrees on the HWG recommendations and technical doc uments such as e definition of textual and graphical forma
364. xt was well written or is well understood Copyright 1995 96 by HOOD Users Group page 27 De f page 28 i HOOD USER MANUAL 1 0 by HUM Working Group Activity 4 Refinement of the solution Activity Inputs Current solution of the design expressed with consistent textual description of the ISS H2 and graphical description H3 Review and agree on your solution before formalizing it Output of the previous activity may not be considered as the final HOOD design but as a prelim inary version used to support discussion between designers Indeed designers have to introduce specific project constraints behavioural and dynamic ones attributes relative to parallelism syn chronism periodic execution or even build prototypes to check particular points and then to modify the solution Thus this activity has to be included between the formalisation of the first solution and the final ization of the last one Advantage of the previous activities are that all designers work from a same design graphical and textual which has a good quality level It is relevant to stress that the graphical description goes with the textual descriptions and vice versa and that the consistency between these two kind of representations shall always be en sured This activity also consists into review and author reader cycles on produced HOOD diagram and textual descriptions An important part of that activity consists in expressin
365. y 3 Formalisation of the strategy This activity consists in giving for each OPCS corresponding to provided operations and OBCS a detailed description of implementation with a pseudo code This description highlights control structures Activity 4 Refinement of the Solution From the previous OPCS description the designer has to identify new internal types constants exceptions and new internal operations in order to complete the ODS internals description Activity 5 Formalisation of the Solution This activity consists in finalize description and definition of internal declaration types con stants exceptions and data description and pseudo code of OBCS and OPCSs Activity 6 Analysis of the Solution Applied to the internals of the ODS this activity consists in a author reader cycle on Control Structures algorithms Analysis will also highlights introduction of internals declarations types constants exceptions data and internal operations Copyright 1995 96 by HOOD Users Group page 31 page 32 j HOOD USER MANUAL 1 0 by HUM Working Group a De 1 3 1 4 The Basic design step applied to the other types of object The way the HOOD basic design step is applied to other types of objects may slightly vary e Op_control An Op control is a terminal object which is used to map parent operation to mul tiple child operations Activity 2 to 4 are relevant for such an object In Activity 2 Elabora tion of an info
366. y all project members e Experience on earlier HOOD projects has shown that author reader cycles on more formal ized notations was almost useless and that short author reader cycles are mandatory with Copyright 1995 by HOOD User s Group page 85 page 86 HOOD USER MANUAL 1 0 by HUM Working Group oof g J a low volume of information to be checked The end of H3 is the ideal time for a effi cient reading of the solution later it will often be too late to impose changes in the solution e Moreover the next phase of formalisation of the remaining fields of ODS is a work that will require much more efforts and which can only be checked by motivated people which are specialized ones in the notations used Ada C STDs or C e theimportance of the understandibility of the texts produced in sections H2 and H3 Ex perience has shown a bad tendency for HOOD designers to produce cryptic H2 and or H3 descriptions often because they do no really see why they have to produce these text sec tions because they always think the important thing is the code We take her the opportu nity to recall that good design is something that reads clearly most of these texts may be extracted to setup a design document for a formal project REVIEW where people from different application areas may participate In that case these descriptions in section Hi are primary elements for quality and complexity mas tering
367. y to validate the dy namical behaviour of the system integration by replacing simulated code by delivered final code The Subcontractor HOOD Activities Are Mainly Concerned With e responsibility of a complete hood sub tree internal design activity performed according to the interfaces defined validated and agreed with prime Copyright 1995 96 by HOOD Users Group page 42 7 f page 43 HOOD USER MANUAL 1 0 HUM 1 0 possible pre integration activity 1 4 7 PHASED INCREMENTAL LIFE CYCLE On large projects requirements definition is a non monotone function of the development pro cess requirements become more and more precise and mastered as the project goes forward Large projects developments have been compared to cathedral building and such top down de velopment are now more and more questioned The risk of such projects can however be limited and at the same time conforming their develop ment to an organisational management model model of the V cycle by splitting the project into phases each of which is conducted as a subproject with deliverables and possibly an own V life cycle In order to achieved some efficiency inputs of a phase may be taken from outputs of a previous one The way the initial partitioning is done is of course of prime importance for the success of the project but hood recommends to follow a phased approach in order to limit this risk e start first by defining a l

Download Pdf Manuals

Related Search

Related Contents

Razor Scooter E300 User's Manual  Télécharger PDF  ESX QUANTUMQ-One  Installation, Use & Care Manual  High speed dome camera en    

Copyright © All rights reserved. Failed to retrieve file