Basic UML
Before we can do "Advanced" UML, we have to do Basic UML, because most of you do not know much UML if any. Fortunately, our textbook covers UML from the very beginning so all you have to do is read it and ask questions... In my undergraduate class which does Basic UML, we cover 3-4 of the most important UML diagram types. Our text for this course describes about 8 diagram types. In one week we can probably cover around 4 UML diagram types, but we may introduce some of the more exotic ones later in the semester if we need them. Most of this stuff is easy enough that you will be able to use it after you see it.
Use Cases
Many OOP and UML books start with class diagrams. But this is just
the Yankee-centric American programmer (Rumbaugh) worldview. Being
Scandinavian, it is Jacobson who has the better world view, which is: before
you try to figure out your classes, figure out what the users are going to
do with the program.
Use Cases and Class Extraction
Use cases are formatted descriptions of "discrete" tasks. By "discrete", we mean an individual standalone thing a user does while using the system. Lethbridge defines a use case as:A use case is a typical sequence of actions that an actor performs in order to complete a given task.
You develop use cases by careful inspection of the specification document (if you have one) or interrogation of the customer (if you have one) or by the sheer entepreneurial vision of seeing a NEED and filling it. The outcome of use case analysis is (optionally) a diagram and not optionally, a set of use case descriptions, which are formatted paragraphs, each describing a particular task. The reason we do use cases first is that they provides vital inputs for the class diagrams and other UML diagrams to follow.
If you look through the tasks mentioned in a specification document, you can identify a set of candidates. Example candidate tasks for an electronic classroom:
- Login
- View thumbnails of students' screens
- Display lecture presentation
- Administer test
Use Case Terminology
- actor
- role that an external entity plays in a system
- use case (or just "case")
- depiction of some aspect of system functionality that is visible to one or more actors.
- extension
- a use case that illustrates a different or deeper perspective on another use case
- use
- a use cases that re-uses another use case.
Use Case Diagrams
Use Case Descriptions
Drawing an oval and putting the name of a task in it is not very helpful by itself, for each use case you need to add a detailed use case description. Our text barely mentions this when it talks about scenarios.Here is a proposed format for use case descriptions. The precise format is not part of the UML; my point is that UML diagrams are almost useless without the supporting documentation. Each use case has many or all of the following pieces of information. The items in bold would be found in any reasonable use case description.
- Name
- The name of the use case.
- Actors
- What participants are involved in this task.
- Goals
- What those people are trying to accomplish.
- Preconditions
- The initial state or event that triggers this task.
- Summary
- Short paragraph stating what this task is all about.
- Related use cases
- What use cases does this use case use or extend? What uses/extends this use case?
- Steps
- The most common sequence of actions that are performed for this task. Lethbridge divides actions into two columns: user input is given in the left column, while system response is given in the right column. The two column format is optional, but saves on paper and may improve clarity. The steps are numbered, so there is no ambiguity in using both columns on each line.
- Alternatives
- Some use cases may vary the normal sequence of steps.
- Postconditions
- what does this task produce?
Open File |
Lethbridge-style two column format is nicely motivated in Example 7.2 from the text, which has enough steps to where two columns saves enough space to matter. When you start having trouble fitting the whole use case description on a page, there are substantial benefits to a compact format.
Exit parking lot, paying cash |
Lethbridge Example 7.3 gives you one more look at use case descriptions. This one is for a library management application.
Check out item for a borrower |
Now, ask yourself: why is Dr. J convinced that use case descriptions are a vital software engineering job in the initial stages of requirements analysis?
More Use Case Diagrams and Examples
One reason to do a use case diagram is simply to summarize or catalog what tasks are part of the system; a sort of table of contents. But the main reason use case diagrams exist is in order to show who does what, when different users (actors) participate in different (overlapping) tasks. If you only have one actor, or there are no tasks in which multiple actors interact, there may be no reason that you have to do a use case dialog.Consider the following example for a university registration system.
There are three actors (Registrar, Student, Professor), and there are five use cases. The "Find information about course" use case is vague and probably the three actor types can find out different information from each other. They are not typically involved in the same instance of finding out information about a class, so the example could be better.
The following figures illustrates some more exotic use case diagram items, namely actors and use cases that use or extend other actors and use cases.
"Include" is a form of dependency in which one or more use cases use another. The included use case is in effect an "abstract" use, it is always used by another use case, not directly by an actor.
Extends is similar to include, except that the included use case may also exist as a standalone task. Use cases which include or extend may specify the point at which they execute the other use case.
Generalization (or specialization) is an inheritance relationship between actors or use cases.
One interesting category of actor in use case diagrams are external systems. A computer program may interact with external entities that are not humans; they may be remote database servers, for example.
Now here is a non-textbook domain for which one might create examples of use cases and use case diagrams.
Class Diagrams
Class diagrams are the "meat and potatoes" of object-oriented analysis and design. Class diagrams describe more implementation-oriented things, in more detail, than use case diagrams. Class diagrams have one or more classes inside rectangles, as in:
| Person |
You may think class diagrams are mainly about describing the classes in an OO system (our textbook authors seem to think so). Experience has taught me that while classes are terribly important, the purpose of doing them in a diagram (instead of, say, C++ header file class declarations) is to show the relationships (called associations) between them with as much detail and precision as possible.
Class diagrams can present varying levels of detail about the classes in them. Some class diagrams may have nothing more than the class name for each class; others may hold the full list of fields and methods. When more space is taken by class details, there is room for fewer classes per diagram, so you often have "overview diagrams" that show many classes and their connections, supplemented by "detail diagrams" that show more information about closely related classes.
Object Modeling
Before you go off and do "object oriented programming", someone has to do object oriented modeling, to model or characterize the application domain in terms of software. If your introduction to object orientation was by programming in C++ or Java, you may not know that the Object Oriented Paradigm was not invented by programming language people, but rather by the software design community, specifically some people doing computer simulations in Scandinavia. They went off and invented an OO language (Simula67) which inspired some Californians to invent SmallTalk, and the rest is history.A model is a representation of a real-world process or concept in graphic or narrative form. Your goal in modeling is to create a model space that closely corresponds to reality. Your goal in modeling is also to discern what parts of reality are relevant to the application at hand. What the application needs to do, determines which parts of information to represent, and how to store it. Light has been modeled variously as particles or waves; people might be modeled as (SSN, income) number pairs, or as pliable 3D solid bodies, etc.
| Reality | Model space | |||
|---|---|---|---|---|
 |
