Chapter 5CSA 217 Design in Construction Chapter 5 1

CSA Design Challenges Turning a specification for computer software into operational software Links requirements to coding and debugging Top-level design provides a structure that can contain multiple lower-level designs 2

Chapter 5CSA 217 Design mistake Example Bridge fell down because of harmonic ripple 3

Chapter 5CSA 2174

Chapter 5CSA 217 Different Designers produce different design for one system Designs evolve and improve through: – design reviews, –informal discussions, –experience writing the code itself, and – experience revising the code 5

Chapter 5CSA Key Design Concepts Role of complexity Desirable characteristics of designs Levels of design. 6

Chapter 5CSA 217 Project Failure Projects fail most often because of –Poor requirements, –Poor planning, or –Poor management –Technical reasons uncontrolled complexity 7

Chapter 5CSA 217 Importance of Managing Complexity the complexity of a problem is reduced by dividing the system into subsystems. Humans understand several simple pieces of information than one complicated piece. The goal of design techniques is to break a complicated problem into simple pieces. More independent the subsystems lead to focusing on one bit of complexity at a time 8

Chapter 5CSA 217 Desirable Characteristics of a Design 1) Minimal complexity –Minimize complexity –Make "simple" and "easy-to-understand" designs –Design should allow you safely ignore of the program when you're working with one specific part. 2) Ease of maintenance –Designing for the maintenance programmer. –Continually imagine the questions a maintenance programmer would ask about the code you're writing 9

Chapter 5CSA 217 Desirable Characteristics of a Design … continue 3) Loose coupling –Connections between the different parts of a program is minimum. –Minimizes work during integration, testing, and maintenance. 4) Extensibility –a piece of a system can be changed without affecting other pieces 10

Chapter 5CSA 217 Desirable Characteristics of a Design … continue 5) Reusability –reuse pieces of the system in other systems. 6) Portability –can easily move the system to another environment 11

Chapter 5CSA 217 Levels of Design Several different levels of detail in a software system is required. –Level 1: Software System –Level 2: Division into Subsystems or Packages –Level 3: Division into Classes –Level 4: Division into Routines –Level 5: Internal Routine Design 12

Chapter 5CSA 21713

Chapter 5CSA 217 Level 1: Software System The first level is the entire system Higher level combinations of classes, such as subsystems or packages 14

Chapter 5CSA 217 Level 2: Division into Subsystems or Packages Identification of all major subsystems deciding how to partition the program into major subsystems defining how each subsystem is allowed to use each other subsystem Within each subsystem, different methods of design might be used rules about how the various subsystems can communicate 15

Chapter 5CSA 217 Subsystems should not communicate with all other subsystems Communication must be restricted Which of the following design is more simple and convenient … 16

Chapter 5CSA 217 This 17

Chapter 5CSA 217 Or this 18

Chapter 5CSA 217 In the first figure, designer can not: change something in the graphics subsystem unless he understands different parts put a new user interface put data storage on a remote machine 19

Chapter 5CSA 217 Common Subsystems Some kinds of subsystems appear regularly in different systems –Business rules : laws, regulations, policies, and procedures that you encode into a computer system –User interface : subsystem to isolate user-interface components –System dependencies: Package operating- system dependencies into a subsystem. –Database access : hide the implementation details of accessing a database. database design structure should be changed without changing most of the program 20

Chapter 5CSA 217 Level 3: Division into Classes identifying all classes in the system the ways in which each class interacts with the rest are specified the aim is making sure that all the subsystems have been decomposed to be implemented as individual classes 21

Chapter 5CSA 21722

Chapter 5CSA 217 Level 4: Division into Routines dividing each class into routines or functions This level of decomposition and design is often left up to the individual programmer, 23

Chapter 5CSA 217 Level 5: Internal Routine Design detailed functionality of the individual routines left to the individual programmer working on an individual routine The design consists of activities such as – writing pseudocode, –looking up algorithms in reference books, –deciding how to organize the paragraphs of code in a routine, and –writing programming-language code 24

Chapter 5CSA 21725

Chapter 5CSA Design Building Blocks Find Real-World Objects The steps in designing with objects are: Identify the objects and their attributes (methods and data). Determine what can be done to each object. Determine what each object is allowed to do to other objects. Determine the parts of each object that will be visible to other objects—which parts will be public and which will be private. Define each object's public interface. These steps aren't necessarily performed in order, and they're often repeated. Each of these steps is summarized below. 26

Chapter 5CSA 217 Computer programs are usually based on real-world entities. Example: you could base a time-billing system on real-world employees, clients, timecards, and bills.  Identify the objects and their attributes 27

Chapter 5CSA 217 Computer programs are usually based on real-world entities. Example: you could base a time-billing system on real-world employees, clients, timecards, and bills.  Identify the objects and their attributes 28

Chapter 5CSA 217  This billing system is composed of four major objects. The objects have been simplified for this example 29

Chapter 5CSA 217 Identifying the objects' attributes is no more complicated than identifying the objects themselves. Each object has characteristics that are relevant to the computer program. For example, in the time-billing system, an employee object has a name, a title, and a billing rate. A client object has a name, a billing address, and an account balance. A bill object has a billing amount, a client name, a billing date, and so on. Objects in a graphical user interface system would include windows, dialog boxes, buttons, fonts, and drawing tools. 30

Chapter 5CSA 217 A variety of operations can be performed on each object. In the billing system, an employee object could have a change in title or billing rate, a client object could have its name or billing address changed, and so on.  Determine what can be done to each object 31

Chapter 5CSA 217 This step is just what it sounds like. The two generic things objects can do to each other are containment and inheritance. Which objects can contain which other objects? Which objects can inherit from which other objects? In in the time-billing system, a timecard object can contain an employee object and a client object, and a bill can contain one or more timecards. In addition, a bill can indicate that a client has been billed, and a client can enter payments against a bill. A more complicated system would include additional interactions.  Determine what each object is allowed to do to other objects 32

Chapter 5CSA 217 One of the key design decisions is identifying the parts of an object that should be made public and those that should be kept private. This decision has to be made for both data and methods.  Determine the parts of each object that will be visible to other objects 33

Chapter 5CSA 217 Define the formal, syntactic, programming- language-level interfaces to each object. The data and methods the object exposes to every other object is called the object's "public interface." The parts of the object that it exposes to derived objects via inheritance is called the object's "protected interface."  Define each object's interfaces 34

Chapter 5CSA 217 Define the formal, syntactic, programming- language-level interfaces to each object. The data and methods the object exposes to every other object is called the object's "public interface." The parts of the object that it exposes to derived objects via inheritance is called the object's "protected interface."  Define each object's interfaces 35