Unified Modeling Language

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.

The Unified Modeling Language

The Unified Modeling Language

Project Start

Much of the content of the Project Process section of this document is purely connotative and is merely my opinion about what is helpful when breaking down a large project into smaller solvable problems. I believe one weakness of the Rational Unified Process is that it does not provide for well ordered methodologies to address how to logically break a large process into smaller sections. I will attempt to address that issue here.
Real World Projects

One thing to keep in mind about UML and the Rational Unified Process is that the real world is complex and project requirements will change. Also there will be unexpected events during development. Enexpected events tend to show up more often and with greater consequences in high risk parts of the project. There are not always exact rules to go by when creating artifacts when using UML and the Rational Unified Process. This is because project situations vary and your situation will depend on many factors including your current systems and staff. This document will give some general ideas and possibly some rules of thumb.
System Requirements

Determining system requirements is a very important part of the system design process. Although this document is not intended to describe this process, due to its importance, I will briefly touch on it here. Without proper determination of system requirements, the project is most likely doomed to fail. The steps in this process are generally as follows:

1. Determine the current capabilities of the present system from the user's point of view.
2. Describe (or reference documentation about) the equipment to be part of the system or that the system must interface with along with protocols and physical media used. Consider some typical calculations the system will do.
3. Get all input possible from user's and technical staff to determine additional capabilities and features to add. Also determine how strongly these features and capabilities are desired.
4. Determine the priorities of proposed features and capabilities.
5. Determine expected system performance including quality features ad discussed in the Management Guide in the management section.
6. Perform a preliminary risk assessment of all proposed features and system capabilities. Factors affecting risk include:
* Difficulty and cost of the feature or capability.
* How easily the feature can be supported by current technology.
* Political implications of including the feature.
* The risk of placing the wrong requirements or wrong emphasis of requirements on the system.
* Whether the organization has staff with the technical skills to build and maintain the system.
7. Determine which system features and capabilities to include in the first iteration by using priority and risk assessment. As the risk rises and the priority of the feature drops, it is less desirable to include the feature in an early iteration. However, if a required feature of the project has a high degree of risk, the risk must be properly assessed through testing or whatever means possible early in the project cycle to determine if the project is actually feasable.

System characteristics that may be important to consider when developing requirements are:

* Scalability - Involves capacity management so increasing user demand may be met and managed efficiently. The system may supply performance information allowing administrators to change configuration to enhance performance for increased demand
* Database connectivity - Efficient data flow - The system can manage the requests to the database (if required) along with caching requests when appropriate, thereby relieving and managing some of the load on the database server (if the system interfaces to one).
* Security - There may be requirements to secure or encrypt information between different parts of the system or between the system and other systems.
* Integration - Provides support to integrate with other or older systems.
* Failure management.
* Stability of the system.
* How easy will the system be to use and learn?

When determining system requirements it is helpful to consider and outline the following:

* Goals of the system.
* System functions
* Categorize functions as essential, hidden and optional. Hidden functions are those functions that the user does not see.
* Determine system characteristics (otherwise known as attributes). These are performance considerations such as system boundary constraints, how fast the system operates, and how easy it is to use.

All system function characteristics must be characterized as required or desired.
Functional System Breakdown

One helpful way to simplify a system is to break it down into levels. Generally, an interface may be developed between these levels to keep changes in one level from effecting another level. Most networking protocols in use today use this method and it works quite well. Some levels may include:

* Display interface for the user.
* Data storage interface.
* Controller interface.

Another way to break a system down is to determine its areas of functionality and attempt to conceptually separate these parts of the system.

1. Draw the overall system use case diagram including initialization. Only consider how the main system will interact with actors on the outside of the system boundary.
2. Consider the main functional steps that the system must perform in order to make the use case happen. Below is listed some example functional areas systems must deal with.
* User authentication - Be sure the user is authorized to use the system and determine their security access level. This will be compared to resources and resource lists to allow the user to see and list resources at their security level.
* Resource posting - Determining resources or information provided by the system that is available to actors outside the system. How the actors will get this information? Also consider security issues.
* Resource determination - Determine resources that are available to the system and information that the system can get from these resources.
* Data storage
* Data display
3. Consider the type of data that is saved or passed around the system. In light of the functional areas above, what kind of data should each functional area deal with or what parts of the data should those functional areas have access to?

Once the above steps/considerations have been made, it may be possible to break the system down into subsystems dependent on functionality with regard to dataflow. This can help simplify the system by breaking one large problem into a series of smaller problems. At this point it should be possible to create use case diagrams for each subsystem and begin the UML process.