http://www.jot.fm/issues/issue_2005_08/article4/ http://freedownloads.rbytes.net/cat/development/c-all/enterprise-architect-for-uml-2.

0/

Toward Engineered, Useful Use Cases

Clay Williams, IBM T.J. Watson Research Center Matthew Kaplan, IBM T.J. Watson Research Center Tim Klinger, IBM T.J. Watson Research Center Amit Paradkar, IBM T.J. Watson Research Center Abstract

REFEREED ARTICLE

PDF Version

We explore common problems that exist in the practice of use case modeling: lack of consistency in defining use cases, misalignment between the UML metamodel and the textual representations of use cases expounded in the literature, and the lack of a semantics that allows use cases to be executable and analyzable. We propose an engineering approach to the issues that can provide a precise foundation for use case development. We next discuss four potential uses of such a foundation and identify the research problems that must be addressed to support these applications.

1 INTRODUCTION
Use cases were developed as a technique for capturing the required behavior of a software system. [Jacobson92] While they have been successful in having an impact on software development, their usage is not as prevalent as we believe it could be. Several potential factors account for this, including: 1. Confusion regarding the meaning of the term use case. Different approaches advocate graphical versus textual methods. Further confusion arises as levels of abstraction vary widely within and across projects using use cases. 2. Misaligned characterizations of use cases in the UML metamodel. In UML, use cases are characterized as BehavioredClassifiers, which does not correctly support the best practices for representing use cases that have been proposed. [Armour01, Cockburn01] 3. Use case semantics are poorly defined, limiting their usefulness to primarily being vehicles for communication. While this is an important use for them, wider industrial use requires that they support machine based processing and analysis. This paper is a philosophical and conceptual exploration of each of these points in detail in which we identify potential solutions that support an engineering approach to creating use cases. However, engineering use cases is not an end in itself the

technique must provide value across multiple dimensions to be adopted in an industrial setting. To support our approach, we discuss four potential uses of such a foundation (prototyping, estimation, refinement to design, and test generation). We close by discussing related work and future research.

2 USE CASE CONFUSION

Across projects, use cases exist at multiple levels of abstraction and are captured in many different notions. The leading practitioners [Armour01,Cockburn01] all advocate similar content that includes preconditions, main (success) sequences, alternative/exceptional sequences, and postconditions. We believe that this serves as a good basis for an engineered use case representation, but more detail is needed to define what the sequences contain. Another issue is that it is not uncommon to see use cases used across widely different levels of abstraction, from high level usage of a system to extremely detailed descriptions of system behavior. This lack of consistency regarding the level of use case abstraction is directly influenced by the content supported within a use case model. We take the position that the most useful use cases are those that Cockburn calls sea level use cases [Cockburn01], which are defined at the user-goal level. Our desire is to make constructing good sea level use cases as intuitive and repeatable as possible. A second goal of our representation is to enable the capture of precise, analyzable, and executable use cases with as little modeling and information required as possible. We start by defining a precise contextual foundation for use cases. Use cases are usually collected during the inception phases of a project. They allow the system requirements to be specified by saying what the system will do without saying how it does it. This requires the capability to talk about the key elements in the system in a very precise way. However, inception occurs prior to architecture definition and design, so we must carefully define the context against which use cases are developed in order to achieve this precision. This context is the domain model of the system. A domain model is a model of the significant elements from the systems application domain. These are the elements that will be created, modified, and used in the application. They are represented as UML classes with attributes. Also present in the domain model are domain rules (or invariants,) which capture constraints that must hold for instances of the domain objects to be valid. Figure 1 shows the domain model for a simple example ATM application. The domain model plus the four primitive types (Boolean, float, integer, and string) serve as the type system for detailing use cases. Use cases are typically defined as sequences of actions that occur between the system and one or more actors, but the specifics of the action types that are supported are left undefined in UML. In our scheme, use cases support 4 basic actions and 4 flow-of-control actions, each of which has an associated statement for use in detailing the use case.

Fig. 2. The UML 2.0 Metamodel Basic Actions:

Input an actor provides input to the use case Output the use case returns output to an actor Computation a computation is performed using provided input and domain instance information. Computation entails creating, modifying, or deleting instances of domain classes. Exception Handling the system responds to an issue with the input or state of the domain model instances.

Flow of Control Actions:

Selection allows the use case to conditionally execute actions Iteration allows the use case to repeatedly execute an action sequence Inclusion allows the use case to include the behavior of another use case Extension defines the extension point for an extending use case

Use cases also have preconditions and postconditions, and both are written in terms of the domain model. Below is an example use case for the Withdraw Money capability for an ATM system.

This example illustrates the four primary types of statements that can occur in a use case: input statements, computation statements, output statements, and exceptions. The example also illustrates selection actions and rejoining the main scenario from an exceptional alternative. This representation (use cases, a high level domain model, and domain invariants) serves as a basis for engineered use cases. The use cases consist of very specific types of actions. They specify, in terms of the domain model, what occurs in an interaction with the system being specified without saying how it is done.

3 METAMODEL ALIGNMENT FOR ENGINEERED USE CASES

UML 2.0 Use Case Shortcomings Figure 1 shows the current metamodel for UML 2.0 use cases [UML02].

Fig. 2. The UML 2.0 Metamodel Although the UML 2.0 metamodel improved over UML 1.x by adding the notion of subjects (what we call context in [Williams01]) to use cases, it does contain two main shortcomings. Given the current size of the UML 2.0 specification, the remedies to these issues are complex, which prevents a complete and formal rectification of them in this paper. In the subsection following this one, we sketch the approach that we believe needs to be used in order to remedy them. In the UML 2.0 metamodel, the UseCase metaclass aligns with the BehavioredClassifier metaclass, which itself is a descendent of Classifer. The OMG standard for UML

[UML02] states that "a classifier is a type. This is problematic for use cases, as the essence of a use case is to describe an interaction between an actor an the system, not to classify types. One consequence of this misalingment is that generalization is poorly defined for use cases. In UML 2.0, geralization is defined as both feature inheritance and subtyping. It is unclear how these apply to use cases when they are understood to be actor-system interaction specifications. Another issues is that BehavioredClassifiers have ownedBehaviors, which misaligns with the typical textual based approaches for use cases. There are two modifications that partially address the problems with the current use case alignment in the UML 2.0 metamodel. However, neither is sufficient to solve the problems without additional re-engineering of the metamodel. Use cases could subclass Behavior. In the current metamodel, this is problematic, as Behavior always exists in the context of a BehavioredClassifier and use cases should exist in the context of the domain model, which consists of several classifiers. Another approach would be to add constraints to UseCase to prohibit ownedBehaviors and attributes from existing on use cases. Then classifierBehavior could serve as the basis for specifying the use case behavior. However, this approach has the problem that it presumes that the classifierBehavior is updating the state of the use case instance rather than the state of domain class instances. To properly support alignment between the graphical syntax of UML and the textual details in a use case requires a careful re-examination of the UML metamodel. We argued earlier that use cases should consist of four basic actions (input, output, computation, and exceptions) with supporting actions providing for control flow specification (inclusion, extension, sequencing, selection, and iteration.) Were it possible to align use cases more carefully with Behavior, refining the model to include specifics regarding contents of a use case would offer a degree of precision that is currently not available. Allowing use cases to support a (possibly enhanced) subset of the existing UML 2.0 actions defined for activities would provide specificity that is lacking in the current specification. As noted above, there is currently no good way to do this in the existing metamodel. Toward a Metamodel Supporting Engineered Use Cases As we cannot redesign the use case portion of the UML 2.0 metamodel in this paper without possibly causing problems in other portions of the specification, we instead outline an approach that can be used to address the concerns raised in the previous section. The first area that must be addressed is which UML metaclass the UseCase metaclass specializes. As suggested earlier, we believe the best remedy is to have UseCase be a specialization of Behavior. This is consistent with the vision defined in section 2, where use cases have input parameters, return results (output), and have preconditions and postconditions. All of these concepts are already supported in the current Behavior metaclass. This requires that Behavior be modified or extended to allow association with multiple classifiers in order to support using the domain model as the use case context.

