Blueprints for Software Development

Simventions, Inc. 1

Use Cases: Blueprints for Software Development

Lawrence M. Root Paul L. Gustavson SimVentions, Inc.

3330 Bourbon Street, Suite 129 Fredericksburg, Va. 22408

[email protected], [email protected]

Abstract:

One of the key elements needed by all phases of successful well-executed software development are requirements. Requirements support software design and development, provides the basis for testing and accrediting, and can be used as the assessment criteria in validating the performance and data produced by a software program. An efficient and effective mechanism useful for capturing and tracking requirements is vital and necessary to support and encourage healthy software development activities. The concept of Use Cases provides a way for software engineers to capture requirements and to track those requirements through multiple stages of development. This session explores Use Cases and identifies a Use Case template mechanism for capturing requirements in an easy-to-read, easy-to-track text format. This paper includes an examination and exploration of how a collection of Use Cases provides a blueprint used to:

1. Capture sponsor requirements and objective 2. Support scenario development and conceptual analysis 3. Facilitate meta-data matching (reuse), and incremental, component-based software development 4. Identify critical test points, and provide the basis for test and VV&A plans 5. Evaluate the success of a software program

The Use Case template that will be described within this session is based on the highly regarded work of Alistair Cockburn. Mr. Cockburn's Use Case template, hereon referred to as Cockburn's Template, is considered to provide an easy-to-read and easy-to-track Use Case requirements mechanism. Cockburn's Template is ideal for software development activities and provides a method for:

1. Representing goals, requirements and objectives (such as a task or interaction between an actor and the system)

2. Recording a set of scenarios that tracks actor actions from a trigger event to the goal

As a means to demonstrate the process and effectiveness of capturing and tracking use cases, Cockburn's Template will be used to establish a Blueprint that captures sponsor objectives, identify scenario elements, and facilitate requirements traceability and component-based design of software projects. Specifically, this process can be used to not only illustrate Cockburn's Template concept, but also the UML Use Case diagramming technique.

Simventions, Inc. 2

Table of Contents: 1.0 Introduction

1.1 What are Use Cases?

1.2 Life-Cycle Process Framework

2.0 Building Use Case Blueprints

2.1 Cockburn's Template

2.2 Applying Cockburn's Template to UML

3.0 Blueprint Centric Process

3.1 Defining Objectives

3.2 Development of a Conceptual Model

3.3 Design and Development

3.4 Integrate and Test

3.5 Exercise and Analyze Execution Results

3.6 LEPO's Blueprint Centric Process - Summarized

4.0 Summary

5.0 Works Cited

Simventions, Inc. 3

1.0 Introduction

The world of software development has many processes that have been used and defined over the years for describing the activities involved in a software development effort. These include the “waterfall,” the “spiral” and “RAD” processes, as well as many others. All of these are highly regarded among the software development community for providing the necessary framework for the life-cycle engineering of a software program. Most of these processes also identify functional requirements, such as sponsor needs and objectives, as critical aspects to successful software development. Functional requirements are a key element needed within every phase of software development. For example, functional requirements can be specifically used to support the following life-cycle engineering activities:

• Establishing and Conveying Requirements • Generating a Conceptual Model • Designing and Implementing Software • Identifying Roles and Responsibilities • Providing the Basis for Testing and Accreditation • Validating Software Execution Performance

An efficient and effective mechanism useful for capturing and tracking requirements is crucial in supporting and encouraging life-cycle engineering activities. One object-oriented technique used for capturing requirements is through Use-Case definitions. The concept of Use Cases, not only provides a technique for software engineers to capture requirements, but to also track those requirements through the multiple stages of the software development process.

1.1 What are Use Cases?

By definition, a Use Case represents a goal or 'case of use' for a software program or system. A Use Case identifies a typical interaction that an actor has with the software program/system in order to achieve a desired goal [1]. By examining the goals a software system is intended to support, solid functional requirements can be identified and used at various stages of development. This is the underlying concept of the Use Case methodology.

