An object-oriented modelling approach to system software design

Infi)rmation and Software Technology 1994 36 (11) 683-694

An object-oriented modelling approach to system software design

P J Lee Department of Management Information Systems, National Yunlin Institute of Technology, 123 University Road Section 3, Touliu, Yunlin, Taiwan 640, ROC

D J Chen and C G Chung Institute of Computer Science and Information Engineering, National Chiao Tung University, Hsinchu, Taiwan, 30050 ROC

e-mail:[email protected]

In this paper, a modelling method entitled MOOD (Modelling approach to Object-Oriented Design) is proposed for the design of object-oriented system software. The method employs entity-refinement, functional modelling, and object modelling techniques to model the world of solution-domain objects. The modelling result based on MOOD forms a set of graphic notations that describe the structure, functions, and client-server relationships among the entities. These graphic notations can be mapped directly into object-oriented programming constructs during the implementation phase. MOOD devotes special attention to the reuse of existing components or newly designed components for future reuse. Unlike other methods, which find objects from textual statements, the entity-refinement approach proposed here can identify all the entities and their operations within the solution domain. MOOD is compared with existing methods to show its feasibility and uniqueness.

Keywords: modelling, entity-refinement, software reuse, request flow diagram, object-oriented design

Modelling can be treated as an abstraction of something lor the purpose of understanding it before building it. To build complex software systems, it is necessary to abstract different views (object, dynamic, architectural, and functional views) of the system ~-~. Generally, we first build models using notation, then verify the models using the requirements of the system, and finally transform the models into a computer program. Modelling techniques have played an important role in the development of complex software because it can alleviate some problems introduced in the construction of large software systems.

Software developers build many kinds of models for various purposes before constructing the real system, Models serve several purposes2:

• Testing a physical entity before building it.

This project was supported in part by the National Science Council. Taiwan, ROC, under contract number NSC 79-0408-E-009-18, and in part by the Institute for International Industry, Taiwan, ROC. P J Lec is responsible for all correspondence.

• Reduction of complexity. • Visualization.

We can see that graphic-based representations are fre- quently incorporated in current object-oriented modelling approaches.

The software world can be viewed and modelled from four points of view2: the object, dynamic, architectural, and functional points of view. These are shown in Figure 1.

(1) Object view. The object view describes the static structure of objects in a system, including their iden- tities, their relationships to other objects (such as associations, aggregations, and generalizations), their attributes, and their operations.

(2) Dynamic view. The dynamic view describes those aspects of a system associated with time attributes and the sequencing of operations. The dynamic view is important for specifying dynamic behaviour in systems such as telecommunications, real-time control, and man-machine interaction systems. Architectural view. The architectural view describes (3)

0950-5849/94/011683 12 ©1994 Butterworth-Heinemann Ltd 683

An obJect-oriented modelling approach to system software design: P J Lee et al.

Object view Architectural view

Dynamic view Functional view

Figure 1 Four views of a software world

the overall structure of a system, including how the system is partitioned into subsystems, how the subsystems are decomposed into a horizontal network of problem-domain entities, how the problem-domain entities are decomposed into nested objects, and how the components are interrelated.

(4) Functional view. The functional view describes those aspects of a system concerned with static transform- ations of values (functions, mapping, constraints, and functional dependencies). It is used to specify the functionality of a certain part of the software, For object-oriented systems it is necessary to describe client-server relationships and data/control flows among collaborating entities.

For example, a CASE (Computer Aided Software Engineer- ing) tool developed using the object-oriented paradigm, is a large-scale man-machine type software system. The architectural modelling step is used to specify the overall structure and the interrelationships among problem-domain components (such as analysis tools, design tools, project management tools, testing tools, and repository). Because CASE involves frequent man-machine interactions, different kinds of messages will result in different kinds of responses (this is a type of dynamic behaviour), and hence we can use the dynamic modelling steps to describe this type of behaviour precisely. On the other hand, the message passing model of interaction between objects can be described by the functional modelling steps. The static relationships among objects can be specified by the object modelling steps.

