8/14/2019 Top Down Data Structure http://slidepdf.com/reader/full/top-down-data-structure 1/17 HEWLETT PACKARD Obiect-Oriented Analysis and Top-Down Software Development Dennis de Champeaux Software an d Systems Laboratory HPL-91-21 February, 1991 [email protected]oo-analysis; top-down; ensemble In this paper, we address th e issue of how to provide an analyst that uses th e object-oriented paradigm with a top-down approach. An analyst gets this approach for free when working within the structured paradigm. Ensembles are introduced that differ from objects in that they connote entities with internal parallelism. Preliminary experimentation suggests that ensembles allow for information hiding. (c)Copyright Hewlett-Packard Company 1990 Internal Accession Date Only
In this paper, we address the issue of how toprovide an analyst that uses th e object-orientedparadigm with a top-down approach. An analystgets this approach for free when working with inthe structured paradigm. Ensembles areintroduced that differ from objects in that they
connote entit ies with internal parallelism.Prelimina ry experimentation suggests thatensembles allow for information hiding.
In this paper, we outline a top-down object-oriented analysis (OOA) method. Top-downOOA allows an analyst to employ well-established strategies like divide-and-conquer.
We start by clarifying some of ou r terminology:
Analysis is th e activity that yields a description of what a target system issupposed to do; detailing functional, performance an d resource requirements.This description could be th e basis for a contract between th e client an d th edeveloper an d aims to be th e unambiguous input to the designer.
Design is th e activity which yields an artifact description of how a targe tsystem will work. Th e design satisfies th e requirements , while it is still implementation language independent. Th e artifact description aims to be th eunambiguous input to th e implementor.
Object-oriented analysis describes a target system with a characterization ofth e entities in th e domain, their inherent interrelationships, an d their intendedbehavior in isolation as well as their interactions. Th e order in which theseaspects are addressed varies, bu t usually th e entity characterization precedesth e behavior description. This contrasts with th e orde r in which structuredanalysis deals with these aspects; behavior first and entity characterization(data dictionaries) second.
Our work is grounded on th e assumption that neither structured analysis nor structureddesign provide a natural character ization for subsequent implementat ion in an objec toriented language, as supported by experience in Hewlett-Packard. At th e same time, we
do no t suggest that object-oriented analysis an d design make sense only when a subsequentimplementation employs an object-oriented programming language.
Th e necessity of analyzing a sys tem in a top-down fashion arises specially in the character ization of large systems. While th e analysis of a toy example like th e popular carcruise control system yields only a "flat" set of objec ts , th e analysis of a corporation likeHewlett-Packard, an airline reservation system or a bank will yield "objects" at differentabstraction levels.
Th e problem that we encounter is caused - we conjecture - by an uncritical adoption ofth e notion of objec t from th e rea lm of th e object-oriented programming languages. Wesuspect that this is th e core reason why identifying objects is a hard task. We can wonderfor instance whether th e following notions are proper objects:
In th e realm of Hewlett-Packard:a division, a departme nt, an employee, a project, a productio n unit, a product, anorder, a floor in a building, a location code, etc.
In th e realm of an airline system:a flight, an airplane, a flight attendant, a client, a flight schedule, a special mealorder, a service schedule, a luggage door, a payment scale, etc.
In th e realm of a bank:an in te rest r ate, a branch office, a teller machine, a corporate account, a loan officer,th e overseas department, a monthly statement, etc.
One cannot immedia te ly deny objec thood to any of those notions. However, their juxtaposition gives an uneasy feeling. We need different abstrac tion levels. Th e unhappyconsequence is that we need to introduce objects that are "less equal", to paraphrase Orwell, than other objects. We propose ensembles, a different k ind of abs trac t ob ject, tofacilitate a top-down analysis mode.
This paper is organized as follows: section 2 summarizes ou r current version of an objectoriented analysis method by outlining th e notions for the models that th e analyst canconstruct. In section 3, we introduce an d discuss th e notion of an ensemble. We illustrateensembles in greater de tail in section 4 by applying them to the example of a car, whichwe view as a hierarchy of multiple systems. Th e last section is devoted to a discussion ofth e pros an d cons of the ensemble concept.
2 The Object-Oriented Analysis Method
Our analysis technique emerged from a variety of influences, among which are work inknowledge representation languages like KL-ONE ([2]), formal software development ([11,5]), experiences gathered inside Hewlett-Packard at utilizing th e object paradigm, an dprevious object-oriented analysis approaches ([9, 3, 8]). In particular, th e work of Shlaerand Mellor ([9]) was th e focus of ou r early efforts.
As mentioned above, we view th e analysis process as "the activity that yields a descriptionof what a target system is supposed to do by detailing functional, performance an d resourcerequirements". The outpu t of object-oriented analysis should satisfy two requirements:
• it should be a c ontrac t between client and developer
• it should be a contra ct between analyst and designer
Many approaches to OOA fail to satisfy th e contract character, mostly because they fallshort of providing two essential features: (1) th e ability to be precise, i.e. to have a richanalysis language that allows, if desired, a rigorous an d semantically unique description ofth e domain of discourse; (2) th e provision of a development process, i.e. a framework inwhich a problem is composed and/ or decomposed.
Our method tries to overcome these deficiencies. I t consists of th e following steps:
These will be discussed in greater detai l in subsequent sections (see also [4]). The reasonfor using these models is to provide a variety of views of an objec t so as to capture as muchdata as possible during analysis. Many of th e topics related to these views go beyond thescope of this paper, for example how to find objects, how to attach identified services toparticular objects, or how to migrate from OOA to OOD. Th e interested reader can findfurther information in th e cited literature.
Th e typical sequence of model development starts with information modeling and proceedsas diagramed below:
1M -------> ST -------> PM
Explanation of th e symbols:1M = Information ModelST = State-Transition ModelPM = Process Model
In order to facilitate th e transition to design an interface model, IFM, may be derived fromth e State-Transition Model an d th e Process Model:
1M -------> ST -------> PM
\ \----------------> 1FM
We foresee that an interface model would generalize away th e specific details of th e object
interactions in th e process model an d would produce th e set of services that are associatedwith a prototypica l instance of a class. (A service is not necessarily a synchronized interaction pair between an initiator an d a recipient. Services subsume here as well trigger andsend-and-forget interactions.)
2.1 I nf o rma ti o n Mo d el
The 1M consists of object class definitions, ensemble class definitions, and definitions ofinter-object relations; th e notion of ensemble is introduced in section 3.
Existing approaches to OOA typically define objec ts by lis ting a collection of a tt ributeswhich are descriptive names (like BankAccount). There are shortcomings with this styleof definition. For example, th e analyst should be able to express what constitutes th e legalvalue set of th e deposit of a BankAccount. An attribute value may be dependent on thevalues of other attributes. Dependencies should be expressible as well. Th e occurrence ofan attribute may be fixed or may vary over all instances of a class. I t is worthwhile toregister such a regularity also.
While attributes help to describe an object, we can elaborate the significance of an attributeby describing it beyond its name through its features. We have borrowed th e followingfeatures from the KL-ONE knowledge representation language ([2]):
• cardinali ty: whether th e attribute value is a singleton, enumerat ion, fixed or unbounded (sub)set.
• modal ity: whether this attribute always ha s a value (i.e. is mandatory), optional orwhether this attribute is derived.
• value restriction: the named set of values ou t of which actual values have to be taken.
The analyst ca n also s ta te a n invariant that applies to every instance of a class. Typically,an invariant is an implicitly quantified statement that refers to features of attributes. (I nKL-ONE ([2]), invariants were captured by structure links; see an example in section 4,figure 1.)
Here is an example that provides attribute name, cardinality, modality, an d value restriction for each attribute:Object class BankAccount
• account owner, fixed-set, necessarily-present, Name
saying that overdraft s in one account ma y be tolerated as long as sufficient funds ar eavailable in connected accounts.
An analyst ma y observe that two defined object classes have common attributes. In thatcase, th e common attributes ca n be abstracted into a new object class, th e common att ri bu te s c an be removed from th e initial classes an d an inheritance relat ionship can beintroduced between th e new abstract object class and the modified classes. Inheritanceca n also be introduced initially as a consequence of inherent commonalities in the domainof discourse. In th e banking world, we encounter checking accounts, saving accounts, commercial accounts, etc. This suggests that one introduces a generic account class an d letth e specific accounts inherit from it .
We can consider the graph constructed by taking the objects as vertices an d th e inheritancel inks as th e arcs. This graph is directed an d acyclic. This graph turns into a tree if noobjec t inher its from multiple parents.
The graph constructed by taking th e objects as vertices a nd th e inheritance links as th earcs is directed an d acyclic. This graph turns into a tree if no object inherits from multipleparents.
While th e Information Model addresses the static aspects of an object, th e dynamic (orbehavioral) aspects are described in a State Model (SM).
The states of an object are derived from th e set of all possible values of i ts att ributes. Astate is defined by a predicate on th e state space spanned by th e cartesian product of th evalue restrictions of th e attributes. The predicates should be defined such that th e statesare mutually disjoint.
A transit ion corresponds with a directed pair of states. The set of states an d transitionsform a directed graph which is no t necessarily connected. In case we have more than onecomponent, we consider th e components as independent. While an object occupies a statewithin each component, inside a component only one state at th e time is visited.
OOA does no t associate actions with states, as is done in [9], bu t with transitions. Th estate-transition model in [9] can be phrased as "states cause each other", while our method
captures "transitions cause each other" .A transit ion carries a condition that is to be fulfilled before a trans it ion can take place;that is, being in a state does not automatically enable a t rans it ion; such a condition canrefer to attributes of "other" objects.
We augment th e concept of state transitions by attaching:
• an external flag that indicates whether a triggering event is required;
• a cause list that describes th e events that are generated as a consequence of th etransition an d act as triggers for subsequent transit ions, usually in other objects.
In order to create objects that are reusable, we describe th e dynamic dimension of an objectindependently of how it will interact with other objects in th e context of th e target system.This entails that a reference to an external object - to describe a causal consequence ofa t rans it ion - should abstract away from th e actual connections that th e object has whenintegrated in the targe t system. To obtain proper generali ty, one may have to introduceattributes in an object whose role is to capture interaction "acquaintanceships" with peerobjects.
As an example consider th e domain of pipes, valves, junctions, pressure regulators, reservoirs, etc. In order to model th e propagation of a pressure change in a pipe, we need torefer to a t ransi tion of an attached device. Since a generic pipe can't know what device itis attached to, we need a pipe attribute that stores this information.
The process model is responsible for "welding" th e state models together through eventdescriptions.
2.3 P ro ce ss M o de l
An analyst can express a causal connection between t ransit ions in different objects byadding to a transit ion in an originator a causelist an d in a recipient transition an indication
that a preceding triggering event is required. In this section, we give an example toelaborate.
We describe th e connection between a button object an d a ca r cruise control object which
is in a sense th e "brain" of a car cruise control system. The but ton 's responsibility is toswitch th e system from th e off to th e on state.
We model th e button as a single state, single transition machine. Th e condition for th et ransit ion is always true. However, th e transition needs a triggering event to fire. Th esource of this trigger is outside th e system boundary an d corresponds with th e side effectof pushing th e physical button on th e dashboard. Th e transition has on its cause list asingle event, On-Event (ccs , turn-on) . Th e ccs argument describes th e recipient of th etrigger; we assume here that th e button ha s an acquaintance attribute ccs. The secondargument, turn-on, indicates which transition in th e recipient is "invited" to fire. Ingeneral, th e originator has no control on whe ther th e recipient can honor th e invitation.For example, pushing th e (physical) button twice should have no effect th e second time.
Th erecipient
ca rcruise control object will have, among others
anOff
s ta te anda
Cruisingstate, and a turn-on transition between th e two. This trans ition requires an externalevent to fire: On-Event. I f necessary a transition may specify an additional condition tobe fulfilled. In our turn-on t ransit ion, we may require, for example , that th e car has acertain minimum speed.
This description is only the tip of th e iceberg. Th e process mode l can employ as wellmore powerful modes of interaction than just send-and-forget triggering. We may want totrigger more than one object/ transition combination an d insist, for example, that thesetransit ions are synchronized. We may want to send data along with a trigger from th eoriginator to the recipient(s). An originator ma y want to obtain an acknowledgementof reception, with or without time-outs . An originator may issue a blocking send whichresults in a suspension until return data is received, etc.
A recipient may be in th e wrong state to honor a trigger/send. There are differentinterpretations of such a situation:
An analyst has made an error; i.e. a condition has been omitted somewhere in th eoriginator.
The trigger/send is queued in th e recipient and will be honored when th e recipient arrivesin th e s ta rt s ta te of th e triggered transition.
Th e trigger/send is lost.
Any of these interpretat ions can be appropr ia te , thus it is the analyst's responsibility toannotate a trigger/send with th e intended interpretation.
3 E n s e m b l e s
Th e different models that we described in th e previous section allow th e analyst to focusattention on different aspects of th e task. Th e definition of th e entities in th e target domain
is separated from th e characterizations of th e dynamics of th e system. The description ofth e lifecycle of an entity is separated from th e description of how an entity interacts withother entities. Still , we feel that th e support for divide an d conquer techniques provided byth e method is insufficient. We should have th e ability to acknowledge formally that certain
groups of entities are t ight ly coupled an d that these groups ar e entities by themselves withmore or less similar features as th e basic entities/ objects in th e target domain. To phraseit in a more compelling m anne r: ob je ct oriented analysis without an entity clusteringtechnique is no t a viable method for th e characterization of large systems.
To stress th e difference between clusters and basic ent it ies, we propose ens embles as analternative for objects. Ensembles share with objects th e modeling apparatus that weoutlined in section 2; i.e, an ensemble h as a tt ri bu te s, h as an associated state-transitionmachine, has th e ability to interact with objects as well as with ensembles an d ca n havean interface model. An ensemble differs from an object in that it stands for a cluster orbundle of less abstract entities which ar e either objects or lower level ensembles. Theseconstituents interact only among each other or with th e encompassing ensemble. I.e. th eensemble acts as a gateway/manager between th e constituents and th e context. Th e
relat ionship between an ensemble an d it s constituents ca n be thought of as sub sumingabstract-part-of. While th e dynamic dimension of an object ca n be conceptualized as asequential machine, an ensemble connotes an ent ity with interna l parallelism.
For example, in th e bank domain, we ca n see an account as an object when only onetransaction at a time is permitted on it. On th e o ther hand, th e loan depar tment withseveral loan officers would be an ensemble because it s constituents, th e loan officers, areoperating in parallel (presumably).
An ensemble h ides detai ls of it s constituent objects/ sub-ensembles that ar e irrelevantoutside th e ensemble, somewhat in analogy with an object in th e programming realm thathides it s internal implementation details.
To make th e notion of an ensemble more real , we will look in this section at it s features inmore detai l. Section 4 discusses an example.
3. 1 E ns em bl e C la ss
In th e same way that we like to deal with classes of objects instead of individual objects, wewill deal with classes of ensembles instead of individual ensembles. An d as is th e custom inthe case of objects in which a class of objec ts is character ized with a prototypical member,called "an object", we will deal with classes of ensembles through a prototypical ensemble.
We have th e following correspondences:
descriptive notiontarget domain atomic clusterentity object ensembleconcept object class ensemble class
Describing th e constituent objects/ sub-ensembles of an ensemble is th e primary task ofit s information model. Regular attributes can do this. An invarian t relating a constituentin th e value-restriction of such an a tt ri bu te a nd t he $self of th e ensemble may elaborateth e abstract-part-of relationship between th e two.
Additional attributes in an ensemble ma y describe features that apply to th e cluster ofconst ituents as a whole. For instance, summary information of th e constituents. Theirnumber is an example. Or, as an another example, we ca n capture in an ensemble information that applies to each of it s const ituents . Consider a fleet to be represented by anensemble. Th e individual ships share th e direction in which they are going. Thus, we canintroduce direction as an attribute of a fleet.
When an ensemble has non-constituent attributes, it may have a "life of it s own"; i.e. wema y develop a state-transition model for it . As an example we can maintain in a fleet anattribute that records th e distance of th e fleet to i ts home port. This allows us, for example,to introduce th ree s tates induced by a l inear ordering suggested by: near-the-home-port,remote-from-the-home-port an d far-away-from-the-home-port. These distinctions couldhave consequences in th e process model for, say, refueling operations.
I f an ensemble has been equipped with a state-transition model, we can describe in terensemble and/or ensemble - object interactions similar to th e plain inter-object interactions. An example of an inter-ensemble interaction in ou r fleet domain, where a home-fleetis seen as th e ensemble consisting of th e home ports of th e ships in th e fleet, would bea fleet-horne-docking trigger initiated by a fleet to begin th e docking of th e ships in th ehome ports. An example of an ensemble - object interaction would be th e fleet giving adirective specifically to one of it s ships.
4 ExampleWe will model fragments of a ca r to illustrate in greater detail th e use of ensembles. A carca n be seen as a single object only if one does no t need to deal with it s components. Thiswould be th e case, for instance, from th e perspective of a ca r rental agency. Otherwise,when th e internal aspects do matter, we better see a ca r as consisting of several systems,including: steering, suspension, electrical, transmission, brake, engine, heating, doors,controls, etc.
We can recognize that th e entries on this l ist do no t correspond with ordinary ca r attributes.They have behaviors of their own, while they operate semi independently an d in paral lel . Incontrast , examples of regular attributes of a ca r are: chassis, coach-work, owner, licensenumber, speed, location, etc. Some of th e entit ies on this li st also have life cycles andoperate semi independently, thus one ma y wonder why t he y a re no t const ituents of a car.The justification for th e different elements vary. For th e chassis and coach-work one mightargue that they have a state "being a part of a ca r assembly", which from th e perspective ofth e car is to o constant to be considered a system. F or th e owner, one might argue insteadthat th e owner attribute is an artifact, th e remnant of a binary Owner relationship betweencars and persons that is realized ("implemented") via attributes. The other attr ibutes referto value restrictions which aren't objects, at least no t from th e perspective of a car.
When we adhere to th e graphic convention that regular att ributes are connected to themain concept with - - - lines, while constituent attributes are connected with === lines, weobtain the following fragment of th e information model of a car:
/ Car \ u----> / Vehicle \ ; Vehicle i s a super class of Car
- - - - - - -{chass i s / 1 / np/ Chassis}-------{coach-work/ 1/ np / Coach-work}- - - - - - -{owner / [1 , 00)/ np/ Person U . . . }
; An owner can also be a here unspecified; non-person, more than one owner i s possible
-------{license-number/ 1/ n p/ S tri ng}- - - - - - -{speed/ 1 / np/ [0 , max-speed]}- - - - - - -{ loca t ion / 1/ np/ Place}======={steering-sys/ 1 / n p/ S tee rin g- sy s}======={suspension-sys/ 1/ np / Suspension-sys}======={electrical-sys/ 1/ np/ Electr ical-sys}======={transmission-sys/ 1/ np/ Transmission-sys}======={brake-sys/ 1/ np / Brake-sys}======={engine-sys/ 1/ np/ Engine-sys}======={heating-sys/ 1/ np/ Heating-sys}======={door-sys/ 1/ np/ Door-sys}======={control-sys/ 1/ np/ Control-sys}======={wheel-sys/ 1/ np / Wheel-sys}
+ s t ruc tu re - l inks :wheel-sys.front-wheels.angle =
wheel-sys.wheel-rotat ion =wheel-rotation-function(speed)
Fig. 1 A fragment of the information model of a Car,when seen as an ensemble .
The structure-link in Car reaches inside th e ensemble Front-wheels which is a constituentof the ensemble Wheel-sys. Front-wheels i tself has a constituent Wheel-pair, which inturn has two Wheels as constituents. We obtain the following fragments:
/ Wheel-sys \
I -- - -- -- {whe e l- r ot a ti o n / 1 / np/ [0 , max-rotation]}I======={front-wheels/ 1 / np/ Front-wheels}I======={rear-wheels/ 1/ np/ Rear-wheels}
Fig. 2 A fragment of some cons t i tuents of theensemble Car; these cons t i tuents arethemselves ensembles.
Regular a tt ribu te s and constituent attributes have much in common, see section 2. Aconstituent attribute also has a ca rdinality descriptor, a moda lity descriptor as well as acharacterization of th e value restriction, i.e. th e kind of constituent(s) that is referred to
in th e attribute. For example, if we see the wheels of a Car as non-distinguished subconstituents of th e Wheel-sys const ituent - unlike th e modeling done above -, we canindicate t ha t t he cardinality feature is four (excluding here pathological vehicles), that th emodality is necessary an d that th e kind is obviously Wheel. A structure link capturing aninvariant can refer to a constituent attribute as well. For example, there is a constraintbetween th e angle of th e front wheels with respect to th e chassis an d th e degree of rotationof th e steering wheel as expressed above in th e information model of Car.
Observe that we introduced a regular attribute wheel-rotation in Wheel-sys. A structurelink in Wheel-sys should express that th e value of this attribute is th e average of th erotations of th e Wheels in th e two constituting Wheel-pairs.
An ensemble ca n have a regular state-transition model (and possibly more than one, as is
allowed for regular objects). For example, we can observe for ou r car whether it is insuredor not, whether it is for sale or not, whether th e manual transition indicates neutral, rear,first, second, third, fourth gear, whether th e l ights are off, on park lights, dimmed or full,etc. Some of these s tate -mode ls a re imported from lower level constituents through th econtrol-sys constituent.
As a major difference between an object and an ensemble, we have associa ted with anensemble a forwarding mechanism for triggers and messages that mediates between externalentities an d th e constituents of an ensemble. Thus, we can hide aspects of th e constituents
of an ensemble which have significance only inside th e ensemble. For example, th e interfaceof th e engine is an internal affair of a ca r an d th e outside world need no t to know anythingabout it . On th e other hand, th e forwarding mechanism of th e ca r ensemble should exportth e interface of th e control constituent.
We will i l lustrate information hiding occurring within th e ca r ensemble by sketching th edescription of starting a car. We will export through th e Control-sys constituent th e statetransition diagrams of an Ign i t ion- lock an d of an Oil-pressure-indication-lamp,which are both (sub) constituents of Car.
The state-transition diagram of th e ignition lock:
Igni t ion- lock:in se r t tu rn -r ig ht tu rn -r ig ht/ - - > - - \ / - - > - - \ / - - > - - \
no - inser ted contact s t a r t
key ke y\ - - < - - / \ - - < - - / \ - - < - - /
remove t u r n - l e f t t u r n - l e f t
Fig. 3 The exported s t a t e - t r a n s i t i o n diagram of th eign i t ion- lock .
The t u rn - r igh t transition that leads into th e con tact state triggers th e contacted transition in Oil-pressure-indication-lamp, see below.
Other relevant constituents that we consider are: Star t -engine, Engine-sys and Oilpressure-sensor.
Their state transitions will no t be exported through th e Control-sys. For th e start-enginewe have th e following behavior description:
Star t -engine :s t a r t -up/ - ->- - \
off running\ - - < - - /tu rn-off
Fig. 4 The s t a t e - t r a n s i t i o n diagram of the s t a r t - en g in e .
We assume that th e t u rn - r igh t transition that connects th e con tact state with th e s t a r t
state in Igni t ion- lock has a t rigger direc ted at th e s t a r t -up transition in Start-engine.(The ident ity of th e recipient object - in this example there is only one legal recipientcan be t raced through th e car ensemble.) We omi t here conditions associa ted with th es t a r t -up transition, like th e transmission being in neutral, etc. Th e s t a r t -up transitionin it s turn will generate a t rigger a imed at th e s t a r t -up transition in Engine-sys:
Fig. 5 The s ta te - t rans i t ion diagram of the engine.
To simplify matters, we assume that the star t -up transition in Engine-sys directly triggers th e go-high transition in Oil-pressure-sensor:
Oil-pressure-sensor:
go-high
/ - ->- - \low high\ - -< - - /go-low
Fig. 6 The s ta te - t rans i t ion diagram of theoi l -pressure-sensor
Th e go-high transition finally triggers the s tar t -up transition in:
Oil-pressure-indicator-lamp, which causes the lamp to go off again:
Oil-pressure-indicator-lamp:
contacted s t a r t -up/ - - > - - \ / - - > - - \
lamp lamp lampoff on off
\ - - < - - / \ - - < - - /
not-contacted tu rn -o f f
Fig. 7 The exported s ta te - t rans i t ion diagram of theoil-pressure-indicator-lamp
Since th e state-transition of the Oil-pressure-indicator-lamp is exported th e driverwill see th e lamp go off.
When we look from th e outside, we see pseudo causal consequences. For instance, th et u rn - r igh t transition ou t of th e inserted-key state "causes" th e oil-pressure- ind icator-lamp to go on. A similar pseudo causali ty turns this lamp off again when the ignitionlock moves into t he s ta rt state (which signals th e driver to turn th e key ou t of th e startposition, which causes th e ignition-lock, etc.)
However, when we look inside th e Ca r ensemble , we will see a different triggeringj messaging pattern that ultimately achieves these pseudo causal consequences.
In s um ma ry a nd w it ho ut claim to automotive correctness: starting engine ~ runningengine ~ actual pressure goes up ~ oil pressure sensor goes in high state ~ oil pressurelamp goes off. Consequently, th e introduction of ensembles has allowed us to successfullyhide low level mechanisms from higher order functionality.
5 Related work
Objec t-or iented ana lysis is a relatively new field. Th e first book in this area is fromShlaer & Mellor, [9]. Most of th e bo ok is dev ote d to th e Information Model. One chapterdiscusses an example in which they illustrate t he S ta te Model an d their Process Model.Their Process Model differs from ours in that they rely on data flow diagrams, borrowedfrom Structured Analysis, to describe th e actions in their State Models. As a result, th e
interaction between objects is described in their method in an indirect way - th e occurrenceof an external data store in a data flow diagram. We feel that our triggers an d messagesallow us to express directly causal interactions between objects. A summary of their versionof Objec t-Oriented Analysis can be found in [10].
In Ward, [12] , an attempt is made to salvage Structured Analysis and Design when an implementation will be done in an Object-Oriented programming language. Ward acknowledgesthat th e original version of SAjSD doesn 't lend itself easily to th e identification of objects,and certainly no t to object hierarchies which deepen th e insight in th e understanding of th edomain. However, he points to a refinement of SAjSD for real-time systems, [13], in whichentity-relationship modeling is imported from th e database realm. We remain doubtfulwhether unbiased object identification can be done after processes have been modeled.
Ou r comment on Ward 's paper, [12], applies also to that of Bailin, [1].
In Wirfs-Brock et al, [14], th e authors discuss th e notion of a subsystem.
A subsystem is a set of ... classes (and possibly other subsystems) collaboratingto fulfill a common set of responsibilities.
They motivate their subsystems similarly:
Subsystems are a concept used to simplify a design. Th e complexity of a largeapplication ca n be dealt with by first ident ifying subsystems w it hi n i t, an dtreating those subsystems as classes.
They take an explicit position regarding whether subsystems will show up ultimately inan implementation:
Subsystems ar e only conceptual entities; they do no t exist during execution.
On th e basis of ou r understanding of their subsystems, we have found here th e mostsignificant difference with respect to ou r ensembles. Certain ensembles introduced in th eanalysis phase may indeed be "compiled away" in th e subsequent design phase, bu t weforesee that at least those ensembles which have their own regular attributes in addition toconstituent attributes will show up in th e implementation. This explains why we felt th enecessity of introducing a forwarding mechanism for triggers/ messages in ensembles. Inaddition, we surmise that th e encapsulation provided by ensembles - constituents cannotbe reached directly from outside an ensemble - is not available in their subsystems.
In th e Eurofean ter ra in, we see two approaches as relevant for th e work described here.Jacobson [6 describes a development method for large object-oriented systems, calledObjectOry, that covers th e analysis phase as well as th e design phase. We discuss hereonly th e analysis component. Th e core notions are: entities, interface objects an d use cases.Entities correspond with th e objects in th e target domain. Interface objects are introducedto shield the "real" objects from th e system interface with th e users/ external world. Usecases - as far as we understand them - correspond with generic scenarios that define th etarget system's behavior from th e perspective of a user. (A user is to be understood ina wide sense; i.e. i t can be another system.) Th e material that we ha d available didno t mention (sub )systems as a way to structure a target system. Use cases, however, doprovide a global view. We suspect that a use case is a special case of th e informationcaptured by a state-transition model associated with the targe t system represented as anensemble.
Beta [7] is a programming language an d also a development technique. T he B eta languagesimplifies th e collection of object-oriented notions by simply providing patterns as th e onlyconcept for classes, methods, procedures an d types. As a consequence, th e analysis technique reflects this simplicity, an d a lot of emphasis is pu t on modeling th e communicationbetween objects. Beta is one of th e few object-oriented systems that emphatically supportsconcurrency in all s teps of th e development process. Th e Beta concurrency primitives fore.g. synchronization are similar to what we have suggested for triggers an d services in ou rmethod. Th e difference is that they have already gained experience with implementinga particular communication scheme, an d that they have restricted th e analysis to thatscheme (ADA-like rendez-vous). In ou r technique, th e analyst has a degree of freedom todefine and use his/her own communication scheme.
6 Summary and Conclusion
Object-oriented techniques, as practiced in OO P have a bottom-up flavor since OO P doesno t formalize an d elaborate object decomposition. This is acceptable or even desirable inth e programming phase. However, an analyst needs to operate - especially in th e earlyphase - in a top-down fashion. In this paper, we have proposed ensembles as a mechanismfor clustering tightly coupled objects. This mechanism supports top-down decomposition.We have illustrated ensembles with several examples.
A major distinction between ensembles an d objects is that an ensemble connotes an entitywith internal parallelism, while an object connotes - from th e perspective of th e ta sk domain - a finite state machine. We associate with an ensemble a trigger/ message forwardingmechanism that mediates th e interaction between external entities an d th e internal constituents of th e ensemble. Th e examples discussed indicate that information hiding can beachieved indeed through ensembles.
Our ensembles resemble th e sub-systems that are introduced for a similar purpose byWirfs-Brock et al [14]. Their sub-systems appear to be a mental construct only while weforesee our ensembles to materialize ultimately in an implementation.
Experiments to validate th e effectiveness of ensembles by applying th e OOA method tolarger real-life examples are ongoing.
Acknowledgement
George Woodmansee, Donna Ho, Penelope Faure an d Teresa Parry provided illuminatingfeedback.
7 References[1] Bailin, S.C., An Object-Oriented Requirements Specification Method, in CACM, vol
32, no 5, pp 608-623, 1989 May.[2] Brachman, R.J ., A Structural Paradigm for Representing Knowledge, Report 3605,
BBN, 1978 May.
[3] Coad, P. & E. Yourdon, Object-Oriented Analysis, Yourdon Press, Prentice-Hall, 1990.
[4] de Champeaux, D., & W. Olthoff, Towards an Object-Oriented Analysis Method, 7thAnnual Poeific Northwest Software Quality Conference, pp 323-338, Portland OR,1989.
[5] Goguen, J., Thatcher, J .W., Wagner, E.G., Wright, J .B. , Ini tia l Algebra Semanticsan d Continuous Algebras, JACM, vol 24, no 1, pp 68-75,1977.
[6] Jacobson, 1., Object-Oriented Development in an Industrial Environment, in Proc.OOPSLA '87, Orlando, Florida, pp 183-191, 1987 October.
[7] Kristensen, B., Madsen, 0., Moller-Pedersen, B., Nygaard, K., Proc. 3rd Conferenceon Object-Oriented Programming Languages, Systems an d Applications, Orlando,Florida, pp 183-191.
[8] Kurtz, B., Object-Oriented Systems Analysis and Specification: A Model-Driven Approach, M.Sc. Thesis, Brigham Young University, CS Dept., 1989.
[9] Shlaer, S. & S.J. Mellor, Object-Oriented Systems Analysis, Yourdon Press, 1988.
[10] Shlaer, S., S.J. Mellor, D. Ohlsen, W. Hywari, Th e Object-Oriented Method for Analysis, in Proceedings of the 10th Structured Development Forum (SDF-X), San Francisco,1988 August.
[11] VDM Specification Language Proto-Standard, SI VDM Working Paper 1ST 5/50/40,1988.
[12] Ward, P.T., How to integrate Object Orientation with Structured Analysis and Design, in IEEE Software, pp 74-82, 1989 March.