Were we to align UseCase with Behavior, the notion of supported actions is still missing. Like the Activities metaclass (which also aligns with Behavior,) the UseCase metaclass should specify a set of Actions which can be performed within a use case instance. A subset of the current actions defined in UML 2.0 would suffice as a basis for creating executable use cases. These include the Read Write Actions (Object Actions, Variable Actions, Link Actions, and Structural Feature Actions). These should be extended with specific Computational Actions (such as arithmetic, Boolean, and string related actions, and domain specific actions.) Invocation Actions are not required, as neither use cases nor their contexts support operations or signals. Given the alignments proposed in this section, we next explore the semantics required to support engineered use cases.

4 TOWARD PRECISE USE CASE SEMANTICS

In order to support an engineering approach to creating precise use cases, we must address semantic issues in addition to the structural/content issues discussed above. While space considerations prevent a formalized treatment of all relevant semantic issues, we provide informal details and in the following discussion. There are two areas for which we provide specific attention: execution semantics and generalization. Execution Semantics For use cases to be precise, we must be able to describe what they mean when they are executed. The execution of a use case is performed in the context of a state consisting of instances of domain model classes. Domain objects may be created, modified, or deleted. Links may be added, or deleted. Attributes may be modified. The following capabilities describe the execution semantics of use cases. 1. Input / Output statements instantiate formal parameter(s) specified in the statement with value(s) of the appropriate type(s). 2. Computation create/delete an instance of a domain object, create/delete a link between existing domain object instances, modify the attribute of a domain object. 3. Exception check exception conditions and fires if true. Given a use case, execution proceeds as follows. Each statement in the main scenario is executed. During its execution, the alternatives / exceptions defined for that statement are checked for execution eligibility. If one or more is eligible, we must determine which one takes priority and execute it. The semantics for determining priority must be defined in the language. If the alternative specifies where control returns to, that is the point where execution continues, otherwise, it resumes at the next statement in the main interaction course. While this is only an informal explanation of execution semantics, our group is exploring surface representations for the use case body and will provide a formal semantics based upon that representation in the future. Generalization Semantics

Generalization has traditionally been a very problematic area for use case semantics. UML 2.0 says nothing about use case generalization, leaving it unclear whether generalization is meant to be a sub-typing mechanism, or a mechanism for simply indicating that the scenarios specified by a parent use case can be replaced with the scenarios specified by its children. If sub-typing is the goal, and use cases are re-aligned to specialize the Behavior metaclass, the design-by-contract calculus can serve as a basis for formalizing generalization. This will ensure the capacity to substitute the child use case for the parent in a context. If scenario replacement is the goal, a careful analysis of the issues related to replacement is required. Of course, a full semantics of use case generalization must be worked out in the context of an updated metamodel that supports both alignment with UML and a precise textual specification for a use case.

5 INDUSTRIAL APPLICATIONS OF ENGINEERED USE CASES

Before engineered use cases will be accepted in an industrial setting, they must provide value that exceeds the effort required to create them. We believe that engineered use cases can provide value across at least four dimensions: prototyping, estimation, refinement to design, and test generation. The first three are in the early research stage in our organization, while the fourth is one in which we have considerable experience. Prototyping The first benefit of using precise, engineered use cases is the ability to use them as the foundation for an executable prototype of the system. This allows early feedback to the customer and provides a means for validating the requirements. The prototyping approach requires that a precise surface syntax for specifying the use case content exists, along with an environment capable of executing these use cases. We have developed beta versions of these elements, and have shown that use cases captured with them can be executed directly. It also requires a facility for prototyping UI elements and associating them with use cases. The steps toward building a useful prototype are as follows: 1. Build the domain and use case models. 2. Create mocked-up user interface (UI) elements for the input and output statements. 3. Associate the UI elements with the input and output statements. 4. Execute the prototype with all involved stakeholders, gathering important feedback. 5. Modify the model according to the feedback and repeat the exercise until the requirements are agreed upon by all stakeholders. The advantage of prototyping based on engineered use cases is obvious it requires almost no effort beyond normal analysis and design activities to have an executable prototype for validating user requirements. Estimation Once the requirements have been validated using the prototyping approach described above, the next step is to determine how much time and cost are involved in realizing the actual system modeled by the use cases. Use cases alone cannot serve as a basis for

estimation, but are an important element for determining the functional complexity of the application being developed. Non-functional requirements also play a significant role in determining time and effort. We believe that our use case approach will serve as a sound basis for estimation, and we are in the very early stages of exploring this idea further. The basic steps in developing such an estimation approach are: 1. Examine existing projects using the engineered use case methods to gather baseline information for an estimation model. 2. Construct the initial estimation model, and apply it to new projects. 3. Gather feedback from the projects, and refine the estimation model. 4. Release the model for general use. Refinement to Design Once the estimate has been accepted and the work authorized, the next two activities occur in parallel. The first is to refine the use cases to a detailed design of the system. This is done as follows: 1. The domain model is refined to a full analysis model. This is done by identifying boundary and controller classes that serve as additions to the model classes already present in the domain model. The boundary classes can be inferred from the UI elements discussed in the section on prototyping. 2. Operations for all of the classes in the analysis model are identified. These are informed by the computation actions in the use case model, as well as required controller and UI computations for the system. 3. The input statements are mapped to operation invocations on the boundary classes. 4. The output statements are mapped to returned parameters from or operation invocations on the boundary classes. 5. Interaction diagrams are used to show how use cases are realized in the system using the mappings defined in steps 3-4 as a basis. 6. Further refinement to a detailed design and implementation can now proceed from the analysis model and use case realizations. Test Case Creation/Generation Finally, we must validate that the system constructed from the refinement described in the above section actually meets the requirements specified by the use cases. This is done by creating precise test cases from the use cases, domain model, and domain invariants. Our group has created test generation tools that automatically produce test cases from these models. We have shown a decrease in the effort required to execute the test suite and an improvement in the coverage of the functionality of the system. Table 1 shows the results of the initial pilots performed with an early prototype version of this approach. Pilot Properties Outcome

Test cases developed by Research Provided to system owner for execution Compared with existing test suite developed manually

Five-fold reduction in test suite size (30 generated test cases vs. 150 manually created) without a loss of functional coverage 68% decrease in time to setup/run/verify test suite Major defect detected by new suite that esacped detection by manually developed suite. Coverage of use case functionality improved 30% in the model-based suite. This was achieved with 10% fewer use case invocations. Testing team estimates achieving comparable coverage to modelbased suite would require twice the effort. >90% coverage of the functionality with a suite of 60 test cases. The suite tested 40 use cases. In total, there were 145 input parameters, 335 partitions, and 117 flow edges in the model.

Modeling and generation done in testing organization. Test expert created model and generated test cases Comparison against a manually developed suite created independently by a different expert.

Modeling and generation done in testing organization. UML use case model built during system design, used by testing organization. Testers analyzed the suite for usability in the project.

Table 1. Pilot Results for Test Generation Tool [Williams01] has specific details for these early results. The major conceptual steps in test generation are as follows: 1. For each use case, ensure that there are test cases for each path through the use case. This can be done using a technique such as the basis paths method [Poole95]. 2. For each condition in a use case (either selection or exception), ensure that condition coverage is achieved using a condition coverage technique [Beizer90]. 3. For each domain rule in the domain model, determine all use cases which update any variable in the domain rule. Determine the interesting ways in which the implementation could be tested to ensure the rule holds, and perform those tests.

6 RELATED WORK
Two recent papers explore extensions or alternatives to the standard UML metamodel for use cases. These include [Nakatana01], which integrates the activity graph

