Unified Modeling Language

This document was written as I learned UML (Unified Modeling Language). I am not an expert in UML and do not pretend to be. However I believe that this document will supplement other UML learning materials and help speed the process of learning UML along with clarify how it should be effectively used. This document should be used along with other referenced materials for learning and using UML. UML can be used as a project modeling tool for object oriented programming and the Rational Unified Process can be used as part of a project management tool.

It is assumed that the reader has basic knowledge of object oriented programming and techniques.

This document outlines some information about Unified Modeling Language (UML) and the Rational Unified Process. Knowledge of both is important for the management and operation of projects that use iterative development. This document will address steps involved in the design process of a project. These steps will be taken for specific purposes and in the process various documents will be created.

The Rational Unified Process (RUP)

The Rational Unified Process provides method for managing tasks and developing documentation. It is a methodology package for sale on the web by Rational Software at http://www.rational.com. It contains software to aid the process.

UML

UML is a notation (graphical language with rules for creating analysis and design methods). UML is a supporting tool for the project.

The Design Process

The UML design process involves the creation of various graphical or text based documents. In UML, these documents are called artifacts and they describe the output of a step in the process. The UML design process has two main parts which are:

• Analysis - What is the problem?
• Design - How should the problem be solved?

The reason for this analysis and design process is to allow the project to be broken down into component parts which provide the following project characteristics:

• Detail is hidden
• The system is modular
• Components are connected and interact
• Layer complexity
• Components may be reusable in other products.
• Variations on a theme.

Phases

Phases describe the functional implementation of the project. There are several iterations in each phase. Project phases and general percent of the project are:

1. Inception - 5%
2. Elaboration - 20%
3. Construction - 65%
4. Transition - 10%

Iterations

The traditional design process involves a step by step process. This process basically includes:

1. Requirements Definition
2. Analysis
3. Design
4. Installation
5. Testing

This process does not allow for changes to the overall design once a particular phase is reached. Changes to a design once the testing phase is reached can be very difficult. This causes projects to have a high maintenance cost long after initial completion. UML and the iterative design process save money by allowing the design of systems that have low maintenance cost. The UML process allows for designs to have iterative processes. Essentially this means that the each iteration add some function (based on a use case) to the system. Additional features or functions are added in succeeding iterations. This allows a project to become active sooner and as feedback is given, additions or modifications can be made with less effort. Each iteration will have a time limit and will have specific goals. This is called "time boxing".

Design steps are broken into iterations which may be performed over and over. Each iteration includes:

1. Analysis
2. Design
3. Code + Design +Test + Integration

It is important to note that test and integration is done during each iteration. This means code is tested to the extent possible during the iteration to be sure of its quality. Also integration should be done during every iteration (Except the first) to get the code from each iteration working together. If integration is left to the end of the project, it may become very difficult. Iterations have a length of two to six weeks. Iterations are "time boxed" with each iteration having a fixed length with specific goals. Use case requirements are used to determine the development to be done during each iteration. Therefore an iteration may include one or more of the following:

• A complete use case.
• A simplified use case.
• The remainder of the use case after the simplified use case was completed in a previous iteration.
• More than one use case.

The idea is to schedule just enough work in each iteration to be able to complete the work by the end of the scheduled iteration.

Workflows

Workflows include:

1. Business modeling
2. Requirements
3. Analysis and Design
4. Implementation and Test
5. Deployment
6. Configuration and change management
7. Project Management
8. Environment - Required tools and software for the project work are made available to the team.

During each project phase and each iteration, there is a certain amount of work being done in each workflow category. Obviously during the inception and elaboration phases business modeling and requirements definitions are done more, however even during the successive phases such as construction, some business modeling or requirements definitions work may be necessary. This will be especially true if the plan changes, however even if the plan does not change some reassessment of requirements definitions should be done along the way.

Artifacts

During each iteration the below artifacts (documents) are created. They are normally created in the order shown.

1. Use Case Diagram
2. High Level Use Case Diagram
3. Expanded Use Case Diagram
4. System Sequence Diagram
5. Domain Model (Formally called conceptual model)
6. Operation contract
7. Collaboration Diagram (Also called interaction diagrams)
8. Design Class Diagrams

The first six steps are part of the analysis phase and the last two steps are part of the design phase.