PROGRAM DESIGN

PROGRAM DESIGN-project teams rely increasingly on packaged software or libraries of preprogrammed code to build systems.

-Term used to describe software that is bunched together making a complete set. For example,MicrosoftOffice ispackaged software that includes many software programs that may be used in the office, such as Microsoft Excel, Microsoft Word and Microsoft Access.

-Program design techniques are still very important, however, for two reasons. First, even preexisting code needs to be understood, organized, and pieced together.

Second, it is still common for the project team to have to write some (if not all) code and produce original programs that support the application logic of the system.

1OBJECTIVESBe able to revise logical DFDs into physical DFDs.Be able to create a structure chart.Be able to write a program specification.Be able to write instructions using pseudo code.Become familiar with event-driven programming.2RECAP4 Basic Functions of ISDATA STORAGEDATA ACCESS LOGICAPPLICATION LOGICPRESENTATION LOGIC

All software systems can be divided into four basic functions. The first is data storage-Most information systems require data to be stored and retrieved, whether a small file, such as a list of lawn chemicals that are no longer authorized for residential applications, or a large database that stores an organizations human resources records. These are the data entities documented in ERDs.

The second function is the data access logic: the processing required to access data, often meaning database queries in Structured Query Language (SQL). (computing) Structured Query Language; used for managing and querying databases

The third function is the application logic: the logic documented in the DFDs, use cases, and functional requirements.

The fourth function is the presentation logic: the display of information to the user and the acceptance of the users commands (the user interface). These four functions (data storage, data access logic, application logic, and presentation logic) are the basic building blocks of any information system.3Moving from Logical to Physical Process Models

WHY?- systems analysts identified the processes and data flows that are needed to support the functional requirements of the new system.-analysts avoid making implementation decisions during analysis, focusing first on the business requirements of the system.-In this way, developers do not get distracted by technical details and are not biased by technical limitations in the initial stages of system development.

4SPOT THE DIFFERENCE

The physical model, therefore, contains a line separating the customer from the rest of the process to show exactly what is done by a person as opposed to a machine.

-The project team will need to weigh the following criteria when drawing the boundary: cost, efficiency, and integrity.-Exproject team must decide whether to store a paper copy of a document or to save an electronic file of information in a central file server, the team likely will find the latter option to be more efficient in terms of improving the usersability to access and update the information.

the team should consider the integrity of the information that is handled by the system. It may be cheaper for a clerk to record orders by phone and deliver the order forms to the distribution area; however, errors could be made when the clerk takes the order, and a form could be misplaced en route to distribution. Instead, the project team may be more comfortable with an automated process that accepts a customers order from the customer directly, using a Web form that is then directly transmitted to the distribution system5

6

Data stores on physical DFDs will refer to files and/or database tables; processes, to programs or human actions; and data flows, to the physical media for the data, such as paper reports, bar code scanning, input screens, or computer reports.

-Figure 10-2 shows the physical DFD that was drawn to depict the physical details for the original logical DFD from Figure 5-18. Notice how the logical data store called Available Tunes that will store data in the Available Tunes table of a mySQL database has been renamed mySQL: Available Tunes Table and the logical data flow Requested Tunes now includes mySQL: Requested Tunes Record to show that this information will be in the form of a record from the Available Tunes table. Can you identify other changes that were made to the physical model to communicate how other components will be implemented?

-MySQLis a popular choice of database for use in web applications-HTML-A set of tags and rules (conformingto SGML) for using them in developing hypertext documents

IN A NUTSHELL-Physical Process Models These details can include references to actual technology, the format of information moving through processes, and the human interaction that is involved.

7STEPS

Metadata===Data about data8APPLICATIONTune Source promote tunes process

First, we need to identify how the data flows, data stores, and processes will be implemented and add the implementation references on the DFD. From the original business requirements, we know that the marketing managers will receive reports on customer interests and tune sales via the Web. The marketing managers will submit information on promotions that will be displayed on the Web site. The marketing managers will also submit promotions that will be sent to customers via e-mail.9

Step 1Add Implementation References Let us assume that the data stores (i.e., customer interests, sales, targeted promotions, and customer) will refer to tables called customer interests, sales, targeted promotions, and customers, respectively, that are contained in a MySQL database; therefore, all four stores are updated with this information to indicate their physical qualities. Also, the promote tunes process will be written in Visual Basic (VB), and this information is added to the process model.10

Let us assume that the data stores (i.e., customer interests, sales, targeted promotions, and customer) will refer to tables called customer interests, sales, targeted promotions, and customers, respectively, that are contained in a MySQL database; therefore, all four stores are updated with this information to indicate their physical qualities. Also, the promote tunes process will be written in Visual Basic (VB), and this information is added to the process model.

