You are on page 1of 12


Jean-Marc Nerson

Applying Analysis

Object-Oriented and Design

:ional analysis and design techniques imply constant paradigm shifts, since manipulate different concepts at each different phase of software developt. The object-oriented technique offers a seamless process that helps viewing the software architecture in terms of problem space elements. • • • • • • • • •
This article presents an analysis and design technique relying on a set of notations and guidelines. It promotes a descriptive method that addresses both analysis and design issues. Key criteria have guided the definition of the technique: scalability, reverse engineering support, documentation aid, structuring mechanisms, systematic design support and component management support. A case study shows how the technique works and fosters the production of reusable components. time to waste on reinvention or inefficient implementation of wellknown algorithms and user interface techniques. In the long run, object-oriented software is aimed at helping to simplify the way we view the real world as it is (or as it should be) and translate our view into software systems. Object-oriented techniques exist to help manage the complexity according to some key points: * Object-oriented architectures are decentralized; • Classification is part of the system structure; • The same ideas and concepts are manipulated from the requirements phase down to the implementation phase. T h e object life cycle shown in Figure 1 and inspired by [9, 16, 18], conveniently reflects a development scheme in which a knowledge base represented by libraries of reusable and pluggable components impact the different production phases. The class reuse and generalization process is an iterative process influencing both analysis (reuse of frameworks [6]) and design (reuse of classifications [ 10]). Compared to traditional techniques, object-oriented development is a seamless process: there is no paradigm shift between the different stages o f the life cycle. Uniform principles apply throughout the development process. If types of objects identified during system analysis are specified by a name and a precise set of properties, they will translate into syntactical units (usually called "classes") in the final program. This observation is both good news and bad news. The good news is that once the intellectual process of objectoriented development is properly understood and mastered, it can be successfully used (with some variations imposed by the levels of abstraction) to the different development stages. Tracing requirements becomes easier since manipulation of entities is more natural and smooth. T h e bad news is that whenever inappropriate types of objects are selected, or whenever awkward structuring choices are made, the final architecture reflects these poor decisions. Because of the continuous development process involved, objectoriented techniques tend to blur the borderline between analysis and design. In the next sections, we will study how an object-oriented analysis and design method and technique is applied. The technique used is based on a method and notation called BON (Better Object Notation [14, 15]). Although the BON notation is both graphical and textual, we shall use the graphical form. In the remaining text, all BONspecific terms will appear in bolditalic type when first introduced.

The Object-Oriented Development Process
Industrial-quality software production of today has become extremely demanding. Applications tend to be much larger and more complex and thus more difficult to develop. Their functionality is shifting from processing to system simulation and integration; from centralized to distributed computing; from textbased to graphics and multimediabased systems [23]. Highly volatile requirements and strong competition call for even shorter development times. This conflict causes many software products to become delayed, or worse, released without adequate production quality. The importance of application portability among a large number of rapidly changing hardware platforms and the need to be easy to learn and understand by end users with different backgrounds, make things even more difficult. Therefore, there is no longer any

Object-Oriented Analysis with an Example
The software to be developed is intended to automate the reservation and invoicing system of a car rental


1992/Vol.35, No.9


Some guidelines exist. smoker or nonsmoker car. trailer. For instance. It# ] ~CONSTRUCTION ~ ( CLASSESNETWORK ) ~ I 1 ~ DESIGN + ~ I L COMPONENTS| REUSABLE / / J o= (3 services they provide. Classes are defined with the information they maintain. individual or corporate customer Looking for objects and classes is the very first step of object-oriented analysis. • Different models of car are grouped into a small number of price classes. whenever nonpubJic information is introduced in a system. the IVUSERREQUIREMENTS INFORMAL 1 REQUIREMENTS "~ ANALYSIS I DESCRIPTIVE ' MODEL " I ~ ~ "-. • Different rental plans are available. • Nonfitted extras are: roof rack. the result being a starting point for the final class programming in some object-oriented language. they are iterative in practice. This activity helps to find the major relationships between the different types of objects considered as class instances. • The price charged is established in l=igufe 1. Although activities are often listed in sequential order. • Vehicles are taken from one location and returned to the same location. and Clustering Classes ABSTRACTION/GENERALIZATION 1 ~ b l e 1. Cluster chart of t h e car rental system CLUSTER CHART: CAR RENTAL CLASS CLIENT CONTRACT DEFINITION Car renter. Analysis classes must satisfy some functional requirements and usually reflect a certain system viewpoint. T h e notation is backed with a set of guidelines that specify activities and deliverables.35. A short outline of the major requirements is given below. Analysis involves some key activities that represent things to be performed by the analyst to get a better understanding of what needs to be done. T h e subtle effort is to decouple "nouns" potentially representing services from those mapping to effective candidate classes. • Free options are: automatic or manual transmission. child seats. Very roughly one could say that analysis becomes design whenever implementation decisions are taken. • The system must handle block booking of cars and keep track of car availability. the constraints they comply with and how they relate to other classes. BON provides a notation and a set of guidelines and recommendations applicable to the preanalysis and analysis phase down to detailed design. snow chains. No miracle formula exists in that respect besides experience and recall of good practices. Both imagination and abstraction guide the analyst. At the analysis level all identified class information is considered public. We retain basic and simple ideas as principles: the aim of analysis is Rentalterms with payment conditions Rental information completed out and returning a vehicle when RENTAL taking VEHICLE MODEL AutOmObileselectedfrom the rental fleet Description of selected features Pricing conditions RATE 64 September 1992/Vol. two or four doors. there is sometimes no clear distinction between what really belongs to analysis and what really belongs to design. but better serve as checklists to things not to miss. These extras are charged to the client. It resembles the activity of describing a picture viewing the problem space for which the system borderline is the frame. Finding. The object-oriented software life cycle Object-oriented analysis tries to identify the type of objects that map into elements of the application domain to be modeled. or whenever newly introduced classes do not relate to problem space objects.9/COMMUNICATIONSOF T H E A C M . No. Naming. In that respect. with a special weekend rate to attract nonbusiness customers.

