the osmosis path to method unification

pp. 451-458 451

Jean BI~ZIVIN *

The Osmosis path to method unification

Abstract

The last years have seen the emergence of a number of so-called object-oriented analysis and design methods (OOADM) like class-relation, OMT, Shlaer-Mellor, etc. In order to cope with the importance and diversity of these offerings, a strong trend toward unification has recently developed. For the time being, this unification movement has a scope mainly limited to notational aspects. In order to be really useful, it should also apply to the organizational aspects, i.e. not only to formalisms but also to processes. A general life cycle reference model called d a is proposed here as a possible alternative to con- ventional schemes, giving rise to a regular organization of processes and products in the software development cycle. Since most of these products are expressed in an object-oriented formalism, their interoperation should be addressed in a general way. Instead of using a class- based meta-notation, we have defined, for that purpose, a minimal knowledge representation kernel called sNets, a specific kind of semantic networks. The da organization framework and the sNet core notation are the two main components of the Osmosis workbench. The synergy between these notational and organizational concepts gives rise to an original pilot software production scheme.

Key words : Software engineering, Object oriented method, Refe- rence model, Software workshop, Semantic network, Knowledge representation.

L'UNIFICATION DES MI~THODES DANS LE PRO JET OSMOSIS

Rrsum6 Ces dernidres ann~es ont vu l' ~mergence d'un grand

nombre de m~thodes dites d'analyse/conception par