metamodel and use case metamodel. In this view, use cases are still stateful classifiers, and the tight link between the actions comprising the use case and the domain model is missing. [Rui03] presents a metamodel that supports refactoring of use case models. This is interesting work, although the metamodel is not aligned with UML, nor does it pay careful attention to the context in which use cases are written. Another common area for focus is the correct representation of use case structure. [Metz03] focuses on the necessity of being able to correctly and concisely specify alternative courses in a use case. This paper is related to the need to support alternative sequences of statements and exceptions, and defines the differences between these precisely. [Li00] offers a structured representation for use case content, and a semiautomated approach to translating use cases into sequence diagrams. This contribution is interesting for both representation and refinement purposes. There is a significant body of work seeking to formalize the content or manner in which use cases are captured. Both [Lee98] and [Jorgensen04] seek to formalize use cases using concepts from Petri Nets. The first paper seeks to represent use cases using the formalism of Constraints-based Modular Petri Nets, while the second uses Colored Petri Nets. While both papers provide an elegant formal basis for use cases and both could be used for use case execution, neither Petri Net approach has been accepted in industry beyond the embedded/real-time space. Finally, [Rysavy04] seeks to represent use cases using higher-order logic. The benefits of this approach are an architecture that supports both static and behavioral information. Again, the downside is lack of industry acceptance of formal representations like HOL. Finally, in the proposed application areas, there is significant work in the testing area [Basanieri02,Briand01] and the estimation area [Smith03]. The testing work typically uses refinements of use cases to interaction diagrams for generation, which differs from our approach [Williams01]. Estimation work to date has been somewhat disappointing in its accuracy, primarily due to the wide variation in the abstraction levels at which use cases are captured. We hope that our more defined approach will help mitigate these problems.

7 CONCLUSIONS
We have argued that for use cases to be truly useful for industrial software development an engineering approach to developing them must be used. Such an approach requires first that use cases be well defined, both structurally and behaviorally. To facilitate this definition, we proposed a method where use cases are developed in the context of a domain model and domain rules. The content of the use cases is carefully elaborated using this context. Next, we proposed an approach for realigning the UML 2.0 metamodel for use cases to reflect the structure and capabilities described above, followed by a discussion of semantics issues associated with use cases. This focused on execution and generalization. Finally, we presented four application areas that place engineered use cases in the context of the software lifecycle. These are prototyping, estimation, refinement to

design, and test creation. We presented a general outline for using engineered use cases in each area. What we have presented in this paper is a philosophical and conceptual framework for developing engineered use cases. What is lacking is the formalized machinery to ensure that the approach is well grounded and the complete tooling to support the endeavor. Our team is currently exploring these areas, as well as they key application areas defined above. We believe that precise, engineered use cases can be useful across the lifecycle and result in cost effective, reliable software systems.

REFERENCES
[Armour01] F. Armour and G. Miller: Advanced Use Case Modeling: Software Systems Addison-Wesley, 2001. [Basanieri02] F. Basanieri, A. Bertolino, and E. Marchetti: The Cow_Suite Approach to Planning and Deriving Test Suites in UML Projects, Proceedings of the 5th International Conference on UML (<<UML>> 2002), pp. 383-397, Sept. 30-Oct. 4, 2002. [Beizer90] B. Beizer: Software Testing Techniques, Van Nostrand Reinhold, 1990. [Briand01] L. Briand and Y. Labiche: A UML-Based Approach to System Testing, Proceedings of the 4th International Conference on UML (<<UML>> 2004), pp. 194208, October, 2001. [Cockburn01] A. Cockburn: Writing Effective Use Cases, Addison-Wesley, 2001. [Jacobson92] I. Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992. [Jorgensen04] J.B. Jorgensen and C. Bossen: Executable Use Cases: Requirements for a Pervasive Health Care System, IEEE Software, vol. 21, no. 2, pp. 34-41, MarchApril, 2004. [Lee98] W.J. Lee, S.D. Cha, and Y.R. Kwon: Integration and Analysis of Use Cases Using Modular Petri Nets in Requirements Engineering, IEEE Transactions on Software Engineering, vol. 24, no. 12, December, 1998, 1115-1130. [Li00] L Li: Translating Use Cases to Sequence Diagrams, Proceedings of the Fifteenth IEEE International Conference on Automated Software Engineering (ASE'00), pp. 293-296, September 11 - 15, 2000. [Metz03] P. Metz, J. OBrien, and W. Weber: Specifying Use Case Interaction: Types of Alternative Courses, Journal of Object Technology, vol. 2, no. 2, pp. 111-131, March-April 2003 http://www.jot.fm/issues/issue_2003_03/article1. [Nakatana01] T. Nakatana, T. Urai, S. Ohmura, and T. Temai: A Requirements Description Metamodel for Use Cases, Proceedings of the Eighth Asia-Pacific Software Engineering Conference (APSEC'01), pp. 251-258, December 04 - 07, 2001.

[Poole95] J. Poole: A Method to Determine a Basis Set of Paths to Perform Program Testing. National Institute of Standards and Technology, Report #5737, November 1995. [Rui03] K. Rui and G. Butler: Refactoring Use Case Models: The Metamodel, Proceedings of the 25th Australasian Computer Society Conference (ACSC 2003), pp. 301-308, 2003. [Rysavy04] O. Rysavy and F. Bures: Formal Abstract Architecture for Use Case Specifications, Proceedings of the 11th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS04), pp. 203-210, May 24-27, 2004. [Smith03] J. Smith: The Estimation of Effort and Size Based on Use Cases , IBM/Rational report available at http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/final TP171.pdf [UML02] UML 2.0 Superstructure Specification. OMG Adopted Specification ptc/0410-02. [Williams01] C. Williams: Toward a test-ready meta-model for use cases, Proceedings of the Workshop on Practical UML-based Rigorous Development Methods, pp. 270-287, October, 2001. About the authors Clay Williams is a Research Staff Member and the Manager of the Software Quality and Testing Research Group at the IBM Watson Research Center. His group primarily focuses on issues related to modeling, testing, and measurement. His personal research focuses on effective use of modeling technology to enable the construction of high quality software. He has a Ph.D. in computer science from Texas A&M University. EMail: clayw@us.ibm.com

Matthew Kaplan is an Advisory Software Engineer in the Software Quality and Testing Research Group at the IBM Watson Research Center. His current work focuses on the use of modeling technology to improve testing, as well as how to model and use domain specific information (e.g. security information) to improve the quality of software. He has an M.S. in computer science from Brown University. E-Mail: mmk@us.ibm.com

Tim Klinger is an Advisory Software Engineer in the Software Quality and Testing Research Group at the IBM Watson Research Center. He primarily focuses on the application of novel techniques from AI to complex problems across the software engineering lifecycle, from design and construction to testing and validation. He has a Ph.D. from New York Univeristy. E-Mail: tklinger@us.ibm.com.

Amit Paradkar is a Research Staff Member in the Software Quality and Testing group at IBM T.J. Watson Research Center, Yorktown, NY. His primary research interest is in the area of software testing - particularly model based test generation using UML. He is also interested in software testability, and applications of AI techniques to Software Engineering problems. He has received Ph.D. in Computer Science, MS in Computer Science, and MS in Textile Engineering and Sciences - all from North Carolina State University in Raleigh. E-Mail: paradkar@us.ibm.com

Lenguaje Unificado de Modelado

De Wikipedia, la enciclopedia libre Saltar a navegacin, bsqueda Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas.
Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando: {{subst:Aviso referencias|Lenguaje Unificado de Modelado}} ~~~~

Collage de diagramas UML.

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema.

UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Contenido
[ocultar]

1 Diagramas 2 Estandarizacin de UML 3 Crticas a UML 4 Historia o 4.1 Antes de UML 1.x o 4.2 UML 1.x 5 Referencias 6 Enlaces externos

[editar] Diagramas

Jerarqua de los diagramas UML 2.0, mostrados como un diagrama de clases

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es til categorizarlos jerrquicamente, como se muestra en la figura de la derecha. Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0) Diagrama de despliegue Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

Diagrama de actividades Diagrama de casos de uso Diagrama de estados

Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