the level o f confidence (novice. Since object-oriented architectures are flexible. An information system behaves as a set o f black boxes o f which the intrinsics are hidden and the only visible part is the list o f services and states provided to the user. simply a convenient way to express how the system changes according to internal events. It is very c o m m o n to start with only one general cluster and then come up with new ones after doing some class grouping. the object a p p r o a c h enforces the use o f data abstraction that encapsulates services. No. but with a different rationale. Although it may be tempting to view the system as a collection o f functions. to represent the entire logic using this model. It is also i m p o r t a n t to locate the place o f a class within the overall structure. In any case they should not be confused with classes. T h e term "organization" here must he u n d e r s t o o d not only as the m a p p i n g o f the work breakdown structure onto a responsibility assignment chart but also as a way information must be detailed or not. one should look for the underlying classes that represent the g r o u p i n g o f these operations. to master the complexity by reformulating the problem. For other specific systems. Large systems are expected to be used in completely different contexts. the level o f expertise or knowledge o f the application domain. During analysis they help g r o u p i n g classes according to proximity criteria based on a subsystem functionality. On the contrary. etc. Users are not equally qualified to access specific pieces o f information. employer. the place of execution may configure the system according to external constraints: severe or protected environment. they can model different problem space descriptions directly as part o f the system description. ability to tune the time/space tradeoff.articles to put some o r d e r to o u r perception o f the real world. A simplified cluster chart for the car rental system is given in Table 1.35. postpone implementation decisions. T h e r e f o r e . an abstraction level or an enduser standpoint. T h e r e are various reasons for this: the level of responsibility in an organization. say AUTOMOBILE. Actors in an organization will access the same information. F r o m the analysis o f the car rental system. T h e cluster chart lists classes participating in the identified clusters and gives a short definition for each o f them. however. quite different classes d e p e n d i n g on application domains. find inconsistencies. partition the problem space. These charts are used as a communication tool between end users and analysts and were inspired by the CRC technique [1]. an initial set of classes comes to mind and participates in the definition o f a first cluster. administrator). Then. advanced user). T h e result is not to p r o d u c e something that complicates the problem to solve or the reality to map. Clusters play various roles. or specialization relationships. Occupational names give some ideas about possible classes for users: engineer. Information systems reflect the way organizations work. as state machines. Design will decide whether classes are linked by derivation. customer. It is generally too complicated. Looking at the information system modeling techniques. For a company using a system operating t h r o u g h a communication network branches. classes are g r o u p e d into clusters. ability to limit or extend the accuracy of a computation d e p e n d i n g on the context. the place o f operation impacts the behavior. A class has an internal state and offers services. generalization. During design they are often used as a structuring technique to selectively visualize the coupling between classes. In the early stages o f analysis. This means that finding related classes is m o r e important tha n finding a single class. in this case. BON uses various charts for describing the different types o f objects. access rights (user. even if services come to mind first. Table 2 illustrates how clustering may g r o u p together with a class.9 6S . is not an implementation technique. A military system will not display ground information in the same fashion for the a r m y general as for the frontline soldier. subsidiaries." which is far too close to procedural techniques. but it will be presented differently. Events and Object Communication Protocols Two different kinds o f events that act on system behavior must be sorted out: external events and in- COMMUNICATIONS OF THE ACM/September1992/%1. but in principle it is simpler to designate a certain viewpoint as the main focus o f interest. In the case o f communication systems. the p u r p o s e is to simplify. A first principle is to consider classes as representations o f abstract data types as o p p o s e d to "things they do. affiliates. We will then continue o u r system analysis based on two types of representation: a dynamic model. information is presented differently according to implied actors. A state-transition diagram. at the r e q u i r e m e n t levels. Analysis must remove noise and overspecification. and other manufacturing plants may be similarly described regardless o f the geographical location. In the case of an e m b e d d e d system. d e p e n d i n g on the actors' levels o f responsibility. showing parts of its behavior and a static model describing its structure. A system usually interacts with different users. Such diagrams are also a variation o f the state-transition diagram and can lead to the production of system classes. Object orientation simply adds structuring mechanisms for defining relationships between system elements and decentralizing local decisions. association. T h e g r o u p i n g factor may vary. diagrams are prod u c e d to stress the information flows. take a certain viewpoint and d o c u m e n t it. Many systems can be defined.

lish text.. class entry in the initial cluster ported: the class level and the clusExternal events may become classes chart. Traffic-light controller 66 September 1992/Vol. SEDAN. Car inspection done on leave and on return. o f object that should c o r r e s p o n d to classes are r e p r e s e n t e d in a quite Table 3 gives an example o f a class entry in the cluster chart. T a b l e 3. filled with free-format Engmay capture additional semantic This technique relates to princi. it to behave like other types of object. It different m a n n e r c o m p a r e d with events applicable to the car rental system and can be c o m p a r e d with a T a b l e 2.p r o d u c e d first really d e p e n d s on Analysis proceeds using a m o r e ior. other classes ask the class to proclass features that will lead to mesRelationships between clusters vide? sages defining the object communiare mostly structural. In practice. Light turns green. A road is closed to traffic. they also translate cording to g r o u p i n g factors or abinto assertions that control the T h e chart is structured in three col. class the constraints that the classes must which the system has no control on charts are then filled out. o p p o s e d to the static model that tance classification later in the proT h e y refer to stimuli received from only reflects the structure. T h e y refer to parts o f system any class definition introduces a • T h e commands: what services can behavior that simply translate into type definition. T h e y are things Out t h e Kernel A r c h i t e c t u r e and their relationships. its elements pected" events. Two levels o f detail are supwhether or when they may occur. reacts according to a certain behav. DOMESTIC_CAR model consists of scenarios d e m o n strating significant object commuCar rental company TRUCK. TRAILER. information that translate into class ples applied in "Object Behavior T h e class chart describes a type annotations. External events help to find the nature of the application and formal way to r e p r e s e n t the system classes that interface the system the analyst's level o f confidence. STATION_WAGON the static system structure.~ that jects are reachable from others. 9 / C O M M U N I C A T I O N S OF T H E AC:M . COUPE.Defining Classes and Sketching by its decomposition. T h e dynamic Repair station FOREIGN_CAR. It highTraffic-light controller lights objects relevant to selected PEDESTRIAN. Examples o f class charts are the outside u p o n which the system Deciding which model should be given in Figure 2. umns.twofold: it helps to validate the is also possible to state that the deExternal events are actions initi. Tank refilled on return. T h e p u r p o s e is LUXURY_CAR ternal events. class features. VEHICLE system behaviors. structure and behavior. Since they act on scaling up or down the system acmust the class maintain? the system state. INTERNAL EVENT Rental contract printed when car returned.straction levels. nication protocols. Relationships between Analysis" [ 19]. BIKE. a class chart is defined acter level that defines relationships or input p a r a m e t e r data passed to cording to three basic types o f inbetween logically g r o u p e d classes. A vehicle is leaving the intersection. p r o d u c e an incoming data flour that maps the system behavior better as This may help refining the inhericrosses the b o u n d a r y o f the system.35. Class relationships p r o p e r behavior o f the system. ']'hey model shows the system structure should not be considered as "unex. A rented car breaks down. Red light starts flashing. nonrelated system (a traffic light Class AUTOMOBILE w i t h r e l a t e d cluster classes controller). N o . COMPACT_CAR. T h e static with the outside world. A vehicle is arriving at the intersection. this means that can other classes ask from the class? lute. cess. T h e y help • T h e constraints: what knowledge cation protocols. Mileage checked on return. A new car joins the fleet A car is returned. E v e n t charts APPLICATION DOMAIN Car rental company EXTERNAL EVENT Customer makes a car reservation. formation: T h e model introduces typed inforInternal events are time-related mation very early in the analysis • T h e questions: what information stimuli that may be relative or absoprocess. along with that can possibly h a p p e n but over F r o m the initial list o f classes. For each fulfill.static model and to make sure obscribed type o f object is suspected ated by the external interactor. APPLICATION DOMAIN CLASSES RELATEDTO AUTOMOBILE Events help to introduce the dynamic model that complements AutOmobile manufacturer LIMO.

