Develop a tool to support the ScenIC method.

ScenIC is a requirements determination method that has been developed for the MORALE project at Georgia Tech. MORALE is developing new techniques for evolutionary software development, including reverse engineering, architecture evaluation and requirements analysis methods. ScenIC is the MORALE requirements method.

ScenIC View is an interactive scenario editing tool for creating and editing ScenIC scenarios. It will be used in conjunction with several other ScenIC and MORALE tools with which it will be loosely coupled and on which it will not be dependent: ScenIC Ride, Scenify, Narrate, SCML Active Browser, SAAM Pad and Sirrene.

ScenIC Ride will extend ScenIC View by automatically attaching process-relevant issues to the episodic and semantic descriptions created by ScenIC View. ScenIC Ride will directly access the scenario repository created and maintained by ScenIC View.

Scenify is a natural-language processing tool that translates natural-language (English) input into the schematic ScenIC representation. Scenify will provide its input by generating SCML (Scenario Markup Language) documents that can be imported into ScenIC View.

Narrate is the reverse of Scenify: a tool that converts schematic representations of ScenIC scenarios into natural language narratives. Narrate will take SCML documents as its input.

SCML Active Browser is to SCML what a web browser is to HTML except that browsing a scenario is an active walkthrough process instead of a passive inspection of a structured document. The walkthrough may depend for its form and level of automation on directives provided by the user and on back-end simulation engines. SCML Active Browser may eventually share software components with ScenIC View, but initially it is being planned to accept SCML produced by ScenIC View, Scenify or manual input.

SAAM Pad is an architecture evaluation support tool that is used in facilitated group discussions. SAAM (Software Architecture Assessment Method) involves scenario walkthroughs at the architectural level. ScenIC View and SAAM Pad will interact through SCML files or an extension of SCML that includes ACME constructs.

Sirrene is a system for diagnosing problems in the execution trace of a system and for proposing modifications to the system. Sirrene is based on the TMK formalism of system purpose and behavior, and ScenIC has been defined with compatible semantics. We expect that later versions of ScenIC View will generate traces for Sirrene either in an extended Sirrene-targeted version of SCML or by means of a separate SCML-Sirrene filter tool.

ScenIC View will be used by software developers and engineers who are familiar with the ScenIC method as described in the ScenIC Guidebook.

ScenIC View will be used as part of the specification and requirements understanding process. Invoking ScenIC and opening relevant files and/or databases must therefore be a lightweight activity.

Scenario entry and editing

A scenario is a narrative that describes how a system will work. In ScenIC, scenarios contain actions performed by users and other entities in the system's environment and by software architecture components. All these doers of actions are referred to as actors.

ScenIC View shall let the user create and edit scenarios in one or more graphical and/or tabular views that present a concrete representation of the ScenIC scenario schema.

It will not be possible to create a scenario with an invalid structure as defined by the scenario schema.

The ScenIC scenario schema defines the constituent structure of a scenario in ScenIC. In ScenIC, a scenario is more than a sequence of actions and is explicitly related to the purpose of the system.

<scenario> ::= {<background>} <narrative>

<narrative> ::= <episode>+

<episode> ::= <episodePoint> <episodeBehavior> {<episodeOutcome>}

<episodePoint> ::= <normativePoint> {<exceptionalPoint>}

<normativePoint> ::= (<actor><goal>)+

<exceptionalPoint> ::= <obstacle>*

<episodeBehavior> ::= (<actor><action>)+

Create new scenario

The create new scenario feature will create an empty scenario template.

Add scenario constituent

The add scenario constituent feature will add a scenario element of a designated type (e.g. as chosen from a menu or picked from a palette) at a specified location of the scenario if such an addition would result in a validly structured scenario.

Edit scenario constituent

The edit scenario constituent feature shall let the user edit the value of an existing scenario constituent.

Prompted constituent values

Existing constituent values shall be available (e.g. via a pop-up menu or list box) when the user adds a new constituent or edits an existing constituent. For example, if the system's scenarios already contain references to the actors 'Instructor' and 'Presentation subsystem', those actors will be available for picking whenever a subsequent constituent is added.

Default constituent values

