SYSTEM MODELING Every computer-based system can be modeled as an information transform using an

10.6 SYSTEM MODELING Every computer-based system can be modeled as an information transform using an

input-processing-output template. Hatley and Pirbhai [HAT87] have extended this view to include two additional system features—user interface processing and main- tenance and self-test processing. Although these additional features are not present for every computer-based system, they are very common, and their specification

makes any system model more robust. Other system modeling

XRef

Using a representation of input, processing, output, user interface processing, and methods take an

self-test processing, a system engineer can create a model of system components object-oriented view.

that sets a foundation for later steps in each of the engineering disciplines. The UML approach can

be applied at the To develop the system model, a system model template [HAT87] is used. The sys- system level and is

tem engineer allocates system elements to each of five processing regions within the discussed in Chapters

template: (1) user interface, (2) input, (3) system function and control, (4) output, and

21 and 22. (5) maintenance and self-test. The format of the architecture template is shown in

Figure 10.5. Like nearly all modeling techniques used in system and software engineering, the system model template enables the analyst to create a hierarchy of detail. A system context diagram (SCD) resides at the top level of the hierarchy. The context diagram "establishes the information boundary between the system being implemented and the environment in which the system is to operate" [HAT87]. That is, the SCD defines all external producers of information used by the system, all external consumers of information created by the system, and all entities that communicate through the interface or perform maintenance and self-test.

CHAPTER 10

SYSTEM ENGINEERING

F I G U R E 10.5

System model template

User interface processing

[HAT87]

Output processing

Input

Process and control

functions

processing

Maintenance and self-test

To illustrate the use of the SCD, consider the conveyor line sorting system that was introduced in Chapter 5. The system engineer is presented with the following (some- what nebulous) statement of objectives for CLSS:

CLSS must be developed such that boxes moving along a conveyor line will be identi- fied and sorted into one of six bins at the end of the line. The boxes will pass by a sort- ing station where they will be identified. Based on an identification number printed on the side of the box (an equivalent bar code is provided), the boxes will be shunted into the appropriate bins. Boxes pass in random order and are evenly spaced. The line is moving slowly.

The SCD provides a “big picture” view of

For this example, CLSS is extended and makes use of a personal computer at the sort- the system you must

ing station site. The PC executes all CLSS software, interacts with the bar code reader build. Every detail

to read part numbers on each box, interacts with the conveyor line monitoring equip- need not be specified

ment to acquire conveyor line speed, stores all part numbers sorted, interacts with a at this level. Refine the

SCD hierarchically to sorting station operator to produce a variety of reports and diagnostics, sends con- elaborate the system.

trol signals to the shunting hardware to sort the boxes, and communicates with a central factory automation mainframe. The SCD for CLSS (extended) is shown in Fig- ure 10.6.

Each box shown in Figure 10.6 represents an external entity—that is, a producer or consumer of system information. For example, the bar code reader produces infor- mation that is input to the CLSS system. The symbol for the entire system (or, at lower levels, major subsystems) is a rectangle with rounded corners. Hence, CLSS is rep- resented in the processing and control region at the center of the SCD. The labeled

PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 10.6

System context

Sorting

diagram for

Bar code

Sorting reader

commands

Bar

Conveyor

mechanism

code

Line Sorting

Formatted reporting data

System

Line speed

Diagnostic data

indicator Sorting

station operator

arrows shown in the SCD represent information (data and control) as it moves from the external environment into the CLSS system. The external entity bar code reader produces input information that is labeled bar code. In essence, the SCD places any system into the context of its external environment.

The system engineer refines the system context diagram by considering the shaded rectangle in Figure 10.6 in more detail. The major subsystems that enable

XRef

The SFD is a precursor the conveyor line sorting system to function within the context defined by the SCD to the data flow

are identified. Referring to Figure 10.7, the major subsystems are defined in a sys- diagram, discussed in

tem flow diagram (SFD) that is derived from the SCD. Information flow across the Chapter 12. regions of the SCD is used to guide the system engineer in developing the SFD—

a more detailed "schematic" for CLSS. The system flow diagram shows major sub- systems and important lines of information (data and control) flow. In addition, the system template partitions the subsystem processing into each of the five regions discussed earlier. At this stage, each of the subsystems can contain one or more system elements (e.g., hardware, software, people) as allocated by the

WebRef

system engineer.

A useful white paper on Hatley-Pirbhai method can

The initial system flow diagram becomes the top node of a hierarchy of SFDs. Each

be found at rounded rectangle in the original SFD can be expanded into another architecture tem-

www.hasys.com/

plate dedicated solely to it. This process is illustrated schematically in Figure 10.8.

papers/ hp_description.html

Each of the SFDs for the system can be used as a starting point for subsequent engi- neering steps for the subsystem that has been described.

CHAPTER 10

SYSTEM ENGINEERING

F I G U R E 10.7 Operator

System flow

Operator requests

CLSS queries, reports, displays

interface

Operator

diagram for

Bar code acquisition request

subsystem

Shunt control status

Sorting reports

CLSS processing

Report

Timing location data

& control

requests

Part

Shunt subsystem

Bar code

cmds reader

Bar code

subsystem controller

control

subsystem

Bin Bar code

Raw bar

code data

Shunt commands

CLSS reports Sensor data

Key formating acquisition

speed

subsystem subsystem

Sort records

Mainframe

BCR status

communications Shunt status

driver Pulse tach

Sensor status

Bar code

Formatting

status

Data acquisition reader status

reporting data

interface Diagnostic interface Output interface

Subsystems and the information that flows between them can be specified (bounded) for subsequent engineering work. A narrative description of each subsys- tem and a definition of all data that flow between subsystems become important ele- ments of the System Specification.