| Unified Modeling Language |
Article Index for Unified |
Website Links For Unified Modeling Language |
Information AboutUnified Modeling Language |
|
UML is officially defined at the Object Management Group by the UML metamodel (a Meta-Object Facility metamodel serialized in XMI ). UML is a General Purpose Modeling Language . While UML was designed to specify, visualize, construct, and document Software -intensive systems, UML is not restricted to modeling software. UML has its strengths at higher, more Architectural levels and has been used for modeling hardware (engineering systems) and is commonly used for Business Process Modeling , Systems Engineering modeling, and representing Organizational Structure among many other domains. UML has been important in the early ages of Model Driven Engineering or Model-Driven Architecture . By establishing a consensual agreement on the various graphical shapes commonly used to represent common concepts like classes, inheritance, agregation, states, transitions, etc. UML has allowed to concentrate on more fundamental issues. In the initial MDA view, PIMs and PSMs may be expressed in the UML language. It is also possible to transform a UML model serialized in XMI into a Java or EJB implementation by using a Model Transformation Language or MTL. The standard way recommended by OMG for achieving this is to use the newly defined QVT standard. HISTORY When (which was better in analysis) and Grady Booch 's Booch method (which was better in design). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method. In June 1995 the Object Management Group (OMG) put out a call for a common modeling approach to reconcile the greater than 50 named approaches in the market. This effort was pushed significantly by Ivar Jacobson of Objectory and Richard Soley of OMG . In 1995, Rational acquired Objectory and with it got the help of Ivar Jacobson, the developer of the OOSE method. Together, Rumbaugh, Booch, and Jacobson, often called the ''three amigos'', redirected their efforts from developing a unified method to developing a unified notation to answer the call from OMG. With this leadership of three leading OO methodologists at Rational, a team of experts representing many companies was assembled to submit their ''Unified Modeling Language (UML)'' proposal to OMG. In 1996, a team known as the UML Partners was convened for this purpose. The consortium included Digital Equipment Corporation , Hewlett-Packard , I-Logix , IntelliCorp , IBM , ICON Computing , MCI Systemhouse , Microsoft , Oracle Corporation , Rational Software , Texas Instruments , and Unisys . In the complex technical/political negotiations that characterize OMG standard development, the several competitor proposals were either dropped or merged with the UML proposal, adding IBM , ObjecTime , Platinum Technology , Ptech , Taskon , Reich Technologies , and Softeam to the UML Partners. By the fall of 1997, after much public review and comment, the UML standard, (by now called UML 1.1) was approved by OMG. As a notation, the influence of the OMT style is most apparent (e.g., in boxes for classes and objects). Though the Booch cloud notation was dropped, the Booch capability to specify lower-level design detail was embraced. The concept and notation of Use Case s (from Objectory) was integrated into the notation. Concepts from many other software-development methods (e.g., Class-Relation (circa 1994 from the French company Softeam), CRC Cards (circa 1989 from Kent Beck and Ward Cunningham ), and OORam ) were subsumed under the idea of supporting all these methods with a single modeling language. UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but large. It is now an international standard: : ISO / IEC 19501:2005 Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2 UML has since been revised and grown, with several releases (the major being UML 1.3 and 1.5), fixing some dead ends and adding new notational capabilities. Many industry firms have now contributed to the standard. The current standard is UML 2.0., a major rewrite. The latest UML version prior to 2.0 was 1.5; this 1.5 version will continue to be the official current version until all four components of UML 2 are completed and ratified. The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other parts of UML 2, notably the infrastructure, the object constraint language ( OCL ) and the diagram interchange were yet to be completed and ratified as of November 2005. The final UML 2.0 specification has been declared ''available'' and has been added to OMG's formal specification library. The other parts of the UML specification, the UML 2.0 infrastructure , the UML 2.0 Diagram Interchange , and UML 2.0 OCL specifications have been ''adopted'' but are not yet considered ''available''. As change is inevitable, a UML 2.1 revision has been underway for some time now. The outcome of this work should be available soon (first semester 2006) in the form of an XMI 2.1 version of the UML 2.1 version. The corresponding XMI 2.1 file will be made available from the OMG ADTF group. Most of the commercially successful modeling tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time for the tools that are in the hands of the developers to reach this level of compliance. METHODS UML is not a method by itself, however it was designed to be compatible with the leading object-oriented software development methods of its time (e.g., OMT , Booch , Objectory ). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (e.g., OMT) and new methods have been created based on UML. Most known is Rational Unified Process (RUP) created by the Rational Software Corporation. There are many other UML-based methods like Abstraction Method , Dynamic Systems Development Method , and others, designed to provide more specific solutions, or achieve different objectives. MODELING It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — textual documentation such as written use cases that drive the model elements and diagrams. There are three prominent parts of a system's model: ''Functional Model'' : Showcases the functionality of the system from the user's Point of View. : Includes Use Case Diagram s. ''Object Model'' : Showcases the structure and substructure of the system using objects, attributes, operations, and associations. : Includes Class Diagram s. ''Dynamic Model'' : Showcases the internal behavior of the system. : Includes Sequence Diagram s, Activity Diagram s and State Machine Diagram s. Models can be exchanged among UML Tool s by using the XML -based XMI format. DIAGRAMS ]] In UML 2.0 there are 13 types of . To understand them, it is sometimes useful to categorize them hierarchically, as shown in the hierarchy chart on the right. ''Structure Diagrams'' emphasize what things must be in the system being modeled:
''Behavior Diagrams'' emphasize what must happen in the system being modeled: ''Interaction Diagrams'', a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols. UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0. Diagrams can be exchanged among UML tools by using the Diagram Interchange standard known as XMI (also DI, XMI {Link without Title} ) . In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram. CONCEPTS UML uses the following concepts: ''For Structure'' : Actor , Attribute , Class , Component , Interface , Object , Package . ''For Behavior'' : Activity , Event , Message , Method , Operation , State , Use Case . ''For Relationships'' : Aggregation , Association , Composition , Depends , Generalization (or Inheritance ). ''Other Concepts''
CRITICISM Although UML is a widely recognized and used standard, it is criticized for the following deficiencies: # Imprecise semantics. This leads to subjective interpretation and difficulties in the formal test phases of development. In one remedy to this form of misinterpretation, authors provide some form of explanation of their models in the form of narration or copious diagram notes. # Not applying well to distributed systems. In such systems, factors such as serialization, message passing and persistence are of great importance. UML lacks the ability to specify such things. For example, it is not possible to specify using UML that an object "lives" in a Server process and that it is shared among various instances of a running Process . The constraints of distributed system development are not an inherent part of UML, much as the plot of a novel is not part of the rules of grammar. # Insufficiency for business applications. UML is also considered to be incomplete for business application development and that it needs to be extended beyond object and component technology to make it useful. Most business systems have user interfaces on the front end, and databases on the back end, yet the UML does not have standard ways to model either. # Bloat. UML is often considered to be too bloated, too fine-grained in many aspects. Though details best captured in source code may be difficult to capture using UML notation, people often try to do so. The requires an expressive, general notation such as UML 2.0. # Complexity. One problem leading to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them. An ACM article, '' Self-diagnosis and early treatment are crucial in the fight against UML Fever '' is an amusing but all-too-true account of this and related issues. # Only the code is in sync with the code. Another perspective holds that it is a working system that is important, not beautiful models. As Jack Reeves succinctly put it, "The code is the design." Pursuing this notion leads to the need for better ways of writing software; UML has value in approaches that '' Compile The Models '' to generate source or executable code. This however, may still not be sufficient since UML as a language does not exhibit Turing Completeness , and any generated source or executable code would be limited to what a UML interpreting tool can discern or assume. One the other hand, perhaps you should just [http://www.agilemodeling.com/essays/whiteboardModeling.htm sketch your models on a whiteboard and then code from there. EXTENSIONS When it is necessary to introduce new notations or terminologies, UML provides user-defined extensions through the use of stereotypes, tagged values and constraints. Currently there are two extensions defined, namely Business and Objectory Process extensions.
SEE ALSO
REFERENCES EXTERNAL LINKS
Related Concepts
|