ENHANCING CRITICAL SOFTWARE DEVELOPMENT USING HOORA/HOOD AND UML-RT Xavier Méhaut, Marc Richard-Foy Aonix - Critical Software Solutions Department ! +33/0 1 41 48 11 29 http: //www.aonix.fr or //www.aonix.com [email protected], [email protected]

Keywords critical software, quality, UML/ROOM, HOORA, HRT-HOOD, norms and standards

Abstract Among the various classes of software, critical software is undoubtedly the one which requires the most development and tuning efforts since the constraints in terms of architecture and software are quite strict. Quality improvement of the critical applications can be carried out by means of a total quality plan as well as by choosing and applying a development process based on rigorous methods well adapted to the domain. This article focuses on the second aspect by deliberately adopting norms and standards as basic concepts, HOORA and HRT-HOOD methods as frameworks of the process, UML -RT as the unique formalism for the process.

INTRODUCTION Objectives Many software development processes exist worldwide. Application managers need to consider carefully changes in these processes especially in the case of critical applications as time scales and constraints are extremely significant in this domain. The main motivation for possible changes is undoubtedly the improvement of quality, be it in terms of readability, efficiency, dependability, traceability, reliability, or testability. This article highlights the benefits which HOORA/HOOD and UML-RT can bring each other insuring the highest global quality of the critical software. Fundamentals In order to achieve this goal, we start from existing experience accumulated over a number of years in the aerospace community and by real time application specialists. This community bases projects to build quality software on mainly two standards; 1) the PSS05 as regards the description of the process of development of embedded applications, and 2)

DASIA’99 - LISBOA

DO178B as regards requirements for qualifying the software after certifying the process. HOORA and HOOD methods have been developed to satisfy the recommendations of these norms and standards. HOOD has been more especially applied to many big projects in the aerospace industry. HOORA is today an emerging method whose the goal is to work in collaboration with HOOD. We take these two methods as basis for our thinking for analysis and design phases of the software development process respectively. UML is a market standard today for various reasons; such as the quantity of information on the subject, the trainings offered, the books and tools available, etc…. UML is henceforth impossible to circumvent. But a method is actually a combination of formalism, a process and checking rules and UML is simply formalism. It is then useful to structure it by means of a process. We also base our approach on the ROOM/UML-RT method, which is increasingly being used as a real time component of UML even if it is not yet normalized. Strategy for software process improvement Our main goal in this article is to focus onto the software development process, and more especially on how we can improve this process in the case of critical software applications as seen previously. Our strategy is based initially upon a generic process usually being

1

applied to Aonix’s customers. This process is called AonixWay and was designed to be: • Customizable for the specific needs of each customer • Applicable on the whole development process without discontinuity • Object oriented, • UML based • Pragmatic We apply on this robust basis pertinent real time enhancements coming from the material described just above. The main enhancements concern real-time aspects of the process, the traceability of the requirement during the whole development process, and progressiveness , smoothness of the process.

REAL-TIME SYSTEM ISSUES

We focus more especially in this article onto the first one. We should obviously take into account all aspects of the development to improve the whole software quality. The PSS05 document doesn’t really impose a specific life cycle but rather define the following development phases : 1. User requirement phase (UR) 2. Software requirement phase (SR) 3. Architectural design phase (AD) 4. Detailed design phases (DD) 5. Transfer phase (TR) 6. Operation and maintenance phases (OM) Certification authorities impose reviews between phases of a project. Our process takes this aspect into account and provides review and checklist sheets.

A software system is mainly a system, which maintains an ongoing timely interaction with its environment. In other words it is a system, which reacts to external stimuli in a specified time scale [Selic98-b]. The environmental stimuli can be defined as time driven (periodic) for continuous inputs or as event driven (sporadic) for discrete inputs. A real time system is in addition of two types : 1. hard real-time : every inputs are taken into account 2. soft real-time : most inputs are taken into account A real-time system is intrinsically complex because of concurrency, synchronicity. It has moreover many technology constraints like memory size, hardware size, and complex algorithms. It also has to take into account many complex functional and non-functional requirements, and is potentially supposed to be certifiable in avionics, space, railway, and automotive domains. Our approach tries to take into account all these aspects of a critical software application into the development process.

