Homework #1 Errors

90-754 Homework #1: Criteria and Comments
30 January 1999

Sample:
A sample solution to Problem #1 is provided here. No sample is available for Problem #2, since elucidating the requirements of the client is a large part of the learning experience of this course.

Contents:
Problem #1
Problem #2

Problem 1: POST System Use Case Diagram

Criteria for grading:

Score Description

5 Understandable and clear, with only minor UML errors or omissions

4 A good start; but lacking some detail and/or readability

3 Attempted to conform to UML but lacking significantly in detail or difficult to read

1-2 Minimal effort made

0 No assignment handed in

Comments:

Number Description

1.1 You received this comment if your answer could have been more clear. Remember that the purpose of these diagrams is to describe, so whenever possible you should label your diagram with very specific words that relate to the system you are describing. For example, be careful when using words like "system", "transaction", "information", "database", "property", and "data" because they are generic and could refer to any of a number of artifacts. Instead, try to use words like "sale", "payment", "expenses", "purchase", and "price".

1.2 In a UML use case diagram's top-level diagram, the only services that should appear are those services that the system can perform that are stand-alone behaviors. In other words, it should make sense for the actor to participate in just one of the top-level use cases in isolation. If your diagram had many fine-grained top-level use cases, such as "Calculate Total" or "Give Change", note that no customer will ever need these activities to be performed in isolation (who would walk up to a clerk, demand that a total be calculated for them, and then leave?). In fact, in this assignment there were only three top-level use cases mentioned: "Log In", "Buy Items", and "Refund".

1.3 This comment indicates that your diagram uses drawing elements that are not valid UML use case diagram elements, or it uses UML use case elements in some incorrect way. Remember that using a UML-compliant CASE tool can save you from most of these errors, and a little bit of care and familiarity with the UML Specification can take you the rest of the way. If your diagram does not adhere to the UML standard but your reader is expecting a UML-compliant diagram, it may be difficult to determine what meaning you are trying to convey. Here is some more information about How to draw UML Use Case Diagrams.

1.4 A typical use case diagram will have a small number of top-level use cases that are decomposed into many sub-use cases in a separate diagram. (See 1.2, also.) Many of you attempted to represent all of the complexity of the scenario without decomposing the top-level use cases separately.

1.5 UML use case diagrams provide no way to indicate the order in which tasks should be executed, or even how many times a given task should be executed. This sort of information can only be represented by other types of diagrams (such as UML Sequence Diagrams), which we will discuss later. Keep in mind that in order to completely represent a system, you will need LOTS of different types of diagrams, so there is neither the need nor the capability to fit it all in with just one diagram type. In short, don't try to jam everything that you know about a system onto one diagram, it will just confuse the reader.

1.6 A lot of you put the "Extension Points" diagram part that appears in the UML specification in your diagrams. Actually, this was just a label on their example to help show you where use cases can be extended or added to, and is not a valid UML symbol. Please don't include it on future diagrams.

1.7 Many of you misused the "extends" edge type. For a discussion of the extends edge, please refer to this information on How to draw UML Use Case Diagrams..

1.8 This is the incomplete-ness comment. The assignment required that you provide a level of detail in your diagram that was a bit more than what was given in the lecture. We took off one, two, or three points for this, depending on the degree to which you omitted detail.

1.9 Use case ovals should always contain actions (you might also refer to them as tasks or commands) that will together be a description of what the system does. Some of you instead put entities (objects, nouns, etc) in your use case ovals. This is incorrect; representing the entities (or objects) in the system is the job of another type of diagram entirely (UML Class Diagrams), which we will discuss later.

1.10 A number of you included detail about the narrative that wasn't mentioned in the given description of the system. When constructing a real system for a client, you may need to make some decisions about system behavior that are not covered by your initial discussions with the client, and this will seem a lot like inventing detail from thin air. But it is important that before new features or functionality is added to the system, it be verified with the client first. Otherwise, you run the risk of delivering a system that is not what was asked for.

1.11 It is important to the readability of these diagrams that you adopt a consistent grammatical standard for your labels. In this homework, one good standard is to always name use cases as present-tense imperative verbs, as if the actor were saying the name of the use case as a command to the system. For example, it makes sense for the customer to say to the terminal, "Check out items" but it does not make sense for the customer to ask the system to please "Printing the receipt".

