Print

Defining UML and its Methodology


UML Described

UML is a graphic language which is very useful for modeling and communicating about systems and processes. Through the use of diagrams, which appear like flowcharts (but are much more useful and descriptive), a language is adopted to allow the systems people and the business people to see a process clearly in enough detail to evaluate and discuss even the most complicated interactions in the project.

Where a project document will consist of sentences and paragraphs, a UML document will consist of clear symbols that describe each process and its interaction with other processes. It is very similar in concept to a blueprint.

UML facilitates the modeling of real world business processes. It permits and facilitates the abstraction of the business processes and interrelationships, allowing the designers to create and identify the sub-processes and their interactions according to the rules of the business. By defining processes in this was, we can better understand their contributions to the more complex system.

UML is a unified practice and technique with defined standards that help in creating good engineering processes. It is the creation of the Object Management Group with the goals of making it ready to use, expressive, simple, precise, extensible, implementation independent and process independent.

UML is a unified modeling language, which is easy to use, and allows all of the production and design team, from the CEO to the programmer/tester a clear and unambiguous language to express and study the developing system/project.

UML Methodology


 

Every System Development lifecycle follows a general pattern:

  •     Requirements gathering
  •     Analysis
  •     Design
  •     Implementation/Building
  •     Testing
  •     Deployment


In the past, development of the system proceeded through a straight-line fashion usually following the business process. The problem is that with this approach, as the various subsystems are integrated later in the process, problems tend to arise with the subsystems which may not fit as well as they should, or that some communication aspects were left undone. This is known as the waterfall approach.

With more complex projects, an ‘iterative approach’ is more productively employed. In an iterative approach, one develops an overview of the whole system during the requirement phase and create a modeling prototype of the system and subsystems which comprise it.

 During the analysis phase, one critique the prototype produced during the first phase, refine it and expand it as needed. The iterative process is repeated during the design phase, as the model is fleshed out and re-examined, as you shift focus from the logical relationships to the physical and less abstract aspects of the system.

During implementation and coding, you will take the objects modeled in the first three phases and actually implement the methods and attributes each of the processes will use. These blueprints will serve well in the testing phase, as all of the interconnections have been previously defined.

Far from adding to the overhead of a project, UML methodology will actually improve the efficiency of design and tend to lower costs. Because each of the objects or diagrams are used in each phase of the project development and enhanced, previous knowledge and planning efforts are leveraged as the project matures.

Iterative development using UML methodology offers the following advantages:

   1. Enhanced feedback and communicators with users as all stakeholders in the project can use the same documents
   2. Better organic documentation, with a tie in to the underlying classes and procedure in the code itself
   3. Better management of the system as a whole because the approach allows easier assembly and testing of sub-components
   4. Easier adaptation of the project to new ideas and changes because changes are designed into the process throughout the cycle
      February 11, 2008out development to test and get feedback are possible.

Resources


These resources provide a history of UML

Copyright © 2001 by Paladin Consultants,Inc.
Chatham, NJ
All Rights Reserved
This page revised   January 25, 2007