O b j e c t . Rental documents. This activity starts from the analysis classes and produces additional types of objects that become classes not directly related to the problem space. Refill gas tank. Client has already reserved or rented a car. Primitives introduced during design are not necessarily public and may relate to implementation decisions such as to determine which Table s. Class charts o f the car rental system COMMUNICATIONS OFTHEACM/Scptember 1992/Vol.. Name. These classes extend. Corporate customer. Applicable rate.. or implement the initial set of analysis classes. Special rate. The class structuring mechanism is based on two basic relationships: the inheritance relationship and the client-supplier relationship. Give special rate. Classes always belong to a cluster usually displayed in abstracted form. as explained in [13]. No.9 67 .. Departing location. Departing date <= returning date. Change oil.. is-contained-ln(l:m) consists-of(re:m) is-a(l:ll Object-oriented design transforms the analysis classes into a computerized model that belongs to the solution space. Checkmileage. Departing and returning locations are the same. Starting and ending mileage. License_plate. Starting mileage <= ending_mileage..35. F i g u r e | .articles techniques such as the entity-relationship model. Selected automobile. Enter in date b a s e . The client-supplier relationship usually encompasses two things: the association relationship and the aggregation relationship. generalize. Departing and returning dates. T a b l e 4. Address. individual or corporate customer Questions CUENT Cluster name: CONTRACT ELEMENTS Behaves like: PURCHASE ORDER Constraints PERSON Constraints . VEHICLE Cluster name: RENTALPROPERTIES TYPE OF OBJECT: Automobile selected from the rental fleet Behaves like: RENTAL Cluster name: CONTRACTELEMENTS TYPE OF OBJECT: Rental Information completed when taking out and returning vehicle QuesUone Commands Behaves like: RENTED_ITEM Constraints I Questions Commands Constraints [ Model of c a r . Extra choices. Tables 4 and 5 make a parallel between the entityto-entity relationships in the relational model and the class-to-class structuring mechanisms of the object model.O r i e n t e d Design w i t h an Example Semantics of entity relationships In the relational model TYPE OF RELATIONSHIP (multipliCity) has_a(1:1) owns. Invoice clienL Acknowledge a reservation.. Semantics of Inheritance and client-supplier relationships In the object-oriented model CLASSTYPE OF RELATIONSHIP CLASS inheritance relationships descendant is-a parent descendant behaves-like parent descendant implements parent descendant combines parents parent defers-to descendant parent factors-out descendants Client/Supplier relationships client uses suppliers client needs suppliers client has-a supplier client consists-of suppliers supplier provides-to clients CONTRACT Cluster name: CAR RENTALSYSTEM TYPE OF OBJECT: Rental terms with payment conditions Questions Behaves like: TYPE OF OBJECT: Car renter. Figure 3 illustrates static and dynamic model notations used in BON. that is only with their header. Returning location. Corporate customers do not get weeX-end rate discounts. I COmmands Commands Means of paymenL Individual or corporate customer. Availability. Selected insurance policy. contains. List of authorized drivers.

T h e translation scheme is straightforward: • Questions are m a p p e d into attributes (state variables) or functions in the Eiffel sense.s I TRANSPORTATION Static model (left side): • Clusters are represented with rounded corner rectangles drawn with dashed lines and are tagged with a name. • Communication protocols are represented with dash lines. Describing. if any. and the class invariant. • Behavior resemblance translates into inheritance (see [11]). Relationships are defined between classes and can be extended to clusters Dynamic model (right side): • Objects are represented inside rectangles. class charts are translated into class descriptions. Indexing and Instantiating Classes ible features. The double line may be tagged with class feature names involved in the client-supplier relationship.and posteonditions) are also listed. the RENTAL class should make sure that whenever a vehicle is r e t u r n e d . Class descriptions first focus on vis- cedures. if any. which means that any consistency checking at that level can only be done by an automated tool. In addition to this. etc. This obvious statem e n t avoids possible misuse o f the system. T h e class body is d e c o m p o s e d into different parts. lead to persistent objects. T h e most commonly described parts are: the reference to a direct parent. one should recall that internal events may become class features. with optional annotations: deferred classes are topped with a star sign. A shadowed rectangle denotes multiple instances. Graphical notations used in BON static and dynamic models Figure 4 is the translation to class descriptions o f the class charts defined d u r i n g the analysis stage. • C o m m a n d s are m a p p e d into pro- During design with BON. • Constraints are m a p p e d into assertions and class invariants.35. • Classes are represented as a name inside an ellipse. pre. Routine signatures (input or output parameters. Classes are now fully described: with their h e a d e r and their body. These class descriptions rephrase the same information in a m o r e structured and formal manner that will help the generation o f prefilled class templates in an app r o p r i a t e object-oriented language. T h e description details class features and contracting conditions. the list of typed features with their assertions and comments. 9 / C O M M U N i C A T I O N $ OF THE ACM . • Inheritance relationships are represented with a single line ending by an arrowhead oriented from the descendant to the parent Client-supplier relationships are represented with a double line ending by an arrowhead in case of association and with an open curly bracket in case of aggregation. be in charge o f e r r o r recovery. labeled with numbers. it has previously been taken out. F i g u r e 3. For instance. reused classes have an underlined name. T h e explanation of some symbols is also given in an associated table.classes will interface to the outside o f the system. Class chart column entries become comments associated to class features. deal with machine or system d e p e n d e n t information. non-deferred descendant classes are topped with a plus sign. T h e r e is always a strange situation which is a potential source o f error: drivers of the same company that have each r e n t e d a car #* / pilot owner I I I I I ! 2'-5-~D"I DRIVER A car is purchased by someone The driver enters the car The car's engine starts and runs The car's engine stops The driver leaves the car i I 2 3 4 5 % . N o . These numbers are then referred to in commented scenarios 68 Septernbcr 1992/Vo1.

Classes are application-dependent. the invariant translates a m a n a g e m e n t rule stated in the initial set o f requirements: corporate customers do not have access to special week- end fees. a first draft o f the architecture is then defined and appears in Figure 5.~ make_ reservation client ~ .-] J COMMUNICATIONS OF THE ACM/September 1992/Vol. In the CONTRACT class. In that case.-~ Symbols used Input argument Output argument Routine precondition Routine postconditlon Class Invarlanl Void reference . T h e only way to solve the problem o f finding suitable classes for reuse is to a d d class indexing F i g u r e 4.~ --I I---. returning_to LOCATION VEHICLE authorized_ drivers SET [DRIVER] Insurance_policy INSURANCE discount J -.. A dynamic scenario is given in Figure 6. High-level classes can easily be customized or particularized using inheritance. T h e design technique emphasizes the system flexibility with respect to its possible extensions or adaptations.35. returning_date DATE I I E-" SET [OPTION] [ availability date I J means_ of payment MEANS OF PAYMENT client . Class descriptions of the car rental system ~ l l c e n s e _ plate KEY type MODEL status vehicle -. From the description o f the classes.R e n l a l contracts SET [RENTAL] invoice -.articles and then switched them without notifying the rental company. returning_mileage VALUE taking_out_date.Rate used to compute the tee RATE extra_ Items SET [EXTRA] starting_mileage..D o the invoicing means_of_payment #=.S e l e c t e d a u t o m o b i l e AVAILABILITY departing_from. the class invariant serves as a system consistency checker..9 69 . Individual or corporate custome CLIENT documents . No.

T h e purpose of this chart is to determine which class is responsible for the creation of the instances of other classes. ."~s. The static architecture only defines class relationships.-- I ! I ! I I ' @ @ • I I i I # RENTAL_PROPERTIES -'~' . to project management information. . (documents) returning_date t I departing_date 1" ". To implement automated tools managing indexing techniques. it is necessary to prepare the future reuse by enforcing design guidelines by which any completed class F i g u r e 5. Partial static model of the car rental system should be documented according to a prefilled header template. the dynamic model only emphasizes selected communication protocols between objects. client.' ... ~ . name . Therefore. . @..: ::~i¢les and documenting information to retrieve them easily from libraries or databases of components according to given selection criteria.~-z_-~ ~ ~Z~' I.SUPPORT s @. Once analysis and design classes are all identified. VEHICLE_PROPERTIES .. a way to map one model to the other is to produce during the design phase an object creation chart. <-. NS_OF PA I @ .we.. No. etc.. TYPE % 70 September 1992/%1. . An example of such an indexing clause is given in Figure 7.35. to requirement documents.peR.. - "" -.9/COMMUNICATIONS OF T H E A C M . we need to know how their instances are created under certain circumstances.-> UAL_G % % I I i l ~. Class header templates include references to the covered application domains. ~" %. At this level of description. one should concentrate only on classes found during the f % I / CAR_RENTALSYSTEM I /d %~ of_payment. "~ . OPTION.1 (options) '~ OPTIONS ".

. T h e r e are some "holes". • T h e access method. a classification is d e f i n e d so as to make class A U T H O R a d e s c e n d a n t o f class PERSON. models reality. i :4 A contract is prepared for a client: 1 V Requested rented cars are grouped by client: 2. automobile p r o d u c e a n y k i n d o f data structure simply by picking a n d assembling classes from these three basic classifications. R e f e r r i n g to [10]. it becomes m u c h easier to 11nble 6. resizable. which is a n e w p a r e n t o f AUTHOR (this will n o t c h a n g e the interface o f AUTHOR) a n d to e x t e n d the classification d o w n f r o m the W R I T E R class so as to i n t r o d u c e a class ACRONYM. 6 p. which concerns the d e s i g n o f a library o f reusable c o m p o n e n t s . . probably a d e f e r r e d one. . 1992 revision: 2.3. a classification d i m e n s i o n that captures the structural relation b e t w e e n the data structure elements. Back to object-oriented software. W h a t to do t h e n without d a m a g i n g the existing architecture? T h e only possible solution is to define a new class. Abstracting and Classifying W h a t really makes object-oriented software so attractive is that its structure "is" its own classification a n d that this classification is achieved so as to be g e n e r a l e n o u g h to a c c o m m o d a t e a n y possible extension or modification without i m p a c t i n g o r complicating the existing architecture. a classification d i m e n s i o n that captures the ways elements are accessed. car lease author: J. n o t because m i n eral e l e m e n t s are yet to be f o u n d . vehicle.3. J • O b j e c t . some time later. transportation mean application domains: car rental. As a conclusion we can state: • A classification.4. Yet a classification is n e v e r perfect. A n o n s o f t w a r e . a new book is a d d e d to the library stock that is n o t written by a p e r s o n b u t by a g r o u p o f u n k n o w n a u t h o r s u s i n g a pseud o n y m . U n f o r t u n a t e l y . T h u s .o r i e n t e d facilities p e r m i t modification o f the m o d e l without GOMMUNICATIONS OF T H E ACM/September 1992/Vol.arl~|¢les very first stages. Table 6 shows a n e x a m p l e o f the object creation table c o r r e s p o n d i n g to the car rental e x a m p l e reviewed earlier. srs. W R I T E R for instance.35. . p r o p e r l y laid out by the analyst according to the u n d e r s t a n d i n g o f the p r o b l e m space. car. .7 keywords: rental.No. agency. assume that a library m a n a g e m e n t software is d e s i g n e d a r o u n d the a s s u m p t i o n that book authors are h u m a n beings.A UTHOR.9 71 . Object c r e a t i o n t a b l e l~/pe of object CONTRACT RENTAL VEHICLE Creates RENTAL. To c a p t u r e this idea.r e l a t e d e x a m p l e is the periodical classification o f chemical elements by Mendelei'v: it fits reality very well. . Indexing clause of the class VEHICLE I I 12 " " - RENTA. It is i n t e n d e d to reflect as closely as possible a reality which has no simple order.3. RATE VEHICLE MODEL F i g u r e G. Nerson date: May 1. b u t because in some cases the classification scheme is better repres e n t e d in 3D whereas it was initially d e s i g n e d in 2D. 3 ] VEHICLE I A rentalplan Is established for a specific vehicle: 4 I A vehicle modelis chosen: 5 ~5 Selected mode/is a two-door manual gear car:. M.1 spec-refs: srs. . b u t n o t exactly. 1. fixed. it is i n t e r e s t i n g to note that any o f a wide r a n g e o f data structures could always be linked to o n e o f the following classification criteria: • T h e storage. a classification dim e n s i o n that captures w h e t h e r the data structure is b o u n d e d .'8 I ] 1 I f synonyms: car. Example of a dynamic scenario F i g u r e 7. • T h e traversing.

