Home arrow Practices arrow Page 3 - Design with ArgoUML

Model-Driven Architecture and the UML - Practices

This article provides an overview of the practical application of object-oriented analysis and design (OOAD) design concepts and the Unified Modeling Language (UML). It is taken from chapter two of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259)

  1. Design with ArgoUML
  2. The Unified Modeling Language
  3. Model-Driven Architecture and the UML
  4. Design Roadmap
  5. The Editing Pane
  6. Drawing Diagrams in ArgoUML
  7. Object Modeling Using Archetypes and Color in UML
  8. Adding Modeling Elements to the Class Diagram
  9. Assigning Archetypes and Creating Associations
  10. Use Case Modeling
  11. Refining Use Cases with Sequence Diagrams
By: Apress Publishing
Rating: starstarstarstarstar / 35
August 25, 2005

print this article



Where is the UML headed? How will it affect enterprise Java development in the future? These are questions that many developers think about. Field experience tells you that the UML currently has an impact on the initial stages of analysis and design of a J2EE system, but its usage sharply dies off after this stage. The OMG is strongly promoting the concept of a Model-Driven Architecture (MDA) in which applications (with the help of the UML) are defined in a completely technology-independent fashion and are then realized in an given platform such as CORBA, .Net, or J2EE.

The MDA is the next step in the evolution of the software-engineering practice and places the model as the centerpiece of your trade. In essence the MDA concerns itself with specifying a system independently of a platform, specifying platforms, and then transforming a system’s specification into an implementation given a chosen platform. Its primary goals are portability, interoperability, and reusability.

Open Source MDA tools are beginning to emerge, such as AndroMDA, which generates Enterprise JavaBeans (EJB) components from a properly annotated (using stereotypes) component model file in eXtensible Metadata Interchange (XMI) format.


Future of the UML and Java

As with any committee-driven initiative, it’s expected that the OO languages that the UML is meant to support will evolve at a faster pace than the UML. Emerging component architectures like EJB and new service-oriented paradigms like web services are currently partially supported via some of the extension mechanisms previously mentioned in this chapter. Using a UML profile such as the one proposed by JSR 26 (UML/EJB Mapping Specification) will standardize the extensions used and enable tool interoperability.


JSR 26, the UML profile for EJB, defines extensions that will enable tool vendors to standardize on a set of UML extensions used to annotate models in a way that they can be used to generate EJB components. Also the extension will enable the reverse engineering of a system composed of EJBs into a UML model. The EJB-JAR format is targeted as a possible carrier for a “UML Descriptor for EJB,” which is an XML file that “identifies UML models stored in the same EJB-JAR and their relationship to EJBs in the EJB-JAR”.6 Enterprise tools could then use these store descriptors for automation and reflection.

But you could argue that if UML profiles proliferate at too high a rate, the UML will become a fragmented beast representative of the problems it was created to solve in the first place. A delicate balance must be achieved by the OMG between adding new concepts to the core of the UML and the liberal use of the extension mechanisms.

Like any general-purpose technology in the rapidly changing landscape of today’s technology, the UML is still a work in progress and it will probably remain that way for the foreseeable future.

Expect Java development to further benefit and extend from the new enhancements to the UML. Problems such as the impedance mismatch between objects and relational databases are being addressed at a conceptual level within the UML. Tool interoperability is slowly becoming a reality with XMI, which goes to show how XML is slowly finding a place within the UML. The ability of business rules to be expressed in the context of an object model is gaining ground with the usage of the Object Constraint Language (OCL).

The notion of executable UML models is rapidly gaining followers in the world of embedded and real-time systems. Executable UML models are an attempt to once again raise the level of abstraction at which humans deal with problems and their solutions. Several efforts are underway to make executable UML a reality, and it’s expected that yet another breed of tools will emerge and that the lessons learned will trickle down into the UML specifications. The OMG and their MDA envisions the complete specification of systems using models. These models are built on a Platform-Independent Model (PIM) that models a solution without any ties to a specific implementation technology. In the fall of 2001, the OMG extended the semantics of the UML with a very complete set of semantics for actions defined at a very high level of abstraction. UML models will rely on these actions to accurately translate models into executable systems. Executable UML is more that just mere forward engineering; it’s a move upwards to a higher level of abstraction that makes code a rarely seen low-level entity as obscure as CPU registers are to a Java developer.

Code Generation and Round-Trip Engineering

Many of the OOAD CASE tools available nowadays feature both code generation and forward and reverse (round-trip) engineering of models to code and vice versa. Knowing when to use those features is a judgment call that must be based mostly on the capabilities of a given tool.

In the Java world, round-trip engineering is gaining new ground as tool vendors experiment with the concepts of MDA, Metadata (see Java Metadata Interface (JMI) specification, JSR 40) and the previously mentioned UML profile for EJB. Tools like AndroMDA are paving the way for the creation of J2EE components from a UML model.

In iterative development, reverse engineering can help in the discovery of potential areas of code reuse, in the application of design patterns, and with possible structural problems such as high coupling and low cohesion. Possible encapsulation and the discovery of component interfaces are activities that can also benefit from a process of reverse engineering. Also, in the case for which there is an existing code base—which is a typical case in the industry because unfortunately most projects seem to go through more than one attempt—reverse engineering can help you determine what code can be reused and what needs to be thrown away. In the absence of documentation, some of the lessons learned in any previous attempts might be revealed for the benefit of the current effort.

In combination with forward engineering, CASE tools can help a system remain true to its architectural vision by providing near-instant feedback on the results of an iteration, and allowing for corrective and preventive measures to be taken.

