UML Methodology an the Unified Process

The UML (Unified Modeling Language)

To quote:

“The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.” [OMG01].

The UML has emerged as the de facto standard diagramming notation for object-oriented modeling. It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to combine the diagramming notations from their two popular methods—the Booch and OMT (Object Modeling Technique) methods. They were later joined by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. Many others contributed to the UML, perhaps most notably Cris Kobryn, a leader in its ongoing refinement.

The UML was adopted in 1997 as a standard by the OMG (Object Management Group, an industry standards body), and has continued to be refined in new OMG UML versions.

The UP (unified Process)

A UP project organizes the work and iterations across four major phases:

1. Inception— approximate vision, business case, scope, vague estimates.

2. Elaboration—refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.

3. Construction—iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.

4. Transition—beta tests, deployment.

This is not the old "waterfall" or sequential lifecycle of first defining all the requirements, and then doing all or most of the design. Inception is not a requirements phase; rather, it is a kind of feasibility phase, where just enough investigation is done to support a decision to continue or stop.

Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high risk issues are mitigated.

Like common schedule-oriented terms in the UP, one development cycle (which ends in the release of a system into production) is composed of many iterations.

The UP describes work activities, such as writing a use case, within disciplines (originally called workflows).3 Informally, a discipline is a set of activities (and related artifacts) in one subject area, such as the activities within requirements analysis. In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, and so on.

There are several disciplines in the UP; some artifacts in the following three:

• Business Modeling—When developing a single application, this includes domain object modeling. When engaged in large-scale business analysis or business process reengineering, this includes dynamic modeling of the business processes across the entire enterprise.

• Requirements—Requirements analysis for an application, such as writing use cases and identifying non-functional requirements.

• Design—All aspects of design, including the overall architecture, objects, databases, networking, and the like.

In the UP, Implementation means programming and building the system, not deployment. The Environment discipline refers to establishing the tools and customizing the process for the project—that is, setting up the tool and process environment.

The UP was not meant by its authors to be either heavy or predictive, although its large optional set of activities and artifacts have understandably led to that The sequential "Waterfall" lifecycle impression in some. Rather, it was meant to be adopted and applied in the spirit of an agile process—agile UP.

Some examples of how this applies:

• Prefer a small set of UP activities and artifacts. Some projects will benefit from more than others, but, in general, keep it simple.

• Since the UP is iterative, requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.

• There isn't a detailed plan for the entire project. There is a high level plan (called the Phase Plan) that estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones.

A detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done adaptively from iteration to iteration.

Business Modeling; The quintessential object-oriented step in analysis or investigation is the decomposition of a domain of interest into individual conceptual classes or objects—the things we are aware of. A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest. They have also been called conceptual models, domain object models, and analysis object models. The UP defines a Domain Model as one of the artifacts that may be created in the Business Modeling discipline.

A UML activity diagram offers rich notation to show a sequence of activities. It may be applied to any purpose (such as visualizing the steps of a computer algorithm), but is considered especially useful for visualizing business workflows and processes, or use cases. One of the UP workflows (disciplines) is Business Modeling; its purpose is to understand and communicate the structure and the dynamics of the organization in which a system is to be deployed. A key artifact of the Business Modeling discipline is the Business Object Model (a superset of the UP Domain Model), which essentially visualizes how a business works, using UML class, sequence, and activity diagrams. Thus, activity diagrams are especially applicable within the Business Modeling discipline of the UP. Some of the outstanding notation includes parallel activities, swimlanes, and action-object flow relationships,

Requirements are capabilities and conditions to which the system—and more broadly, the project—must conform. A prime challenge of requirements work is to find, communicate, and remember (that usually means record) what is really needed, in a form that clearly speaks to the client and development team members.

The UP promotes a set of best practices, one of which is manage requirements. This does not refer to the waterfall attitude of attempting to fully define and stabilize the requirements in the first phase of a project, but rather—in the context of inevitably changing and unclear stakeholder's wishes; finding, documenting, organizing, and tracking the changing requirements; in short, doing it skilfully and not being sloppy. The UP embraces change in requirements as a fundamental driver on projects. Finding is another important term; that is, skilful elicitation via techniques such as use case writing and requirements workshops.

Design The UP does not specifically define an artifact called a "design class diagram." The UP defines the Design Model, which contains several diagram types, including interaction, package, and class diagrams. The class diagrams in the UP Design Model contain "design classes" in UP terms. Hence, it is common to speak of "design class diagrams," that is shorter than, and implies, "class diagrams in the Design Model."

Domain Model; This is a visualization of the domain concepts; it is similar to a static information model of the domain entities.

Design Model; This is the set of diagrams that describes the logical design. This includes software class diagrams, object interaction diagrams, package diagrams, and so forth.

Summary

With UML and UP, use cases are an excellent way to capture business requirements. They scale well over large projects, as long as you define appropriate abstraction levels to allow for an understandable and traceable elaboration from top to bottom.

Just increasing the number of use cases does not work. Business users who validate your requirements can feel quite comfortable with a use case-based approach. The technical team that elaborates your to-be-automated business use cases into technical requirements is often even more receptive to this approach. So, a complex business requirements project, it is an iterative process of decomposition..

By using a use case approach to requirements engineering, supported by a sound development process and refined by best practices and  principles, you can overcome many challenges and make the project a success.