• Later. T h e answer usually varies according to the d o m a i n o f activity of the d e v e l o p m e n t team. may simply be kept u n d e r a new name in class PRODUCT. two options are possible: • Do nothing and the benefit gained from applying objectoriented techniques is limited to the structuring o f the application. • R e v e r s e e n g i n e e r i n g : since any kind o f information is stored in a coherent internal data structure. it is possible to reuse existing systems and translate them back into a schematic form. CONSUMER. many c o m m o n features exist. Looking at o u r system architecture. 24]. . but other elements must change: there is little chance that the price o f a pair o f skis can be linked to a n u m b e r o f miles ._ELEMENTS cluster can possibly be kept after some m i n o r modifications. This enables the analyst to visualize existing class libraries not developed with a modeling technique. Before the implementation of the car rental system is completed. Referring to o u r initial car rental system. 5. This will not h a p p e n though. In the case of a large software house. diving material. new classes have to be i n t r o d u c e d as ancestor classes. No. for example. Classes such as VEHICLE. BON and Tools T h e methodology and notation presented result from an ESPRIT Project ("Business Class" [8]) in which an object-oriented analysis and design technique was develo p e d after e x p e r i m e n t i n g on pilot projects different existing methodologies [2. Looking at o u r c u r r e n t system architecture. itself translatable into a set o f p r o g r a m m i n g language classes. • Since the initial set o f classes appears too problem-specific. the VEHICLE class changes as detailed in Figure 8.9/COMMUNICATIONS OF THE A C M . RATE. For instance. a generalization process must begin. A repository o f classes. 17. T h e y are heir classes o f the existing classes. properties. Consequently. DRIVER. Classes inside the RENTAL_PROPERTIES cluster are much too problem-specific. it may be a p p r o p r i a t e to do some extra work to generalize the initial architecture. one may ask how to pave the way for coping with other systems similar to o u r initial p r o b l e m such as: • A boat rental system (motor boat and sail boat). T h e i m p r o v e m e n t process often results in the following scenario: • A first version o f the system is written. It is worth noting that some features now introduced in class PRODUCT. • Scalability: the formalism for r e p r e s e n t i n g groups o f classes scales u p and supports p r o b l e m partitioning based on layers o f abstraction using class clustering techniques. To be generalized. which is why their ism helps the analyst in sketching a first set o f classes a n d relationships that can directly be translated into a system design. Generalization of the Example At the completion o f the objectoriented analysis and design. This inspired the BON objectoriented analysis and design model a n d notation designed so as to supp o r t the following capabilities: • A n a l y s i s a n d d e s i g n : the formal- UCT. • Documentation: any element that appears in the schematic diag r a m or in the textual form should be traceable. Some class invariants initially int r o d u c e d in the VEHICLE class are now moved u p into the PRODUCT class. 4] with a strong database orientation a n d some similarities to O O S A [21]. Features listed in the VEHICLE class now simply address car rental system specifics. a plus symbol sign (+) is app e n d e d to the feature name. the PRODUCT class is initially defined by abstracting features originally i n t r o d u c e d in the VEHICLE class. Specific attention was also devoted to possible enhancements o f a modeling technique n a m e d O* [3. • Do some extra work involving the search for m o r e general structures. These high-level classes serve as p a r e n t classes o f the classes belonging to the initial system and to the classes newly introduced. we may wonder if it is sufficiently general to maximize future reuse. 20. classes inside the CONTRACT. These classes introduce features that will be i m p l e m e n t e d or reimp l e m e n t e d in o u r previously defined classes. PRICE. High-level class abstractions usually do not come first to mind. . 7. T h e car rental system classes listed inside the RENTAL cluster can now be rewritten according to the generalization process. These new classes keep the same interface as the ones they are p a r e n t of. o r for which the accompanying analysis and design documentation does not come with the off-the-shelf product. relationships and dependencies is maintained and can I~ September 1992/Vol. 22. specialized versions of" existing classes are w r i t t e n . with feature type that is only relevant to the class VEHICLE as outlined d u r i n g o u r initial analysis. . some c o m m o n features are factored out into very high-level classes. etc). Even applications such as a hotel reservation system or a box office ticketing system have similarities with o u r initial system.breaking the core architecture when extensions or special cases show up.35. INSURANCE may now be d e f i n e d as descendant classes o f m o r e general and abstract classes that could respectively be: PROD- names are also a p p e n d e d with a plus sign. such as serial_number or stocking place. From this observation. before class coding has even started. Since feature license_plate is a d a p t e d from feature serial_number i n t r o d u c e d in p a r e n t class PRODUCT. e x t e n d i n g or r e i m p l e m e n t i n g parent features. • A sport e q u i p m e n t loan system (snow skis. WARRANTY.

• Component management: software elements such as classes. It permits the definition and visualization o f well-decentralized software architectures promoted by objectoriented techniques. The first EiffelCase component is a drawing tool that supports the notation and generates class templates from an internal form o f clusters and system dependencies. T h e dynamic graph illustrates communication scenarios between objects. OBJECT CREATION CHART DEFINE CLASS FEATURES. The layout of the graphical classes and clusters remains under the user's control. A summary of the different methodological steps to follow is given in Table 7. Each class is known by its version and other key information can potentially be interfaced with adapted querying tools. returning_to LOCATION status + AVAILABILITY type MODEL I departing_from = returning_to I J T a b l e 1.and postconditions of class invariants. thanks to the indexing clauses. The graphical view offers a drawing-tool interface. with a palette of graphical elements to be selected and placed on the screen. Modified scription VEHICLE class de- f-serial_number KEY stocking_place LOCATION status* ACCESSIBILITY Heir of: PRODUCT "~ license_plate + KEY departing_from + . OBJECT COMMUNICATION PROTOCOLS. For these three views a consistent internal structure is maintained. The class chart view offers forms to fill out. relationships are kept under configuration management control. features. consists of two different components. This workbench. ! also thank very much II=lguTe 8 . Assertions such as pre. In the scope of "Business Class" a workbench supporting BON is being implemented: EiffelCase. The supporting repository is layered on top of the PCTE (Portable C o m m o n Tool Environment) Object Management System emerging as a CASE tools integration standard. At any time. classes. It is a large-scale browser that queries and updates a database of class information according to various criteria. • Systematic design: the model fosters the application of the contract model between classes.35. • The class descriptions. Any object-oriented analysis and design technique must be backed with supporting CASE tools. Summary of B0N methodological steps • ° • • • • • • • DELINEATE THE SYSTEM BORDERLINE LIST CANDIDATE CLASSES OBSERVED IN THE PROBLEM DOMAIN GROUP CLASSES INTO CLUSTERS DEFINE CANDIDATE CLASSES IN TERMS OF QUESTIONS/COMMANDS/ CONSTRAINTS DEFINE BEHAVIORS: EVENTS. clusters. designed with BON and programmed in Eiffel [11]. Any change made to one of the views is automatically propagated into the other two as soon as some "commit" operation is triggered. No. can be expressed with a formalism relying on symbols commonly used in set theory and then directly implemented in Eiffel. three different views can be displayed and manipulated: • The class charts.9 73 . INVARIANTS AND CONTRACTING CONDITIONS REFINE CLASS DESCRIPTIONS WORK ON GENERALIZATION COMPLETE AND REVIEW ARCHITECTURE COMMUNICATIONS OF THE ACM/September 1992/Vol.articles be queried to produce browser-like information or cross-reference forms. The second EiffelCase component is aimed at helping the analyst to find and manage collections of • Structuring mechanism: the model offers two graphical representations: a static diagram and a dynamic graph. T h e static diagram represents classes and clusters of classes all linked through different kinds of relationships. Acknowledgments I am very grateful t o Bertrand Meyer for his constant support and for suggesting bright and productive ideas. • The clusters.

M. Meyer. Meyer..2. 18. 9 (Sept. Commun.J.JUDE CH/LDREN'S ~ RESEARCHH O S P / T A L II~mn r~Nr~*i. July-August 1991). Commission of the European Economic Community.L.6..No. W.6. ~ ST. Nierstraz. Modeling object oriented systems: the uniform object notation. S. J. ACM 35. (Santa Barbara.0 [Computing Methodologies]: Simulation and Modeling-general. 1. Coad. K. In Proceedings TOOLS 5. Wilkerson. I.J.J. O.. 4. (Santa Barbara.10 [Software]: Software Engineering-design. pp. or to republish. Englewood Cliffs. Inc.J. ACM 35. 1992). 1990). and notice is given that copying is by permission of the Association for Computing Machinery. R. 104 rue Castagnary.3 [Computing Methodologies]: Simulation and Modeling-applications... Edwards. 1991. 12. Rumbaugh. C. 1991. The Benjamin/ Cummings Publishing Company. W.. Modeling the World in Data. S.. Prentice Hall. Englewood Cliffs. Prentice-Hall. Wirfs-Brock. Object Oriented Series. Shlaer. A. Englewood Cliffs. 3. Winblad. Extending Eiffel toward O-O analysis and design. J. N..J. N.1 [Software]: Software Engineering Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage.. 9 (Sept. pp. Muller. K. 17. N. Tsichritzis.. 75015 Paris.. flexible software architecture. object-oriented notation and methodology. N.I.. Prentice-Hall. B. [] References 1. Booch. D. 11. 69-88. Mandrioli and B. Commun. and Weiner. Prentice Hall. 6. Rubin. Commun. 9/COMMUNICATIONS OF THEACM . 1-50. 377392. Addison-Wesley Publishing Company. Current research interests include the analysis and design of reliable systems. and Lorensen. pp. 14. Pircher. 7. France.4 [Computing Milieux]: Management of Computing and Information Systems--system management General Terms: Design.J. B. Englewood Cliffs. 465-483. Englewood Cliffs. Experimentation Additional Key Words and Phrases: Analysis. Object-Oriented Series. June 1990. In puting Series. pp. Rose. static class model and dynamic object model About the Author: JEAN-MARC NERSON is managing director of the Soci4t~ des Outils du Logiciel (Paris). 1991. Smith. King. 1990.requirements / specifications. Prentice-Hall. Nov. A. Constantine. requires a fee and/or specific permission. 1990. N. D. 1991. Wasserman. 5.. JulyAugust 1991). 1989. Englewood Cliffs. Project #5311.R. University of Paris I. 1991. and Mellnr. object-oriented software engineering. 1992). B. Paris. G.. Englewood Cliffs. Call (800)877-5833for information Object Oriented Modeling and Design. OOPSLA'89.Kim W a l d e n a n d all the reviewers for their extremely helpful comments. Englewood Cliffs.989.. M.6. Bruxelles.J. Modeling the world with semantic objects. W. ACM 35.. A design methodology for object oriented database. Author's Present Address: Soci~t6 des Outils du Logiciel. Concepts of objectoriented structured design. Cauvet. Object-oriented patterns. 9 (Sept. Coad.A. A.2. E. Beck. Prentice Hall. Designing Object-Oriented Software. Puhr. Commun. 1988. 10. Goldberg. S. P. Object Oriented Systems Analysis. International Conference on Management of Data. Commun. Internal Report. 1992. S. 1.D.J. 1991. 1991. 1991. Gibbs. D.. 1992). P. Blaha. Monarchi. Object Oriented Series. Englewood Cliffs. Paris. 15. Potter. 9 (Sept. King.J. Comput.. Meyer.. 269-280. reliable component reusability. A research typology for object-oriented analysis and design. and Weiss. G. Nerson. Meyer. 24. A laboratory for teaching object-oriented thinking.. 20. India. Advances in Object-Oriented Software Engineering. C. TOOLS 4 Tutorial Notes.. In Proceedings TOOLS '89 Conference. R. D.. P. Duke. 1992). Component-Oriented software development. 22. 1989. Eddy. K. (Oct. 1-6.3 [Computing Milieux]: Management of Computing and Information Systems--software management. Englewood Cliffs. ©ACM0002-0782/92/0900-063 $1. design. Henderson-Sellers. Object Oriented Design with Applications. C. ACM 33. email: marc@ eiffel. 1. Design by contract. 23. S. N. 1990. the ACM copyright notice and the title of the publication and its date appear. J. P. Software development with Eiffel. L. 2..6. L. B. Sept.J. Tools for the new culture: Lessons from the design of the Eiffel libraries. CR Categories and Subject Descriptors: D. F. N.Founder Prentice-Hall. Prentice-Hall.50 Give the gift of life. D. In Proceedings TOOLS 5. The object-Z specification language. Yourdnn Press Corn- 74 September1992/Vol. BOOK of Object-Oriented Knowledge. Premerlani. Eiffel: The Language. Oct. B. Prentice-Hall. Roland.. 21. Second Edition. R. Object behavior analysis. 13. 9 (Sept. J. K. and Yourdon. Page-Jones..J. G. N. 8. To copy otherwise. ESPRIT II. 1990).J. G. Ed.. Lang. Nerson. Object Oriented Software. Prentice-Hall.. Object Oriented Analysis. To appear. Business Class Technical Annex. N. Object-Oriented Architec- tures: Analysis and Design of Reliable Systems. Hyderabad.. J.35. 9. 7. 69-87. Proix.. Brunet. pp. N. 16. ACM 35. 19. Cunningham.