Unformatted text preview:

And Their ApplicationIntroductionA-7 Program CharacteristicsDocument Objectives are toDocument Design Principles are toSummary of Specifying Software RequirementComplex Systems: New TechniquesAnd Their Application---By Guanghui Weng April 26, 2003Author: Kathryn L. HeningerPublished in IEEE Transactions on software Engineering in January 1980For StudentsThis paper concerns new techniques for making requirement specifications precise, concise, unambiguous and easy to check for completeness and consistency. These techniques are used in writing the document of the Navy’s A-7 aircraft software system that is a complex real-time system.IntroductionMuch software is difficult to understand, change, and maintain. Several new software engineering techniques have been suggested to ameliorate this situation including modularity, information hiding, formal specs etc. The Navy Research Lab and the Naval Weapons Center tested these techniques and want to redesign and rebuild the operational flight program for the A-7 aircraft by using them. The new program must be functionally identical to the existing program. The first step was to produce a complete description of the program requirements in a form that would facilitate the development of the new program and that could be updated easily as the requirements continued to change. The team used some new techniques that are mentioned in this paper and these approaches can be useful for other projects.A-7 Program CharacteristicsThe A-7 flight program is an operational Navy program with tight memory and time constraints. The code of the old system contains 12,000 assembler language instructions and is difficult to change. Twenty-two devices are connected to the computer.Document Objectives are to1. Specify external behavior without implying a particular implementation2. Specify constraints on the implementation especially the details of the hardware interfaces3. Be easy to change4. Serve as a reference tool5. Record forethought about the life cycle of the system6. Characterize acceptable responses to undesired eventsDocument Design Principles are to1. State questions before trying to answer them2. Separate concerns3. Be as formal as possibleTechniques for Describing Hardware InterfacesTo organize the hardware interface descriptions, we have a separate unit called a data item. A-7 computer receives 70 input data items and transmits 95 output data items. For each data item, there is a form to be completed. On the form each data item and value are given a symbolic name with difference bracket like /input-data-item/, //output-data-item//, $nonnumeric-values$. The bracket reduces confusion by identifying the item type. There are two types of data items: arbitrary details that might change if a device were replaced with a similar device, and essential characteristics that would be shared by similar devices. Templates were designed to describe these data items. They made values easier to describe, made the descriptions consistent with each other and create the same standards of completeness to all items of the same type.When describing input data items, we refrain from mentioning how or when the data is used by the software to avoid making any assumptions about the software function. We define numerical values in terms of what they measure. For the output data items, they are described in terms of their effects on the associated devices. Techniques for Describing Software FunctionsWe describe the software as a set of functions associated with output data items. Each function determines the values for one or more output data items, and each output data item is given values by exactly one function. Thus, every function can be described in terms of externally visible effects.Software functions are classified as either demand or periodic. A demand function must be called for by theoccurrence of some event every time it is performed. A periodic function is performed repeatedly without being requested each time. If a periodic function need not be performed all the time, it is started and stopped by specific events. To describe a periodic function, one must initiate the events that cause it to start and stop and the conditions that affect how it is performed after it is started.The requirements of output values are expressed as functions of aircraft operating conditions. Conditions are predicates that characterize some aspect of the system for a measurable period of time. An event occurs when the value of a condition changes from true to false or vice versa. How the program detects this event is left to the implementation.We introduced text macros that are bracketed in exclamation points and defined in an alphabetical dictionary to describe conditions. The advantage of the macro is to abbreviate the compound conditions thatare frequently used or very detailed, and only the dictionary need to be changed if the criteria change for the sensor. Sometimes one function is affected by a set of conditions, so we can organize these conditions into groups in order to keep the function descriptions simple. This group is called mode. A mode is given a short mnemonic name enclosed n asterisks. We invented two types of tables. One is a condition table that is used to define some aspect of an output value that is determined by an active mode and a condition that occurs within that mode. In each row there are a set of mutually exclusive conditions and only one should be true whenever the program is in the modes denoted by the row. The other is an event table that shows when demand functions should be performed or when periodic functions should be started or stopped. Each row in an event table corresponds to a mode or group of modes. Techniques for Specifying Undesired Events and for Characterizing Types of ChangesWe need to interview pilots and maintenance programmers to find out what they would like to have happened, what are the possible changes and what they consider feasible. We can use the classification scheme to list all the undesired events and all the feasible


View Full Document
Download Complex Systems
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Complex Systems and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Complex Systems 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?