CS446
Assignement 1: Use case model and domain model
Tools:
I recommend you to either use a diagramming tool like Visio for the diagrams,
or to draw them by hand (readable!), and to use a text processor for all
the descriptions and lists.
You are free to use SoftModeler (http://www.softera.com/download.htm),
Rational Rose , Visio, or any other CASE-Tool for the assignement, free
trial copies as well as documentation can be downloaded from their web
pages. The use of a CASE-Tool is not required for this assignement, though
it could be very interesting for you to get familiar with a CASE-Tool even
if the use of a CASE-Tool for such a small and short-lived model is overkill.
Problem Statement:
Your customer wants to get a software system for a simple electronic bookstore
called EBook. EBook does not store any books itself. It just provides a
large catalogue of the books it offers. The catalogue contains for each
book the usual information like ISBN-number, title, authors, subtitles,
publisher, typical shipping time, number of pages, hardcover/paperback,
price. Furthermore, for some books, customer comments can be looked up
(only by those customers accessing the system over the web).
A customer can order a book by mail, phone or WWW. He can pay either
by credit card (Mastercard, Visa and American Express are accepted), or
by check (only when he orders by mail). Customers and clerks can look up
the catalogue on the WWW.
When a customer orders books, payment gets verified and the book
is then ordered directly from the publisher (we assume that the money is
credited or cashed at the time of ordering the book, not at delivery time).
The communication with the publishers is by fax, i.e. the system automatically
sends out a fax for each book that gets ordered. For the sake of
simplicity, we assume that every book gets delivered eventually, and that
there are no undeliverable books in the catalogue. When books arrive from
a publisher, the books get shipped to those who ordered them. A customer
can order one or several books per order, yet they will get shipped to
the customer as they arrive at EBook, i.e. a single order can result in
several shippings to the customer.
Of course, the catalogue needs some maintenance, so the clerks can
add and delete items from the catalogue, as well as update information.
Moreover, the clerks as well as customers can enter customer comments
for a specific book. Also, whenever they want, the clerks are able to inquire
how many books are pending from a specific publisher. Customers and clerks
can inquire about the status of an order any time.
Cancellation: A customer can cancel an order as long as it has not
yet been sent out to him. In case of a cancellation, EBook either
cancels the order at the publishers or returns the book(s) to them.
Return of books: A customer can return a book within a week. The money
will either be credited to his credit card, or he receives a check.
Deliverables for assignement 1a:
-
Use case model:
-
List of actors and descriptions of actors.
-
Use case diagram(s) that show actors, use cases and any relationships among
the use cases.
-
Names of use cases, short one-sentence description of each use case, and
a priority assigned to each use case (define priority levels yourself).
-
Detailed description for each use case containing sections for pre- and
postconditions (of course only if there are some that are important enough
to document), step-by-step description of primary scenario (numbered list
of steps), secondary scenarios.
You are free how you document the secondary scenario (deltas to basic
flow of events, within description of basic flow of events, separate description),
yet be consistent und choose a reasonable level of detail.
-
Risk factors:
-
List of risks you see in developing this system (not more than 10 risks)
-
Priorization of the risk factors
-
Non-functional requirements:
-
List of high-level requirements not captured in the use case model, e.g.
timing requirements (not more than 5 items)
Deliverables for assignement 1b:
-
Domain Model (high-level class model of main business objects):
-
Class diagram showing classes and associations
-
For each class: short description, attributes (just names without any further
information about visibility, type, etc.), maybe some essential operations
(not yet any low level operations like getting and setting attributes)
Grading
The documentation has to be delivered to me in paper form. Feel free to
use scissors and glue to overcome any shortcomings in the documentation
facilities of the tools you use. Also feel free to combine handdrawn diagrams,
a CASE-Tool or a drawing tool with a text editor.
You might find it helpful to create additional diagrams for yourself
that help you to detect elements of other diagrams. Yet these diagrams
are not required as a deliverable in this exercise.
Be aware that some requirements are not stated explicitly, e.g. in order
to ship books to a customer the system of course needs to have certain
information about the customer.
The above problem statement is certainly not complete. In real life,
you would specify items unclear or missing by communicating with your customer
and future users of the system. For this exercise, you have to take on
both roles, the role of the software developer as well as the role of the
people actually responsible for deciding on the requirements of this system.
Criteria for the grading will be the content of the work (see deliverables)
as well as how it is presented. Be aware that somebody else is going to
read your model. Too much documentation is just as bad as too little documentation,
and the organization in your documentation is very important. A good choice
of names increases readability, as do precise yet short descriptions of
names. Beware of implicit assumptions: even if you know what you mean by
a specific term, and what that term includes and what it excludes, the
reader might make different and wrong interpretations if you are not specific
enough. You are free to add additional text to the documentation wherever
you might think it will be helpful.
You may form teams of two to do this assignement and just hand
in one solution per team. Both team members will get the same grade, and
it is up to you to make sure you both contribute to the solution and learn
about modeling.
You may discuss the assignement together - the goal is that you learn
and exercise modeling, and modeling is a team activity - yet every team
has to hand in its own solution.