| CEN4020: Software Engineering I | up↑ |
Learn to construct a use case diagram from a textual description.
Optionally, learn to use a UML tool.
Using the University Testing Center project description, construct a use case diagram. Include all of the actors and all of the use cases that are to be implemented by the computer system. (Do not include use cases that do not involve the computer system.)
Please try to install and use one of the several open-source UML tools, and use it for this assignment and all others that involve UML. It will save you errors, especially as we get into the team phase of the course and we have multiple individuals working on the same UML diagrams. Please see the separate notes on Eclipse and UML tools for more information abou this.
Otherwise, at least for this first assignment, you may produce the diagram in any way you are able, so long as you turn in either a .pdf or a .doc file. If you choose to use MS Word or Open Office oowriter, there is a use case diagram template provided.
Make sure you review your solution carefully. This review will help you to identify things that you might have misunderstood or omitted. Omissions on Homework 1 will result in omissions in Homework 2, so be careful.
Note that the example UCD is is only one of several variations of how this system might be represented. For example, we might break out the scanning sub-case, and share it as an included case for both adding and deleting a video, as well as returning and changing type. The example also is missing a use-case for the automatic return of checked-out videos that are not picked up within 24 hours. This should probably also be triggered by a timer in the system.
(We might consider instead starting with scanning as the main use case, and then make adding, deleting, returning, and changing type into extensions of scanning. However, that would be inconsistent with the statment taht the owner first "chooses the remove option and (then) scans". It seems that this model of choosing the operation first and then scanning is also less prone to error.)
In the recitation meetings, we will go through how the use case diagram was derived from the problem description. The following will be covered along the way:
Before you start this, please be sure you have read the section on use case diagrams in the textbook, including the figure that shows the syntax elements of a diagram, and the three figures showing examples. Read those carefully. They show you what you need to know. In particular, pay attention to the different kinds of lines, most references on UCD's specify that there are no arrow heads on the lines between actors and use cases. However, some suggest using a line with an arrowhead to distiguish the case when the actor is responsible for taking action to initiate the use case.
I recommend that you start by doing the basic diagram, with just ovals, stick figures, and just lines between actors and use cases. Then, if you can find appropriate places to use the arrows for generalization, includes, and extends relationships, add them (for both use cases and actors). These relationships can be easily confused.
Stick with the requirements stated in the problem description. If the description is ambiguous on some point, resolve it in a way that makes sense and is consistent with the description. Do not add features that are not called for in the problem description.
Keep in mind that when use cases are applied in the requirements definition process, the relationships do not have quite so narrow an interpretation as when one is moving on to coding. For the purposes of this exercise, you may use the following interpretations:
When you are done, re-read the system description document carefully. Look out for omissions (e.g., a sentence that implies a use case that you do not have in your diagram) and errors of over-inclusion (e.g., making a use case out of a non-functional requirement). All the information you need is in the project description, but not all the information in the project description belongs in the use case diagram. (The other information will come into play later, in your full SRS document.)
Finally, when you think you are done, make another pass through the document, and another pass through your diagram. Verify that every actor in the text has an actor in the use case, and vice versa. Verify that every active service provided by the system is represented by a use case, and that every use case is justified by a statement in the document. Make certain that your use cases are describing actions, not things.
You have the textbook, the VRS example, and the course notes on use cases which accessible via links from the notes page, including the following:
If you are interested in more depth you may also want to look at these IBM pages.
Follow the general instructions for delivering individual homework assignments.
The maximum potential score is 100 points. Points may be lost for errors. Bonus points may compensate for errors.
| Error | Deduction | |
|---|---|---|
| Tentative grading scheme, still being revised | ||
| Basic Diagram | ||
| Use cases missing or incorrect | -5 points each, up to a maximum of 40 points | |
| Actors missing or incorrect | -5 points each, up to a maximum of 20 points | |
| Actor-use-case relationships (associations) missing or incorrect | -5 points each, up to a maximum of 20 points | |
| Missing system boundary box | -5 points | |
| Word Choice | ||
| Poor choice of actor name | -1 point each | |
| Poor choice of use case name | -1 point each | |
| Misspelled words | -1 point each | |
| Advanced Relationships | ||
| Correct use of "extend" relationship | +5 points first; +1 each additional | |
| Correct use of "include" relationship | +5 points first; +1 each additional | |
| Correct use of inheritance relationship | +5 points first; +1 each additional | |
| Incorrect use of "extend", "include" or inheritance | -5 points first; -1 each additional | |
| ($Id: hw1.html,v 1.3 2010/08/31 19:43:32 baker Exp baker $) |