Program Components and Interfaces
22.3.3 Program Components and Interfaces
An important aspect of software design quality is modularity; that is, the specification of program components (modules) that are combined to form a complete program. The object-oriented approach defines the object as a program component that is itself linked to other components (e.g., private data, operations). But defining objects and operations is not enough. During design, we must also identify the interfaces between objects and the overall structure (considered in an architectural sense) of the objects.
Although a program component is a design abstraction, it should be represented in the context of the programming language used for implementation. To accom- modate OOD, the programming language to be used for implementation should be capable of creating the following program component (modeled after Ada):
PACKAGE program-component-name IS TYPE specification of data objects
PROC specification of related operations . . . PRIVATE data structure details for objects PACKAGE BODY program-component-name IS PROC operation.1 (interface description) IS
END PROC operation.n (interface description) IS
END END program-component-name
Referring to the Ada-like PDL (program design language) just shown, a program component is specified by indicating both data objects and operations. The specifi- cation part of the component indicates all data objects (declared with the TYPE state- ment) and the operations (PROC for procedure) that act on them. The private part (PRIVATE) of the component provides otherwise hidden details of data structure and processing. In the context of our earlier discussion, the PACKAGE is conceptually sim- ilar to objects discussed throughout this chapter.
The first program component to be identified should be the highest-level module from which all processing originates and all data structures evolve. Referring once again to the SafeHome example, we can define the highest-level program component as
PROCEDURE SafeHome software The SafeHome software component can be coupled with a preliminary design for the
following packages (objects): PACKAGE system IS
TYPE system data PROC install, define, build, load PROC display, reset, query, modify, call PRIVATE
PACKAGE BODY system IS PRIVATE
system.id IS STRING LENGTH (8); verification phone.number, telephone.number, ... IS STRING LENGTH (8); sensor.table DEFINED
sensor.type IS STRING LENGTH (2), sensor.number, alarm.threshold IS NUMERIC;
PROC install RECEIVES (telephone.number)
{design detail for operation install}
END system PACKAGE sensor IS
TYPE sensor data PROC read, set, test PRIVATE
PACKAGE BODY sensor IS PRIVATE
sensor.id IS STRING LENGTH (8); sensor.status IS STRING LENGTH (8); alarm.characteristics DEFINED
threshold, signal type, signal level IS NUMERIC, hardware.interface DEFINED type, a/d.characteristics, timing.data IS NUMERIC,
CHAPTER 22
OBJECT-ORIENTED DESIGN
END sensor •
END SafeHome software Data objects and corresponding operations are specified for each of the program
components for SafeHome software. The final step in the object design process com- pletes all information required to fully implement data structure and types contained in the PRIVATE portion of the package and all procedural detail contained in the PACK- AGE BODY.
To illustrate the detail design of a program component, we reconsider the sensor package described earlier. The data structures for sensor attributes have already been defined. Therefore, the first step is to define the interfaces for each of the oper- ations attached to sensor:
PROC read (sensor.id, sensor.status: OUT); PROC set (alarm.characteristics, hardware.interface: IN) PROC test (sensor.id, sensor.status, alarm.characteristics: OUT);
The next step requires stepwise refinement of each operation associated with the sensor package. To illustrate the refinement, we develop a processing narrative (an informal strategy) for read:
Stepwise refinement and structured
When the sensor object receives a read message, the read process is invoked. The process
programming
determines the interface and signal type, polls the sensor interface, converts A/D charac-
(Chapter 16) are
teristics into an internal signal level, and compares the internal signal level to a threshold
used at this stage
value. If the threshold is exceeded, the sensor status is set to "event." Otherwise, the sen-
to complete the design of each
sor status is set to "no event." If an error is sensed while polling the sensor, the sensor sta-
operation.
tus is set to "error." Given the processing narrative, a PDL description of the read process can be devel-
oped: PROC read (sensor.id, sensor.status: OUT);
raw.signal IS BIT STRING IF (hardware.interface.type = "s" & alarm.characteristics.signal.type = "B" THEN
GET (sensor, exception: sensor.status := error) raw.signal; CONVERT raw.signal TO internal.signal.level; IF internal.signal.level > threshold
THEN sensor.status := "event"; ELSE sensor.status := "no event";
ENDIF ELSE {processing for other types of s interfaces would be specified} ENDIF RETURN sensor.id, sensor.status;
END read
The PDL representation of the read operation can be translated into the appropriate implementation language. The functions GET and CONVERT are assumed to be avail- able as part of a run-time library.
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