Design Principles - PowerPoint PPT Presentation

Loading...

PPT – Design Principles PowerPoint presentation | free to download - id: 5da02d-MGU2N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Principles

Description:

Title: Design Principles Subject: SWE 321 Author: Dr. Dewan Tanvir Ahmed Last modified by: Kwangcheol Shin Created Date: 12/8/1995 5:21:36 PM Document presentation format – PowerPoint PPT presentation

Number of Views:20
Avg rating:3.0/5.0
Slides: 64
Provided by: DrDewanT
Category:

less

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

Title: Design Principles


1
Software Design FundamentalsDesign Principles
Slides from Dr. Dewan Tanvir Ahmed
2
Lecture Objectives
  • To understand the importance of design in
    developing quality software
  • To describe the translation from the requirements
    analysis model to the design model
  • To understand the principles that guide proper
    design of software

2
3
Lecture Objectives
  • Design Principles
  • Abstraction
  • Modularity
  • Information Hiding
  • Cohesion
  • Coupling

3
4
Software Design
  • General definition of design
  • the process of applying various techniques and
    principles for the purpose of defining a device,
    a process, or a system in sufficient detail to
    permit its physical realization.
  • Goal
  • To produce a model or representation that will
    later be built
  • Engineering or Art?

4
5
Software Design Model
5
6
Software design process
6
7
Software architecture
  • The design process for identifying the
    sub-systems making up a system and the framework
    for sub-system control and communication is
    architectural design.
  • The output of this design process is a
    description of the software architecture.

7
8
(No Transcript)
9
General Design Guidelines
  • Exhibit a hierarchical organization that makes
    intelligent use of control among components
  • Logically partitioned into components that
    perform specific tasks and subtasks
  • Distinct representation of data and procedure
  • Lead to interfaces that reduce complexity
  • Derived using a repeatable method driven by
    information gathered during requirements

9
10
Data Design
The primary activity during data design is to
select logical representations of data objects
identified during the requirements definition and
specification phase.
  • Transforms the information domain model created
    during the analysis into the data structures that
    will be required to implement SW.
  • Identify the program modules that operate upon
    the logical data structures
  • Data design leads to better program structure,
    effective modularity, reduced complexity

10
11
Data Specification Principles
  • Apply functional analysis principles to data
  • Identify all data structures and associated
    operations
  • Establish a data dictionary to define data
    program design
  • Defer low-level data design decisions
  • Representation of data structure should only be
    known to modules with direct use of data within
    the structure
  • Develop a library of useful data structures
  • Language should support abstract data types

11
12
Architectural Design
  • Objective is to develop a modular program
    structure and represent the control relationships
    between modules
  • Combines program and data structure by defining
    interfaces that allows data to flow throughout
    the program
  • Holistic view of software

12
13
Design Principle - Abstraction
  • It is a means by which one can focus on the
    important aspects of a problem at a particular
    level without the hindrance of unnecessary or
    irrelevant and/or low-level detail.
  • Abstraction is especially essential in solving
    complex problems as it enables the problem solver
    to think in terms of conceptual ideas rather than
    in terms of their details. Abstraction can be
    expressed in different ways. Jeff Kramer

13
14
Abstraction in Software Engineering
  • Requirements Engineering - gather the critical
    aspects of the environment and required system
    while neglecting the irrelevant.

Goals Assumptions Constraints Scope Properties Use
Cases?
Requirements
Requirement Specification
14
15
Abstraction in Software Engineering?
  • Design - clearfy the software architecture and
    component functionalities which satisfy
    functional and non-functional requirements while
    avoiding unnecessary implementation constraints.

Goals Assumptions Constraints Scope Properties Use
Cases?
User Interface
Business Logic
Data Layer
15
16
Design Principle - Modularity
  • What is Modularity (or Modularisation)
  • Decomposing large software into a number of
    smaller as independent as possible components,
    usually with the goal of placing different
    functionalities or responsibilities in different
    components.
  • A Component the basic unit of modularisation
    (also called Modules) is
  • A method
  • A class
  • A package
  • Or other design element

16
17
Design Principle - Modularity
Easier to build, easier to change, easier to fix
...
17
18
Design Principle - Modularity
  • Why Modularity
  • Software consists of thousands or millions of
    lines of code and the complexity can be easily be
    overwhelming. Modularity allows such complexity
    to be manageable for purposes of implementation
    and maintenance.
  • Where Modularity is needed
  • Architectural Design
  • Layered software architecture is an example of
    modularity
  • Independent Design
  • Enable the ability to design different components
    in different ways.

