908 OBJECT-ORIENTED ANALYSIS $27.4 Schedules We concentrate on the schedule for a 24-hour period;the class (data abstraction) SCHEDULE presents itself.A schedule contains a sequence of individual program segments;let us start with class SCHEDULE feature segments:LIST [SEGMENT] end When doing analysis we must constantly watch ourselves for fear of lapsing into overspecification.Is it overspecifying to use a L/ST?No:L/ST is a deferred class, describing the abstract notion of sequence;and television programming is indeed sequential,since one cannot broadcast two segments on the same station at the same time. By using L/ST we capture a property of the problem,not the solution. Note in passing the importance of reusability:by using classes such as L/ST you immediately gain access to a whole set of features describing list operations:commands such as put for adding elements,queries such as the number ofelements cout.Reusability is as central to object-oriented analysis as it is to other O-O tasks. What would be overspecifying here would be to equate the notion of schedule with See“More on that of list of segments.Object technology,as you will remember from the discussion of implicitess",page abstract data types,is implicit;it describes abstractions by listing their properties.Here 149. there will certainly be more to a schedule than the list of its segments,so we need a separate class.Some of the other features of a schedule present themselves naturally: indexing description:"Twenty-four hour TV schedules" deferred class SCHEDULE feature segments:LIST [SEGMENT]is --The successive segments deferred end air time:DATE is --Twenty-four hour period for this schedule deferred end set air time (t:DATE)is --Assign this schedule to be broadcast at time t. require t.in future deferred ensure air time =t end print is --Print paper version of schedule. deferred end end
908 OBJECT-ORIENTED ANALYSIS §27.4 Schedules We concentrate on the schedule for a 24-hour period; the class (data abstraction) SCHEDULE presents itself. A schedule contains a sequence of individual program segments; let us start with class SCHEDULE feature segments: LIST [SEGMENT] end When doing analysis we must constantly watch ourselves for fear of lapsing into overspecification. Is it overspecifying to use a LIST? No: LIST is a deferred class, describing the abstract notion of sequence; and television programming is indeed sequential, since one cannot broadcast two segments on the same station at the same time. By using LIST we capture a property of the problem, not the solution. Note in passing the importance of reusability: by using classes such as LIST you immediately gain access to a whole set of features describing list operations: commands such as put for adding elements, queries such as the number of elements count. Reusability is as central to object-oriented analysis as it is to other O-O tasks. What would be overspecifying here would be to equate the notion of schedule with that of list of segments. Object technology, as you will remember from the discussion of abstract data types, is implicit; it describes abstractions by listing their properties. Here there will certainly be more to a schedule than the list of its segments, so we need a separate class. Some of the other features of a schedule present themselves naturally: indexing description: "Twenty-four hour TV schedules" deferred class SCHEDULE feature segments: LIST [SEGMENT] is -- The successive segments deferred end air_time: DATE is -- Twenty-four hour period for this schedule deferred end set_air_time (t: DATE) is -- Assign this schedule to be broadcast at time t. require t ● in_future deferred ensure air_time = t end print is -- Print paper version of schedule. deferred end end See “More on implicitness”, page 149
$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