Diagrama de secuencia Diagrama de comunicacin, que es una versin simplificada del Diagrama de colaboracin (UML 1.x) Diagrama de tiempos (UML 2.0) Diagrama global de interacciones o Diagrama de vista de interaccin (UML 2.0) La version de UML 2.0 apartir de esta y las que vienen son las buenas

[editar] Estandarizacin de UML

Desde el ao 2005. UML es un estndar aprobado por la ISO como ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML) Version 1.4.2.

[editar] Crticas a UML

Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas.
Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando: {{subst:Aviso referencias|Lenguaje Unificado de Modelado}} ~~~~

A pesar de su status de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Sin embargo, UML s acepta la creacin de nuestros propios componentes para este tipo de modelado.

Entorno de desarrollo integrado Herramienta CASE Tcnica de Modelado a Objetos Programacin orientada a objetos XMI, un formato estndar basado en XML para el intercambio de modelos UML. OCL, Lenguaje de especificacin para los diferentes modelos en UML.

Webml, Metodologa para el diseo de Sistemas de Informacin Web. Categora:Herramientas UML

[editar] Historia

[editar] Antes de UML 1.x

Despus de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compa se convirti en la fuente de los dos esquemas de modelado orientado a objetos ms populares de la poca: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para anlisis orientado a objetos, y el Mtodo Booch de Grady Booch, que era mejor para el diseo orientado a objetos. Poco despus se les uniIvar Jacobson, el creador del mtodo de ingenier de software orientado a objetos. Jacobson se uni a Rational en 1995, despus de que su compaa Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prcticas metodolgicas. En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba alentando la adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consult con representantes de compaas competidoras en el rea de la tecnolog de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notacin de Booch que utilizaba simbolos de nubes. Bajo la direccin tcnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificacin UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mesla UML Partners formo una Fuerza de Tarea Semntica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

[editar] UML 1.x

Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de Booch, si se adopt la capacida de Booch para especificar detalles de diseo en los niveles inferiores. La notacin de Casos de Uso del Objectory y la notacin de componentes de Booch fueron integrados al resto de la notacin, pero la integracin semntica era relativamente dbil en UML 1.1, y no se arregl realmente hasta la revisin mayor de UML 2.0. Conceptos de muchos otros mtodos OO fueron integrados superficialmente en UML con el propsito de hacerlo compatible con todos los mtodos OO. Adems el grupo tom en cuenta muchos otros mtodos de la poca, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es til en

una variedad de problemas de ingeniera, desde procesos sencillos y aplicaciones de un slo usuario a sistemas concurrentes y distribuidos. Overview of the UML profile for software services The aim of the profile, implemented in IBM Rational Sofware Architect, is to provide a common language for describing services, one which covers a number of activities through the development lifecycle and also provides views to different stakeholders. For example, the profile provides capabilities for architects to map out services -- early in the lifecycle -- using logical partitions to describe the entire enterprise-wide service portfolio. This view is further detailed by designers, who develop the service specifications -- both structural and behavioral -- that act as the contracts between the services' clients and implementers. The message view provides the ability for designers to reuse information models for common service data definitions. Conceptual model Figure 1, following, is a diagram showing the important concepts in modeling services. As you can see the number of concepts is relatively small, and should be reasonably familiar to anyone who has worked on service-oriented solutions. The UML 2.0 profile this diagram represents has been implemented in IBM Rational Sofware Architect, used successfully in developing models of complex customer scenarios, and used to help educate people about the concerns relevant to developing service-oriented solutions. However, although the profile is a realization of this model, note that a number of the concepts are not explicit stereotypes in the profile. For example, there is no stereotype for operation or for protocol, as these are existing notions in UML 2.0 that the profile reuses without any ambiguity or further constraint.

Figure 1. Modeling services

Identified subset of UML 2.0 Table 1 lists the elements of the UML 2.0 meta model that are used as meta classes for stereotypes in the UML Profile. Table 1. Elements of the UML 2.0 meta model UML 2.0 Meta class Class Classifier Collaboration Connector Interface Port Property Stereotypes Message, Service Partition, Service Provider Service Consumer Service Collaboration Service Channel Service Specification Service, Service Gateway Message Attachment

Back to top

The profile itself Figure 2 (clickable) is a UML 2.0 profile diagram. It demonstrates the actual details of the profile, showing each stereotype with its meta class using the extension notation (filled arrow head).You can also see some of the constraints in the model, particularly those co-constraints between profile elements.

Figure 2. A UML 2.0 profile diagram

The following sections outline the elements of a UML 2.0 profile as it is currently defined. Each section outlines an individual stereotype, the details of which specify its meta class, properties, and any constraints which should be applied when using the profile. Stereotype message Extends Class Semantics A message represents a concept as defined in the WSDL (Web Services Description Language) specification; that is, it's a container for actual data which has meaning to the service and the consumer. A message may not have operations, but it may have properties and associations to other classes (likely of some domain model). A message

stereotype has a property to denote its assumed encoding form (for example, SOAPliteral, SOAP-rpc, ASN.1, and so on). Properties Table 2 lists the properties of a message stereotype. Table 2. Properties of a message Kind Name Type Description

Property encoding String Denotes the platform encoding mechanism to use in generating the schema for the message; examples might be SOAP-RPC, Doc-Literal, ASN.1, and so on. Notation Constraints

Shall not have any owned operations Shall not have any owned behaviors

Stereotype message attachment Extends Property Semantics This stereotype is used to denote that some component of a message is an attachment to it (as opposed to a direct part of the message itself). In general, you're not likely to use this stereotype much in higher level design activities, but for many processes it's important to differentiate attached data from embedded message data. For example, a catalog service may return general product details as a part of the structured message, but return images as attachments to the message. This also allows you to denote that the encoding of the images is binary (as opposed to the textual encoding of the main message). Properties Table 3 lists the properties of a message attachment stereotype. Table 3. Properties of a message attachment

Kind

Name

Type Description

Property encoding String Denotes the platform encoding mechanism to use in generating the schema for the message; examples might be SOAP-RPC, Doc-Literal, ASN.1, and so on. Notation Constraints

Shall only be used on properties owned by classes stereotyped as <<Message>>

Stereotype service Extends Port Semantics The service model element provides the end-point for service interaction (in web service terminology), whereas the definition of these interactions is a part of the service specification stereotype. In your model, a service not only identifies the provided interface, but may also identify required interfaces (such as callback interfaces). A service has an additional property that denotes the binding to be used, such as SOAPHTTP, SOAP-JMS, and so on. Properties None Notation Constraints

Shall only be used on a class stereotyped as <<Service Provider>> Shall be typed by an interface stereotyped as <<Service Specification>>

Stereotype service channel Extends Connector Semantics

A channel represents the communication path between two services. It is important to note that interaction may occur over a channel, but the channel does not represent any particular interaction. In the web services world, each service denotes the binding(s) associated with it (so that a client may access it). In a modeling profile, you denote binding either on the communication between services or between a service and consumers. In this way, you can be flexible in understanding the binding requirements. Properties Table 4 lists the properties of a service channel stereotype. Table 4. Properties of a service channel Kind Name Type Description

Property binding String Denotes the platform binding mechanism to use in generating the service binding in WSDL; examples might be SOAP-RPC, SOAPDoc, HTTP-Get, and so on. Notation Constraints

At least one end of the connector shall connect to a port stereotyped as <<Service At most one end of the connector may connect to a port stereotyped as <<Service Gateway>>, a class stereotyped as <<Service Provider>>, or a classifier stereotyped as <<Service Consumer>>

Stereotype service collaboration Extends Collaboration Semantics A service collaboration is a way of specifying the implementation of a service as a collaboration of other services. From a web services point of view, this corresponds to the use of BPEL4WS (Business Process Execution Language for Web Services) in specifying service implementation. So, this means that you use a service collaboration as the behavior of a service and -- if it is intended to generate to a language such as BPEL -- it may have other implementation-specific constraints. Properties

None Notation Constraints

