Discussion

Most information technologists use the word domainto mean an identifiable family of applications. More astute observers prefer to include the context in their definition; for example, Jim Coplien defines domain analysis as "the study of fundamental business abstractions" (1998a). For this book, a domain is a packaging of business features and services at some level of abstraction that is meaningful to an organization.

Most current writers who write about the domain-modeling view see domain models as glorified information models. To some extent, this reflects the marginal status of object-orientation until the last few years. Domain engineering (the source of domain modeling) emerged during the same period as object- orientation in response to similar needs (reuse and structure), but following a different route.

A more up-to-date version of domain modeling would incorporate considerations of behavior and interaction. Ivar Jacobson, speaking for the Three Amigos in The Unified Software Development Process, suggests that a domain model that only includes the classes within an area of interest "is really just a special case of (a) business model developing a business model is a powerful alternative" (Jacobson, Booch, and Rumbaugh 1999a, 122).

I've taken the view that domain modeling is the activity of modeling a particular aspect of a business one that uses all of the appropriate constructs available within the UML.

A domain does not have to be contained within an organization. In particular, with the emergence of the networked organization and such trends as cooperation, partnering, and data sharing among companies, the traditional boundaries of organizational interest are dissolving. In these circumstances, a domain can include the elements from a number of organizations, such as a supply chain.

One simplistic example of a domain from automobile distribution might be Asset Lifecycle Management. This is a package of features and services that support the relationship between a distributor and its dealers. A distributor makes the most profit from financing and from controlling churn: the reselling of the car throughout its life. Dealers, not car buyers, are the distributor's real customers, and so they are both the agents and the partners in maximizing profit. Distributors work with the dealers to provide them with services and supporting systems to retain control of each car as an asset for as much of its life as possible. Within this business domain, a variety of applications provides focused services for example, leasing services and systems that maximize ongoing control of a vehicle during its lifecycle.

Domain models are essential for bounding a domain so that it is useful for software planning and management. Software developers model domains to provide the basis for a family of applications. A domain model captures and situates the set of high-level requirements that are common to applications within an identified area of interest. This area of interest may be as broad as an organization (hopefully not) or as narrow as a functional area. The model can include the following:

  • A definition of scope for the domain

  • Information or objects at the conceptual level

  • Features or use cases, including factors that lead to variation again, high-level and business-oriented

  • Operational/behavioral characteristics

To be clear, modeling at this level is sufficiently conceptual so that the only end result of our efforts is models. But because these models provide the basis for understanding and using all the other development artifacts, it is especially critical to the value of our models at all levels.

Higher-level models built to support planning and management are where the new modeling approaches are most starkly different from the traditional ones. These obvious differences most clearly illuminate the maturing of our craft, especially in the areas of why we model and what we model.

6.1 DOMAIN MODEL IS ESSENTIAL

PROBLEM

How to model the important elements of a domain.

CONTEXT

Understanding and documenting the domain context for use in building or refactoring a system or organization.

FORCES

  • A domain model must be capable of being directly validated and explained by the end users.

  • Users know what they do, but may not know what they know.

  • Too much detail can be blinding.

  • Domain information is the critical context for design decisions.

  • Design decisions must be traceable to the domain.

SOLUTION

Document the components of the domain with a minimum of implementation detail. Business activities should be documented with essential business use cases. These are, in effect, scripts that describe interactions with the business or organization in which actors play essential roles. Things and services in the real world are represented as essential business objects.

RESULTING CONTEXT

The essential activities, things, and services are identified, packaged, labeled, and agreed upon. They are made available in diagrammatic form that allows for further massaging as the overall domain model is refined.

DISCUSSION

McMenamin and Palmer (1984) introduced the idea of essential models backin the dying days of structured analysis. In order to reduce the complexity of the information generated when analyzing the need for a new system, an essential model would contain only elements that represented the ideal system, free of any implementation considerations. Recently, the notion of essential models has been revived by writers such as Larry Constantine (who helped develop the idea in the first place). His idea of essential use cases is championed by Jacobson and others (Jacobson, Booch, and Rumbaugh 1999).