Recently, the object-oriented approach to software development has become increasingly attractive because it supports software engineering practices such as data abstraction, reuse, and reduces the complexity of programming logic. Research in object-oriented modelling methodology includes descriptions of the modelling process, finding rules for good modelling, and building tools to support modelling. Most methodologies 7 to are only suitable for Ada-like programming environments and do not cover subjects such as reusability. In order to support software reuse (code or design reuse), reusability must be taken into consideration in the modelling phase. We have found that most existing object-oriented modelling methods suffer from the following limitations:

(1) Objects are discovered from textual descriptions 2'5'~° or by using pre-classified object categories 3"4, which will produce an unstable set of objects. Observations. (a) Rumbaugh 2, Wirfs-Brock 5, and

HOOD 7 suggest discovering objects from textual descriptions. They advocate writing an English description of the problem (or part of the problem) and then underlining the nouns and verbs. The nouns represent candidate objects, and the verbs represent candidate operations upon them. The list of objects and operations that results from this strategy is fairly imprecise, and its quality is strongly dependent on the domain knowledge and writing skill of the authors. Moreover, because it is easy to skew the candidate list of objects and operations, much time may be wasted in the process of development and the resulting system may be unstable. This approach is by no means rigorous and is only suitable for certain trivial problems, as remarked in Jalote 9.

(b) Coad and Yourdon 3, and Shlaer and Mellor 4 suggest using a set of pre-categorized object classes as a clue to discover objects.

These approaches produce an unstable set of objects, which will significantly affect the management of a team project.

(2) They are rich in notations but weak in modelling processes. Observations. The books from Booch ~, Coad and

Yourdon 3, and Shlaer and Mellor 4 discussed the concept of object orientation but provide only general guidelines for analysis and design activities.

(3) The transition and traceability between the analysis and design phases is not addressed by most methods. Observations. (a) Booch ~, HOOD 7, and Wirfs-Brock 5

provide only design activities, and it is unclear how the outcome of analysis performed using other methods is to be used.

(b) Fine guidelines are lacking in Coad and Yourdon's, Booch's, and the GOOD design methods.

(c) Shlaer and Mellor's method provides only analysis activities and it is unclear how its results are to be adopted for use with other design methods.

The object-oriented paradigm has the potential to increase consistency within the software development process compared with traditional software engineering approaches. Several existing methods, however, tend to focus on a particular phase without addressing the transition and traceability between phases. This narrow focus makes communication and maintenance (for changing requirements) highly burdensome for developers.

(4) Neither design for reuse nor design with reuse is addressed explicitly.

This paper proposes a new modelling approach to object- oriented design. Our approach uses graphic notation to specify the functions, client-server relationships, dynamic behaviour and class structure among solution-domain entities. Unlike the textual statement approach, the entity- refinement approach proposed here identify all entities and their operations within the solution domain. During entity- refinement steps, the characteristics (dynamic, simple, complex, sharable, reusable or task) of newly identified

684 Information and Software Technology 1994 Volume 36 Number l l

An object-oriented modelling approach to system software design: P J Lee et al.

entities and the relationships (containing or using relationships) among entities can be easily identified. This information is then applied to the modelling process helping to integrate the resulting models closely together. In particular, the reuse of existing components or the designing of components for future reuse is emphasized in this method.

MOOD: A modelling approach to object-oriented design

An overview

MOOD is in fact a design method. During the analysis phase, the target system is partitioned into several manageable subsystems, and these subsystems are each in turn partitioned, according to the requirements collected and organized, into problem-domain classes. Their inter-use- relationships are identified ~, and then MOOD is applied to possible parallel design of the software. In MOOD, an entity-refinement step for object identification and a modelling process to model a problem-domain class is applied. It starts from the identification of alternative solutions for the class and generates two kinds of models (i.e., object, and functional models) for showing the class hierarchy, client-server relationships (containing or using relationships), and functions of the solution-domain entities. These models depict: (a) what the desired system must do; (b) what it consists of; (c) what the relationships among entities are; and (d) how the system accomplishes its task. The design activities of MOOD are the following:

(1) Object design for all problem-domain entities. (a) Deriving alternative solutions. (b) Object refinement to discover nested objects. (c) Functional modelling. (d) Object model refinement.

(2) Verify the consistency among models. (3) Object model integration.