Collaboration participants shall only be classes stereotyped as <<Service Provider>>

Stereotype service consumer Extends Classifier Semantics Any classifier (class, component, and so on) may act as the consumer of a service, and that includes another service. While this stereotype is most definitely optional, it may help you identify elements of a model -- that are not services themselves -- as clients of services. On the other hand, it may just be overhead and you don't need to use it. Properties None Notation Constraints None Stereotype service gateway Extends Port Semantics A service gateway looks like a service but is only available for use on partitions and not service providers. A gateway acts as a proxy service, and you can use it to mediate protocols or to denote the interface available to a partition. For example, you might denote that -- although a number of services are implemented within a partition -- only some of them are available for use outside the partition, and therefore gateways are provided for these services. This disallows other services or partitions from communicating to services that are not exposed via gateways. Properties

None Notation Constraints

Shall only be used on a class stereotyped as <<Service Partition>> Shall be typed by an interface stereotyped as <<Service Specification>>

Stereotype service partition Extends Class Semantics A partition represents some logical or physical boundary of the system. It is optional but useful to model partitions. For example, you could use partitions to represent the web, business, and data tiers of a traditional n-tier application. You might also use partitions to denote more physical boundaries (such as my primary data center, secondary site, customer site, partners, and so on), in which case the crossing of partitions may have particular constraints for security, allowed protocols, bandwidth, and so on. A partition may only have properties that represent nested parts, be they services or other partitions. Note that this is a constraint -- no other elements may currently be represented in a partition. A partition also has the notion of being strict. If a partition denotes that all communication between it and other partitions must be directed through typed gateways, then it is said to be a strict partition. Properties None Notation Constraints

Shall not have any owned properties Shall not have any owned operations Shall not have any owned behaviors Any owned part shall be a class stereotyped <<Service Provider>>

Stereotype service provider Extends Class

Semantics The service provider is a software element that provides one or more services. In modeling terms, you would most usually expect to see a UML component here; however, such a restriction seems arbitrary, and so the metaclass is noted as class for more flexibility. A service provider has a property that captures information about its location, although the meaning of this is implementation-dependent. The class acting as the service provider may not expose any attributes or operations directly: only public ports may be provided (stereotyped as service), and these are typed by service specifications. The location property -- while implementation- or platform-specific -- is useful in generating service endpoint names. For example (with WSDL), the location may be http://svc.myco.com/ and a service might be called CustInfo, in which case the endpoint name for the service could be generated as http://svc.myco.com/CustInfo. Properties Table 5 lists the properties of a service provider stereotype. Table 5. Properties of a service provider Kind Name Type Description

Property allowedBindings String Denotes the allowed platform binding mechanism a channel may use in connecting to the service; examples might be SOAP-RPC,
SOAP-Doc, HTTP-Get, etc.

Property location

String The location of the provider, this may be used by generators to create endpoint names.

Notation Constraints

Shall not have any owned properties Shall not have any owned operations

Shall not have any owned behaviors Any owned port shall be stereotyped <<Service>>

Stereotype service specification Extends Interface Semantics The use of an interface denotes a set of operations provided by a service. Note that a service may implement more than one interface. By convention, it is possible to attach a protocol state machine or UML 2.0 collaboration to such a specification to denote the order of invocation of operations on a service specification. With such a behavioral specification, any implementing service can be validated against not only a static but dynamic specification of its structure and behavior. Note that the service specification may only provide public operations, and each operation should only consume at most one message and produce at most one message. Properties Table 6 lists the properties of a service specification stereotype. Table 6. Properties of a service specification Kind Name Type Description

Property published Boolean This property denotes whether the service is assumed to be published into a service repository; this is a different notion from the public/private property provided by UML. Notation Constraints

Shall not have any owned properties All operations shall be marked as public May only be used as the type for a port stereotyped as <<Service>> or <<Service Gateway>>

Tabla de contenidos

Introduccin Conociendo UML 2.0 o Objetivos del UML 2.0 o El UML y la Industria del Software o Conceptos bsicos sobre UML o (Muy) Breve Resea Histrica o El Nuevo Enfoque del UML 2.0 Reestructuracin del Lenguaje OCL Especificacin para el Intercambio de Diagramas Infraestructura Superestructura o La Superestructura del UML Organizacin de la superestructura Diagramas de Estructura y Diagramas de comportamiento Breve descripcin sobre los diagramas o Conclusin Cmo sigo? Bibliografa

Introduccin
Al momento de desarrollar el nuevo estndar 2.0 de UML, la OMG se plante, entre otros, dos objetivos que podramos considerar principales, debido a la influencia de stos en la nueva versin del estndar:
1. Hacer el lenguaje de modelado ms extensible. 2. Permitir la validacin y ejecucin de modelos.

En el presente artculo, se muestran los principales cambios en UML 2.0, cmo stos influyen en los objetivos planteados anteriormente, la nueva estructura de UML 2.0, los nuevos diagramas y los cambios ms importantes en los diagramas preexistentes. La evolucin de la programacin hacia la ejecucin y validacin automtica de modelos

Conociendo UML 2.0

En este artculo nos introduciremos al mundo del diseo de aplicaciones de software, a travs de su puerta ms novedosa: UML 2.0. ste es el comienzo de una serie de artculos en los que iremos, poco a poco, conociendo el UML 2.0 en detalle. En el presente trabajo, nos enfocaremos en el lenguaje propiamente dicho; su historia, estructura, cambios y objetivos de mayor influencia, en esta nueva y radical versin.

Objetivos del UML 2.0

Al momento de desarrollar el nuevo estndar 2.0 del UML, la OMG se propuso, entre otros, dos objetivos que podramos considerar principales debido a la influencia de stos en la versin final del estndar. Estos objetivos son:
1. Hacer el lenguaje de modelado mucho ms extensible de lo que era. 2. Permitir la validacin y ejecucin de modelos creados mediante el UML.

UML 2.0 se desarrolla sobre la base de estos dos objetivos, causando un quiebre respecto a versiones anteriores. Para entender la razn del quiebre y el por qu de esta evolucin tan marcada, nos profundizaremos un poco en la historia y definicin misma del UML.

El UML y la Industria del Software

El UML se ha vuelto el estndar de facto (impuesto por la industria y los usuarios) para el modelado de aplicaciones de software. En los ltimos aos, su popularidad trascendi al desarrollo de software y, en la actualidad, el UML es utilizado para modelar muchos otros dominios, como por ejemplo el modelado de procesos de negocios.

Conceptos bsicos sobre UML

UML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de Modelado Unificado. Para comprender qu es el UML, basta con analizar cada una de las palabras que lo componen, por separado.

Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que ste cuenta con una sintaxis y una semntica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cmo deben agruparse los elementos del lenguaje y el significado de esta agrupacin. Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretacin y entendimiento de ste. Unificado: unifica varias tcnicas de modelado en una nica.

Ya que el UML proviene de tcnicas orientadas a objetos, se crea con la fuerte intencin de que este permita un correcto modelado orientado a objetos.

(Muy) Breve Resea Histrica

Las races del UML provienen de tres mtodos distintos. El mtodo de Grady Booch, la Tcnica de Modelado de Objetos de James Rumbaugh y Objetory, de Ivar Jacobson. Conocidas estas tres personalidades como los tres amigos. En 1994 Booch, Rumbaugh y Jacobson dieron forma a la primera versin del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versin v1.1 del UML. Desde entonces, UML atraves varias revisiones y refinamientos hasta llegar a la versin actual: UML 2.0.
Qu es la OMG?

La OMG (Object Management Group) es una asociacin sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard?. Esta asociacin se encarga de la definicin y mantenimiento de estndares para aplicaciones de la industria de la computacin. Otro de los estndares definidos por la OMG, adems del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio. Podemos encontrar ms informacin sobre la OMG en su sitio oficial: http://www.omg.org/ (cache)
Es importante destacar que, a lo largo de estas constantes revisiones, muchas tcnicas existentes fueron agregadas a UML. Esta constante ampliacin del lenguaje hizo que el UML fuera perdiendo identidad, convirtindose en una agrupacin de distintas tcnicas de modelado, sin demasiada cohesin entre ellas. Esto transform al UML en un lenguaje sin identidad y, en muchos puntos, ambiguo o falto de coherencia conceptual.