A supporting term used in this definition of a Use Case is actor. An actor is anything that acts on the system that has behavior. Depending upon the scope and level of the Use Case, an actor may represent an actual user or another system external to the one being developed. In general, actors are external entities (i.e., one or more users or other software program(s)) that interact with the software program system being developed to achieve a desired goal.

A complete Use Case identifies goals, actors, and scenarios which detail the sequence of steps and events that must be performed to accomplish the stated goal. The complete collection of Use Cases identified for a software engineering effort generates a Blueprint that can be used to support and encourage a full range of software development activities.

This paper examines a "Use Case Blueprint Centric Approach" for software development, testing and analysis, and later examines mechanisms used for documenting and tracking Use Cases.

Simventions, Inc. 4

1.2 Life-Cycle Process Framework

In order to fully understand the benefit of Use Cases and how it can be used to support successful software development, it's important to first identify and agree upon a general framework for life-cycle software development. This framework must be high level and flexible allowing the overlay of a more detailed process such as a Waterfall, Spiral, FEDEP [2], or RAD process model by boiling down the key elements and aspects from each of these comprehensive models, a generic framework for life-cycle development can be formulated that consists of five basic phases and multiple channels for potential feedback. We've identified this process as the Lifecycle Engineering Process Outline (LEPO) (see Figure 1.0).

Figure 1.0 - Lifecycle Engineering Process Outline (LEPO)

LEPO identifies five major elements required for most lifecycle development projects.

1. Identify Objectives, 2. Define Conceptual Model, 3. Design and Develop Software, 4. Integrate and Test, 5. Execute and Analyze.

Specific processes and techniques may be applied to accomplish any of these five key elements, however the utilization of Use Cases is highly recommended as a technique to be applied to the first two steps. The collection of use cases gathered and formulated in Steps 1 and 2, respectively, compose a Blueprint that can serve as a guide for the remainder of the software development effort. It also provides meta-data useful for the maintenance and up-keep of a software development product. Therefore, it's important to consider this Blueprint as the center-

Simventions, Inc. 5

piece in software development (see Figure 1.1). The remainder of this paper seizes upon this principle, and focuses upon a Blueprint Centric Approach for software development, testing and analysis, and later examines mechanisms and techniques used for documenting and tracking Use Cases.

Figure 1.1 - Blueprint Centric Process

2.0 Building Use Case Blueprints Before diving into how Use Cases can be applied to support the activities described by a software development process such as the one defined by the LEPO model, it's important to understand the mechanism for capturing a requirement and providing the basis for a conceptual model. This section examines a template for documenting Use Cases that achieves these objectives. We'll also explore how Use Cases captured by the template mechanism can be reflected using the Unified Modeling Language (UML).

2.1 Cockburn's Template

Many assume that UML provides the best mechanism to document a Use Case. While the UML places strong emphasis on Use Cases and provides a standard diagramming method for representing a Use Case, as illustrated in Figure 2.1, the UML diagramming technique is not necessarily helpful in allowing us to apply and track requirements across the entire software development process. For instance, a UML diagram is not directly supportive of testing and software validation. In order to maximize the use of Use Cases at the various activities described by the LEPO model, it is important to have a Use Case document mechanism useful for sharing, linking, and tracking across all phases of the lifecyle engineering process.

Simventions, Inc. 6

Figure 2.1 - UML Use Case Diagram

Fortunately, a standardized (de facto) Use Case template has been developed that identifies the important aspects of functional requirements, and is very effective in supporting requirements traceability. The Use Case template proposed within this paper was developed by Alistair Cockburn [3] [4] and is highly regarded in the software development community -- including Ivar Jacabson who fathered the Use Case concept in 80's and is one of the principal founders of the UML. Mr. Cockburn’s template, hereon referred to as Cockburn’s Template, provides an “easy-to-read” and “easy-to-track” Use Case requirements mechanism that complements the UML.

