南京大学：《面向对象技术 OOT》课程教学资源（教材电子版）27 Object-oriented analysis.pdf_大学文库

904 OBJECT-ORIENTED ANALYSIS $27.1 Goals of performing analysis Al.To understand the problem or problems that the eventual software system,if any,should solve. A2.To prompt relevant questions about the problem and the system. A3.To provide a basis for answering questions about specific properties of the problem and system. A4 To decide what the system should do. A5 To decide what the system should not do. A6.To ascertain that the system will satisfy the needs of its users,and define acceptance criteria(especially when the system is developed for an outside customer under a contractual relationship) A7.To provide a basis for the development of the system If analysis is being applied to a non-software system,or independently of a decision to build a software system,Al,A2 and A3 may be the only relevant goals. For a software system,the list assumes that analysis follows a stage of feasibility study which has resulted in a decision to build a system.If,as sometimes happens,the two stages are merged into one(not an absurd proposition,since you may need an in-depth analysis to determine whether a satisfactory result is conceivable),the list needs another item:A0,deciding whether to build a system. Although related,the goals listed are distinct,prompting us in the rest of this chapter to look for a set of complementary techniques;what is good for one of the goals may be irrelevant to another. Goals A2 and A3 are the least well covered in the analysis literature and deserve all the emphasis they can get.One of the primary benefits of an analysis process, independently of any document that it produces in the end,is that it leads you to ask the relevant questions(A2):what is the maximum acceptable temperature?What are the recognized categories ofemployees?How are bonds handled differently from stocks?By providing you with a framework,which you will have to fill using input from people competent in the application domain,an analysis method will help spot and remove obscurities and ambiguities which can be fatal to a development.Nothing is worse than discovering,at the last stage of implementation,that the marketing and engineering departments of the client company have irreconcilable views of what equipment maintenance means,that one of these views was taken by default,and that no one cared to check what the actual order giver had in mind.As to A3,a good analysis document will be the place to which everyone constantly goes back if delicate questions or conflicting interpretations arise during the development process. Requirements The practical requirements on the analysis process and supporting notations follow from the above list of goals:

904 OBJECT-ORIENTED ANALYSIS §27.1 If analysis is being applied to a non-software system, or independently of a decision to build a software system, A1, A2 and A3 may be the only relevant goals. For a software system, the list assumes that analysis follows a stage of feasibility study which has resulted in a decision to build a system. If, as sometimes happens, the two stages are merged into one (not an absurd proposition, since you may need an in-depth analysis to determine whether a satisfactory result is conceivable), the list needs another item: A0, deciding whether to build a system. Although related, the goals listed are distinct, prompting us in the rest of this chapter to look for a set of complementary techniques; what is good for one of the goals may be irrelevant to another. Goals A2 and A3 are the least well covered in the analysis literature and deserve all the emphasis they can get. One of the primary benefits of an analysis process, independently of any document that it produces in the end, is that it leads you to ask the relevant questions (A2): what is the maximum acceptable temperature? What are the recognized categories of employees? How are bonds handled differently from stocks? By providing you with a framework, which you will have to fill using input from people competent in the application domain, an analysis method will help spot and remove obscurities and ambiguities which can be fatal to a development. Nothing is worse than discovering, at the last stage of implementation, that the marketing and engineering departments of the client company have irreconcilable views of what equipment maintenance means, that one of these views was taken by default, and that no one cared to check what the actual order giver had in mind. As to A3, a good analysis document will be the place to which everyone constantly goes back if delicate questions or conflicting interpretations arise during the development process. Requirements The practical requirements on the analysis process and supporting notations follow from the above list of goals: Goals of performing analysis A1 • To understand the problem or problems that the eventual software system, if any, should solve. A2 • To prompt relevant questions about the problem and the system. A3 • To provide a basis for answering questions about specific properties of the problem and system. A4 • To decide what the system should do. A5 • To decide what the system should not do. A6 • To ascertain that the system will satisfy the needs of its users, and define acceptance criteria (especially when the system is developed for an outside customer under a contractual relationship). A7 • To provide a basis for the development of the system

