曝光臺(tái) 注意防騙 網(wǎng)曝天貓店富美金盛家居專(zhuān)營(yíng)店坑蒙拐騙欺詐消費(fèi)者

and C++ code generation. At the same time, a new ESA project produced a Hard Real Time version of the
method, called HRT-HOOD, dedicated to embedded real-time systems, and providing a direct support for
schedulability analysis. After several years of operational use of these different variants of HOOD by major
European projects, it appeared that HOOD 3.1, HOOD4 and HRT-HOOD were fully compatible and reflected
the implementation of the same basic principles for various application profiles.
In HOOD, each Module (including the application itself), has an interface and a body. The interface consists of
the Provided_Interface that lists the declaration of all the software elements that are implemented by the Module
and made visible to be used by other Modules, and the Required_Interface that lists the references to all the
remote software elements that are required to implement the Module. The body is called the Internals of the
Module and contains either child Modules (for Non_Terminal Module) or a list of declaration of private
software elements and all the implementation (for Terminal Module).
Additionally, HOOD only distinguishes between the Modules "type" and Modules "instances" in two particular
cases only. The general case being that a Module is handled as an Object, that is, the unique instance of an
anonymous "type". The first particular case is when the Module "type" is described by a Class (like in UML),
but then, instances of this Class (which are in effect only instances of the main data Type provided by the Class)
becomes Data, Constants, etc… embedded somewhere inside another Module. The other particular case is when
the Module "type" is described by a Generic, then, instances of this Generic (which are in effect only instances
of the formal parameters) becomes other Modules called Instance_Of. HOOD also supports Generic Classes
(similar to C++ templates) that need to be instanciated twice. The only extension mecanism offered by HOOD is
the Class Inheritance.
The main contribution of the HOOD method, however, comes from its well defined software modeling process.
Based on a recursive top down hierarchical breakdown, this process provides rigorous design rules to enforce
"good practices", like incremental documentation and coding, and improve the level of quality and productivity
of a project. Moreover, its support by a tool offers automatized features such as multi languages code and
documentation generators.
The use of the HOOD method fully complies with the main software engineering standard recommended for
mission critical development of avionics, space, defense and some ground transportation projects, such as:
- DO-178B for airborne applications (Software Design Process)
- ISO/IEC-12207: for information technology (Software Architectural Design and Software Detailed Design)
- ECSS-E40: for space applications (Software top-level Architectural Design and Design of Software Items)
- EN-50128: for railway applications (Software Architecture and Software Design and Development)
The COTRE project, conducted by Airbus, and with the partnership of several French laboratories (LAAS, IRIT,
CERT, ENSTB) and TNI, was an opportunity to investigate the connection between HOOD and the AADL. The
result is that most HOOD concepts can be represented by an equivalent AADL paradigm without any major
semantical discrepancy.
Although HOOD offers an appropriate set of graphical notations, the main issue that was encountered by many
projects using this design method during the recent past years, was probably the unsuitability of the UML 1.x
concepts and notations to represent real-time software architectures. This need is about to be satisfied with the
new features that are offered by UML 2.0 structure diagrams.
using the AADL for mission critical software development page 4
<<component>>
name
provided
interface
required
interface
black box view of a UML 2.0 component
name
<<component>>
:name1
provided
interface
required
interface
white box view of a UML 2.0 component
<<component>>
:name2
4 Using UML 2.0 structure diagrams
UML 2.0 introduce structure diagrams to model component based architectures. These new UML concepts and
notations is being studied in order to consider there use as a support for both AADL and HOOD paradigms.
Following description of structure diagrams refer to the "UML 2.0 Final accepted draft" dated August 2003. In
the following paragraphs, the texts in italic are quotations from this document. As for the AADL, the reader is
invited to refer to the final definition of the standard, when released.
　
中國(guó)航空網(wǎng) www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：航空資料23(73)