6.2 ACTORS PLAY ESSENTIAL ROLES

PROBLEM

How to identify the important interactions in a domain so that they can be modeled successfully.

CONTEXT

Understanding and documenting the domain context for use in building or refactoring a system or organization.

FORCES

  • A domain model must be capable of being directly validated and explained by the end users.

  • User interactions form the basis for system events.

  • Domain jobs and user titles may not match responsibilities.

  • Domain jobs and user titles may change.

  • A domain model should not only reflect current realities.

  • Too much detail can be blinding.

  • Domain information is the critical context for design decisions.

  • Design decisions must be traceable to the domain model.

SOLUTION

Start by examining stereotypical roles that are external to the domain examples of types of users of the domain, rather than real users or anything else that is external to the domain that interacts with it. Each role is a candidate for being represented as an actor in your model. Establish the actors by refactoring these roles into essential roles generic parts played by participants in the domain script, rather than job names or titles.

The intent is to establish the types of users who are interacting with the domain and the system as a starting point for listing and analyzing the interactions themselves. Avoid being too fine-grained: ATM_Customer is (normally) preferable to separate roles of Depositor, Withdrawing Customer, Balance Checker, and so on. These roles should be meaningful to your user, and they should reflect the way the business or organization actually interacts with the outside.

RESULTING CONTEXT

The main roles within the domain are identified and packaged, labeled, and agreed-upon. They are made available in diagrammatic form that allows for further massaging as the overall domain model is refined. Each role also helps to define the bounding and scope the domain. And each role provides a starting point for listing essential domain activities.

DISCUSSION

In Software Reuse: Architecture, Process and Organization for Business Success, Jacobson, Griss, and Jonsson (1997) use the phrase "Actors model roles" to signify how to think about actors. McMenamin and Palmer's Essential Systems Analysis (1984) also provides another insight into how to think of actors that is, separated as much as possible from implementation details (for example, job titles) or technology (external systems). This pattern is eminently scalable and applies to system actors as well anything that interacts with the system. However, the essential quality is most important in determining the actors in the domain itself.

6.3 FACTOR THE ACTOR

PROBLEM

How to model the roles that define the users and uses of the system in a useful way.

CONTEXT

Modeling the boundary and context of a product, and to a lesser extent, a domain.

FORCES

  • Users can have multiple roles.

  • A role can be performed by multiple users.

  • Roles need to be generic but focused.

  • Actors are environmental.

  • Actors are contextual.

  • Actor identification is iterative.

SOLUTION

Identify actors use roles iteratively. As you work through use cases, continually refine them either by moving from the specific to the abstract, or vice versa. Look at the functions and responsibilities associated with the events that trigger interactions with the domain or system by each actor. Roles that have common functions or shared responsibilities may be combined. On the other hand, significant variations between roles that are superficially the same may have to be identified as distinct actors. Variations on Customer are simple examples.

RESULTING CONTEXT

Actors with appropriate granularity that can help provide a starting point for defining common variations.

DISCUSSION

Actors are a critical starting point for establishing the use cases that are the functional requirements for products in a domain. They must be identified in a disciplined fashion.

A domain with established boundaries and substantial history will have clearly defined functions and tacit domain experts who can kick-start the process. Use them and their roles as a beginning.

On the other hand, if you are introducing new technology or processes, or involved in some form of reorganization or re-engineering, you may need to look at the technology or the target business model for guidance in identifying abstract roles, types of users, or potential job functions.

6.4 ESSENTIAL ACTIONS

PROBLEM

How to represent the activities of a domain to provide focus in documenting the requirements and analysis model.

CONTEXT

Understanding and documenting the domain.