1.12 Actors cannot "use" use cases; they can only communicate with use cases (indicated by the unlabelled line connecting the actor to the use case). "Uses" is strictly an aggregation operator amongst use case ovals.

1.13 These use case diagrams must not be thought of as flow charts, data flow diagrams, or scenario descriptions. The UML Use Case diagram is a tool to represent the entire functionality of a system, to an arbitrary degree of detail, and therefore can (theoretically) capture all of the behavior of a system in a horizontal way. A flow chart or scenario description, though, can only capture one specific process in the system, and does nothing to indicate the breadth of the system's functionality. Please see How to draw UML Use Case Diagrams for a discussion of the differences between a flow chart and a Use Case Diagram.

1.14 You received this comment if your diagram was illegible. Please remember to use CASE tools that we have reccommended, or at least make some attempt to render the diagram in an intelligible way. If you feel that the diagram you've created is sloppy, overly complex, or unreadable, you may have chosen a poor method for decomposing your design, and should consider finding another way to represent the system that you are trying to describe. If you are really lost, please see the TAs for help.

1.15 An important part of the use case diagram is showing which actors can initiate and communicate with the various top-level use cases. If your diagram has no actors, there is no real way to tell how the system you are describing is to interface with the outside world.

1.16 Only the top-level Use Case Diagram need show the actors in the system. In subsequent diagrams, the actors are implied by the top-level, so there is no need to show them again (and it can make the diagram busy and crowded to include them.)

1.17 Detail breakdown diagrams that accompany the top-level diagram should show the actual oval representing the use case being detailed. Please see How to draw UML Use Case Diagrams for tips on decomposing use cases.

Back to top

Problem 2: Church System Requirements Description

Note: Since the purpose of this course is to learn how to analyze requirements and design a system based on that analysis, we will not be evaluating you on the accuracy of your analysis. Instead, you will be evaluated on the readability and clarity of your documents which present that analysis. Also, you were not penalized for incorrect use of UML in this section, since you already may have lost credit for making the same mistakes in Problem #1.

Criteria for grading:

Score Description

5 Understandable and clear; gives a good impression of the requirements

4 A good start; but lacking some detail and/or readability

3 Strange or poor organization; sometimes difficult to read

1-2 Minimal effort made

0 No assignment handed in

Comments:

Number Description

2.1 When compiling requirements information of this sort, it is usually helpful to write a short, clear, natural-language summary of what you are trying to explain so that the overall document is tied together well.

2.2 When doing group work, please submit only one copy of your final document, and ensure that all of your names are prominantly displayed on the front and top cover.

Back to top

Score	Description
5	Understandable and clear, with only minor UML errors or omissions
4	A good start; but lacking some detail and/or readability
3	Attempted to conform to UML but lacking significantly in detail or difficult to read
1-2	Minimal effort made
0	No assignment handed in