El Nuevo Enfoque del UML 2.0

En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms comportamiento (Behavior). De esta forma, se permiti la creacin de herramientas que soporten la automatizacin y generacin de cdigo ejecutable, a partir de modelos UML.
Estndares que conforman el UML

Superestructura: Es la especificacin que usamos todos los das. Aqu se encuentran todos los diagramas que la mayora de los desarrolladores conocen. Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entre otras. OCL: Lenguaje de restriccin. De utilidad para especificar conceptos ambiguos sobre los distintos elementos del diagrama. XMI / Intercambio de diagramas: Permite compartir diagramas entre diferentes herramientas de modelado UML.

Reestructuracin del Lenguaje

Para lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el lenguaje.

Figura 1: Especificaciones principales del UML 2.0

Veamos a continuacin, un poco ms en detalle cada una de las principales especificaciones que componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habr oportunidad de profundizar en cada una de ellas.

OCL
OCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama, entre otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML en la versin 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo ms de las muchas herramientas agregadas al UML.

Especificacin para el Intercambio de Diagramas

La especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este Schema no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado UML.

Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra fundamental sobre la cual la Superestructura es definida. Esta ltima s es la utilizada por el comn de los usuarios. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cules son sus objetivos.

Superestructura
La superestructura del UML es la definicin formal de los elementos del UML. Esta definicin sola contiene ms de 640 pginas. La superestructura es tpicamente utilizada por los desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores del UML.

La Superestructura del UML

Es en la Superestructura donde encontramos los cambios que ms afectan en el da a da a quienes trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general, deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones.

