Goldberg, A.; Rubin, K.S.: Object Behaviour Analysis. In: Communications of the ACM. Vol. 35, No. 9, 1992, pp. 48-62  Home/Search   Document Not in Database   Summary   ACM   TOC   Related Articles   Check

....1992] and [Rumbaugh et al. 1991] express use cases and event traces with structured english with the claim that narrative texts facilitate the capture of requirements. There are a number of formatted variants such as tables [Potts et al. 1994] structured texts [Regnell et al. 1995] or scripts [Rubin and Goldberg, 1992]. Other media have been used to amplify scenarios, graphics [Rumbaugh et al. 1991] images [Gough et al. 1995] sketches and photographs of the application and its environment, and videos [Wood et al. 1994] to capture a system context or to record design scenarios being discussed in meetings. ....

....scenario descriptions. Scenarios presented in a tabular form are an example. Such tables like in [Potts et al. 1994] often encode temporal sequences of actions or events together with the agent responsible for their executions. Scenario scripts used in the Object Behaviour Analysis methodology [Rubin and Goldberg, 1992] to capture the services offered by the system objects is another example of descriptions based on semi formal notations. Structured representations such as the use case extension proposed by Regnell et al. Regnell et al. 1995] fall in the same category. Regnell et al. propose two kinds of ....

[Article contains additional citation context not shown here]

K. S. Rubin and A. Goldberg, "Object Behaviour Analysis", Communications of the ACM, 35(9):48-62, 9 1992.

.... used to focus discussion on usability issues [14, 27, 45] They support discussion to gain an understanding of the goals of the design [23] and help to set overall design objectives [20, 34] In contrast, scenarios play a more direct role in SE, particularly as a front end to object oriented design [8, 22, 29, 31, 35, 36, 37, 38, 47]. Use case driven approaches [6, 8, 15, 16, 17, 30] have proved useful for requirements elicitation and validation. The aim of use cases in Requirements Engineering is to capture systems requirements. This is done through the exploration and selection of systemuser interactions to provide the ....

....and selection of systemuser interactions to provide the needed facilities. A use case is a description of one or more end to end transactions involving the required system and its environment [28] The basic idea is to specify use cases that cover all possible pathways through the system functions [8, 30, 35]. The concept of use case was originally proposed in Objectory [15, 16] but has recently been integrated in a number of other approaches including the Fusion method [7] and the Unified Modeling Language [38] 1 The work presented in this paper is funded by the European Community within the ....

K.S. Rubin and A. Goldberg, Object Behaviour Analysis, Communications of the ACM 35(9) (1992) 4862.

....Name Refs Type of Pub. Tool Support Cunningham Beck [CuBe86] C Desfray Object Engineering [Des94] T Edwards Ptech [Edw89] T Y Embley et al. EmKu92] T ESA HOOD [ESA89] M Felsinger [Fel87] R Ferstl Sinz SOM [FeSi91] FeSi90] A A Y Firesmith [Fir92] T Goldberg Rubin OBA [GoRu92] A Y Graham [Gra91] T Halladay Wiebel [HaWi93] T Henderson Sellers Edwards [HeEd94] Hen92] T T IBM [IBM90] R Jacobson et al. OOSE [JaCh92] T Y Johnson Foote [JoFo85] A Kadie [Kad86] R Kappel Schrefl [KaSc91] A Lee Carver [LeCa91] A Liskov Guttag [LiGu86] T Martin Odell [MaOd92] ....

Goldberg, A.; Rubin, K.S.: Object Behaviour Analysis. In: Communications of the ACM. Vol. 35, No. 9, 1992, pp. 48-62 40

....2.2.3.6. 5 Other Approaches Other object oriented approaches include Colbert [Col89] Wirfs Brock [Wir90] Champeaux [Cha91b] Hull, O Donoghue and Hagan [HOH91] Barbier [Bar92] Seidewitz and Stark [SS92] Martin and Odell [MO92] Embley and Kurtz [EK92] Jacobson [Jac92] Rubin and Goldberg [RG92], Berard [Ber93] Graham [Gra93] Edwards and Henderson Sellers [EH93] Firesmith [Fir93] Chou and Chung [CC94] Kilov and Ross [KR94] and MacLean et al. [McL94] 2.2.3.7 Summary of Object Oriented Analysis and Specification Methods 48 A natural question that comes from this study is Which ....

Rubin, K.S. and Goldberg, A. Object Behaviour Analysis. Communications of the ACM, Vol. 35, No. 9, pp. 48-62, September 1992.

