Change cases: use cases that identify future requirements

Change Cases: Use Cases that Identify Future Requirements Earl F. Ecklund, Jr. Objective Technology Group Beaverton, OR 97008 [email protected] Lois M. L. Delcambre Oregon Graduate Institute Beaverton, OR 97006 [email protected] ABSTRACT Evolution of software systems is prompted by all sorts of changes. This paper demonstrates how the use case, a well known construct in objectoriented analysis, is adapted to form the change case, to identify and articulate anticipated system changes. A change case provides the ability to identify and incorporate expected future change into a design to enhance the long-term robustness of that design. In this paper, we define change cases and demonstrate how change cases are captured by the analyst. We present examples to illustrate how change cases can influence present system design and point the way toward designs that more easily accommodate expected future changes. Change cases can be effectively employed in the context of any methodology that supports use cases and traceability links. I - INTRODUCTION AND MOTIVATION Software systems derive their usefulness from providing services in an operational context that consists of human (and electronic) users who request either information or action. These requests are embedded in larger organizational processes, of which the human users are a part. System change is sometimes necessitated because of a poor initial match between the system and its context. However, even if a system is well matched with its context, change is inevitable. Brooks observed that “the software product is embedded in a cultural matrix of applications, Michael J. Freiling Conceptrics Portland, OR 97213 [email protected] users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product.” [Brooks871 Examples of such changes include: Market changes - As a business becomes more successful, the client base it serves tends to grow larger and more demanding. New clients may require things done ‘their way’, especially if the business they do is significant in volume. A large customer, for instance, may require on-line access to order and inventory information, requiring a new avenue of access to the system. Business requirements change Organizations are constantly changing their policies and procedures to cope with changes in their environment. For example, a new policy may be established to check a customer’s account status before shipping goods to fill an order. This policy change will affect the organization’s order fulfillment system. Operational processes change - Required information or actions are redefined because of changes to the operational process for internal or economic reasons. For example, the elimination of data entry clerks in an order process may require the system to expand its capabilities to validate raw data as it enters the system. Legislative or regulatory change Operational actions may need to be changed and new information acquired in the face of legislative or regulatory change. Previous operations may now be forbidden, Recent Financial Accounting Standards Board (FASB) regulations requiring companies to account for pension and retiree Permission to make digital/hard copy of part or all of this work for personal or classroom use is ranted without fee provided that copies are not made or distributed for pro BIt or commercial advantage, the cppyright noti% the title of the publication and its date appear, and notice !s given that copying is by permission of ACM, Inc. To copy otherwlse, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. OOPSIA ‘96 CA, USA (D 1996 ACM 0-89791-788-x/96/0010...$3.50 342 A change may have a small focus and yet still have a large scope. In a system that was not carefully designed, for instance, the change of medical benefits, for instance, could require a company’s reporting system to access information that was not previously needed. expanding Social Security Numbers to include Canadian and other national identification numbers could have a tremendous scope, even though its focus is quite small. Imaginative users -- As users become more familiar with a system, they inevitably discover ways in which it could better meet their needs. Users will request enhancements that make them more productive, even when their initial satisfaction with the system was quite high. To understand and analyze change effectively, it is necessary to understand the key characteristics of each change under consideration. We have identified three key characteristics that we will rely on in this paper to discuss the analysis and handling of potential changes. The focus of a change is the set of system responsibilities that the change directly affects. Take a billing system for example. If we are contemplating a change to the billing terms from net 60 days to net 30 days, then the focus of this change are the system responsibilities to determine when an account is past due and take appropriate action. The narrower the focus of a potential change, the easier we will be able to accommodate the change. The scope of a change, with respect to a given model, refers to the pervasiveness of ramifications of the change throughout the artifacts developed in that model. We use the term ‘model’ to refer to the end product of any phase of the development life cycle, e.g, requirements model, analysis model, etc. We use the term artifacts to refer to the components of the model, e.g., objects, responsibilities, etc. Intuitively, one might think of the scope of a change as the number of objects or subsystems that will have to modify their behavior in order to accommodate the change. But the scope of a change also includes user documentation, project documentation, test cases, et cetera. 343 The degree of definition of a change refers to the extent to which we know the particulars of the potential change. In some cases, we know all the particulars or at least many of them, e.g., when it is necessary to extend an electronic CAD system to handle an already existing device technology such as CMOS. In other cases, such as legislative or regulatory changes, the most we can know in advance are the focus of the pending change, and perhaps the competing alternatives. The change does not become fully defined until the law has passed. For years, researchers and practitioners in software design have recognized that robustness to change is one of the hallmarks of a good design. Historically, however, the development of designs that are robust to change has been more a matter of art than science. Predictable and repeatable development of such designs requires two things: a means to capture and identify potential changes to a system, and the availability of constructs to support designs that effectively take potential change into account. Jacobson, almost alone among object-oriented methodologists, has pointed out the importance of addressing change in a systematic way [Jacobson86, Jacobson87, Jacobson911, but his focus has not been on the description of the changes. We propose the change case to capture potential change. The change case is expressed primarily as a use case [Jacobson87, Jacobson921 to describe potential functionality of the system. Change cases, like use cases, express functionality from the user’s point of view. A change case adds links to all relevant use cases that the change case will affect, if the change is ever implemented. That is, the change case links determine the scope of the change at the use case model level. The change case thus allows for the articulation of potential changes to system functionality and, further, directly relates a change to the current system functionality. scope, such as amending the business model to enable employees to telecommute and work from home. Thus, depending on the narrowness of its focus, a change may require amending one or many use cases, expressed as change cases which describe the intended, revised function. We advocate the use of change cases for objectoriented development methodologies that are based on use cases and traceability [Jacobson92]. Such a use case-driven, object-oriented development methodology supports traceability through the entire development life cycle. The links from change cases to use cases, coupled with traceability, explicitly allow the developers to consider the impact of a potential change and to evaluate alternative models according to their robustness to change. Definition: A change case consists of: (a) a use case, with a new or revised scenario, derived from a change to requirements, and (b) a set of existing use cases, that would need to be changed to be consistent with the changed requirements. We note that there are requirements beyond those that describe the functionality of the system as expressed in use cases, such as algorithmic specifications, performance requirements or constraints concerning the software deployment environment, Changes to such requirements are outside the scope of this paper. In the next section we present our definition of change cases along with an example. Section III briefly discusses use cases and traceability, the foundation for change cases. Section IV discusses measuring the impact of a change and the robustness of a design to a change. Section V describes the role of change cases during the phases of software development using an objectoriented methodology. We offer concluding remarks in Section VI. II - CHANGE Our description of change comprises the description of the change (intentional) and an associated set of change cases, each describing a potential, new or revised use case. Each change case, in turn, has a relationship to the use cases that would by affected by the change case. We thus provide traceability as advocated by Jacobson [Jacobson921 at two levels: from the change to representative change cases, and from each change case to the affected use cases (the Impact Links) These components and their relationships are shown in Figure 1. Y Change Case CASES AND AN EXAMPLE A change is a requirements-level expression of an intended revision. A change may be very specific, such as changing from 9.6 Kb modems to 28.8 Kb modems, or it may represent a simply stated intention to make a revision that will have broad 344 Figure 1. Change, Change Cases and Use Cases Specifically, a change case “isa” use case [Jacobson87, Jacobson921. As inherited from use cases, the behavior of a change case can be characterized by a sequence of interactions or dialogue between a user (or actor) and the system. Each change case’s scenario describes a single course of events in the actor/system interaction. A scenario can be described in English, as a dialogue or conversation [Rubin92, WirfsBrock941, or in other notations [Buhr96, Potts941. many subordinate use cases (e.g. based on the extends or uses abstractions [Jacobson92]). The scope of the change case at the use case level is determined from the number of use cases affected. We give an example, taken from the field of pension administration, of a change and a related change case. Our example deals specifically with the task of supporting the process that occurs when an employee retires and wishes to begin receiving a pension benefit. This example comes from concrete experience with a commercially available pension administration system [WatsonWyatt95]. A change case refines a use case by adding a relationship between the change case and the use cases that are affected by the change. A single change case may affect one or more of the use cases already captured. Usually, one would expect a change case to affect one user-visible use case and, in a refined use case model [Jacobson92], When an employee announces his or her intention to retire, a process is set in motion to compute a Jse Case 1. qame: Initiate Retirement Process lcenario: E: s: E: s: E: s: E: s: I’d like to retire. What is your name and social security number? I’m Joe Smith, SSN 222-33-4444. What will be your last day of work? July 31, 1996 What month do you wish to begin receiving your benefit? January, 1997 A preliminary estimate indicates you are entitled to the following (based on regulations in effect February 1, 1996): (a) life annuity with no payment to surviving spouse (b) life annuity with 50% to surviving spouse: (c) life annuity with 100% to surviving spouse: benefits 752.00 664.02 594.46 Please select the option you prefer. E: s: Option (c) [ records pending retirement on indicated date ] [ records election of option (c) ] [ logs suspended process for final calculation and issue trustee instructions Thank you very much. Cast of Characters: Figure E: employee 2. S: system Use Case Describing 345 the Retirement Process ] r Figure 3. Interaction Diagram for Retirment Processing pension benefit that will be paid to the employee. In most pension plans, the employee is allowed to select from several payment options. If the employee is married, for instance, he/she may typically select from options that pay a “survivor annuity” to his/her spouse in the event that the employee should die before the spouse. Depending on the option selected, the amount of the survivor annuity may be 50% or 100% of the original benetit amount. Needless to say, the higher the percentage for the survivor, the lower the amount of the initial annuity payment for the employee. Annuities of equivalent “actuarial present value” can be calculated using actuarial techniques that consider mortality and interest rates [Jordan67]. benefit payment calculation process is established to compute the exact final benefit and send instructions to the pension plan’s trustee to begin paying a benefit to the employee. This process is held in suspension until the day the employee actually retires. The calculation of an employee’s benefit in a defined benefit pension plan is usually a function of the employee’s final pay and length of service. The exact amount of this benefit cannot be known until the employee actually stops working. But, a preliminary estimate of the benefit must be computed, to enable the employee to select a payment option prior to the actual date of retirement. Once an option has been selected, a process. Figure 2 shows a use case corresponding to this requirement. To keep matters simple, we have cast the use case as a conversation between the system and the retiring employee. In practice, this conversation is typically between the system and a pension plan administrator, who carries out the dialogue via formal correspondence with the employee. The administrator uses the system to manage and track the employee’s retirement We show in Figure 3 a summary of a CRC analysis session for this use case, shown as an interaction diagram. Each vertical line represents an object (i.e., a card in CRC). Each directed arrow represents a collaboration from one object to another, with the return of control shown by a dotted, directed arrow in the reverse direction. 346 PCO: Plan Control Object responsibility: capture retirement date get employee data perform preliminary pension calculation determine elected form of benefit log benefit payment process Employee Interface Object responsibility. capture retirement date determine elected form of benefit EIO: EDB: Employee Database responsibility. retrieve employee historical CALC: PSS: Pension responsibility. perform pension 4. with: collaborates with: collaborates with. collaborates with: collaborates with: data Calculator calculation Pension Subsystem responsibility: log benefit payment process Figure collaborates EIO EDB CALC EIO PSS CRC Model for Retirement The vertical box on the line indicates the duration of the execution, within that object; time proceeds down the page. Finally, each collaboration line is labeled to indicate the responsibility that is being Processing invoked. This is at the analysis level in that we identify objects and responsibilities by name; there are no signatures, attributes, relationships, etc. Change R-l Description: Add support for court-issued qualified domestic relations orders (QDRO). When initiating pension payments on an employee’s plan, determine if a QDRO applies to this plan, and if so, determine the QDRO splits of benefits by interacting with the plan administrator. Do not begin actual payments until the QDRO split is certified by the plan administrator. This is an anticipated regulatory change. Traceability Links: Change Case 23: ... Figure Initiate Pension Payment 5. Change to support 347 with QDRO QDRO benefit splits much like Wirfs-Brock [Wirfs-Brock901, shows the resulting CRC model. Figure 4 One possible (and likely) change is a change in the regulations concerning the calculation of payment amounts. The associated change case would supersede the use case in Figure 2 and would indicate a new version of the regulations. To accommodate such a change, delegating the calculator responsibility to a separate object, as shown in Figure 3, would result in a very small scope (only one object in the analysis model needs Change Case 23. Vame: Initiate Retirement Process with QDRO scenario: E: s: E: s: E: s: E: s: I’d like to retire. What is your name and social security number? I’m Joe Smith, SSN 222-33-4444. What will be your last day of work? July 31, 1996 What month do you wish to begin receiving your benetit? January, 1997 [ determines that there is a QDRO for Joe Smith] Please excuse me. Because a qualified domestic relations order has been issued on your pension benefit, we will need some time to determine your exact benefit. S->P: P: What is the benefit split for Joe Smith? Joe Smith gets 50% of his accrued benefit. s: A preliminary estimate indicates you are entitled to the following benefits (based on regulations in effect February 1, 1996): 376.00 (a) life annuity with no payment to surviving spouse 332.01 (b) life annuity with 50% to surviving spouse: 297.23 (c) life annuity with 100% to surviving spouse: Please select the option you prefer. E: s: Option (c) [ records pending [ records election [ logs suspended [ logs suspended Thank you very Cast of Characters: retirement on indicated date ] of option (c) ] process for final calculation and issue trustee instructions process to determine benefit for QDRO payee ] much. E: employee S: system P: plan administrator impacted Use Cases: Use Case 1. Initiate Retirement Figure 6. Change Process Case Initiating 348 Retirement Process with a QDRO ] Figure 7. Interaction Diagram for Retirement with a QDRO to be changed). The analysis model of figure 4 is quite robust to this change. To demonstrate a more substantive change case, we now consider expanding the original system to handle qualified domestic relations orders, or QDRO’s. A QDRO is an order written by the court that entitles someone other than the employee to a stipulated portion of the employee’s pension benefit. Typically, QDRO’s are issued as part of a divorce settlement, and award a former spouse the fraction of the benefit to which they were entitled. Because courts may write QDRO’s in any number of ways, entering the amount of the QDRO benefit split often requires the intervention of a pension plan administrator. The administrator may consult the actual text of the QDRO, confer with lawyers and/or actuaries if necessary, determine an amount for the split benefit, and enter it into the system. The change to add QDRO processing to a pension system is shown in Figure 5. 349 Processing One of the change cases associated with this change is shown in Figure 6. Note that now two separate benefit payment processes must be initiated -- one for the employee, and one for the QDRO payee. Also note the introduction of a new participant, the plan administrator, in the change case. We note that, in practice, a scenario may not actually wait for the plan administrator to enter the QDRO amount, but we express it this way for simplicity. An interaction diagram for a CRC analysis session on this change case scenario is shown in Figure 7 and the resulting CRC model is shown in Figure 8. A QDRO “specialist” object (QCO) is introduced to handle issues related to the QDRO. This is a control object traceable to the change case. A new interface object (PIO) is introduced to handle communications with the plan administrator. There are new collaborations (from the QDRO control object) to existing objects. That is, the number of objects depending on certain responsibilities has increased, providing additional information about the assumptions or preconditions that those responsibilities should assume. In particular, the Employee DB must now PCO: Plan Control Object responsibility: capture retirement date get employee and QDRO data handle QDRO (if needed) perform pension calculation determine elected form of benefit log benefit payment process collaborates EIO EDB QCO CALC EIO PSS QC 0: QDRO Control Object responsibility. handle QDRO determine benefit split log benefit payment process EIO: HO: EDB: CALC: PSS: with. collaborates with: PI0 PSS Employee Interface Object responsibility. capture retirement date determine elected form of benefit collaborates with. collaborates with: Employee Database responsibility: get employee and QDRO data collaborates with: Pension responsibility: perform pension collaborates with: collaborates with. Plan Administrator Interface responsibility: determine benefit split Object Calculator calculation Pension Subsystem responsibility. log benefit payment process Figure 8. CRC Model for Retirement tell us whether a QDRO is in effect for this employee, the Calculator object must now work with the net amount available, and the Pension Subsystem is now called twice (for the QDRO recipient and the employee). The benefits of change case analysis are demonstrated by this example. By conducting this simplified analysis CRC session for the change case, we discover broader contexts for existing responsibilities. For example, without the change 350 Processing with QDRO’s case, the Pension Subsystem might have been written assuming that there was only one payment process per retiree. Or the calculation program might have been written expecting the entire employee benefit to be available during the computation (rather than the net amount, e.g., after the QDRO). Based on the change case, both the interface and the context for each (affected) responsibility in the current design can easily reflect the broader view of the system that includes the change case. If the interfaces and the contexts of existing responsibilities do effectively support the change case, then change case analysis has minimized the scope of the change at the analysis model. (I.e., no existing objects need to be changed, only the new control objects are in the scope of the change.) Note that the new objects associated with the change case, by themselves, do not affect the robustness of the design, Rather, they are simply added, designed, and implemented when the change The benefit from change is actually authorized. case analysis is consistent with common wisdom that getting the interfaces to existing objects “right” promotes the maintenance and evolution of the software system. Change case analysis allows the current design to reflect interfaces that can accommodate a future change. III - THE FOUNDATION FOR CHANGE CASES: USE CASES AND TRACEABILITY The use of change cases for analyzing and adapting to change is not in itself a methodology. Rather, it represents a technique that can be applied in the context of any methodology for object oriented design and development, as long as the methodology being used supports: (a) capture of use cases (b) capture and maintenance of traceability links between different phases of the methodology. In this section, we discuss the importance of these two capabilities as a foundation for the use of change cases. USE CASES A use case [Jacobson87, Jacobson92, Jacobson951 describes a single thread of interaction with the (proposed) system from the point of view of a user or other external actor (which may be a separate system). A use case-driven software development methodology, such as that advocated by Jacobson [Jacobson92], gathers all of the 351 requirements for user level system functionality in the form of use cases and drives the development of each model developed during the software life cycle by considering these use cases. A number of different formats have been proposed for expressing use cases [Buhr96, Rubin92, WirfsBrock941. These formats include: l a “conversation” between the user and the system 0 a transcript of alternating user and system actions 0 a flow chart or list of decision/action steps that are not assigned to either user or system. While we have found the conversation format simple and natural to use (see examples in Section II), our change case model does not depend on any specific format. All that is required of the format employed is that it be easy to identify which use case steps motivate specific artifacts in the analysis model (or design model, if the methodology does not support an analysis model). Change cases also carry the same benefits as use cases. They are expressed in user or domain terminology. They are understandable to the user because they express changes in the system according to how the user-visible functionality of the system will be changed. They can be easily validated by the user and they engage the user into thinking about possible system evolution. TRACEABILITY Effective use of the change case model also requires that the methodology support traceability from one design level to another. Simply put, traceability refers to the explicit recording, on paper or in a CASE tool, of links from artifacts at one level to related artifacts at subsequent levels in the methodology. For example: 0 each construct (e.g., analysis object) in the analysis model is linked back to the use case(s) that motivates the construct. each construct (e.g., block [Jacobson92]) in the design model is linked back to the analysis model construct from which it is derived. 0 each test in the test suite is linked back to the use case or other requirement it is intended to test. Traceability allows us to gauge the scope of a change with respect to any level of a system’s evolving design by following the traceability links forward from affected use cases to the level we are examining. Understanding the scope of a change on any level enables us to make judicious decisions about how to change the design at that level (see Section V). refinement one can assert that the next level of requirements (when met) will, as a set, satisfy the parent requirement, then the detailed requirements are complete; l Traceability is well known and widely practiced in software engineering and software requirements engineering [e.g., Nelson90, Potts94, Thayer90, Wymore79, Zave791. In software requirements engineering, traceability is sometimes referred to as requirements flowdown, and it is used to trace the refinement of general requirements into more concrete requirements. Traceability enables one to speak about the completeness and necessity of the final detailed requirements as follows: l COMPLETENESS: If each top-level requirement traces forward to detailed requirements, and if at each level of Use Cases Analysis Model l NECESSITY: If each final detailed requirement traces backward to a top level requirement, then it is necessary. If a requirement statement does not trace backward to a top level requirement, then it is spurious and/or out of scope, so designing and implementing to that statement is wasted work. (Or we have identified a missing top-level requirement.) In software engineering, traceability is also commonly used to relate test cases to requirements. A test case can be traced back to the requirements that provide the criteria against which the test case is performed. Within the Object-Oriented community, Jacobson advocates using traceability in object-oriented software engineering [Jacobson87, Jacobson921. It is a consistent theme in his work that development proceeds by seamlessly refining the models, with traceability from use cases (representing requirements) to each successive implementation Design Model Test Figure 9. Traceability in Object-Oriented 352 Software Development model (analysis, design, implementation and test models). Traceability enables one to determine which objects implement each use case, and to develop test cases against those objects that derive the test criteria from the use cases (see Figure 9). Traceability has the most value in a methodology when the links are bi-directional. Tracing the links “downstream” allows us to see the analysis and design level ramifications of a use case or change case, and to determine the scope of a change. Tracing the links “upstream” allows us to see why (in terms of the original requirements) a particular design decision was made. Even when a hypertext-like system is not available to support the navigation, links can be maintained in simple database tables and/or paper documents that refer to individually numbered sections (or pages, if appropriate) of the appropriate document versions. Impact( change C, use case level U) = use cases in U We can take this approach a step further by noting that any level in the system development process consists of a number of constructs. Typical constructs are shown in Table 1. If we have (as discussed in the previous section) traceability links between levels, we can determine the constructs affected by a given change at each level. The number of affected constructs, relative to the total number of constructs at that level, gives us a rough measure of the impact of the change at that level. Irnpact( change C, level L) = IV - MEASURING CHANGE ( use cases in U affected by C 1 1constructs in L affected by C 1 constructs in L THE IMPACT OF A As mentioned in Section II, the links from a change case to the affected use cases are an important part of the structure of an individual change case, since they determine the scope of the change at the use case level. We can get a rough estimate of the impact of the change at this level by measuring the percentage of use cases affected by the change. Although software designers can often recognize a good design for some particular purpose, determining objective criteria by which designs can be judged has been quite difficult. Some software metrics have been proposed [Henderson96, Lorenz941. Recent work on object-oriented development [Jacobson92, Gamma951 has focused on robustness to change as a critical criterion for evaluating designs. The concept of impact of a change, shown above, can be used to develop a rough measure of 353 robustness of a design to potential changes. Intuitively, we would like an absolute measure of the potential impact of a change. We would then be able to compare the potential impact against the actual impact, using the formula developed above. However, the potential impact may be a real world concept that does not submit to formalization in our model. robust with respect to some of the component changes, and D, more robust with respect to others. If the robustness of D, exceeds that of D2 for every component of C, then D, is clearly preferable with respect to the changes contemplated. Otherwise, it is a judgment call based on the relative likelihood and priority of each component change, Ci. Note that the existing use cases for a system are a fixed reference set, since revisions are made by adding change cases. Thus we can use the impact of a change at the use case level (i.e., the focus of the change) as an approximation of the potential impact of the change. Although this metric is useful for judging impact, we note that other considerations must be taken into account when evaluating a design. To measure the robustness of a downstream level to a particular change, we propose to measure the impact of that change at the (downstream) level, and compare it with the impact at the use case level, whether the downstream level be analysis, design, or implementation. Robustness = ( level L, change C ) 1 Impact( change C, use case level U) 1 1 Irnpact(change C, level L) 1 In general, this measure will vary between 0 and 1, although it can exceed 1. The higher the value, the more robust our design. If it exceeds 1, we have a very good design from the standpoint of change C, because it means that the impact of the change at this level has been reduced from the original focus. This measure, Robustness(L, C), measures robustness to only one change. In the overall evaluation of a design, of course, we would want to measure robustness against a set of changes, C,, Cl, . . . Ck, which can be viewed as components of a change vector C = < C,, C2, . . . Ck >. In comparing two designs, D, and DZ, against a change vector C, D, will most likely be more 354 V - CHANGE CASES IN A DESIGN METHODOLOGY So far, we’ve talked about how change cases can be employed in individual situations. In this section, we discuss the overall role of change cases in a full software development methodology. In particular, we discuss how the requirements, analysis, design and implementation phases can be affected by incorporating change cases into your methodology. The discussion of the requirements phase focuses on sources for discovering changes, and determining which change cases to elaborate. Discussion of phases after the requirements phase assumes that the change cases have been captured, and focuses on their use during the phase. REQUIREMENTS PHASE The requirements phase is typically where use cases are captured, so it is a relatively simple matter to capture change cases as well during this phase. Sources for information about potential change are also plentiful, including: l planned or scheduled changes to product / service offerings 0 user comments during JAD sessions 0 review of regulatory / legal environment l drafts of pending legislation / regulations l review of organization’s technology & platform strategy Candidate Change Analysis Budget Line L iII---chGle---& Use Cases Design Objects I Figure I -----; *------------I ----,-----T/-----T--.____, 1 Poten@xl Analysis Objects 1 ,_____-__-----_-__--_I ,_-_/_----_-__-______, ; -$o-t~n-t~~l l+jEn_ Fbjects ; ------ Analysis Objects Implemented 8 Objects 10. Change Analysis Budget for Robustness The difficult decision to make is to determine how many and which potential changes are important enough to warrant consideration during initial system design, since budgetary constraints usually preclude consideration of every possible change. In Figure 10, we show the required development artifacts on the left side and the “optional” development artifacts, associated with potential changes, on the right side. Assuming that a project might budget some resources for change analysis, we have drawn a dashed line to indicate the budgetary cutoff. The budget line is sloped to imply that a subset of the change cases should be considered, with some of the change cases reflected in the analysis model, and possibly a few of the changes reflected in the design model. We assume that none of the potential changes are to be implemented within the present scope of the project. of a potential change can The “importance” depend on many things, including its likelihood, scope and expected cost. In general, it requires a judgment call on the part of the design team to identify the most important changes while staying within budget. Any design effort, however, will benefit from analysis of some potential changes, because they provide a benchmark for evaluating the design that emerges in the later stages of the methodology. 355 Analysis Once the significant changes are identified, change cases can be captured using the same techniques and formats that the methodology employs for ordinary use cases. As we have discussed throughout this paper, it is important to establish the links between each change case and the existing use cases that would be affected by it. ANALYSIS PHASE Methodologies differ as to the deliverables expected from the analysis phase of a design methodology. Some expect a preliminary object model that is directly driven by the domain requirements and pre-figures the design phase object model, just as an entity-relationship diagram pre-figures a final data model. Analysis guidelines of such methodologies include rules like: 0 “Create a surrogate object for each system user.” 0 “Create a surrogate object for each object that occurs in the domain.” 0 “Create a specialist object for each use case.” 0 “Create a responsibility in the specialist object for each . . , “ We will prioritize or otherwise select change cases to be analyzed within the change analysis budget. Having selected a set of change cases, we develop the base analysis model, based on analysis of all the use cases, and then perform analysis of selected change cases. This produces a “changeextended analysis model”, that is, the base model transformed by the selected change cases. When performing change case analysis, we may observe common responsibilities between a change case object and a use case object, which would lead us to factor out a superclass providing the shared responsibilities. This is a good change to the analysis model, making it more robust to the related change. Traceability links should be exploited to keep track of the dependencies between the change cases and the components of the various analysis models, so that the reasons for such analysis decisions do not become lost. DESIGN PHASE Typically, the design phase focuses on refining the analysis model as the requirements and design constraints are more carefully considered. Often this results in factoring and/or reducing the analysis model to produce an object model suitable for code development in the implementation phase. A concern is that a design-level decision (e.g., factorization) may reverse an analysis-level decision made explicitly for robustness. Therefore, at the design level, attention should be paid to the scope of the analysis model constructs that are traceable back to change cases. The impact measures defined in Section V can be used to predict whether the design model with a particular factorization (reduction) is more robust to the analyzed changes than otherwise. Suppose D, is a design model for a given analysis model, and D2 is a design model, with some additional factorization (reduction) for the same analysis model. For a given change C, by comparing Impact(C, Design level) for designs D, and D2 , we can determine which design is preferable (more robust) with respect to change C. 356 IMPLEMENTATION PHASE The implementation phase usually focuses on realizing the design model in working code. Significant changes are considered a re-design rather than a separate refinement of the design model. While the analysis and design models may include the effects of potential changes, it is appropriate at the implementation phase to focus on what actually needs to be delivered for the upcoming system release. Traceability links identify objects and methods that owe their existence primarily to of these can potential changes. Implementation be deferred, stubbed, or replaced with simpler code derived from a restricted design model. As with all artifacts of the implementation model, traceability links should be created to identify the need to change these artifacts when the potential change becomes actual. LATER IDENTIFIED CHANGES Finally, consider a potential change, C, that is identified when the design, or even the implementation, is nearly complete. Change cases can be used to analyze the impact of C on the current models. Assuming that the impact analysis of change C is within the robustness analysis budget, for each phase of the development lifecycle, we select change cases (that trace from C) to analyze the robustness of the model at that level. The desirable outcome is that, after robustness analysis, the robustness of each model level (to this change) is acceptable. Otherwise, we could consider a redesign, at one or more levels of the model. We can use the impact measure, Impact(C, L), and the known cost of completed models to estimate the expected costs of making change C with or without doing immediate redesign for additional robustness. Depending on costs-benefit analysis, we may choose to backtrack and revise the existing work for increased robustness. VI - CONCLUSION REFERENCES In this paper, we have introduced the concept of a change case as a way to describe potential system functionality, and demonstrated how it can be used to capture potential changes and design systems that are robust to the changes identified. The importance of dealing with change early in the analysis process cannot be underestimated. By dealing with change early in the development process, it should be possible to both reduce future maintenance costs, and extend the system’s effective life span. Brooks87 F. Brooks, “No silver bullet -- essence and accidents of software engineering”, Computer 20,4, April, 1987, pp. 10-19. Buhr96 R. Buhr and R. Casselman, Use CASE Maps for Object-Oriented Systems, Prentice-Hall, 1996. Gamma95 E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. Henderson96 B. Henderson-Sellers, ObjectOriented Metrics: Measures of Complexity, Prentice-Hall, 1996. Jacobson86 I. Jacobson, “Language Support for Changeable Large Real Time Systems”, Proc. OOPSLA’86, pp. 377-384. Jacobson87 I. Jacobson, “Object Oriented Development in an Industrial Environment”, Proc. OOPSLA’87, pp. 183-191. Jacobson9 1 I. Jacobson and F. Lindstrom, “Reengineering of old systems to an objectoriented architecture”, Proc. OOPSLA’91, pp. 340-350. Jacobson92 I. Jacobson, M. Christerson, P. Jonsson and G. avergaard, Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press, 1992. Jacobson95 I. Jacobson, M. Ericsson and A. Jacobson, The Object Advantage: Business Process Reengineering with Object Technology, ACM Press, 1995. Jordan67 C. Jordan, Society of Actuaries, Textbook on Life Contingencies, Society of Actuaries, Chicago, 1967. Lorenz94 M. Lorenz and J. Kidd, ObjectOriented Software Metrics, Prentice-Hall, 1994. Nelson90 E. Nelson, “System Engineering and Requirement Allocation”, System and Software Requirements Engineering, R. Thayer and M. Dorfman, eds, IEEE Computer Society Press, 1990, pp. 60-76. We note that object-oriented programming provides constructs which can be effectively used to produce designs that are robust to change. The object construct itself supports the encapsulation of both data and its associated behavior, and provides a convenient means of isolating a small number of system components likely to be affected by some change. The message passing model, and the use of control objects and interface objects [Jacobson921 to serve as gatekeepers to accept all incoming messages for larger object subsystems, supports the isolation of larger subsystems if necessary. Finally, the polymorphism of most object languages provides a means of developing protocols to request and receive services, even when the exact nature of the responding object is poorly understood, or likely to change. Thus, we observe a symbiotic relationship between use cases, change cases and object orientation. Acknowledgment We thank Rebecca Wirfs-Brock for her insightful comments and assistance, which led to significant improvements in the final version of the paper. 357 C. Potts, K. Takahashi and A. Anton, “Inquiry-Based Requirements Analysis”, IEEE Software, 11,2, March 1994, pp. 2132. K. Rubin and A. Goldberg, “Object Rubin Behavior Analysis”, CACM, 35,9, September, 1992, pp. 48-62. Thayer90 R. Thayer and W. Royce, “Software System Engineering”, System and Software Requirements Engineering, R. Thayer and M. Dorfman, eds, IEEE Computer Society Press, 1990, pp. 77-116. HR Edge PENSIONS User’s WatsonWyatt Guide Version 2.0, Watson Wyatt Software, Lake Oswego, OR, 1995. R. Wirfs-Brock, B. Wilkerson Wirfs-Brock90 and L. Wiener, Designing Object-Oriented Software, Prentice-Hall, 1990. R. Wirfs-Brock, “The Art of Wirfs-Brock94 Designing Meaningful Conversations”, The Smalltalk Report, 3,5, 1994. A. Wymore, “Resolution of Wymore79 System Design”, Proc. COMPSAC’79, IEEE Computer Society, 1979, pp. 21 l122. P. Zave, “A Comprehensive Approach Zave79 to Requirements Problems”, Proc. COMPSAC’79, IEEE Computer Society, 1979, pp. 117-214. Potts94 358