Es aqu dnde se definen los diagramas y los elementos que los componen. La Superestructura se encuentra dividida en niveles. Estos niveles se conocen como:

Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas de clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas de Componentes y Diagramas de despliegue. Completo (L3): Representa la especificacin del UML 2.0 completa, como por ejemplo: las Acciones, Caractersticas avanzadas y PowerTypes? entre otros.

Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas (features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles.

Organizacin de la superestructura
El bloque de construccin bsico del UML es un diagrama. La estructura de los diagramas UML est reflejado por el diagrama de la figura 2, de acuerdo con la especificacin del UML 2.0 del Object Development Group. Los detalles sobre estos diagramas especficos se organizan de acuerdo a esta estructura taxonmica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas de interaccin comparten propiedades y atributos similares, como lo hacen los diagramas estructurales y de comportamiento. En color azul se distinguen aquellos diagramas que aparecen en esta versin del UML.

Figura 2: Estructura taxonmica del UML 2.0

Diagramas de Estructura y Diagramas de comportamiento

Los diagramas estructurales representan elementos y as componen un sistema o una funcin. Estos diagramas pueden reflejar las relaciones estticas de una estructura, como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecucin, tales como diagramas de Objetos o de Estructura de Composicin. Los diagramas de comportamiento representan las caractersticas de comportamiento de un sistema o proceso de negocios y, a su vez, incluyen a los diagramas de: actividades, casos de uso, maquinas de estados, tiempos, secuencias, repaso de interacciones y comunicaciones.

Breve descripcin sobre los diagramas

En beneficio de quienes quieran seguir investigando dentro del mundo UML, en el siguiente cuadro se muestra la importancia que tiene, para un desarrollador, conocer cada una de las nuevas caractersticas del UML 2.0. Sobre esta premisa, ampliaremos la explicacin de cada diagrama en las prximas ediciones, dando ms importancia a los diagramas que figuran con mayor prioridad en el cuadro.
Diagrama Descripcin Muestra una coleccin de elementos de modelado declarativo (estticos), tales como clases, tipos y sus contenidos y relaciones. Prioridad

Diagrama de Clases

Alta

Diagrama de Componentes

Representa los componentes que componen una aplicacin, sistema o empresa. Los componentes, sus relaciones, Media interacciones y sus interfaces pblicas.

Representa la estructura interna de un clasificador (tal como Diagrama de Estructura una clase, un componente o un caso de uso), incluyendo los Baja puntos de interaccin de clasificador con otras partes del de Composicin sistema. Un diagrama de despliegue fsico muestra cmo y dnde se desplegar el sistema. Las mquinas fsicas y los procesadores se representan como nodos y la construccin interna puede ser representada por nodos o artefactos Media embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicacin es guiada por el uso de las especificaciones de despliegue. Un diagrama que presenta los objetos y sus relaciones en un punto del tiempo. Un diagrama de objetos se puede Baja considerar como un caso especial de un diagrama de clases o un diagrama de comunicaciones.

Diagrama de Despliegue Fsico

Diagrama de Objetos

Un diagrama que presenta cmo se organizan los elementos Diagrama de Paquetes de modelado en paquetes y las dependencias entre ellos, Baja incluyendo importaciones y extensiones de paquetes. Diagrama de Actividades Diagrama de Comunicaciones (anteriormente: Diagrama de colaboraciones) Representa los procesos de negocios de alto nivel, incluidos el flujo de datos. Tambin puede utilizarse para modelar Alta lgica compleja y/o paralela dentro de un sistema. Es un diagrama que enfoca la interaccin entre lneas de vida, donde es central la arquitectura de la estructura interna y cmo ella se corresponde con el pasaje de Baja mensajes. La secuencia de los mensajes se da a travs de un esquema de numerado de la secuencia. Los Diagramas de Revisin de la Interaccin enfocan la revisin del flujo de control, donde los nodos son Baja Interacciones u Ocurrencias de Interacciones. Las Lneas de Vida los Mensajes no aparecen en este nivel de revisin Un diagrama que representa una interaccin, poniendo el foco en la secuencia de los mensajes que se intercambian, junto con sus correspondientes ocurrencias de eventos en las Lneas de Vida.

Diagrama de Revisin de la Interaccin

Diagrama de Secuencias

Alta

Un diagrama de Mquina de Estados ilustra cmo un elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con Diagrama de Mquinas disparadores de transiciones, guardias de restricciones y de Estado otros aspectos de los diagramas de Mquinas de Estados, que representan y explican el movimiento y el comportamiento.

Media

Diagrama de Tiempos

El propsito primario del diagrama de tiempos es mostrar los cambios en el estado o la condicin de una lnea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso ms comn es mostrar el cambio de estado de un objeto a lo Baja largo del tiempo, en respuesta a los eventos o estmulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cundo se desea mostrar el evento que causa el cambio en la condicin o en el estado. Un diagrama que muestra las relaciones entre los actores y Media el sujeto (sistema), y los casos de uso.

Diagrama de Casos de Uso

Conclusin
A lo largo del artculo hemos analizado los objetivos y el impacto de stos en la versin 2.0 del UML. Analizamos la estructura del UML 2.0, su conformacin interna y la divisin taxonmica de sus diagramas.

Cmo sigo?
Recomendamos leer el siguiente artculo, el cual es la continuacin del presente: El Poder Semntico del UML 2.0 en la Prctica donde se muestran los cambios ms importantes en el Lenguaje Unificado de Modelado, desde el punto de vista del desarrollador, mediante ejemplos.

Bibliografa
Libros recomendados: Hemos revisado varios libros dedicados a la superestructura del UML 2.0. Entre ellos el que parece ser ms destacable es: UML 2.0 in a Nutshell.

UML 2.0 in a Nutshell (cache) de Dan Pilone y Neil Pitman

Excelente referencia para el trabajo diario. La introduccin terica es un poco superficial, debido a que el foco del libro es la superestructura. El libro puede ser til tanto a expertos UML como para quienes recin se inician.

UML 2 for Dummies de Michael J. Chonoles y James A. Schardt

Libro de muy fcil lectura con una introduccin terica adecuada. El tratamiento de los temas podra ser un poco ms amplio, ya que el libro apunta a personas sin conocimiento del UML.

Fast Track UML 2.0 de Kendall Scott y Apress

Libro totalmente orientado a la superestructura. La introduccin conceptual terica a los nuevos aspectos del UML 2.0 es bastante superficial y carece de un hilo conductor en cuanto a la organizacin de los temas. A pesar de esto, los distintos diagramas estn bien explicados Otros libros recomendados de Orientacin a Objetos: Para quien quiera una excelente introduccin terica al mundo del diseo orientado objetos, dejamos estas recomendaciones:

"Designing Object-Oriented? Software" de Rebecca Wirfs-Brock?, Brian Wilkerson y Lauren Wiener

Si le preguntan a alguien que trabaje con objetos sobre un libro de diseo orientado a objetos, seguramente les recomiende este libro

"Smalltalk Objects, and Design (Paperback)" de Chamond Liu

Otro excelente libro de diseo OO. Un poco ms orientado a Smalltalk, pero conceptualmente completo.

Object-oriented Systems Analysis and Design Using UML de Simon Bennett, Steve McRobb? y Ray Farmer.

Un libro que combina teora de objetos y UML, con un enfoque un poco ms prctico. Herramientas A continuacin, nombramos algunas herramientas que soportan UML 2.0. Dado que no todas tienen el mismo nivel de conformidad, el nivel ms alto a la fecha lo tiene Enterprise Architect.
Enterprise Architect http://www.sparxsystems.com/ (cache) Altova UModel 2005 http://www.altova.com/umodel/ (cache) Together Rational Software Architect Embarcadero Describe http://www.borland.com/together/designerce/index.html http://www-306.ibm.com/software/rational/ (cache) http://www.embarcadero.com/products/describe/dedatasheet.html (cache)

UML 2 Class Diagrams*

w w w .agiledata.o ISO-8859-1

L:http://w w w .agi 1

en pub-1563172974

active w w w .agilemodel

ISO-8859-1

Home | AMDD | Best Practices | Architecture | Requirements | Analysis | Design | Documentation | Models | Modeling Style | Contact Us | Mailing List | FAQ

Search

UML 2 class diagrams are the mainstay of object-oriented analysis and design. UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling. Although I prefer to create class diagrams on whiteboards because simple tools are more inclusive most of the diagrams that Ill show in this article are drawn using a software-based drawing tool so you may see the exact notation.

In this article I discuss:

Conceptual class diagrams Design class diagrams How to create UML class diagrams Suggested reading

1. Conceptual Class Diagrams

Figure 1 depicts a start at a simple UML class diagram for the conceptual model for a university. Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods. By including both an attribute and a method box in the class Im arguably making design decisions in my model, something I shouldnt be doing if my goal is conceptual modeling. Another approach would be to have two sections, one for the name and one listing responsibilities. This would be closer to a CRC model (so if I wanted to take this sort of approach Id use CRC cards instead of a UML class diagram). I could also use class boxes that show just the name of the class, enabling me to focus on just the classes and their relationships. However, if that was my goal Id be more likely to create an ORM diagram instead. In short, I prefer to follow AMs Apply the Right Artifact(s) practice and use each modeling technique for what its best at.

Figure 1. Sketch of a conceptual class diagram.

Enrollment is an associative class, also called a link class, which is used to model associations that have methods and attributes. Associative classes are typically modeled during analysis and then refactored into what I show in Figure 2 during design (Figure 2 is still a conceptual diagram, albeit one with a design flavor to it). To date, at least to my knowledge, no mainstream programming language exists that supports the notion of associations that have responsibilities. Because you can directly build your software in this manner, I have a tendency to stay away from using association classes and instead resolve them during my analysis efforts. This is not a purist way to model, but it is pragmatic because the other members on the team, including project stakeholders, dont need to learn the notation and concepts behind associative classes. Figure 2 depicts a reworked version of Figure 1, the associative class has been resolved. I could have added an attribute in the Seminar class called Waiting List but, instead, chose to model it as an association because that is what it actually represents: that seminar objects maintain a waiting list of zero or more student objects. Attributes and associations are both properties in the UML 2.0 so theyre treated as basically the same sort of thing. I also showed associations are implemented as a combination of

attributes and operations I prefer to keep my models simple and assume that the attributes and operations exist to implement the associations. Furthermore that would be a detailed design issue anyway, something that isnt appropriate on a conceptual model.

Figure 2. Initial conceptual class diagram.

The on waiting list association is unidirectional because there isnt yet a need for collaboration in both directions. Follow the AM practice of Create Simple Content and dont over model you dont need a bi-directional association right now so dont model it. The enrolled in association between the Student and Enrollment classes is also uni-directional for similar reasons. For this association it appears student objects know what enrollment records they are involved with, recording the seminars they have taken in the past, as well as the seminars in which they are currently involved. This association would be traversed to calculate their student objects average mark and to provide information about seminars taken. There is also an enrolled in association between Enrollment and Seminar to support the capability for student objects to produce a list of seminars taken. The instructs association between the Professor class and the Seminar class is bidirectional because professor objects know what seminars they instruct and seminar objects know who instruct them. When Im conceptual modeling my style is to name attributes and methods using the formats Attribute Name and Method Name, respectively. Following a consistent and sensible naming convention helps to make your diagrams readable, an important benefit of AMs Apply Modeling Standards practice. Also notice in Figure 2 how I havent modeled the visibility of the attributes and methods to any great extent. Visibility is an important issue during design but, for now, it can be ignored. Also notice I havent defined the full method signatures for the classes. This is another task

I typically leave to design. I was able to determine with certainty, based on this information, the multiplicities for all but one association and for that one I marked it with a note so I know to discuss it further with my stakeholders. Notice my use of question marks in the note. My style is to mark unknown information on my diagrams this way to remind myself that I need to look into it. In Figure 2 I modeled a UML constraint, in this case {ordered FIFO} on the association between Seminar and Student. The basic idea is that students are put on the waiting list on a first-come, first-served/out (FIFO) basis. In other words, the students are put on the waiting list in order. UML constraints are used to model complex and/or important information accurately in your UML diagrams. UML constraints are modeled using the format {constraint description} format, where the constraint description may be in any format, including predicate calculus. My preference is to use UML notes with English comments, instead of formal constraints, because theyre easier to read.

2. Design Class Diagrams

Coming soon

Figure 3. A design class diagram.

3. How to Create Class Diagrams

To create and evolve a conceptual class diagram, you need to iteratively model:

Classes Responsibilities Associations Inheritance relationships Composition associations Vocabularies

To create and evolve a design class diagram, you need to iteratively model:

Classes Responsibilities Associations Inheritance relationships Composition associations

Interfaces

3.1 Classes
An object is any person, place, thing, concept, event, screen, or report applicable to your system. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object and, in many ways, it is simply a template from which objects are created. Classes form the main building blocks of an object-oriented application. Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.

3.2 Responsibilities
Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. The initial classes of your model can be identified in the same manner as they are when you are CRC modeling, as will the initial responsibilities (its attributes and methods). Attributes are the information stored about an object (or at least information temporarily maintained about an object), while methods are the things an object or class do. For example, students have student numbers, names, addresses, and phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a student does, which get implemented (coded) as methods. You should think of methods as the object-oriented equivalent of functions and procedures. An important consideration the appropriate level of detail. Consider the Student class modeled in Figure 2 which has an attribute called Address. When you stop and think about it, addresses are complicated things. They have complex data, containing street and city information for example, and they potentially have behavior. An arguably better way to model this is depicted in Figure 4. Notice how the Address class has been modeled to include an attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope). By introducing the Address class, the Student class has become more cohesive. It no longer contains logic (such as validation) that is pertinent to addresses. The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs. Furthermore, if the need arises to support students with several addressesduring the school term, a student may live in a different location than his permanent mailing address, such as a dorminformation the system may need to track. Having a separate class to implement addresses should make the addition of this behavior easier to implement.

