|
The Unified Modeling Language |
UML Resources Home |
||||||||||||||||||||||||||||||||||||||||||||
|
HOME
UML links |
Setting the scene Statistic: 90% of software is not delivered on time or within budget or both. Question: How can this be changed?A building architect would not imagine constructing a building without a blueprint. A software architect’s blueprint is modeling. Visual modeling captures business processes, it is a communication tool, it manages complexity, it defines the software architecture and it promotes reuse. The Unified Modeling Language (UML) is the standard language for visualizing, specifying, constructing and documenting the artifacts of a system. It can be used with all processes, throughout the development life cycle and across different implementation technologies. Answer to previous question: With good use of the UML.History of UML From the early 1980s, many object-oriented (OO)
methodologies have emerged, each specifying a notation and a process.
Some of the most prominent were the Booch method, Jacobson’s OO
Software Engineering, Rumbaugh’s Object Modeling Technique (OMT),
Fusion and Shlaer-Mellor. Most methodologies shared the same concepts
but differed in notation. By the end of 1995 Grady Booch, James Rumbaugh
and Ivar Jacobson (‘the three amigos’) were working at Rational to
unify their methods and thus to provide stability to the OO
marketplace. The result was the UML version 0.9, which was submitted
in mid-1996 to the Object Management Group (OMG). UML gained industry
support and a UML consortium was established that included Microsoft,
Hewlett-Packard and IBM amongst other industry leaders. In early-1997
version 1.0 documents were released; by mid-1997 the consortium was
hugely expanded and by late-1997 version 1.1 of the UML was submitted
to the OMG for standardization. In the same year OMG adopted the UML,
the maintenance of which was taken over by the OMG Revision Task Force
(RTF). The current version of the UML is 1.3 (adopted mid-1999).
Quick Overview of UML Complex systems are best viewed from several different perspectives. The system architecture in UML is described by five complementary views: use-case view, logical view, implementation view, process view and deployment view. A view is not a graph, but an abstraction consisting of a number of diagrams. A diagram is a graph and UML has nine different diagrams that combined provide a complete picture of a system. The diagrams are: use-case diagram, class diagram, object diagram, state diagram, sequence diagram, collaboration diagram, activity diagram, component diagram and deployment diagram. Next, we briefly describe the views and diagrams of UML. The use-case view describes the functionality of the system from the system users’ perspective. In this context, the user could be another system or an actual person and they are called actors. The view is composed of use-case diagrams and activity diagrams. It is central to understanding the whole system. The logical view looks inside the system describing how the system functionality is provided. The static aspects of the system are captured in class and object diagrams; the dynamic aspects are captured in state, sequence, collaboration and activity diagrams. This is also a very important view as it uncovers most of the system’s vocabulary. The process view concentrates on the
dynamic aspects of a system (such as processes, processors and
threads) and is composed of state, sequence, collaboration and
activity diagrams with a focus on the active classes. The implementation view is a description of the implementation modules/files (that are used to assemble and release the physical system) and their dependencies. It is composed of component diagrams and is of greater importance to programmers. The deployment view shows the hardware topology (e.g. computers and devices) on which the physical system executes. Hardware elements are called nodes. The view is composed of deployment diagrams. The diagrams: A use-case diagram shows actors and their relationship to use cases. Use cases are descriptions of a functionality that the system provides. They are described only as viewed externally by the actor. Use-case diagrams are essential to capturing requirements. A class diagram shows a set of classes, interfaces, their internal structure (in terms of attributes & operations) and their relationships. Kinds of relationships are: dependency, association, generalization and realization. Class diagrams remain valid at any point in the system’s life cycle; they are the most common diagrams found in models of OO systems. An object diagram differs from a
class diagram in that it shows a number of instances of classes rather
than actual classes. It shows an example of a class diagram that shows
what the system could look like at some point in time. Object diagrams
are used to exemplify complex class diagrams. A state diagram addresses the dynamic view
of a system. It can be seen as a complement to the description of a
class. It shows all possible states that objects of the class can have
and emphasizes the object’s event-ordered behavior. State diagrams
are not drawn for all objects rather for the more complex ones. Sequence and collaboration diagrams are often referred to as interaction diagrams. Interaction diagrams address the dynamic view of a system showing the sequence of messages between a number of objects. Sequence diagrams emphasize the time-ordering of messages and collaboration diagrams emphasize the structural organization of the participating objects. Activity diagrams are variants of state diagrams. They emphasize the flow of control among objects within a system but not in response to external events rather to internal processing. Activity diagrams focus on work performed in the implementation of an operation. A component diagram shows the physical structure of the code in terms of code components. It may also shows dependencies between components and any interfaces they expose. Components, here, include source code or executables. Component diagrams provide the mapping between the logical and the implementation view. A deployment diagram shows the configuration of run time processing nodes and the components that live on them. Deployment diagrams are especially useful for distributed or embedded systems. We should note at this point that few systems (very large, very complex and with rigid documentation requirements) would be modeled utilizing all nine types of diagrams. The concepts used in diagrams are called model elements. Model elements can be used in several different diagrams but there are rules that control this. UML also utilizes some general mechanisms, for additional information, in all diagrams such as adornments or notes. Also defined in the UML are extensibility mechanisms such as stereotypes. [also see diagram] It should be apparent that there is no prescribed process in UML. In order to get full benefit from UML, consider choosing a process that is use case driven, architecture-centric, iterative and incremental. Finally, in 'serious' projects, the use of UML should be supported by a suitable CASE tool. UML CASE tools vary in functionality ranging from drawing diagrams and acting as a repository to round-trip engineering and multi-user support. In any case, consider choosing a tool that adheres to the standard (and does not add ad-hoc extensions) and that provides cross-tool compatibility. For more on UML visit sites from the 'UML Links' page and study through the material on the 'UML seminar' page.
Bibliography (for project)
|
