Stumpf and Teague ObjectOriented Systems Analysis and Design

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 Hall 3

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 Hall 4

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 Hall 5

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 Hall 6

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 Hall 7

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 Hall 8

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 Hall 9

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 Hall 10

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 Hall 11

Goals of Design • • • Satisfaction of requirements Performance Constructibility Efficient design process

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 Hall 13

Design Method A design method is an organized procedure for accomplishing a task. It

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 Hall 15

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 Hall 16

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 Hall 17

Strategies for Generating a Design Solution • • Re-use an existing design Modify an

Strategies for Simplifying Design Decisions • • Stepwise refinement Partition the system into subsystems

Design Trade-Offs. © 2005 Prentice Hall 20

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 Hall 21

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 Hall 22

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 Hall 23

Modeling Techniques • Physical: measurable • Mathematical: calculable • Simulation: experimental or observable •

Evaluating Models The four “C’s” of evaluation: 1. Consistency 2. Completeness 3. Correctness 4.

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. © 2005 Prentice Hall 26