DESCRIPTION OF THE DEVELOPMENT PROCESS To place the problem domain in its proper context, we should keep in mind here the four plans of software development according to PSS05 for instance : 1. Project Management, 2. Configuration Management, 3. Verification and Validation, 4. Quality assurance

DASIA’99 - LISBOA

S o ftwa re en g in eers

DDD (Detailed Design Document)

ADD

DD phase DD Plan P ro ject Develop ers

Code

Pro ject Develo pers

DD phase review

acknowlegment or not

User Manual So ft ware en gineers, Hardware en gin eers, Operat io n al st aff, Users

Figure 1. Example : Idef0/SADT diagram of DD phase with review process

Our process uses basically the object-oriented paradigm during the whole development process (from specification to the design). The advantages we can expect from are : • Stability of the modelization w.r.t. the real world • Loosely coupled links between objects enabling iterative constructions • Better reuse • Better functional evolving 1

The AonixWay process is basically iterative . It can 2 be incremental if the certification authorities enable it. It splits conceptually (figure2) the object architecture definition from the software architecture one. A realtime system involves both software and computer hardware aspects. The process described doesn’t focus especially onto the system architecture, which is more related to the hardware aspects of the system even if those aspects have to be taken into account.

1

2

mini-life cycles but taking into account all phases of the project in a simplified manner if needed indicates that we enhance the current phase w.r.t. the previous one. We can go back to this one to take into account new items

2

Object Archit ect ure

Cont rol

Int erface

Ent it y

Object diagram Use case diagram Sequence diagram

Component diagram Calss diagram Deployement diagram

Requirements

Development

Class diagram Architecture diagram Activity digram

Design

Soft ware Archit ect ure

M ult i-T asking

P ersist ence

Object diagram Class Diagram Architecture diagram

Sequence diagram Collaboration diagram State diagram

Static analysis

Dynamic analysis

Figure 4. UML diagrams in the life cycle Syst em Archit ect ure

Archit ect ure

HOW TO IMPROVE THE ANALYSIS?

Figure 2. System development layers [Moore99]

Our life cycle consists in parallelizing (figure3) development steps (analysis, and a part of the design). The general design phase is replaced by a phase of software architecture specification. During this phase we choose frameworks, software libraries and components, which will be used in the DD phase . We also define which patterns, which code generation rules, will be used to automate code generation and improve quality, and reusability.

Our process reuse mainly the concepts proposed by HOORA. HOORA (Hierarchical Object Oriented Requirement Analysis) has been developed under ESA (European Space Agency) control to support the software requirement phase (SR). User requirement document

Analysis phase HOORA

Software requirement document

Figure 5. Place of HOORA in Life Cycle.

Methodological concepts of the HOORA method

4

We can describe HOORA as follows:

UR

SR

AD

DD

TR

Figure 3. AonixWay Life Cycle

Each iteration is an entire life cycle itself including phases described above, and each iteration is also punctuated by an iteration review. At most 3 or 4 iterations should be sufficient. The process is based on the UML formalism, and we attach UML diagrams to each phase of the life cycle (figure4). We add also specific stereotypes or tagged 3 values to UML to take into account process characteristics. Finally we propose a pattern and framework libraries to help the developer to automate code generation. This aspect is important and enables improvement of the software quality in avoiding code errors, in systematizing programming rules, …

• • • • •

Totally object oriented Natural path to HOOD PSS05 compliant Focus mainly on the requirement model Top/Down decomposition to manage complexity • Requirement traceability [Micouin97] defines three kind of models, i.e. knowledge model which describes the process model and has a cognitive goal, the operational model which describes the real-time system itself, and the requirement model which describes interactions between the two previous models (figure6). HOORA focus more especially onto the knowledge and requirement models.

4

This section will describe a little bit longer the HOORA method [E2S/OORA/WP1/REF94], taking into account the method is not yet widespread. 3

stereotypes and tagged values are defined in UML to extend the original concepts of the formalism

DASIA’99 - LISBOA

3

(figure8). A class which can refined generates another class diagram here this class is repeated. Mesurements, Events CRD top

Environment

Real-time system Commands

Knowledge model *static model *dynamic model

Class 1

Requirement model

Class 2

Operational model CRD Clas s1

Class 1

Software specification (HOORA)

Class 4

Design (HOOD)

Figure 6. Use spectrum of HOORA [Micouin97]

