Summary

In this chapter, I've explored how the basic UML constructs of use cases, actors, and objects (or more properly, types) can be used in a simple fashion to capture the critical aspects of a domain. Modeling the domain properly is the first step to modeling a system successfully.

The definition of domain I've used here can form the basis for applying the idea of domain beyond the original narrow technical meanings of the term found in domain engineering. At the same time, it allows the developer to leverage some of the insights and techniques that domain analysis brought to the forefront: in particular, the notions of commonality and variability as a basis for thinking about reuse from the start, and the idea of treating applications as potentially part of a family.

Domain modeling using the UML is a visibly different activity from the business modeling done as part of business process improvement, avoiding the confusion and turf wars with process consultants that occasionally mar business analysis. Again, ideas from the process improvement world can be usefully appropriated in looking at domains namely, the use of ToBe and AsIs models to help focus the understanding of what the user needs (and wants).

Although they may overlap, a business and a domain are different; it's the domain, not the business, that is of interest to the software-intensive system developer. This point is particularly critical when doing the preliminary thinking about systems that go beyond the boundaries of the business, such as support for supply chain management.

Aside from reviving the idea of domains itself and providing a new home for aspects of business modeling, domain models, as described in this chapter, emphasize the need for another well-respected idea in systems: essential modelsfor analysis. Maintaining an implementation-independent perspective in understanding the problem space becomes even more important in an iterative and architecture-centric development process, which gives rise to architectural decision-making early on. Developing essential views of actors, use cases, and even business objects helps balance the scales in avoiding an architecture that is too shortsightedly based on existing circumstances.

There are a number of resources available for exploring these ideas further, as a way of enhancing your use of the UML. Software Reuse: Architecture, Process and Organization for Business Success(Jacobson, Griss, and Jonsson 1997) provides a good discussion of domain engineering and a critical perspective that is only slightly skewed by a bias toward a particular development process. The Software Engineering Institute (SEI) at Carnegie-Mellon University has a number of important papers about domain engineering on its Web site (http://www.sei.cmu.edu). Jim Coplien's book, Multi-Paradigm Design Using C++ (1998a), has an interesting slant on domains and is the basis for my definition.

From an IT perspective, the only current book worth reading about business modeling is D'Souza and Wills' Objects, Components and Frameworks with the UML: The Catalysis Approach (1998). It is especially useful because of the patterns it includes about business modeling, many of which had a role in the patterns I include here. D'Souza's patterns are the only really useful ones on business modeling in the patterns literature.

Finally, anyone interested in essential models should take a look at McMenamin and Palmer's classic Essential Systems Analysis (1984). Not only is it the best work on thinking essentially, but it is also invaluable for its discussion of event-based analysis the precursor to use cases.



A UML Pattern Language
A UML Pattern Language (Software Engineering)
ISBN: 157870118X
EAN: 2147483647
Year: 2005
Pages: 100
Authors: Paul Evitts

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net