That said, it’s important to point out that code generation and round-trip engineering are in their infancy and you must take care not to get caught in a cycle of manually correcting poor, skeletal code.

Methodologies, Processes, and the UML

Most modern methodologies have adopted the UML as the foundation for their notations. That said, it’s important to note that the UML doesn’t impose a specific methodology or process, yet it enables a model-driven, architecture-centric, iterative and incremental process especially suited to work with distributed, object-oriented, component-based systems. The UML is therefore an enabling force that encourages the application of methodologies in the form of processes.

There are a variety of methodologies and processes, and an equally large set of reasons why one might be a better fit for a particular development effort. Factors such as the personality makeup of a development team, the size and scope of a system, and the target architecture all weigh heavily in deciding what methodology to follow. Experience shows that no methodology is a perfect fit for every organization and for every system. But most experts in the industry seem to agree that any semblance of a process is better than no process at all. Of course, devotion to process for the sake of process leads to what Steve McConnell refers to as “cargo cult organizations”7 in which there is the perception that the production of process-related documentation guarantees a project’s success. But the reality is that the combination of a committed team and the right amount of process are key to a project’s success.

Most successful contemporary methodologies share one common trait: None are linear. Iterations, with discovery, assessment, and enhancement cycles, are the norm. Waterfall or “big-bang” development has proven ineffective and inflexible when dealing with the dynamic nature of contemporary applications. Incremental development with small, well-defined models and test-driven deliverables are winning the race and delivering on-time and on-budget quality software systems.

In the neverending debate over methodologies, contrasting lines have been drawn between the so-called heavyweight methodologies and their counterparts: the lightweight or agile methodologies. Describing and comparing both methodologies and process types is rather difficult. No proponent of a methodology refers to it as a heavyweight methodology; the term has been coined in a negative context to mean that a methodology focuses excessively on the actual process and documentation and not on the results. Agile methodologies have risen out of the frustrations caused by negative experiences in trying to follow rigid and predictive methodologies. By adapting rather than predicting, agile methodologies acknowledge that a map is hard to follow when the landscape is constantly changing. Agile methodologies focus on people first by accommodating the way programmers work and viewing coding not as a construction-only phase but also in large part as a design-refinement phase. This notion is a notable departure from the usual analogies to the construction trade, in which design is thought of as a creative process and construction is a repetitive, manual process. Agile methodologies view coding as an extension of the design as well as an equally creative process. Because creative processes are quite hard to predict, as agile proponents claim, it’s very hard to control such a process with a methodology that’s rigidly designed to control predictable processes.


It bears mentioning that proponents of methodologies considered heavyweight or formal are quick to show that their methodology can be implemented as a light or agile process. One common example is the Rational Unified Process (RUP) for which there are several references in the literature on how to implement an “RUP instance” in an agile fashion.

In this book you’ll draw ideas and best practices from several of the most prevalent methodologies. You’ll use ideas from the Unified Process (UP)8, Feature-Driven Development (FDD),9 and Extreme Programming (XP).10 As a guide for newcomers to the modeling world, the OMG suggests that you first select a methodology and then find a UML modeling tool that best supports it. Your approach will be simpler and much more cost effective, when possible, and for the sake of continuity you’ll use a tool that will enable you to evolve your models as your system development gets under way. Current tools aren’t as flexible as you’ll want them to be and aren’t conducive to collaborative work in the way that a simple whiteboard and a set of markers are. Therefore, if the tool is getting in the way of progress put it aside and go the low-tech way!

Methodology Lessons Learned

We’ve listed a brief set of best practices or general guiding principles from the methodologies previously outlined. These methodologies share many common traits that can be used by anyone to improve the quality of software.

A development model is needed to guide, document, and provide feedback to the customer, stakeholder, or client. In the race to deliver quality software on time and on budget, several methodologies have evolved to mitigate the often drastic trade-off between quality, time, and cost of construction. Most contemporary methodologies acknowledge the following:

  • Feedback to the customer in the form of working software, as opposed to reports or mockups, is of the utmost importance for a project to remain alive.


  • Any processes need to strive to minimize the overhead of applying the process. Programming is a creative endeavor and an overly constrained process is a quick way to kill creativity.



  • Models are only good if they guide the development of a system. A model is nearly useless in practice if the resulting code base isn’t a reflection of the models.


  • No methodology is a one-size-fits-all solution. Some work better with different team personalities, different project domains, and different levels of project complexity and different team sizes. If a model-driven methodology is selected hastily, it’s never too late to switch into a more appropriate methodology. The UML can make this transition smoother by enabling models to be universally usable by any methodology or process.


  • If at all possible, reinforce a methodology by selecting a CASE tool that enforces the values and practices of said methodology. But if no available CASE tool fits your team’s work methodology you can always rely on low-tech approaches to successfully mitigate the task of modeling.


We encourage teams to borrow practices from different methodologies. After all, only the application of a practice can help you discern those based purely on theory from those based solely on practice. For example, we usually borrow ideas from Jeff Sutherland’s SCRUM project’s management methodology, which includes daily SCRUM meetings in which we ask ourselves what has been accomplished since our last meeting, what roadblocks we’ve encountered, and what we plan on doing between now and the next meeting. Other practices we subscribe to include the minimization of static modeling and active on-the-job knowledge transfer.


SCRUM is a lightweight, agile way to manage a project that shares many of its ideals with XP. Like XP, it’s centered on the concept of an iteration as a period of planning and execution that results in a perceivable and measurable value. In SCRUM, a daily iteration is called a “scrum” though the external iteration is termed a “sprint,” which is a manageable “scrum” collection that makes up a milestone (usually not more than 30 days).

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: