Your SlideShare is downloading. ×
Software design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software design

2,618
views

Published on

Published in: Education, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,618
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
131
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Design
  • 2. SW Design Software design is an iterative process through which requirements are translated into a ―blueprint‖ for constructing the software. Initially, the blueprint depicts a holistic view of software.
  • 3. Process of Design Engineering During the design process the software specifications are transformed into design models Models describe the details of the data structures, system architecture, interface, and components. Each design product is reviewed for quality before moving to the next phase of software development. At the end of the design process a design model and specification document is produced. This document is composed of the design models that describe the data, architecture, interfaces and components.
  • 4. Process Specification (PSPEC)Data Object Description procedural Entity- design Data Flow Relationship Diagram Diagram interface Data Dictionary design architectural State-Transition design Diagram data Control Specification (CSPEC) design THE ANALYSIS MODEL THE DESIGN MODEL
  • 5. Design Specification Models Data design – created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software. Part of the data design may occur in conjunction with the design of software architecture. More detailed data design occurs as each software component is designed. Architectural design - defines the relationships among the major structural elements of the software, the ―design patterns‖ than can be used to achieve the requirements that have been defined for the system, and the constraints that affect the way in which the architectural patterns can be applied. It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD).
  • 6. Design Specification Models Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much of the necessary information required. Procedural / Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the process specification (PSPEC), control specification (CSPEC), and state transition diagram (STD).
  • 7. Design - Fundamental Concepts Abstraction Architecture Patterns Modularity Information hiding Functional independence Refinement Refactoring 7
  • 8. Abstraction Data Abstraction Procedural Abstraction
  • 9. Architecture Design ―The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.‖Design can be represented as Structural Models  Defines the components of a system (e.g., modules, objects, filters) and  How the components are packaged and interact with one another. Framework Models  Increase level of abstraction Dynamic Models and Process Models  Predicts behavioral and reliability aspects Functional Models  Depicts functional Hierarchy.
  • 10. Patterns a pattern is ―a common solution to a common problem in a given context.‖ While architectural styles can be viewed as patterns describing the high-level organization of software (their macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their microarchitecture). Creational patterns (example: builder, factory, prototype, and singleton) Structural patterns (example: adapter, bridge, composite, decorator, façade, flyweight, and proxy) Behavioral patterns (example: command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor)
  • 11. Design Pattern Design Pattern enables a designer to determine whether the pattern :  is applicable to the current work  can be reused  can serve as a guide for developing a similar, but functionally or structurally different pattern.
  • 12. Modular Design Easier to change Easier to build Easier to maintain
  • 13. Sizing Modules: Two Views Whats How big inside?? is it?? MODULE
  • 14. Information Hiding Principle of information hiding says that a good split of modules is when modules communicate with one another with only the information necessary to achieve the s/w function. So information hiding enforces access constraints to both  procedural detail with a module, and  local data structure used by that module. Data hiding is a CRITERION for modular design. How to know what modules to create.
  • 15. Information Hiding module • algorithm controlled interface • data structure • details of external interface • resource allocation policy clients "secret" a specific design decision
  • 16. Information Hiding (Benefits) 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 16
  • 17. Functional Independence COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system. 17
  • 18. Cohesion Internal glue with which component is constructed All elements of component are directed toward and essential for performing the same task
  • 19. Range of Cohesion High Cohesion Functional Sequential Communicational Procedural Temporal Logical Coincidental Low
  • 20. Examples of Cohesion-1 Function A Function A Time t0Function Function logic Function A’ Time t0 + X B CFunction Function Time t0 + 2X D E Function A’’ Coincidental Logical Temporal Parts unrelated Similar functions Related by time Function A Function B Function C Procedural Related by order of functions
  • 21. Examples of Cohesion-2 Function A Function A Function B Function B Function C Function C Sequential Communicational Output of one is input to another Access same data Function A part 1 Function A part 2 Function A part 3 Functional Sequential with complete, related functions
  • 22. Coupling  Degree of dependence among components. No dependencies Loosely coupled-some dependencies Highly couples-many dependencies
  • 23. Ways components can be dependent References made from one to another  Component A invokes B  A depends on B for completion of its function or process Amount of data passed from one to another  Component A passes to B: a parameter, contents of an array, block of data Amount of control one has over the other  Component passes a control flag to B  Value of flag tells B the state of some resource or subsystem, process to invoke, or whether to invoke a process Degree of complexity in the interface between components  Components C and D exchange values before D can complete execution
  • 24. Range of Coupling High Coupling Content Common External Control Loose Stamp Data Uncoupled Low
  • 25. Content Coupling : (worst) When a moduleuses/alters data in another moduleCommon Coupling : 2 modules communicatingvia global dataExternal Coupling :Modules are tied to anenvironment external to the softwareControl Coupling : 2 modules communicatingwith a control flag
  • 26. Stamp Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs. Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs. No data coupling : independent modules.
  • 27. Summary COHESION COUPLING The measure of strength The measure of of the association of interdependence of one elements within a module module to another It is the degree to which It describes the the responsibility of a relationship between single component form a software components meaningful unit It is a property or It is a property of a characteristic of an collection of modules individual module
  • 28. Refinement Refinement is a process of elaboration It is a top-down design strategy A program is developed by successfully refining levels of procedural details
  • 29. Stepwise Refinement Open Door walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesnt turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat
  • 30. Refactoring Fowler [FOW99] defines refactoring in the following manner:  "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.