Discussion

Product design and development has long been a well-defined discipline outside of software development. However, the idea of treating internally developed systems as products within organizations has only recently started to emerge as a way of managing corporate development. Recently, organizations such as Microsoft and object-oriented methodologists such as Brian Henderson-Sellers have recognized the need to organize development by product (the end result), rather than just focusing on projects (the work itself).

The Microsoft Solution Framework (MSF) is particularly interesting. MSF is Microsoft's publicly available development process its alternative to Rational's Unified Process and Catalysis for developing component-based systems. It incorporates a number of features that can be considered UML-friendly, including an emphasis on architecture, the use of small teams for development, an iterative and incremental development cycle, and, of course, product as a cornerstone (details at http://www.oteam.com/msf).

Models are a critical element of product as a coherent way of packaging software-intensive systems to enhance their long-term management. They are no longer merely archival after a system is deployed; instead, they become the basis for managing and evolving a system throughout its life as a product.

I discuss product in more depth in Chapter 10, "The UML in Context."

7.1 MANAGABLE PRODUCT

PROBLEM	How to ensure that the end result of a development effort is manageable, appropriate, and sustainable.
CONTEXT	Planning and managing using the UML.
FORCES	Products can be modeled from a management perspective Modeling must support management as well as engineering. Projects have a predefined set of boundaries both scope boundaries and time boundaries. The life of a piece of software is longer than any of the individual projects that create or maintain it. Software is an organizational asset that needs to be managed as an asset. The management of software development needs a broader perspective and longer timeframe than a project. Software provides solutions to business and technical problems that are ongoing and changing. Redundant and duplicate projects and stovepipe systems can result from project conceptualization and planning with too narrow a focus or that narrowly reflects the memory of an organization.
SOLUTION	Focus on the product being developed, not the Make the product model the fulcrum for development and management. Identify the requirements for the product as a whole. Model the overall solution as a product with a lifecycle of its own, from birth to death. Start with a product definition that captures the idea of the solution without being constrained by dates and schedules. Integrate the product within a domain framework of shared services. Define how the product itself will be managed, apart from any development projects that may be required. Identify requirements and metrics with the product. Establish a set of criteria for ending the product life.
RESULTING CONTEXT	An overall framework for managing development and the results of development that aligns with the needs of customers and business management, rather than just the concerns of technical staff and the priorities of project managers.
DISCUSSION	This is one of those patterns that explains why models are important, rather than how to model. A project focus for development emphasizes solving immediate problems and meeting a deadline. Project management has a narrow focus solving project problems associated with providing a set of tangible end results within the timeframe and scope established by project planning. For a software product to be managed effectively, to be planned proactively, and to provide ongoing value, it needs to be continually managed. A product-based approach allows key components of software to be managed beyond the duration of individual projects (especially requirements and quality measures), and allows for capturingexperience in a more useful form.

7.2 PRODUCT STAKEHOLDERS ARE MODEL CLIENTS

PROBLEM	How to help manage a product using a product model.
CONTEXT	Identifying the roles of key players in the organized life of a product.
FORCES	Products are part of a domain. Products must be planned and managed. Products are organized as well as engineered. The product organization must be defined if the product is to be planned and managed. Stakeholders have a role, just as users do (stakeholders are actors in the domain). The product has responsibilities to stakeholders. Stakeholders have responsibilities to the product. Contracts define mutual responsibilities. Organization is an architected abstraction. Models represent abstractions. Organizations are models.
SOLUTION	Use the UML to capture the organization model needed to make the product manageable over time. This model can be an alternative to an organizational chart or can complement it, depending on the extent to which the organization chart reflects jobs and positions, rather than roles. The organization model should reflect roles, not jobs or positions. This is a critical aspect of defining a product, and is another type of context diagram. In particular, identify stakeholders and their roles. A stakeholder has a more general relationship to a product than the product owner(s). Some stakeholders are product owners (the people who control the money that makes ongoing development possible). Some provide other resources (for example, network bandwidth, processing time, or support staff). A variety of product responsibilities can be identified and diagrammed for stakeholders. Typical responsibilities that should be understood up front include "advise" (keep informed) and "consent" (approve), as well as the traditional "provide resources." The range of responsibility types may be more nuanced than this, of course, but the range of responsibilities needs to be factored into types that make sense for the organizational culture and politics, as well as for the organizational architecture. The organization model should also, of course, identify the development team roles. However, remember that the client for this model is the stakeholders not the users and not the workers. In effect, you're creating an architectural view of the organization to provide management context.
RESULTING CONTEXT	The stakeholders can see and validate the organization architecture for the product easily, and it is presented in a fashion that is consistent with the other product management artifacts.
DISCUSSION	Ivar Jacobson addresses the larger issues of modeling an organization in The Unified Software Development Process (Jacobson, Booch, and Rumbaugh 1999a). The UML's business modeling profile reflects the unified process approach of modeling an organization providing a set of extensions that facilitate using the UML in describing organizational architecture. David Taylor provides a non-UML perspective on modeling an organization as part of developing business systems (and re-engineering business) in Business Engineering with Object Technology (Taylor 1995).

7.3 PRODUCT EVENTS IN CONTEXT

PROBLEM	How to scope and bound the product.
CONTEXT	Planning the product and the development effort.
FORCES	Products are part of a domain. Products provide services that must be clearly defined. A product must have a contract with its customers. Services must have users. Products must be planned and managed. Development work must be scoped. Scope and boundaries can be elusive and changeable. Work products must be traceable.
SOLUTION	Create a context diagram as a model of the product's interaction with the outside world. This can take the form of black-boxing the product as a package, with the system's actors attached and their interactions annotated (see Figure 7.1) Figure 7.1. A simple context diagram. . The workers and external systems modeled in the domain model provide a starting point. Any business actors that will interact with the system are also included. In some cases, customers may interact directly with the system. In other cases, a business interaction in the domain model may be mediated by a worker object interacting with the product. Annotate the actors to document the user roles, interactions, and key business abstractions that are central to the product. Each interaction should be explainable as an event it should be triggered by an action on the part of the actor involved, and it should be completed by the system. Make sure that it's tangible and provides value for the actor. Desmond D'Souza and Wills provide a comprehensive approach to modeling a system's context in their book (1998, 592). The Catalysis Approach extends the notion of collaborations, makes use of a variety of UML artifacts to detail the context dynamics, and uses packages and actors to define the boundaries.
RESULTING CONTEXT	Management can see the boundaries and scope of the product easily, in terms that are meaningful to them. The development team can understand the business contract that the product must meet.
DISCUSSION	Context diagrams are old and honorable tools in the arena of systems development. Although never formalized in a way agreeable to all, the need for a diagram type that establishes the environment and key interactions with the outside world (and the boundaries with that outside world) are running themes in modeling. Packages and actors, and use cases and business objects provide a UML equivalent to the data/process modeling "single bubble" that encapsulated the application inside and situated the outside world outside.

7.4 USE CASES REPRESENT REQUIREMENTS

PROBLEM	How to document product requirements in a way that is meaningful to the product user and efficient for the product developer.
CONTEXT	An evolving product within a domain, modeled by using the UML.
FORCES	Requirements are fundamental and provide the justification for any development activity. Requirements need to be organized and managed. Product evolution needs to be robust (that is, able to incorporate change in a managed fashion). Product management needs to be able to organize development work. In an ideal world, changes should not cause rework or distort the solution provided by the product. Too much detail can be blinding.
SOLUTION	Document your product's business requirements in the form of use cases. If you're using a requirements management tool, map the individual detailed requirements to the use case(s) that realize them, but use the use cases as your organizing structure for planning work and increments. All requirements identified during preliminary analysis should map to one or more use cases. Requirements that don't map to any use cases may be badly defined or redundant.
RESULTING CONTEXT	A coherent organized model of the business requirements that can provide a starting point for organizing work and planning product increments (the product lifecycle) in a visually graphic and textually straightforward form.
DISCUSSION	For this pattern, the important aspects of use cases to remember are that they represent an interaction with the product, and that the interaction provides added value to the user. The product requirements are made explicit by rendering the interactions pictorially and textually, and ensuring that each interaction does provide value. Use cases provide a framework for packaging and managing requirements that are meaningful to the user and beneficial to both the developer and planner. It is also important to remember that use cases do not detail the how the underlying processes or algorithms that produce the results. They are not process models, which are specification artifacts rather than analysis artifacts. A properly defined use case model is a contract with the user that spells out what will be provided by the product.

7.5 BOUNDARY-CONTROL-ENTITY (BCE)

PROBLEM	How to organize the initial list of objects to facilitate further analysis, design, and implementation.
CONTEXT	Analysis has produced a preliminary set of use cases, and these have been reviewed to identify a candidate list of objects.
FORCES	All objects are not alike. All objects are not equal. Different types of objects have characteristic behaviors and responsibilities. Analysis needs to be focused. Boundaries need to be clear.
SOLUTION	Stereotype each analysis object as either a boundary object, a control object, or an entity object to provide a logical view of the roles played by each in the domain being analyzed (see Figure 7.2). A boundary object is responsible for communication between the system and its surroundings. According to Jacobson (1994), each boundary object should (ideally) be concerned only with communications and interactions with actors (including the system variety). Originally, Jacobson called them "interface objects," which is probably more expressive of their purpose, but interface is an overworked term. The canonical example is an ATM interface. A control object performs all of the sequencing and control functions associated with a use case. In effect, it acts as a manager for a use case. Control objects, being solely responsible for the sequencing of operations and flow of control within a process (or system), should neither interact with the actor nor be concerned with managing persistence. There should be at least one control object for a use case (although they may be shared like the others). Entity objects should be the home for any information that lasts longer than the life of a use case. Focus on the specific characteristics of each type in refining your analysis. When appearing in diagrams of UML models, the boundary/control/entity stereotypes can be represented by using the standard angled brackets notation (<<and >>) or guillemets. The UML also provides graphical icons that can be used in place of guillemets. These are suitable when used within analysis models or where detailed information about the class that is represented isn't needed. Use the textual stereotype in the class name compartment when class details must be shown. Be careful to use the stereotypes consistently within diagrams to avoid confusion. Also, donot depart from the semantics of the boundary/control/entity stereotypes. Figure 7.2. Boundary-control-entity pattern as a collaboration. Figure 7.3 shows how the boundary-control-entity collaboration can be depicted with UML stereotypes in the classes as well as by using graphical icons. Be consistent by using one or the other. Figure 7.3. Alternative UML notations for BCE.
RESULTING CONTEXT	A more precisely defined model that establishes relationships between the objects created by development cycle iterations that can be used to explore the details of the domain. This is especially valuable for obtaining user feedback and validation, as well as to document the types of behavior the classes are intended to exhibit.
DISCUSSION	BCE stereotyping is a simple way of enriching UML models with information that may be useful to users. Also, it is closely related to the preceding use case analysis and provides an additional means of establishing traceability. Jacobson has discussed the BCE pattern in each of his books, and applied it to both business use cases and system use cases. In The Object Advantage (1995), he also explains how to translate a business model expressed using the BCE pattern into the starting point for defining system interactions that support each business use case. This is refined in Software Reuse (Jacobson, Griss, and Jonsson 1997).

7.6 PRODUCT CHUNKS DIGEST EASILY

PROBLEM	How to scope incremental development of a product.
CONTEXT	Planning and managing a model-based product.
FORCES	A product is incrementally developed. Requirements change over time. New requirements may be identified during the life of a product. Use cases define product requirements. Use cases drive product specification. Developers like a feeling of accomplishment often. Users like results. Managers like the feeling of control.
SOLUTION	With high-level system use cases as the basis for planning, plan for short development cycles with frequent incremental releases. After each release, replan the remaining portions of the product life-cycle, including the prioritization and scope of future increments (refactor the remainder). But remember that use cases do not structure the product itself, only the development work architecture structures product.
RESULTING CONTEXT	Well-formed use cases that support minimal rework in the evolution and maintenance of a product.
DISCUSSION	The UML is implicitly supportive of an incremental and iterative development style. Barry Boehm's spiral lifecycle is the closest approximation available to a development approach that combines the needs of management (control and communication) with realistic planning. Use cases provide the most reasonable approach to chunking development work so that work boundaries are meaningful to the user and incremental functionality is traceable to real requirements. However, use cases are not architecture. Because use cases are analysis artifacts and not design artifacts, they provide a communication tool for working with domain management and users. They do not provide a way to structure the product; the product architecture does that.

7.7 PRODUCT TRACES SUPPORT ROBUSTNESS

PROBLEM	How to ensure that product changes are consistently integrated and aligned with product requirements as the product evolves.
CONTEXT	An evolving product specified, designed, and implemented with UML models.
FORCES	Product evolution needs to be robust (that is, able to incorporate change in a managed fashion). Product knowledge needs to be maintained as the product evolves. The requirements are fundamental and provide the justification for any development activity. Use cases model requirements. In an ideal world, changes should not cause rework or distort the solution provided by the product. Too much detail can be blinding.
SOLUTION	Support extended traceability within the overall product model itself, using the <<traces>>stereotype of the UML to highlight connections between artifacts. Traces are used to denote connections between elements in different models (such as the analysis model and the design model); they are not allowed within a model. The connections can either result from development and refinement, such as from requirement to implementation (and vice versa), or they can result from versioning (traces between versions and version elements).
RESULTING CONTEXT	The product models specifically include key traceability information in a visually graphic form that can provide clear guidance when change requests or new requirements occur.
DISCUSSION	Jacobson emphasized robustness and traceability as key benefits of object-oriented development from early on, in the OOSE methodology that preceded Objectory. And an emphasis on traceability as a contributing factor to robustness was one of the contributions OOSE offered to the UML. The increasing importance (and successes) of short-cycle development and incremental product evolution make robustness and traceability critical aspects of good design and good management via models. Other parts of the UML can also contribute (for example, the "realizes" association that specifies the relationship between an interface and the class/component that actualizes it). One of the strengths of the UML is its adaptability and breadth. A diagrammatic representation of key traces is only part of an overall traceability strategy that includes configuration management and traceability data collection during development. However, although traceability is desirable for its positive impact on product quality and manageability, the overuse of traceability via diagrams can reduce their clarity. The UML Reference Guide suggests using hyperlinks between model elements to identify traceability other than critical links that are needed during model development as human helpers, as reminders of changes that need to be propagated across models, for example (Jacobson, Booch, and Rumbaugh 1999b, 494).

7.8 USE CASES: WORK AS PACKAGES

PROBLEM	How to partition the development work to be done in a useful way.
CONTEXT	Managing development in an incremental process.
FORCES	Development efforts have to provide visible and usable results for the customer. Incremental development requires easy integration of each increment. Work boundaries must have some meaning to the developer as well as the user. The acceptance-testing model is based on use cases. Granularity of work impacts ease of planning and progress tracking. Work products must be traceable.
SOLUTION	Define units of development work according to high-level use cases. Package use cases that will be done together. The use cases should be analyzed for risk and prioritized accordingly, depending on whether the development approach is risk-driven or risk-aversive. Map the release strategy to the use case packaging, and develop other artifacts such as manuals by use case package.
RESULTING CONTEXT	Increments that provide value to the customer, which are real chunks of functionality for the developer and have meaningful boundaries for management.
DISCUSSION	Although the UML does not, by itself, impose a development process, the notion of use cases and the strategy called use case-driven development are woven into its threads. (And besides, they make sense.) Traceability back to requirements is via use cases, and the most sensible way to organize testing is around use cases. They provide a convenient way of organizing the work at hand for communicating with the customers and stakeholders, as well as a convenient starting point for planning. However, it is important to remember, as I've cautioned elsewhere, that as analysis artifacts, they do not drive the architecture.

7.9 TESTS NEED MODELS

PROBLEM	How to align testing with development to ensure that testing is focused, consistent, and meaningful.
CONTEXT	Supporting the life of a model-based product.
FORCES	Object interactions are complex and may be nondeterministic for practical purposes. Testing should be repeatable. Testing needs to be planned and designed. Testing needs to reflect the purpose and objectives of the product. Users need requirements-based testing. Designers need architected testing. Developers need detailed testing. Managers need reassurance. Testing assets are expensive to create and maintain. Testing assets can be refactored and reused. Testing is expensive. Testing should provide closure to all, including users and stakeholders.
SOLUTION	Fabricate a test model that parallels and refactors the product model. For example, user acceptance testing should be built around the use cases validated by the users, based on scenarios developed to validate the requirements themselves. These scenarios can also be used for usability testing and as a basis for automated stress testing. Manage the life of the test model for a product in the same way that the other models are managed.
RESULTING CONTEXT	A basis for managing product testing throughout the product lifecycle, as well as iterations of the development lifecycle.
DISCUSSION	Testing is not a stage, but rather an ongoing activity. As with any aspect of an architected and model-driven process, testing needs to be based on models that are consistent with models developed for other views of the product, but differentiated according to the specific needs and perspective of the model client in this case, the tester. Because the underlying process for UML-based modeling is driven by use cases, and because use cases provide the basis for traceability and significant communication with the end user, the test model for a product should be derived from the use cases it includes. This approach also provides a means of closure because the acceptance testing for each release will be based on the initial scenarios derived from the use case model, closing the loop of validation.

7.10 CONFIGURATION MANAGEMENT MODEL

PROBLEM	How to organize and control changeable models in an architected environment.
CONTEXT	Managing product models over time and, more generally, applying the UML in a consistent and uniform fashion. (Note: this is a pattern that says we use models for everything.)
FORCES	Products need to be packaged. Products evolve and so need to be packaged at slices in time. A product is only as good as its architecture. An architecture is only as good as the models from which it's made. Product models are visible. Product models are management tools. Product components change as well as evolve. Development work is done in chunks. Work chunks need to be organized and managed. He who ignores history is doomed to repeat it. The last minute is too late. A chain is only as strong as its weakest link. The UML should be used consistently and uniformly across all domains of development.
SOLUTION	Establish a configuration-management model for the product at the start of development. From a management perspective, this is the dynamic equivalent of the product architecture. Start by establishing the key work products that need to be managed as a whole and kept in synch. These are the core of the product and they need to be up-to-date for all product stakeholders: senior management, product management, the development team, and production. These packages are called configurations, and the key work products are called configuration items. Using the key models from each stage of development, identify the key work products from the overall development process that will need to be managed as a whole. Model the static and dynamic relationships of these work products as a starting point for documenting the overall approach to configuration management over the development lifecycle and product lifecycle. Define and document a configuration-management process using a UML model. This must be integrated with change management, testing, and release management (see example that follows).
RESULTING CONTEXT	A process for managing the evolution of a product that is documented consistently and that is consistent with the other documentation artifacts associated with the product.
DISCUSSION	A defined and clearly communicated model for handling the versions and configurations of a product is a core requirement for successful product management, not just project management. Various SCM tools provide variations on standard themes for how to handle configuration management, but their approaches need to be evaluated against what works in a given organization and development culture. A configuration model can be derived from a corporate model as one target that can be reused. Alternatively, a product may require a special configuration model to suit special needs. There are an increasing number of patterns available that deal with the specifics of configuration management. A notable one is by Brad Appleton, Steve Berczuk, and others calledStreamed Lines: Branching Patterns for Parallel Software Development at http://www.enteract.com/~bradapp/acme/branching/branch-structs.html (1999).

Summary

This chapter has provided a starting point for seeing how the UML can be used to help model a system from a product perspective. Identifying the context, providing support for maintenance and testing, and managing the product are all activities that need to handled with models just as much as the actual design itself.

Many of the patterns in Chapter 6, "Domain Patterns," are also applicable at the product level, with the boundary of the area of interest shifting from the business to the system.

Designing the product is when you'll use some of the major sources of other patterns. Martin Fowler's Analysis Patterns(1997), theGang of Four's Design Patterns (Gamma et al. 1995), and A System of Patterns (Buschmann et al. 1996) are the prime sources for useful patterns.