Cockburn’s Template provides a method for:

1. Representing goals, requirements and objectives (such as a task/interaction between an actor and the program), and

2. Recording a set of scenarios that tracks actor actions from a trigger event to the goal (success conditions) and failures.

Table 2.1 - Cockburn’s Use Case Template Use Case Title <goal as a short active verb phrase>

Goal in Context <a longer statement of the goal in context if needed>

Scope <what aspect of software can be considered the black box under design>

Level <one of : Summary, Primary Task, Sub-function>

Preconditions <what we expect is already the state of the world>

End Conditions <the state of the world upon successful/failed completion>

Primary, Secondary Actors

<a role name or description for the primary actor>. <other actors relied upon to accomplish use case>

Simventions, Inc. 7

Trigger <the action upon the software that starts the use case>

Scenario

Main Step Action

1 <steps of the scenario from trigger to goal delivery, and any cleanup after>

2 <...>

3 <...>

Extensions Step Branching Action

1a <condition causing branching> : <action or name of sub use case>

Variations Step Branching Action

1 <list of variations>

Cockburn’s template is illustrated in Table 3.1. Let us examine the template in greater detail.

The Use Case is identified by a Title that reflects the goal in a short active verb phrase. The title and an associated unique ID (that can be hidden from the user) provides a reference key useful for tracking requirement goals during multiple stages of software development. The Use Case is further described within the Goal in Context.

The Scope, Level, and Trigger provide additional components identifying the Use Case goal. Scope reflects the boundary or breadth of the software element represented by the Use Case. For example, scope might identify a specific system component or key activity required for a community (or sub-community) of users. The Level indicates the condition of the goal specifically identified as either a Summary goal, Primary Task goal, or a Sub-Function goal (see Table 2.3).

In addition to capturing the core system goal, Cockburn’s Template provides the capability to identify pre and post conditions. The Precondition identifies the required state of the system for the Use Case activity to take place. The Trigger identifies one or more actions that initiates the Use Case scenario within the system. Once the Use Case scenario has been played out, two possible outcomes may result; either the goal was successfully accomplished or it failed. The End Condition describes the state of the program when the goal was satisfied and should also include the state of the program when the goal was either abandoned or completed unsuccessfully (failed).

Actors are required to either provide or achieve the goal of the Use Case. Each Use Case may have two types of actors: primary actor(s) and secondary actor(s). A Primary actor uses the system to achieve a goal. Use Cases are incomplete without a primary actor. A typical Use Case will have only one primary actor, however it is possible to identify multiple primary actors if multiple coordinated actors use the program in conjunction to achieve a goal. A Secondary actor

Simventions, Inc. 8

may be required by the program to assist the primary actor’s goal. Primary actors and secondary actors are responsible to carry out specific actions required in reaching the goal. Once a Use Case scenario is initiated it will typically follow a set of steps necessary to realize the goal. The Scenario describes the steps from trigger to goal delivery and is identified by three parts: the Main, Extensions, and Variations.

The scenario Main description identifies the main success scenario in a sequential and abstract step oriented manner. Each step is uniquely numbered so that it can be referenced within the scenario Extension and Variation sections. The Extension section indicates recovery cases of a step.

This provides a brief description of Cockburn’s Template labels, but to fully understand this template and the concept of a Use Case Scenario it’s helpful to provide an example. Table 2.2 illustrates an example of a Use Case describing an Air-to-Air Engagement for a flight simulation game.

Table 2.2 - Air-to-Air Engagement Use Case Use Case Title Air-To-Air Engagement

Goal in Context Perform Air-To-Air Engagements on Hostile Tracks over protected Air Space

Scope Defense of “No Fly Zone”

Level Primary Task

Preconditions Air Threat, “No Fly Zone” Region

End Conditions Air Threat Destroyed (s), Air Threat Departed (s), Air Threat Remains (f)

Primary Actors Air Threat, Air Defense AAM, Interceptor

Secondary Actors AWACS, Ground Controller