Number	Description
1.1	You received this comment if your answer could have been more clear. Remember that the purpose of these diagrams is to describe, so whenever possible you should label your diagram with very specific words that relate to the system you are describing. For example, be careful when using words like "system", "transaction", "information", "database", "property", and "data" because they are generic and could refer to any of a number of artifacts. Instead, try to use words like "sale", "payment", "expenses", "purchase", and "price".
1.2	In a UML use case diagram's top-level diagram, the only services that should appear are those services that the system can perform that are stand-alone behaviors. In other words, it should make sense for the actor to participate in just one of the top-level use cases in isolation. If your diagram had many fine-grained top-level use cases, such as "Calculate Total" or "Give Change", note that no customer will ever need these activities to be performed in isolation (who would walk up to a clerk, demand that a total be calculated for them, and then leave?). In fact, in this assignment there were only three top-level use cases mentioned: "Log In", "Buy Items", and "Refund".
1.3	This comment indicates that your diagram uses drawing elements that are not valid UML use case diagram elements, or it uses UML use case elements in some incorrect way. Remember that using a UML-compliant CASE tool can save you from most of these errors, and a little bit of care and familiarity with the UML Specification can take you the rest of the way. If your diagram does not adhere to the UML standard but your reader is expecting a UML-compliant diagram, it may be difficult to determine what meaning you are trying to convey. Here is some more information about How to draw UML Use Case Diagrams.
1.4	A typical use case diagram will have a small number of top-level use cases that are decomposed into many sub-use cases in a separate diagram. (See 1.2, also.) Many of you attempted to represent all of the complexity of the scenario without decomposing the top-level use cases separately.
1.5	UML use case diagrams provide no way to indicate the order in which tasks should be executed, or even how many times a given task should be executed. This sort of information can only be represented by other types of diagrams (such as UML Sequence Diagrams), which we will discuss later. Keep in mind that in order to completely represent a system, you will need LOTS of different types of diagrams, so there is neither the need nor the capability to fit it all in with just one diagram type. In short, don't try to jam everything that you know about a system onto one diagram, it will just confuse the reader.
1.6	A lot of you put the "Extension Points" diagram part that appears in the UML specification in your diagrams. Actually, this was just a label on their example to help show you where use cases can be extended or added to, and is not a valid UML symbol. Please don't include it on future diagrams.
1.7	Many of you misused the "extends" edge type. For a discussion of the extends edge, please refer to this information on How to draw UML Use Case Diagrams..
1.8	This is the incomplete-ness comment. The assignment required that you provide a level of detail in your diagram that was a bit more than what was given in the lecture. We took off one, two, or three points for this, depending on the degree to which you omitted detail.
1.9	Use case ovals should always contain actions (you might also refer to them as tasks or commands) that will together be a description of what the system does. Some of you instead put entities (objects, nouns, etc) in your use case ovals. This is incorrect; representing the entities (or objects) in the system is the job of another type of diagram entirely (UML Class Diagrams), which we will discuss later.
1.10	A number of you included detail about the narrative that wasn't mentioned in the given description of the system. When constructing a real system for a client, you may need to make some decisions about system behavior that are not covered by your initial discussions with the client, and this will seem a lot like inventing detail from thin air. But it is important that before new features or functionality is added to the system, it be verified with the client first. Otherwise, you run the risk of delivering a system that is not what was asked for.
1.11	It is important to the readability of these diagrams that you adopt a consistent grammatical standard for your labels. In this homework, one good standard is to always name use cases as present-tense imperative verbs, as if the actor were saying the name of the use case as a command to the system. For example, it makes sense for the customer to say to the terminal, "Check out items" but it does not make sense for the customer to ask the system to please "Printing the receipt".
1.12	Actors cannot "use" use cases; they can only communicate with use cases (indicated by the unlabelled line connecting the actor to the use case). "Uses" is strictly an aggregation operator amongst use case ovals.
1.13	These use case diagrams must not be thought of as flow charts, data flow diagrams, or scenario descriptions. The UML Use Case diagram is a tool to represent the entire functionality of a system, to an arbitrary degree of detail, and therefore can (theoretically) capture all of the behavior of a system in a horizontal way. A flow chart or scenario description, though, can only capture one specific process in the system, and does nothing to indicate the breadth of the system's functionality. Please see How to draw UML Use Case Diagrams for a discussion of the differences between a flow chart and a Use Case Diagram.
1.14	You received this comment if your diagram was illegible. Please remember to use CASE tools that we have reccommended, or at least make some attempt to render the diagram in an intelligible way. If you feel that the diagram you've created is sloppy, overly complex, or unreadable, you may have chosen a poor method for decomposing your design, and should consider finding another way to represent the system that you are trying to describe. If you are really lost, please see the TAs for help.
1.15	An important part of the use case diagram is showing which actors can initiate and communicate with the various top-level use cases. If your diagram has no actors, there is no real way to tell how the system you are describing is to interface with the outside world.
1.16	Only the top-level Use Case Diagram need show the actors in the system. In subsequent diagrams, the actors are implied by the top-level, so there is no need to show them again (and it can make the diagram busy and crowded to include them.)
1.17	Detail breakdown diagrams that accompany the top-level diagram should show the actual oval representing the use case being detailed. Please see How to draw UML Use Case Diagrams for tips on decomposing use cases.

Score	Description
5	Understandable and clear; gives a good impression of the requirements
4	A good start; but lacking some detail and/or readability
3	Strange or poor organization; sometimes difficult to read
1-2	Minimal effort made
0	No assignment handed in

Number	Description
2.1	When compiling requirements information of this sort, it is usually helpful to write a short, clear, natural-language summary of what you are trying to explain so that the overall document is tied together well.
2.2	When doing group work, please submit only one copy of your final document, and ensure that all of your names are prominantly displayed on the front and top cover.