$27.1 THE GOALS OF ANALYSIS 905 There must be a way to let non-software people contribute input to the analysis, exam ine the results and discuss them (A1,A2). The analysis must also have a form that is directly usable by software developers(A7) The approach must scale up (A1). The analysis notation must be able to express precise properties unambiguously(A3). It must enable readers to get a quick glimpse of the overall organization of a system or subsystem (A1,A7) Scaling up(the third point)means catering to systems that are complex,large or both -the ones for which you most need analysis.The method should enable you to describe the high-level structure of the problem or system,and to organize the description over several layers of abstraction,so that you can at any time focus on as big or as small a part of the system as you wish,while retaining the overall picture.Here,of course,the structuring and abstracting facilities of object technology will be precious. Scaling up also means that the criteria of extendibility and reusability,which have guided much of our earlier discussions,are just as applicable to analysis as they are to software design and implementation.Systems change,requiring their descriptions to follow;and systems are similar to previous systems,prompting us to use libraries of specification elements to build their specifications,just as we use libraries of software components to build their implementations. The clouds and the precipice It is not easy to reconcile the last two requirements of the above list.The conflict,already discussed in the context of abstract data types,has plagued analysis methods and specification languages as long as they have existed.How do you "express precise properties unambiguously"without saying too much?How do you provide readable broad-brush structural descriptions without risking vagueness? The analyst walks on a mountain path.On your left is the mountain top,deep ensconced in clouds;this is the realm of the fuzzy.But you must also stay away,on your right,from the precipice of overspecification,to which you might be perilously drawn if your attempts to be precise tempt you to say too much,especially by giving out implementation details instead of external properties of the system. The risk of overspecification is ever present in the minds of people interested in analysis.(It is said that,to gain the upper hand in a debate in this field,you should try "Approach X is nice,but isn't it a tad implementation-oriented?"The poor author of reputation lost,career shattered,will not dare show up in a software gathering for the next twenty years.)To avoid this pitfall,analysis methods have tended to err on the side of the clouds,relying on formalisms that do a good job of capturing overall structures, often through cloud-like graphical notations,but are quite limited when it comes to expressing the semantic properties of systems as required to address goal A2(answering precise questions)

§27.1 THE GOALS OF ANALYSIS 905 • There must be a way to let non-software people contribute input to the analysis, examine the results and discuss them (A1, A2). • The analysis must also have a form that is directly usable by software developers (A7). • The approach must scale up (A1). • The analysis notation must be able to express precise properties unambiguously (A3). • It must enable readers to get a quick glimpse of the overall organization of a system or subsystem (A1, A7) Scaling up (the third point) means catering to systems that are complex, large or both — the ones for which you most need analysis. The method should enable you to describe the high-level structure of the problem or system, and to organize the description over several layers of abstraction, so that you can at any time focus on as big or as small a part of the system as you wish, while retaining the overall picture. Here, of course, the structuring and abstracting facilities of object technology will be precious. Scaling up also means that the criteria of extendibility and reusability, which have guided much of our earlier discussions, are just as applicable to analysis as they are to software design and implementation. Systems change, requiring their descriptions to follow; and systems are similar to previous systems, prompting us to use libraries of specification elements to build their specifications, just as we use libraries of software components to build their implementations. The clouds and the precipice It is not easy to reconcile the last two requirements of the above list. The conflict, already discussed in the context of abstract data types, has plagued analysis methods and specification languages as long as they have existed. How do you “express precise properties unambiguously” without saying too much? How do you provide readable broad-brush structural descriptions without risking vagueness? The analyst walks on a mountain path. On your left is the mountain top, deep ensconced in clouds; this is the realm of the fuzzy. But you must also stay away, on your right, from the precipice of overspecification, to which you might be perilously drawn if your attempts to be precise tempt you to say too much, especially by giving out implementation details instead of external properties of the system. The risk of overspecification is ever present in the minds of people interested in analysis. (It is said that, to gain the upper hand in a debate in this field, you should try “Approach X is nice, but isn’t it a tad implementation-oriented ?” The poor author of X, reputation lost, career shattered, will not dare show up in a software gathering for the next twenty years.) To avoid this pitfall, analysis methods have tended to err on the side of the clouds, relying on formalisms that do a good job of capturing overall structures, often through cloud-like graphical notations, but are quite limited when it comes to expressing the semantic properties of systems as required to address goal A2 (answering precise questions)

