Understanding Object-Oriented Design Properties and Use Cases in UML - Prof. David Workman, Exams of Computer Science

Answers and explanations for various questions related to object-oriented design properties, such as procedural abstraction, data abstraction, information hiding, data encapsulation, reusability, control distribution, and their implementation in uml. It also covers the handling of abstractions and the relationship between use case diagrams and actors.

Typology: Exams

Pre 2010

Uploaded on 02/24/2010

koofers-user-yzd
koofers-user-yzd 🇺🇸

10 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1. (b) There is only one answer from the list that contains the word “spiral.” It
should be obvious I am referring to the “Spiral Model.” Knowing it is a model is
already known through the context and rewriting it seems repetitious.
Response: You only lost one point, and the directions were clear. Why didn’t
you add the word “model”?
2. (a) Listed below are the design properties directly from the notes (see Exam-
StudyGuide.ppt)
Procedural Abstraction
Data Abstraction
Information Hiding
Data Encapsulation
Reusability
Control Distribution
Procedural Abstraction is listed as one of these properties.
Response: You didn’t lose any points on this question – abstraction would have
been a better answer (included data and procedural abstraction), but you were not
penalized for your answer.
2. (b) Data Encapsulation is now implemented. Data encapsulation lends itself very
strongly to information hiding. “Encapsulation is most often achieved through
information hiding (not just data hiding), which is the process of hiding all the
secrets of an object that do not contribute to its essential characteristics…”
Further from this page “’For abstraction to work, implementations must be
encapsulated’ [53]. In practice, this means that each class must have two parts:
an interface and an implementation.” (Page 51, Booch et al)
My answer is almost identical to the answer key. One of the main benefits from
Object-Oriented design is the ability to reuse. Creating the Vector class allows
the methods and data to be reused. Using the method calls states Vector class can
be reused. Response: you deserved more credit (+2)
2 (d) Separating OO- and OO+ is how the abstractions are handled. “’For
abstraction to work, implementations must be encapsulated’” (Page 51, Booch et
al) Yes, encapsulation is very important. But this is only used as a tool to
achieve the greater significant implementation – Object Oriented design which
uses abstraction with is done by encapsulation. The Object Oriented design
allows reuse and separates the control and data. Response: you deserved more
credit (+2)
3 (b) More than one correct answer exist for this problem. The answer depends on
the point of view. My view is “Pay by Coin” as a way to “Pay For Beverage.”
As a result, paying for a beverage includes paying by coin.
Response: Your reason was correct, but the way you express this concept on
pf3

Partial preview of the text

Download Understanding Object-Oriented Design Properties and Use Cases in UML - Prof. David Workman and more Exams Computer Science in PDF only on Docsity!

1. (b) There is only one answer from the list that contains the word “spiral.” It should be obvious I am referring to the “Spiral Model.” Knowing it is a model is already known through the context and rewriting it seems repetitious. Response: You only lost one point, and the directions were clear. Why didn’t you add the word “model”? 2. (a) Listed below are the design properties directly from the notes (see Exam- StudyGuide.ppt) Procedural Abstraction Data Abstraction Information Hiding Data Encapsulation Reusability Control Distribution Procedural Abstraction is listed as one of these properties. Response: You didn’t lose any points on this question – abstraction would have been a better answer (included data and procedural abstraction), but you were not penalized for your answer.

  1. (b) Data Encapsulation is now implemented. Data encapsulation lends itself very strongly to information hiding. “Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics…” Further from this page “’For abstraction to work, implementations must be encapsulated’ [53]. In practice, this means that each class must have two parts: an interface and an implementation.” (Page 51, Booch et al) My answer is almost identical to the answer key. One of the main benefits from Object-Oriented design is the ability to reuse. Creating the Vector class allows the methods and data to be reused. Using the method calls states Vector class can be reused. Response: you deserved more credit (+2) 2 (d) Separating OO- and OO+ is how the abstractions are handled. “’For abstraction to work, implementations must be encapsulated’” (Page 51, Booch et al) Yes, encapsulation is very important. But this is only used as a tool to achieve the greater significant implementation – Object Oriented design which uses abstraction with is done by encapsulation. The Object Oriented design allows reuse and separates the control and data. Response: you deserved more credit (+2) 3 (b) More than one correct answer exist for this problem. The answer depends on the point of view. My view is “Pay by Coin” as a way to “Pay For Beverage.” As a result, paying for a beverage includes paying by coin. Response: Your reason was correct, but the way you express this concept on

a Use Case Diagram is with the Generalize/Specialize relation. Make sure you understand the UML relationships for UCDs correctly. 3 (d) More than one correct answer exist for this problem. Refilling the beverage rack can be viewed as a specific form of restocking. Response: “restocking” is a more inclusive term. Restocking clearly requires as a sub-step, the replentishing of the beverages. 4 (a) “To show which actors use which use cases, you can create a use case diagram by connecting them via basic associations , shown by lines, as in Figure 5-22” (Page 177, Booch et al) Response: You misread the question. You were to express the relationship between Use Case Diagram and Actor. This is clearly the composition relationship, because every UCD must have at least one Actor! You were modeling the relationship between Use Case and Actor. 4 (c) A dam hold back water, it contains and limits a stream of water. Response: Yes, you are correct, but a dam does not contain water (like a jug contains water). You were apply the everyday use of “contain”, not the UML meaning of “contain”. Furthermore, there should be no multiplicity annotation on water – what does it mean to say “zero or more” water? Maybe if the problem had been more explicit you might be able to say multiple “gallons of water”, but that is reading information into the problem. 4 (d) One container, the bottle, contains the beer. There exist many beer quanta in the container. Response: see my response to multiplicity in the previous problem. 5 What’s wrong with a lot of detail? I have a different interpretation. Design should not be limited to only one method. Response: You are being tested on whether or not you know how to model using Data Flow Diagrams. Answer the question that is asked. You have the read the questions more carefully. Does this diagram show I know the process and method to create a data flow diagram? “.. a notation is only a vehicle for capturing the reasoning about the behavior and architecture of a system; a notation is not an end in itself.” (Page 151, Booch et al) Booch’s comment applies to the design process in a general real-world context, not how to respond to a question on an exam. 6 More than one correct answer. My view is a Stadium contains all entities in this system. Concerning the circle around the Fan aggregation to a Ticket. “… aggregation need not require physical containment. For example, although shareholders own stocks, a shareholder does not physically contain the owned stocks. Rather, the lifetimes of these objects may be completely independent, although there is still conceptually a whole/ part relationship (each share is always a part of the