Both the Unified Modeling Language and the Unified Process are quite loosely defined. Guidelines that constrain the language and the process in very practical ways can make the process much more effective. This tutorial proposes a coherent body of such guidelines.
The tutorial is intended for developers and managers who are considering adopting Rational’s Unified Process for use with the Unified Modeling Language. The tutorial will assume an elementary knowledge of object-oriented concepts and their use in Object-Oriented modeling.
The Unified Process (UP) from Rational Corporation uses the Unified Modelling Language (UML). The UP can be thought of as a layer above the UML.
The UML and the UP are both quite loosely defined, so that different projects working in different ways might all claim to be using the UP and UML.
This tutorial presents key elements from a layer we think of as coming between the modelling language and the process. This layer clarifies and constrains the UP and its use of the UML, and hence provides support for modelling and support for the process.
We have found in practice that such clarifications and constraints add value to the UP by building on its strengths and overcoming some of its weaknesses. The strengths of the UP include its emphasis on iterative working. Weaknesses include failing to tighten the underlying language, UML, and failing to distinguish clearly between development activities and development phases.
This list does not define a new process. Rather, it reduces the number of interpretations of the Unified Process.
The list is not comprehensive. For example, we could add support for project-management through time-boxing of development activities, or support for high levels of precision through the use of OCL. Or we could focus more on modelling support, through such topics as design patterns. Our particular selection focuses on process issues, and reflects what we have found in practice adds considerable value to many kinds of projects with only a small investment in learning.
By design, the elements in the selection work together to form a coherent whole. For example, it is easier to avoid premature design of behaviour when you have an architectural model that shows where such design choices belong.'