- History of Modeling Tools
- Designing an Application
- Modeling a Web Application
- System Modeling
- The Unified Modeling Language
- Modeling Web Pages
- EJB UML Mapping
- Tool Support
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Unified Modeling Language
The strength of UML is rooted in its semantics as well as the metamodel that forms a foundation for future methods. The metamodel is one layer of a four-layer metamodeling architecture. In a metacircular manner, it specifies itself using a subset of UML object-oriented notation.
Through the unification of leading object-oriented methods founded on a wide base of user experience, UML provides the basis for an object-oriented analysis and design standard. Standardization of a language can become the foundation for tools and processes as well. The Unified Modeling Language is an object-oriented modeling language for specifying, visualizing, and documenting the artifacts of an object-oriented system during development. It combines concepts including Booch-93, OMT-2, and OOSE, resulting in a single, common, and widely usable modeling language for users of these and other methods.
Users of any object-oriented method can usually learn enough to achieve the same level of expressiveness fairly quickly. UML is appropriate for real-time systems, providing support for modeling classes, objects, and the relationships among them. These relationships include association, aggregation, inheritance, dependency, and instantiation. Use cases are directly supported with scenarios for detailed descriptions of required system behavior. Model scenarios are graphically represented through interaction diagrams that can include both timing and message synchronization annotations. Real-time features are supported through enhanced finite state machine modeling, including concurrency, event propagation, and nested states. The UML is extensible through the definition of additional stereotypes.
Many CASE tool vendors have committed to supporting the UML, so it will likely remain the standard notation for object-oriented systems development for the foreseeable future.
Goals and Principles of the UML
Devising a notation for use in object-oriented analysis and design is somewhat like designing a programming language. First, the author must define the problem, answering questions such as Should the notation encompass requirements specification? and Should the notation extend to the level of a visual programming language? Secondly, a balance between expressiveness and simplicity must be achieved. A notation that is too simple will limit the breadth of problems that can be solved, while one that is too complex can be overwhelming for the developer. If the methods already exist, too many changes may confuse existing users. On the other hand, not advancing the notation may eliminate the possibility of engaging a broader set of users.
The UML has seven goals:
-
To provide users with a ready-to-use, expressive visual modeling language for the development and exchange of meaningful models
-
To provide mechanisms for extensibility and specialization in order to extend the central concepts
-
To be independent from specific programming languages and development processes
-
To provide a formal foundation for understanding the modeling language
-
To encourage further development in the OO tools market
-
To support higher-level development concepts including collaborations, frameworks, patterns, and components
-
To integrate best practices
A metamodel was created in order to offer a common, clear-cut statement of the method's semantic model. Once this metamodel was developed, decisions about the surface graphical syntax for the visual elements of this model were taken. A number of principles to guide these efforts have been established:
Simplicity—A method should only require a few concepts and symbols.
Expressiveness—A method should be applicable to a wide variety of production-quality systems.
Usefulness—A method should only focus on elements that are meaningful to practical system and software engineering.
Common problems—These should be simple to model. More rare problems should still be expressible, but may require some complexity corresponding with their frequency of use.
Self-consistency—The same concept and symbol should be used in the same manner throughout the method.
Orthogonality—Unrelated concepts should be modeled independently.
Advanced concepts—Layers of advanced concepts should be treated as additions to the method for more basic concepts.
Stability—Concepts and symbols that are already commonly understood and used should be adopted.
Printability—The approach to visualization should be based on a format that can be extended. Users should be able to sketch out the method manually or display it as a printed image.
Adaptability—Extensible users and tool builders should have the ability to extend and adapt the method.
Devising real methods requires balancing each of these principles.
Conventions and Terminology
In UML, the explanation of each element follows a simple pattern. The semantics of the concept are described, followed by its graphical syntax. The following subsections may be found within each section:
-
Semantics—This subsection provides a brief summary of semantics. For a fuller explanation and discussion, locate the UML Semantics document by searching for it by keyword on OMG's document search page at http://cgi.omg.org/cgi-bin/doclist.pl.
Notation—This subsection explains the notational representation of the semantic concept, not always in a separated subsection.
Presentation options—This subsection describes various options in presenting the model information, such as the ability to suppress or filter information, alternate ways of showing things, and alternate ways of presenting information within a tool.
We will discuss the underlying principles and/or relevance of each element that is explained and will provide a simple example of its use, an explanation of any recommended idioms, and hints that will help both users and tool builders.
This section is arranged according to diagram types, including the model elements found on that diagram as well as their representation. Many model elements can be used in more than one diagram; therefore, the description has been placed where it is used the most.
The metamodel layer can be thought of as a framework of subsections describing concepts of the underlying layer. The metamodel layer describes the subsections that will be used to describe the features of the UML concepts for object-oriented modeling on the model layer. In this case, metaclasses forming top-level packages on the metamodel level along with classes on the model level can be described as using the subsections Attributes (class attributes) and Associations (relationships between class instances).
The UML metamodel can be broken down into several top-level packages. The Foundation and Behavioral Elements packages are described in the following sections.
The Foundation Package
The Foundation package is composed of the Core, Auxiliary Elements, Extension Mechanisms, and Data Types subpackages, which are defined here:
Core—This includes a Model Element, Generalizable Element, and Classifier. Specified constructs include Class, Attribute, Operation, and Association. This package specifies the core constructs required for a basic metamodel, defining an architectural backbone for the attachment of additional language constructs such as metaclasses, meta-associations, and meta-attributes.
Auxiliary Elements—This package defines additional constructs that extend the core to support advanced concepts such as dependencies, templates, physical structures, and view elements.
Extension Mechanisms—This package specifies how model elements are customized and extended with new semantics.
Data Types—This package defines basic data structures for the language.
The Behavioral Elements Package
The Common Behavior package is the most fundamental of the subpackages that make up the Behavioral Elements package. This package specifies core concepts that are required for dynamic elements and provides the infrastructure to support the Collaborations package, the State Machine/Activity package and the Use Cases package. The Collaborations package specifies concepts required for expressing how different elements of a model interact with each other from a structural point of view. The State Machine package specifies a set of concepts that can be utilized for modeling behavior through finite state-transition systems. It also relies on concepts that are defined in the Common Behavior package, allowing integration with the other subpackages within Behavioral Elements. The Use Cases package specifies concepts utilized for defining the functionality of an entity such as a system. The elements in the Use Cases package are used mainly to define the behavior of an entity such as a system or a subsystem without specifying the internal structure. The key elements in this package are UseCase and Actor. See Figure 3.12 for a use case diagram of the SilverBooks sample application including the actors (portrayed as stick figures).
){kind=link}
Figure 3.12 Sample application use case diagram.
Rational Rose 2000, by Rational Software Corporation, is a visual modeling tool that assists teams practicing iterative software development. The tool features multiuser support for round-trip engineering supporting C++, Java, and J2EE/EJB1.1. It supports the UML, including use cases, the Booch method, and the Object Modeling Technique (OMT). With the information contained in an application model, Rational Rose can generate both relational database schemas and CORBA 2-compliant IDL source code. Rational Rose 2000 includes portions of BEA's WebLogic Products for implementation of EJB 1.1. Go to http://www.rational.com for more information on Rational Rose.
Together ControlCenter by TogetherSoft (http://www.togethersoft.com/) is the development platform for building enterprise solutions. Its platform and building blocks technologies feature an end-to-end development environment that attempts to integrate the design, deployment, debugging, and administration of complex applications. See Figure 3.13 for an example of the tool's look and feel.
){kind=link}
The latest version of ControlCenter has several new features and improvements. They are listed here:
Diagram editor advances—new folded compartments, snap-to-grid, Web application diagrams, robustness diagrams
Programming editor advances—new deep-search usage, JSP and HTML syntax, javadoc code completions, keyboard shortcuts for bookmarks
JSP advances—new JSP/HTML editor, plus deployment and debugging with Tomcat
Servlet advances—complete servlet modeling and generation
EJB advances—new 2.0 support, EJB verification, works with over a dozen leading application server products
Audit and metrics—results to HTML, plus new C++ support
XML Metadata Interchange (XMI)—full and complete coverage in accordance with the Unisys standard
Figure 3.13 Together modeling tool.