模型和代码的连接

1997/July/2 13:44Models and code: the connectionAlan Cameron Wills, TriReme International Ltd1 The power of the Big PictureWhen you gather around a whiteboard to discuss your design withyour colleagues, the last thing you want write up there is programcode. On that whiteboard, you want to show how your piece of thesystem works, and how it interacts with things outside it. Andwhether it’s a single procedure or an entire planetwide distributedsystem, you want to fit it all on that board and convey useful thingsabout it.So we draw diagrams: sometimes ad hoc, sometimes using a recog-nised notation (like UML[2], Coad-Yourdon, use-cases, flowcharts,or many others). The great power of these pictures is their ability toexpose the important things you really want to say about the soft-ware (or indeed, about hardware or business processes) while get-ting rid of the clutter of fine detail — which you are forced into ifyou write program code.This idea of leaving out the fine detail is called abstraction . Althoughthe word sometimes has somewhat esoteric or theoretical connota-tions, it is actually essential to our capability to think: it is the onlyway a human-sized brain can grasp the whole thing at once.© 1997 Alan Cameron Wills 1997/July/2 13:44 -1 of 28But natural language (English etc) is good at abstraction. When youstand at the whiteboard, you talk. But it’s not so good at precision,nor at conveying complex relationships. Hence the diagrams andother modeling and design notation: they take the ambiguity out ofthe things you say, helping to avoid everyone coming away withdifferent understandings of what has been said and agreed.And that precision has another benefit: writing down the abstrac-tions often exposes inconsistencies and gaps that would otherwisebe glossed over. People sometimes think that it’s only when you getto program code that you find these mistakes. Not so: it’s not thedetail of programming language that exposes the problems, but itsunforgiving precision. Using a design language that is precise andyet abstract gives us a way to assess a design with confidence beforecoding.On the other hand, anything written entirely in heiroglyphs is writ-ten once and never read. In good documentation or presentation,the natural language narrative and the more formal descriptions(often supported by a design tool) should complement each other.This is not to argue that you must always complete the high-leveldocumentation before embarking on coding. There are plenty oftimes when it’s a tactical necessity to do things the other wayaround. Prototypes and Rapidly Approaching Deadlines are theusual reasons. Nor is extensive documentation always necessary. Asoftware component that may be used in many contexts is worthmore effort than a throwaway assemblage from a kit of parts.But what I do support is that the project cannot be called completeuntil the abstract documents (to whatever extent they exist) are truestatements about the delivered software; that is, the code shouldconform to the abstractions. The purpose of this article is to examineexactly what is meant by conformance. When you draw a linebetween a couple of boxes, what are you promising the user, orimposing on an implementor? And what are you not promising,what can the designer get away with?The ideas described here are part of the Catalysis approach to soft-ware design [1], developed by the present authors. Catalysis buildsupon the widely-accepted Unified Modeling Language, offeringwell-defined techniques for component-based and more traditionalstyles of software construction.-2The power of the Big PictureThe next section discusses the idea of abstract models, and how they relate to their implementations. The third section shows an example of how a design can be related to abstract models in terms of a small set of defined conformance relations.The power of the Big Picture-32An abstract modelLet’s look first at what can be done with a good abstract model.Figure 1 shows a model of a spreadsheet, together with a Dictionaryinterpreting the meaning of the pieces in the model. A spreadsheetis a matrix of named cells into each of which the user can type eithera number or a formula. In this simplified example, a formula can beonly the sum of two other chosen cells (themselves either sum ornumber cells).The model shows exactly what is expected of a spreadsheet: that itmaintains the arithmetic relationships between the cells, no matterhow they are altered: in particular, the invariant “{Sum::...” says thatthe value of every Sum-cell is always the addition of its two oper-ands.Notice that this is very much a diagram not of the code, but of whatthe user may expect. The boxes and lines illustrate the vocabulary ofterms used to define the requirement.The box marked Cell, for example, represents the idea that a spread-sheet has a number of addressable units that can be displayed. Itdoesn’t say how they get displayed, and it doesn’t say that if youlook inside the program code you’ll necessarily find a class calledCell. If the designer is keen on performance, some other internalstructure might be thought more efficient. On the other hand, if thedesigner is interested in maintainability, using a structure that fol-lows this model would be helpful to whoever will have to do theupdates.The model doesn’t even say everything that you could think of tosay about the requirements. For example, are the Cells arranged inany given order on the screen? How does the user refer to a Cellwhen making a Sum? If all the Cells won’t fit on the screen at a time,is there a scrolling mechanism?It’s part of the utility of abstract modeling that you can say or notsay as many of these things as you like. And you can be as precise orambiguous as you like — we could have put the “{Sum::...” invari-ant as a sentence in English. This facility for abstraction allows us touse modelling notation to focus just on the matters of most interest. -4An abstract modelFigure 1: Model for a SpreadsheetAn abstract model-5Although (or perhaps because) the model omits a lot of the detailsyou’d see in the code, you can do useful things with it. For example,we can draw ‘snapshots’ — instance diagrams that illustrate quiteclearly what effect each operation has.Snapshots illustrate specific example situations. Figure 2 shows asnapshots showing the state of our spreadsheet before and after anoperation. (The thicker lines and bold type represent the state afterthe operation.)Notice that because we are dealing with a requirements model here,we show no messages (function calls) between the objects: those willbe decided in the design process. Here we’re only concerned withthe effects of the operation invoked by the user. This is part of howthe layering of decisions works in Catalysis: we start with the effectsof operations, and then work out how they are implemented interms of collaborations between objects.Figure 2: Spreadsheet snapshots-6An abstract model3RefinementNow let’s consider an implementation. The first thing to be said isthat the program code is very much larger than the model, so we’llonly see glimpses of it here.1 Nor does every detail of the code fol-low the same structure as the model: for example, we’ll see thatthere is no class called Blank in the code.But suppose I’m asked in a code review to justify the differencesbetween my code and the model, which expresses requirements.What arguments do I use? The ultimate justification of course is thatwhatever the code does is at least what you’d expect from themodel, and testing should bear this out. But some kind of rationalewould give earlier and better confidence; and convince me, whileI’m designing, that I’m on the right track.The relationship between a model and a design is called ‘refine-ment’. A valid refinement does everything you’d expect from read-ing the model. (Some prefer to say that the design ‘conforms’ to themodel, and reserve ‘refinement’ to mean the act of making a confor-mant design or more detailed model.)In an object-oriented context, we can distinguish a few main kindsof refinement. Combinations of them cover most of the valid cases:you can explain most design decisions in terms of them. In a largedevelopment, the usual layers of requirements, high-level design,detailed design, and code, can be seen as successive refinements.Understanding the different kinds of refinement has several advan-tages:•It makes clear the difference between a model of requirements and a diagram more directly representing the code (one box perclass).•It makes it possible to justify design decisions more clearly.•It provides a clear trace from design to implementation.1.It can be inspected at /trireme/papers/refinement/Refinement-7Many of the well-known design patterns are refinements applied inparticular ways. The refinements we’re about to discuss are, if youlike, the most primitive design patterns.The rest of this article illustrates four principal kinds of refinement,using the Spreadsheet as an example. Briefly, the four categories are:Model conformance: An abstract model contains much less informa-tion than the program code. The class diagram is alot simpler. Model conformance is the relationshipthat says “this model represents the same conceptsas that, but with more detail.”Operation conformance: In a model, we can specify an operation bywriting down the effects it achieves (for examplewith a pair of pre and postconditions). Operationdecomposition means writing the program codethat meets the spec.Action decomposition: ‘I got money from my bank’ is an abstractionof a sequence of finer-grained actions. A refine-ment might be ‘I gave the bank my card; it told memy current balance; I asked it for $50; it gave meback my card; it gave me the cash; it debited myaccount’.Object decomposition: ‘My bank’ is an abstraction refering to a col-lection of people, buildings, machines, and so on.‘I [had some interaction with] my bank’ means Ihad some interaction with some part of it. I gavemy card to the card-reader forming part of anATM, which is in turn part of my bank; the screenof the ATM told me my balance; I pressed the keyson the ATM to tell it I wanted $50; and so on. (Andwhile we’re on the subject, “I” is an abstraction fora collection of many pieces as well.)3.1Model conformanceLooking at my code for the Spreadsheet, the first thing the reviewernotices is that the classes differ somewhat from those mentioned inthe requirements model.-8RefinementFor example, in my code, Sums can have a list of any number of operands. “So where are the left and right attributes of a Sum?” asks the reviewer. “No problem,” I reply. “All the information mentioned by the requirements is there --- it’s just that some of the names have changed. If you want to have the left and right operands of any Sum, use the first and second items on my operands list.”3.1.1Documenting model conformanceThe general rule is that, for each attribute or association in the abstract models, it should be possible to write a read-only function in the implementation code that abstracts (or ‘retrieves’) its value. It doesn’t matter if an abstraction function is hopelessly inefficient: it only needs to demonstrate that the information is in there some-where. Nor does it matter if there is more information in the code than in the model.QA departments may insist that abstraction functions should be written, even though they are not always actually used in the deliv-ered code, because:•Writing them is a good cross-check, helping to expose inconsis-tencies that might otherwise have been glossed over.•They make it clear exactly how the abstract model has been rep-resented in your code.•For testing purposes, testbeds will be written that test the post-conditions and invariants defined in the requirements models.These talk in terms of the abstract model’s attributes, so theabstraction functions will be needed to get their values.For example, during testing we could check the invariant after every user operation (Sum:: value == left().content.value + right().content.value). For that to work in my code, we’ll need my abstraction functionsdefined for Sums:class Sum1{private Vector operands; // of CellCell left () { return (Cell) operands.elementAt(0);}Cell right () { return (Cell) operands.elementAt(1);} ...Refinement-9But even worse, my design (shown in Figure 3) does not give a con-tent attribute for Cells, and (until I have to include them for theabstraction function) does not have classes Content, Blank andNumber. But the information can be abstracted:class Cell1{private Sum constraint ; // may be nullprivate int value;Content content (){if (constraint!= null) return constraint;else if (constraint.size() == 0) return new Blank();else return new Number (value);}Model conformance allows an abstract yet precise picture to be writ-ten, of the information stored in a system or component. A moredetailed model will support a more detailed account of the design,or more features.3.2Action decompositionThe next thing my code reviewer notices is that nowhere is there afunction setSum(Cell, Cell). I explain that I have decided to refine thisaction (or ‘use-case’) to a finer-grained series of interactionsbetween the User and the Spreadsheet. A diagram that more closelyrepresents my design is in Figure 3.To set a cell to be the sum of two others as per requirement, the userperforms these steps:•select the Cell in question by clicking the mouse;•type “=” and click one of the operand Cells;•type “+” and click on the other.In fact, the requirement is provided by a combination of features inmy implementation, which allows for a Cell’s contents to be equal tothe sum of one or more other cells. My “=” operation turns the Cellinto a single-operand sum, and each “+” operation adds anotheroperand. So there is no single operation with the signature “set-Sum(Cell, Cell), either at the user interface, or anywhere inside thecode.-10RefinementIn general, actions shown as ellipses between participants representsome interaction, without going into the details of the dialogue.Actions can always be documented with unambiguous postcondi-tions, stating the overall effect of the process.Notice that all participants are affected. A user who knows how touse my spreadsheet-implementation will not necessarily know howto use another design. It is the collaboration that has been refinedhere, not the participants individually.3.2.1Documenting action decompositionFor the benefit of future reviewers, maintainers, and the author ofthe user manual, we document the refinement as in Figure 4.3.2.2Action decomposition in codeAction refinement is not just about user interactions. The same prin-ciple can be sued when describing dialogues between objects in thesoftware. This enables collaborations to be described in terms of theeffects achieved by the collaborations, before going into the precisenature of the dialogue.Figure 3: A step nearer my codeRefinement-11-12RefinementFor example, in the Spreadsheet implementation, Sums register as observers of their target Cells; so when a Cell’s value changes, it must notify all its observers. The local effect is to propagate the change in value; we can document that without deciding whether the Cell sends the new value in the message, or whether the Sum calls back asking for the new value.Ordinary object-oriented function calls are the most refined stage of action decomposition.3.3Object decompositionObject decomposition often accompanies action decomposition, when it turns out that the detailed dialogue is not conducted between the participants as wholes, but between their parts.For example, the user interface of the spreadsheet should be sepa-rated from the core classes. The mouse and keyboard operations are received by different UI objects, depending on mode. By default, mouse clicks are dealt with by a Cell selector, that sets the currentFigure 4: Action decompositionCell c, Sum s :: c.value != c.old.value && c in s.operands => update ( )postcondition: The difference in value is propagated to the Sum.c.value – c.old.value == s.~constraint.value – s.old.~constraint.valueupdate occurs whenever any operation changes the Cell’s valuefocus. But after an “=” or “+” keystroke, a SumController is created and registered as mouse listener; it interprets mouse clicks as addi-tions to the focus Sum.3.3.1Documenting object decompositionThe refinement relation in object decomposition can best be docu-mented with object interaction graphs or sequence charts. The abstract object can be shown enclosing its refinements.3.4Operation conformanceThe most refined form of action is an ordinary function (or ‘opera-tion’ or ‘message’) defined on a particular receiver class. Operations may be specified in a model with pre/postcondition pairs. Any invariants should be considered to be ANDed with both the pre and the postcondition of each operationof the model. In other words, the designer may assume the invariant true to begin with, and must ensure it is restored when the operation is finished.Refinement-13A conformant operation may be produced by strengthening thepostcondition or weakening the precondition: that is, the refinementmay do more than expected, or do it in a wider range of circum-stances (or both). A refined model may also have more operationsdefined than the abstraction (because in the abstraction nothing isknown about their effects: they have completely open postcondi-tions).But the usual operation refinement is a block of program code. Theprecondition can be thought of as a test that, in debug mode, can beapplied at the beginning of the operation, if it ever turns out false,there is a problem with the caller. The postcondition has to comparestates between the start and end of the operation, and a false indi-cates a problem with the operation’s design. Some programminglanguages, such as Eiffel, provide for pre and postconditions in thesyntax, together with such a debugging mode.Sequence charts are once again useful for illustrating the working ofan operation in a typical cases, though they have the drawback thatonly one situation is shown, with one configuration of objects.-14Refinement4Software ComponentsComponent-based development is about constructing kits of partsthat can fit together in many ways to make a variety of applications.The Java Beans protocol, for example, provides a basis on whichcomponents can be built.Components need interface specifications. If we are seriously goingto build software parts each of which can be used in situations itsdesigner never envisaged, we will have to be very clear about whateach component claims to be able to do. This suggests that CBD willmotivate a higher standard of documentation than has hitherto beencommon.Its designer will have to be able to verify that a component willwork under any circumstances permitted by the model. And userswill have to be able to verify that a component they’ve aquired(with its model) will satisfy the requirements they have (expressedin their own model). This suggests an unbelievable leap in enthusi-asm for formal program proof!Component-coupling protocols (such as Beans) generally providefor two sorts of interfaces: output and input. The outputs of onecomponent are connected to the inputs of another:Using a model, the inputs can be specified using pre and postcondi-tions (whether you write them very formally or just in naturallanaguage). The inputs cause a change of state in the model; the out-puts are caused by a change of state. Outputs can be specified in thisstyle:Button::old.up && down => ^pressed ()(^marks an output event.)Software Components-155Using refinementsThe four kinds of refinement discussed here are used as the basics inthe Catalysis approach to software development. We have omittedsome complexities associated with callbacks and concurrentthreads.It is possible to construct frameworks of ‘prefabricated’ refinements,which can be used to document the relationship between model anddesign in the same way as the primitive refinements. Many of thecommon design patterns can be understood in these terms.One of the most useful aspects of an abstract model is that it isn’t theonly one: many useful ‘views’ can be constructed about one piece ofprogram code. Different users’ viewpoints, and different functionalareas are frequently useful parallel abstractions.It is unfortunate that there is very weak support for refinementamong the popular OOA/D tools. In particular, some tool vendors’boasts that their tool can extract diagrams from C++ and vice versaseem to miss the point. Why use diagrams unless they help you getaway from the C++? To express your programs in pictures is nice insome ways, but isn’t getting the most out of the notation.As we have seen, a detailed design can be related to a much moreabstract model by using combinations of refinements. This enablesthe most important design decisions to be separated from the detail,and discussed and documented without ambiguity.-16Using refinements6ReferencesD. F. D’Souza & A. C. Wills Software development with Catalysis,Addison-Wesley, in preparation.[3] UML 0.9 Documentation Set, [4] G.Leavens et al, Object specification using Larch[5] Reenskaug, Wold, Lehne: Working With Objects, Manning/Prentice Hall. NewYork 1996[6] D. D’Souza and A. Wills, Extending Fusion: Practical Rigor and Refinement: http:///papers; also in Fusion in the Real World, D. Coleman et aleds, Prentice Hall, 1995[7] B Meyer, Object oriented Program Construction, PHI 1988[8] A. Wills, “Frameworks”, in proceedings of Object-Oriented Information Systems,London Dec 1996. Also /papers/fworks.html[9] S.Cook & J.Daniels, Designing Object Systems, [PHI 1994]. Discusses abstractmodels, refinement and strong semantics for OOA models.[10] D.Coleman et al, Fusion, 1994. Discusses abstract models and refinement.References-17-18ReferencesReferences-19-20References。