Manage Domain Variations
One of the most effective ways to identify and manage reusable software assets is by understanding the concepts in your domain that vary and the need for supporting these variations in a flexible manner. The idea of domain concepts having variability is not new and is present in several domains.
For example, cell phone software could have variations around size/features on the contact list, ability to create and manage image/video content, and the support for web browsing and data exchange. Using these core categories of variations there might be a variety of cell phone offerings that might need to be supported.
For the sake of an example, lets say there are only three flavors: a basic plan, a medium plan, and a high-end plan. All of them support local and long distance calling, call waiting, caller identification, and voice-mail. The basic might support 50 contacts in the contact list, no support for multiple numbers per contact, and only ability to view pictures from other callers. The medium supports all the features of the basic and additionally offers ability to store multiple phone numbers per contact, take and email pictures as well as store 100 entries in the contact list. The high-end flavor might support storage for 500 contacts, ability to take pictures and store and distribute them, as well as ability to view video content.
What you are looking at is certainly a product line that needs to be managed. If not, there will not be reuse but chaotic duplication of functionality implemented inconsistently across the different flavors. To manage the variations:
Separate common capabilities across products from ones that vary with every product
Identify the capabilities that vary among the products
For each capability identify the parameters that will vary based on product offerings
Establish a means to gracefully upgrade or downgrade among products within the product line
Encapsulate variation characteristics via configuration external to the execution code
The capabilities that are common need to be built as reusable software assets leveraged across the product line. The capabilities that vary are also built as reusable software assets supported by a variability mechanism. In the example from above, contact management could be the same asset reused across all the products with product specific parameters – basic only supports 50, medium 100, and high-end 500 contacts – based on the product the total number of contacts could be customized. Similarly, the idea can be extended to all the other features that vary across products in the product line. This in essence the idea of encapsulating what varies and can be applied to classes and software services. In the coming days, I will expand on aligning product variations within an iterative lifecycle in order to not only achieve systematic reuse but minimize schedule risks.
Understand Domain Context
There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:
What product features typically go together?
Do certain features vary more than others across products?
Is it possible to vary a product feature at runtime or design-time?
All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!
Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.
Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.
#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.
#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.
#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages
#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.
Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.
Capture Variations
Capturing necessary variations in the domain is extremely important to systematic reuse. Business domains are filled with variations that need to be identified and managed across your codebase. Product line variations are at the heart of effective software reuse. To identify variations in your domain you need go seek subject matter experts as well as end users in your shop. Work with them closely to understand the domain, the aspects that tend to vary often, and how these variations are manifested in user stories. From the customer’s point of view, these variations are a natural way of how their business functions. Invest time to make sure that you not only recognize variations as a whole but also identify the sub-set of variations that really matter.
Given the pragmatic nature of software reuse that is necessary, it is unrealistic to identify all variations in a problem domain. Your iterations will not happen and working software won’t get delivered unless you can include and adapt domain variations as part of your development practices. From a design perspective there are some questions that will help you. Every time you look at a user story you should ask yourself:
What domain entities involved?
Are there entities being encountered for the first time?
Is this story requested in more than one product or application?
What aspect of the domain varies in the story? Some common variations tend to reoccur – the kind of user who uses a feature, number of features being offered, differences in behavior for a feature or a group of features, how features are bundled together based on business criteria, interface metaphors and themes, and reporting/charting capabilities.
Are there a set of user stories or aspects of user stories that appear together often?
Last updated