Trigger Air Threat Entered “No Fly Zone”

Scenario

Main Step Action

1 Air Threat Enters “No Fly Zone”

2 Vector Interceptors To Air Threat

3 Lock on Target

4 Fire Missile(see “Munition Fire” use case)

5 Assess Damage

Extensions Step Branching Action

3a Enemy Fire (see “Evasive

Simventions, Inc. 9

Maneuvers” use case)

Variations Step Branching Action

2 Air Threat Leaves “No Fly Zone”

As shown in the example, scenarios are comprised of a series of steps. These steps contain the primary (or main) execution plan for the participating actors and may include “extensions” or “variations” of the execution plan.

An extension is a condition causing branching and may reference an additional Use Case required to perform this type of exception. For example in our Air-to-Air Engagement Use Case the third step in the Scenario is for our computer controlled Air Defense interceptor to “lock on target”, however what if the threat turns and begins to fire on the computer controlled interceptor. This is identified as an extension or exception within the Air-to-Air Engagement execution plan (see extension step 3a), and it must be handled differently before resuming the execution plan. In this case, our interceptor has a requirement to perform “Evasive Maneuvers” described by another Use Case upon enemy fire.

A variation represents circumstantial change in the execution plan, but does not cause an exception. For example, in our Air-to-Air Engagement Use Case, the second step in the Scenario is to “Vector Interceptors to Air Threat.” However, what if the Air Threat departs the ‘No Fly Zone’ when the Interceptor is vectored to the region. This is considered a Variation as opposed to an exception. In this case the primary goal to “protect air space” was accomplished by the exodus of the air threat albeit earlier than expected. Variations allow abstract Use Case scenario steps to be rapidly defined by providing a mechanism for further amplification of the various elements that might be used to support and/or satisfy the step.

Therefore, Scenario steps are in essence sub-goals and can often reflect other Use Cases (via a main step or an extension to a main step). Therefore, Use Case nesting is a natural behavior when defining a collection of Use Cases. The collection of Use Cases forms a blueprint made up of a hierarchy of requirements, described in Table 2.3, identifying three distinct levels of goals: Summary Goals, Primary Task Goals, and Sub Function Goals.

Table 2.3 - Use Case Levels Type Description Example

Summary Use Case Collection of user (sponsor) level goals. Includes mix of high level Summary Use Cases may encapsulate multiple lower Summary Use Cases.

Sponsor Needs, Objectives

Primary Task Use Case

Represents an Primary Task /

“Air to Air Engagement”, or “Arial Bomb Attack on

Simventions, Inc. 10

Interaction to be performed

Surface Targets”

Sub Function Use Case

A scenario step and granule execution detail of the software. Drawn from Scenario Steps of the Primary Task Use Case

“Fire missile”, or “Illuminate incoming threat”

In addition to the Use Case template, Alistair Cockburn also developed a related ‘meta-data’ template, which makes provisions for additional characteristic data that reflects related meta-data information. The meta-data includes the identification of a Use Case or Priority, Open Issues regarding the Use Case, a link to any Superordinate or Subordinate Use Cases (for sub-level linking), data regarding the Revision History, and allows for additional Comment Information to be included as illustrated in Table 2.4.

Table 2.4 - Related Meta-Data Template (Use Case) RELATED INFORMATION

<Use case name/#>

Priority <how critical to the program>

Open Issues <list of issues awaiting decision affecting this Use Case>

Superordinates <name of any Use Case(s) that reference this one>

Subordinates <links to any sub Use Cases>

Revision History <document the revision history of the Use Case>

Comment Information <additional meta data>

2.2 Applying Cockburn's Template to the UML

Cockburn's template focuses on capturing requirements in an easily understood, natural language text that is mutually shared between the project sponsor, developers, and users of the system. One way to provide a visualization of a documented Use Case is to use a UML Use Case Diagram. Table 2.4 identifies the graphical notions used in UML.


Table 2.5 - Use Case Terminology and Symbols

