In the game of bowling, a player, called a bowler, throws a heavy ball down a long, narrow lane at the end of which stand ten wooden pins (in a triangular configuration). The bowler's goal is to knock down all ten pins. If she succeeds in a single throw, she is said to have made a strike. If, after her first throw, one or more pins are left standing, she throws the ball again in an attempt to knock down the standing pins. If she succeeds, she is said to have made a spare. In any case, after throwing two balls (or only one, if it resulted in a strike), the bowler is said to have played a frame. If pins remain standing after the bowler has played a frame, the frame is said to be open.
A game of bowling consists of between ten and twelve frames.1 To calculate a player's score for a game, we award a certain number of pins for each of the first ten frames, according to the rules below.2
Given these scoring rules, it is clear why it makes sense to say that a game consists of "between ten and twelve" frames:
Accessible via the links below are several Ada program units:
You are to supply the missing package bodies of Bowling_Frames and Bowling_Games. It is not really recommended, but, if you wish, you may modify the private parts of the specifications of these two packages, where the details of data type representations are given.3 You may not modify the non-private parts of those package specifications, however. The Kegler_Kings_Bowlers package and Bowling_Program are simply for the purpose of testing the Bowling_Frames and Bowling_Games packages that you are to complete.
The purpose of a package specification is to define an interface through which the package's clients request the services of that package. The purpose of a package body is to provide an implementation of the services offered by the package. That is, the package's specification tells WHAT services it offers and its body tells HOW those services are provided. (For this to be entirely accurate, we would have to move the private part of the package's specification into its body. As mentioned in a footnote, technical reasons led to it not being done this way.)
Suppose that program unit A is a client of package B. Then only those data types, data objects, subprograms, and exceptions that are mentioned in the (non-private part of the) specification of B are "visible" to A.
Compare the specification and body of the Kegler_Kings_Bowler package. Notice that, for every subprogram declared in the specification, the body contains a copy of that declaration (in which the names, types, and modes (e.g., in out) of the formal parameters are the same), plus the subprogram's local declarations and body. (Notice that the word is appears in the package body (instead of the semicolon appearing in the package specification) immediately after the subprogram's heading.
A package body may include data types, data objects, and subprograms that are not mentioned in the corresponding specification (and therefore are not visible to clients of the package). Such entities are for the purpose, directly or indirectly, of implementing the services provided by the package.
Suppose that package A is a client of B. It could be that the specification of A includes the context clause "with B". (For example, the specification of Bowling_Games indicates that it is a client of Bowling_Frames. This is necessary, because one of the functions visible to clients of Bowling_Games returns as its result an object of type Frame_Type, which comes from the Bowling_Frames package.) In this case, the body of A need not explicitly indicate, via the context clause "with B", that it is a client of B. (This explains why the body of Bowling_Games fails to include a context clause mentioning Bowling_Frames.)
On the other hand, it could be that the body of a package A needs to use services provided by B, but that its specification does not. In that case, the body of A, but not its specification, should include the context clause "with B". For an example of this, notice that the body of Kegler_Kings_Bowler makes use of Bowling_Frames but that its specification does not.
1The standard description says that a game is comprised of ten frames, but, from the point of view of creating a computer simulation, it is useful to talk of an 11th and 12th frame.
2We see, then, that the term pins refers not only to the objects that the bowler attempts to knock down but also to the unit of scoring. Which of the two meanings is intended for a particular use of the term should be clear from context.
3Recall that,
for practical reasons having to do with the development of compilers,
the designers of Ada decided that such information should be placed
into a "private" section within the package specification,
even though, from a conceptual point of view, this information belongs
in the package body.