18
19
Design Principle - Modularity
  • Where Modularity is needed
  • Component Design
  • Make sure each component has a single
    well-defined purpose or function, with few, clear
    connection (for example, by interfaces) with
    other components
  • Debugging
  • Make bug finding easier as modularity allows bug
    finding to be with a particular component rather
    than the whole software
  • Testing
  • Modularity makes it possible that the testing can
    be carried out in a piecemeal fashion one
    component at a time. This is crucial important
    for testing of large and integrated software
    systems

19
20
Design Principle - Modularity
  • Where Modularity is needed
  • Independent Implementation and Development
  • Make possible to distribute large software
    development into each individual in a team of
    people as far as the interface between components
    are clear and few.
  • Summary
  • In conclusion, modular based design are useful
    for each phase of software development, from
    design, implementation, test, to maintenance.
  • The reason behind this is that the as much as
    possible independence between the different
    components allows that the software tasks can be
    done separately to overcome high complexity in
    software development.
  • So modularity is one of the key principles in
    software design

20
21
Design Principle - Modularity
  • Balance component size and complexity
  • The small size components will require a lot of
    connections between them in total although less
    complexity in each component
  • The large size components will require less
    connections in total but more complexity in each
    component
  • Therefore, a balance of component size is
    required

21
22
Design Principle Information Hiding
  • How to achieve modularity
  • Apply information hiding principle and approach
  • What is the information hiding
  • In modularisation context
  • Components hides the internal details and
    processing from one another
  • In more general context
  • grouping and packaging the elements and internal
    details of an abstraction (a component, an
    abstract data type, a class or a object etc ) and
    making those details inaccessible
  • Also called data hiding or encapsulation

22
23
Design Principle Information Hiding
23
24
Design Principle Information Hiding
  • Everyday example
  • Suppose you have to pay the bill of your
    newspaper subscription to your hawker. You can
    give your bill in two ways.
  • Take out your wallet and give the wallet to the
    hawker so that he can take his bills amount out
    of your wallet.
  • Take out your wallet, ask the bill amount from
    the hawker and give him the asked amount.
  • Which option is better?

24
25
Design Principle Information Hiding
  • Why information hiding in design each component
    hides a design decision from the others to
    achieve
  • Changeability
  • If a design decision is changed, such as a data
    structure, changes are confined to as few
    components as possible whereas the design as a
    whole can remain intact
  • Independent development
  • Enable independent development as far as the
    interfaces between components are simple and well
    defined. Also access methods are often simpler
    than access data
  • Comprehensibility
  • For design, debug, testing and maintenance, it is
    vital to understand each component independently
    of others. Information hiding improves our
    understanding by eliminating confusing from
    unrelated functions and data.

25
26
Design Principle Information Hiding
  • How to achieve information hiding
  • Apply the information hiding principle in design
  • Aiming at the end of the design process, any data
    structure or file is accessed only via certain
    well-defined specific methods (interfaces)
  • Separation of interface and implementation
  • Separating interface and implementation involves
    defining a component by specifying a public
    interface, separate from (or hid) the details of
    how the component is realized.
  • Choose programming languages support Information
    hiding
  • Such as Java, C, C, Visual Basic, .Net

26
27
Characteristics of Good Design
  • Component independence
  • High cohesion
  • Low coupling

28
Design Principle Coupling and Cohesion
  • What are Coupling
  • Coupling is a term to describe the interactions
    between components. The lower coupling, the less
    interaction (i.e., the more independence )
    between components
  • Design Principle Minimise Coupling
  • Coupling connections cause dependencies between
    components, which in turn, have an impact on
    system qualities such as maintainability (a
    modification of a components may require
    modifications to its connected components) or
    testability (a fault in one components may cause
    a failure in a completely different, connected
    components). Thus, a common design principle is
    to minimize coupling.

28
29
Coupling Degree of dependence among components
No dependencies
Loosely coupled-some dependencies
High coupling makes modifying parts of the system
difficult, e.g., modifying a component affects
all the components to which the component is
connected.
Highly coupled-many dependencies
30
Design Principle Coupling and Cohesion
  • What are Cohesion
  • Cohesion is a term to describe the interactions
    within components. The more cohesive a component,
    the more related the internal parts of the
    component to each other and to its whole purpose
  • Design Principle Maximise Cohesion
  • A low cohesive design element has been assigned
    many unrelated responsibilities. Consequently,
    the design element is more difficult to
    understand and therefore also harder to maintain
    and reuse. Design elements with low cohesion
    should be considered for refactoring, for
    instance, by extracting parts of the
    functionality to separate classes with clearly
    defined responsibilities.

30
31
Design Principle Coupling and Cohesion
Everyday Example
31
32
Design Principle Coupling and Cohesion
32
33
Design Principle Coupling and Cohesion
  • Relationship between Coupling and Cohesion
  • Coupling and cohesion are opposite sides in that
    strong cohesion tends to create weak coupling and
    vice versa