Actors are any external entities or interfaces that interact with the system such as users and other systems. Actors have goals that they wish to accomplish using the system. Actors interact with the system to achieve the desired goal identified by the use case. Actors may be primary or secondary. Primary actors are the main 'customer' for the system, whereas secondary actors are often relied upon to accomplish the desired goal.

Use cases describe a particular behavior of the system in a given context. Use cases typically have a specific goal, and may have one or more scenarios describing a sequence of steps to be performed to meet the use case goal.

Other use case terms used within this document include the following:

Scope- Describes the aspect (extent) of the project considered under design.

Level- Indicates the goal level of the requirement. The three basic levels are: Summary, Primary Task, and Sub Task. Summary level is often abstract and at the hightest (very little detail), Primary Task level is User goals and provide a bit more detail. Sub-Task level is extremely detailed goals.

Preconditions- Describes the expected state of the world prior to the start of the use case.

Postconditions-

Describes the expected state of the world upon completion of the use case. Both success (s) and failure (f) conditions may be identified.

Triggers describe the event that causes or initiates the application of the use case. The trigger may precede the first scenario step of the use case, or it may often be equivalent to the first step of the use case.

A use case scenario describes the general sequence of events or actions that must take place to reach delivery of the use case goal. The scenario consists of a series of steps thatidentify an action or event including any actors required to perform an element of the goal defined by the use case.

An exception is an extension that identifies a condition within an step that causes branching (detour) and identifies either an additional use case or an inline action to deal with the branching condition.

A variation is an extension that identifies different attributes or different ways to perform the actions of a step. An additional use case may be identified that directly deals with the specific varation.


Let's go back to the Air-to-Air Engagement Use Case and see how it might look using UML diagramming (see Figure 2.2).

Figure 2.2 - Air-To-Air Enagement Use Case

Despite the "cartoonish" appearance, the benefit of UML is that it provides a way to visually present this Use Cases with project sponsors, domain experts, developers, users and testers. Keep in mind though, that Use Case diagrams alone are not sufficient in allowing us to track requirements across the entire software development process.


3.0 Blueprint Centric Process Let's now take a look again at the LEPO process model introduced in the beginning. As stated earlier, Use Cases are used to identify and capture the functional requirements of the system. The collection of these Use Cases documented using Cockburn's template forms a blueprint that can be used during the remainder of the life-cycle development process (see Figure 3.0). A Use Case Blueprint encourages communication and involvement among sponsors, engineers, testers, and analysts through each software process activity .

Figure 3.0 - Blueprint Centric Process

Like an architectural blueprint for a house or building, a Use Case Blueprint provides a common reference for the development, maintenance, testing and analysis of a software program. The Use Case Blueprint ensures that the software engineering purpose is understood, and encourages the active participation and communication collaboration among Sponsors (e.g , Publishers), Engineers, Graphics Artists, Testers, and Analysts throughout the development effort.

Figure 3.0 illustrates the key steps identified by the LEPO model, which, again, reflects the summary activities defined by most software development processes. For the purpose of this paper, this diagram will be used to convey the effectiveness of Use Cases across the entire software development effort. In Figure 3.0, Steps One and Two are used to generate the Use Case Blueprint. The mechanism used to capture these Use Cases is Cockburn's template. The requirements process and feedback loops supported by most software development processes (specifically between their early stages) encourage iterative and incremental development of this Blueprint (see Figure 1.0). The Use Case Blueprint generated from Steps One and Two can then be used to support the activities described within the rest of the software development processes (i.e., Steps Three, Four and Five).


This section explores the relationship of a Use Case Blueprint within each of these software development Steps.

3.1 Defining Objectives

The activities described within the first step require that the software development sponsor and its software development team define and agree on a set of objectives, and document what must be accomplished to achieve those objectives. As shown in Figure 3.1.1, Use Cases provide a means for identifying:

1. Initial planning documents, and 2. Software objective statements.

