Improving software development is ongoing research by many people. Here, we concentrate on how these various efforts deal with the requirements-design nexus.
Object-Oriented Software Engineering (OOSE) provides some advice on how to relate objects in an object model to use cases [17]. Specifically Jacobson et al. describe how to develop an analysis model by identifying the Interface (now generally referred to as Boundary), Control, and Entity objects needed to realize the use case. While this is useful advice, it does require some interpretation to follow, particularly in assigning behavior to the resulting classes. Our approach is more operational in this regard.
As others before us have have observed, use cases are a convenient way to
organize the requirements to better match an object-oriented design
[18]. As we discussed in section
, Jacobson introduced the use case concept
[17] and Constantine and Lockwood developed essential use
cases as a modification of this original idea for use in user interface
design [9]. There has been much more
written about use cases and their use in software development. Cockburn's
recent book provides a detailed account of how to write use cases, and
includes a good summary of the different styles of use cases
[8]. Armour and Miller discuss how use cases can be
discovered and managed as part of the requirements gathering
process[2]. However, these works say little on how
the use cases are then fed into the analysis and design phases. Discussions
that do relate use cases to design generally advocate the development of
domain models (for example [22]). The domain
model then provides the first step in the development of the design. We
believe the development of a domain model is important, as we have discussed
above. But, we believe there is still a large step between identifying the
requirements and determining how the domain model satisfies those
requirements.
The importance of traceability is widely discussed in the literature. Pfleeger identifies both vertical and horizontal forms of traceability [21]. Vertical traceability refers to identifying relationships within models in the development process, whereas horizontal traceability refers to relationships between models. There is practical evidence to show that emphasizing traceability does improve the quality of aspects of the software development process and reduces maintenance costs [19].
Our work addresses the horizontal traceability between requirements and design artifacts. In our approach, the relationships between the requirements and the design correspond directly to the decisions on how to distribute the responsibilities. This means that the traceability is ensured as part of the design process.
Any software development effort follows some kind of overall process. One of the most talked about processes of late is the Rational Unified Process (RUP) [16]. RUP is a use case driven process, meaning use cases impact each phase of the process. Use cases are as important to our approach as they are to RUP. We differ in the choice of form of use case. Our use of essential use cases is not inconsistent with any of the RUP descriptions, and in fact can be regarded as a refinement of the Analysis and Design work-flow. This work-flow is based on OOSE, which we addressed above.
Another software development process is OPEN (more accurately, a framework for software development methods, but we concentrate on the process part of it). Of particular interest is the OPEN Toolbox of Techniques [14], which provides a comprehensive survey of techniques that can be used to accomplish various tasks needed for software development. There are several techniques the can be used to produce a design model from the initial requirements, including: Collaborations Analysis, CRC card modeling, Delegation Analysis, Domain analysis, Generalization and inheritance identification, and Transformations of the object model. Any of these techniques can be used in conjunction with our approach, and again, the key contribution of our approach is more operational guidance and the direct provision of traceability.
Recently there has been a lot of interest in lightweight processes such as Extreme Programming (XP) [3]. XP's rules on design include keeping the design as simple as possible for the required functionality, and not adding functionality before it is needed. XP is a strongly incremental process that takes individual ``user stories'' (like use cases but written completely concretely) and then incrementally refactoring an extant program to implement those use cases. Some parts of the underlying dynamic of our approach and XP are similar, such as the idea that all design can be seen as refactoring. In XP, design happens when the minimal program is extended to support a new use case, then refactored so that it is well designed. In our approach, the design begins with a complete system object that is imagined to implement the entire program, and all refactorings preserve the responsibilities of this object and simply redistribute them amongst its internal components.