Submitted by: Noriaki Suzuki and Jonathan Eser
Instructors: Mark Austin and John Baras
ENSE 621-622: Systems Requirements and Design, Sprint 2004.
TABLE OF CONTENTS
The goals of this project are to improve current fishery statistics system for the Ministry of Agriculture in the nation of El Salvador
By collecting statistical information on the fish caught per year in El Salvador, inferences can be made about biological data such as the population of various species of fish, their maturity, their gender, and their size
Results from this study will support an annual report published by the organization, recommendations to the national legislature for fishing restrictions, and installation of artificial reefs to act as sanctuaries for many fish
Problem and Goals
The suite of current problems includes:
Hence, the goals of this project are as follows:
Figure 1 shows the high-level interactions are shown for the system.
Figure 1. System Boundary
Outside conservation groups and the government of El Salvador set many requirements and are observant of system activity, they are noted as the environment. Of course, the system must interact with fisherman at the landing points (fishing ports) in order to gain information. Main system functions are conducted by members of the Fishery Development Center including the scheduling of employees for data collection and the data collection with support activities.
Initial Use Case Diagram for The Fishery Statistics System
Considering the breadth of activities that the system conducts and main stakeholder requirements that it fulfills, only two use cases are discussed in the following report that of "scheduling" and "collection." See Figure 2.
Figure 2. Initial Use Case Diagram for Fishery Project
These use cases are examined in depth for both design behavior and structure using a semi-automated iterative procedure complete with requirements analysis. The new scheme for behavior analysis considering both positive (desired) and negative (undesired) behavior has resulted in several behavior improvements as noted in ?red? in Figures 3 and 4 below.
Activity Diagram for "Schedule for Collection" (A)
The key activities for "schedule for collection" are shown in red.
Figure 3. Activity Diagram for Use Case "Schedule for Collection" (A)
Activity Diagram for "Collect Data" (B)
The key activities for "collect data" are shown in red.
Figure 4. Activity Diagram for Use Case "Collection Data"(B)
Visual Aid for Statechart diagram (Statecharts vs. State Diagrams) ...
In order to properly interpret the system, an effective visual representation must be used that satisfies two requirements:
Prior work utilized a state diagram representation of system states. While the state diagram tool is effective at identifying state transitions it does so in a flat and linear fashion that confines the system to sequential transitions and does not show depth, hierarchy, or modularity. With a large system, the state diagram representation becomes over crowded with linkages and guards. Because of the sequential perspective of the state diagram there is also no way to create timing within the state diagram for synchronized transitions.
Figure 5 displays the state diagram for the ?full-time collector throughout the subsystems in question, the limitations of such a representation are clear when a higher level diagram such as Figure 7 is displayed, which considers more state transitions, but does so in a simpler format.
An improved method of representing system states is with a state chart, which depicts the same information as a state diagram, but also is capable of showing concurrent behavior and nested relationships. State charts are the preferred method for describing reactive systems that respond to inputs with an organized set of actions and state conditions. By allowing for depth and orthogonal design, state charts can describe not only links between states but also relationships providing some insight on how states with similar transitions may be seen as a modular unit. Triggers and guards allow for the same conditions for transition that state diagrams have, but the broadcasting functions in statecharts allow for synchronized behavior between concurrent processes.
Statechart Diagram for "Full Time Collector" (Previous Version)
Figure 5. Statechart Diagram for Fulltime Collector (Previous Version)
Statechart (Current Version)
Statecharts = state diagrams + depth + orthogonality + broadcast communication
Figure 6 depicts in simplified form the distinct methods for describing relationships in a statechart.
Figure 6. Statechart Concept (Current Version)
Depth is depicted in the figure by nesting states A and C together in D. As the figure depicts the black dot shows where within an accumulation of states the initial state resides. Here upon entering the system A is entered and either A or C can lead to B through transition "f". The advantage to demonstrating depth is that now states A and C are no longer seen completely independent, but are shown to have a commonality in how they transition to B. Aspects of orthogonal design and broadcasting are also displayed. Orthogonal design effectively allows for all the combinations of states divided by a dashed line irrespective of order. Concurrent design can be easily depicted by showing transitions as independent within the system as a whole. While on process within the system sits in state A another parallel process can transition between B and D following the correct triggers. Synchronization of behavior across concurrent processes are made possible with broadcasting communications. As is shown above, the nomenclature of transitions "f/g" means that once "f" occurs ?g? will occur immediately. This effectively show that state C,B cannot transition directly to A,B because once ?f? occurs "g" will immediately follow leading from C,B to A,D. Communication between parallel processes is a useful tool for accurately describing real world concurrent systems.
Statechart Representation of Arrived States
Figure 7 shows the system high level state transition viewpoint.
Figure 7. Statechart for Schedule for Collector (A), Collection Data (B) (Current Version)
A statechart representation is utilized so that the inherent concurrent behavior can be accurately described. Beginning with system activation, the scheduling aspects of the system are entered and revolve around communications and sharing of messages between four main state groupings the local office/manager, both the full-time and part-time collector, and the monitor. Here, these state groupings are convenient because they also correspond to objects within the system. By using the statechart tool these types of groupings are possible utilizing the depth of the visual formalism. Understanding is improved by seeing that states can be grouped according to the object they relate to and how those objects interact within the overall system state. Concurrency is also displayed within the scheduling state between states occupied for part-time scheduling and full-time scheduling. The diagrams are also consistent with the positive/negative scenario analysis afforded by the LTSA tool. It should not be possible to exit the scheduling states without having the schedules complete and sending them to the monitor.
On exiting the scheduling states, the collection states are entered that display relationships between collection states of the collector and contact with the boat where data is gained and finally with the data sheets where the data is entered. While the collector gains and enters data the concurrent feature of this use case is displayed by the monitoring that occurs simultaneously.
This state chart representation is limited to the scheduling and collecting subsystems within the fishery statistics program and does not display all the guards and triggers that would be needed to automate such a finite state representation. An interesting improvement of such a representation would be the direct transfer of the Label Transition State (LTS) diagrams offered by the LTSA tool into the state chart representation. Such an improvement would allow behavior analysis within the LTSA environment to directly transition to the lucid state chart format.
LTSA (Labeled Transition System Analyzer) is a verification tool for concurrent systems. It mechanically checks that the specification of a concurrent system satisfies the properties required of its behavior. In addition, LTSA supports specification animation to facilitate interactive exploration of system behavior. A system in LTSA is modeled as a set of interacting finite state machines. LTSA performs analysis to exhaustively search for violations of the desired properties. Each component of a specification is described as a Labeled Transition System (LTS), which contains all the states a component may reach and all the transitions it may perform.
We aim to use LTSA (Labeled Transition System Analyzer) tool for detecting the presence of concurrency problem (implied scenarios) in our system:
Before presenting usage of LTSA tool, we show what the concurrency system problem is (Figure 8). LTSA encounters a difficulty with shared resources. The concurrency problem causes a safety error and deadlocks
Figure 8. Example of Concurrency Problem
Usage of LTSA Tool
The verification architecture in the LTSA tool is formed from two viewpoints to find implied scenario.
See Figure 9.
Figure 9. Model-Based Verification Architecture
Specification is created as part of the requirements for the composition. The specification consists of a message sequence chart, and the FSP representation of the composition for verification. The MSC (Message Sequence Chart) allows models to be described by graphically editing sets of scenarios in the form of message sequence charts. The LTSA can be used to detect the presence of implied scenarios in the system as part of an iterative design process. Using LTSA-MSC allows capture of workflow behavior desired by user in the form of message sequence charts.
The verification process to our project is as follow.
Implied scenarios are shown on the following pages.
Schedule for Collector (Implied Scenario)
Figure 10. Implied Scenarios for Schedule (A.1)
Schedule for Collector (Architecture Model)
Figure 11. Architecture Model for Schedule 1.
Figure 12. Architecture Model for Schedule 2.
Collection Data (Implied Scenario)
Figure 13. Implied Scenario for Collection Data (B-1)
Figure 14. Implied Scenario for Collection Data (B-2)
Figure 15. Implied Scenario for Collection Data (B-3)
Collection Data (Architecture Model)
Figure 16. Architecture Model for Collection Data 1.
Figure 17. Architecture Model for Collection Data 2.
Figure 18. Architecture Model for Collection Data 3.
Requirements for Solving the Implied Scenarios
Requirements are added to solve the implied scenarios encountered with use of the LTSA tool. The requirements were developed as part of the requirements analysis discussed next and are shown in Table 1 below.
|Schedule for Collector (A)|
|Requirement||Relating Implied Scenario|
|The monitor should not begin to work from the monitor schedule until the part time scheduling is complete.||A-1: Monitor checked schedule to make the monitor sheet before part time collector fixed the schedule.|
|Collection Data (B)|
|Requirement||Relating Implied Scenario|
|Monitor must evaluate the data after collectors scribe the data to the datasheet.||B-1: Monitor checks the data sheet before collectors acquire data.|
|B-3: Monitor can not evaluate incomplete collected data|
|Monitor should contact collector not to landing point.||B-2: Once collectors fail to contact boat, they have to look for another boat monitor doesn't recognize. In this case, it is impossible for monitor to contact with collectors|
Table 1. Requirements Generated from Implied Scenarios
LTSA Tool Limitation
|No more than 6 instances||When it compiles, computer may freeze|
|No more than 10 transitions in High level MSC||When it compiles for drawing, there is a shortage of memory|
|No more than 7 or 8 bMSC||When it compiles for drawing, there is a shortage of memory|
|No more than 62 states||More than 62 states will be not displayed|
|LTS draw isn't able to copy or select||LTS draw isn't able to copy or select|
|Changing instance name affects all transition contained in the instance||bMSC editing|
|"." isn't available for lavels||bMSC editing|
|Sequence diagram isn't able to copy or select||Sequence diagram isn't able to copy or select|
Table 2. LTSA Tool Specification
Solution for the Concurrency Problem
Figure 19. Solution for Concurrency Problem
Method for Requirements Analysis
Requirements analysis for the fishery statistics system follows the same style as presented in the ENSE 622 class notes.
Requirements analysis for the fishery statistics system Stakeholder goals and high level requirements are gathered and used to form high level use cases. The design intent at this point is that the system should perform a job that interested parties request and sufficient behavior should exist to ensure the goals are fulfilled, structure should be derived from behavior. Textual use cases are then written outlining the specific scenarios of nominal system behavior over which the use cases will cover. Paths of behavior should follow from individual scenarios. A visual representation of the scenarios can be made with activity diagrams outlining several paths of behavior that may be intertwined and meet a decision junctions or across synchronized behavior. From the activity path vantage point, necessary structure should be derived with an analysis outlining related classes of components and how the classes of components and objects are related. Object characteristics including static variables and behavioral dynamic variables must also be noted. Traces of scenarios can be represented by showing exactly how objects pass messages and communicate to perform a task, such a trace is called a sequence diagram. Objects are introduced with the intent of performing certain tasks leading to the ultimate goals of the system. Tracking the object characteristics and behavior to how they can meet the high level goals of the system needs a requirements set. Requirements are the detailed specification of values that object traits must posses. Without direct requirements, specification traits would not be constrained and stakeholder goals would not be met. In addition to determining requirements based on mandating objects to perform activities, requirements can also be developed by mandating objects to avoid performing certain other behaviors. By considering both the ?should? and he "should not" a fully coherent set of requirements can be developed that will ensure desired behavior and exclude undesired behavior.
Figure 20. Method for Requirements Analysis
As noted in Figure 20, the LTSA tool used for analyzing behavior played an integral part in the development of consistent requirements that do not serve cross purposes and coherent in that both positive (desired) scenarios and negative (undesired) scenarios are taken into consideration.
From such an iterative requirements design scheme that considers both positive and negative scenarios, requirements are internally and externally consistent with imposed high level goals. Iteration is a necessary aspect of the requirements analysis method because the steps for identifying requirements needed to ensure behavior is still manual. Future system design methods may be capable of assigning quantitative values for system objects once proper behavior is identified, but currently the best source of system behavioral knowledge is still the involved cognizant engineer.
Requirements are divided for purposes of tracing into various categories for hierarchy adjustment. First level requirements imposed on the system by the government of El Salvador include the necessity of quality data, low cost, and timeliness in the system. Subcategories at the project level ensure their respective first level requirement is met and are identified by the adjacent table 2 in the second digit. Detailed requirements and quantitative limits on object characteristics are noted in third and fourth level requirements.
|R1 Quality Data||R2 Low Cost||R3 Timeliness|
Table 3. High Level Specification for the Project
Tracing Requirements to Behavior
Table 4. High-level Traceability Matrix
With requirements set through an iterative scheme of fulfilling positive scenarios and denying negative scenarios, there is considerable overlap between the high-level requirements across different scenarios. The overlap is not surprising given that general system operation necessitates a whole host of requirements each from a different high level goal. For instance, in order to implement proper scheduling a base of properly qualified employees is required that are assigned deadlines for their work and whom collect the proper type of data and at the right location and frequency. Despite the overlapping of many requirements, there are some needs within the system that are more useful. These most used requirements are evident when the scenarios are traced to the requirements that implement them.
Two requirement sets that are most useful are the need for qualified employees that have proper training for their job assignments and also the setting and maintenance of deadlines for work. Within every functional level of the system there are repeated needs for jobs to be performed correctly and under the constraint of deadlines. When trade-off analysis is performed on these system design, special consideration must be taken for these two requirement sets. They are crucial for the proper operation to the system; however they are both factors that would increase cost. Implementation of requirements does not come cheaply; only after quantitative arguments are presented can the proper level of employee training and work load be determined.
The following table outlines many of the requirements derived for the system. The supported scenario is marked with column "SCENARIO" and related high level requirement is referenced in the column "REQ". In the column "OBJECT" the object that controls the behavior is listed and in the "STATIC/DYNAMIC VARIABLE" column the quantitative specification is made for the object attribute or a comment is made outlining the appropriate limit when no quantitative value is reasonable. Several requirements also support preventing negative scenarios and besides them a ?***? indication is made.
|Full time collector is scheduled|
|A.1.1||Ministry of Agriculture requests annual collection and analysis||R.1.1||local manager||receive information|
|R.1.3||local manager||arrange transportation|
|R.3.2||local manager||make schedule|
|local manager||make data sheets|
|local manager||make schedule|
|A.1.2||Local managers make collection schedules/data sheets||R.1.1||local manager||.... etc ... etc|
Table 5. Abbreviated Pathway from Scenarios to Lists of Requirements
Several improvements have been made to the fishery statistics system by using a semi-automated behavioral design scheme with iteration on behavior and requirements. A new visual aid has been demonstrated that better represents the condition of a reactive system and continues to support and surpass the qualities of the standard state chart diagram. Work with the LTSA tool helped to identify confusing and non-intentional behaviors. These faulty behaviors were labeled as negative scenarios and appropriate measures were taken in the requirements analysis to prevent them. Requirements were also derived to support the completion of scenarios. In most cases the requirements were reflected in a quantitative manner. By transcending high level goals into quantitative details, designers can take advantage of a trade off analysis for optimized system design in a meaningful way.
Future work will entail using the LTSA tool to automatically eliminate negative scenarios and modify the architecture design accordingly. A review of the Capability Maturity Model (CMM) will help to validate system design practices and assure potential investors that the system is on stable footing for operation. A more detailed trade off analysis taking advantage of the newly developed requirements and behavioral aspects will help to define when is needed for initial system implementation.