Figure 3.1.1 - Step One

At this stage in requirements definition, one or more software engineers, in conjunction with the project sponsor(s), establish the rationale, scope and subsequent goals of the software development effort. The Use Cases developed at this level begin as Summary Use Cases due to their high level, conceptual nature. Once the Summary Use Cases have been identified, another level (or nesting) of requirements and goals can then be revealed. These next level requirements and goals provide either additional Summary information or identify a primary task to be accomplished within the software program. Summary information is documented as a deeper-level Summary Use Case whereas; a requirement or goal that identifies a primary task is documented as an Primary Task Use Case. The characterization of a Primary Task Use Cases may then lead to the identification of Sub-Function Use Cases in a similar manner. Figure 3.1.2 provides a simple graphical representation of a Use Case hierarchy.


Figure 3.1.2 - Use Case Hierarchy

It is important to note that the focus for Step One is to simply identify the goals and objectives of the project. Therefore, not all of Cockburn's template needs to be filled out initially. Typically the name, the goal, the scope and the level are all that's required. If the precondition or postcondition is known, then that can be filled out as well. In many circles, this requirements aspect is identified as the "inception" level of the requirements effort. The Use Cases identified in Step One will be further "elaborated" within the activities described by Step Two. The benefits of Use Cases within Step One are highlighted in Table 3.1.

Table 3.1 - Step One Use Case Support Step One Elements Use Case Support Major Benefit

Sponsor Needs Captures sponsor requirements and needs as hi-level Summary Use Cases.

Establishes an explicit and unambiguous statement of sponsor needs.

Objectives Development

Captures detailed set of specific objectives as deeper-level Summary Use Cases and Primary Task Use Cases.

Contains measurable objectives and initial VV&A/test requirements criteria.

3.2 Development of a Conceptual Model

The second step of our software development process requires that a representation of the real world domain of interest (entities and tasks) needed for the system be described and documented. This is the nature of a conceptual model. It is within Step Two that the elaboration of aspects pertaining to goals and requirements occurs for the Use Cases initially identified in Step One. Here we fill in the rest of Cockburn's template; completing the precondition, postcondition, actors, and scenario steps including exceptions and variations. This elaboration process allows us to further breakdown the Summary Use Cases identified in Step One into Primary Task and Sub function Use Cases, and to elaborate on the elements of each Use Case thereby creating the conceptual model for the system under development. Aspects of elaboration might include the types of high-level analysis required to ensure proper execution or the identification of specific


behaviors of instantiated objects controlled by a element of the software. Once the tasks involved in Step Two are complete, the collection of completed Use Cases becomes a Blueprint identifying:

1. Conceptual model and requirements, 2. General scenario for potential Object Models (i.e., structures, classes, and methods), and 3. Test criteria needed to evaluate the success of the system.

At this point, the Blueprint will now contain representations and relationships that have identified and captured the software programs objectives, cases of use, domain, top-level design, and top-level planning. These elements are identified in figure 3.2.

Figure 3.2 - Step Two

The major benefits of Use Cases within Step Two are identified in Table 3.2.

Table 3.2 - Step Two Use Case Support Step Two Elements Use Case Support Major Benefit

Scenario Development

Captures major entities to be involved and entity capabilities, behavior and relationships as Primary Task Use Cases. Includes Preconditions, End Conditions and Scenario Description.

Provides establishment of potential interaction based scenarios.

Conceptual Analysis Captures the detailed set of specific objectives as low-level Summary Use

Provides a traceability link between the objectives and the design implementation.


Cases and/or Primary Task Use Cases.

3.3 Design and Development

The third step of our software development process describes the design and implementation phases of software construction. At this step, the process requires all actors to have been determined, all Primary Task Use Cases and Sub Function Use Cases to be established, and all information exchange requirements and responsibilities explicitly documented. See Figure 3.3.1.

Figure 3.3.1 - Step Three

