Lesson 2: UML

Basic UML

The Object Management Group (OMG) specification states:

The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.

UML is a broad standard that can be used in all sorts of design processes. We use a small subset of the UML language for very specific purposes in this course, mainly to graphical render database tables and the relations between them. The main elements of this subset are briefly described here.

Class Diagrams

A class diagram describes system objects and the relationships between them. A class diagram graphically represents the specifications for part of a system, and, depending on the UML software being used, can be translated into matching code (Java, C++, DDL, etc.), or reversed engineered from such source code.

class
A class is a specification of a static system element, while an object is an instance of that specification. In database design, a class represents a table design or description, while an object is the instantiation of that table.
name
A unique identifier of a class.
attribute
In the context of a database a class attribute is simply a table attribute. It can be assigned a type (i.e. domain), initial values, or constraints.
operation
An operation is a procedure or function that can be run against an object of a given class type. In the context of a database operations are not implemented as part of a table - rather, they belong to the database as a whole. However, it can be useful to think of an operation as conceptually belonging to a particular table. Operations may be defined with elements such as parameters, return types, default values, etc.
stereotype
Classes, attributes, operations, and associations can have stereotypes. A stereotype identifies a class, attribute, or operation has having a special, predefined role within a system. Database stereotypes includes such things as table, view, and primary key.
assocation
An association represents the relationship between two classes.
role
Each class in an association plays a role with respect to the other class in the association. Generally, these roles represent the basic concerns of software design - specialization, association, aggregation, and view - but the actual names used for the roles may go beyond the short list of descriptive terms used for those concerns ("is-a", "uses-a", "has-a", "views-a") in order to make the part a class plays in a relationship clear. By default both ends of an association are considered to be navigable, meaning that the classes at each end of an association contain attributes that can be used to identify a specific instance of a class at the other end. A directional association implies that only one of these classes has such an attribute. In database terms, related tuples are identified by primary and foreign keys. In a navigable association both tables have matching primary key values. In a directional association, a primary key in one table is matched by a foreign key in another table, but not visa versa.
multiplicity
Multiplicity gives the number of objects that may participate in an association. This may be a single value (ex: 1, 3), or a range of values (ex: 0..1, 1..5, 0..*). It also shows how many items can be stored in an attribute. Thus a multiplicity of 0..* indicates some kind of array or data structure that can hold many values. For a database attribute multiplicity has a very special meaning - [1]: NULL not allowed (this field must contain valid domain values); [0..1]: NULL is allowed (this field may be left empty); any form of [*] is not normally used as fields are usually atomic and contain a single value.
Sample Class Description

The diagram shows two sample classes and the association between them. The various parts of the diagram are labelled. (The labels shown are UML Note symbols connected to the item they are describing with Anchors.)

The member and publication classes are related by the member_publication association. member has three attributes: surname , forename , and memberId ; and three operations: add_member() , delete_member() , and select_member() . None of the parameters or default values for these operations are shown in the diagram. publication also has attributes and operations defined, but they are not shown in the diagram either. (UML software generally allows the user to show or hide various elements of classes and associations). Both member and publication have a <<table>> stereotype, clearly indicating that they are database tables. memberId has a <<primary key>> stereotype, indicating that it is the primary key for the member table.

The member_publication association is a directional association since it has a single arrow pointing from the publication table to the member table. This means that the publication table contains foreign key values that match primary key values (of the attribute memberId ) in member . The reverse is not true - member does does not contain a foreign key attribute that matches the primary key attribute of publication , whatever that primary key attribute may be.

The muliplicity of the member_publication association implies that each tuple in member may be associated with 0 or more tuples in publication , while each tuple in publication may be associated with only one tuple in member . The association roles explicitly describe, in English, the relationship between the two tables. Thus, the relationship from member to publication may be read as: "A member owns zero or more publications"; while the relationship from publication to member may be read as: "A publication is owned by one member."

Use Case Diagrams

A use case diagram displays the relationships between actors and use cases.

actor
An actor is a user of a system - can be a human user, some other part of the system, or another system altogether. Actors are named according to the roles they play with respect to a system. The entities represented by actors may change as their roles change.
use case
A use case represents an act or operation that a actor can perform within a system.
ATM (Automated Teller Machine) Sample Use Cases