906 OBJECT-ORIENTED ANALYSIS $27.2 Many of the traditional analysis methods fit this description.Their success comes from their ability to list the components of a system and describe their relations graphically,making them the software equivalent of the block diagrams of other engineering disciplines.But they are not too good at capturing the semantics.For software projects this carries a risk:believing that you have completed a successful analysis when all you have really done is to define the major components and their relations,leaving out many deeper properties of the specification that may turn out to be critical. Later in this chapter we will study ideas for reconciling the goals of structural description and semantic precision. 27.2 THE CHANGING NATURE OF ANALYSIS Although the object-oriented analysis literature hardly mentions this point,the most significant contribution of object technology to analysis is not technical but organizational.Object technology does not just provide new ways of doing analysis;it affects the very nature of the task and its role in the software process. This change follows from the method's emphasis on reusability.If instead of assuming that every new project must start from scratch,considering the customer's requirements as the Gospel,we bring into the picture the presence of a regularly growing repertory of software components,some obtained (or obtainable)from the outside and some developed as a result of in-house projects,the process becomes different:not the execution of an order from above,but a negotiation Customer Requirements analysis as a negotiation Compromise) Developer B The figure suggests this process:the customer starts with a requirement at A;you counter with a proposal at B,covering perhaps only part of the requirements,or a slightly different form of the requirements,but based for a large part on existing reusable components and hence achievable at significantly less cost and sooner.The customer may initially find the sacrifice of functionality too large;this opens a haggling phase which should eventually lead to an acceptable compromise. The haggling has always been there,of course.The customer's requirements were the Gospel only in some descriptions of the "software process"in the software engineering literature,presenting an ideal view for pedagogical purposes,and perhaps in some government contracts.In most normal situations,the developers had some freedom to discuss requirements.But with the advent of object technology this officious phenomenon becomes an official part of the software development process,and gains new prominence with the development of reusable libraries

906 OBJECT-ORIENTED ANALYSIS §27.2 Many of the traditional analysis methods fit this description. Their success comes from their ability to list the components of a system and describe their relations graphically, making them the software equivalent of the block diagrams of other engineering disciplines. But they are not too good at capturing the semantics. For software projects this carries a risk: believing that you have completed a successful analysis when all you have really done is to define the major components and their relations, leaving out many deeper properties of the specification that may turn out to be critical. Later in this chapter we will study ideas for reconciling the goals of structural description and semantic precision. 27.2 THE CHANGING NATURE OF ANALYSIS Although the object-oriented analysis literature hardly mentions this point, the most significant contribution of object technology to analysis is not technical but organizational. Object technology does not just provide new ways of doing analysis; it affects the very nature of the task and its role in the software process. This change follows from the method’s emphasis on reusability. If instead of assuming that every new project must start from scratch, considering the customer’s requirements as the Gospel, we bring into the picture the presence of a regularly growing repertory of software components, some obtained (or obtainable) from the outside and some developed as a result of in-house projects, the process becomes different: not the execution of an order from above, but a negotiation. The figure suggests this process: the customer starts with a requirement at A; you counter with a proposal at B, covering perhaps only part of the requirements, or a slightly different form of the requirements, but based for a large part on existing reusable components and hence achievable at significantly less cost and sooner. The customer may initially find the sacrifice of functionality too large; this opens a haggling phase which should eventually lead to an acceptable compromise. The haggling has always been there, of course. The customer’s requirements were the Gospel only in some descriptions of the “software process” in the software engineering literature, presenting an ideal view for pedagogical purposes, and perhaps in some government contracts. In most normal situations, the developers had some freedom to discuss requirements. But with the advent of object technology this officious phenomenon becomes an official part of the software development process, and gains new prominence with the development of reusable libraries. Requirements analysis as a negotiation Customer Developer A B (Compromise)