Default constituent values will be added to a scenario to reduce the amount of unnecessary editing by the user. For example, the outcome of an episode will be given as its default value the combination of the the normative points (goals) of the episode unless the user specifies an obstacle, in which case the outcome will be empty.

Scenario interface format

The export feature shall store a single scenario in SCML-1 (Scenario Modeling Language 1), a plain text format for storing ScenIC scenarios.

The export feature shall save the SCML-1 representation of the scenario in a designated file. Normal file-save features (e.g. confirmation if an existing file would be overwritten, directory navigation, etc.) will be provided.

The import feature shall read a single scenario in SCML-1 format to enable the user to edit the scenario. Normal file-load features (e.g. directory navigation) will be provided.

SCML-1 has yet to be fully defined. It will be an XML/SGML DTD.

Example: Think of SCML-1 as resembling HTML with '<', '</', and '>' as the special symbols and the capitalized names of the non-terminal components from the ScenIC schema as the tags. For example, the loading of a presentation into a Classroom-2000-like system might take the form of the following two SCML-1 fragments, one showing a successful sequence of actions, the other showing the occurrence of an obstacle:

<EPISODE loading presentation>

<POINT>

<ACTOR Instructor> <GOAL Presentation subsystem received slides>

</POINT>

<ACTOR Instructor> <ACTION Load slides into presentation subystem>

<ACTOR presentation subsystem> <ACTION present view of first slide in presentation>

<OUTCOME Presentation subsystem received slides>

</EPISODE>

<EPISODE failure to load unreadable presentation>

<POINT>

<ACTOR Instructor> <GOAL Presentation subsystem received slides>

<OBSTACLE Unreadable slides>

</POINT>

<ACTOR Instructor> <ACTION Load slides into presentation subystem>

<OUTCOME Presentation subsystem did not receive slides>

</EPISODE>.

Scenario storage and retrieval

A system's scenarios will be stored in a persistent form (e.g. a relational DB) between sessions of use.

An acceptable storage and retrieval mechanism for scenarios in early versions of ScenIC View would to use the import/export features with SCML. In that case, ScenIC View should provide an explicit save feature that saves the scenario

Semantic constituents

The scenario schema defines the structure of scenarios in ScenIC. Semantic constituents may occur in specific places in scenarios, but they may also be referred to in generalized specification documents (e.g. "whenever the Instructor loads a presentation, the slides in the presentation shall be displayed in sequence...") which are not themselves scenarios.

The semantic components are as follows:

Goals, which have the subclasses Objectives and Tasks

Actors, which have the subclasses Environmental Entity and Architecture Component

Obstacles.

Semantic components have a name and a free-text definition.

Later versions of ScenIC View will support more structured semantic components (e.g. tasks that contain a discriminating field according to whether they cause an information transmission or a physical change in the world).

Semantic constituent creation

The create semantic constituent feature creates a semantic constituent of the specified type as long as its name is new.

Users invoke the create semantic constituent feature as a standard editing operation.

Semantic constituent editing

The edit semantic constituent feature lets the user edit the attributes or associations of a semantic constituent as long as its name remains unique and the attributes and associations are given valid values according to the semantic schema.

ScenIC View will not let the user assign an invalid value to an attribute or association of a semantic constituent.

Users invoke the edit semantic constituent feature as a standard editing operation.

Semantic constituent deletion

The delete semantic constituent feature deletes a specified semantic constituent and any associations between that constituent and others.

Users invoke the delete semantic constituent feature as a standard editing operation.

Associate semantic constituents

The associate semantic constituents feature lets the user associate one semantic constituent to another with a specified type of association link.

Users invoke the associate semantic constituents feature from standard editing operations that are presented in ScenIC terms. (For example, assigning or attributing an action to an actor is an example of associating two semantic constituents: an actor and an action.)

The semantic schema defines the following binary associations:

Actor - responsible for -> Goal

Actor - performs -> Task

(if the Goal is a task, performs=responsible-for)

Obstacle - blocks -> Goal

Task - defends against -> Obstacle

Task - mitigates -> Obstacle

Export and import

The semantic constituents of a system can be saved in a plain-text format. Normal file saving features will be supported (e.g. confirmation prior to overwriting a file, directory navigation, etc.)

The plain text format representation of a system can be imported into ScenIC View to create a new system description. Normal file opening features will be supported (e.g. directory navigation, etc.)