FORCES

  • A domain model must be capable of being directly validated and explained by the end users.

  • Users know what they do, but may not know what they know.

  • Too much detail can be blinding.

  • Unnecessary complexity can be misleading.

  • Activities are atomic and unconnected.

  • Processes are commonly understood packages of domain actions.

SOLUTION

Document the essential actions within a domain by building a set of business use cases. Focus on describing the normal flow of the typical procedures that users are familiar with. Rework these use cases to reflect the real needs of the users. Use business use case diagrams to help refactor the domain itself; that is, to reorganize your understanding of what happens in the domain, and ultimately to perhaps reorganize the domain itself.

RESULTING CONTEXT

The essential activities are identified, packaged, labeled, and agreed-upon. They are made available in diagrammatic form that allows for further massaging as the overall domain model is refined.

DISCUSSION

Business use cases are simple but effective tools that can be developed by end users, frequently without any explicit guidance from technical types. After the focus on normal flow is made clear, these cases provide a convenient mechanism for unearthing the essential and the critical in discussions about the actions taking place in a domain. The diagrams provide a concise, short-form way of visually packaging the results, without excessive formalism or syntactical overhead. Again, this is ideal for supporting the joint iterative analysis of a domain with users.

6.5 ESSENTIAL VOCABULARY

PROBLEM

How to document your understanding of the domain in a way that captures the essential information and provides a common vocabulary with your users/customers.

CONTEXT

Understanding and documenting the domain.

FORCES

  • Too much detail can be blinding.

  • Words must work both ways.

  • Many aspects of a domain may be understood tacitly and lack formal expression.

  • Vocabulary-building provides insight into a domain.

  • Technical language can confuse or intimidate users.

  • Objects are not just for systems.

SOLUTION

Develop a domain model that consists of business use cases and a preliminary catalog of business objects.

RESULTING CONTEXT

A vocabulary of domain actions and interactions (use cases) and objects (a catalog and preliminary Business Object model) that combines graphical and high-level textual information for ease of discussion.

DISCUSSION

The essential analysis of a domain is both iterative and incremental. Broad stroke pictures that can be changed easily and quickly work best in a joint effort by the architect and users. Business use cases provide labels for activities, and business objects provide names for a basic vocabulary. Defining the use cases and objects in collaboration with the users provides a common understanding of the meaning of the elements of the vocabulary.

Designing the domain model is what Donald Schon (1983) refers to as engaging in a "reflective conversation with a situation" involving "spatial action language," a language that "combines drawing and speaking." The UML itself provides the basis for a common vocabulary for a spatial action language for business modeling. As the big picture emerges, local experiments with model elements reveal the need for new elements or the need to change the existing model.

6.6 OBJECTIFY INTERNAL ROLES

PROBLEM

How to model the roles played by people, systems, and organizations within a domain.

CONTEXT

Building a domain model and providing a context for defining product requirements.

FORCES

  • An organization's interactions with the outside world can be mediated by people or systems.

  • A domain model must be capable of being directly validated and explained by the end users.

  • Internal roles interact with people or systems.

  • Domain jobs and user titles may not match responsibilities.

  • Domain jobs and user titles may change.

  • Too much detail can be blinding.

  • Domain interactions are the critical context for system design decisions.

  • Design decisions must be traceable to the domain model.

SOLUTION

This is very similar to identifying essential roles as actors. Start by examining stereotypical roles, but examine those that are internal to the domain this time. Each role is a candidate for being represented as an object in your domain model. Establish the people objects by refactoring these roles into essential roles generic parts played by participants in the domain script, rather than job names or titles. The intent is to establish the types of users who are interacting with actors and the domain's systems as a starting point for listing and analyzing the interactions themselves.

RESULTING CONTEXT

The main roles within the domain are identified and packaged, labeled, and agreed-upon as objects. Each "object" will in turn be available for further analysis as potential actors in the system-use cases that define the requirements for the product.

DISCUSSION

