Data Objects, Attributes, and Relationships
12.3.1 Data Objects, Attributes, and Relationships
The data model consists of three interrelated pieces of information: the data object, the attributes that describe the data object, and the relationships that connect data objects to one another.
Relationships: Data objects, attributes and
F I G U R E 12.2
Address Age Driver's license Number
owns
Make Model ID number Body type Color
Data objects. A data object is a representation of almost any composite informa- tion that must be understood by software. By composite information, we mean some- thing that has a number of different properties or attributes. Therefore, width (a single value) would not be a valid data object, but dimensions (incorporating height, width,
A data object is a and depth) could be defined as an object. representation of any
A data object can be an external entity (e.g., anything that produces or consumes composite information
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) that is processed by
or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., account- computer software. ing department), a place (e.g., a warehouse), or a structure (e.g., a file). For example,
a person or a car (Figure 12.2) can be viewed as a data object in the sense that either can be defined in terms of a set of attributes. The data object description incorporates the data object and all of its attributes.
Data objects (represented in bold) are related to one another. For example, per-
WebRef son can own car, where the relationship own connotes a specific "connection” between
Useful information on person and car. The relationships are always defined by the context of the problem
data modeling can be that is being analyzed. found at
A data object encapsulates data only—there is no reference within a data object
www.datamodel.org
to operations that act on the data. 1 Therefore, the data object can be represented as
a table as shown in Figure 12.3. The headings in the table reflect attributes of the object. In this case, a car is defined in terms of make, model, ID number, body type, color and owner. The body of the table represents specific instances of the data object. For example, a Chevy Corvette is an instance of the data object car.
1 This distinction separates the data object from the class or object defined as part of the object-ori- ented paradigm discussed in Part Four of this book.
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
Ties one data object to another, Tabular
F I G U R E 12.3
Naming
in this case, owner representation of data objects
attributes
Descriptive Referential
Identifier
attributes attributes
Make Model
ID#
Body type Color Owner
Lexus LS400
AB123. . .
Sedan
White RSP
Instance Chevy Corvette X456. . .
Sports
Red CCD
BMW 750iL
XZ765. . .
Coupe White LJL
Ford
Taurus
Q12A45. . . Sedan
Blue BLF
Attributes. Attributes define the properties of a data object and take on one of three different characteristics. They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make reference to another instance in another table.
Attributes name a data In addition, one or more of the attributes must be defined as an identifier—that is, the object, describe its
identifier attribute becomes a "key" when we want to find an instance of the data characteristics, and in
object. In some cases, values for the identifier(s) are unique, although this is not a some cases, make
reference to another requirement. Referring to the data object car, a reasonable identifier might be the ID object.
number. The set of attributes that is appropriate for a given data object is determined through an understanding of the problem context. The attributes for car might serve well for an application that would be used by a Department of Motor Vehicles, but these attri- butes would be useless for an automobile company that needs manufacturing con- trol software. In the latter case, the attributes for car might also include ID number, body type and color, but many additional attributes (e.g., interior code, drive train type, trim package designator, transmission type) would have to be added to make car a meaningful object in the manufacturing control context.
Relationships. Data objects are connected to one another in different ways. Con- sider two data objects, book and bookstore. These objects can be represented using
Relationships indicate the simple notation illustrated in Figure 12.4a. A connection is established between the manner in which
book and bookstore because the two objects are related. But what are the rela- data objects are
tionships? To determine the answer, we must understand the role of books and book- “connected” to one
another. stores within the context of the software to be built. We can define a set of object/relationship pairs that define the relevant relationships. For example,
A bookstore orders books.
A bookstore displays books.
A bookstore stocks books.
A bookstore sells books.
A bookstore returns books.
F I G U R E 12.4
Relationships Book
Bookstore
(a) A basic connection between objects
Orders Displays
Sells Returns
(b) Relationships between objects
The relationships orders, displays, stocks, sells, and returns define the relevant con- nections between book and bookstore. Figure 12.4b illustrates these object/rela- tionship pairs graphically.
It is important to note that object/relationship pairs are bidirectional. That is, they can be read in either direction. A bookstore orders books or books are ordered by a bookstore. 2
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