The knowledge model includes both the static and dynamic sub-models and is in interaction with the requirement model as follows:

Figure 8. HOORA hierarchical decomposition

Requirement model Knowledge model

Dynamic model

Static model

Requiremt model

Figure 7. Inter-model interactions [Micouin97]

Knowledge model This model is actually composed of three parts temporarily ordered, i.e. the requirement definition, the static model and the dynamic model. In order to express the requirements, we need to define two dictionaries built from the User Requirement Document (URD): 1. Term and expression dictionary where all terms and expressions are defined formally to avoid ambiguities later 2. Requirement and rules dictionary where requirements about the process model and the real-time system itself are defined The static model (Class and Object diagrams) and the dynamic model (Class interaction, Sequence, and Finite state diagrams) are very similar conceptually and in the form to the UML ones. The knowledge model is made by the means of class relationship diagrams (CRD), each diagram being composed of at most 15 entities. Man works by abstraction level; each level can contain entities, which may be described hierarchically by another diagram

DASIA’99 - LISBOA

We focus here on the Real-Time software aspect. This model is largely based upon SRDT from Ward &Mellor. Its inputs are the knowledge model and it describes real-time requirements (functional and nonfunctional) that a real-time system has to satisfy. Its aims are: • Tell what the software must be able to do (requirements on the product) • Tell how to do this (requirements on the process) A requirement model is: • •

A context diagram A behaviour model o Control flows o Data flows o Event flows o Data buffering • Time constraints, external events We don’t describe deeply all these notions, but it is important to tell all these notions are globally present in UML. HOORA describes in addition the process to use them in order to make a right software analysis. Impacts on the UML based process The analysis process described by HOORA is very elegant and can be applied directly in UML (class, object, sequence, collaboration, activity, FSM diagrams can be used to match the HOORA concepts). It offers a clear view of what and in which order to do. Moreover it describes the transition path to the design (initially HOOD), i.e. how to derive from the analysis models design models. We also reuse the requirement definition dictionaries as described above and we improve them by using the Use Case Diagrams. This dictionaries and

4

use cases will be maintained and updated during all the development process.

Environment Nom du module

HOORA also categorizes all requirements (functional and non-functional) in accordance with PSSO5 standards. We can directly reuse this. Examples of requirement classification: functional, performance, interface, operational, quality,

Include relation implemented by service1

Provided Services

Unidirectionnal Data flow

Bidirectionnal Data flow

Use relation

HOW TO IMPROVE THE DESIGN? We improve the design using basically HOOD concepts. The HOOD method mainly fulfills the requirements of the DD and TR phases of the development process. The figure 9 shows how HOOD is placed in the life cycle in comparison with HOORA. UR

SR

HOORA

AD

DD

TR

HOOD

Figure 9. HOORA and HOOD spectrums

Methodological concepts of the HOOD method The HOOD approach is textual as well as graphical. In the development stage where the result of the analysis is detailed in-depth, we must provide a graphical synthesis of the application, as well as a textual view, which allows the re-entering of graphically non-relevant information. HOOD also formalizes a certain number of design rules, which can be checked by the tools, continually ensuring the coherence of the design. One also finds in HOOD, as in HOORA, the basic concept of Top/Down hierarchical decomposition of an application, which is one of the ESA requirements. The basic object of the method is the module. The module is refined into sub-modules, until final modules are obtained. The module conveys the interface concept. Moreover each module includes separate descriptions of interface: • The functional interface • The data interface • The behavioral interface. The hierarchy relation describes this Top-Down decomposition. There also exists the use relation between modules, which is called client/server relation. The figure 10 below describes synthetically all relationships of the functional view. We should add to be more complete relationships in the data view. The real time aspects also are taken into account by HOOD-RT extension, as well as the standardization of documentation generated by the tools, or the ADA code generation scheme from the design.

Level N

Figure 10. Functional view of a HOOD object