....and its subclasses. In (Lucas, 1997) this idea was extended to deal with evolution of cooperating classes, and (Mens et al. 1999) discussed the application of reuse contracts to collaborations in UML. Even the application of reuse contracts to requirements models using Object Behaviour Analysis (Rubin et al. 1992) has been investigated (D Hondt, 1998) This paper ties together, extends and generalises these previous efforts by providing one unified approach for software evolution. In order to fully understand this paper, some knowledge of the UML metamodel and the OCL is required (OMG, 1999) Please note ....

Rubin, K. S. and Goldberg, A. 1992. Object Behaviour Analysis. Communications of the ACM, Special Issue on Object-Oriented Methodologies. ACM Press, 35(9): 48-62.

....of system use and illustrations of agent behaviours. Moreover, they allow to elicit requirements in envisioned situations [Potts 94] to help in the discovery of exceptional cases [Rolland 98a] Sutcliffe 98] to derive conceptual object oriented models [Dano97] Rumbaugh 91] Jacobson 95] Rubin 92] to understand needs through scenario prototyping [Hsia 94] and animation [Lalioti 95] to reason about design decisions [Carroll 95] Young 87] create context for design [Kyng 95] and so on. 4 The underlying reason for the popularity of scenario based approaches seems to be that people react ....

.... groups, departments and agents found in it, or even stakeholder information including the characteristics of people, their views and aspirations [Nardi 92] However, scenarios may also concentrate on the required functional features of a system [Firesmith 94] Glinz 95] Olle 92] Potts 94] Rubin 92] Rawsthorme 96] Som 96] Scenarios can be expressed at three different levels of abstraction : instance, type and mixed. In the former case [Carroll 95] Potts 94] Young 87] a scenario uses specific names 5 or events with real argument values. These scenarios describe particular ....

[Article contains additional citation context not shown here]

K. S. Rubin, A. Goldberg, Object Behaviour Analysis. Communications of the ACM, Vol.35, N9, pp.48-62, 1992.

....and conceptualise scenarios. In addition, we focus on textual scenarios, that is to say descriptions of stories of system usage in (more or less structured) natural language. In the literature, textual scenarios are also referred to as stories [6] cases in use case descriptions [18] or scripts [22]. 1 The work presented in this paper is funded by the European Community within the framework of the ESPRIT LTR project CREWS (Cooperative Requirements Engineering With Scenarios) n 21903. Authoring is part of a two step process of scenario authoring goal discovery . Indeed, the CREWS ....

K.S. Rubin and A. Goldberg, Object Behaviour Analysis. Communications of the ACM, 35(9), pp. 48-62, 1992.

....achieves the goal. There are no internal objects visible, just the system itself and the actors originating the stimulus [14, 9] This approach is popular among object oriented methodologies. First proposed by Ivar Jacobson [8] it has been adopted by the Object Behavioral Analysis proposed in [13] or the Object Modeling Technique described in [15] However, there is a gap between the informality in which users describe their expectations concerning the system, and the formality in which these requirements should be described in order to be used during the system development. An attempt to ....

.... a reductionist manner, that is, one entity at a time, use cases serve to provide a more holistic, user centered approach 1 [14] Techniques based on the arguments and pre post conditions of the use cases have been described to identify relevant entities in the domain model (e.g. the OBA method [13], or the SESAME approach [2] The description of these techniques is outside the scope of this paper. Entity behavior is commonly described through state transition diagrams (STDs) which represent the allowable sequence of events for each entity. We follow here the approach presented in [5] ....

K.S. Rubin and A. Goldbeerg. Object behaviour analysis. Communications of the ACM, 35(9):48--62, 1992.

.... Text is probably the most widespread medium used as many authors associate mainly scenarios to narration of stories ( Erickson 95] Holbrook 90] Kyng 95] Jacobson et al. 92] There is however a number of formatted variants such as tables [Potts 94] structured texts [Regnell 95] or scripts [Rubin 92] Graphics [Rumbaugh 91] images [Gough 95] interaction diagrams [Jacobson et al. 92] sketches and photographs of the application and its environment, are grouped under the graphical value. As well as videos [Wood 94] they are used to capture a system context or to record design scenarios ....

....An other concrete example is the failure in automating the London Ambulance Service, due to lack of such kind of requirements [Finkelstein 96] Macaulay 96] 3.2.2. 2 The coverage facet 8 Most scenario models focus on descriptions of behaviours (e.g. Firesmith 94] Glinz 95] Rawsthorne 96] Rubin 92] Jacobson 92] Some 96] either of the system under design or at the level of interactions with the environment. It is more and more accepted by the IS community that system design requires some understanding of the organisation s objectives, intentions and goals. Goal driven approaches such ....