Again, the collection of Use Cases developed during the first step and second step produces the Blueprint. This Blueprint can now be used to guide the construction (or modification) of a software program. For example, a Primary Task Use Case within the Blueprint may identify the requirement for a structure or class and its associated methods and identify any related classes required to support its goals. The Blueprint takes the guesswork out of what needs to be defined. By following the Blueprint, software patterns can be identified and components can be designed and developed without the need of extensive queries and discussions among software engineers.

It’s also important to note that the Blueprint encourages incremental development of the software engineering effort. “Build a little, test a little, learn a lot” is a common engineering philosophy, when put into practice, can produce tremendous benefits in the life-cycle development of software and systems. The same philosophy can be applied to software development when a Use Case Blueprint is being utilized. The Blueprint identifies the elements required for the software and any linked elements. If a program is built to a subset of contingent elements, it can then be delivered, used and tested prior to it’s completion. Therefore, a Use Case Blueprint streamlines software design and development.

The incremental development that a Use Case Blueprint encourages, also lends itself well in guiding the design and development of design patterns and components. This includes the creation and use of Reusable Object Models (ROM). A ROM is a generic term for a component that reflects a single aspect of software execution that can be used as a building block for other


development efforts. This is analogous to component based software development in which a programmer may use, or generate DLL, ActiveX, VCL, CLX, JavaBean, or Base Object Model (BOM) components. The Use Case Blueprint also provides the meta-data necessary to describe the intent of a ROM.

For example, if a program is being developed or enhanced, a software engineer may use the Use-Case data contained in the Blueprint to perform a meta-data match against the Use Case information for existing ROMs (including DLLs, ActiveX, VCL, CLX, JavaBean, and BOM components). This Use Case meta-data is vital because it identifies the purpose and capability of a software component. Figure 2.3.2 illustrates the process for incremental and component based design and development based on Use Cases and ROMs.

If a ROM exists that helps to satisfy a requirement of the software being developed or updated, then it can be quickly and efficiently integrated into that effort. If a ROM does not currently exist, then the software engineer may define and store the particular component-based object and the associated Use Case contained within the Blueprint as a distinct ROM, which can also be used for future development. This allows ROMs (such as VCLs) to be created ‘on-the-fly’ during software development and maintenance. Because the ROM created ‘on-the-fly’ has a well-defined Use Case associated with it, Meta-data matching may be performed during the construction or modification of other software development efforts.

Figure 3.3.2 - Object Oriented Construction

The summary benefits of Use Cases within Step Three are highlighted in Table 2.3.

Table 3.3 - Step Three Use Case Support Step Three Elements Use Case Support Major Benefit

Design Guides construction or modification of a software development project.

Provides the necessary foundation for Design.

Development Facilitates incremental and

Helps produce requirement verified design patterns and


component-based development of a system.

components with supplemental meta-data. Provides a traceability link between objectives, design, and the actual implementation.

3.4 Integrate and Test

The fourth step of our software development process describes the aspects of integrating and testing the software prior to delivery. During this step, the software development process requires all necessary software implementation activities to be performed, and testing to be conducted to ensure all requirements are being met. This includes planning, identifying, and integrating program segments and data flow, and performing an initial checkout test as illustrated in Figure 3.4.

Figure 3.4 - Step Four

In order to ensure that interoperability requirements are met, the original requirements must be examined and compared. Primary Task Use Cases contained within the Blueprint provide an easy-to-read, easy-to-track mechanism useful for comparing implementations against requirements. The tracking capabilities produced through Use Cases provide requirements traceability. Use Cases can be passed to Step Four to help identify critical test points, and provide the basis for developing:

1. Software Compliance and Integration Test Plans, 2. Scenario and Exercise Plans, and 3. Verification, Validation and Accreditation (VV&A) Plans.

Summaries of the benefits Use Cases provide within Step Four are highlighted in Table 3.4.


Table 3.4 - Step Four Use Case Support Step Four Elements Use Case Support Major Benefit Execution Planning Supports the

