The Information Domain
11.3.1 The Information Domain
All software applications can be collectively called data processing. Interestingly, this term contains a key to our understanding of software requirements. Software is built
6 Only a small subset of Davis’s requirements engineering principles are noted here. For more information, see [DAV95a].
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
to process data, to transform data from one form to another; that is, to accept input, manipulate it in some way, and produce output. This fundamental statement of objec- tive is true whether we build batch software for a payroll system or real-time embed- ded software to control fuel flow to an automobile engine.
It is important to note, however, that software also processes events. An event represents some aspect of system control and is really nothing more than Boolean
The information data—it is either on or off, true or false, there or not there. For example, a pressure domain of a problem
encompasses data sensor detects that pressure exceeds a safe value and sends an alarm signal to mon- items or objects that
itoring software. The alarm signal is an event that controls the behavior of the sys- contain numbers, text, tem. Therefore, data (numbers, text, images, sounds, video, etc.) and control (events) images, audio, video,
both reside within the information domain of a problem. or any combination of
these. The first operational analysis principle requires an examination of the information domain and the creation of a data model. The information domain contains three dif- ferent views of the data and control as each is processed by a computer program: (1) information content and relationships (the data model), (2) information flow, and (3) information structure. To fully understand the information domain, each of these views should be considered.
Information content represents the individual data and control objects that consti- To begin your
tute some larger collection of information transformed by the software. For exam- understanding of the
information domain, ple, the data object, paycheck, is a composite of a number of important pieces of the first question to be
data: the payee's name, the net amount to be paid, the gross pay, deductions, and so asked is: “What
forth. Therefore, the content of paycheck is defined by the attributes that are needed information does this
to create it. Similarly, the content of a control object called system status might be system produce as
output?” defined by a string of bits. Each bit represents a separate item of information that indicates whether or not a particular device is on- or off-line.
Data and control objects can be related to other data and control objects. For exam- ple, the data object paycheck has one or more relationships with the objects time- card, employee, bank, and others. During the analysis of the information domain, these relationships should be defined.
Information flow represents the manner in which data and control change as each moves through a system. Referring to Figure 11.3, input objects are transformed to intermediate information (data and/or control), which is further transformed to out- put. Along this transformation path (or paths), additional information may be intro- duced from an existing data store (e.g., a disk file or memory buffer). The transformations applied to the data are functions or subfunctions that a program must perform. Data and control that move between two transformations (functions) define the interface for each function.
Information structure represents the internal organization of various data and con- trol items. Are data or control items to be organized as an n-dimensional table or as
a hierarchical tree structure? Within the context of the structure, what information is related to other information? Is all information contained within a single structure or
F I G U R E 11.3
Information flow and
Output transformation
Input
Intermediate
object(s)
Transform
data and control
Transform object(s)
Data/control store
are distinct structures to be used? How does information in one information struc- ture relate to information in another structure? These questions and others are answered by an assessment of information structure. It should be noted that data structure, a related concept discussed later in this book, refers to the design and imple- mentation of information structure within the software.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more