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.

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.