11

Step 2Draw a human machine boundarySeparate Human action vs. automated12

Separate Human action vs. automated13

Step 3Add System-relatedData Stores, Data Flows,and ProcessesIn step 3, you will add to the DFD additional processes, stores, or flows that are specific to the implementation of the system and have little (or nothing) to do with the business process itself. These additions can be due to technical limitations or to the need for audits, controls, or exception handling.

For example, suppose that a data store exists on the logical DFD to hold customer information, but the database technology that will be used to build the system cannot handle the large volume of customers in one table. A physical DFD may need to have two data storesone for current customers and one for old customersso that the technology will work properly.

Audits, controls, or exception handling refers to putting checks and balances in place in the system in case something goes wrong. For instance, on rare occasions, customers might call and cancel an order that they placed. Instead of just having the system get rid of the information about that order, a process may be included for control purposes that records the deleted orders along with reasons for the cancellations.

14

15

FOR THE PROMOTION OF TUNE SOURCELet us assume that a separate Access database is going to be maintained that includes records on e-mail promotion messages sent to customers. This database may be used by the marketing managers to analyze the effectiveness of their e-mail promotional campaigns. So, we add a data store to the diagram to reflect this decision. See Figure 10-4 for these changes.16

Step 4Update the Data Elements in the Data Flowsthe elements in the data flows. The data flows will appear to be identical in both the logical and physical DFDs, but the physical data flows may contain additional system-related data elements, for reasons similar to those described in the previous section. For example, most systems add system-related data elements to data flows that capture when changes were made to information (e.g., a last_update data element) and who made the change (e.g., an updated_by data element). Another physical data element is a system-generated number used to uniquely identify each record in a database. During step 4, the physical data elements are added to the metadata descriptions of the data flows in the CASE repository.

17

FOR THE TUNE SOURCEFor example, we will create a system-related data element called date-added and add it to the data flow that goes from process 3 to the targeted promotions data store. This field will capture the time a piece of promotional material was inserted in the system.

18

Step 5Update the Metadata in the Computer-Aided Software Engineering RepositoryStep 5: Update the Metadata in the Computer-Aided Software Engineering Repository

(2)In aCASEdevelopment system, a database of information about thesoftware, including data elements, processes, inputs, outputs and interrelationships. A CASE system uses a repository to identify objects and rules for reuse.

Finally, the project team needs to make sure that the information about the DFD components in the CASE repository is updated with implementation-specific information. This information can include when batch processes will be run and how often, names of the actual tables or files that are represented by data flows, and the sizes and projected growth rates of the data stores.

For the example:Step 5 requires that we add implementation-specific information in the metadata in the CASE repository. This can include such information as the actual field types and sizes of the data elements that will be stored in the tables, or the expected response time for a report to be created for the marketing manager.19

Why cant we jump into implementation phase?20

It can be tempting to jump right into the implementation phase by coding without much thought or planning, but this can lead to disastrous results, such as inefficient programs, code that does not work with other code, and a system that doesnt do what its supposed to do. Instead, analysts should first take time in the design phase to create a maintainable system. In other words, analysts should create a design that is modular and flexible.

Modular-Constructed with standardized units or dimensions allowing flexibility and variety inuse21

GIVING DIRECTIONTo do this, analysts can design programs in a top-down modular approach,

Think about giving someone directions to your house (Figure 10-5). Before getting to the details, such as naming streets and identifying landmarks, it is best to first orient the person to your general location (e.g., the state you live in, the part of town). As he or she becomes comfortable with where to go at a high level, you can become more detailed in your instructions. This top-down approach helps orient the other person and conveys the big picture of where you live, making the detailed directions much easier to understand.Also, directions can be communicated in modules: First, drive from your house to the highway.Then, drive from the highway to the appropriate exit. Next, locate my neighborhood.Finally, drive to my house.traveling from the south, it is likely that the last two modules of directions (i.e., to the neighborhood and to the house) will not change even though the first two modules will differ for each friend. The modular approach makes the directions much easier to develop and change.

Good program design is similar to the top-down modular approach that we described. First, analysts create a high-level diagram that shows the various components of a program, how the components should be organized, and how the components interrelate. This diagram, known as the structure chart, illustrates the organization and interactions of the different pieces of code within the program to the analysts and programmers so that the program can be developed by many programmers working independently. The diagram can be used when the project team plans to write code from scratch or when existing pieces of code will be assembled to build the system. The physical process models just described provide a good starting point for understanding what this structure chart needs to include.Once the overall program is defined at a high level, with a structure chart, program specifications are written to describe exactly what needs to be included in each program module. The specifications include basic module information (e.g., a name, calculations that need to be performed, and the target programming language), special instructions for the programmer, and pseudocode.

