Ectropic Design Tools Usage Scenarios This is a set of hypothetical usage scenarios for the proposed Ectropic Design Tools, involving a (fairly ambitious) hybridization of CRC Cards, Scenarios, Goals, and some UML diagrams. Actors: Humans: Software Designer [Student] Programmer [Student] Requirements Analyst [Professor] End User [TA] Tools: Ectropic Navigator including: CRC Card Editor Scenario Editor Goal Editor UML Class Diagram Editor UML Sequence Diagram Editor Code Development Tool Design Critics (These may be embedded in particular tools; however, a productive alternative may be to have an independent "critic agent" which lives outside all of the tools. The advantage of this approach is that it facilitates the use of the critics to observe flaws that exist in the combinations of results, e.g., detecting a mismatch between the Class diagram and the code.) --------------------------------------------------------------------- * Scenario #1.1: Starting a project This scenario illustrates the use of the tools during early design. It is intended to be a fairly simple, ordinary use. 1) The Professor assigns a project: A simple calculator program (like xcalc, but with fewer operations). The assignment includes a description of what buttons should be on the calculator and how they work. 2) The Student begins by noticing that the requirements suggest three obvious types of visual elements: a calculator window, the display at the top, and the buttons. The student uses the CRC Card Editor to create three CRC Cards: Calculator, Display, and Button. These classes are automatically made available to the Scenario editor (so they can be referred to in a Scenario by clicking / dragging / selecting from a menu / whatever. 3) These three classes are automatically placed into the UML Class diagram. At this point they are simply boxes; they have no structure or connections. 4) The Student decides on a scenario: the user types "1+2=" and the answer "3" is put up on the board. The Student enters in a Scenario to the Scenario Editor with 5 episodes: the 4 button presses and the answer appearing. Each button press involves the Button class (since that's what's being clicked on). Furthermore all of the button presses except for the "+" involve the Display changing. Since the Button clicks appear to be driving the action, the Button class is assigned as the one responsible for the events while the Display action is listed as supporting the action. The display of the answer is listed as the responsibility of the Display class. At this stage, each button click is represented as a separate responsibility for the Button class (e.g., first number, second number, etc.). 7) The CRC Cards are automatically updated to reflect the responsibilities and collaborations encoded in the elaborated scenario. 8) The steps of the scenario are automatically reflected in the UML Sequence Diagram Editor. 9) [Maybe] the UML Class Diagram is updated to reflect the fact that there is some unspecified relationship between Display and Button. I'm not certain whether UML can / should be used to represent preliminary, uncertain information of this sort. Point: There is a variety of information about classes and relationships between them encoded in the CRC Cards, the Class Diagram, and (to a lesser extent) the Scenarios and the data in the other tools. Much of this information is redundant; for example, the fact that Button and Display are connected to each other are represented in (at least) the CRC Cards, the UML Class Diagram, and a Scenario. To avoid being overwhelmingly cumbersome, the tools need to automatically transfer redundant information among tools (rather than require that it be entered separately in each step). --------------------------------------------------------------------- Scenario #1.2: Dividing scenario steps into substeps This scenario builds on the calculator program started in Scenario #1.1. It involves the use of design critics to suggest a modification. 1) Having completed the first draft of the first scenario, the Student asks the Design Critics to analyze the state of the system. The Design Critics assert that there is a problem: the Button click responsibility lists the Display as a collaborator for the click handling responsibility but the Display class has no corresponding responsibility for handling this request from the Button class. 2) The Student responds to the critique by dividing the steps in the Button click handling events into two other steps: the Button being activated and the Display being modified. This division is done within the Scenario editor. 3) The change is automatically reflected in the CRC Card Editor (i.e., that the new responsibilities for Display are being updated). The change is also automatically reflected in the UML Sequence Diagram Editor; no change is made to the UML Class Diagram since the precise details of the classes are still ambiguous. Point: Another vital characteristic of these tools is that they allow information which has already been entered to be modified. These modifications can be complex and require updates across tools which can potentially be even more challenging than propagating new information (since the tools have to figure out what old pieces of information across tools are invalidated by the change AND what new pieces are added). --------------------------------------------------------------------- Scenario #1.3: Merging responsibilities A moderately early scenario within the calculator design; it starts to get at the distinction between the Scenario Editor (which focuses on specific instances of use), the CRC Cards (which generalize the class relationships in the scenarios), and the Sequence Diagram Editor (which generalizes the process relationships in the scenarios). This scenario takes place after the student has entered several related calculator scenarios. 1) The Student (or perhaps a Design Critic) notices that some of the different responsibilities assigned to the Button class seem to be very similar in the sequence of events that they trigger; specifically, the entry of a number before the operator and the entry of a number after the operator both involve similar actions which both lead to the invocation of similar effects on the display class. This suggests that they may actually be instances of the same responsibility. 2) The Student merges the two responsibilities using the CRC Card editor. 3) The different steps in the Scenario are not merged (since they are still separate steps) but they are changed to indicate that they refer to the same responsibility. 4) The Sequence Diagram is updated to show that some of the steps in the process match. Point: This is another example of propagating changes. While #1.3 demonstrated dividing elements into pieces, this scenario illustrates merging elements. Both are important capabilities. --------------------------------------------------------------------- Scenario #1.4: Dividing a class into subclasses More calculator refinements; exploring the elaboration of the classes. This scenario takes place after a fair amount of scenario, CRC, and related information has been provided. 1) In reviewing the CRC Cards, the Student [or possibly a Design Critic] notices that one responsibility of the Button class (i.e., indicating a particular operation) is only relevant for some specific instances of the class (i.e., the operator buttons). 2) The Student decides that number buttons and operator buttons should be divided into separate subclasses. This indicated using the CRC Card Tool. This may be somewhat complicated; in particular, the responsibilities which have been assigned to Button need to be divided into three categories: ones which remain in the main Button class, ones which are restricted to the NumberButton subclass, and ones which are restricted to the OperatorButton subclass. 3) Also in the CRC Card tool, those classes which refer to Button as a collaborator may need to be updated. If collaborator references explicitly indicate what responsibility of the related class that they involve, then this process may be automated. Otherwise, the user will probably have to do this manually. 4) An update to the UML Class Diagram is done automatically; this seems fairly simple if the diagram is still just showing what classes exist; indicating class / subclass relationships is a major part of what UML Class Diagrams are for. If more information about class relationships is available at this point, updating the Class Diagram to indicate what aspects of those relationships translate down to the subtasks may require intervention from the user. 5) There should be relatively little change to the Scenarios and the UML Sequence Diagram; these elements still refer to / build on specific responsibilities, even if those responsibilities are moved to a subclass, the references to them should still be valid (they should require slight tweaking in how they are displayed, e.g., the class name listed in the sequence step needs to change). Point: Propagation of change can be increasingly challenging for very fundamental changes, such as changing the underlying class structure. Some of the propagation may only be semi-automated, i.e., a tool can determine that a change affects information in some other tool but cannot automatically decide what the effect should be. --------------------------------------------------------------------- Scenario #1.5: Beginning Coding Obviously, this scenario occurs fairly late in the calculator design process. The Scenarios, CRC Cards, and UML Diagrams are complete or nearly complete (but are still subject additional revisions). 1) The Student activates the Code Development Tool. That tool uses the UML Class diagram and CRC Cards to automatically generate preliminary code for the class definitions. 2) As much code as possible is automatically generated from other design information (how much can / should be generated here is an open issue). 3) The Student then elaborates those portions of the code which have been automatically generated and then starts building those portions which are not automatically generated. Point: Having the design tools do some preliminary coding provides the user with some concrete return on their time investment for having gone through all of the design steps. This is probably a particularly important point for a class project, since the student probably could have just started coding right away and probably not encountered any problems. --------------------------------------------------------------------- Scenario #1.6: Introducing an intermediate class This scenario takes place during coding (although a similar sort situation could have occured much earlier if the student had been thinking ahead). 1) In the process of writing code, the Student notices that, as currently structured, the calculator design requires that the Display class keep state other than the information which is currently being displayed; for example, it needs to recall the previously displayed number so that it can respond correctly to the pressing of the "=" key. This seems inconsistent with the student's intuitions regarding the nature of Display. 2) The student goes back to the CRC Card editor and produces a new card for a class called Memory which holds previous numerical values and is also responsible for doing the actual computation. [Side note: alternatively, this stuff could just be put into the Calculator class; I am assuming the student creates a new class here in that it illustrates my point.] 3) The student indicates that the processes which involved going from Button to Display now go from Button to Memory to Display. Such an indication may be given in the CRC Card Editor, the Scenario Editor, or the UML Sequence Diagram Editor [I'm not really sure how this should work; presumably this capability should be available in one or all of these tools and then the information provided should propagate to the others.] 4) [Maybe] the automatically generated code is modified to reflect these changes; of course, we want to be careful not to overwrite code which has been manually edited. This may not be as much of a problem if a versioning control system is available; even then, however, we do want to be careful to avoid automatically making unwanted changes. Even if a user can recover the old code, it's hardly desirable to force the user to do so. Point: The tools certainly need to allow the user to modify the system design even after programming has begun. --------------------------------------------------------------------- Scenario #1.7: Detecting an inconsistency with the design This scenario takes place even later in coding. 1) The student writes a method in the Memory class which involves querying the last button clicked to determine what its value is. This method is inconsistent with the CRC Cards, which says that NumberButton has Memory as a collaborator but not visa versa. 2) A Design Critic detects the inconsistency. [Note: it is probably inappropriate to have this sort of thing checked for continuously as the programmer is typing. Not only would that be computationally prohibitively expensive, it would also be potentially very annoying to be interrupted while coding. We may want the Design Critics to run all at once at one or more of the following points: when the program is saved, when it is compiled, when it is about to be submitted to an archive, when the user explicitly requests critique, etc.] 3) The Student is faced with three options: change the design, change the code, or allow the inconsistency to remain. [Note it is debatable whether we want to allow the last option at all. At the very least, we should have something in the various design editing tools which explicitly flags a piece of the design info as being apparently inconsistent with the code and allows (requires?) the user to place an annotation on the design explaining the inconsistency.] The first option involves editing the process of responding to a button click within the scenarios, etc. (as in Scenario #1.2). The second option presumably involves having the value of the button passed along to the Display when it is invoked (thus maintaining the flow of control which was specified in the design). The third option may be desirable if the Student feels that this access is sufficiently simple / trivial that it is "beneath" the level of the design and thus should be represented only in the code [again, I'm not sure it we want to allow that.] 4) If a change is made to the design, it is entered in one of the tools and is automatically (or semi-automatically) propagated to the others, as normal. Point: Using design critics to analyze inconsistencies between the stated design and the actual code seems particularly relevant to the goals of the Ectropic project. There are many varieties of inconsistencies which could potentially be observed. --------------------------------------------------------------------- Scenario #1.8: Adding goals. 1) The student goes through the responsibilities and creates corresponding goals. 2) The student observes that there is a higher level goal, adding numbers, implicit in the addition scenario 3) A new goal is created: "Add Numbers from User" 4) The user explicitly adds each of the goals for the responsibilities in the addition scenario to the "Add Numbers from User" goal (note, however, that this will not always involve adding _all_ of the responsibilities from a scenario; instead many more complex scenarios will involve multiple goals. 5) [Maybe] Tests are written for both the low level and hgh level goals and are attached to those goals. Point: It is expected that students will encode goal information very late in the process, probably mostly for documentation and/or testing purposes. Note that this is in contrast with the use of goals for larger-scale projects (e.g. Open Source) where we would hope that goals would play a larger and earlier role. --------------------------------------------------------------------- Scenario #2.1: Starting the addition a memory button to a calculator This scenario takes place after the original calculator project has been turned in. 1) The Professor assigns a new project, to revise the calculator project to add new buttons which store and retrieve a number in memory. 2) The Student adds new independent class called Memory. 3) A new CRC Card for this class is generated. [as in 1.1] 4) The Student adds a new sublass of Button for called MemoryButton. 5) The student has the option to move responsibilities from Button to MemoryButton [as in 1.4]. In this case, no responsibilities are moved because the MemoryButton is created to handle new functionality which hasn't been described yet. Point: Revising a design is a lot like refining a design. Many of the same actions are performed. The key difference (of course) is that we are going from one complete design to another rather than from an incomplete design to a less incomplete design. It seems like there may be substantial difference in the way Design Critics should handle these situations, however (so some explicit awareness of the distinction between refinement and revision may be useful). ---------------------------------------------------------------------