$27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY 907 27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY Object technology also affects,of course,the techniques of analysis. Here the most important thing to learn is that we have almost nothing to learn.The framework defined in the preceding chapters has more than enough to get us started with modeling."More than enough"actually means too much:the notation includes an operational part,made of two components which we do not need for analysis: Instructions (assignments,loops,procedure calls,...)and all that goes with them Routine bodies of the do form (but we do need deferred routines to specify operations without giving out their implementation). If we ignore these imperative elements,we have a powerful system modeling method and notation.In particular: Classes will enable us to organize our system descriptions around object types,in the broad sense of the word"object"defined in preceding chapters (covering not just physical objects but also important concepts of the application domain). The ADT approach-the idea of characterizing objects by the applicable operations and their properties-yields clear,abstract,evolutionary specifications. To capture inter-component relations,the two basic mechanisms of "client"and inheritance are appropriate.The client relation,in particular,covers such information modeling concepts as"part of,association and aggregation. As we saw in the discussion of objects,the distinction between reference and expanded clients corresponds to the two basic kinds of modeling association. Inheritance-single,multiple and repeated-addresses classification.Even such seemingly specialized inheritance mechanisms as renaming will be precious to model analysis concepts. Assertions are essential to capture what was called above the semantics of systems: properties other than structural.Design by Contract is a powerful guide to analysis. Libraries of reusable classes will provide us-especially through their higher-level deferred classes-with ready-made specification elements. This does not necessarily mean that the approach seen so far covers all the needs of system analysis (a question that will be discussed further below);but it certainly provides the right basis.The following example will provide some evidence. 27.4 PROGRAMMING A TV STATION Let us see concretely how to apply the O-O concepts that we know to pure modeling The example involves organizing the schedule of a television station.Because it is drawn from a familiar application area,we can start it(although we most likely could not complete it)without the benefit of input from"domain experts",future users etc.;we can just,for the analysis exercise,rely on every layperson's understanding of TV. Although the effort may be the prelude to the construction of a computerized system to manage the station's programming automatically,this possibility is neither certain nor relevant here;we are just interested in modeling

§27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY 907 27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY Object technology also affects, of course, the techniques of analysis. Here the most important thing to learn is that we have almost nothing to learn. The framework defined in the preceding chapters has more than enough to get us started with modeling. “More than enough” actually means too much: the notation includes an operational part, made of two components which we do not need for analysis: • Instructions (assignments, loops, procedure calls, …) and all that goes with them. • Routine bodies of the do form (but we do need deferred routines to specify operations without giving out their implementation). If we ignore these imperative elements, we have a powerful system modeling method and notation. In particular: • Classes will enable us to organize our system descriptions around object types, in the broad sense of the word “object” defined in preceding chapters (covering not just physical objects but also important concepts of the application domain). • The ADT approach — the idea of characterizing objects by the applicable operations and their properties — yields clear, abstract, evolutionary specifications. • To capture inter-component relations, the two basic mechanisms of “client” and inheritance are appropriate. The client relation, in particular, covers such information modeling concepts as “part of”, association and aggregation. • As we saw in the discussion of objects, the distinction between reference and expanded clients corresponds to the two basic kinds of modeling association. • Inheritance — single, multiple and repeated — addresses classification. Even such seemingly specialized inheritance mechanisms as renaming will be precious to model analysis concepts. • Assertions are essential to capture what was called above the semantics of systems: properties other than structural. Design by Contract is a powerful guide to analysis. • Libraries of reusable classes will provide us — especially through their higher-level deferred classes — with ready-made specification elements. This does not necessarily mean that the approach seen so far covers all the needs of system analysis (a question that will be discussed further below); but it certainly provides the right basis. The following example will provide some evidence. 27.4 PROGRAMMING A TV STATION Let us see concretely how to apply the O-O concepts that we know to pure modeling. The example involves organizing the schedule of a television station. Because it is drawn from a familiar application area, we can start it (although we most likely could not complete it) without the benefit of input from “domain experts”, future users etc.; we can just, for the analysis exercise, rely on every layperson’s understanding of TV. Although the effort may be the prelude to the construction of a computerized system to manage the station’s programming automatically, this possibility is neither certain nor relevant here; we are just interested in modeling

