Software Engineering 2007/2008 Chapter 5 Designing the System.

Slides:



Advertisements
Similar presentations
Lecture 6: Software Design (Part I)
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Lecture # 2 : Process Models
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Information Systems Analysis and Design
1 Chapter 2: Product Development Process and Organization Introduction Importance of human resources: Most companies have similar technology resources.
Outline About author. The problem that discussed in the article.
Object-Oriented Analysis and Design
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
© Copyright 2011 John Wiley & Sons, Inc.
Software Testing and Quality Assurance
Applying Architectural Styles and Patterns. Outline  Defining Architectural Patterns and Style The activation model Styles and Quality Attributes  Common.
Design Creative Process of transferring the problem into a solution
Designing the system Conceptual design and technical design
Fall 2007CS 225 Introduction to Software Design Chapter 1.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
SWE Introduction to Software Engineering
Unified Modeling (Part I) Overview of UML & Modeling
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Chapter 1 Principles of Programming and Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Spring 2009CS 225 Introduction to Software Design Chapter 1.
Course Instructor: Aisha Azeem
CSC230 Software Design (Engineering)
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
CH05: Designing the System To design a system is to determine a set of components and inter-component interfaces that satisfy a specified set of requirements.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Continuation From Chapter From Chapter 1
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system design 1 what is systems design? preparation of the system’s specifications with.
Lesson 7 Guide for Software Design Description (SDD)
Chapter 2 The process Process, Methods, and Tools
An Introduction to Software Architecture
ITEC 3220M Using and Designing Database Systems
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
10 Software Architecture CSCU 411 Software Engineering.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
SE: CHAPTER 7 Writing The Program
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Cohesion and Coupling CS 4311
1 Introduction to Software Engineering Lecture 1.
GRASP: Designing Objects with Responsibilities
Design Concepts By Deepika Chaudhary.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
CMSC 345 Fall 2000 Design Issues. Modularity and Abstraction Characteristic of all design methods Components have clearly defined inputs and outputs,
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Conceptual design Tells the customer what the system will do Tells the customer what the system will do Answers: Answers: Where will the data come from?
Feb. 9, 2004CS WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004.
The Software Development Life Cycle: An Overview
1 Week 6 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
Chapter : 9 Architectural Design
Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Principles of Programming & Software Engineering
7. Modular and structured design
Chapter ? Quality Assessment
System Design and Modeling
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
An Introduction to Software Architecture
PPT and video are due no later than February 15, 2019
Presentation transcript:

Software Engineering 2007/2008 Chapter 5 Designing the System

Learning objectives  Explain the difference between a conceptual( 概念 ) design and technical design, and the reasons why each is useful for software development  Describe an overview of important design styles, techniques and tools, and the conditions under which different choices may be appropriate( 适当的 )  Identify the characteristics of “ good software ”.  Explain why validating( 确认 ) designs is necessary, and a general overview of how this task can be accomplished  Explain how to usefully document a design

5.1 WHAT IS DESIGN?  Design is the creative( 创造 ) process of transforming the problem into a solution; the description of a solution is also called design..  A conceptual design( 总体设计 ) or system design that tells the customer exactly what the system will do  Technical design is that system builders translate the conceptual design into a much more detailed document FIGURE 5.1 Conceptual and technical designs.

5.1 WHAT IS DESIGN?  a description of the major hardware components( 硬件部件,硬件成分 ) and their functions . the hierarchy( 层次 ) and function of the software components( 软件构件, 软件成分 ) . the data structures( 数据结构 ) and the data flow( 数据流 )

5.2 DECOMPOSITION AND MODULARITY  Wasserman (1995) suggests that designs are created in one of five ways: Modular decomposition( 模型分解 ) Data-oriented decomposition Even-oriented decomposition Outside-in design ( 从外侧向内侧的 ) Object-oriented design No matter the design approach, each kind of decomposition separates( 分开的 ) the design into its composite( 合成的 ) parts, called modules( 模块 ) or components( 组件, 部件 )

