Yuanfang cai room 104 university crossings 215 895 0298 yfcai@cs drexel edu
Download
1 / 22

CS 451 Software Engineering Winter 2009 - PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on

Yuanfang Cai Room 104, University Crossings 215.895.0298 [email protected] CS 451 Software Engineering Winter 2009. Design within the Context of Software Engineering. Software Design. Between Requirement and Coding Including: Data Design Architectural Design Interface Design

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CS 451 Software Engineering Winter 2009' - myrilla-favian


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Yuanfang cai room 104 university crossings 215 895 0298 yfcai@cs drexel edu

Yuanfang Cai

Room 104, University Crossings

215.895.0298

[email protected]

CS 451Software EngineeringWinter 2009



Software design
Software Design

  • Between Requirement and Coding

  • Including:

    • Data Design

    • Architectural Design

    • Interface Design

    • Component Design

    • Detailed Design

  • Need to be modeled, analyzed, and reviewed in industrial strength software.


Translating the analysis model into the design model
Translating the Analysis Model into the Design Model

Component Design

Interface Design

Architecture Design

Data/Class Design



Design engineering
Design Engineering

  • Software design is an iterative process through which requirements are translated into a “blueprint” for constructing software

    • Abstraction

    • Refinement


Design engineering1
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.


Design quality
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.


Design quality functionality usability reliability performance and supportability
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


Design quality functionality usability reliability performance and supportability1
Design Quality - Functionality, Usability, Reliability, Performance, and Supportability

  • Supportability – combines:

    • the ability to extend the program (extensibility),

    • adaptability,

    • serviceability

    • testability,

    • compatibility,

    • configurability.


Design concepts
Design Concepts Performance, and Supportability


Design concepts1
Design Concepts Performance, and Supportability

  • Abstraction

    • Architecture

    • Patterns

    • Data

  • Modularity

    • Information Hiding

    • Functional Independence

    • Refinement

    • Refactoring

  • Design Classes


Design concepts abstraction
Design Concepts-Abstraction Performance, and Supportability

  • “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


Design concepts architecture
Design Concepts-Architecture Performance, and Supportability

  • 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.


Design concepts patterns
Design Concepts-Patterns Performance, and Supportability

  • “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


Design concepts modularity
Design Concepts -Modularity Performance, and Supportability

  • 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.


Design concepts information hiding
Design Concepts –Information Hiding Performance, and Supportability

  • 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.


Design concepts functional independence
Design Concepts-Functional Independence Performance, and Supportability

  • 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.


Design concepts functional independence1
Design Concepts-Functional Independence Performance, and Supportability

  • 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.


Design concepts refinement
Design Concepts-Refinement Performance, and Supportability

  • Stepwise refinement is when a program is developed by successively refining levels of procedural detail.

  • Refinement is actually the process of elaboration.


Design concepts refactoring
Design Concepts-Refactoring Performance, and Supportability

  • Refactoring is a reorganizational technique that simplifies the design )of code) of a component without changing its function or behavior.


Design concepts design classes
Design Concepts-Design Classes Performance, and Supportability

  • Refine analysis classes by providing design details

  • Create a new set of design classes that implement a software infrastructure to support the business solution

  • Five types:

    • User interface classes

    • Business domain classes

    • Process classes

    • Persistent classes

    • System classes


ad