The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Transitioning to the UML

You can model 80 percent of most problems by using about 20 percent of the UML. Basic structural things, such as classes, attributes, operations, use cases, and packages, together with basic structural relationships, such as dependency, generalization, and association, are sufficient to create static models for many kinds of problem domains. Add to that list basic behavioral things, such as simple state machines and interactions, and you can model many useful aspects of a system's dynamics. You'll need to use only the more advanced features of the UML once you start modeling the things you encounter in more-complex situations, such as modeling concurrency and distribution.

A good starting place for using the UML is to model some of the basic abstractions or behavior that already exist in one of your systems. Develop a conceptual model of the UML so that you'll have a framework around which you can grow your understanding of the language. Later on, you'll better understand how the more advanced parts of the UML fit together. As you attack more-complex problems, drill down into specific features of the UML by studying the common modeling techniques in this book.

If you are new to object-orientation,

• Start by getting comfortable with the idea of abstraction. Team exercises with CRC cards and use case analysis are excellent ways to develop your skills of identifying crisp abstractions.

• Model a simple static part of your problem using classes, dependency, generalization, and association to get familiar with visualizing societies of abstractions.

• Use simple sequence or communication diagrams to model a dynamic part of your problem. Building a model of user interaction with the system is a good starting place and will give you an immediate payback by helping you reason through some of the system's more important use cases.

If you are new to modeling,

• Start by taking a part of some system you've already builtpreferably implemented in some object-oriented programming language, such as Java or C++and build a UML model of these classes and their relationships.

• Using the UML, try to capture some details of programming idioms or mechanisms you used in that system, which are in your head but you can't put down directly in the code.

• Especially if you have a nontrivial application, try to reconstruct a model of its architecture by using components (including subsystems) to represent its major structural elements. Use packages to organize the model itself.

• After you become comfortable with the vocabulary of the UML and before you start cutting code on your next project, build a UML model of that part of the system first. Think about the structure or behavior you've specified, and only then, when you are happy with its size, shape, and semantics, use that model as a framework for your implementation.

If you are already experienced with another object-oriented method,

• Take a look at your current modeling language and construct a mapping from its elements to the elements of the UML. In most cases, you'll find a one-to-one mapping and that most of the changes are cosmetic.

• Consider some difficult modeling problem that you found clumsy or impossible to model with your current modeling language. Look at some of the advanced features of the UML that might address that problem with greater clarity or simplicity.

If you are a power user,

• Be sure you first develop a conceptual model of the UML. You may miss its harmony of concepts if you dive into the most sophisticated parts of the language without first understanding its basic vocabulary.

• Pay particular attention to the UML's features for modeling internal structure, collaboration, concurrency, distribution, and patternsissues that often involve complex and subtle semantics.

• Look also at the UML's extensibility mechanisms and see how you might tailor the UML to directly speak the vocabulary of your domain. Take care to resist the temptation to go to extremes that yield a UML model that no one but other power users will recognize.