OOSA also supports object-oriented design by a language-independent notation known as OODLE, which includes class diagram, class structure chart, dependency diagram and inheritance diagram [Shlaer 91].

2.3.3 OBJECT-ORIENTED ANALYSIS/DESIGN (OOA/OOD)

Coad/Yourdon’s object-oriented analysis (0 0A) [Coad90] is also derived from the Yourdon entity-relationship model. It is a reasonably complete, practical method and supporting notation, suitable for commercial projects, though the distinguishing between class and object was not been made until the second edition [Coad 91a]. 0 0 A proceeds in five stages:

• subject - decompose the problem domain into manageable subjects and describe them by different levels of DFDs;

• object - define real world abstractions as objects by using data analysis, which create a stable framework for analysis and specification;

• structure - identify classification and composition hierarchical structures, then represent them as generalisation-specialisation and whole-part relationships respectively;

• attribute - define attributes of each object by conventional data analysis, the instance connection is modelled by mapping object responsibilities (similar to that of CRC);

• service - equip each object with services (known as ‘methods’) by considering the behaviours of the object, the message connections between objects are also identified.

whole generalisation

class class-&-object

class-&-object _{attribute gen-spec " f S art} attribute 1

attribute2 attribute 1

attribute2 _service structure

servicei service2 servicei

service2 specialisation2 specialisation 1

iver | Instance

i connection class-&-object2

class-&-object1 receiver _connection sender

1 subject

Figure 2.7 Coad/Yourdon OOA Notations

OOA introduces a less clumsy notation than Shlaer/Mellor’s OOSA (refer to figure 2.7). In addition, OOA documents each class-&-object in a specification template and individual service is further specified by an object state diagram and/or a service chart. Coad/Yourdon’s object-oriented design (OOD) adds four design components to OOA [Coad 91b]. These components allow design-specific issues to be included in the OOA diagrams:

• problem domain component - refine the products of OOA in the problem domain;

• human interaction component - design interaction, such as format of windows and reports; • task management component - handle different types of tasks and their communications; • data management component - provide infrastructure of storage and retrieval of object.

i n v e s i i g u u u n u j o u j i w u r e l s c v c i u j j h i c/i i i n c m u u o

The main critique of OOA/OOD is that it does not really handle dynamics and the connection of services can only display thread of execution one at a time [Graham 94]. Nevertheless, the

OOATool produced by Object International supports the denotation of the method.

From the meta modelling viewpoint, OOA/OOD does not describe design steps explicitly, although the strategies recorded at the end of the literature present the techniques of the nine structured activities (five activities from the OOA and four activities from the OOD). Each strategy defines the condition of the activity by the ‘when to' statement(s) and the action as

‘how to...' or ‘what to...' statement(s). This is demonstrated by the analysis strategy of

identifying subjects shown below. In fact, this information gives the significant guidance of the method and must be denoted in the method representation.

ANALSIS STRATEGY - identifying subjects Subject. A subject is a ...

How to select: Promote the nam e ... How to refine: Refine subjects by using ...

How to construct: On the subject layer, draw each subject as ... When to add: Add subjects once an overall map ...

2.3.4 NIELSEN OBJECT-ORIENTED DESIGN (NIELSEN OOD)

Nielsen OOD introduced a design method for real-time systems [Nielsen 88] and then it was expanded to a distributed design method [Nielsen 91]. The object-oriented flavour was only inserted in a later literature [Nielsen 92]. Nielsen OOD focuses more on specifying process distribution and message passing than concurrency or task structuring.

Unlike other methods described so far, Nielsen OOD is very much an Ada based method, the major aim of process abstraction is to map process structure charts (as shown in figure 2.8a) into Ada Task graphs for further transformation into Ada packages. Although Nielsen OOD method includes data abstraction to take in object-orientation, the definition of an object (as demonstrated in figure 2.8b) is only an encapsulated data structure and no inheritance is encountered. Buttons Switches Axis 10 PROGRAM ControL _Message Repty Panel Program Id Control. ^ j PaneL Processor Event ^ DB Access Handler Panel Outputs Interpreter ControL PaneL Motion Blocks

OutpuL SENSORY I/O

DATA STORE Resume Handler Motion Acknowledgment Axis Block Sensory. InpuL Handler Axis. Manager Axis Controller Acknowledgment S en so ry .^ Output OutpuL Handler, operations module Buffer Dequene visible Interface Buffer.Module encapsulated %. boundary

a. process structure chart of a robot controller b. a buffer object Figure 2.8 Nielsen OOD Notations

The design heuristics of Nielsen OOD are plentiful and they receive different emphasis in different literature. Although the development steps are summarised with the according representations (diagram and/or design language), there is no proper structure to arrange this guidance back to the corresponding design steps as in Coad’s OOA/OOD. Later on in this chapter, another distributed real-time method, Codarts/DA, is described which uses a similar set of notations, but it associates design steps and heuristics in a more structured way.

2.3.5 OBJECT-ORIENTED SOFTWARE ENGINEERING (OOSE)

Object-oriented software engineering (OOSE) is a subset of Jacobson’s object-oriented method, Objectory, which is supported by his OrySE CASE tool. OOSE suggests dividing system development into three activities: analysis, construction and testing [Jacobson 92]. Each of these activities develop models: requirements and analysis models in analysis; design and implementation models in construction; and test model in testing. The OOSE underlying enterprise analogy is an architecture that is based solely upon the customised constructs below:

• tool - support all activities of the enterprise, i.e. architecture, method and process; • method - make explicit procedures to be followed in applying architecture to projects; • process - provide for scaling-up the method to a larger interacting activities and parties;

f r

Customer

a. use case model for a recycling machine b. mapping use cases to domain objects Figure 2.9 Jacobson OOSE Notations

Many ideas of OOSE are similar to other 0 0 methods, except the concept of use case. Use cases are descriptions of how users interact with a system, such as the recycling machine use case model shown in figure 2.9a. The domain objects, such as interface object, entity object

and control object, can also be shared amongst different use cases as depicted in figure 2.9b. Nevertheless, a list of methods are described with OOSE in the literature [Jacobson 92], including OOSD, OOSA, OOA/OOD, Booch OOD, HOOD, OMT and CRC (the last four methods are described later in this chapter). The concepts of these methods are mapped to OOSE and the activities are compared. These method evaluations give a better picture of the method, though a generic representation of all methods should make the job much easier.

Recycling machine Generate daily report ■►^Returning itei

Change item _Operator

case 2

KD

2.4 CHOSEN METHODS

Since it is impossible to cover all software development methods in such detail within the limits of time, five methods are chosen deliberately for the study of meta modelling in depth. However, criteria can be used for selecting methods so that the outcomes are made generic to other methods. The criteria are as follows:

• The semantics must be encapsulated in a ‘distinct’ method, which provides a set of concise and precise presentable conceptual ideas (see section 2.1). Contrary, the techniques for developing actor-based systems are only given as strategies rather than conceptual models. • The group of methods must not incline towards a particular programming paradigm or

software development phase, so that the study is not biased toward certain sets of semantics. In our selections, they include structured method, object-based as well as object-oriented methods, and also cover both analysis and design development phases. • The chosen methods should denote a wide range of software modelling techniques, so that

they reflect a large spectrum of modelling features and method viewpoints.

The five selected methods are Booch OOD, Codarts/DA, HOOD, OMT and Ptech. Table 2.1 shows the basic features of software development with these methods. A *•’ denotes the feature is fully supported by the method, a ‘ O ’ describes a partial support, whereas a ‘O’

means little support is given. If the cell is blank, there is no support from the method. These features are categorised into three groups in this order: development paradigms or phases, method viewpoints and meta model components3. Most of them are self explanatory.

Category Feature Booch OOD Codarts/DA HOOD OMT Ptech

Development Paradigms Object-Oriented

•

O

o

•

•

Structured

O

Analysis

O

•

o

•

• Design •

•

•

o

O

Method Viewpoints Object Model

•

o

o

•

•

State Model

•

•

•

o

Function Model

o

o

o

•

o

Real-Time

o

•

•

Concurrency

o

•

•

•

•

Distributed

o

• • Meta Model Components Product - Concepts • • • • • Process - Activities

o

•

o

•

o

Heuristic - Guidance

o

•

o

•

o

Graphical Fragment • • • • • Textual Fragment • • •

o

o

Table 2.1 Basic Supported Features of the Five Chosen SDMs

3 The components of a meta model are made clearer later in this thesis. At the moment, they can just be

In document A generic model for representing software development methods (Page 42-46)