Software Design_Se lect16 btech


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Design_Se lect16 btech

  1. 1. Software Design • Deriving a solution which satisfies software requirements
  2. 2. Purpose of Design
  3. 3. Purpose of Design• Design is where customer requirements, business needs, and technical considerations all come together in the formulation of a product or system• The design model provides detail about the software data structures, architecture, interfaces, and components• The design model can be assessed for quality and be improved before code is generated and tests are conducted – Does the design contain errors, inconsistencies, or omissions? – Are there better design alternatives? – Can the design be implemented within the constraints, schedule, and cost that have been established? 3
  4. 4. From Analysis Model to Design Model• Each element of the analysis model provides information that is necessary to create the four design models – The data/class design transforms analysis classes into design classes along with the data structures required to implement the software – The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system – The interface design describes how the software communicates with systems that interoperate with it and with humans that use it – The component-level design transforms structural elements of the software architecture into a procedural 4 description of software components
  5. 5. From Analysis Model toDesign Model (continued) Component-level Design (Class-based model, Flow-oriented model Behavioral model) Interface Design (Scenario-based model, Flow-oriented model Behavioral model) Architectural Design (Class-based model, Flow-oriented model) Data/Class Design (Class-based model, Behavioral model) 5
  6. 6. Task Set for Software Design1) Examine the information domain model and design appropriate data structures for data objects and their attributes2) Using the analysis model, select an architectural style (and design patterns) that are appropriate for the software3) Partition the analysis model into design subsystems and allocate these subsystems within the architecture a) Design the subsystem interfaces b) Allocate analysis classes or functions to each subsystem4) Create a set of design classes or components a) Translate each analysis class description into a design class b) Check each design class against design criteria; consider inheritance issues c) Define methods associated with each design class d) Evaluate and select design patterns for a design class or subsystem 7
  7. 7. Task Set for Software Design(continued)5) Design any interface required with external systems or devices6) Design the user interface7) Conduct component-level design a) Specify all algorithms at a relatively low level of abstraction b) Refine the interface of each component c) Define component-level data structures d) Review each component and correct all errors uncovered5) Develop a deployment model  Show a physical layout of the system, revealing which components will be located where in the physical computing environment 8
  9. 9. Stages of Design • Problem understanding – Look at the problem from different angles to discover the design requirements. • Identify one or more solutions – Evaluate possible solutions and choose the most appropriate depending on the designers experience and available resources. • Describe solution abstractions – Use graphical, formal or other descriptive notations to describe the components of the design. • Repeat process for each identified abstraction until the design is expressed in primitive terms.
  10. 10. Phases in the Design Process
  11. 11. Design Phases• Architectural design: Identify sub-systems.• Abstract specification: Specify sub-systems.• Interface design: Describe sub-system interfaces.• Component design: Decompose sub-systems into components.• Data structure design: Design data structures to hold problem data.• Algorithm design: Design algorithms for problem functions.
  12. 12. Phases in the Design Process Requir ements specificaion t Design acti vitiesAr chitectural Abstract Interface Component Data Algorithm design specificaio t design design structur e design n design Softw are Data System Interface Component Algorithm specificaion t structurearchitectur e specifica t ion specificaion t specifica t ion specificaion t Design pr oducts
  13. 13. Design Phases• Architectural design• Abstract specification• Interface design• Component design• Data structure design• Algorithm design
  14. 14. Hierarchical Design Structure System level Sub-system level
  15. 15. Top-down Design• In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level.• In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
  16. 16. Design methods
  17. 17. Design methods• Many methods support comparable views of a system.• A data flow view showing data transformations.• An entity-relation view describing the logical data structures.• A structural view showing system components and their interactions.
  18. 18. Design Description
  19. 19. Design Description• Graphical notations: Used to display component relationships.• Informal text: Natural language description.
  20. 20. Design Strategies
  21. 21. Design Strategies• Functional design – The system is designed from a functional viewpoint. The system state is centralized and shared between the functions operating on that state.• Object-oriented design – The system is viewed as a collection of interacting objects. The system state is decentralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods.
  22. 22. Functional View of a CompilerSource Tokens Tokens Syntax Objectprogram tree code Build Generate Scan Analyse symbol code source table Error Symbols Symbols indicator Symbol Output table errors Error messages
  23. 23. Object-oriented View of a Compiler Scan Add Source Token Symbol program stream table Check Get Syntax Err or Gr ammar tree messages Build Print Generate Abstract Object code code Generate
  24. 24. Mixed-strategy Design• Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary.• Good software engineers should select the most appropriate approach for whatever sub-system is being designed.
  25. 25. Design Quality
  26. 26. Qualitys Role• The importance of design is quality• Design is the place where quality is fostered – Provides representations of software that can be assessed for quality – Accurately translates a customers requirements into a finished software product or system – Serves as the foundation for all software engineering activities that follow• Without design, we risk building an unstable system that – Will fail when small changes are made – May be difficult to test – Cannot be assessed for quality later in the software process when time is short and most of the budget has been spent• The quality of the design is assessed through a series of formal technical reviews or design walkthroughs 27
  27. 27. Design Concepts
  28. 28. What is…..• Abstraction• Architecture• Patterns
  29. 29. Design Concepts• Abstraction – Procedural abstraction – a sequence of instructions that have a specific and limited function – Data abstraction – a named collection of data that describes a data object• Architecture – The overall structure of the software and the ways in which the structure provides conceptual integrity for a system – Consists of components, connectors, and the relationship between them• Patterns – A design structure that solves a particular design problem within a specific context – It provides a description that enables a designer to determine whether the pattern is applicable, whether the pattern can be reused, and whether the pattern can serve as a guide for developing similar patterns 30
  30. 30. Design Concepts (continued)• Modularity – Separately named and addressable components (i.e., modules) that are integrated to satisfy requirements (divide and conquer principle) – Makes software intellectually manageable so as to grasp the control paths, span of reference, number of variables, and overall complexity• Information hiding – The designing of modules so that the algorithms and local data contained within them are inaccessible to other modules – This enforces access constraints to both procedural (i.e., implementation) detail and local data structures• Functional independence – Modules that have a "single-minded" function and an aversion to excessive interaction with other modules – High cohesion – a module performs only a single task – Low coupling – a module has the lowest amount of connection needed with other modules 31
  31. 31. Design Concepts (continued)• Stepwise refinement – Development of a program by successively refining levels of procedure detail – Complements abstraction, which enables a designer to specify procedure and data and yet suppress low-level details• Refactoring – A reorganization technique that simplifies the design (or internal code structure) of a component without changing its function or external behavior – Removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failures• Design classes – Refines the analysis classes by providing design detail that will enable the classes to be implemented – Creates a new set of design classes that implement a software infrastructure to support the business solution 32
  32. 32. Types of Design Classes
  33. 33. Types of Design Classes• User interface classes – define all abstractions necessary for human-computer interaction (usually via metaphors of real-world objects)• Business domain classes – refined from analysis classes; identify attributes and services (methods) that are required to implement some element of the business domain• Process classes – implement business abstractions required to fully manage the business domain classes• Persistent classes – represent data stores (e.g., a database) that will persist beyond the execution of the software• System classes – implement software management and control functions that enable the system to operate and communicate within its computing environment and the outside world 34
  34. 34. Characteristics of a Well-Formed Design Class
  35. 35. Characteristics of a Well-Formed Design Class• Complete and sufficient – Contains the complete encapsulation of all attributes and methods that exist for the class – Contains only those methods that are sufficient to achieve the intent of the class• Primitiveness – Each method of a class focuses on accomplishing one service for the class• High cohesion – The class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities• Low coupling – Collaboration of the class with other classes is kept to an acceptable minimum – Each class should have limited knowledge of other classes in other subsystems 36
  36. 36. The Design Model Component-level Design Interface Design Architectural Design Data/Class Design
  37. 37. Introduction• Design model elements are not always developed in a sequential fashion – Preliminary architectural design sets the stage – It is followed by interface design and component-level design, which often occur in parallel• The design model has the following layered elements – Data/class design – Architectural design – Component-level Design Interface design – Component-level design Interface Design• A fifth element that follows all of the others is deployment-level design Architectural Design Data/Class Design 38
  38. 38. Design Elements
  39. 39. Design Elements• Data/class design – Creates a model of data and objects that is represented at a high level of abstraction• Architectural design – Depicts the overall layout of the software• Interface design – Tells how information flows into and out of the system and how it is communicated among the components defined as part of the architecture – Includes the user interface, external interfaces, and internal interfaces• Component-level design elements – Describes the internal detail of each software component by way of data structure definitions, algorithms, and interface specifications• Deployment-level design elements – Indicates how software functionality and subsystems will be allocated within the physical computing environment that will support the software 40
  40. 40. Pattern-based Software Design
  41. 41. Pattern-based Software Design• Mature engineering disciplines make use of thousands of design patterns for such things as buildings, highways, electrical circuits, factories, weapon systems, vehicles, and computers• Design patterns also serve a purpose in software engineering• Architectural patterns – Define the overall structure of software – Indicate the relationships among subsystems and software components – Define the rules for specifying relationships among software elements• Design patterns – Address a specific element of the design such as an aggregation of components or solve some design problem, relationships among components, or the mechanisms for effecting inter-component communication – Consist of creational, structural, and behavioral patterns• Coding patterns – Describe language-specific patterns that implement an algorithmic or data structure element of a component, a specific interface protocol, or a mechanism for communication among components 42 
  42. 42. Architectural Design - Introduction - Data design - Software architectural styles - Architectural design process - Assessing alternative architectural designs
  43. 43. Introduction
  44. 44. Definitions• The software architecture of a program or computing system is the structure or structures of the system which comprise – The software components – The externally visible properties of those components – The relationships among the components• Software architectural design represents the structure of the data and program components that are required to build a computer-based system• An architectural design model is transferable – It can be applied to the design of other systems – It represents a set of abstractions that enable software engineers to describe architecture in predictable ways 45
  45. 45. Architectural Design Process• Basic Steps – Creation of the data design – Derivation of one or more representations of the architectural structure of the system – Analysis of alternative architectural styles to choose the one best suited to customer requirements and quality attributes – Elaboration of the architecture based on the selected architectural style• A database designer creates the data architecture for a system to represent the data components• A system architect selects an appropriate architectural style derived during system engineering and software requirements analysis 46
  46. 46. Emphasis on SoftwareComponents• A software architecture enables a software engineer to – Analyze the effectiveness of the design in meeting its stated requirements – Consider architectural alternatives at a stage when making design changes is still relatively easy – Reduce the risks associated with the construction of the software• Focus is placed on the software component – A program module – An object-oriented class – A database – Middleware 47
  47. 47. Importance of Software Architecture• Representations of software architecture are an enabler for communication between all stakeholders interested in the development of a computer-based system• The software architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity• The software architecture constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together 48
  48. 48. Software Architectural Styles
  49. 49. Software Architectural Style• The software that is built for computer-based systems exhibit one of many architectural styles• Each style describes a system category that encompasses – A set of component types that perform a function required by the system – A set of connectors (subroutine call, remote procedure call, data stream, socket) that enable communication, coordination, and cooperation among components – Semantic constraints that define how components can be integrated to form the system – A topological layout of the components indicating their runtime interrelationships 50
  50. 50. A Taxonomy of Architectural Styles Independent Components Communicating Event Systems Processes Implicit Explicit Client/Server Peer-to-Peer Invocation Invocation Data Flow Data-Centered Batch Sequential Pipe and Repository Blackboard Filter Virtual Machine Call and Return Main Program Object and Subroutine Layered Oriented Interpreter Rule-Based 51 System Remote Procedure Call
  51. 51. Data Flow StyleValidate Sort Update Report 52
  52. 52. Data Flow Style• Has the goal of modifiability• Characterized by viewing the system as a series of transformations on successive pieces of input data• Data enters the system and then flows through the components one at a time until they are assigned to output or a data store• Batch sequential style – The processing steps are independent components – Each step runs to completion before the next step begins• Pipe-and-filter style – Emphasizes the incremental transformation of data by successive components – The filters incrementally transform the data (entering and exiting via streams) – The filters use little contextual information and retain no state between instantiations – The pipes are stateless and simply exist to move data between filters 53
  53. 53. Data Flow Style (continued)• Advantages – Has a simplistic design in the limited ways in which the components interact with the environment – Consists of no more and no less than the construction of its parts – Simplifies reuse and maintenance – Is easily made into a parallel or distributed execution in order to enhance system performance• Disadvantages – Implicitly encourages a batch mentality so interactive applications are difficult to create in this style – Ordering of filters can be difficult to maintain so the filters cannot cooperatively interact to solve a problem – Exhibits poor performance • Filters typically force the least common denominator of data representation (usually ASCII stream) • Filter may need unlimited buffers if they cannot start producing output until they receive all of the input • Each filter operates as a separate process or procedure call, thus incurring overhead in set-up and take-down time 54
  54. 54. Data Flow Style (continued)• Use this style when it makes sense to view your system as one that produces a well-defined easily identified output – The output should be a direct result of sequentially transforming a well-defined easily identified input in a time-independent fashion 55
  55. 55. Call-and-Return Style Main module Subroutine B Subroutine ASubroutine A-1 Subroutine A-2 Application layer Class V Class W Transport layer Network layer Class X Class Y Data layer Class Z 56 Physical layer
  56. 56. Call-and-Return Style• Has the goal of modifiability and scalability• Has been the dominant architecture since the start of software development• Main program and subroutine style – Decomposes a program hierarchically into small pieces (i.e., modules) – Typically has a single thread of control that travels through various components in the hierarchy• Remote procedure call style – Consists of main program and subroutine style of system that is decomposed into parts that are resident on computers connected via a network – Strives to increase performance by distributing the computations and taking advantage of multiple processors – Incurs a finite communication time between subroutine call and response 57
  57. 57. Call-and-Return Style (continued)• Object-oriented or abstract data type system – Emphasizes the bundling of data and how to manipulate and access data – Keeps the internal data representation hidden and allows access to the object only through provided operations – Permits inheritance and polymorphism• Layered system – Assigns components to layers in order to control inter-component interaction – Only allows a layer to communicate with its immediate neighbor – Assigns core functionality such as hardware interfacing or system kernel operations to the lowest layer – Builds each successive layer on its predecessor, hiding the lower layer and providing services for the upper layer – Is compromised by layer bridging that skips one or more layers to improve runtime performance• Use this style when the order of computation is fixed, when interfaces are specific, and when components can make no useful progress while awaiting the results of request to other components 58
  58. 58. Data-Centered StyleClient A Client B Client C Shared DataClient D Client E Client F 59
  59. 59. Data-Centered Style (continued)• Has the goal of integrating the data• Refers to systems in which the access and update of a widely accessed data store occur• A client runs on an independent thread of control• The shared data may be a passive repository or an active blackboard – A blackboard notifies subscriber clients when changes occur in data of interest• At its heart is a centralized data store that communicates with a number of clients• Clients are relatively independent of each other so they can be added, removed, or changed in functionality• The data store is independent of the clients 60
  60. 60. Data-Centered Style (continued)• Use this style when a central issue is the storage, representation, management, and retrieval of a large amount of related persistent data• Note that this style becomes client/server if the clients are modeled as independent processes 61
  61. 61. Virtual Machine Style Program Program Data Instructions Interpretation Program Engine Internal State 62
  62. 62. Virtual Machine Style• Has the goal of portability• Software systems in this style simulate some functionality that is not native to the hardware and/or software on which it is implemented – Can simulate and test hardware platforms that have not yet been built – Can simulate "disaster modes" as in flight simulators or safety- critical systems that would be too complex, costly, or dangerous to test with the real system• Examples include interpreters, rule-based systems, and command language processors• Interpreters – Add flexibility through the ability to interrupt and query the program and introduce modifications at runtime – Incur a performance cost because of the additional computation involved in execution• Use this style when you have developed a program or some 63 form of computation but have no make of machine to directly
  63. 63. Independent Component Style Client A Client B Server Client C Client D Peer W Peer X Peer Y Peer Z 64
  64. 64. Independent Component Style• Consists of a number of independent processes that communicate through messages• Has the goal of modifiability by decoupling various portions of the computation• Sends data between processes but the processes do not directly control each other• Event systems style – Individual components announce data that they wish to share (publish) with their environment – The other components may register an interest in this class of data (subscribe) – Makes use of a message component that manages communication among the other components – Components publish information by sending it to the message manager – When the data appears, the subscriber is invoked and receives the data – Decouples component implementation from knowing the names 65 (More on next slide) and locations of other components
  65. 65. Independent Component Style(continued)• Communicating processes style – These are classic multi-processing systems – Well-know subtypes are client/server and peer-to-peer – The goal is to achieve scalability – A server exists to provide data and/or services to one or more clients – The client originates a call to the server which services the request• Use this style when – Your system has a graphical user interface – Your system runs on a multiprocessor platform – Your system can be structured as a set of loosely coupled components – Performance tuning by reallocating work among processes is important – Message passing is sufficient as an interaction mechanism among 66 components
  66. 66. Heterogeneous Styles• Systems are seldom built from a single architectural style• Three kinds of heterogeneity – Locationally heterogeneous • The drawing of the architecture reveals different styles in different areas (e.g., a branch of a call-and-return system may have a shared repository) – Hierarchically heterogeneous • A component of one style, when decomposed, is structured according to the rules of a different style – Simultaneously heterogeneous • Two or more architectural styles may both be appropriate descriptions for the style used by a computer-based system 67