Impacts on the UML based process Even if the Hood’s formalism is quite different from the UML formalism, the concepts can be reused nevertheless without problem. The main aspect of HOOD we add to our process is the hierarchical decomposition. The Top/Down approach allows a large-scale software development by different teams. We can derive directly from the HOORA CRDs the HOOD modules and sub-modules as described in These non-terminal [E2S/OORA/WP1/REF94]. modules can be directly transformed into UML systems 5 and sub-systems to which we associate facade design pattern for translating the implemented by relationship for instance. The client/server relationship is also reused and is directly available through UML system relationship. The data views are directly translated in UML class diagrams. Exceptions are considered as part of the class description like attributes or operations. We suggest hardly to reuse the ODS (Object Description Skeleton) concept of HOOD. It is the textual part of the method where all textual inputs are managed (information, code,.). This skeleton intends to provide the developer with a clear framework of what to do and how. All the information written inside can be directly reuse to generate documentation compliant to the standards. The code generation schemes of HOOD can be derived phase as code generation patterns in the software architectural, especially for ADA code generation. The last interesting point of HOOD is its definition of checking rules in order to verify the coherence of the design. UML misses fundamentally those rules. We decide to apply HOOD rules in our process.

5

DASIA’99 - LISBOA

A UML system is a stereotyped package

5

•

REAL-TIME ASPECTS IN THE PROCESS The previous sections showed mainly two main aspects of our process: system and data views, which can be considered as static views. We focus in this section on the behavior view, i.e. how active objects inter-act each other. We can consider roughly that an active object is a passive object associated with a thread. We use for our thinking two kind of material: 1) RT HOOD concepts and 2) ROOM/UML-RT concepts.

Time-out constraints; generally associated with the other types of constraints.

HRT-HOOD adds extra-notions like protected types, cyclic types and sporadic types. It also defines attributes on those objects like deadline, thread_wcet, period, maximal_arrival_frequency, importance, ... We could speak about Virtual nodes notions too in order to map a logical architecture onto a physical one. In conclusion we can say that HOOD and its dialect HRT-HOOD offer many elegant and simple solutions to take into account Real-Time aspects of RT software.

6

Real time aspects in HOOD

7

Real time aspects of ROOM/UML-RT

In HOOD the object behaviour is described by finite state machines (FSM). We associate one FSM to each active object. Transitions are triggered by event inputs. The events that an active object can receive are described in its provided interface. The way events are received defines a communication service. Operations activated by an event occurrence and associated with a communication service are defined as constrained operations. This mechanism is described in the OBCS (OBject Control Structure). clear /clear()

Control System Clear Start Stop

=>

1 start/start()

2 Indicate constrained operations stop/stop()

Figure 11. Simplified view of how active objects are associated with FSM

HOOD offers several communication services, called below Execution Request (ER). We find: •

Concurrency constraint : mutual exclusion constraints (MUTEX), read/write constraints (RWER), read only constraints (ROER). RWER and ROER are generally associated to protected objects.

•

Protocol constraints: Highly synchronous protocols (HSER), Loosely synchronous protocols (LSER), asynchronous protocols (ASER) and less used protocols like RLSER and RASER)

UML-RT is the spiritual son of the ROOM (Real-Time Object-Oriented Modelling) method initially defined in 1994 by B. Selic, G. Gullejson and P. Ward, many famous specialists in Real-Time modelling. UML-RT can be seen as an extension set to UML, especially in defining the structural, time model, and resources aspects of RT software. Many concepts are very similar to HOOD concepts, like architectural design, interface, automatic code generation, and then will be reused too. For the real-time aspects, UML-RT proposes in addition of the usual UML class diagram view to use the collaboration diagram (object) view. This is made because of the kind of application we can find in realtime area. Real-time embedded applications are actually more often derived from the hardware, and we know then how many instances of each kind of objects we have to handle. This approach can be also found in HOOD. UML-RT proposes a graphical extension of UML to express communications between instances of active objects. This extension defines in particular new types of objects like port, or protocol. Roughly we can define them like: • Port: describes the interface of an active object. Each object owns a specified number of ports • Protocol: specifies valid message exchange sequence between two active objects. One protocol instance is associated to one port instance. Its is defined by a set of incoming and outgoing signals, sequence of messages, and finite state machine (like in HOOD)

7 6

We suggest to read the HOOD Reference Manual to have a better understanding of the following notions. We only evocate them in this section. See also [Rosen97].

DASIA’99 - LISBOA

We still recommend to read documentation about ROOM and UML-RT to get a better understanding of the purpose. It is not our aim to provide you with a complete description of the method and the formalism.

6

TankPort : TankProtocol

TankPort : TankProtocol