As shown in Figure 2, during the analysis phase we proposes a mixture of 'top-down' (partitioning/abstraction) and 'bottom-up' (projection) strategies to decompose the target system into problem-domain objects and their structure ]2, which can make a team project more manageable and facilitate communication among developers. After the analysis phase, the design steps are applied to devise parallel models for the solution domain of all the identified problem-domain objects, and during the design of an object an object refinement approach for identifying nested object is applied. The design starts from identification of alternative solutions for the object and generates two kinds of models (i.e., object model refinement, and functional model) that show the static object structure, client-server relationships (containing or using relationships), and functionalities of the objects in the solution domain.

During the analysis phase, the RFD (refinement flow diagram) for the architectural view of a subsystem has been obtained. Because the interrelationships and the requirement flows between problem-domain objects are identified, the design steps for all these objects can be undertaken simul- taneously. Also, because the responsibilities of each object

~ f y s i _ ~

subsystem 4-OMD C n . . ~ ~ ,

Bose class Subclasses

STEP natives)'.

Parallel design

-==1 °bjectdesign ~ '

-i~J °bject design F

• E I

-ID,.~ object design F- ~

Object refinement

g 0

g E

m o .

E

Functional mode ing, and object model refinement

Object , , ~ refinement; STEP 3 - STEP 5

STEP 2, ( Specify internal behaviour ~ (Discover nested and clarify the strucfure objects) of the classes)

4 4

Reusable environment

: Reusable problem-domain subsystem

: Complex problem-domain subsystem

F i g u r e 2 Des ign activit ies o f M O O D

Information and Software Technology 1994 Volume 36 Number 11 685


i o o m oxl:>o="t i

~ubayato~O~m n o w l o d g o

- - - - ~ R F D s L~j , B r ~ I ¢ m o d o l Syst4~cn - r F D - S u b m y m t o r r l - r F D B

o . .

s u b s y m t ®

R F D s

Figure 3 DFD showing the design activities of specific problem-domain entities

are clearly identified, the design steps can be followed coherently. There are four steps involved in designing an object in the problem domain, where step 1 and step 2 con- sist of finding the nested objects that collaborate to fulfil the services of the parent object, and steps 3 and 4 are modelling steps, which specify the internal behaviour, client-server relationships, and the static object structures of the objects in the solution domain. These models depict: (a) what the desired parent must do; (b) what it consists of: (c) what the relationships among objects are; and (d) how the system accomplishes its task. Finally, the derived models are integrated and their consistency is verified. During these steps, the principles of 'design for reuse' and 'design with reuse' are observed. A DFD showing the activities and parallelism of the design steps of MOOD is illustrated in Figure 3.

system. Our goal is to create a design with maximum com- monality for these possible classes. With such considerations, one can use existing reusable components ~3 or design a new subsystem as a reusable component for future reuse ~4.

Specifically, Figure 4 depicts an initial class-hierarchy of a disk-driver (a problem-domain object) to be designed.

Object refinement to discover nested objects (a) Identify responsibilities and functions that the class

instances must provide. (b) Specify activities of all the functions identified in step (a). (c) Identify collaborators to fulfil the functions. (d) Identify, evaluate, and choose alternative solutions

(classes) for each complex object.

Object design for each problem-domain entity (parallel design) Deriving alternative solutions. The problem-domain objects and their inter-use relationships have been identified during the requirements analysis phase. In order to provide for code or design reuse, possible alternative solutions for each object to design are studied, evaluated, and chosen for further development. For example, a disk-driver is a problem- domain entity of an operating system that may be a hard- disk driver, a floppy-disk driver, or a RAM-disk driver. Similarly, a memory management subsystem may be First- Fit management, Best-Fit management, Worst-Fit management, Buddy management, page management, segmentation management, or paged-segmentation management sub-

(Disk -d r ive r )

L ( H a r d - d i s k )

Figure 4 A disk-driver class hierarchy

( F l o p p y - d i s k )

686 Information and Software Technology 1994 Volume 36 Number 11


(e) Apply step (a) to step (d) for the complex classes recursively.

Figure 5 depicts the object-refinement steps graphically. In what follows, we describe the steps in detail.

(a) Identify responsibilities and functions that the class instances must provide.