objets comme classe-relation, OMT, Shlaer-Mellor, etc. Afin de pouvoir maftriser l'importance et la diversit~ de ces offres, une forte tendance unificatrice s'est r~cem- ment ddvelopp~e. Pour le moment, ce mouvement uni- ficateur s'int~resse essentiellement aux aspects notationnels. Pour qu'il soit v(ritablement utile, il faudrait qu'il s'applique Ogalement aux aspects organisation- nels, c'est-gt-dire pas seulement aux formalismes mais aussi aux proc~d~s. Un module g~ndral de rdf~rence pour le cycle de vie appel~ j3 en tant qu'alternative aux schemas classiques et constitu~ d'une organisation rdgulidre des proc~d~s et des produits dans le cycle de d~veloppement du logiciel est propose. La plu- part des produits ~tant exprim~s dans un formalisme d objets, leur interfonctionnement doit dtre consid(r~ d'une fagon aussi g~n~rale que possible. Au lieu d'uti- liser une m~ta-notation basre sur le concept de classe, un noyau minimal de representation de connaissances appel~ sNets, une forme sp~cifique de r~seaux s~man- tiques typds, rdflexifs et modulaires est ddfini. Le cadre d'organisation j3 et le noyau de notation des sNets sont les deux composants essentiels de l'atelier Osmosis. La synergie entre ces concepts notationnels et organisation- nels donne naissance gt un schrma original de d~veloppement de logiciel.

Mots elks : Grnie logiciel, Mrthode orientre objet, ModUle rrfrrence, Atelier logiciel, Rrseau srmantique, Reprrsentation connaissances.

Contents

I. Introduction. II. Software development : themes and variations.

III. In search of a general organization. IV. In search of a meta-notation. V. Conclusion.

References (14 ref.).

* Universit6 de Nantes, 2, rue de la Houssini~re, F-44072 Nantes Cedex 03, France.

1/8 A~N. TI~L~COMMUN., 51, n ~ 9-10, 1996

452

I. INTRODUCTION

Transitioning from procedure-oriented to object- oriented (oo) development methods may prove to be more difficult than foreseen. One of the reasons is that we may be too shy in giving up traditional ways of thinking. Sticking to the classical analysis-design- implementation cycle may lead us to a wicked under- standing of the real nature of the oo development process. Even the exact meaning of design process may radically change when moving from procedural to oo culture.

In order to investigate some of the issues related to the transition from procedural to oo-based methods, we have been building and using an experimental research platform named Osmosis [BEzivin 95b]. The kernel of this system is made of a minimal representation support called sNets, a typed, reflective and modular kind of semantic networks. Using this meta-notation in a systematic way has led us to view the complete oo development cycle as a regular organization of interconnected processes producing or consuming information sets called products or models. Each such model is composed of typed entities (nodes) and of relations between these entities (links) i.e. each model is a partition in the sNet.

Many proposals have been centered around a unique notation or a family of strongly-related notations for all software development tasks. This movement has used the seamlessness argument, i.e. the supposed property of continuity between different object models. In this view, one can progressively build an analysis model from the observation of the real world and then progressively move from this abstract description to more concrete design or implementation models. We have found many difficulties in putting this method to work and this is why we have investigated, in the Osmosis project, the two related issues of software process organization and uniform product notation.

II. SOFTWARE DEVELOPMENT : THEMES AND VARIATIONS

Various aspects of software development take great importance when considering transition to object technology. We present, in this section, some general considerations that have guided our thinking in the Osmosis project.

II.1. Problem and solution.

It is widely recognized that a systematic software development method should emphasize the separation of

ANN. TI~LI~COMMUN., 51, n ~ 9-10, 1996

J. BI~ZIVIN. -- OSMOSIS PATH TO M E T H O D UNIFICATION

the problem space from the solution space. This separation shows up differently in the new oo development world than in the traditional procedural development world. Very often this dichotomy of spaces is associated to the dichotomy between analysis and design or between the what and the how, or simply between abstract and concrete. There are many subtle differences between all these couples of concepts and straightforward assi- milation may be risky.

II.2. Origin of objects.

When we analyze the final code resulting from a software development using such languages as Small- talk, C + + or Java, we face a set of several hun- dreds of classes. Whatever development method is used (or not used), the fundamental question is Where are all these components coming from ? A corollary to this question arises then : Which sequence of obser- vations, choices and constructive efforts has contri- buted to the identification, definition and inclusion of each of these components in the final code ? Answering this question amounts to outlining an object-oriented development method. The principle of excluded sponta- neous generation states that, for any item present in the final code of a system, we should be able to list the sequence of observation records, reasoning statements and decision steps that have resulted in the final choice to include this object in the operational software.

II.3. Elaborational vs. transformational strategies.

There has been, in the recent period, many discussions on the organization of the software development cycle and on the deep nature of the design process. Two schools of thought have expressed different views on the transition between analysis and design, one based on elaboration and the other one based on transformation. In the elaboration camp, one finds the Booch approach [Booch 91] and the Rumbaugh approach [Rumbaugh 91]. Two examples of the transformation camp are class- relation and Shlaer-Mellor [Shlaer 92].

In the design by elaboration school, abstract application models are first built up. These analysis models are elaborated, refined and then optimized to produce a practical design [Rumbaugh 91]. In another elaborative proposal [Booch 91], the developer first identifies key application abstractions and then shift his perspective towards finding new objects to put these abstractions to work. This iteratively repeated process changes or adds new objects to the model until reaching stability. One of the most advocated advantage of elaborational design is its smoothness and continuity, from analysis to design and then to coding. The main work through- out the whole development process consists in adding application information. Several drawbacks of elabora-

2/8

J. BI~ZIVIN. -- OSMOSIS PATH TO METHOD UNIFICATION

tive methods have been outlined. The most serious one stems from the absence of separate domain analysis models because these models are modified, refined, adjusted and optimized to account for all kinds of design and implementation considerations. As a consequence, reusability of analysis is thus hampered. Other drawbacks are related to reversibility of the process (in case of errors for example), reproducibility, traceability, etc.

The transformational approach usually assumes the existence of a number of separate so-called domains, i.e. work products related to a given logical task in the development process. Associated to domains, one may find sets of transformation rules, specifying automatic, semi-automatic or manual transformation procedures of the domain content into other domain work products. Since domains are not intermingled, the various work products may be more easily reused. Although it seems less progressive or even less natural than the elaborational approaches, the transformational schemes seem to lead to a clearer organization of the software process.

453

Implicit statement of the goals has been lost in the move from top down procedural decomposition to object composition. Such a statement has to be reintroduced in a complete object approach. The best known way to do this is the use case concept [Jacobson 92]. Obviously this separate expression of service has to be taken explicitly into account in the new software production organization.

IlL IN SEARCH OF A GENERAL ORGANIZATION

As an alternative to the classical analysis/design/ implementation, we borrow ideas from three different sources in order to build a simplified organization framework called j3.

11.4. Traceability.

According to E. W. Berard, Traceability is the degree of ease with which a concept, idea or other item may be fol lowed from one point in a process to either a suc- ceeding, or preceding, point in the same process. For example, one may wish to trace a requirement through the software engineering process to identify the delive- red source code which specifically addresses that requirement. Traceability was a natural property of such organization as the cascade model because one item was directly linked to either the next level or the following level. Similarly, traceability was not too difficult to implement in hierarchical top-down or bottom-up organization. In a general object-oriented multi-model system, traceability, at the same time, become more important and more complex to implement.

11.5. Stating the goals.

In a hierarchical top-down procedural decomposition process, the root of the decomposition tree had several usages. It was used as the goal, and could be associated to several information like reliability or performance information, or estimation of the project resources nee- ded to achieve implementation.

In a pure object composition scheme, explicit statement of the goals (i.e. of the service that should be performed by the system) have completely disappeared. In such a pure object scheme, building a good system (i.e. a system with good software engineering qualities) becomes the priority over building the good system (i.e. the system answering the real needs of its potential u s e r s ) .

III.1. The vertical approach (Jackson).

We call vertical axis (Fig. 1) what Jackson calls coupling between the worm on one side and the machine on the other side [Jackson 95]. The worm may be associated with the domain analysis model or the universe of discourse. It embodies all possible statements of problems. On the other side, the machine corresponds to the domain of resources, mainly computer resources that may be used in the solution.

declarative specification of coupling

FIG. 1. - - J a c k s o n ' s a p p r o a c h : the ver t ica l s cheme .

L'approche de Jackson : le schema vertical.

111.2. The horizontal approach (Jacobson/Johnson).

We call horizontal axis (Fig. 2), the path from goals to solutions and more precisely we suppose that goals are expressed as use cases [Jacobson 92] and solutions as design pattern instances [Gamma 94]. We have here two models (requirement and design) and a process path between them. As a matter of fact, this is a very simplified presentation because the design process will itself be decomposed in several sub-processes. Also the

3/8 ANN. T~LI~COMMUN., 51, n ~ 9-10, 1996

454 J. Bt~ZIVIN. -- OSMOSIS PATH TO METHOD UNIFICATION

f r o m user

n e e d s m o d e l

u s e cases i i i i

design process

patterns i i I i

implementation model

FIG. 2. - - From use cases to design patterns.

Des cas d'usage aux schdmas de conception.

requirement model is the result of a less formal model corresponding to final user interviews and workshops (user needs model).

The importance of a separate expression of services in the context of object technology has been advocated by Jacobson. Although not mentioning explicitly a requirement model, this idea was also present in the JSD method [Jackson 83] as a separate phase of the process called adding function to the system : <( The model, or simulation, of the real world resulting from the first three steps of the JSD development procedure provides the basis on which the system functions are to be specified. In the function step the developer specifies the system functions in terms of the model. Broadly, a Jso function is specified in the form : When such-and-such a combination of events has occurred in the real world, the system should produce such-and-such outputs. >~

III.3. Combined approach (j3).

da is thus the proposed synthesis between the ideas of Ralph Johnson (as the representative of the software design pattern movement), Michael Jackson (the father of the well known JsD method and also the promoter of recent ideas on the world and machine organization) and Ivar Jacobson (the inventor of use case engineering), j3 may be regarded as the cross-shaped organization resulting from the superposition of a vertical axis (the Jackson axis) and an horizontal axis (the Jacobson/Johnson axis).

So, the first idea is that there are three different domains : world, machine and service. Translating this in terms of object technology, we may state that we have three models that correspond to domain analysis, resource analysis and service analysis (that we call requirement).

Entities from the domain analysis model are called business objects. Entities from the technical resources model are called technical objects. Entities from the requirement model are called requirement scripts and may be viewed as a generalization of use cases.

Design is the activity that results in the creation of the design model (Fig. 4). The Osmosis nature of the design activity may seem classical. As a matter of fact it is not and contradicts many current expressed views. In several presentations, the essence of the design phase

\technical resources/~

FIG. 3. - - The combined .i3 scheme.

Le schdma combind .13.

~ technical requirement resources

" model , C I o d e l

design model

operational model

FIG. 4. - - The j3 life cycle reference.

Le modOle de rdfdrence du cycle de vie .13.

is mainly to transform a declarative description into an implementable one. The view presented in [deCham- peaux 92] defines analysis as the production of a declarative description of what the proposed software is supposed to do, design as the production of a computational description of software that meets analysis requirements, and implementation as the production of an expression of the design suitable for the target environment.

Our definition of design is an activity that has the purpose of combining together business objects and

ANN. TI~LI~COMMUN., 51, n ~ 9-10, 1996 4/8

J. BEZIVIN. -- OSMOSIS PATH TO METHOD UNIFICATION

technical objects in order to fulfill some particular needs expressed by requested services in the requirement model.

The notion of combination is essential here. Combina- tion is, to object-based technology, what refinement was to procedure-based technology. We see a body of knowledge progressively consolidating around the notion of object composability techniques [Nierstrasz 95]. The pattern movement [Gamma 94] is also representative of this evolution. What appears in Figure 5 is that the design model is composed of pattern instances or frames. Each such frame is linked to its source requirement script (the goal it is supposed to fulfill) and also to business and technical object involved.

III.4. Illustration.

Let us take one example and suppose we are working on a bank system. One item of our world domain could be a BankAccount. Similarly, on the computer resource side (the machine domain), we find a LaserPrinter device.

Among the services that have to be provided, is the following one : << Every Monday, each account owner of the bank, with a negative balance, should be sent a printed letter giving the current state of the account >>. This informal statement is transformed in a requirement script, let's say Service#1297. This script will be used, as a starting point, to define the frame that will be responsible to deliver the particular service let's say Frame #F54.

Stepwise refinement of functions in traditional practice is considerably easier than merging objects in

q

455

object-oriented development. However certain systematic techniques are beginning to emerge. Besides the basic mechanisms of inheritance and aggregation, one may quote more elaborated techniques such as the use of gluons described in [Pintado 91], outlining a gene- tic software development tool based on the composition of independently constructed objects (remember that business and technical objects are created without kno- wing how they will be used later, in future applications). Inter-component communication is mediated by such interconnection objects that assume the responsi- bility of component interaction and conceals interface differences between the components.

/ ~ ////Frame #F54

FIG. 6. -- Implementing a service.

Mise en eeuvre d'un service.

In the very simple illustration example presented above, the frame may be composed of an independent object, interrogating the different accounts, analysing the extracted data according to a given business rule, and then requesting the printer technical object to achieve the corresponding service.

domai analys~

model model

FIG. 5. -- Some traceability links.

Quelques liaisons de tra~abilit~.

mical , ~ources

model

5/8 ANN, T~LI~COMMUN., 51, n ~ 9-10, 1996

456 J. BI~ZIVIN. -- OSMOSIS PATH TO METHOD UNIFICATION

IV. IN SEARCH OF A META-NOTATION

IV.1. The problem.

So, as we have seen, the life cycle is populated with a number of so-called models. We have previously met the essential models (requirement, domain analysis, technical resources, design, implementation), but there are much more of them. On the horizontal development axis, in addition to the user needs model, there is a number of intermediate models between the requirement and the design model. Several other models have also been mentioned in the previous discussion and many more should be added to make the software development line complete. Let us mention test models, metrication models, reliability models, deployment model, etc.

Furthermore each model is usually composed of sub- models. In a domain analysis, for example, several par- titions may correspond to natural decomposition of the organization like accounting, sales, production, marke- ting, etc. But in many cases there are also other point of view decomposition. It is usual for example to consider three points of view on a given situation : structure (what are the entities, their attributes and the basic relationship between them ?), communication (how, when and what do the entities exchange ?) and behaviour (what is the dynamic behaviour of the entities ?).

So we face an important number of models and sub-models in the life cycle. Each model concerns a particular subject, but there are nevertheless several links between different models, the traceability links being one important category of these. As a consequence we need a notation that will be able to describe each model and also the relations between different models. In view of the diversity of the models, this can only be achieved by a very primitive meta-notation.

IV.2. Models and ontologies.

Each work product in the life cycle corresponds to what we call a model. In the Osmosis project, a model is the image of a given system with respect to an ontology (Fig. 7). An ontology is an explicit specification of the conceptualization of a given domain. It identifies at least the various concepts considered as relevant and the relations between them.

The set of entity types (or concepts) and possible relations between them is defined within an ontology.

In the requirement model for example, we find the Actor and RequirementScript concepts plus several relations between them, like some form of specialization between RequirementScript. These concepts and relations are defined in the requirement ontology and each requirement model conforms exactly to this ontology. In

FIG. 7. - - A model as the image of a sys tem with respect to an ontology.

Un moddle comme image d' un systdme par rapport dune ontologie.

this particular example, the system consists of the set of services wished by the final users. The ontology acts as a filter to extract the essential elements that should characterize this situation.

IV.3. sNets.

Let us take one example (Fig. 8). We can view a system as a Petri net, considering only places, transitions, links from places to transitions or from transitions to places. The starred identifiers mean that there are several possible links from a place to a transition, or from a transition to a place. There is no possible link in this ontology from a place to a place or from a transition to a transition. Note that we have not included here a link between place and number of tokens. The model described in the example has a graphical presentation useful to the Petri net specialist, but carrying no more information than the textual form.

runiverse Pet riExample; sere Pet riSom; partOf I'driGeneral, node

pl,p2,p3: Place; t 1,t2: Transition;

links pTC~ (pl, t]); tTOp (tl, p2); ITOp (tl, p3); pTO= (p2, t2); pTOt (p3, t2); tTOp (12, p1);

end Universe PetriF.xarnplc

IJniverse l>elriSem; semsBase; | parlOf s Root; l concept l

Place; I Transition; I

links I ITOp" ITransition, Placel; | pTO~" I Place, Transitionl; |

end Universe PelriSem; / t |

FIG. 8. - - A s imple situation.

Une situation simple.

All the information is represented by a special kind of semantic networks called sNets. Each node is typed i.e. has a meta-node called its concept. This is pictured by circles in Figure 9 with the lower part showing

ANN. TI~LI~COMMUN., 51, n ~ 9-10, 1996 6/8

J. BI~ZIVIN. - OSMOSIS PATH TO METHOD UNIFICATION

FIG. 10. - - G e n e r a l o r g a n i z a t i o n o f the sNe t sys tem.

Organisation g~n~rale du systdme sNet.

the name of the node and the upper part its concept (or type). There is a layer of functionalities built in a support system called the sMachine and implementing the primitive concept nodes. A standard tool called the sBrowser is provided to navigate in the whole network and to update its content (Fig. 9). This tool is used when no other specialized viewer or graphical editor exists like the one for Petri nets. Facilities to build specialized graphical tools for specific ontologies are provided by the support system.

An important particularity of sNets is their modula- rity. The concept of Universe defines a partition in the graph. This is a real concept, i.e. represented explicitly in the graph by a node. Each ontology is represented by a Universe as is any model. The relation sem holds between a model and its defining ontology. In Figure 10, three universes are shown, U, SU ans SSU.

457

The situation M is a method of class Q is described in a model represented by universe U. The ontology of this model U is defined by universe SU where we find nodes corresponding to the concepts of method and class and to the relation methodOf between a method and a class.

As can been seen in Figure 10, the sNet formalism is modular and reflective. For example ontology SU has its own ontology SSU defining the concepts of Node and Link and some other basic relations.This multi- level modular and reflective architecture allows to define many different formalisms and to describe models with these formalisms.

V. CONCLUSIONS

Recent announcements of the so-called Unified method [Booch 95] has lightened many worries about a possible Babel tower syndrome in the domain of object- oriented analysis and design. While this is usually considered as a positive move, it does not solve all problems and leaves one important interrogation : Is the corresponding unified notation really adapted to the various software activities ? Initial investigation in the field led us to give a negative answer to that question. As a consequence we faced the problem of defining a suitable notation for each separate activity in the software development process (analysis, design, testing, etc.). We then realized that almost every author use the terms analysis, design, implementation, requirement, etc. with a different meaning. It became then obvious that we were put-

FIO. 9. - - S a m p l e r ep resen ta t ion o f a P4tri net.

Echantillon d'un rdseau de P(tri.

7/8 ANN. TI~LI~COMMUN., 51, n ~ 9-10, 1996

458

ting the cart before the horse and that we should first define a common life cycle reference model for object technology prior to discussing common notations. This has led us to propose the j3 model as a general framework for a software process organization.

The Osmosis platform is intended to be a research tool to investigate new forms of software development. As such, it proposes an idealized regular development scheme composed of processes and products. Each product (or model as we call it) has an ontology defining the associated concepts and relations. This allows a much more precise identification of the role of each process in the production of some products, based on the utilization of other products. As a central example, this has permitted to define much more precisely the design process as an activity producing the design model and based on several other well identified products : requirement model, domain analysis model, technical resource model and library of patterns. The origi- nality of the j3 scheme mainly lies in this definition of the design process. Around this part of the software production scheme, many other processes and models are defined. One example is testing. The test model is itself defined by an ontology and related to the requirement model as well as to the design model. After a first set of experiments, we view this basic organization (j3) as well as the meta-notation (sNets) as very efficient tools to understand more clearly the essential problems in new software development practices. We intend particularly to use this framework to specify more rigorously some transformational processes.

ACKNOWLEDGMENTS

We thank all the students of the DESS of gdnie informa- tique of Nantes, for their participation and enthusiasm in this project. We thank also Richard Lemesle for his contribution to the definition of sNets, J~rrme Lanne- luc for his participation to the implementation of the

J. BI~,ZIVIN. -- OSMOSIS PATH TO METHOD UNIFICATION

sMachine and R~gis Berteaud for his help in building the first illustration example. Gilbert Landais has provided many ideas and suggestion of improvement since the beginning of the project.

Manuscrit requ le 25 juin 1996, accept~ le 12 aoat 1996.

REFERENCES

[Brzivin 94] BI~ZIVIN (J.), LANNELUC (J.), LEMESLE (R.). Representing knowledge in the object-oriented lifecycle. Tools Pacific'94, Melbourne, Prentice Hall (Dec. 1994), pp. 13-24.

[Brzivin 95a] B~ZlVlN (J.). Object-oriented requirement elicitation in the Osmosis project. IEEE International Symposium and Work- shop on Systems Engineering of Computer-Based Systems, Tuc- son, Arizona (6-9 March 1995), pp. 289-298.

[Brzivin 95b] BEZtVrN (J.). Osmosis : an ontology-based meta-case. Sixth Workshop on the Next Generation of CASE Tools, Jyviiskylii, Finlande (12-13 June 1995), pp. 137-142.

[Booch 91] BOOCH (G.). Object-oriented design with applications. Benjamin/Cummin, Redwood City ( 1991 ).

[Booch 95] BOOCH (G.), RUMBAUGH (J.). Unified method for object- oriented development documentation set. Version 0.8, Rational Software Corporation (Oct. 1995).

[deChampeaux 92] DE CHAMPEAUX (D.), LEA (D.), FAURE (P.). The process of object-oriented design. OOPSLA'92, ACM Sigplan Notices (Oct. 1992), 27, n ~ 10, pp. 45-62.

[Gamma 94] GAMMA (E.), HELM (R.), JOHNSON (R.), VLISSIDES (J.). Design patterns elements of reusable object-oriented software. Addison Wesley Professional Computing Series (1994), 395 p.

[Jackson 83] JACKSON (M. A.). System development. Prentice Hall International (1983).

[Jackson 95] JACKSON (M. A.). Software requirement and specifica- tions, a lexicon of practice, principles and prejudices. Addison Wesley, ACM Press (1995), 228 p.

[Jacobson 92] JACOBSON (I.), CHRISTERSON (M.), JONSSON (P.), OVER- GAARD (G.). Object-oriented software engineering. Addison Wes- ley (1992), 524 p.

[Nierstrasz 95] NIERSTRASZ (O.), TSICHRITZIS (D.). Object-oriented software composition. Prentice Hall (1995), 361 p.

[Pintado 91] PINTADO (X.). Gluons and the cooperation between software components. Nierstrasz 95, pp. 321-347.

[Rumbaugh 91] RUMBAUGH (J.), BLAHA (M.), PREMERLANI (W.), EDDY (E), LORENSEN (W.). Object-oriented modeling and design. Pren- tice Hall (1991), 500 p.

[Shlaer 92] SHLAER (S.), MELLOR (S. J.). Object-oriented system analysis : modeling the world in states. Prentice Hall Int Inc. (1992).

ANN. T~L~COMMUN., 51, n ~ 9-10, 1996 8/8

the osmosis path to method unification

Documents