Unified Modeling Language Guide Contents Page

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:
  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:

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

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:

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.
  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.

Unified Modeling Language Guide Contents Page