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