© 2005 Prentice Hall6-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

© 2005 Prentice Hall6-2 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.

© 2005 Prentice Hall6-3 Learning Objectives Identify similarities in the concerns of all designers regardless of their specific discipline. Summarize some different perspectives on the nature of design. Explain how design differs from requirements analysis and construction. Give some reasons for design.

© 2005 Prentice Hall6-4 Learning Objectives (continued) Define design as used in textbook. Discuss why it is important to have a design method when developing systems. Name and explain some strategies for generating design solutions, simplifying design decisions, evaluating designs, and terminating the search for alternatives. Discuss the purpose of design models and the principal categories of design models.

© 2005 Prentice Hall6-5 Overview Design is a critical intermediate step between a statement of requirements and the construction of a solution. It produces a description of the solution – not the solution itself. This description is sufficiently complete and accurate to assure that the solution can be constructed. Design models allow the behavior of proposed solutions to be evaluated and compared.

© 2005 Prentice Hall6-6 Overview (continued) Designers in a variety of disciplines and domains draw on fundamental design principles and concepts. Information system designers can learn much from the experience of those in other design domains. Design methods organize the design process and guide it to a successful outcome.

© 2005 Prentice Hall6-7 What Is Design? Innovation and creativity Concerned with the artificial Source of change Problem solving Decision making Modeling Planning Learning An intermediary between requirements and construction

© 2005 Prentice Hall6-8 What Is Design? (continued) Design is a process which creates descriptions of a newly devised artifact. Design is also the product of the design process – a description which is sufficiently complete and detailed to assure that the artifact can be built.

© 2005 Prentice Hall6-9 Why Design? The desired artifact or system does not exist. People cannot wait for gradual evolution. Complex systems require multidisciplinary teams and shared design processes. It is risky and expensive to construct without a plan.

© 2005 Prentice Hall6-10 Why Design? (continued) To model and predict system performance. Alternatives can be compared to select the best. Complex systems need multidisciplinary teams and shared design processes.

© 2005 Prentice Hall6-11 Why Design? (continued) It is less expensive to test, predict, and evaluate during design than after construction. The cost of detecting and correcting errors increases as the process of creating an artifact unfolds.

© 2005 Prentice Hall6-12 Goals of Design Satisfaction of requirements Performance Constructibility Efficient design process Personal preferences and objectives

© 2005 Prentice Hall6-13 Emphases of Good Design A design which fits the structure of the problem A system which is easy to understand, modify, and maintain Models which use graphic representations Explicit criteria for refining and improving an initial design

© 2005 Prentice Hall6-14 Design Method A design method is an organized procedure for accomplishing a task. It marshals the resources of participants in the process to achieve an effective result.

© 2005 Prentice Hall6-15 Roles of a Design Method 1.To provide a conceptual framework for understanding the design process and for communicating that understanding to the participants 2.To guide the design process to a successful outcome for a single design project 3.In some cases, to provide a strategy for selecting, sequencing, and coordinating multiple projects

© 2005 Prentice Hall6-16 Goals of a Design Method 1.An acceptable result 2.A product of adequate quality 3.Specific steps or procedures which allocate appropriate models and techniques to the activities and decisions of the design process 4.Well-defined roles and tasks for the participants in design – both technical and managerial 5.Compatibility of the design with the goals of the using organization

© 2005 Prentice Hall6-17 A General Design Method 1.Define the objectives of the design. 2.State the problem, defining its constraints. Repeat until a solution is found: 3.Generate a tentative solution. 4.Test the solution for feasibility.

© 2005 Prentice Hall6-18 Strategies for Generating a Design Solution Re-use an existing design Modify an existing design Synthesis Direct design

© 2005 Prentice Hall6-19 Strategies for Simplifying Design Decisions Stepwise refinement Partition the system into subsystems at critical interfaces

© 2005 Prentice Hall6-20 Design Trade-Offs.

© 2005 Prentice Hall6-21 Strategies for Terminating the Search for Solutions Satisficing – accept the first feasible solution. Optimizing – accept only a solution which is better than or at least equal to all other solutions. Adaptavizing – stop searching when the estimated cost of generating another solution exceeds the estimated improvement in the value of the solution.

© 2005 Prentice Hall6-22 Design Patterns Recent practice in program design makes extensive use of patterns. (See Chapter 8.) A pattern is a statement of a design problem together with an appropriate solution to that problem.

© 2005 Prentice Hall6-23 Design Models Design models can: Simplify complexity. Calculate or simulate the expected performance of the artifact or system. Manipulate and alter the relationships between the components of the system.

© 2005 Prentice Hall6-24 Modeling Techniques Physical: measurable Mathematical: calculable Simulation: experimental or observable Conceptual analogies

© 2005 Prentice Hall6-25 Evaluating Models The four “C’s” of evaluation: 1.Consistency 2.Completeness 3.Correctness 4.Communicability

© 2005 Prentice Hall6-26 Summary Designers in all disciplines draw on fundamental design concepts and principles. Design is a process which produces a description of a newly devised artifact from which the artifact can be built. Design is dependent on methods and models for a successful outcome.