- By
**azuka** - Follow User

- 140 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' Solutions for Homework Assignment 3' - azuka

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### Solutions for Homework Assignment 3

Assignment Points: 50

Due Date: October 31, 2001

Final Date: November 7, 2001

Late Penalty: 5 points.

7.1. Consider the Polyline, Polygon, and Point classes of Figure 7-14 on page 249 in the book. Write the following constraints in OCL:

[10 Points Total]

• A Polygon is composed of a sequence of at least three Points.

[3 Points]

This is an invariant of the class Polygon which applies to all of its instances.

contextPolygon inv:

Polygon.allInstances->forAll(p:Polygon| p->points->size >= 3)

• A Polygon is composed of a sequence of Points starting and ending at the same Point.

[3 Points]

This is also an invariant that applies to all of its instances. This constraint exercises the use of sequence operators on the points association.

contextPolygon inv:

Polygon.allInstances->forAll(p:Polygon|p->points->first = p->points->last)

7.1 continued

• The Points returned by the getPoints(bbox) method of a Polygon are within the bbox rectangle.

[4 Points]

This is a post condition which applies to all the Point instances returned by the getPoints(bbox) operation.

context Polygon::getPoints(bbox) post:

result->forAll(p:Point| bbox.left <= p.x and p.x <= bbox.right and

bbox.top <= p.y and p.y <= bbox.bottom)

7.3. Consider the Point class in Figures 7-14 and 7-15 in the book. Assume that we are evaluating an alternative design in which a global object called DetailTable tracks which Points have been included or excluded from a given detail level (instead of each Point having a inDetailLevels and notInDetailLevels attribute). This is realized by two associations between DetailTable and Point, which are indexed by detailLevel (see Figure 7-34 on page 281 in the book). Write OCL constraints specifying that, given a detailLevel, a DetailTable can only have one link to a given Point (i.e., a DetailTable cannot have both an includesPoint and an excludesPoint association given a Point and detailLevel).

[10 Points]

contextDetailTable inv:

DetailTable.allInstances->forAll(t:DetailTable, detailLevel|

t->includesPoint[detailLevel]->intersection(t->excludesPoint[detailLevel])->isEmpty)

7.4. Using the transformations described in Section 7.4.8, restructure the object design model of Figure 7-34 on page 281.

[10 Points]

Section 7.4.8 explains how to realize different types of associations, including qualified associations. A correct answer to this exercise should take into account that both includesPoint and excludesPoint associations are related. This results into two private attributes and four operations as depicted in the following figure

7.6. Discuss the relative advantages of the Point class of Exercise 7.3. versus the Point class of

Figure 7-34 on page 281 from a response time and a memory space point of view.

[5 Points]

The solution with Set attributes (inDetailLevels and notInDetailLevels) can result in a slightly better response time but results in more memory overhead than the DetailTable solution.

7.8. You are the developer responsible for the getOutline() method of the Layer class in Figure 7-15 on page 250 in the book. You find that the current version of getOutline() does not properly exclude Polylines consisting of a single Point (as a result of the clipping). You repair the bug. Who should you notify?

[5 Points]

You should notify all developers who use the Layer class so that they can check if they were relying on the bug. You should also notify the testers such that they can develop a test case for exercising other methods that could have the same type of problem.

7.10. Why is maintaining consistency between the analysis model and the object design model difficult? Illustrate your point with a change to the object design model.

[10 Points]

The analysis model and the object design model are representations of the system at different levels of abstraction. Several transformations and refinements of the object design model make it difficult to trace the original analysis decisions back to the analysis model. For example, a many to many association between two classes in the analysis model may be represented with two Vector attributes and six different operations in the object design model (see Section 7.4.8 in the book). If a developer changes the multiplicity of this association in the object model (e.g., by removing one of the Vector attribute and replacing it with a simple reference), it is difficult to trace back the original association in the analysis

6.7. Why are use cases that describe boundary conditions described during system design (as opposed to during requirements elicitation or analysis)?

5 Points.

Use cases that describe boundary conditions DEPEND ON SYSTEM DESIGN DECISIONS. For example, software architecture decisions need to be made before developers can describe how the system is started or shutdown.

Download Presentation

Connecting to Server..