6.170 / Spring 2001 / Lecture 15 Card Answers

Handout L15-QA

Question: If a loop throws an exception or returns a value during execution, can this be considered both:

• abnormal termination, for the purposes of proving partial correctness...
• and yet still "clean" termination (as opposed to crashing or infinite loop) for purposes of proving eventual termination?

A RuntimeException that is not in the specification would fall under the category of "abnormal termination" (i.e., a crash). An Exception that is in the specification should be considered part of the specified behavior and thus something we want to reason about in terms of partial correctness.

In practice, what you will probably want to do is desugar returning the value or throwing the exception into some other form that is more palatable to the reasoning framework. For example,

while(b) { 
   if (!c) 
       return 0; 
   else 
       f(); 
} 
return 1; 

while(b && c) { 
   f(); 
} 
if(!c) 
    return 0; 
return 1; 

Question: Can you explain !, ? and * more?
Answer: Those three symbols are short-hands for descriptions of the allowed multiplicities.

Symbol	Interpretation
* (default)	Zero or more
?	Zero or One
+	One or more
!	Exactly One

Many of these symbols were chosen because of their history of being used for denoting corresponding multiplicities in regular expressions, which may be helpful to know if you have a background programming in Perl or other languages that use regular expressions.

For further explanation of what these multiplicities mean, see the next question.

Question: Can you explain multiplicity relations, especially the difference between markings at head vs tail of arrow?
Answer: The relations themselves are not multiplicities; the multiplicity annotations represent constraints on the relations. They document the boundaries in the space of possible states of the system.

Adding a multiplicity annotation to the target of a relation (that is, to the head of an arrow) constrains how many elements of the target set can be mapped to by any particular element of the source set. Thus, the following diagram says that any particular Person has exactly one date of birth, and at most one day that he or she got their first car (since the person may have never owned a car).

Adding a multiplicity annotation to the source of a relation (that is, to the tail of the arrow) constrains how many elements of the source set can map to any particular element of the target set. In the above example, many people can share the same birthday, and at the same time, there is no guarantee that some person will actually HAVE a given birthday. So the notation we add to the date-of-birth relation is a *, (zero or more), which is really no constraint at all. A similar argument holds for the day-received-first-car relation.

As another example of putting multiplicity constraints on the source end of a relation, the following Object Model illustrates the mother-child relationship. Every person has a mother; thus there is a ! on the source end of the child relationship. But each woman might have many children, or might not have any children; thus we annotate the target end of the has-child relation with a *.

Question: Please explain

Answer: These are annotations for mutability and multiplicity on sets.

A single vertical bar on the left indicates that the set is static; that is, the objects in the set remain in that set for the extent of their existance. The contents of the set can change; over time, new objects may come into existance, and old ones can die. An example use of this is in an elaboration of the earlier mother-child diagram: presuming that the sex of a given person is fixed for all time, then it would be sensible to declare the set of Woman as being static, as follows:

Two vertical bars on either side of the set indicate that the set is fixed; the contents of the set do not change throughout the lifetime of the system. This would not be an appropriate annotation to put on our Woman domain in the above example, since women can die and be born in the world. An approriate place to use such an annotation might be "Streets in Cambridge" or "Planets in the Milky Way", depending on the intended usage and lifetime of the system you are designing.

A ! next to the name of a set indicates the set will have exactly one element throughout the lifetime of the system. More generally, any multiplicity marking next to the name of a set introduces a constraint on the cardinality of that set; a + would indicate that the set always has at least one element, a ? would indicate that the set has at most one element, and so on.

Question: On Slide 13, you said that a list had to have one entry. I don't understand how the diagram shows this, since there is a ? at the tail of the header relation.
Answer: Remember the annotations on the tail of a relation introduce constraints on how many elements of the source domain map to any particular element of the target domain.

To see that a list has to have one entry, look at the ! on the target of the header relation. This tells us that every list has exactly one header Entry object.

So what does the ? on the source of the header relation mean then? Well, header is relating all pairs of the form (List, Entry). Thus, the ? is saying "for every Entry, there is at most one List that is using that Entry as a header." This tells us that two Lists will not share a single Entry as a header. But why is it a ? and not a ! then? Because not every Entry is a header itself; notatably, all of the Entries besides the header in a given List will probably not have a List using them as their header.

Question: What is the difference between code object model and problem object model?
Answer: A code object model is a tool to document and to understand the relationships between objects on the Java heap. It is an attempt to concisely describe the possible states the Java heap may take.

A problem object model is similar, except instead of talking about objects on the Java heap, it is relating objects in the real world. This is very useful at the very beginning of developing a design, when you're still trying to understand the problem that you are attempting to solve. Thus, if you were trying to write a recipe database, you might define domains for the recipes themselves, the ingredients, the tools you need to carry out the instructions in the recipe, the style of cuisine of the dish, etc. In the code you later write for this system, you may or may not actually introduce an Ingredient class or a CookingTool class; those choices are irrelevant when you are first working on understanding the requirements of the system you are going to build.