The plain text format for importing and exporting is analogous to SCML-0 but is not yet defined. (It may also provide an interchange formate between ScenIC View and Sirrene.)

Storage and retrieval of semantic constituents

The semantic constituents of a system and the associations among them will be stored in a persistent form (e.g. a relational DB) between sessions of use.

For early versions of ScenIC View, an acceptable mechanism for providing storage and retrieval of semantic constituents would be to use the import/export mechanism. In that case, an explicit save feature should be provided that overwrites the most recently imported file with the current semantic constituents.

Annotation

The user can attach annotations to any high-level scenario constituent or any semantic constituent.

A high-level scenario constituent is one of the following: Scenario, Background, Episode.

Annotations have a type.

Some annotation types are built in to ScenIC View. These are issue annotations, action annotations, and comments.

An issue annotation is a free-text comment that is attached to a constituent to remind the user to address some design concern. It is usually phrased in the form of a question.

Future versions of ScenIC View will incorporate ScenIC Ride, which will create annotations automatically, depending on the state of the corpus of scenarios and semantic constituents and on process directives provided by the user.

An action annotation is a free-text comment that is attached to an issue annotation or to a constituent to remind the user to make a change to some semantic or scenario constituents.

A comment is a free-text comment that is attached to any constituent or annotation for any purpose helpful to the user.

Users may label comments with user-defined type names. These are ignored by ScenIC View, but are apparent in how the annotations are displayed to the user. Future versions of ScenIC View may support filtering or other information management and reporting functions that use user-defined annotation types.

Annotate

The annotate feature attaches an annotation of the specified type to an appropriate scenario contituent, semantic constituent, or annotation.

Only annotations that follow the attachment constraints defined above will be possible.

Edit annotation

An annotation may be edited at any time.

Delete annotation

The delete annotation feature deletes the specified annotation, any link with other annotations or constituents, and also deletes attached annotations that are not otherwise attached to a constituent.

Example: An issue annotation is attached to an episode. It is subsequently annotated with an action annotation. When the action is acted on (or reconsidered) and the user deletes the issue annotation, the link to the original episode is also deleted, as are the link from the issue annotation to the action annotation and the action annotation itself.

Resolve issue

The resolve issue feature marks an issue annotation as resolved.

The user may toggle a switch that makes it impossible to mark as resolved any issue annotation that has no action annotations attached to it. (This would be like marking an issue as resolved even though the designers have not decided what to do about it. It would be better in this situation just to delete the issue.)

Future versions of ScenIC View that incorporate ScenIC Ride may automatically mark certain automatically-added issue annotations as resolved when action annotations that represent predefined resolution mechanisms are selected.

Commit action

The commit action feature marks an action annotation as having been committed to.

Actions that are not committed to are referred to as being tentative.

The user may toggle a switch that automatically marks as resolved any issue annotation that an action annotation is attached to when the action is committed to.

Future versions of ScenIC View that incorporate ScenIC Ride may automatically mark certain automaticall-added action annotations as committed to when other relevant action annotations are selected or committed to.

Report open issues

The report open issues feature prepares a list of issue annotations that have been created and not yet deleted or marked as resolved.

Report tentative actions

The report tentative actions feature prepares a list of action annotations that have been created and not yet deleted or marked as committed.

Report committed actions

The report committed actions feature prepares a list of action annotations that have been marked as committed to.

Context-bound reports

Future versions of ScenIC View may support context-bound reports, such as reporting open issues created by a certain user or within specified date ranges.

Future versions of ScenIC View that incorporate ScenIC Ride will distinguish in reports between those annotations that were created or marked as resolved or committed to manually by a user or automatically by ScenIC Ride.

Storage and retrieval of annotations

Annotations are stored persistently between editing sessions without any explicit user intervention.

Annotations are not exported in SCML or the semantic constituent plain-text format.

[Note that the separate, stop-gap use of both these formats for persistent storage in early versions of ScenIC View, if adopted, should allow for annotations to be embedded in the formats and stored between sessions. It is not the purpose of the plain-text formats to store annotations, however, and such storage features should be disabled whenever the plain-text formats are used as a true export feature (e.g. to other ScenIC or MORALE tools) and should be removed from ScenIC View as soon as true persistent storage features are provided.]