Chapter Comments 6-1

Chapter  6
System Engineering

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to provide a brief introduction to the system engineering
process. The overall structure of computer-based systems is discussed and a brief
overview of the system engineering hierarchy is presented. Business process
engineering (BPR) and product engineering are discussed in overview fashion.
Note: Some reviewers of this edition argued that a discussion of system engineering is
beyond the scope of a software engineering text.

S/W Eng occurs as a consequence of a process called System engineering. System

Engineering focuses on analyzing, designing, and organizing those elements into a
system that can be a product, a service, or a technology for the transformation of
information.

6.1 Computer-Based Systems

This section introduces the systems view of engineering (all complex systems can be
viewed as being composed of cooperating subsystems). The elements of computer-
based systems are defined as software, hardware, people, database, documentation, and
procedures.

A computer-based system makes use of a variety of system elements.

Software: programs, data structures, and related work products.

Hardware: electronic devices that provide computing capabilities.
People: Users and operators of hardware and software.
Database: A large, organized collection of information that is accessed via S/w and
persists over time.
Documentation: manuals, on-line help files.
Procedures: the steps that define the specific use of each system element.

One complicating characteristic of computer-based system is that the elements

constituting one system may also represent one macro element of a still large system.
 6-2 SEPA, 6/e Instructor’s Guide

The micro-element is a computer-based system that is one part of a larger computer

based system.
6.2 The System Engineering Hierarchy

The key to system engineering is a clear understanding of context. For software

development this means creating a "world view" and progressively narrowing its focus
until all technical detail is known.

In software engineering there is rarely one right way of doing something. Instead
designers must consider the tradeoffs present in the feasible solutions and select one
that seems advantageous for the current problem. This section lists several factors that
need to be examined by software engineers when evaluating alternative solutions
(assumptions, simplifications, limitations, constraints, and preferences).
Regardless of its domain of focus, system eng. Encompasses a collection of top-down
and bottom-up methods to navigate the hierarchy illustrated below:

Business or
Product Domain
World view

Domain of interest

Domain view

System element

Element view

Detailed view
 Chapter Comments 6-3

The system eng. Process usually begins with a “world view.” The entire business or
product domain is examined to ensure that the proper business or technology context
can be established.

The world view is refined to focus more fully on a specific domain of interest.

Within a specific domain, the need for targeted system elements (data, S/W, H/W, and
people) is analyzed.

Finally, the analysis, design, and construction of a targeted system element are initiated.

6.2.1 System Modeling

System modeling is an important element of the system eng. Process. The Engineer
creates models that:
1. Define the processes that serve the needs of the view under consideration.
2. Represent the behavior of the processes and the assumptions on which the
behavior is based.
3. Explicitly define both exogenous and endogenous input to the model.
4. Exogenous inputs link one constituent of a given view with other constituents at
the same level of other levels; endogenous input links individual components of
a constituent at a particular view.
5. Represent all linkages (including output) that will enable the engineer to better
understand the view.

To construct a system model, the engineers should consider a number of restraining

factors: “Read examples of each in book page# 127.”
1. Assumptions that reduce the number of possible permutations and variations,
thus enabling a model reflect the problem in a reasonable manner.
2. Simplifications that enable the model to be created in a timely manner.
3. Limitations that help to bound the system.
4. Constraints that will guide the manner in which the model is created and the
approach taken when the model is implemented.
5. Preferences that indicate the preferred architecture for all data, functions, and
technology.

6.3 Business Process Engineering: An Overview

 6-4 SEPA, 6/e Instructor’s Guide

The goal of Business Process Engineering (BPE) is to define architectures that will enable a
business to use information effectively.
BPE is one process for creating an overall plan for implementing the computing
architecture.
Three different architectures must be analyzed and designed within the context of
business objectives and goals:
 Data architecture
 Application architecture
 Technology infrastructure

The data architecture provides a framework for the information needs of a business. The
building blocks of the architecture are the data objects that are used by the business.
Once a set of data objects is defined, their relationships are identified. A relationship
indicates how objects are connected to one another.

The application architecture encompasses those elements of a system that transform

objects within the data architecture for some business purpose.

The technology infrastructure provides the foundation for the data and application
architectures. The infrastructure encompasses the h/w and s/w that are used to support
the applications and data.

The complete
System analysis
product
(World view)

capabilities

hardware software
Component
engineering
(Domain view)

Processing requirement

function behavior Analysis & Design

data
Modeling
(Element view)

program
component Software
Engineering

Construction
&
Integration
(Detailed view)
 Chapter Comments 6-5

6.4 Product Engineering: An Overview

Emphasize that software engineers participate in all levels of the product engineering
process that begins with requirements engineering. The analysis step maps
requirements into representations of data, function, and behavior. The design step maps
the analysis model into data, architectural, interface, and software component designs.

6.5 System Modeling with UML

 In terms of the data that describe the element and the operations that manipulate the
data Deployment diagrams
 Each 3-D box depicts a hardware element that is part of the physical
architecture of the system
 Activity diagrams
 Represent procedural aspects of a system element
 Class diagrams
 Represent system level elements

CLSS processor

Sorting subsystem Operator display

Sensor data
shunt controller
acquisition subsystem

Conveyor Bar code reader Shunt actuator

Pulse tach
6-6 SEPA, 6/e Instructor’s Guide

st art c onveyor line

read bar c ode get c onveyor speed

valid bar code invalid bar code

det er mine bin loc at ion set f or rejec t bin

send shunt
c ont rol dat a

get shunt st at us read bar c ode get c onveyor st at us

produc e report ent ry

conveyor stopped conveyor in motion

 Chapter Comments 6-7

class name

Box
attributes
barcode note use of capital
forwardSpeed letter for multi-word
conveyorLocation attribute names
height
width
depth
weight
contents
operations
(parentheses at end
readBarcode() of name indicate the
updateSpeed () list of attributes that the
readSpeed() operation requires)
updateLocation()
readLocation()
getDimensions()
getWeight()
checkContents()