Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Getting the most from unified modeling language

Posted: 03 Mar 2003 ?? ?Print Version ?Bookmark and Share

Keywords:uml? ad hoc modeling? architectural modeling? elaboration? round-trip modeling?

Modeling, in one form or another, is used in every software development effort to turn abstract requirements into a sequence of machine instructions to be executed. As systems grow more complex, with large and changing requirements, complex algorithms, interactions and constraints, a higher level of abstraction and more powerful, expressive models are required.

The unified modeling language (UML) is a standard graphical notation for representing aspects of systems. Use case diagrams help gather and express requirements from the users' point of view. Component and deployment diagrams capture architecture and high level design. Class diagrams capture the abstractions defined in the application. Statechart, activity, sequence and collaboration diagrams describe coarse grained behavior, while action language procedures specify the detailed behavior.

Ad hoc and architectural modeling

Ad hoc modeling is pragmatically focused and limited in scope. While this can be effective, it takes some experience to know when and how to apply models to the problem. Typical ad hoc modeling includes use cases at the requirements stage; component and deployment diagrams for the basic architecture; preliminary class diagrams to determine the main set of abstractions and operations; and statechart or sequence diagrams as necessary to understand some subset of system behavior or interaction. Little tool support is required, but any insight gained will later have to be reconstructed from the code.

Architectural modeling captures the high level structure of a system, and is similar to ad hoc modeling, except that these models are maintained throughout development. Architectural modeling defines the components, libraries, threads, processes and the interfaces and communication mechanisms between them, such as TCP/IP, shared memory, or layered function calls. These are captured in component and deployment diagrams.

Architectural diagrams are typically free from the detailed requirements and design changes that occur during development. The diagrams are easy to maintain and are only changed for large scale design decisions.


Elaboration continues the architectural modeling, adding detail and interpreting the diagrams as work progresses into the coding phase. Often, there is a hazy boundary where design concepts end, and where coding concepts begin.

Due to the high cost of keeping the design diagrams in sync with the ever-changing code, they are often left behind by the development team. Models eventually become a liability, increasingly inaccurate and misleading, and the code becomes the only true view into the system.

Round Trip modeling

This approach captures every aspect of the implementation code in UML. Changes in models are propagated to code, and changes made in code are carried back into models. Tool support is critical to maintaining the proper synchronization between models and code. As development progresses, the focus of effort shifts gradually from modeling to code.

However, the need to capture all implementation details obscures the problem-space abstractions - the original purpose of the models. Most of the advantage in modeling and communicating the problem space is lost in the interwoven complexity. Also, the ability to pull in modified code may lead developers to focus only on the code, when a more appropriate solution would be to refactor the model.

However, round-trip modeling offers some key benefits:

  • It is easily accepted by novice modelers with strong programming backgrounds due to its code focus.

  • Its directness and simplicity are a good match for relatively simple systems or components with a uniform level of abstraction.

  • An accurate graphical representation of the code can convey more information more quickly that reading source code.

    Analysis Modeling

    An analysis model uses UML to model the problem space itself, independent of design and implementation details. A separate, disjoint translation process maps these models to implementation.

    Translation is similar to the operation of a source code compiler. The translator takes in the models, applies transformation rules, and outputs code based on those rules. The rules capture the code implementation patterns and enforce the system architecture automatically. In this approach, the generated implementation code is not changed. Changes are fed back into the models or translation rules and the code is regenerated.

    Trusting that an off-the-shelf translator produces the correct results is risky. Pre-packaged translators cannot possibly meet the architectural, memory, and performance requirements of every project. Translation can guarantee sufficient code only when the end-user project completely controls this translation.

    Analysis modeling offers some key benefits:

  • Analysis modeling maintains an appropriate level of abstraction

  • Complete analysis models are verifiable through execution earlier in the development cycle

  • The models are free from specific implementation dependencies

  • Components are simpler, easier to reuse, and more flexible in the face of changing requirements

    For analysis modeling to be practical, the models must be complete, specifying detailed behavior. Tool support is required to take full advantage of the higher level of abstraction to manage complexity, while maintaining control of the generated code.

    Analysis modeling supports product line development and reuse through model level components independent of design and implementation, and by defining reusable common architectures, encoded in translation rules. For example, applications on a cellphone would share a common architecture, even if they have completely different functions, and a component of a cellphone application could be reused in a mainframe application.

    - Gregory Eakman and Peter Fontana

    Master Consultants

    Pathfinder Solutions

  • Article Comments - Getting the most from unified modeli...
    *? You can enter [0] more charecters.
    *Verify code:


    Visit Asia Webinars to learn about the latest in technology and get practical design tips.

    Back to Top