HeatingPort : HeatingProtocol

HeatingPort : HeatingProtocol

« Capsule »»

«« Capsule »»

:Tank

:Heating Reactor

Figure 12. Example of object view under UML-RT with notion of port

Originally ROOM was defined more especially for telecommunication domains. This way of representing communication protocols between active objects is very well suitable to this kind of applications. Generic protocols like X25 or TCP/IP protocols can be easily defined in UML-RT. We are not sure nevertheless that the genericity involved by the port and protocol notions are very useful in aerospace or railways domains. Behavioural aspects are provided by finite state machine, and more precisely by Statecharts offered basically by UML. UML-RT specifies moreover notions of signals, messages, events, message priorities, guard conditions, delays, RT frameworks and patterns, and so on… We can conclude in saying that all notions we found in HOOD, or other real-time methods can be found in very similar way in UML-RT/ROOM. Impacts on the UML based process Our process is based onto the UML-RT graphical formalism, i.e. statecharts to formalize finite state machine (with restrictions according to the kind of constraints we have), and UML-RT collaboration view (figure12). We take from HOOD different notions like the types of constraints (HSER, LSER, RWER, ROER, …), which can be derived as communication patterns in UML-RT. We also reuse the notions of virtual nodes, protected, cyclic and sporadic objects and their attributes.

CONCLUSION This paper presents the way we follow to offer a development process, which enables the developer to improve in a significant manner the software quality. This guideline combines the best of HOORA, HOOD and UML. It allows re-using and extending existing HOOD designed applications with UML based tools and provides HOORA compatibility. Other ways could be considered concurrently; test case generation directly from the specification, formal

DASIA’99 - LISBOA

methods and languages, the use of metric tools. All these techniques, far from being excluded, should be merged in the long term into CASE tools. But to succeed, they will have to be simple and easy to use…

REFERENCES [Barnes97] J. Barnes, Programmer en Ada 95, AddisonWesley , 1997 [Booch98] G.Booch, J.Rumbauch, I.Jacobson, The Unified Modeling language User Guide , Addison-Wesley, 1998 [Burns95] A.Burns, A. Wellings, Hard Real-Time HOOD: A structured Design Method for Hard Real-Time Ada Systems, Elsevier [Burns97] A.Burns, A. Wellings, Real time systems and programming languages, Addison-Wesley, 1997 [Canals97] A. Canals, J.C. Lloret, Démarche de développement OMT-UML/HOOD, Article CISI/CNES 1997 [Canals98] Agusti Canals, UML-Cisi : un processus de conception pour le langage de modélisation UML, Article, 1998 [Douglass98] B. P. Douglass, Real time UML: developing efficient objects for embedded systems, Computer and engineering publishing group, 1998 [Fowler97] Martin Fowler, UML distilled : applying the Standard Object Modeling Language, Addison-Wesley , 1997 [E2S/OORA/WP1/REF94] Hoora: Reference Manual V1.5, Document de E2S [E2S/OORA/WP1/UM94] Hoora : Method User Manual, Document de E2S [ESA91] ESA PSS-05-0 Issue 2, Feb. 1991 [Jacobson99] I. Jacobson, G. Booch, J. Rumbaugh, The unified software development process, Addison-Wesley 1999 [Lyons98] A. Lyons, UML For Real-Time Overview, Article, 1998 [Micouin97] P. Micouin, Spécification orientée objet avec HooraDraft , STERIA Méditerranée [MinhDuc98] Bui Minh Duc, Conception et modélisation objet des systèmes temps réel, Eyrolles, 1998 [Moore99] Alan Moore, An architected, incremental development approach for real-time systems, article RealTime Magazine 99-1 [Rational98] Unified Modeling Language For Real-time Systems Design, Article, 1998 [Rosen97] J-P. Rosen, HOOD: An Industrial Approach for Software Design, Edited by: HOOD User Group, 232 pages, ISBN 2-9600151-0-X [Selic94] Bran Selic, Garth Gullekson, Paul T. Ward, Realtime Object Oriented Modeling, Wiley, 1994 B. Selic, Jim Rumbaugh, Using UML for [Selic98-a] Modeling Complex Real-Time Systems, Article, 1998 Bran Selic, Extending the Unified [Selic98-b] Modeling Language for Real-Time Development, ObjectTime slides, 1998

7