Creating an Entity/Relationship Diagram
12.6.1 Creating an Entity/Relationship Diagram
The entity/relationship diagram enables a software engineer to fully specify the data objects that are input and output from a system, the attributes that define the prop- erties of these objects, and their relationships. Like most elements of the analysis model, the ERD is constructed in an iterative manner. The following approach is taken:
? 1. During requirements elicitation, customers are asked to list the “things” that
What steps
are required
the application or business process addresses. These “things” evolve into a
to build an ERD?
list of input and output data objects as well as external entities that produce or consume information.
2. Taking the objects one at a time, the analyst and customer define whether or not a connection (unnamed at this stage) exists between the data object and other objects.
3. Wherever a connection exists, the analyst and the customer create one or more object/relationship pairs.
4. For each object/relationship pair, cardinality and modality are explored.
5. Steps 2 through 4 are continued iteratively until all object/relationships have been defined. It is common to discover omissions as this process continues. New objects and relationships will invariably be added as the number of iter- ations grows.
6. The attributes of each entity are defined.
7. An entity relationship diagram is formalized and reviewed.
8. Steps 1 through 7 are repeated until data modeling is complete. To illustrate the use of these basic guidelines, the SafeHome security system exam-
ple, discussed in Chapter 11, will be used. Referring back to the processing narrative
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 12.18
Control panel Sensor
for SafeHome (Section 11.3.3), the following (partial) list of “things” are relevant to the problem:
• homeowner • control panel • sensors • security system • monitoring service
Taking these “things” one at a time, connections are explored. To accomplish this, each object is drawn and lines connecting the objects are noted. For example, refer- ring to Figure 12.18, a direct connection exists between homeowner and control panel, security system, and monitoring service. A single connection exists between sensor and security system, and so forth.
Once all connections have been defined, one or more object/relationship pairs are identified for each connection. For example, the connection between sensor and security system is determined to have the following object/relationship pairs:
security system monitors sensor security system enables/disables sensor security system tests sensor security system programs sensor
Each of these object/relationship pairs is analyzed to determine cardinality and modal- ity. For example, considering the object/relationship pair security system monitors sensor, the cardinality between security system and sensor is one to many. The modality is one occurrence of security system (mandatory) and at least one occur- rence of sensor (mandatory). Using the ERD notation introduced in Section 12.3, the
F I G U R E 12.19
Monitors
Developing relationships and cardinality/
Enables/disables
modality Security system
connecting line between security system and sensor would be modified as shown in Figure 12.19. Similar analysis would be applied to all other data objects.
Each object is studied to determine its attributes. Since we are considering the software that must support SafeHome, the attributes should focus on data that must
be stored to enable the system to operate. For example, the sensor object might have the following attributes: sensor type, internal identification number, zone location, and alarm level.
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