Scenario presentation tool

Details Scenario presentation tool Scenario presentation tool

1997-08-04

2001-03-20

Chaki, Kakali (Department: 2762)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C345S960000, C717S152000

Reexamination Certificate

active

06205575

ABSTRACT:

The early phases of software system design for a customer are generally performed by a team of analysts who depend on their abstraction and communication skills to perform the tasks of specifying the requirements of the proposed system and representing these requirements in textual descriptions and diagrams. Typically, such analysts will have to reach a consensus among themselves that their design approach will meet the requirements. Next, they must describe to the customer their proposed solution to the problem. Once agreement has been reached that the proposed design will satisfy the customer's needs, the proposed design must be communicated to a larger team with responsibility for the system implementation.
The task of generating and reviewing large software system design specifications can be an inefficient use of design time since the documents that are produced are often too complex to be readily comprehensible. The participants in a design review are typically expected to have read and thoroughly understood the specifications. In a typical working environment, such an expectation is usually unreasonable for large design specifications as most projects are limited by tight schedules. Many of the reviewers will not be able to allocate sufficient time to the review of large design specifications. Design reviewers often concentrate only on the areas of their particular interest, and they may fail to see the overall picture or design defects in other areas of the design.
In a typical prior art approach, software engineering staff in a research laboratory may be called in to support design reviews of a new product being developed by a company. Such a product may readily contain 150,000 to 200,000 (150 k to 200 k) lines of, for example, C code when implemented. The project design team may use a commercially available tool such as Cadre Teamwork to illustrate the dataflows for the design. Typically, a large stack of dataflow diagrams is then printed and inserted into design notebooks, and projector slides such as viewgraphs are made for the design review meetings. Such a stack of diagrams can become very thick and, in the interest of practical convenience, designers would accordingly generally present only important components of the design to the review teams. For example, an approach used for review meetings might be to define scenarios of important product functions, and then “walk through” the annotated dataflow diagrams to illustrate the sequential behavior of the design model. It is herein recognized that this approach has value both for designing and reviewing the designs of complex software systems. It also herein recognized that automated support for defining scenarios and “walking through” design documentation is desirable.
In order to build a software system, it is necessary to first describe the system requirements. The requirements are usually described in text that may be ambiguous and misleading. Analysis of the requirements results in a more precise system description that can be represented in many forms, such as dataflow diagrams, pseudo-code, sequence charts, and so on.
Thus, scenarios are useful early in the software design process for specifying what the designer wants the system to do. Scenarios are sequences of transition and activity which specify the desired system behavior. Their advantage is that valuable illustrations of the working system can be developed quickly. The dynamic behavior is often the most important aspect of a system being developed. However, many software development methods focus the designer's attention on the system structure or architecture. Since the structure is emphasized first, more effort is expended in this area and correspondingly less effort is put into the analysis of the dynamic behavior. It is important to view the design from three perspectives: structure, data, and behavior. The emphasis will vary by the nature of the system being designed, but it is important that all three be considered.
A more productive approach can involve the reviewing of a smaller set of key design diagrams accompanied by a set of important scenarios. The scenarios are used to “walk” through the design for review or “shake-out”. These scenarios can then become a useful form of documentation throughout the life of the project. Although a number of development organizations are currently defining scenarios, there is limited computer aided software engineering (CASE) tool support for these efforts. In addition, many development organizations could improve their designs by taking more advantage of scenarios in the early phases of system development.
Scenarios can be used for describing and communicating a system design for review purposes. Since people tend to describe how things work in terms of scenarios, it is useful to capture these scenarios and make them part of the software development methodology.
The scenarios focus attention on a particular behavior or function thread of the system and they provide an alternative to trying to imagine and mentally juggle the complex interactions of the entire system at once. CASE tools provide the capability to model a large problem by means of decomposition and abstraction. Scenarios are slices of the system behavior which can be considered one at a time in terms of the system model.
Scenarios have wide appeal because of the many benefits obtained over the life of a software development project for minimal investment. In the early stages of a project, scenarios have the ability to bring a design to life and illustrate what the designers have created. Verification that all the software system requirements have been covered is facilitated using scenarios. Software systems designs can become better documented, thereby relieving experienced design personnel from having to explain all of the details of a design to reviewers, coders, testers, maintainers, and customers as they become involved with a project in later stages of development and delivery.
The subject matter of the present application is closely related to that of the copending application entitled “METHOD FOR ANIMATING COMPOSITE BEHAVIOR OF SCENARIOS” being filed concurrently herewith in the name of the same inventors as the present application, now abandoned and whereof the disclosure is herein incorporated by reference.
The following are among the definitions herein adopted for purposes of clarity.
Scenario
A scenario is a sequence of steps. The scenario also has a title, description, and associated requirements. The description is typically a summary of what function thread is being illustrated along with some context setting information and possibly an initial state.
Step
Each step of a scenario comprises a source node, a directed flow, and a destination node. The flow conveys a message or a value from the source to the destination. A step may have a description and state change information associated with it. The state indicates the name of the system, subsystem, or object state following the completion of that step.
Node
On a dataflow diagram, a node is a process bubble, a terminal, a data store, a control element, or an offpage reference. Offpage references are connections to the parent level diagram. For object oriented system designs, nodes are the objects.
Flow
On a dataflow diagram, flows may be unidirectional or bidirectional. They may connect elements on the diagram together, or they may connect diagram elements to the parent level via offpage connectors. The flows may have names, and the data being transferred from source to destination are the messages. In an object oriented system, the flows are the relationships between classes. The messages being sent from the source object are method invocations on the destination object.
Animation
Animation is provided to illustrate the step-by-step nature of a scenario. The nodes and flows provide graphical techniques for depicting emitting a message, receiving a message, and transferring a message. Use of animation leads the user through the scenario, and eliminates translating betw

Affiliated with

Also associated with

Rating

Scenario presentation tool does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Scenario presentation tool, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Scenario presentation tool will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2457344