This diagram shows three actors: Customer , Technician , and Head Office . The Customer and Technician actors represent humans who interact with an ATM, while the Head Office actor represents an external computer system that is connected to an ATM. Deposit Money , Withdraw Cash , Repair , and Validate Transactions are all use cases representing actions that the actors that are associated with them can take. Actors represent only roles, not the people or systems playing those roles. Thus, when people repair ATMs, they do so as Technicians , but when those same people withdraw cash from an ATM, they do so as Customers . Thus there is no need to connect the Technician to the Withdraw Cash use case.

Describing use cases is one of the fundamental first steps in describing and developing a system. You must know how as system is to be used before you can design the system itself. Use cases and their associated diagrams provide a method of describing those system uses.

Web UML

The Web Application Extension (WAE) standard for UML was first described by Jim Conallen, A Senior Software Engineer at IBM. Conallen designed semantics and constraints for modeling web architectural elements. Some aspects of WAE are described here.

The WAE Model

The foundation element of web applications is the web page. In WAE, a number of different stereotypes are applied to a web page depending on the role it plays in a web site. Web pages can be subdivided into various components depending on the functions of those components. (In implementation terms each of these components can be mapped to HTML elements.) There is a large set of WAE items defined for classes, components, packages, and other UML elements. Conallen suggests class descriptions for a number of other web elements not listed here, such as frames, client-side scripts, and java servelets. Further, he demonstrates the use of sequence diagrams, component diagrams, and other UML elements for describing the form and function of a web site. However, the narrow subset of WAE elements used here is sufficient as a basis for the topics under discussion. The following table present only those WAE items used in this course, with some minor modifications from the standard for simplicity's sake.

WAE Elements

A «server page» is a web page that contains operations executed by a web server or application server. The server page itself cannot be viewed - instead the execution of its operations builds a client page that is then viewed by a browser. In order for a form to submit its values it must know the address of its submission target (the form's action). The path tagged value provides this address. The ScriptingEngine tagged value lists either the language or engine that should be used to execute or interpret this page (PHP, Perl, Java, etc.)
A «client page» is what the user sees on their browser. It can be a simple web page or can be built by a server page. It may contain data, images, client operations, and further WAE elements such as forms. The memberTitle of a client page is normally used as its name. A client page may also have a path tagged value if it is an actual page and not built by a server page.
If you see this message, then your browser does not support SVG objects directly. Please switch to a browser that does, such as FireFox 3. A «form» is an element of a client page. In implementation terms it is a set of HTML input fields surrounded by a <form> tag. It has no operations since these are contained within its owning page. In UML forms are shown as part of their owning page through an aggregation association. The method tagged value is the HTML submission method used by the form. Forms cannot stand alone and must be part of a client page. One client page may contain many forms.
A «builds» association connects a server page to the client page it build when the server page's logic is executed. Because server pages may contain conditional logic, one server page may build more than one class of client pages.
A «submit» association shows the connection between a form and the server page its data is submitted to. A form may have only one «submit» association. A «submit» may have tagged values of parameters that are passed along with the submission request.
A «link» association shows hyperlinks between pages and is mapped to the HTML anchor element. Client pages may link to all other page types. (Not all server pages need form input data in order to be executed and may thus be linked to directly). Note that a server page cannot have an outgoing link, but the the client page that it builds can. A «link» may have tagged values of parameters that are passed along with the page request. A link association is always directional and points from one page to another.
«input» An «input» attribute stereotype maps to the HTML <input> tag. It may have the tagged values: type - The type of input control to be used: one of text, number, hidden, password, checkbox, radio, submit, and reset. size - Specifies how large an area to allocate on screen, in characters. maxlength - The maximum number of characters the user can input..
«select» A «select» attribute stereotype maps to the HTML <select> tag. It may have the tagged values: size - Specifies the number of lines of text to display at once on screen. multiple - Specifies that multiple values may be selected at once.
«textarea» A «textarea» attribute stereotype maps to the HTML <textarea> tag. It may have the tagged values: rows - The number of visible text lines. cols - The visible width of the control in average character widths.