5.2 DECOMPOSITION AND MODULARITY 图 5.3 分解的层次

5.3 ARCHITECTURAL STYLES AND STRATEGIES  Shaw and Garlan (1996) suggest three design levels: architecture, code design, and executable( 完成 ) design. Architecture Code design Executable design  Just as buildings reflect( 反映 ) a particular architectural style, so,too can we characterize software architectural styles. A style involves its components, connectors,and constrains( 约束 ) on combing components. Shaw and Garlan note that there are seven commonly used styles: Pipes( 管, 导管, 管道 ) and Filters( 过滤器, 筛选, 过滤 ), objects,implicit invocation, layering,repositories, interpreters,and process control.

5.4 ISSUES IN DESIGN CREATION 1. Modularity( 模块化 ) and Levels of Abstraction( 抽象层次 ) levels of abstraction information hiding 2. Collaborative( 协作的 ) Design On most projects, the design is not created by one person. Rather,a team works collaboratively to produce a design,often by assigning( 分派 ) different parts of the design to different people. Several issues must be addressed by the team, including who is best suited to design each aspect( 样子 ) of the system, how to document the design so each team member understands the designs of others,and how to coordinate ( 协同,协调 ) the design components so they work well as a unified whole( 统一整体 ). One of the major problem in performing collaborative design is addressing( 选择 ) differences in personal experience,understanding,and preference( 喜好 )

5.4 ISSUES IN DESIGN CREATION As the software industry seeks( 追求 ) to cut costs and maximize productivity by developing software with collaborative( 协作 ) groups located all over the world, the importance of understanding group behavior will increase. Your identifies four stages in the distributed development: 1. In the first stage, a project is performed at a single site with on- site developers from foreign countries. 2. In the second stage, on-site analysts determine the system's requirements. Then, the requirements are provided to off-site groups of designers and programmers to continue development. 3. In the third stage, offsite ( 不在现场的 ) developers build generic products and components that are used worldwide. 4. In the fourth stage, the offsite developers build products that take advantage of their individual( 单独 ) areas of expertise.

5.4 ISSUES IN DESIGN CREATION 3. Designing the User Interface Marcus (1993)discusses many of the issue involved in interface design. He points out that an interface should address several key elements:

5.4 ISSUES IN DESIGN CREATION metaphors( 比喻 ): the fundamental terms( 基本术语 ), images, and concepts that can be recognized and learned a mental model( 思维模型 ): the organization and representation of data, functions tasks, and roles the navigation rules( 导航规则 ) for the model: how to move among data, functions, activities, and roles look: the characteristics of the system's appearance( 外观 ) that convey( 传达 ) information to the user.feel: the interaction techniques that provide an appealing( 动人的, 引人入胜的 ) experience for the user

5.4 ISSUES IN DESIGN CREATION The user interface can incorporate( 结合, 包括 ) a variety of technologies: agents( 代理 ), hypertext( 超文本 ), sound, three-dimensional( 三维的, 立体的 ) displays, video, and virtual reality( 虚拟现实 )

5.4 ISSUES IN DESIGN CREATION 4 Design patterns( 模式 ) and Reuse Often, we design and built systems that are similar in some respects( 关系 ) to the systems we have built before. We want to take advantage of the commonality( 公共的 ) among systems,so that we need not develop each “ from scratch( 乱抓, 凑合 ) ”. A popular way of identifying the commonalities is to look for design pattern. Then,we can reuse the patterns, as well as the code,test,and documents related to them, when we build the next similar system

5.5 CHARACTERISTICS OF GOOD DESIGN 1. Component Independence Coupling:  highly coupled, Loosely coupled, Uncoupled, FIGURE 5.12 Component coupling.