33
34
Design Principle Coupling and Cohesion
Examples of Coupling and Cohesion
High Coupling Low Cohesion
Low Coupling High Cohesion
Which one is better from a software design point
of view and why?
34
35
Design Principle Coupling and Cohesion
  • Types of coupling
  • Content coupling
  • Common coupling
  • Control coupling
  • Stamp coupling
  • Data coupling

35
36
Types of Coupling
  • 1. Content Coupling (i.e., modifying data within
    another component)
  • Allowing one component to modify another
    component data.
  • This is very strong coupling as a fault in one
    component may be caused by another
  • One component references contents of another
  • Example
  • Component directly modifies anothers data
  • Component modifies anothers code, e.g., jumps
    into the middle of a routine

36
37
Types of Coupling
  • 1. Content Coupling (i.e., modifying data within
    another component)
  • Example
  • Part of program handles lookup for customer.
  • When customer not found, component adds customer
    by directly modifying the contents of the data
    structure containing customer data.
  • Improvement
  • When customer not found, component calls the
    AddCustomer() method that is responsible for
    maintaining customer data.

37
38
Types of Coupling
  • 2. Common Coupling (i.e., shared or global data)
  • Several components sharing the same or global
    data cause strong coupling between the components
    via data
  • Two components share data
  • Global data structures
  • Common blocks
  • Usually a poor design choice because
  • Lack of clear responsibility for the data
  • Reduces readability
  • Difficult to determine all the components that
    affect a data element (reduces maintainability)
  • Difficult to reuse components
  • Reduces ability to control data accesses

38
39
Types of Coupling
  • 2. Common Coupling (i.e., shared or global data)
  • Process control component maintains current data
    about state of operation. Gets data from multiple
    sources. Supplies data to multiple sinks.
  • Each source process writes directly to global
    data store. Each sink process reads directly from
    global data store.
  • Improvement
  • Data manager component is responsible for
    data in data store. Processes send data to and
    request data from data manager.

39
40
Types of Coupling
  • Control Coupling (i.e., a method call with a
    parameter that is a switch)
  • Passing parameters to control the activity of
    another component and allowing one component to
    control another component behaviour.
  • Component passes control parameters to coupled
    components.
  • May be either good or bad, depending on
    situation.
  • Bad when component must be aware of internal
    structure and logic of another module
  • Good if parameters allow factoring and reuse of
    functionality

40
41
Types of Coupling
  • Stamp Coupling
  • This is the case where entire data structures are
    passed to the called component but only some
    individual fields are used, or
  • Component passes a data structure to another
    component that does not have access to the entire
    structure.
  • Requires second component to know how to
    manipulate the data structure (e.g., needs to
    know about implementation)
  • May be necessary due to efficiency factors this
    is a choice made by insightful designer, not lazy
    programmer.

41
42
Types of Coupling
  • Stamp Coupling
  • Example The print routine of the customer
    billing accepts a customer data structure as an
    argument, parses it, and prints the name,
    address, and billing information.
  • Improvement
  • The print routine takes the customer name,
    address, and billing information as an argument.

42
43
Types of Coupling
  • Data Coupling
  • Pass pure data parameters into another component.
    Often used interaction between components. This
    is a weak couple and leaves less room for errors
  • Pass a series stream of data to another component
    without any transfer of control between
    components. This is the weakest coupling.
  • Conclusion
  • Strong coupling increases dependency and
    complexity, decreases transparency of components,
    and leave more room for errors
  • Weak coupling between components is desired as
    it increases the modularity, is easy to manage,
    and reduces errors

43
44
Design Principle Coupling
The different degree of coupling in order
High Coupling
Content Coupling Common Coupling Control
Coupling Stamp Coupling Data Coupling Uncoupled
Loose
Low
44
45
Design Principle Coupling
  • Types of Cohesion
  • Coincidental Cohesion
  • Logical Cohesion
  • Temporal Cohesion
  • Procedural Cohesion
  • Communication Cohesion
  • Sequential Cohesion
  • Functional Cohesion

45
46
Design Principle Coupling and Cohesion
The different degree of cohesion in order
High Cohesion
Functional Sequential Communication Procedural Tem
poral Logical Coincidental
Low Cohesion
46
47
Design Principle Types of Cohesion
  • Coincidental Cohesion
  • The worst degree of cohesion in which unrelated
    functions, processes, or data are put into a same
    component coincidently
  • Parts of the component are only related by their
    location in source code
  • This leads the component without well defined
    purpose
  • Example
  • Print next line
  • Reverse string of characters in second argument
  • Add 7 to 5th argument
  • Convert 4th argument to float

47
48
Design Principle Types of Cohesion
  • Logical Cohesion
  • Elements of component are related logically and
    not functionally.
  • Several logically related elements are in the
    same component and one of the elements is
    selected by the client component.
  • The second worst degree of cohesion where several
    logically related functions or data elements are
    placed in the same component
  • such as all output functions to screen, to
    printer, to fax machine, and to database are
    placed together
  • but without taking into account the different
    purposes