K. S. Rubin and A. Goldberg, "Object Behaviour Analysis", Communications of the ACM, 35(9):48-62, 1992.

.... [3] x x x Bertreaud et al. 4] x Cockburn [5] x x Glinz [6] x Gough et al. 7] x Holbrook [8] x x Hsia et al. 9] x Jacobson et al. 10] x Koskimies et al. 13] x Kyng [15] x x x Leite et al. 16] x x Potts et al. 20] x x x Rawthorne [21] x x x Regnell et al. 22] x x x Rubin et al. [23] x Rumbaugh [24] x Scalzo [25] x x x Some et al. 26] x x Fig. 2 Classification of existing scenario approaches. 2.2 Structuring the Context of Information Systems Each type of system has its own typical context. For example, in the case of information systems the output is typically used ....

.... initiate the execution of a given scenario [4; 7; 16; 22; 23; 26] Postconditions are used to indicate the states of the system and the environment after scenario termination [4; 7; 22; 23] Some approaches propose to express the pre and postconditions as object states of agents and or resources [23]. Others represent pre and postconditions using Approach Agent User Org. Role Goals Location Resource precond. postcond. Armour et al. 1] X X X B aumer et al. 2] X Benner et al. 3] X Cockburn [5] X X X X X Holbrook [8] X X Kyng [15] Leite et al. 16] X X X X X Potts et al. ....

Kenneth S. Rubin and Adele Goldberg. Object behaviour analysis. Communications of the ACM, 35(9):48--62, 9 1992.