5.5 CHARACTERISTICS OF GOOD DESIGN  There are many ways that components can be dependent on each other, so coupling depends on several things: The references made from one component to another. For example, component A may invoke( 调用 ) component B, so component A depends on component B for completion of its function or process. The amount of data passed from one component to another. For example, component A may pass a parameter, the contents of an array, or a block of data, to component B. The amount of control one component has over the other. For example, component A may pass a control flag to component B. The value of the flag tells component B the state of some resource or subsystem, which process to invoke, or whether to invoke a process at all. The degree of complexity in the interface between components. For example, component A passes a parameter to component B, after which B can execute( 执行 ). But components C and D exchange values before D can complete execution, so the interface between A and B is less complex than that of C and D.

5.5 CHARACTERISTICS OF GOOD DESIGN We can measure coupling( 耦合 ) along a range of dependence,from complete dependence to complete independence,as shown in Figure 5013 FIGURE 5.13 The range of coupling measures.

5.5 CHARACTERISTICS OF GOOD DESIGN FIGURE 5.14 Example of content( 内 容 ) coupling FIGURE 5.15 Example of common coupling

5.5 CHARACTERISTICS OF GOOD DESIGN Cohesion( 内聚 ) refers to the internal “ glue( 粘合 ) ” with which a component is constructed FIGURE 5.16 Types of cohesion.

5.5 CHARACTERISTICS OF GOOD DESIGN FIGURE 5.17 Examples of cohesion.

5.5 CHARACTERISTICS OF GOOD DESIGN 2. Exception( 异常 ) Identification( 鉴别 ) and Handling( 处理 )  Typical( 典型的 ) exception include Failure to provide a service Providing the wrong service or data Corrupting( 不可靠的 ) data  For each exception we identify,we can handle it in one of three ways Retry Correct report

5.5 CHARACTERISTICS OF GOOD DESIGN 3. Fault prevention( 缺陷预防 ) and Fault Tolerance( 故障容错 ) How to handle with the fault? Active Fault Detection Fault Correction Fault Tolerance

5.6 TECHNIQUES FOR IMPROVING DESIGN The way to improve the design: Reducing complexity ( 降低复杂度 ) Design by Contract ( 按合同进行设计 ) Prototyping Design ( 原型设计 ) Fault-Tree Analysis ( 故障树分析 )

5.7 DESIGN EVALUATION AND VALIDATION  Validation( 确认 ) of the design :we make sure that the design satisfies all requirements specified by the customer  verification( 鉴定 ) :we address the quality of the design

5.7 DESIGN EVALUATION AND VALIDATION Techniques of the validation and verification 1.Mathematical validation 2.Measuring Design Quality 3.Comparing Designs 4.Design Reviews

5.8 DOCUMENTING THE DESIGN An important product of the design process is a set of documents that describe the system to be built. As we have seen, one part must tell the customers and users in natural language what the system will do; a second part uses technical terminology to describe the system's structure, data, and functions. Thus, the contents of the two parts may overlap, but the way of expressing them may not. The design documents should contain a section, called the design rationale, outlining the critical issues and trade- offs( 权衡 ) that were considered in generating the design. This guiding philosophy helps the customers and other developers understand how and why certain parts of the design fit together.

5.8 DOCUMENTING THE DESIGN The design also should contains( 包含 ) descriptions of the components of the system.We should address how the users interact with the system, including the following: menus and other display-screen formats( 格式 ) human interfaces: function keys, touch screen descriptions, keyboard layouts, and use of a mouse or joystick ( 操纵杆 ) report formats input: where data come from, how they are formatted, and on what media they are stored output: Where data are sent, how they are formatted, and on what media they are stored general functional characteristics performance constraints ( 性能约束 ) archival procedures ( 归档手续 ) fault-handling approach ( 故障处理 步骤 )

5.8 DOCUMENTING THE DESIGN  If the system is distributed( 分布式 ), the configuration( 配置 ) in the design is detailed enough to show the topology of the network.  If the customer requires it, elements of the design may address monitoring ( 监视 ) system performance.  Finally, the design is cross-referenced ( 前后参照, 交叉 引用 ) with the requirements to demonstrate how the design is derived( 起源 ) from them.