Figure 4. Student and address (Conceptual class diagram).

An interesting feature of the Student class is its Is Eligible to Enroll responsibility. The underline indicates that this is a class-level responsibility, not an instance-level responsibility (for example Provide Seminars Taken). A good indication that a responsibility belongs at the class level is one that makes sense that it belongs to the class but that doesnt apply to an individual object of that class. In this case this operation implements BR129 Determine Eligibility to Enroll called out in the Enroll in Seminar system use case. The Seminar class of Figure 2 is refactored into the classes depicted in Figure 5. Refactoring such as this is called class normalization (Ambler 2004), a process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes. A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CSC 148 Introduction to Computer Science." The attributes name and fees where moved to the Course class and courseNumber was introduced. The getFullName() method concatenates the course number, "CSC 148" and the course name "Introduction to Computer Science" to give the full name of the course. This is called a getter method, an operation that returns a data value pertinent to an object. Although getter methods, and the corresponding setter methods, need to be developed for a class they are typically assumed to exist and are therefore not modeled (particularly on conceptual class diagrams) to not clutter your models.

Figure 5. Seminar normalized (Conceptual class diagram).

Figure 6 depicts Course from Figure 5 as it would appear with its getter and setter methods modeled. Getters and setters are details that are not appropriate for

conceptual models and in my experience arent even appropriate for detailed design diagrams instead I would set a coding guideline that all properties will have getter and setter methods and leave it at that. Some people do choose to model getters and setters but I consider them visual noise that clutter your diagrams without adding value.

Figure 6. Course with accessor methods (Inching towards a design class diagram).

3.3 Associations
Objects are often associated with, or related to, other objects. For example, as you see in Figure 2 several associations exist: Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship. When you model associations in UML class diagrams, you show them as a thin line connecting two classes, as you see in Figure 6. Associations can become quite complex; consequently, you can depict some things about them on your diagrams. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars.

Figure 6. Notation for associations.

It is not enough simply to know professors instruct seminars. How many seminars do professors instruct? None, one, or several? Furthermore, associations are often twoway streets: not only do professors instruct seminars, but also seminars are instructed by professors. This leads to questions like: how many professors can instruct any given seminar and is it possible to have a seminar with no one instructing it? The implication is you also need to identify the multiplicity of an association. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction (Table 1 summarizes the potential multiplicity indicators you can use).

Table 1. Multiplicity Indicators. Indicator 0..1 1 0..* 1..* n 0..n 1..n Meaning Zero or one One only Zero or more One or more Only n (where n > 1) Zero to n (where n > 1) One to n (where n > 1)

Another option for associations is to indicate the direction in which the label should be read. This is depicted using a filled triangle, called a direction indicator, an example of which is shown on the offering of association between the Seminar and Course classes of Figure 5. This symbol indicates the association should be read a seminar is an offering of a course, instead of a course is an offering of a seminar. Direction indicators should be used whenever it isnt clear which way a label should be read. My advice, however, is if your label is not clear, then you should consider rewording it. The arrowheads on the end of the line indicate the directionality of the association. A line with one arrowhead is uni-directional whereas a line with either zero or two arrowheads is bidirectional. Officially you should include both arrowheads for bidirectional assocations, however, common practice is to drop them (as you can see, I prefer to drop them). At each end of the association, the role, the context an object takes within the association, may also be indicated. My style is to model the role only when the information adds value, for example, knowing the role of the Student class is enrolled student in the enrolled in association doesnt add anything to the model. I follow the AM practice Depict Models Simply and indicate roles when it isnt clear from the association label what the roles are, if there is a recursive association, or if there are several associations between two classes.

3.4 Inheritance Relationships

Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Because you dont want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance is that mechanism. Inheritance models is a and is like relationships, enabling you to reuse existing data and code easily. When A inherits from B, we say A is the subclass of B and B is the superclass of A. Furthermore, we say we have pure inheritance when A inherits all the attributes and methods of B. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass. Many similarities occur between the Student and Professor classes of Figure 2. Not only do they have similar attributes, but they also have similar methods. To take advantage of these similarities, I created a new class called Person and had both Student and Professor inherit from it, as you see in Figure 7. This structure would be called the Person inheritance hierarchy because Person is its root class. The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person. The Purchase Parking Pass method is also common between the two classes, something we discovered after Figure 2 was drawn, so that was also moved into the parent class. By introducing this inheritance relationship to the model, I reduced the amount of work to be performed. Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.

Figure 7. Inheritance hierarchy.

3.5 Composition Associations

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. Figure 8 presents an example using composition, modeling the fact that a building is composed of one or more rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition). In UML 2, aggregation would be shown with an open diamond.

Figure 8. Modeling composition.

I'm a firm believer in the "part of" sentence rule -- if it makes sense to say that something is part of something else then there's a good chance that composition makes sense. For example it makes sense to say that a room is part of a building, it doesn't make sense to say that an address is part of a person. Another good indication that composition makes sense is when the lifecycle of the part is managed by the whole -for example a plane manages the activities of an engine. When deciding whether to use composition over association, Craig Larman (2002) says it best: If in doubt, leave it out. Unfortunately many modelers will agonize over when to use composition when

the reality is little difference exists among association and composition at the coding level.

3.6 Vocabularies
In Agile Database Techniques (Ambler 2004) I discussed the importance of vocabularies when it comes to modeling XML data structures. A vocabulary defines the semantics of entity types and their responsibilities, the taxonomical relationships between entity types, and the ontological relationships between entity types. Semantics is simply a fancy word for meaning when were defining the semantics of something were defining its meaning. Taxonomies are classifications of entity types into hierarchies, an example of which is presented for persons Figure 9. Ontology goes beyond taxonomy. Where taxonomy addresses classification hierarchies ontology will represent and communicate knowledge about a topic as well as a set of relationships and properties that hold for the entities included within that topic.

Figure 9. A taxonomy for people within the university.

The semantics of your conceptual model are best captured in a glossary. There are several interesting aspects of Figure 9:

It takes a single section approach to classes, instead of the three section approach that weve seen in previous diagrams, because were exploring

relationships between entity types but not their responsibilities. It uses UML 2.0s generalization set concept, basically just an inheritance arrowhead with a label representing the name of the set. In UML 1.x this label was called a discriminator. There are three generalization sets for Person: Nationality, Role, and Gender. These generalization sets overlap a person can be classified via each of these roles (e.g. someone can be a male foreign student). This is called multiple classification. You can indicate sub generalization sets, for example Student within the Role generalization set. Some generalization sets are mutually exclusive from others, not shown in the example, where an entity type may only be in one set. This is referred to as single classification and would be modeled using an XOR (exclusive OR) constraint between the two (or more) discriminators.

Source
This artifact description is excerpted from Chapters 8 and 12 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

Japanese

Suggested Reading

Artifacts for Agile Modeling: The UML and Beyond Class Diagramming Guidelines Introduction to the Diagrams of UML 2 Introduction to Object Orientation (OO) and UML Modeling Style Guidelines Pavel Hruby's UML 2.0 Stencil for Visio Why Extend the UML Beyond Object and Component Technology? The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile
modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development. The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD). The Object Primer also includes a chapter

overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.

Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation. It
describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts. Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.

The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams.
They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with. These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler. This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer). The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help
I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.

Disclaimer
The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the current version of the UML for one or more of reasons:

The notation may have evolved from when I originally developed the diagrams. The UML evolves over time, and I may not have kept the diagrams up to date. I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the book, and have been reviewed by thousands of people online since then, an error may have gotten past of us. We're only human. I may have chosen to apply the notation in "non-standard" ways. An agile modeler is more interested in created models which communicate effectively than in conforming to notation rules set by a committee. It likely doesn't matter anyway, because the modeling tool(s) that you're using

likely won't fully support the current version of the UML notation perfectly anyway. Bottom line is that you're going to be constrained by your tools anyway. If you're really concerned about the nuances of "official" UML notation then read the current version of the UML specification.