....relationship between enterprise goals and IS requirements, and the application of scenarios to the operationalisation of enterprise goals. Until now, scenarios have been used in goal oriented approaches mainly for goal identification ( Potts [4] Dardenne, Lamsweerde [7] Rubin and Goldberg [29] , Thebaut, Interrante [30] Holbrook [31] validation ( Potts, Takahashi [32] Carroll and Rosson [33] Anderson and Durney [34] and prototyping purposes ( Rosson and Carroll [35] Hsia, Samuel [36] Hooper and Hsia [37] The novelty of our work is in the use of scenarios as the ....

Rubin, K.S. and A. Goldberg, Object Behaviour Analysis. Communications of the ACM, 1992. 35(9): p. 48-62.

.... advance in object oriented analysis, since it allowed the process of requirements capture to begin further upstream than with na ve object modelling [4] Different scripting techniques in object oriented analysis appeared at around the same time: as use cases in OOSE [17] as scenarios in OBA [23] and as task scripts in SOMA [13] although formalised scripts first appeared in Schank s work on conceptual dependency [24] 1.1. The size and representation of a use case A use case is defined as: a sequence of transactions performed by a system, which yields an observable result of value for ....

....of an everyday work task [18] Various authors have attempted to improve on this informality, for example: 9, 14, 15, 5, 6] 1.2. The type level semantics of a use case Whereas the scenarios of OBA were collected as instances of user interaction, each like a single execution of a process [12, 23], in Jacobson s approach [17, p127 8] a use case was considered a type level concept, more like a procedural definition. This is evident in statements such as: Each use case is a specific way of using the system and every execution of the use case may be viewed as an instance of the use case ....

K. Rubin and A. Goldberg, "Object behaviour analysis", Comm. ACM, 35(9), 1992.

....ab initio, not after the prior construction of object models. It is important to keep entity boundaries plastic while responsibilities are being elicited and redistributed prior object modelling tends to fix these boundaries too early. RDD is compatible with other behaviourcentred approaches [12, 25, 13] which use scripts scenarios use cases [16] to explore system page 5 requirements before assigning behaviours to objects. However, very few authors have picked up on the systematic layering offered by the second transformational phase of RDD, which we believe has been unfairly neglected. 2.1 ....

Rubin, K. and Goldberg, A. "Object-behaviour analysis", Comm. ACM, 35(9) 1992.

....world modeling. To give some background for the discussion made in following sections we will give a short description of existing methods in the three companies. TASKON AS have developed an OOD method named OORAM [22, 33, 45] This method can be characterized by being similar to RDD [44] and OBA [36] through its early focus on responsibilities and scenarios formalized as role models. SYSDECO AS have developed a method aimed at developing database applications. It is based on modeling of data and presentations, integrated by a 1 The NSR (Norsk System Rammeverk = Norwegian System ....

....what we previously had considered as design issues. Aspects that we had considered to be analysis such as requirement acquisition and model validation was neglected. Because it is difficult to define exactly what OOA is, we choose to define it in terms of the methods that we evaluated, i.e. [11, 42, 24, 36, 38, 39]. We admit that to use a general term such as OOA is not fair to any individual method, but avoiding such a generalization will lead to an incomprehensible amount of details, blurring the issue of this paper. An important source for general information about the state of the art in OOA, is survey ....

[Article contains additional citation context not shown here]

Kenneth S. Rubin and Adele Goldberg. Object Behaviour Analysis. Communications of the ACM, 35(9):48--62, September 1992.

....ab initio, not after the prior construction of object models. It is important to keep entity boundaries plastic while responsibilities are being elicited and redistributed prior object modelling tends to fix these boundaries too early. RDD is compatible with other behaviour centred approaches [11, 21, 12] which use scripts scenarios usecases [15] to explore system requirements before assigning behaviours to objects. However, very few authors have picked up on the systematic layering offered by the second transformational phase of RDD, which we believe has been unfairly neglected. 2.1 The Rules of ....

Rubin, K. and Goldberg, A. "Object-behaviour analysis", Comm. ACM, 35(9) 1992.

.... The OOSE models are not specified in a formal language although Regnell et al. have shown how this can be achieved for the use case model [20] Use cases have recently been introduced into Rumbaugh s OMT [22] In Object Behaviour Analysis (OBA) use scenarios play a similar role to use cases [21]. Glinz has shown how scenarios can be specified using Statecharts [8] Although he proposes that the specified scenarios can be integrated to provide a complete specification, he does not demonstrate how this can be done when scenarios interact with one another. He also states that future work ....

....the formal user centred model into ROOA 2.8.1 The ROOA Method The aim of the ROOA method is to construct a formal object oriented model of the observable behaviour of a system. It involves three tasks. In Tasks 1 and 2, it uses the techniques of informal object oriented analysis methods such as [6, 11, 21, 23] to build an object model and part of the dynamic model from a set of informal requirements. In Task 3, we build the formal system centred model (the ROOA model) The construction of a system centred model is shown in Chapter 3. The ROOA model is expressed in LOTOS and acts as a formal ....

[Article contains additional citation context not shown here]

Rubin, K.S., Goldberg, A.: Object Behaviour Analysis. Comm ACM, 35(9), 48-62, 1992.

....part of the iceberg . Scenarios can be used for a wide variety of purposes in the requirements engineering lifecycle 2 notably, to elicit requirements in hypothetical situations [2, 58] to help identify exceptional cases [59] to populate more abstract artifacts such as conceptual models [68, 67], business rules [66] or glossaries [72] to validate requirements in conjunction with prototyping [70] animation [18] or plan generation tools [1, 22] to reason about usability during system development [9] to generate acceptance test cases [32] to structure requirements through ....

....sequencing of the FloorRequest and DoorsClosing events in the Lift scenario given in Figure 8. 7. RELATED WORK The informal use of scenarios for requirements elicitation, validation and documentation is widely recognized among practitioners [69, 72] and is promoted by many methodologies [68, 67, 34, 58]. Proposals for representing scenarios have flourished [63] they generally consist in extensions or adaptations of existing notations for capturing dynamic behaviors of specific agents. For type level scenarios, these include, e.g. regular expressions [11] statecharts [25] decision trees [32] ....

[Article contains additional citation context not shown here]

K.S. Rubin and J. Goldberg, "Object Behaviour Analysis", Communications of the ACM, Vol. 35 No. 9, September 1992, 48-62.

....models (extended Entity Relationship Diagrams) of some kind. It is important to keep entity boundaries plastic while responsibilities are being elicited and redistributed prior object modelling tends to fix these boundaries too early. RDD is compatible with other behaviourcentred approaches [Gibs90, RuGo92, Grah95] which use scripts scenarios use cases [JCJO92] to explore system requirements before assigning behaviours to objects. However, very few authors have picked up on the systematic layering offered by the second transformational phase of RDD, which we believe has been unfairly neglected. 2.1 The ....

K Rubin and A Goldberg, "Object-behaviour analysis", Comm. ACM, 35(9) (1992).

No context found.

Goldberg, A.; Rubin, K.S.: Object Behaviour Analysis. In: Communications of the ACM. Vol. 35, No. 9, 1992, pp. 48-62

No context found.

K Rubin and A Goldberg (1992), "Object-behaviour analysis", Comm. ACM, 35(9).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC