C:\edix\open\webieee96.pdf

OPEN: Towards Method Convergence
with other input from the OPEN methodology collaborative team of ezivin, L.L. Constantine, P. Desfray, R. Du¶e, D. Mehandjiska-Stavrova, B. Meyer, J.-M. Nerson, J.J. Odell, M. Page-Jones, T. Reenskaug, B. Selic, A.J.H. Simons, P. Swatman, R. Winder This paper was published in IEEE Computer, Volume 29 number 4, IEEE Computer °1996 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating newcollective works for resale or redistribution to servers or lists, or to reuse any copyrightedcomponent of this work in other works must be obtained from the IEEE.
In the beginning, there were no object-oriented (OO) methodologies. Around 1990, a collection of analysis and (predominantly) design techniques were published, either in paperor book form. These approaches were, in general, derived independently and (possibly)tested with local industry. Over the next few years, the increasing number of publicationsand international conferences allowed the OO methodologists to meet, discuss and exchangeideas. This then led to a \second round" of publications, which may loosely be termedsecond generation in the sense that they unashamedly borrow from other sources. Exam-ples are Fusion (using CRC, Booch, OMT and formal methods) and the second editionof Booch's \Object-Oriented Analysis and Design". These second generation approachesdo not invalidate the ¯rst generation approaches (unless they are a second version e.g.
Booch93/94 does replace the 1991 version). Consequently, by the mid-1990s methods suchas RDD, OMT and OOSE co-existed with more recently published methodologies such asBooch93/94, MOSES, SOMA, Martin/Odell, BON and OOram.
Whilst Grady Booch and Jim Rumbaugh continue to focus on OO modelling tech- niques as they develop \a method for specifying, visualizing and documenting the artifactsof an object-oriented system development", there is no stated intention to include in theirjoint work any process model or any signi¯cant concern or focus on business issues, strategicplanning, project management, reuse strategies, requirements engineering, metrics, legacysystems, interface design, transaction processing or formal speci¯cations. The stated aimof the OMEGA project[1], creating the ¯rst, fully-tested third generation methodology,OPEN (Object-oriented Process, Environment and Notation), is to do just this: providea FULL process model underpinning for systems to be developed, initially within thebusiness context, across the full lifecycle including reuse, quality, transactions and legacysystems. In addition, OPEN will o®er support for HCI, concurrency, databases, distributedsystems, fuzzy logic, AI and intelligent agents. Incorporating, as it does, many ideas frommethodologies such as RDD, BON, MOSES, SOMA, Martin/Odell, Syntropy, ROOM,OBA, OOram, FOOM etc., OPEN is a truly third generation methodology. In addition,many of those authors have pledged active support of OPEN, as evidenced by the authorlist for this column.
The good news, therefore, is that OPEN is not just another methodology. We do not add one more to the overall count of current OO methodologies. On the contrary,the OPEN methodological framework outlined here will signi¯cantly decrease the numberof methods available to be chosen from, superseding as it does MOSES, SOMA, BON,Martin/Odell, etc. The draft handbook for the OPEN methodology is currently in thehands of the methodology developers and the industry users | names such as Dow JonesTelerate (in Sydney), SBC Warburg (in London), JP Morgan, FourFront (in India), LBMS.
Only following industry testing will we publish the de¯nitive OPEN Handbook.
The overall OPEN life-cycle process model
OPEN is fully object-oriented. Even its life-cycle model is represented as a network of interacting objects (Figure 1(a)). Each object represents an Activity. Transition betweenActivities is governed by a contract (usually pre- and post-conditions and invariants) |we thus call this life-cycle the contract-driven life-cycle. Activities include a well-speci¯edtesting programme and should deliver test results against both task scripts and a normaltechnical test plan.
The contract-driven lifecycle does not prescribe only one deterministic process.
Rather, it permits (1) ordering in an iterative and incremental fashion and (2) the tai-loring by a given organization to its own internal standards and culture | an importantcomponent for each organization's internal \culture". We indicate in this diagram onlysome of the likely routes between Activity objects. But remember, the main governingconstraint on the routes are whether you do or do not meet the pre-conditions of theActivity to which you wish to transition. The post-conditions are your assurance of qual-ity. Di®erent process con¯gurations, chosen to re°ect the needs of di®erent problems anddi®erent organizations, can be constructed from this °exible framework. Once chosen,the lifecycle process is ¯xed | although still, at least in an OO project, highly iterative,°exible and with a high degree of seamlessness[2].
On the left hand side of Figure 1(a) are Activities which are associated with a single project; on the right hand side, in the shaded box, are those Activities which transcend asingle project and are associated more with strategic planning and implementation concernse.g. resources across several projects; reuse strategies; delivery and maintenance aspects.
OPEN includes both projects and organizational software strategies. The relation of theprocess lifecycle in Figure 1(a) to the business issues is illustrated in Figure 1(b) in whichit can be seen that software development can be viewed as a recurring set of enhancementsfollowing the ¯rst of the iterative cycles (i.e. the growth period).
Activities and Tasks
The Activities permit a largescale structuring of the project management for an OO product development. What they don't do is to identify things that have to be done ata low enough resolution to match with tasks that need to be done in order to meet theobjectives of each Activity. For example, when the developer is focussing on an Activitysuch as Evolutionary Development, there are a number of associated Tasks which need tobe undertaken successfully. One of these is the Task: Structure the object model. Thisis a clearly delineated task that someone can take responsibility for (the delivery of awell-structured object model for the problem in hand). We should also note that for thisparticular Activity, more than one task may well be identi¯ed; for other Activities theremay be predominantly only one Task required. OPEN's Tasks are therefore statements ofthings that need to be done. They may be described as the \smallest unit of work on aschedule which contributes to a milestone". Tasks are either completed or not completed.
We can thus think of these links (Activities to Tasks) in a probabilistic manner and visualize them in a 2-D matrix which links together each Activity with each Task andallocates to that linkage a measure of possibility of its occurrence. Following industrytests, we will give our overall recommendations for each Activity/Task pair in terms ofM (=mandatory), R (recommended) O (=optional), P (=possible | but unlikely) and F(=forbidden). For example, planning the number of iterations in an OO development is notlikely to occur in the Evaluation Activity. Finding the CIRTs (CIRT is a generic term toinclude class, instance, r^ ole and type) is almost certainly mandatory in the Development Activity (Rapid OOA/D/P and testing). Constructing a Distributed Systems Strategymay be totally absent in some software projects; but critical to the project's success inothers. For any speci¯c project the actual pattern of M/R/O/P/F should be determinedas part of the initial planning activity, usually the responsibility of the project manager.
This is part of the process of tailoring the OPEN methodology to your own organization.
This two-dimensional matrix also o®ers the project manager signi¯cant °exibility. If new ideas/tasks are developed in a particular context, then incorporating them into thisframework is extremely easy. It only requires the addition of a single line in the matrixand the identi¯cation of the M/R/O/P/F nature of the interaction between this new taskand the activities of the chosen lifecycle process model.
Tasks and Techniques
However, knowing that the Task: Structure the object model is one (of several) tasks that the developer can undertake in order to complete the Activity does not tell thedeveloper how to accomplish the Task(s). The Task is the statement of the unit of workrequired, the \what"; the \how" is described by one or more Techniques. This is similarto saying that I want to hang a picture on my living room wall. This is today's Task. Buthow do I do that? I use some Technique | but often I have a choice between techniques;and furthermore I may use not just one but several techniques to accomplish my task. Inthis case I have a choice between using (a) a hammer to knock a nail into the wall or (b)a screwdriver and a screw together with (for either option) a piece of string and knowledgeof how to tie an appropriate (reef) knot.
OPEN does not mandate techniques | you are at liberty to accomplish these tasks with whatever tools and techniques you are familiar with. However, in order to aid thedeveloper, the OPEN methodology does include a large range of suggested techniqueswhich we, and others, have found to be appropriate. Again there is a fuzzy nature to thelinkage of techniques and tasks. Some tasks are clearly best accomplished with a single,speci¯c technique | a technique applicable to that task and nothing else (for example,implementation of services which support the coding task). Other techniques will be founduseful in a range of tasks (for example, contract speci¯cation). And ¯nally for some tasksthere may be a choice that the project manager has to make. For example, there are many ways of identifying classes, objects and types. These include interactive techniques suchas the use of CRC-like cards to identify responsibilities; scenarios/task models/scripts/usecases to focus on functionality delivered as a prelude to ¯nding CIRTs within these scripts;textual analysis, in which nouns in the requirements analysis have the potential to berealized as CIRTs; simulation which focusses on the objects within the modelling exercise;and even (for some skilled people), the use of ER diagrams as a basis for an CIRT structurediagram.
OPEN has over 100 suggested and proven techniques from which to choose. Many focus on business issues (e.g. cost estimation and project planning), others on reuse (com-pletion of abstractions, generalization, patterns and frameworks). We believe in the impor-tance of quality, through techniques such as contracting[3]. User requirements capture isalso fully supported by the use of task scripts, a more generic version of use cases[4] whichprovide a seamless link between business objects and (software) system objects. Tasksalso provide the basis for the task point metric | a focus of the International OO MetricsClub.
The OPEN technology supports a metamodel compatible with the emerging OMG standard, a fully OO, responsibility-driven and contract-driven object model with connec-tions which do not break encapsulation, a suite of techniques to manage large models andtheir inherent complexity, technical support for r^ oles, patterns, frameworks and distributed object systems | all supported by a full notation and a growing number of CASE, require-ments engineering, metrics and BPR tools such as SOMATiK, Simply Objects, MetaEdit,Graphical Designer.
OPEN is a methodology that contains many options from which to choose so that when that choice has been made the resulting method, tailored to your organization andyour project, is readily learnable and becomes your organizational standard; yet \yourown methodology" is completely compatible with the published (and larger, more com-prehensive) OPEN methodology, supported worldwide by consulting and training orga-nizations (e.g. Tower Technology, Vayda Consulting Inc., COTAR), CASE tool vendors(e.g. Bezant Object Technologies, Advanced Software Technologies, Inc., Adaptive ArtsPty Ltd, Taskon) and users (e.g. Dow Jones Telerate, SBC Warburg) | a methodologywhich opens the door to your software development future.
References
[1] Henderson-Sellers, B., 1995 Methodology | convergence is in the air!, Object Magazine, [2] Wald¶en, K. and Nerson, J.-M., 1995 Seamless Object-Oriented Architecture, Prentice [3] McKim, J., 1996, Programming by contract, IEEE Computer, March 1996 [4] Graham, I.M., 1996, Task scripts, use cases and scenarios in object-oriented analysis, Object-Oriented Systems, 3(3), 123-142
Methodologies consulted: (perhaps as a side bar)
Booch93/94 | Booch, G., 1994, Object-Oriented Analysis and Design with Applications (2nd edition), The Benjamin/Cummings Publishing Company, Inc., RedwoodCity, CA, 589pp en, K. and Nerson, J.-M. 1995, Seamless Object- Oriented Architecture, Prentice Hall, 301pp CRC: Class, Responsibility, and Collaborations | Beck, K., and Cunningham, W., 1989, A laboratory for teaching object-oriented thinking, SIGPLAN Notices, 24(10)
FOOM: Formal Object-Oriented Methodology | Swatman, P., 1995, Documentation from http://mae.ba.swin.edu.au/»paul/foom.html Fusion | Coleman, D., Arnold, P., Bodo®, S., Dollin, C., Gilchrist, H., Hayes, F. and Jere- maes, P., 1994, Object-Oriented Development: the Fusion Method, PrenticeHall Inc., Englewood Cli®s, NJ, 313pp Martin/Odell | Martin, J. and Odell, J.J., 1995, Object-Oriented Methods. A Foundation, MOSES: Methodology for Object-oriented Software Engineering of Systems | Henderson- Sellers, B. and Edwards, J.M., 1994a, BOOKTWO of Object-Oriented Knowl-edge: The Working Object, Prentice Hall, Sydney, 616pp OMT: Object Modeling Technique | Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W., 1991, Object-oriented Modelling and Design, PrenticeHall, New Jersey, 500pp OOram: Object-Oriented Role Analysis Method | Reenskaug, T., Wold, P. and Lehne, O.A., 1996, Working with Objects. The OOram Software Engineering Manual,Manning, Greenwich, CT, USA, 366pp OOSE: Object-Oriented Software Engineering | Jacobson, I., Christerson, M., Jonsson, Overgaard, G., 1992, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison Wesley, 524pp RDD: Responsibility Driven Design | Wirfs-Brock, R.J., Wilkerson, B. and Wiener, L., 1990, Designing Object-Oriented Software, Prentice Hall, 368pp ROOM: Realtime Object-Oriented Method | Selic, B., Gullekson, G. and Ward, P.T., 1995, Real-Time Object-Oriented Modelling, John Wiley & Sons, Inc., NewYork, 525pp Syntropy | Cook, S. and Daniels, J., 1994, Designing Object Systems, Prentice Hall, UK, SOMA: Semantic Object Modelling Approach | Graham, I.M., 1995, Migrating to Object Technology, Addison{Wesley, Wokingham, UK, 552pp Figure Legends
Figure 1(a) Contract-driven process lifecycle model Figure 1(b) The process lifecycle is embedded in an iterative cycle of growth and enhance-

Source: http://www.open.org.au/open/Publications/Documents/webieee96.pdf