CSEB233 Fundamentals of Software Engineering - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

CSEB233 Fundamentals of Software Engineering

Description:

CSEB233 Fundamentals of Software Engineering Module 4: Software Design Badariah Solemon 2011 – PowerPoint PPT presentation

Number of Views:47
Avg rating:3.0/5.0
Slides: 50
Provided by: bad132
Learn more at: http://ce.sharif.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSEB233 Fundamentals of Software Engineering


1
CSEB233 Fundamentals of Software Engineering
  • Module 4 Software Design

2
Objectives
  • To explain set of design principles, concepts,
    and practices.
  • To describe four design models required for a
    complete design specification data design,
    architectural design, user interface design, and
    component-level design.
  • To introduce design support tools and evaluation.
  • To introduce design specification document.

3
What is Desig/900726
  • Design creates a representation or model of the
    software
  • but unlike the analysis model, the design model
    provides detail about
  • software architecture,
  • data structures,
  • interfaces, and
  • components that are necessary to implement the
    system.
  • Why is it important?
  • Because the model can be assessed for quality and
    improved before code is generated, tests are
    conducted, and more users are involved.

4
Analysis Models ? Design Model
The four design models
Each of the elements of the analysis/requirements
model provides information that is necessary to
create the design models required for a complete
design specification.
5
Characteristics of Good Design
  • According to McGlaughlin(1991)
  • 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.
  • Must be a readable, understandable guide for
    those who generate code and for those who test
    and subsequently support the software.
  • Should provide a complete picture of the
    software, addressing the data, functional, and
    behavioral domains from an implementation
    perspective.

6
Design Principles
  • According Davis(1995 )
  • 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.

7
Design Principle
  • The design process should not suffer from tunnel
    vision.
  • The design should not reinvent the wheel.
  • Reinventing the wheel is a phrase that means to
    duplicate a basic method that has already
    previously been created or optimized by others.

8
Design Principles (cntd)
  • The design should be structured to accommodate
    change.
  • The design should be structured to degrade
    gently, even when irregular 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.

9
Generic Task Set for Design
  • Refer to the Task Set in page 222.

10
Design Concepts
  • Fundamental design concepts that span both
    traditional and OO software development include
  • Abstraction
  • Architecture
  • Patterns
  • Separation of concerns
  • Modularity
  • Information hiding
  • Functional Independence
  • Refinement
  • Aspects
  • Refactoring
  • OO Design concepts
  • Design classes

11
Abstraction
  • Designers should work to derive both procedural
    and data abstractions that serve the problem.
  • Procedural abstraction sequence of instructions
    that have a specific and limited function
  • Data abstractions a named collection of data
    that describes a data object

12
Abstraction (cntd)
door details of enter algorithm
implemented with a "knowledge" of the object that
is associated with enter
door manufacturer model
number type swing direction
weight
implemented as a data structure
13
Abstraction (cntd)
  • Data abstraction refers to, providing only
    essential features by
  • hiding its background details.  
  • class result
  • int marks
  • float percentage
  • char name20
  • void input()
  • void output()
  •  
  • main()
  • bank b1
  • b1.input()
  • b1.output()

b1 is an object calling input and output member
functions, but that code is invisible to the
object b1.
14
Architecture
  • Is concerned on
  • describing the fundamental organization of the
    system,
  • identifying its various components and their
    relationships to each other, and
  • the environment in order to meet the system's
    quality goals.
  • Also, describe the overall structure of the
    software
  • organization of program modules,
  • the manner in which these modules interact, and
  • the structure of data used by the components.

15
Patterns
  • Online pattern searching
  • http//inventors.about.com/gi/dynamic/offsite.htm?
    sitehttp3A2FFpatents.uspto.gov2Fpatft2Findex
    .html
  • Under Quick Search, try to search pattern no.
    7669112.
  • You will get automated spell analysis pattern.

16
Separation of Concerns
  • Actually, it is a rule of thumb to define how
    modules should be separated to each other
  • different or unrelated concerns should be
    restricted to different modules.
  • Suggests that any complex problem can be easily
    handled if it is sub-divided into pieces that can
    be solved independently.
  • Why? So that a problem takes less time and effort
    to solve.
  • Is manifested in other design concepts
    modularity, aspects, functional independence and
    refinement.

17
Modularity
  • When software is divided into components
    (modules).
  • Modularize a design
  • To ease the planning for implementation (coding,
  • To define and deliver software increments,
  • To easily accommodate changes,
  • To efficiently test and debug program, and
  • To conduct long-term maintenance without serious
    side effects

18
Modularity Example
With Module
include ltstdio.hgt void print_menu(void) main()
print_menu() / end main / void
print_menu(void) printf(This program draws a
rectangle) / end function /
  • x

vs.
Without Module
include ltstdio.hgt main() printf(This
program draws a rectangle)
19
Information Hiding
  • Suggests that modules should be specified and
    designed so that information (data structures and
    algorithm) contain within a module is
    inaccessible to other modules that have no need
    for such information.
  • Implies that effective modularity can be achieved
    by defining a set of independent modules that
    communicate with one another only necessary
    information.

20
Information Hiding (cntd)
  • Serves as an effective criterion for dividing any
    piece of equipment, software or hardware, into
    modules of functionality.
  • Provides flexibility.
  • This flexibility allows a programmer to modify
    functionality of a computer program during normal
    evolution as the computer program is changed to
    better fit the needs of users.
  • When a computer program is well designed
    decomposing the source code solution into modules
    using the principle of information hiding,
    evolutionary changes are much easier because the
    changes typically are local rather than global
    changes.

21
Information Hiding Example
  • Suppose we have a Time class that counts the time
    of day
  • class Time
  • public
  • void Display()
  • private
  • int ticks
  • The Display() member function prints the current
    time onscreen. This member function is accessible
    to all. It's therefore declared public.
  • By contrast, the data member ticks is declared
    private. Therefore, external users can't access
    it.

22
Information Hiding Example (cntd)
  • Regardless of how Display() extracts the current
    timestamp from ticks, users can be sure that it
    will "do the right thing" and display the correct
    time onscreen.

23
Functional Independence
  • Achieved by developing independent modules each
    module address a specific subset of requirements.
  • Is assessed using cohesion and coupling.
  • Cohesion - is an indication of the relative
    functional strength of a module.
  • a cohesive module should (ideally) do just one
    thing.
  • Coupling - is an indication of the relative
    interdependence among modules.
  • depends on the interface complexity between
    modules, the point at which entry or reference is
    made to a module, and what data pass across the
    interface.

24
Functional Independence (cntd)
  • This class lacks cohesion
  • public class CashRegisterpublic void
    enterPayment(int dollars, int quarters, int
    dimes, int nickels, int pennies). . .public
    static final double NICKEL_VALUE 0.05public
    static final double DIME_VALUE 0.1public
    static final double QUARTER_VALUE 0.25. . .

25
Functional Independence (cntd)
  • The CashRegister, as described above, involves
    two concepts cash register and coin
  • Solution Make two classes
  • public class Coinpublic Coin(double aValue,
    String aName) . . . public double getValue()
    . . . . . .public class CashRegisterpubli
    c void enterPayment(int coinCount, Coin coinType)
    . . . . . .

26
Functional Independence (cntd)
  • Coupling

27
Refinement
open
walk to door
reach for knob

open door
repeat until door opens

turn knob clockwise
walk through
if knob doesn't turn, then
close door.
take key out
find correct key
insert in lock
endif
pull/push door move out of way
end repeat
28
Refactoring
  • According to Fowler (1999)
  • "Refactoring is the process of changing 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
  • or any other design failure that can be corrected
    to yield a better design.

29
Design Model Elements
  • Data/Class Design
  • Class diagrams transformed into the design class
    realization and the data structures required to
    implement the software.
  • Architectural Design
  • Provides high-level overview of the system with
    detailed descriptions to be given by other design
    elements.
  • Defines the relationship between major structural
    elements of the software, the architectural
    styles and design patterns that can be used to
    achieve the requirements of the system and the
    constraints that affect the way in which the
    architecture can be implemented.

30
Design Models (cntd)
  • Interface Design
  • Describes how the software communicates with
    systems that interoperate with it, and with human
    who use it.
  • Component-Level Design
  • Defines the data structures, algorithms,
    interface characteristics, and communication
    mechanisms allocated to each software component
    or module.

31
Data/Class Design Elements
  • example High-level DFD
  • Source http//yourdon.com/strucanalysis/wiki/inde
    x.php?titleChapter_9

32
Data/Class Design Elements (cntd)
  • example ERD
  • Source http//www.svgopen.org/2003/papers/SvgInte
    rfaceElectricalSwitching/index.html

33
Data/Class Design Elements (cntd)
  • example Class Diagram
  • Source http//www.agiledata.org/essays/objectOrie
    ntation101.html

34
Architectural Design Elements
  • The architectural model Sha96 is derived from
    three sources
  • information about the application domain for the
    software to be built
  • specific requirements model elements such as data
    flow diagrams or analysis classes, their
    relationships and collaborations for the problem
    at hand, and
  • the availability of architectural patterns
    (Chapter 12) and styles (Chapter 9).

35
Architectural Design Elements (cntd)
  • Example architecture diagram
  • Source http//blog.tmcnet.com/blog/tom-keating/20
    04/10/index.asp?page7

36
Architectural Design Elements (cntd)
  • Example Architectural styles
  • Source x

37
Interface Design Elements
  • External interfaces to other systems, devices,
    networks or other producers or consumers of
    information

38
Interface Design Elements (cntd)
  • The user interface (UI)

39
Component Design Elements
  • UML Component Diagram
  • Source http//edn.embarcadero.com/article/31863c
    omponent-and-deployment-diagrans

40
Design Support Tools
  • All aspects of the software engineering can be
    supported by software tools
  • from project management software through tools
    for business and functional analysis, system
    design, code storage, compilers, translation
    tools, test software, and so on.
  • However, tools that are concerned with analysis
    and design, and with using design information to
    create parts (or all) of the software product,
    are most frequently thought of as CASE tools.
  • List of CASE tools http//www.unl.csi.cuny.edu/f
    aqs/software-enginering/tools.html

41
CASE Tool Example
  • IBM Rational Software Architect
  • Source http//www.ibm.com/developerworks/rational
    /library/10/whats-new-in-rational-software-archite
    ct-8/index.html

42
CASE Tool Example (cntd)
  • Database Modeling Enterprise Architect by Sparx
    Systems Pty Ltd.
  • Source http//www.sparxsystems.com/images/screens
    hots/platforms/databasemodeling_tn.jpg

43
Design Evaluation
  • "A good software design minimizes the time
    required to create, modify, and maintain the
    software while achieving run-time performance.
    (Shore and Chromatic, 2007)
  • According to Elssamadisy (2007)
  • Design quality is people-sensitive.
  • For instance, design quality is dependent upon
    the programmers writing and maintaining the code.
  • Design quality is change-specific.
  • There are two general ways to make designs of
    higher quality with respect to this aspect
  • generalizing from the tools like design patterns,
    and
  • using tests and refactoring as change-enablers.

44
Design Evaluation (cntd)
  • Modification and maintenance time are more
    important than creation time.
  • Because
  • time spent in maintenance is much more than
    creation time of a software, and
  • in iterative development, modification happens
    during the initial creation of the software.
  • Design quality is unpredictable.
  • Because quality is really dependant on the team
    developing the software. As the team changes, or
    evolves, then the design quality also evolves.
  • You really only know how good a design is by it
    standing the test of time and modifications.

45
Design Evaluation (cntd)
  • Points to ponder
  • to maintain the quality of the design, we must
    maintain the theory of the design as the
    programming team evolves,
  • That design quality is tied to the people who are
    building and maintaining the software(Shore and
    Chromatic, 2007).

46
Design Specification
  • IEEE Standard for Information Technology -Systems
    Design - Software Design Descriptions (IEEE
    1016-2009) an improved version of the 1998
    version.
  • This standard specifies an organizational
    structure for a software design description
    (SDD).
  • An SDD is a document used to specify system
    architecture and application design in a software
    related project.
  • Provides a generic template for an SDD.

47
SDD Examples
  • Refer to http//www.cs.uofs.edu/dmartin/exsesrm.h
    tm_Toc514249734
  • Refer to SDDSample.doc

48
Summary
  • This module has
  • Introduced set of design principles, concepts,
    and practices.
  • Described four design models required for a
    complete design specification data design,
    architectural design, user interface design, and
    component-level design.
  • Introduced design support tools and evaluation.
  • Introduced design specification document (SDD).

49
References
  • Pressman, R. (2003). Software Engineering A
    Practitioner's Approach. 6th 5th edition. New
    York McGraw-Hill.
  • Somerville I. (2001). Software Engineering. 6th
    edition. Addison Wesley
  • http//www.allinterview.com/showanswers/66313.html
  • http//www.augustana.ab.ca/mohrj/courses/2006.win
    ter/csc120/slides/ch09/ch09.html
  • http//www.informit.com/guides/content.aspx?gcplu
    splusseqNum78
  • Shore, J. and Chromatic, (2007). The Art of Agile
    Development. O'Reilly Media.
  • Elssamadisy, A. (2007). Defining Design Quality.
    http//www.infoq.com/news/2007/04/defining-design-
    quality
About PowerShow.com