UML

Starting UML Diagrams

First of all, you need to recognize that UML is not perfect. The goal of UML is to serve as a communicate means for everyone in the developmental phases of an information system. Thus, the designers of UML have decided to make it more formal than English -- so there is less ambiguity -- but less formal than mathematics -- so everyone can use and understand it. UML has a lot of advantages and disadvantages, which you will surely discover once you start modeling with it. In industry, there are tons of companies using UML, and there are also companies that use only UML. Therefore, it is to your advantage that you learn to use it well.

Something To Remeber When Drawing Diagrams

In Assignment 2, you are asked to do four sets of diagrams for you system:

use case diagrams
class diagrams
sequence diagrams
state diagrams

Modeling is not a linear process -- although you start off by drawing use case diagrams and then class diagrams, you will most likely need to go back and fix some problems so that all the diagrams concur. In practise, the most ``iterative'' part is between class diagrams and sequence diagrams. When you do your assignment, you'll probably find that you'll need to go back and forth between these two sets of diagrams and make sure that the classes make sense (i.e. they are doing the right thing) and the operations are doing the intended communication.

If you find that you've gone through the first pass of the use case and class diagrams, and you are doing sequence diagrams and not finding any problems at all, there is probably something wrong (because it's hard to get it perfect at first try). Double check and make sure everything makes sense, the way you (as the designer) intend for the system to work.

How To Start

Once you have a system that you want to model, where do you start? The most hands-on way is to do a ``cognitive walkthrough'' of the system. Here is what I mean: pretend you are one of the user of the system. Now, imagine what you might want to do with the system and how you would do it. Do it, and then write down all the steps that you carried out. Now you have a simple description of a typical system use and what parts of the system you are interested in.

1. Actors

Identify all relevant actors of your system. Remember these are the entities external to your informaion system. They can be people, companies, warehouses, etc. as long as they function on their own and interact with your IS in a relevant way (i.e., there are arrows representing data flow between your IS and these actors).

2. Use cases

Identify all relevant use cases of your system, with respect to each actor. MORE

3. Use Case Diagrams

Putting actors and use cases together... MORE

4. Classes

Identify all relevant classes of your system. MORE

Determine all the attributes and operations. MORE

5. Class Diagrams

Lay out your classes and ask: what are the relationships among these classes? what alternate relationships can you have? do the relationships depict the REAL system? are the classes too detailed? should certain classes be split up as smaller classes, or can the details just be represented as attributes?

If there are ``floating'' classes: are we missing some relationship, or should these classes not be there?

Determine the multiplicities of each association. MORE

6. Sequence Diagrams

Once you've identified your classes and their corresponding attributes and operations, you can start thinking about how they interact with each other (and also with external actors).