CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu 1 Drexel University
Design within the Context of Software Engineering 2 Drexel University
Software Design Between Requirement and Coding Including: Data Design Architectural Design Interface Design Component Design Need to be modeled, analyzed, and reviewed in industrial strength software. 3 Drexel University
Translating the Analysis Model into the Design Model Component Design Interface Design Architecture Design Data/ Class Design 4 Drexel University
Design Process and Desgin Quality 5 Drexel University
Design Engineering Software design is an iterative process through which requirements are translated into a “blueprint” for constructing software Abstraction Refinement 6 Drexel University
Design Engineering A 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. A design must be a readable, understandable guide for those who generate code and 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. 7 Drexel University
Design Quality FURPS – Functionality, Usability, Reliability, Performance, and Supportability. Functionality – assessed by evaluating: the feature set capabilities of the program. Usability - assessed by considering: human factors, overall aesthetics, consistency, end-user documentation. 8 Drexel University
Design Quality - Functionality, Usability, Reliability, Performance, and Supportability Reliability – is evaluated by measuring: the frequency and severity of failure, the accuracy, of output results, the mean-time-to-failure, the ability to recover from failure, the predictability of the program. Performance – is measured by: processing speed, response time, resource consumption, throughput, efficiency 9 Drexel University
Design Quality - Functionality, Usability, Reliability, Performance, and Supportability Supportability – combines: the ability to extend the program (extensibility), adaptability, testability, compatibility, configurability. 10 Drexel University
Design Concepts 11 Drexel University
Design Concepts Abstraction Architecture Patterns Modularity Information Hiding Functional Independence Refinement Refactoring 12 Drexel University
Design Concepts-Abstraction “Abstraction is one of the fundamental ways that we as humans cope with complexity.” Grady Booch “What kinds of things do we abstract? data objects procedures modules just about anything 13 Drexel University
Design Concepts-Architecture Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Architecture is: the structure or organization of program components (modules), the manner in which these components interact, the structure of data that are used by the components. 14 Drexel University
Design Concepts-Patterns “A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns.” “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Christopher Alexander 15 Drexel University
Design Concepts -Modularity MODULARITY “Modularity is the single attribute of software that allows a program to be intellectually manageable” Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements. 16 Drexel University
Design Concepts –Information Hiding Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. This means that inadvertent errors introduced during modification are less likely to propagate to other locations within the software. Changes to the internal representation of one module should have not have an effect on other modules. 17 Drexel University
Design Concepts-Functional Independence Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules. We want to design software so that each module addresses a specific subfunction of requirements and has a simple interface when viewed from other parts of the program structure. 18 Drexel University
Design Concepts-Functional Independence Independence is assessed by using two qualitative criteria: Cohesion – How related a module is to itself. It should perform a single task and require little interaction with the rest of the program. Coupling is an indication of the interconnectoin among modules in a software structure. 19 Drexel University
Design Concepts-Refinement Stepwise refinement is when a program is developed by successively refining levels of procedural detail. Refinement is actually the process of elaboration. 20 Drexel University
Design Concepts-Refactoring Refactoring is a reorganizational technique that simplifies the design )of code) of a component without changing its function or behavior. 21 Drexel University
SOLID Drexel University
Single Responsibility Principle There can be only one reason for a class to change. Drexel University
Open-Close Principle Classes and methods should be open for extension but closed for modification. Drexel University
Liskov Substitution Principle Every function or method which expects an object parameter of class A must be able to accept a subclass of A as well, without knowing it. Drexel University
Interface Segregation Principle Classes should not depend on interfaces that they not use. Drexel University
Dependency Inversion Principle High level classes should not depend on low level classes. Both should depend upon abstractions. Details should depend upon abstractions. Abstractions should not depend upon details. Drexel University
Please refer to the design document rubric 28 Drexel University
Recommend
More recommend
