1 / 21

Chapter 9 Design Engineering

Chapter 9 Design Engineering. Flow-oriented elements. Data flow diagrams control flow diagrams Processing narratives. Analysis Model. Behavioral elements. component-level design. State diagrams Sequence diagrams. Scenario-based elements. i. n. t. e. r. f. a. c. e. d. e. s.

chogan
Download Presentation

Chapter 9 Design Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 9Design Engineering

  2. Flow-oriented elements Data flow diagrams control flow diagrams Processing narratives Analysis Model Behavioral elements component-level design State diagrams Sequence diagrams Scenario-based elements i n t e r f a c e d e s i g n Use-cases (text) Use-case diagrams Activity diagrams Swim lane diagrams a r c h i t e c t u r a l d e s i g n data/class design Class-based elements DESIGN MODEL Class diagrams Analysis packages CRC models Collaboration diagrams 9.1 Design within the Context of SE 1/20

  3. 9.2 Design Process and Design Quality • the design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. • the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. • the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. • Three characteristics for a good design Please read Quality Guidelines in Section 9.2 2/20

  4. 9.2 Design Process and Design Quality • Design Principles (from Davis [DAV95] ) • The design process should not suffer from “tunnel vision”. • The design should be traceable to the analysis model. • The design should not reinvent the wheel. • The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world. • The design should exhibit uniformity and integration. • The design should be structured to accommodate change. • The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. • Design is not coding, coding is not design. • The design should be assessed for quality as it is being created, not after the fact. • The design should be reviewed to minimize conceptual (semantic) errors. 3/20

  5. door open manufacturer details of enter model number type algorithm swing direction inserts lights type number weight opening mechanism repeat until door opens turn knob clockwise; implemented with a "knowledge" of the if knob doesn't turn, then object that is associated with enter take key out; implemented as a data structure find correct key; insert in lock; endif pull/push door move out of way; end repeat 9.3 Design Concepts • Abstraction — data, procedure, control walk to door; reach for knob; open door; walk through; close door. • Refinement — top-down design strategy 4/20

  6. 9.3 Design Concepts • Architecture:The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. [SHA95a] • Structural models: represent architecture as an organized collection of program components • Framework models: increase the level of abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications • Dynamic models: address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events • Process models: focus on the design of the business or technical process that the system must accommodate. • Functional models: represent the functional hierarchy of the system 5/20

  7. 9.3 Design Concepts • Patterns Design Pattern Template • Pattern namedescribes the essence of the pattern • Intentdescribes the pattern and what it does • Also-known-assynonyms for the pattern • Motivationprovides an example of the problem • Applicabilityspecific design situations in which the pattern is applicable • Structureclasses that are required to implement the pattern • Participantsresponsibilities of the classes • Collaborationshow the participants collaborate to carry out their responsibilities • Consequencesdescribes the “design forces” that affect the pattern and the potential trade-offs • Related patternscross-references related design patterns 6/20

  8. module development cost cost of software module integration cost easier to build, easier to change, easier to fix ... optimal number number of modules of modules 9.3 Design Concepts • Modularity 发信人: liuyidaojian (山水涅磐), 信区: CS 标 题: 林锐的软件工程里的一段 发信站: 飘渺水云间 (Sun May 4 14:51:41 2003), 转信 模块就如同人的器官，具有特定的功能。人体中最出色的模块设计之一是手，手只有几种动作，却能做无限多的事情。人体中最糟糕的模块设计之一是嘴巴，嘴巴将最有价值但毫无相干的几种功能如吃饭、说话、亲吻混为一体，使之无法并行处理，真乃人类之不幸。 -- 昔我往 友 柳依依，今我来?，雨雪霏霏！ 人微言轻，以其不争，故天下莫与之争？ 树犹如此，人何以堪？ 万古长空，一朝风月！ ※ 来源:·飘渺水云间 Freecity.dhs.org·[FROM: liuyidaojian] 7/20

  9. module • algorithm controlled • data structure interface • details of external interface • resource allocation policy clients "secret" a specific design decision 9.3 Design Concepts • Information Hiding • reduces the likelihood of “side effects” • limits the global impact of local design decisions • emphasizes communication through controlled interfaces • discourages the use of global data • leads to encapsulation—an attribute of high quality design • results in higher quality software 8/20

  10. Great deal of dependence Independent  Highly coupled Loosely coupled Uncoupled  9.3 Design Concepts • Functional Independence • Coupling Goal: as loose as possible = as independent as possible 9/20

  11. 9.3 Design Concepts A: ……………… ……………… entry 1: ……………… ……………… entry 2: ……………… ……………… …… A B A: ………… ………… goto C1 ………… ………… C D C: ………… ………… C1: …… …… A B  Content Coupling: One module modifies another. The least desirable 10/20

  12. 9.3 Design Concepts Global : V1 V2 Global : V1 V2 A: ………… ………… A1=V1+V2 ………… ………… B: ………… ………… V1=B1 ………… ………… A: ………… ………… V1++ ………… ………… B: ………… ………… V2=B1+V1 ………… …………  Common coupling：Data are accessible from a common data store. 11/20

  13. 9.3 Design Concepts B Fn …… Flag A F2 …… Flag F1  Control coupling：One module passes parameters to control the activity of another module.  Data coupling ：Only data are passed. It is easy to trace data and make changes.  The most desirable. 12/20

  14. 9.3 Design Concepts from disk from tape from …… A: Read inputs • Cohesion: as cohesive as possible  Coincidental cohesion ：Unrelated functions, processes, or data are found in the same module (for convenience).  Logical cohesion：Logically related functions or data are placed in the same module.  Temporal cohesion：The functions are related only by the timing involved. 13/20

  15. 9.3 Design Concepts enter data check data manipulate data • Cohesion: (continued)  Procedural cohesion：Functions are grouped together in a module to ensure a certain order of performance.  Communicational cohesion：All the functions in a module operate on or produce the same data set.  Functional cohesion：Every processing element is essential to the performance of a single function. 14/20

  16. 9.3 Design Concepts Sizing Modules: Two Views 15/20

  17. 9.3 Design Concepts • Refactoring: change a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure. • When software is refactored, the existing design is examined for: • redundancy • unused design elements • inefficient or unnecessary algorithms • poorly constructed or inappropriate data structures • any other design failure that can be corrected to yield a better design. 16/20

  18. 9.3 Design Concepts • Design Classes • User interface classes • Business domain classes • Process classes – lower-level business abstractions required to fully manage the BD classes • Persistent classes – database • System classes – management and control functions 17/20

  19. high Analysis model Abstraction dimension c l R e q u i r e m e n t s : a s s d i a g r a m s a n a l y s i s p a c k a g e s c o n s t r a i n t s u s e - c a s e s - t e x t c l a s s d i a g r a m s C R C m o d e l s u s e - c a s e d i a g r a m s i n t e r o p e r a b i l i t y a n a l y s i s p a c k a g e s c o l l a b o r a t i o n d i a g r a m s a c t i v i t y d i a g r a m s C R C m o d e l s t a r g e t s a n d d a t a f l o w d i a g r a m s s w i m l a n e d i a g r a m s c o l l a b o r a t i o n d i a g r a m s c o n f i g u r a t i o n c o n t r o l - f l o w d i a g r a m s c o l l a b o r a t i o n d i a g r a m s d a t a f l o w d i a g r a m s p r o c e s s i n g n a r r a t i v e s s t a t e d i a g r a m s c o n t r o l - f l o w d i a g r a m s s e q u e n c e d i a g r a m s p r o c e s s i n g n a r r a t i v e s s t a t e d i a g r a m s s e q u e n c e d i a g r a m s d e s i g n c l a s s r e a l i z a t i o n s t e c h n i c a l i n t e r f a c e s u b s y s t e m s d e s i g n c o m p o n e n t d i a g r a m s c o l l a b o r a t i o n d i a g r a m s d e s i g n c l a s s r e a l i z a t i o n s N a v i g a t i o n d e s i g n d e s i g n c l a s s e s s u b s y s t e m s G U I d e s i g n a c t i v i t y d i a g r a m s c o l l a b o r a t i o n d i a g r a m s Design model d i a g r a m s s e q u e n c e d i a g r a m s c o d m e p s o i g n n e n c t l a s s e s a c t i v i t y d i a g r a m s s e q u e n c e d i a g r a m s r e f i n e m e n t s t o : r e f i n e m e n t s t o : c o m p o n e n t d i a g r a m s low d e s i g n c l a s s r e a l i z a t i o n s d e s i g n c l a s s e s s u b s y s t e m s a c t i v i t y d i a g r a m s c o l l a b o r a t i o n d i a g r a m s s e q u e n c e d i a g r a m s d e p l o y m e n t d i a g r a m s a r c h i t e c t u r e i n t e r f a c e c o m p o n e n t - l e v e l d e p l o y m e n t - l e v e l e l e m e n t s e l e m e n t s e l e m e n t s e l e m e n t s Process dimension 9.4 The Design Model 18/20

  20. abstraction 9.5 Pattern-based Software Design • Design patterns – a technique that reuses design elements that have proven successful in the past • A description of a design pattern may also consider a set of design forces. • Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied. • Types of design patterns: • Architectural patterns • Design patterns (focus on a specific element of design) • Idioms (coding patterns) 19/20

  21. 9.5 Pattern-based Software Design • Framework – an architectural skeleton with a collection of “plug points” that enable it to be adapted to a specific problem domain. • Gamma et al note that: • Design patterns are more abstract than frameworks. • Design patterns are smaller architectural elements than frameworks • Design patterns are less specialized than frameworks 20/20

More Related