Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Executable UML: Diagrams for the Future  : Page 3

Executable UML marries an abstract program model with a platform-specific model compiler that outputs an executable application. If successful, this combination holds the potential for a major shift in development tasks.


advertisement
Executable UML: Why the Book Is Important
Although Stephen J. Mellor and his late colleague Sally Shlaer are two of the seminal thinkers behind MDA, they are rarely given credit in either the OMG's public records or elsewhere. Their early work with the arguably ill-named Recursive Design was completely isomorphic with the principle tenet of MDA, namely that an implementation-neutral yet complete specification or solution could be translated through mapping into a target implementation. Shlaer-Mellor Object-Oriented Analysis (SM-OOA) was an early object development method and notation centered on such a translative approach. It was mildly popular in certain development niches, particularly in the real-time and embedded systems world. The notational consolidation that gave rise to UML effectively delivered a knockout blow to SM-OOA as a notation but perhaps, as we shall see, not as a method. The consolidation of the notational styles and artifacts of Booch, Rumbaugh, and Jacobsen into one "unified" whole—UML—is to the modeling community what paella is to the Spanish kitchen: throw whatever you have into the pot. Unfortunately, what is delicious in a culinary sense has become to the modeling community a rather complex and intertwined set of artifacts that often leaves the novice overwhelmed and may indeed steer developers away from using UML. In an ideal world, given unlimited resources, the full UML can theoretically be used to create the perfect software. In practical terms and in most practice, a subset of UML is sufficient to create useful software for real world needs. This pragmatic approach gives rise to the notion of UML profiles. A UML profile is a subset of UML that is necessary and sufficient for a given development effort.
The consolidation of the notational styles and artifacts of Booch, Rumbaugh, and Jacobsen into one "unified" whole—UML—is to the modeling community what paella is to the Spanish kitchen: throw whatever you have into the pot.
In their book Executable UML: A Foundation for Model-Driven Architecture, Mellor and co-author Balcer offer a profile of UML that is unapologetically equivalent to the artifacts used in SM-OOA, albeit using UML notation. The authors go as far as to say, "Executable UML brings Shlaer-Mellor and UML notation together by using UML notation and incorporating concepts of execution." In other words, the authors have conceded the notational battle, but still favor translation over elaboration (see the sidebar The Three Amigos). There are a few minor changes, such as the absence of a requirement for identifiers and referential attributes, which differentiate the UML profile defined by Mellor and Balcer from pure SM-OOA. But overall, their UML profile and its usage is essentially SM-OOA: this is not necessarily a bad thing, given the conceptual similarity of SM-OOA and MDA.

The book uses only four artifacts of UML: Packages, Class Diagrams, State Models, and a semantically valid action language. The authors contend that, for a large class of applications, these are the only constructs needed to create a complete, consistent, and verifiable model of an application that can be mapped onto and executed within a VEE. Packages provide the structural elements necessary to separate the various subject matters of an application development effort into domains. To appreciate the use of the other three artifacts, consider the abstract programming model of data, control, and algorithm: Class Diagrams provide the specification of the data, State Models provide the specification of control, and the action language provides the specification of algorithm. Modelers make these specifications are made at a higher level of abstraction than is possible in a third generation language. The intellectual capital captured in the models is protected from the evolution of execution technology because there is a clear separation between the specification of the solution and its implementation. All that is needed to execute the solution is a VEE and the appropriate mapping from the model into that VEE. This mapping is accomplished by the use of a model compiler.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date