The responsibilities of an entity are all the services it provides for all system entities that communicate with it. During the analysis phase, the whole system is decomposed into several manageable problem-domain objects, and their interrelationships are identified. More importantly, the responsibilities and functions of the server class (either problem-domain or solution- domain class) can be identified easily because the requirement flows are well identified. In concurrent software systems, there may exist four kinds of functions: (i) synchronous: the client suspends execution until server completes requested operation; (ii) asynchronous: the client sends request and continues its execution; (iii) balking: a synchronous communication where client gives up if server is not ready; (iv) timed: a synchronous communication where client gives up the request if server is not ready after specified period.

(b)

(c)

Specify activities for all functions identified in step (a). For each service function, we ask what activities that

function must perform and then give brief descriptions of these activities. These serve as clues in the next step for discovering what collaborating entities will fulfil the functions. Identify collaborators to fulfil the functions.

In general, an entity can accomplish its functions in three possible ways: by performing the necessary com- putation itself, by collaborating with nested entities, or by requesting services from other server entities. From the description of all the functions in step (b), one can identify what nested entities and external entities can collaborate to fulfil the functions. In MOOD, up to seven kinds of solution-domain entities may be identified: complex, simple, reusable, sharable, task, dynamic, and private-function entities. A complex entity is an entity that cannot be found in the reusable library and needs further refinement. A simple entity is an entity that can only be acted upon. It is considered to be a simple functional entity which cannot be found in the reusable library and can be implemented directly and easily. A reusable entity is an existing component that can be used directly or indirectly (i.e., with some minor modification) from the reusable library to

1-"

I I / I I

I I,,,,.... ~ '

I I

xO

ml~.m m w

o b i - m (Cam) L

J