|
An object is an application-specific group of related information, used to represent some part of a model. "Numbers" or "arrays" are not application-specific, but "rate schedules" or "teams" might very well be objects in applications that work with those ideas.
Fields and Methods
The information in an object is called a field (a.k.a. member variable). Fields are tightly controlled and modified according to the rules of the application domain from which that object originates (laws of physics, corporate policies, etc.). This control is achieved by means of encapsulation: you can't get at the information directly, you must go through a public interface consisting of a set of methods (a.k.a. member functions, or operations).
| Reality | Model space | ||||
|---|---|---|---|---|---|
|
|
There are lots of different kinds of cars that could be represented by the same class, and share the same code. Classes define attributes and methods which form some kind of approximation or projection of the real world thing or idea. What attributes you choose depend on what the application will need to do with the objects. A set of methods forms a public interface to the objects of a given class; attributes are not accessed directly.
A method is a function that:
- operates on an instance
- can read or write information from the instance's fields
- can call other methods to do part of its work
- can ask another object to do part of its work (via its public interface)
How to select "good" classes?
Textbook answer #1: a good class model consists (as far as possible) of classes which represent enduring classes of domain objects, which don't depend on the particular functionality required today.Textbook answer #2: You will not be likely to get it right the first time. Fred Brooks said: "Plan to throw (the first) one away."
Textbook answer #3: "Noun indentification". Pick out all the interesting nouns from the requirements specification. Discard those nouns that prove not interesting after all for any of the following reasons:
- redundant - they are the same thing as another interesting noun
- vague - you can't tell what it is
- event or operation - something done to, by, or in the system
- metalanguage - e.g. "requirements", "system"
- irrelevant - outside the scope of the software system
- attribute - information that is attached to another class
What kinds of things are classes?
- tangible real-world things in the application domain
- roles played by human users (actors)
- interactions, or transactions - but beware the "event or operation" criterion!
Associations
Perhaps the main purpose for class diagrams is to identify and depict relationships between objects that will be needed in the running system. An association is the word we use for such a relationship. We draw a line between the rectangles for classes to depict an assocation. There are three major kinds of relationships shown in UML Class diagrams:- inheritance
- aggregation
- user defined
- aggregation
Inheritance: the Un-Association
Inheritance is not really an association, it is a relationship between kinds of things, in the design and maybe in the programming language type system, whereas associations are relationships between instances (objects) at run-time. Inheritance is so vital that many class diagrams focus specifically on a large inheritance class hierarchy, similar to a biological taxonomy of species. Inheritance is usually a static feature of a design, although there exist languages in which instances can change who they inherit from at runtime.Here is an example class hierarchy:
Aggregation: the Simplest Association
Aggregation, the parts-whole relationship, is perhaps the most useful association of all of them. Many many complex things are made up of an assembly of simpler items. There are at least two flavors of aggregation, static and dynamic. Static aggregation (a.k.a. composition) is unchanging or lifelong aggregation; the parts cannot exist apart from the whole, or enter or leave the whole. Composition appears in diagrams as a solid diamond. Dynamic aggregation is more like a team whose members can come and go. Here is an example of a massive chain of aggregations:
Note: our textbook author warns us that new designers usually over-use aggregation!
lecture #2 began here
Next Homeworks
The next homework is available on the class webpage.Association Details
There are many details added to associations to show more information about the relationship. Some of these details are discussed in Chapter 5 in your text.- link
- just as classes have instances at runtime called objects, associations have instances at runtime called links. Links occasionally are so important and complicated that they need their own attributes. The main information about them is usually their lifetime, and what instances they are connecting.
- multiplicity
- a.k.a. cardinality, it is the number of object instances per link instance in a given relationship
- qualifier
- some many-to-one relationships have a unique key used to traverse the association.
- roles
- the different ends of an association may have differing roles associated with them. Especially useful if both ends of an association connect the same class.
- composition
- there is a special kind of aggregation called composition, which denotes aggregations in which the component parts have no existence apart from the whole thing. The relationship is hardwired, static, or constant. Composition is marked using a filled diamond; hollow diamond means a regular (transitory, or dynamic) aggregation.
- derivation
- some associations are said to be derived from (or "implicitly implied by") (possibly multiple) other associations. They generally don't require an extra data structure or consideration in more detailed design work, but may warrant supporting methods in the implementation.
Here are some more class diagram figures from some old software engineering text (Pfleeger). One point here is that it is logical to start with a simple sketch of classes and basic relationships, and add many details later on. Note that I consider these diagrams fatally flawed: many associations are indicated but undefined! If it is not inheritance and it is not aggregation, it should be named, and a supporting paragraph or more of documentation should describe the relationship.
User-defined Association Examples
Here is an association you might see in a human resources application. It features roles, and names the association properly...
|
employee employer Works-for |
|
What are some example instances of this association? How useful will such a diagram be to later design and implementation? I claim that simply giving an association a name is not sufficient; if it isn't inheritance or aggregation, it needs at least a paragraph defining what it is. Here is an attempt at such
Works-for: When an employee Works-for an employer, the employee is allocated appropriate resources (space, phone) and is scheduled for tasks and meetings appropriate to their job title. The employee is entered into payroll and benefits systems in the personnel office. The Works-for relationship is established between an employer and an employee when a hiring procedure is completed, and terminates either at the end of a contract (for contractor employees) or when a salaried employee retires, quits, or is fired.
Here is a more detailed version of that association:
|
employee employer * Works-for |
|
There is a multiplicity, since many people may work for the same company. But what if a given person works for more than one company?
Here is an association you might need for a geography application:
| Has-capital |
|
Now, what are some examples of this association? Give me some instances -- and their "links". To include more information in this association, we need to know:
- How many capitals can a country have?
- How many countries can a city be capital of?
- Does every country have a capital? Vice-versa?
Constraints
The graphical elements of class diagram notation are swell, but don't really capture many of the semantic restrictions that may be required by an application domain. In addition to class and association detail information, UML has an escape hatch called OCL (Object Constraint Language) for writing additional semantic restrictions.Association Classes
When an association describes a relationship complex enough to warrant its own attributes and methods, the association gets promoted to a class.Interfaces and Abstract Classes
UML supports the notion of interfaces in a manner very similar to Java; Java interfaces may be influenced by UML. Interfaces look like classes, with no attributes section and with <<interface>> inscribed after the class name. Public methods are specified, without any implementation. Any class implementing that interface must implement its methods.An abstract class is similar to an interface; it is a class that has no instances. Unlike interfaces, an abstract class may provide implementations for some or all of its public interface. It exists to be subclassed. Design Patterns (which we will discuss in a few weeks) are rife with abstract classes.
Statecharts (Chapter 11)
A statechart, or state diagram, depicts dynamic properties of a system. See p. 138 of the text. A statechart consists of- a set of states
- drawn as circles, ovals, or rectangles, with a label or number inside.
- a set of transitions
- drawn as arrows from one state to another.
- a start state, and a set of final states
Some of you may be getting an eery sense of deja vu at this point. Statecharts are a non-trivial extension of finite automata, because they have:
- instead of "input symbols", events associated with transitions
- these may be complex, synchronous or asynchronous
- events may have conditions, drawn inside square brackets
- activities
Statechart Diagram Examples
Collaboration Diagrams
Collaboration diagrams are the next form of UML diagram we will describe in this course. Collaboration diagrams describe how a set of objects interacts by calling from method to method.Collaboration Diagram Examples
A collaboration where an actor pushes a button to get an elevator to his floor. The control object checks how long the job queues of all the elevators are and chooses the shortest. It then creates a job order object and invokes it by putting it in a queue. The elevator object runs concurrently and picks up jobs from the queues. The elevator is an active object, meaning that it executes concurrently with its own thread of control.
The object MainWindow receives the message NewCustomer, and creates a
Customer object. A CustomerWindow is created, and the customer object
is then passed to the CustomerWindow which allows for update of the
customer data.
A collaboration diagram that summarizes sales results.
A Collaboration Diagram for a Printer Server
Collaboration Diagram with Simple Numbering
Collaboration Diagram with Decimal Numbering
There is no lecture #3; this is a placeholder