TABLE OF TABLES
Contract 8: Execute a financial transaction
2.5.2 ASTS DEVELOPMENT METHOD 3 (ADM3)
Firesmith’s ADM3 is an integrated object-oriented method [Firesmith 93], which originated from an Ada-oriented method known as ASTS. The ADM3 method covers a large spectrum of software development (from system requirement to analysis and then logical design). It borrows ideas from semantic networks and has an emphasis on real-time systems. The method denotes static architecture and dynamic behaviour by six incorporated models, where each model is associated with a set of diagrams, as shown in table 2.2. The six models are briefly described below:
• assembly model - a static view of the entire assembly in terms of terminators, subassemblies and the relationships among them;
• object model - a static view of the architecture of a subassembly by the existence, abstraction and visibility of its component objects and terminators;
• class model - a static view of inheritance architecture by the existence and abstraction of its component classes and the ‘has subclass’ and ‘has instance’ relationships;
• state model - a dynamic view of the objects and classes by their states, transitions, modifier operations and exceptions;
• control model - a dynamic view of subassembly, its major threads of control, objects and classes by their attributes, operations and control flows;
• timing model - a temporal view of the subassembly by the timing of messages passed within and between objects.
DIAGRAM
APPLICABILITY STATIC ARCHITECTURE AREA OF CONCERNS DYNAMIC BEHAVIOUR
S
c o p E
ASSEMBLY assembly model context diagram
assembly diagram control model timing model
oo control flow diagram timing diagram
SUBASSEMBLY object model
class model
general semantic net interaction diagram composition diagram classification diagram
control model timing model
oo control flow diagram timing diagram
AGGREGATION
HIERARCHY object model composition diagram INHERITANCE
HIERARCHY class model classification diagram THREAD OR
SCENARIO object model interaction diagram control model timing model oo control flow diagram timing diagram
CLASS object model
class model general semantic net interaction diagram
classification diagram
state model control model
timing model
state transition diagram state operation table oo control flow diagram
timing diagram
OBJECT object model
class model
general semantic net interaction diagram classification diagram
state model control model timing model
state transition diagram state operation table oo control flow diagram
timing diagram
ADM3 allows the developer to specify the diagram notations by the ASTS diagramming language (ADL), and it also introduces Object-Oriented Specification and Design Language
(OOSDL), to document the design with specification of individual assembly, class, object, operation and state etc. (refer to Booch templates). The OOSDL format is rather like a C++ header file, for instance the specification of a SET_OF_TRAFFIC_SIGNALS object as below
[Firesmith 93]:
object SET_OF_TRAFFIC_SIGNALS parent subassembly INTERSECTION; specification
message CHANGE_PRIMARY raise LIGHT_FAILED, POWER_FAILED is synchronous; message FLASH_PRIMARY raise LIGHT_FAILED, POWER_FAILED is synchronous; exception LIGHT_FAILED; exception POWER_FAILED; end; J Visible. / ✓ 7 Concurrent./— / Object / Visible. Sequential. Object _f Visible. / / 7 Concurrent. It~ ~ / Class U Visible. Sequential. Class Visible. Subassembly / Hidden. / /C oncurrent./ J Object / Hidden. Sequential. Object / Hidden. / / / Concurrent. / / j Class U Hidden. Sequential.
Class SubassemblyHidden.
L Subassembly
Assembly Subassembly System
I / Identifier f Attribute_Types Constant_Attributes | Messages Exceptions
}
.Types i -x attributes I ittributes I V ges ”| I c options___”1I
}“
Attrlbute_Types I ConstanLAttrtoutes 1 Variable_Attrlbutes | I Messages I Exceptions specification{
Attribute.Type [TJ. Constant_Attribute [C], Messages ExceptionsFigure 2.18 ADM3 Icons for Interaction Diagram
ADM3 has an overwhelming set of notations, such as the icons used for the interaction diagram shown in figure 2.18. Thus, it was decided not to use it for the detailed experimentation in this research. Moreover, ADM3 is considered as a complex ternary method reminiscent in some respects of both Booch OOD and OMT. In other words, the major semantics of ADM3 have been concealed by the two chosen methods. Since ADM3 is an integrated object-oriented method, it is described in this section rather than in section 2.3.
2.5.3 THE FUSION METHOD (FUSION)
The Fusion method is another integrated OO method [Coleman 94], which claims to combine the best aspects of several methods. The principle influences on Fusion are depicted in figure 2.19. The software development phases are described individually as follows:
The analysis phase is inspired by the OMT analysis models. Unlike other analysis methods, Fusion objects have neither interface nor dynamic behaviour in this phase, since it claims that object interfaces are likely to be invalidated by the later global decisions regarding the overall system and its behaviour. Fusion also does not use state diagrams during analysis, because they exhibit dynamics and the descriptions are cumbersome. The major influences are:
Object model: the object model in OMT with relatively minor notational differences;
Operational model. OMT functional model with pre- and post- condition specifications from formal methods;
Life-cycle model, the regular expression of life cycles from JSD (section 2.2.2). CRC
OMT object model
and process object interaction Fusion
pre- and post
conditions visibility Booch OOD Formal Methods.
class Gun
attribute constant clutch: Clutch attribute constant pump: Pump attribute trigger: TriggerStatus attribute status: GunStatus method depress_trigger() method release_trigger() method enable() method disable()
method is_enabled(): Boolean endclass
Figure 2.19 Influences on the Fusion Method Figure 2.20 Class Description The design phase is based on the CRC and Booch OOD methods, where a systematic design process is added. Fusion provides class descriptions by collating information from the object model and the following design models:
• Object interaction graphs: the communication information scattered across CRC cards; • Visibility graphs: the visibility information between objects from Booch object diagrams; • Class descriptions and inheritance graphs: a template notation to document the syntax of
classes (as the example in figure 2.20) and graphs for recording inheritance.
In the implementation phase, Fusion claims that most applications can be directly resolved from the class descriptions. For instance, the class description of a Gun object shown in figure
2.20 (above) can be easily mapped to a C++ header file. The developer can fill in the details of each operation with supports from various graphs in the design phase. Moreover, Fusion suggests recording extra class semantics by a language-independent notation, such as extended state machine with pre- and post- conditions.
Fusion aims to meet the needs of software development which are not met by any existing methods. It requires a strong commitment to being systematic and rigorous, but this may not fit the technical requirements of an object-oriented development [Coleman 94], One major drawback of Fusion is that the method needs to be modified for use on distributed, real-time object-oriented systems. Basically, Fusion picks the proficient tools provided from the influential methods, and mixes their semantics together by resolving the context dependence, that is how the semantics of the tools relate to one another. This advocates an important technique for meta modelling adopted in this research (see next chapter). Nevertheless, since there are no distinct features with respect to the five selected methods, Fusion is not included for detailed experimentation.