$27.4 PROGRAMMING A TV STATION 909 See“Using asser- Note the use of deferred bodies.This is appropriate since by nature an analysis tions for documen- document is implementation-independent and even design-independent;having no body, tation:the short form of a class". deferred features are the proper tool.You could,of course,dispense with writing the page 389. deferred specification and instead use a formalism such as that of short forms.But two important arguments justify using the full notation: By writing texts that conform to the syntax of the software notation,you can make use of all the tools of the supporting software development environment.In particular,the compiling mechanism will double up as a precious CASE(computer- aided software engineering)tool,applying type rules and other validity constraints to check the consistency of your specifications and detect contradictions and ambiguities;and the browsing and documentation facilities of a good O-O environment will be as useful for analysis as they are for design and implementation. Using the software notation also means that,should you decide to proceed to the design and implementation of a software system,you will be able to follow a smooth transition path;your work will be to add new classes,effective versions of the deferred features and new features.This supports the seamlessness of the approach, discussed in the next chapter. The class assumes a boolean query in fiture on objects of type DATE;it only allows setting air time for future dates.Note our first use of a precondition and postcondition to express semantic properties of a system during analysis. Segments Rather than continuing to refine and enhance SCHEDULE,let us at this stage switch to the notion of SEGMENT.We can start with the following features: indexing description:"Individual fragments of a broadcasting schedule" deferred class SEGMENT feature schedule:SCHEDULE is deferred end --Schedule to which segment belongs index:INTEGER is deferred end --Position of segment in its schedule starting time,ending time:INTEGER is deferred end --Beginning and end of scheduled air time next:SEGMENT is deferred end --Segment to be played next,if any sponsor:COMPANY is deferred end --Segment's principal sponsor

§27.4 PROGRAMMING A TV STATION 909 Note the use of deferred bodies. This is appropriate since by nature an analysis document is implementation-independent and even design-independent; having no body, deferred features are the proper tool. You could, of course, dispense with writing the deferred specification and instead use a formalism such as that of short forms. But two important arguments justify using the full notation: • By writing texts that conform to the syntax of the software notation, you can make use of all the tools of the supporting software development environment. In particular, the compiling mechanism will double up as a precious CASE (computeraided software engineering) tool, applying type rules and other validity constraints to check the consistency of your specifications and detect contradictions and ambiguities; and the browsing and documentation facilities of a good O-O environment will be as useful for analysis as they are for design and implementation. • Using the software notation also means that, should you decide to proceed to the design and implementation of a software system, you will be able to follow a smooth transition path; your work will be to add new classes, effective versions of the deferred features and new features. This supports the seamlessness of the approach, discussed in the next chapter. The class assumes a boolean query in_future on objects of type DATE; it only allows setting air time for future dates. Note our first use of a precondition and postcondition to express semantic properties of a system during analysis. Segments Rather than continuing to refine and enhance SCHEDULE, let us at this stage switch to the notion of SEGMENT. We can start with the following features: indexing description: "Individual fragments of a broadcasting schedule" deferred class SEGMENT feature schedule: SCHEDULE is deferred end -- Schedule to which segment belongs index: INTEGER is deferred end -- Position of segment in its schedule starting_time, ending_time: INTEGER is deferred end -- Beginning and end of scheduled air time next: SEGMENT is deferred end -- Segment to be played next, if any sponsor: COMPANY is deferred end -- Segment’s principal sponsor See “Using assertions for documentation: the short form of a class”, page 389