In modeling with the UML, only external roles can be modeled as actors. People and things within a domain that provide the domain services required by a domain actor can be modeled as objects from the perspective of the domain itself. In an essential model, both an ATM and a teller provide banking services to an actor called Bank Customer. Later on, workers as objects within the domain themselves become prime candidates for actors of the application that constitutes the product.

6.7 TOBE MODEL

PROBLEM

How to document important information about the way the domain should work.

CONTEXT

An essential model of the domain is available.

FORCES

  • Product requirements need to be traceable to an idealized state of the domain.

  • The idealized state of the domain should reflect the essential model.

  • Domain visioning is strategic.

  • Re-engineering may be necessary at the domain level.

  • Visioning needs to be anchored.

  • Too much detail can be blinding.

SOLUTION

Do a ToBe model after developing the essential domain model. The ToBe model refines the essential domain model to highlight practices that reflect a common vision of how things should be done. It should specifically identify potential visionary solutions to problems identified in the AsIs model. As with the AsIs model, the essential business use cases may be extended and detailed, and the preliminary Business Object model may have visionary objects. Avoid unnecessary detailing, however, and do not include any use cases that don't add value to the analysis of either opportunities or product requirements avoid jargon, market-speak, or philosophy. Patterns or anti-patterns can be used to compress specific and repeating elements that need additional highlighting and discussion.

RESULTING CONTEXT

A domain vision is documented that is traceable to the essential model of the domain. The product vision and requirements should be traceable to this vision. The ToBe model extends the essential model and is directly traceable to it. Red flag situations are explored in terms that are understandable to the user. Opportunities for re-engineering are highlighted. Note: the ToBe model does not need to be large if the essential model captures the critical underlying elements of the domain and if the AsIs model that highlights current problems indicates that improvement rather than re-engineering is needed.

DISCUSSION

Traditional systems analysis and business re-engineering have focused on understanding the current situation in an organization as a first step, followed by the development of an ideal vision as a replacement. Frequently, however, because of the time and resources depleted doing the AsIs model, management cuts short the modeling of the ToBe vision, reinforcing the quick solutions framed by "the way things are done" in the AsIs model. Regardless, the existence of two separate models (the AsIs and the ToBe models) creates problems for maintenance and impedes traceability.

6.8 ASIS MODEL

PROBLEM

How to document important information about the domain as it currently works.

CONTEXT

An essential model of the domain is available.

FORCES

  • Problems and opportunities may need to be traceable to the current state of the domain.

  • The current state of the domain should reflect the essential model.

  • Focusing on "the way things are done" can impede a clear understanding of the essential aspects of a domain.

  • Re-engineering may be necessary at the domain level.

  • Implementation details may be problematic.

SOLUTION

Do an AsIs model after developing the essential domain model. This way, an AsIs model refines the essential domain model to highlight current practices. For example, the essential business use cases may be extended and detailed, and the preliminary Business Object model may have specific objects added that are currently in use (for example, paper documents). Avoid unnecessary detailing, however, and do not include any use cases that don't add value to the analysis of problems and opportunities. Patterns or anti-patterns can be used to compress specific and repeating elements that need additional highlighting and discussion.

RESULTING CONTEXT

Sources of current problems are modeled to extend the essential model and is directly traceable to it. Red flag situations are made visible and explained in terms that are understandable to the user. Opportunities for re-engineering are highlighted.

DISCUSSION

Traditional systems analysis and business re-engineering have focused on understanding the current situation in an organization as a first step, followed by the development of an ideal vision as a replacement. Frequently, however, the focus on modeling the current situation turns out to be both overly expensive (in time and resources) and misleading, which encourages quick solutions framed by "the way things are done." Also, the existence of two separate models (the AsIs and the ToBe models) creates problems for maintenance and impedes traceability. By starting from the essential model and adding only those refinements needed to pinpoint problems and opportunities, an AsIs model can help focus discussion around re-engineering and refactoring requirements. Note, however, that AsIs use cases are not requirements.



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