48
49
Design Principle Types of Cohesion
  • Logical Cohesion
  • Example A component reads inputs from tape,
    disk, and network. All the code for these
    functions are in the same component. Operations
    are related, but the functions are significantly
    different.
  • Solution/Improvement
  • A device component has a read operation that is
    overridden by sub-class components. The tape
    sub-class reads from tape. The disk sub-class
    reads from disk. The network sub-class reads from
    the network.

49
50
Design Principle Types of Cohesion
  • Temporal Cohesion
  • Elements of a component are related by timing.
  • Very weak cohesion in which functions or
    processes are put into a same component only
    because they have to be carried out at about the
    same time
  • These activities are unrelated to one another
    except that theyre carried out at a particular
    time.
  • Example
  • A system initialization routine this routine
    contains all of the code for initializing all of
    the parts of the system. Lots of different
    activities occur, all at init time.
  • Improvement
  • A system initialization routine sends an
    initialization message to each component.
  • Each component initializes itself at component
    instantiation time.

50
51
Design Principle Types of Cohesion
  • Procedural Cohesion
  • Weak cohesion in which functions or processes are
    put into a same component only because they
    happen in a certain order
  • such as enter data check data, and calculation
  • They are related by order of execution rather
    than by any single problem-related function.

51
52
Design Principle Types of Cohesion
  • Communicational Cohesion
  • Module performs a series of actions related by a
    sequence of steps to be followed by the product
    and all actions are performed on the same data
  • Update record in database and send it to the
    printer.
  • database.Update (record).
  • record.Print().

52
53
Design Principle Types of Cohesion
  • Communicational Cohesion
  • Relative weak cohesion in which functions or
    processes are put into a same component because
    they act on the same data
  • such as find title of book find price of book
    find author of book find publisher of book find
    published date of book. These four activities are
    related because they all work on the same data
    book
  • The weakness is that it is narrow on one side
    (book) and arbitrarily broad on the other (find
    title, price, author, publisher, date etc)
    depending on the number of functions in the
    component. This could lead to duplication or
    redundant of functions (think about book is
    changed to PC, then all find functions needed
    to be recoded)

Dr. Dewan Tanvir Ahmed
53
54
Design Principle Types of Cohesion
  • Sequential Cohesion
  • Certain cohesion in which the output from one
    part of a component is input to the next part
  • The output of one component is the input to
    another.
  • Occurs naturally in functional programming
    languages
  • Good situation

54
55
Design Principle Types of Cohesion
  • Functional Cohesion
  • Every essential element to a single computation
    is contained in the component.
  • Best cohesion in which every processing element
    is essential to the performance of a single
    function, and all essential elements are
    contained in one component.
  • The functionally cohesive component performs the
    function for which it is designed, and only
    performs that function and nothing else.
  • Ideal solution

55
56
Examples of Cohesion-1
Time t0 Time t0 X Time t0 2X
Function A
Function A Function A Function A
Function B
Function C
logic
Function D
Function E
Coincidental Parts unrelated
Logical Similar functions
Temporal Related by time
Function A Function B Function C
Procedural Related by order of functions
57
Examples of Cohesion-2
Function A Function B Function C
Function A Function B Function C
Communicational Access same data
Sequential Output of one is input to another
Function A part 1 Function A part 2 Function A
part 3
Functional Sequential with complete, related
functions
58
Design Principle Cohesion
  • Conclusion
  • Cohesion is the measure of the functional
    relatedness of elements (instructions, data
    definitions, etc.) within a single component. In
    a good design, the cohesion of every component is
    high. Together with coupling, cohesion is one of
    the good measures of the quality of a design.

58
59
High-Level (abstract) design
Low-Level (detailed) design
59
60
Some Desirable Design Attributes
  • Hierarchical A good design should be organized
    into a well-designed hierarchy of components.
  • Modular Separate distinct concerns (data and
    processing) into distinct containers (i.e.,
    subsystems, modules, and/or classes). Hide
    implementation details and provide clean, simple
    interfaces for each container.

60
61
Some Desirable Design Attributes
  • Independent Group similar things together limit
    the amount of special knowledge that unrelated
    components may share. If you change your mind
    about something, the impact will be localized.

61
62
Some Desirable Design Attributes
  • Simple Interfaces Endless flexibility adds
    complexity. Complex interfaces mean
  • hard to understand by users and developers (e.g.,
    Unix man page syndrome)
  • many possible variations of use
  • inconvenient to change interface in order to
    eliminate bad options.
  • You can get away with flexible interfaces in a
    low-level localized setting, but the larger the
    scale, the simpler the interface should be.

62
63
Submit SRS by next week!
About PowerShow.com