identification of software performance requirements and other Software Execution Planning issues.

Provides the initial hi-level information required to support program execution.

Integration and Test Identifies critical test points based on objectives (Summary Use Cases), and Actor-to-System interactions (Primary Task Use Cases and Sub Function Use Cases).

Provides an initial checklist and tracking mechanism useful for all levels of testing

3.5 Exercise and Analyze Execution Results

As illustrated in Figure 3.5, the fifth and final step of our software development process describes the aspects of the software program execution and criteria for analyzing the execution results. Specifically, this step requires the software to be executed, outputs analyzed, and feedback provided to the sponsor.

Use Cases collected during Steps One and Two provide the “test evaluations criteria” necessary to ascertain the success or failure of the software within Step Five activities. Additionally, the Use Case Blueprint provides a framework for the High Level Analysis Plan and the basis for the Detailed Data Collection and Analysis (DC&A) plan necessary to support the role of the Software and System Analyst.

Figure 3.5 - Step Five


A summary of the benefits of Use Cases within Step Five is highlighted in table 3.5.

Table 3.5 - Step Five Use Case Support Step Five Elements Use Case Support Major Benefit

Execution Use Case scenarios guide execution.

Provides a clear concept of execution operation.

Results Supports execution analysis.

Provides initial checklist and tracking mechanism useful for execution analysis.

Feedback Supports the evaluation of success or failure of the software based on the Use Case scenarios and success criteria.

Provides a mechanism for evaluating software execution and supporting modifications of that software.

3.6 LEPO's Blueprint Centric Process - Summarized

As detailed in the above sections, and summarized in Figure 3.6, the Use Cases captured within Cockburn's template from LEPO's Step 1 and Step 2 forms a Blueprint that can be used throughout the life-cycle development process, extending through LEPO's Step 3, Step 4, and Step 5. Like an architectural blueprint for a house or building, a Use Case Blueprint provides a common reference for the development, maintenance, testing and analysis of a software program.

Figure 3.6 - LEPO's Blueprint Centric Process


4.0 Summary Solid functional requirements can be identified and effectively used at each software development process stage by examining the intended goals of the software engineering effort. The collection of these functional requirements, documented as Use Cases, establishes a highly useful Blueprint.

The collection of Use Cases, identified as a Blueprint, not only represents a set of objectives and functional requirements, for a specific software project, but also the real world domain of interests (entities and tasks). Use Cases are described in terms of a set of required behavior (or activities) and interactions. This information can be effectively used at each software development process stage. Specifically, the Use Case Blueprint ensures that the software development purpose is fully understood, and encourages the active participation and communication of Sponsors, Engineers, Testers, and Analysts throughout the software development process.

Cockburn’s Template provides the necessary mechanism to identify and document the functional requirements as Use Cases and provides a standard template for related requirements meta-data. Applying this mechanism for software development projects promotes and encourages the following capabilities:

• Simplifies Requirements Capturing • Provides An Easy Way To Share (Communicate) with Sponsors, Engineers, and Analysts • Supports Software Verification and Validation • Facilitates Automation of the Software Development Process • Encourages Object Model Reuse (i.e. ROMs)

It is highly recommended that the development and use of Use Case Blueprints be applied to better support the development, testing and analysis of software systems.

5.0 Works Sited [1] Fowler, M., “UML Distilled: Applying the Standard Object Modeling Language”, Addison -

Wesley, 1997.

[2] Department of Defense, “High Level Architecture, Federation Development and Execution Process (FEDEP) Model”, Version 1.5, 8 Dec 1999, http://www.dmso.mil/hla/.

[3] Cockburn, A., "Structuring Use Cases with Goals", HaT.TR.95.1, Journal of Object-Oriented Programming (JOOP), Sept and Nov 97, two part series.

[4] Cockburn, A., “Basic Use Case Template”, TR.96.03a, Human and Technology, October 26, 1998, http://members.aol.com/acockburn/.

Documents

Blueprints for Software Development