22

How to make a good program design?23PPT retrieved fromhttps://www.ce.yildiz.edu.tr/personal/gurkan/file/9101/StructureCharts.pptSTRUCTURE CHARTS24Structure ChartsAgenda:Use of Structure ChartsSymbolsHow to create25Structure Chart UseDescribe functions and sub-functions of each part of system (in more detail than a DFD)

Show relationships between common and unique modules of a computer program

Hierarchical, Modular structureEach layer in a program performs specific activitiesEach module performs a specific function

26Structure Chart symbols representModules(sequential logic)Conditions (decision logic)Loops(iterative logic)Data couplesControl couplesStructure Chart Symbols27

Structure Chart - ModuleRectangle represents a module (program or subroutine)Control Modules (mainline) branch to sub-modulesLibrary modules are reusable and can be invoked from more than one Control Module elsewhere in the system28

Structure Chart - Data Couple Arrow with an empty circle Shows the data one module passes to another29Structure Chart - Control Couple

Arrow with filled circle Shows a message (flag) which one module sends to another Module uses a flag to signal a specific condition or action to another module

30Structure Chart - Condition

A line with a diamond Indicates that a control module determines which subordinate module will be invoked31

Structure Chart - Loop A curved arrow representing a loop One or more modules are repeated32Structure Chart for Calculate Pay Amount RoutineFigure 9-9

33Structure Chart for Entire Calculate Payroll ProgramFigure 9-11

34Steps in drawing a structure chart

Identify the top-level modules and then decompose them into lower levelsIdentify modules and relationshipsAdd couples, loops, and conditionsAnalyze the structure chart, the DFDs, and the data dictionary

Example: Order System DFD Order System Structure Chart Creating a structure chart is usually a four-step process. First, the analyst identifies the top-level modules and then decomposes them into lower levels. (This process is similar in some ways to identifying high-level processes in a DFD and then decomposing them into lower-level processes.) Second, the analyst adds the control connections among modules, such as loops and conditional lines that show when modules call subordinates. Third, he or she adds couples, the information that modules pass among themselves. Finally, the analyst reviews the structure chart and revises it again and again until it is complete.35APPLICATIONTune Source

The various levels of the DFD generally translate into different levels of the structure chart. Look back at the DFDs that we created for Tune Source in Chapter 5 (Figures 5-15 through 5-20). The context-level DFD (the overall system) is placed at the top of the structure chart in Figure 10-11 to represent the overall control module of the system that manages the highest level of system functions. Then, the level 0 DFD processes are placed below it as subordinates. You should recognize that this particular structure of modules is a transaction structure, because the subordinates represent different functions that can be called by the control module

Example:This pattern continues through all the DFD levels. For example, the level 1 DFD that we created for the search and browse tunes process is placed below the search and browse tunes process control module. The subordinate modules are load Web site, process search requests, and process tune selection, the three processes from the search and browse tunes process level 1 DFD. Note that this structure of modules is a transform structure because the subordinate modules are carried out in a sequence to perform the process that is represented by the control module, search and browse tunes (Figure 10-11).

Likely, you will need to include additional levels of detail to the structure chart, until modules have enough detail so that they each perform only one function. Additional detail for the structure can be found within the use cases (Chapter 4) and requirements definition (Chapter 3) for the system. For example, if you read the use case for the search and browse tunes process in Figure 4-14, notice that step 3 includes listening to a sample, adding the tune to the Favorites list, and selecting the tune to buy. Modules have been added to the last row of Figure 10-11 to reflect our detailed understanding of these processes.Finally, you must determine whether any modules on the diagram are reusable; if they are, they should be represented as library modules. In this particular portion of the structure chart, Jason has marked two modules as library modules, with vertical lines on the sides. He believes that these modules currently exist in the CD sales system and can be reused in this system.36APPLICATIONTune Source

The next step is to add loops and conditional lines to represent modules that are repeated or optional. For example, a customer of the Digital Music Download system can search for multiple tunes. Thus in Figure 10-12, we place a curved arrow around the line under the search and browse tunes process to show that modules 1.1.1 through 1.1.3 can be repeated several times. Can you think of other modules on the structure chart that will be iterated? According to Figure 10-12, one module under the process payment process also can happen several times before the system will accept payment information from the customer.A diamond is placed below a control module that directs subordinates, which may or may not be performed. For example, customers may choose to listen to a tune sample, add it to the Favorites list, or buy itthey do not necessarily use all three alternatives. So a diamond is added below the process tune selection module to communicate this to the programmer. What other part of the structure chart contains subordinates that are invoked conditionally?37

