Developing the Data Design Model

J.E.D.I method.

4.4.2 Developing the Data Design Model

In developing the Data Design Model, a pattern should be decided on. In the following example, we will use the JDBC Design Pattern to model the Club Membership Maintenance Data Design . STEP 1. Define the static view of the data elements that needs to be persistent. Using the static view of the design pattern, model the classes that collaborate. Figure 4.29 shows the application of the JDBC Design pattern. The DBAthlete class is used to connect and execute SQL statements. It also populates the persistence classes, PCLAthlete , Athlete and Guardian. Software Engineering 164 Figure 4.29 DBAthlete Static View J.E.D.I STEP 2: For all behavior, model the behavior of the classes in a sequence diagram. All the JDBC Dynamic Views should be modeled to determine how the DBClasses and Persistent Classes collaborate using the Sequence Diagrams. The succeeding diagrams illustrates the JDBC Read Figure 4.30, Create Figure 4.31, Update Figure 4.32 and Delete Figure 4.33. Software Engineering 165 Figure 4.30 DBAthlete JDBC Read Figure 4.31 DBAthlete JDBC Create J.E.D.I STEP 3: Document the data design classes. Identify attributes and operations of each class. Examples are shown in Figure 4.34. Software Engineering 166 Figure 4.32 DBAthlete JDBC Update Figure 4.33 DBAthlete JDBC Delete J.E.D.I STEP 4: Modify the software architecture to include the data design classes. It should be on top of the database layer. In simple systems, this becomes part of the business logic layer. You may modify packaging decisions. At this point, entity classes are replaced by the DBClasses, Persistent Classes and Database Design. The modification is shown in Figure 4.35. Software Engineering 167 Figure 4.34 Definition of Athlete DBClasses and Persistent Classes Figure 4.35 Modified Software Architecture from Data Design Model J.E.D.I

4.5 Interface Design

The Interface Design is concern with designing elements that facilitate how software communicates with humans, devices and other systems that interoperate with it. In this section, we will be concentrating on design elements that interact with people, particularly, pre-printed forms, reports and screens. Designing good forms, reports and screens are critical in determining how the system will be acceptable to end-users. It will ultimately establish the success of the system. As software engineers, we would want to decrease emphasis on reports and forms and we want to increase emphasis on the screen. When do we use reports? • Reports are used for audit trails and controls. • Reports are used for compliance with external agencies. • Reports are used if it is to voluminous for on-line browsing. When do we use forms? • Forms are used for turnaround documents. • Forms are used if personnels need to do the transaction but does not have access to workstations. • Forms are used if they are legally important documents. When to use Screens? • Screens are used to query a single record from a database. • Screens are used for low volume output. • Screens are used for intermediate steps in long interactive process.

4.5.1 Report Design

Reports can be placed on an ordinary paper, continuous forms, screen-based or microfilm or microfiche. The following gives the steps in designing reports. Report Design Consideration 1. Number of Copies and Volume. There should be a balance between the number of copies generated with the number of pages. • How many copies of the report will be generated? • On the average how many pages will be generated? • Can the user do without the report? • How often to do the user file a copy? Is it really needed? 2. Report Generation Software Engineering 168