910 OBJECT-ORIENTED ANALYSIS $27.4 rating:INTEGER is deferred end Segment's rating (for children's viewing etc. ..Commands such as change next,set sponsor,set rating omitted... Minimum duration:INTEGER is 30 --Minimum length of segments,in seconds Maximum interval:INTEGER is 2 --Maximum time between two successive segments,in seconds invariant in list:(I =0 positive times:(starting time>0)and (ending time>0) sufficient_duration:ending_time-starting time >Minimum duration decent interval:(next.starting time)-ending time <Maximum_interval end Each segment"knows"the schedule of which it is a part,expressed by the query schedule,and its position in that schedule,expressed by index.It has a startingtime and an ending time;we could also add a query duration,with an invariant clause expressing its relation to the previous two.Redundancy is acceptable in system analysis provided redundant features express concepts of interest to users or developers,and the relations between redundant elements are stated clearly through the invariant.Here,clauses in list and in schedule of the invariant express the relation between a segment's own index and its position in the schedule's list of segments. A segment also knows about the segment that will follow,next.Invariant clauses again express the consistency requirements:clause next in list indicates that if the segment is at position i the next one is at position i+/;clause no next iff last,that there is a next if and only if the segment is not the last in its schedule. The last two invariant clauses express constraints on durations:sufficient duration defines a minimum duration of 30 seconds for a program fragment to deserve being called a segment,and decent interval a maximum of two seconds for the time between two successive segments (when the TV screen may go blank). The class specification has taken two shortcuts that would almost certainly have to be removed at the next iteration of the analysis process.First,times and durations have been expressed as integers,measured in seconds;this is not abstract enough,and we should be able to rely on library classes DATE,TIME and DURAT/ON.Second,the notion of SEGMENT covers two separate notions:a TV program fragment,which can be defined independently of its scheduling time;and the scheduling of a certain program at a certain time slot.To separate these two notions is easy;just add to SEGMENT an attribute content:PROGRAM FRAGMENT

910 OBJECT-ORIENTED ANALYSIS §27.4 rating: INTEGER is deferred end -- Segment’s rating (for children’s viewing etc.) … Commands such as change_next, set_sponsor, set_rating omitted … Minimum_duration: INTEGER is 30 -- Minimum length of segments, in seconds Maximum_interval: INTEGER is 2 -- Maximum time between two successive segments, in seconds invariant in_list: (1 = 0 positive times: (starting_time > 0) and (ending_time > 0) sufficient_duration: ending_time – starting_time >= Minimum_duration decent_interval: (next ● starting_time) – ending_time <= Maximum_interval end Each segment “knows” the schedule of which it is a part, expressed by the query schedule, and its position in that schedule, expressed by index. It has a starting_time and an ending_time; we could also add a query duration, with an invariant clause expressing its relation to the previous two. Redundancy is acceptable in system analysis provided redundant features express concepts of interest to users or developers, and the relations between redundant elements are stated clearly through the invariant. Here, clauses in_list and in_schedule of the invariant express the relation between a segment’s own index and its position in the schedule’s list of segments. A segment also knows about the segment that will follow, next. Invariant clauses again express the consistency requirements: clause next_in_list indicates that if the segment is at position i the next one is at position i +1; clause no_next_iff_last, that there is a next if and only if the segment is not the last in its schedule. The last two invariant clauses express constraints on durations: sufficient_duration defines a minimum duration of 30 seconds for a program fragment to deserve being called a segment, and decent_interval a maximum of two seconds for the time between two successive segments (when the TV screen may go blank). The class specification has taken two shortcuts that would almost certainly have to be removed at the next iteration of the analysis process. First, times and durations have been expressed as integers, measured in seconds; this is not abstract enough, and we should be able to rely on library classes DATE, TIME and DURATION. Second, the notion of SEGMENT covers two separate notions: a TV program fragment, which can be defined independently of its scheduling time; and the scheduling of a certain program at a certain time slot. To separate these two notions is easy; just add to SEGMENT an attribute content: PROGRAM_FRAGMENT

§27.4 PROGRAMMING A TV STATION 911 with a new class PROGRAM_FRAGMENT describing the content independently of its scheduling. Feature duration should then appear in PROGRAM_FRAGMENT, and a new invariant clause of SEGMENT should state content ● duration = ending_time – starting_time For brevity the rest of this sketch continues to treat the content as part of the segment. Such discussions are typical of what goes on during the analysis process, aided by the object-oriented method: we examine various abstractions, discuss whether they justify different classes, move features to other classes if we think they have been misassigned. A segment has a primary sponsor, and a rating. Although here too we might benefit from a separate class, rating has just been specified as an integer, with the convention that a higher rating implies more restrictions; 0 means a segment accessible to all audiences. Programs and commercials Probing the notion of SEGMENT further, we distinguish two kinds: program segments and commercial breaks (advertizing segments). This immediately suggests using inheritance: This urge to use inheritance during analysis, by the way, is always suspect; you should be wary of bouts of taxomania, prompting you to create spurious classes where simple distinctive properties would suffice. The guiding criterion was given in the description of inheritance: does each proposed class really correspond to a separate abstraction, characterized by specific features and properties? Here the answer will be yes; it is not difficult to think of features for both programs and commercials, as will be listed in part below. Using inheritance will also yield the benefit of openness: we can add a new heir such as INFOMERCIAL later to describe segments of a different kind. We can start COMMERCIAL as follows: indexing description: "Advertizing segment" deferred class COMMERCIAL inherit SEGMENT rename sponsor as advertizer end PROGRAM SEGMENT COMMERCIAL See “TAXOMANIA”, 24.4, page 820

912 OBJECT-ORIENTED ANALYSIS $27.4 feature primary:PROGRAM is deferred --Program to which this commercial is attached primary index:INTEGER is deferred --Index of primary set_primary (p:PROGRAM)is --Attach commercial to p. require program_exists:p/=Void same schedule:p.schedule schedule before:p.starting_time <starting_time deferred ensure index updated:primary index=p.index primary updated:primary p end invariant meaningful primary index:primary_index =primary.index primary before:primary.starting_time <starting time acceptable sponsor:advertizer.compatible (primary.sponsor) acceptable rating:rating <primary.rating end Note the use of renaming,another example of a notational facility that at first sight might have appeared to be useful mostly for implementation-level classes,but turns out to be just as necessary for modeling.When a segment is a commercial,it is more appropriate to refer to its sponsor as being its advertizer. Every commercial segment is attached to an earlier program segment (not a commercial),its primary,whose index in the schedule is primary index.The first two invariant clauses express consistency conditions;the last two express compatibility rules: If a show has a sponsor,any advertizer during that show must be acceptable to it;you do not advertize for Pepsi-Cola during a show sponsored by Coca-Cola.The query compatible of class COMPANY might be given through some database. The rating of a commercial must be compatible with that of its primary program:you should not advertize for Bulldozer Massacre Ill on a toddlers'program. The notion of primary needs refinement.It becomes clear at this stage of our analysis that we should really add a level:instead of a schedule being a succession of program segments and commercials,we should view it as a succession of shows,where each show (described by a class SHOW)has its own features,such as the show's sponsor,and a succession of show segments and commercials.Such improvement and refinement, developed as we gain more insight into the problem and learn from our first attempts,are a normal component of the analysis process

912 OBJECT-ORIENTED ANALYSIS §27.4 feature primary: PROGRAM is deferred -- Program to which this commercial is attached primary_index: INTEGER is deferred -- Index of primary set_primary (p: PROGRAM) is -- Attach commercial to p. require program_exists: p /= Void same_schedule: p ● schedule = schedule before: p ● starting_time <= starting_time deferred ensure index_updated: primary_index = p ● index primary_updated: primary = p end invariant meaningful_primary_index: primary_index = primary ● index primary_before: primary ● starting_time <= starting_time acceptable_sponsor: advertizer ● compatible (primary ● sponsor) acceptable_rating: rating <= primary ● rating end Note the use of renaming, another example of a notational facility that at first sight might have appeared to be useful mostly for implementation-level classes, but turns out to be just as necessary for modeling. When a segment is a commercial, it is more appropriate to refer to its sponsor as being its advertizer. Every commercial segment is attached to an earlier program segment (not a commercial), its primary, whose index in the schedule is primary_index. The first two invariant clauses express consistency conditions; the last two express compatibility rules: • If a show has a sponsor, any advertizer during that show must be acceptable to it; you do not advertize for Pepsi-Cola during a show sponsored by Coca-Cola. The query compatible of class COMPANY might be given through some database. • The rating of a commercial must be compatible with that of its primary program: you should not advertize for Bulldozer Massacre III on a toddlers’ program. The notion of primary needs refinement. It becomes clear at this stage of our analysis that we should really add a level: instead of a schedule being a succession of program segments and commercials, we should view it as a succession of shows, where each show (described by a class SHOW) has its own features, such as the show’s sponsor, and a succession of show segments and commercials. Such improvement and refinement, developed as we gain more insight into the problem and learn from our first attempts, are a normal component of the analysis process