APPLICATIONTune Source

Next, we must identify the information that has to pass among the modules. This information can be data attributes (denoted by an arrow with an empty circle) or special control parameters (denoted by an arrow with a filled-in circle). The arrowheads on the arrows indicate which way information is passed along.The DFD data flows provide us with some guidance about the couples to add, because the information that flows in and out of the DFD processes likely will also flow in and out of the corresponding structure chart modules.We will illustrate the addition of couples to our structure chart by focusing just on the purchase tunesmodule and its subordinate modules. The DFD in Figure 5-19 shows that a new customer can provide customer information or can access existing customer information by signing in to his or her account. Therefore, one module on our structure chart (1.2.1) returns customer details for new customers, and one module (1.2.2) returns customer details for customers having existing accounts. The driver module (1.2 Purchase Tunes) calls the correct subordinate, depending on the existence of a customer account for the customer. The driver module then calls the process paymentmodule (1.2.3). This module repeatedly calls its subordinate module, gather purchased tunes (1.2.3.1), to find all tunes the customer wants to purchase. These are then passed to the compute amount due module (1.2.3.2), which returns that result. Library module accept payment info (1.2.3.3) returns the customers payment information, which is then used by the get payment authorization library module (1.2.3.4). A control couple is returned by that module, indicating the result of the authorization step. The process paymentmodule (1.2.3) returns the authorized payment data couple to its parent module, purchase tunes (1.2). The purchase tunes module calls the confirm purchase module (1.2.4) to obtain the customers purchase confirmation, shown as a control couple. Finally, information about the purchased tune(s) is passed to the release downloadmodule (1.2.5) to complete the customers purchase.

Revise Structure Chart By now we have created the initial version of the structure chart based on the DFDs, use cases, and requirements definition, but rarely is a structure chart completed in one attempt.

There are many gray areas and decisions that need to be confirmed by other information gleaned during analysis. There are several tools that can help when we are fine-tuning the structure chart. First, we can look at the process descriptions in the CASE repository to see whether there are any details of the processes that havent yet been captured on the diagram. The process descriptions may uncover couples that were overlooked or explain more about how modules should be broken down. Second, we can examine the data model to confirm that the right records and specific fields have been passed using the data couples. This exercise also will confirm that data being passed are actually being captured by the system.As with most diagrams about which you have learned, the structure chart will evolve and contain more detail as new information is uncovered over the course of the project. Structure charts are not easy. The example that we have presented is much more straightforward than charts found in the real world. The following section explains some guidelines and good practices that you should apply to the chart as you work to improve it:38SummaryShow the relationships among program modulesStructure Chart consists of:Modules - Related program code organized into small units that are easy to understand and maintainData couples - Data passed between modules Control couples - Data passed between modules that indicates a condition or action to another moduleConditions - determines what subordinate module a control module will runLoops - Indicates one or more subordinate modules are repeatedStructure Charts are based on the DFD and Data Dictionary

39

Be able to revise logical DFDs into physical DFDs.Be able to create a structure chart.*Structure Chart*Building Structure Chart*Structure Chart Design GuidelinesBe able to write a program specification.Be able to write instructions using pseudo code.Become familiar with event-driven programming.44DESIGN GUIDELINESHigh quality structure charts result in programs that are modular, reusable, and easy to implement

HOW?46

Rule #1 Build modulesWithHigh Cohesion-Cohesion-well integrated-Make one module do one task,,,more task more complex, ex: and-the lines of code within each structure chart module must relate to each other47

-if our subordinate module were print grade listing and deans list, then a control flag would need to be sent to the subordinate module so that it could determine which report (or both) to print; the subordinate would have to make decisions regarding how to perform its functions.

48Terms to remember:Control flagsFunctional cohesionTemporal cohesionCoincidental cohesionFactoring-presence of control flags that are passed down to subordinate modules; their presence suggests that the subordinate has multiple functions from which one is chosen.

49

Build Loosely Coupled ModulesModules are independent from each other

-changes will not have a rippling effect-Although the modules are communicating with one another, notice that the communication is quite limited (only one data couple passed in and out of the module) and there are no superfluous couples (data that are passed for no reason).-52Types of Coupling

Types of Coupling

Create High Fan-In