{ r--1 {

[] R

_/-7. ('----I

objJ. (Class-i)

I y 0 z0

t y p e s o f f u n c t i o n s : 1. S y n c h r o n o u s j 2. Asylachronous

3. B a l k i n g 4. T i m e d

f

[==t

nO o0 P0 'd-,, ,_

J

: Shmrab le o b j e c t

: R e u s a b l e o b j e c t

: T a s k o b j e c t

: P r i v a t e f -unc t ion

J

j obi-k (ck)

f

l (Ck)

I

I

I L"

, ,

: D y n A m i c o b j e c t

: C o m p l e x o b j e c t

: Simaple o b j e c t

s t e p s :

a,b

C

d

e

Figure 5 The objec t - ref inement steps


An object-oriented modelling approach to system soj~ware design." P J Lee et al.

compose a new component. A sharable entity is also an existing component that can be used to provide services to the other entities in the system. It is possible to reuse a component without sharing it. For example, a floppy- disk driver is a sharable entity that can be used to provide disk services for its clients. Another example is an instance of a queue, which is a reusable component that may be found in a queue class-hierarchy in an existing library. The class may be instantiated by clients for the composition of a specific component. A (d)

task entity is responsible for a specific duty. It may emit a thread of control within an active object that runs with other threads concurrently in order to accomplish specific functions. A dynamic entity has time- dependent behaviours, the behaviour of this type of entity has been specified during the dynamic modelling steps in analysis phase. A private function is only used by an object internally and is not visible to other objects. Identify, evaluate, and choose alternative solutions for

syLoo I write()

I

d i s k - s e r v e r / task

S S ~

[ synchronizer ] i . q (D i sk -queue~

t. _ _ ---~.~ . . . . . ~--

I I ( F C F S ) ( S C A N )

t (Disk-queue) [

I ( C - S C A N )

[ *controller I FDController L ( F D C o n t ~

- - I

( S S F T )

(FCFS) (SCAN)

1 T

g~tO p~t0 pu~ync0

Figure 6

I I

! I i ~ 0

(SSFr) ]

- - I

Object-refinement steps applied to floppy-disk driver

688 Information and Software Technology 1994 Volume 36 Number l l


each complex object. This step is necessary when 'design for reuse' seems

desirable. Since the possible solutions are properly structured and constructed, the system may be tailored for a specific usage and customization of the system is possible.

(e) Apply step (a) to step (d) for the complex classes recursively.

Specifically, the nested/utility objects of the floppy disk are discovered step by step, as shown in Figure 6. The objects in the solution domain of the hard disk are discovered in a similar way.

Functional modelling

Object-oriented systems can be characterized as modelling the real world. Consequently, it would be attractive to view such systems as collections of cooperating autonomous objects communicating via messages. This would enable concurrent processes or multiple threads of control to be modelled naturally and at a high level of abstraction. At the design level, objects encapsulate data and operations and could incorporate their own thread of controls, providing autonomous behaviour. A design method, especially for concurrent software systems, should support the specifi- cation of the functionality of this kind of software. In fact, Booch ~ has proposed a set of notations to represent different kinds of concurrent entities, such as task and synchronization constructs, timed-invocation, asynchronous- invocation, and so on. Unfortunately, the modelling process used to specify the functionality of concurrent software is not defined in his method. In MOOD, the behaviour of the cooperative thread of controls can be specified on a single

Request-Flow-Diagram, which allows multitasking behaviour to be easily understood.

After the entity refinement steps, all nested entities and external server entities and their operations are identified. We then perform functional modelling on these entities. The functional modelling is used to describe the functions of the identified entities. This is done by constructing RFDs (Request Flow Diagrams) that describe the functions and client-server relationships among entities. An RFD can specify one or more service functions, depending on the functional complexity. A set of RFDs can specify precisely the functions and the client-server relationships of a subsystem. For each function, there are four steps involved in constructing an RFD:

(1) Identifying the threads of control that cooperate to fulfil the function.

(2) Specifying parameters and their types. (3) Building the RFD by specifying data flows, control

flags, and client-server relationships among entities. (4) Specifying and describing the running sequences for

each thread of control.

Figure 7 is an RFD that describes the functions of a problem domain entity e~ that provides three service functions f, , f,2, and f~3. There exist three internal entities, e , , e,2, and ei3, and two external entities, ej and ek, which collaborate in order to fulfil the functions. The entity e, contains nested entities e,~ and e~2. When a client requests e~, by passing a message, for the service of f~l, e, will request e~t and ei3 for the service of f~tl and f~3~, respec- tively. Entity e, in turn needs to request its internal simple entities eit I and e,2 for some services, whereas el3 may

c l i n t - i e i ( E i c l a s s )

~ t 2 ~ k

I -\ I

I i \ . I I ' ' i

I )o 1 i

e k ( lEk c l a s s ) I

I / I

e i l O E i l c l a s s )

e l 2 0 E i 2 c l a s s )

e j OEj c l a s s )

Figure 7 A request flow diagram

d a t a f l o w r e q u e s t f l o w c o n t r o l f l a g



request an external server e k for the service of fk," Therefore, we may say that e~, e~, e~3, and e k collaborate to fulfil the function of f, . Note that there is only one thread of control in this case.

More specifically, Figure 8 shows how collaborators

cooperate to fulfil the synchronous-read operation of a floppy-disk driver that is an active object (has its own thread of control) and runs on a revised version of an educational operating system ~5.

/ f l o p p y - d i s k - A ( F l o p p y _ d i s k )

\ " o~

intBlock ~ intClientTaskiq *Buffer

synchronous

*node

rend 2 [ np(Node pool) *nod0

5 4 ................. ::::::::::::::::::::::::::::::::::::::::::: ............... ~

intCli~ n! 'R' Taski( ! J

mailer (Infinite Mailbox) I

I

I tClie~ T ~ ~ Lkid

.oo,

*q (Disk-queue)

I task

intSufface . intTrack V intScetor

*Buffer

ok I [ *controller (FDController)

!

] synchronizer I

m • s U S l ~ n 4 ~ l ' e s u m o

k I : Asynchronous operation

] : Synchronous operation

Shaxable objects : synchronizer

- - I 1 ~ . - Request flow Reusable objects : rip, mailer

. . . . ~ Data flow Complex objects : q, controller ,- .-- Control flag floppy-diak-A v Task objects : client, disk-server

Thread I for the client task: 1. Request a synchronous rod-operation. 2. Get an empty node from node pool and fill in the requested information, such as block number. 3. Put the requesting node into disk queue for disk-access scheduling. 4. Send an 'R ' message to the server task to inform the server a job has arrived. 5. Suspended by the synchronizer until completion of the job.

Thread 2 for the disk server task: 1. Receive a job request message synchronously (will be blocked by mailer when there is no message

ready). 2. Get a requesting node from disk-queue. 3. Interpret the job and then request controller for a synchronous-read service (will be blocked

by controller when the hardware is activated and resumed when the I/O is completed). 4. Return the requesting node to node pool. 5. Resume the client task for completion of the job.

Figure 8 An RFD to specify the read operation of a floppy-disk driver


An object-oriented modelling approach to system software design." P J Lee et al.

Object model refinement

During the design phase, class structural modelling captures the static hierarchy of the relationships (association, generalization, and aggregation) among solution-domain objects. It can also specify the attributes and operations that characterize each class of objects. The class structural modelling process consists of two steps:

(1) Identifying the relationships among solution-domain entities.

(2) Constructing the object-model-diagrams (OMDs).

More specifically, Figure 9 shows the refined-OMD specifying the object structure of a disk driver. Note that the driver in the problem domain contains two subclasses: a floppy disk and a hard disk. The refined-OMD shown here is a refinement from object modelling results in the analysis phase. Disk-queue is a nested class which contains four subclasses, according to the possible disk scheduling policies~: an FCFS-Disk-Q, a SCAN-Disk-Q, a C- SCAN-Disk-Q, and an SSTF-Disk-Q. Disk-controller is also a nested class. It contains two subclasses: a Floppy- Disk Controller (FDController) and a Hard-Disk Controller (HDController). As long as the class family has been well developed, the disk system can easily be customized for a specific usage.

Verify consistency among models. Conflicts (for example, naming conflicts) among models are identified and corrected in this step.

Object model integration. Merge all the refined OMDs into system-OMDs to specify the static relationships among objects in the whole system.

Comparison with existing approaches

The methods proposed by Booch L°, HOOD 7, Jackson 1718, Wirfs-Brock 5 and Rumbaugh 2 start by discovering the classes and objects from the vocabulary of textual problem descriptions. They suggest writing an English description of the problem (or part of the problem) and then underlining the nouns and verbs. The nouns represent candidate objects, and the verbs represent candidate operations upon them. The list of objects and operations that results from this strategy is imprecise, and its quality is strongly dependent on the domain knowledge and writing skill of the authors. Moreover, because it is easy to skew the candidate list of objects and operations, much time may be wasted in the process of development and the resulting system may be unstable. This approach is by no means rigorous and is only suitable for certain trivial problems as mentioned in Jalote ~.

In MOOD, we propose an entity-refinement approach to discover nested entities and server entities that cooperate to perform the services of the problem domain entity. During the refinement process, we also identify whether each newly discovered entity is a dynamic, reusable, sharable, simplex, complex or task entity, then various kinds of modelling processes are performed to construct different views of the software. MOOD provides a means of specifying precisely the functions, relationships, dynamic behaviour, and hierarchical structure of solution-domain entities.

Note that Rumbaugh and Shlaer and Mellor use DFDs to specify the functional view of the system. In a traditionally structured approach, a DFD is a modelling tool for specifying the system decomposition (architecture) and functional views of the system. During design phase, the DFDs will

I (FCFS)

p u t s y n e O gctO

r (Disk-driver) r e a d ( ) write() syncO

I~tsK-qucue --q Controller *controlle~ TCB d i s k - s e r v e r

I I

I T / ] (Dl~(:-queUe)put()

putsyneO RetO

I R~tNode h e a d ReqNode curt-node int n u m

,1. I I

(SCAN) ] ( c SCAN) putsyncO [ putsyncO getO get()

char direction

(sync~

r e a d O | write() |

p u t s y n v O get()

Figure 9 Refined OMD for the disk driver

Information and Software Technology 1994 Volume 36 Number I I 691


be transferred into structured-chart to obtain the control flow of the target program. DFD is recognized as a good tool for the communication (for requirements verification) among developers and customers. As the emphasis in the structured approach (i.e., functions) is very different from that in the object-oriented approach (entities), using DFDs to specify the functionality of object-oriented software systems is awkward because the transformation from data flow to control flow will still be a problem just like structured approaches. On the other hand, MOOD uses RFDs to specify the functional behaviour (functionality and client- server relationships) among cooperating entities. RFDs are structured in a way that reflects human cognitive process and are easier to map onto object-oriented programming constructs. Note that RFD is a design tool rather than an analysis tool which will not provide for the communication with customers. We summarize and compare MOOD with other major existing methods in Tables 1, 2 and 3.

Conc lus ions

The modelling techniques play an important role in the development of complex software system. MOOD, the modelling method proposed here, uses graphic notations to specify the functions, client-server relationships, internal behaviour and class structure among solution-domain entities. The characteristics of MOOD are summarized below:

(1) Provides an entity-refinement approach for discovering classes, objects, and their operations systematically.

Table 1. Object identifications

Methods Object identification

Booch

Rumbaugh 2

Coad and Yourdon 3

Shlear and Mellor 4

Wirfs-Brock 5

Yourdon 6 SA

HOOD 7

GOOD s

MOOD

Suggests using domain analysis to discover candidate classes, and then model the world by identifying the classes and objects that form the vocabulary of the problem domain.

Identifies candidate objects and classes from textual descriptions of the problem.

Identifies objects from some observations: 1. Structures. 2. Other systems. 3. Devices. 4. Things or events remembered. 5. Roles played. 6. Operational procedures. 7. Sites. 8. Organizational units.

Objects are likely to fall into the following five categories: 1. Tangible things. 2. Roles. 3. Incidents. 4. Interactions. 5. Specifications.

Identifies objects from textual descriptions.

Functional decomposition approach to discover sub-functions.

Object decomposition approach to discover solution- domain objects.

Object decomposition approach to discover both problem-domain and solution-domain objects.

Entity-refinement approach to discover solution domain entities and their operations.

Table 2. The comparison of modelling tools

I methods ~ Architecture Object

Booch

Analysis

Dynamic

Design

Rumbaugh 2

Coad and Yourdon 3 Subject diagrams

Shlear and Mellor 4

Wirfs-Brock 5

Object Model Diagrams (OMDs)

Object Model Diagram

ERDs

STDs or Harel statechart

STDs

STDs

Yourdon 6 SA DFDs ERDs STDs

HOOD 7

Functional Architecture Object Dynamic

Modules Class STDs diagrams or diagrams and Process Timing diagrams diagram

DFDs Layered Refined- hierarchy OMDs

Service-chart, Flow-chart and Message- connections

DFDs

GOOD s

MOOD

PDL (Process Description Language)

Functional

Object diagrams

Refined- OMDs

Subsystems Class hierarchies

Structure chart

HOOD diagram

Seniority hierarchy

Structured- Refined- RFDs OMDs

STDs or Ada-based PDL

Collaborated graphs

PDL (Program Description Language)

Ada-based PDL and Object Def. Skeleton

Composition hierarchy

RFDs


An object-oriented modelling approach to system software design." P J Lee et al.

Table 3. S u m m a r y o f the methods

Methods Character is t ics s u m m a r y

Boochl 1.

Rumbaugh:

Coad and Yourdon ~

Shlear and Mellor a

Wirfs-Brock 5

Yourdon ~ SA

HOOD 7

GOOD ~

MOOD

2. 3. 4. 5.

1. 2. 3. 4. 5.

1

2. 3. 4. 5.

I 2. 3.

4.

1 2. 3.

1. 2. 3. 4. 5.

1. 2. 3. 4. 5.

1. 2. 3. 4. 5. 6. 7.

1. 2. 3. 4. 5.

6.

7. 8. 9.

Perform modelling during design phase• Richness of notations. Weakness of modelling process. Suitable for concurrent software constructions. Round-trip gestalt design.

Known as OMT. Iteration is critical. Modelling during analysis phase and detailed in design and implementation phases. Combine ERD and class structure into object model diagram• Architecture modelling is considered until design phase.

• Nearly all the system is described in a single diagram (in fact, it is an enhanced ERD), this diagram is considered to have several layers--objects, structure, subjects, attributes and services layers. This approach is simple but may be difficult to work with a large system. Modelling during analysis phase. Weakness of architecture modelling. Data modelling and structure modelling are combined.

• Modelling during analysis phase. Emphasize ERD constructions. STD is significant for those objects with dynamic behaviour. In general, it is not suitable for functional description of most kinds of objects. Architecture modelling is missing.

• Data modelling is missing. Behaviour modelling is missing. Bottom-up approach.

Modelling both during analysis and design phases• Top-down functional decompositions. The transition from structured analysis (DFDs) to structured design (Structure chart and packages) is very difficult. The emphasis on structure analysis (i.e., functions) is very different from that of object-oriented development (entities). Currently, it is a well-developed and popular methodology for business software systems.

Suitable tbr concurrent software construction• Object-based method. Nested object concepts. Has been applied to a number of airspace projects. Uses object-decomposition approach to find solution-domain objects.

Uses object-decomposition approach to model the architectural view of the world. Data modelling is missing. Behaviour modelling is missing. Top-down approach. Has been refined by a pilot project to develop a system of about 50,000 statements of Ada codes. Object-based. Nested object concepts.

It models the functional, internal behavioural, and static objects view of the solution domain. Systematic approach to find classes, objects, and operations. Different models are integrated together closely. Nested objects concepts. RFDs to model the functional view (client-server and containing relationships) of the system is more natural than DFDs in traditional structured methods. It can be seen that the RFD is more natural for human cognition and easier for incorporating with the programming constructs. Reusability is considered ('with' design reuse and 'for" design reuse). The mapping of models into programming codes is straightforward. Suitable for concurrent software constructions.

(2) Provides a systematic approach for deriving request flow diagrams (functional modelling).

(3) Provides a systematic approach for deriving class structures (structural modelling).

(4) Different models can be integrated together closely. (5) Nested object concept is employed. (6) Uses RFDs to model the functional view (client-server

and containing relationships) of the system, which is more natural than using DFDs, as in traditionally structured methods.

(7) Reusability is considered ('with' design reuse and 'for' design reuse).

(8) The mapping of models into programming codes is straightforward.

(9) Suitable for concurrent software construction.

R e f e r e n c e s

1 Booch, G Object-oriented design with applications Benjamin/Cummings (1991)

2 Rumbaugh, J, Biaha, M, Premerlani, W, Eddy, F and Lorensen, W Object-oriented modelling and design Prentice-Hall (1991)

3 Coad, P and Yourdon, E Object-oriented analysis Prentice-Hall (1990) 4 Shlaer, S and Mellor, S Object-oriented systems analysis: modelling

the worm in data Yourdon Press (1988).



5 Wirfs-Brock, R, Wilkerson, B and Weiner, L Designing object-oriented software Prentice-Hall (1990)

6 Yourdon, E Modern structured analysis Prentice-Hall (1989) 7 HOOD technical group and working group, HOOD reference manual

and HOOD users manual European Space Research and Technology Center, Version 3.1 (1991)

8 Seidewitz, E 'General object-oriented software development: back- ground and experience' Journal of Systems and Software Vol 9 (1989) pp 95-108

9 Jalote, P "Functional refinement and nested objects for object-oriented design' IEEE Trans. Soft. Eng. Vol 15 No 3 (March 1989)

10 Booth, G 'Object-oriented development" IEEE Trans. Soft. Eng. Vol SE-12, No 2 (February 1986) pp 211-222

11 Chen, D J and Lee, P J 'A requirement organization approach for object-based construction of software systems" accepted by Journal of Inf. and Soft. Technol. (1992)

12 Lee, P J An object-oriented modelling approach for the analysis and design of large system software PhD Dissertation of National Chung- Tung University, ROC, 7 (1993)

13 Chen, D J and Lee, P J 'On the study of software reuse using reusable C + + components' accepted by Journal of Systems and Software (1992)

14 Chen, D J and Huang, S K "Interface of reusable software components ~ accepted by Journal of Object-Oriented Programming (1992)

15 Pao-Jyh, L and Feng-Jian, W 'TriO: an object-oriented operating system for education' Proc. of Int. Computer Symposium Hsinchu, Taiwan, ROC (December 1990) pp 926-931

16 Silberschatz, A, Peterson, J and Galvin, P Operating system concepts, 2nd edn, Addison-Wesley (1991) pp 329-355

17 Jackson, M A System development Prentice-Hall (1983) 18 Cameron, J R "An overview of JSD" IEEE Trans. Soft. Eng. Vol

SE-12. No 2 (February 1986) pp 222-240


Documents

An object-oriented modelling approach to system software design