Sw Software Design


Published on

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sw Software Design

  1. 1. SW Software Design SW
  2. 2. Design <ul><li>Architecture </li></ul><ul><ul><li>High Level Design </li></ul></ul><ul><ul><li>Module Decomposition </li></ul></ul><ul><ul><ul><li>Functional/OO </li></ul></ul></ul><ul><ul><li>Design Document/IEEE Std.1016 SDD </li></ul></ul><ul><li>Detailed Design </li></ul><ul><li>Formal Methods </li></ul><ul><li>UML </li></ul><ul><ul><li>Overview </li></ul></ul><ul><ul><li>Graphical Diagrams </li></ul></ul>
  3. 3. Architectural Design <ul><li>Establishing basing structural framework of an application - decomposition ( subsystems, modules ), interface specification and communication . </li></ul><ul><ul><li>subsystems - independent components/modules of an application </li></ul></ul><ul><ul><li>modules - provide one or more services to other modules </li></ul></ul><ul><li>Output - Design Document/SDD </li></ul>
  4. 4. Architecture Design Choice <ul><li>Affects: performance, robustness, distributabilty and maintainability and development costs . </li></ul><ul><li>Application Constraints: </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><ul><li>localize critical operations </li></ul></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><ul><li>access control, layered structure </li></ul></ul></ul><ul><ul><li>Safety </li></ul></ul><ul><ul><ul><li>costly validation, single component for safety-related operations </li></ul></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><ul><li>include redundant components </li></ul></ul></ul><ul><ul><li>Maintainability </li></ul></ul><ul><ul><ul><li>self-contained components </li></ul></ul></ul>
  5. 5. Structure Design <ul><li>Repository Design </li></ul><ul><li>Client-Server Design </li></ul><ul><li>Layered Design </li></ul><ul><li>Control Models </li></ul><ul><ul><li>Centralized control </li></ul></ul><ul><ul><ul><li>Hierarchic Design </li></ul></ul></ul><ul><ul><ul><li>Centralized Design </li></ul></ul></ul><ul><ul><li>Event Driven </li></ul></ul><ul><ul><ul><li>Broadcast </li></ul></ul></ul><ul><ul><ul><li>Interrupt driven </li></ul></ul></ul>
  6. 6. Repository Design Registrar Staff Professor Client Admin Client Student Database Professor Database Schedule Class Database Adv : - share large database - integrate tools w/ same data model Drbk : - performance - evolution difficult - forces the same policy on subsystems - difficult to distribute Student Client
  7. 7. Client/Server Design Registrar Staff Student Database Professor Database Schedule Class Database Payroll HR Adv : - distributed - scalable Drbks : -naming/registry -diff to anticipate prbls w/ add a srvr -independent data mgmt/recovery Student Client Professor Client
  8. 8. Layered Design Kernel Memory Mgmt I/O - Dev.Drv File Server - GUI Adv : - incremental dev. - portability
  9. 9. Hierarchic Control Design Adv : - call/return - only for sequential tasks
  10. 10. Centralized Design Adv : - parallel tasks - RTS System Controller Input Sensor Program Program/Data
  11. 11. Broadcast Design network Client A Client B Client C Client D
  12. 12. Interrupt Design IH 2 Proc IH 3 Proc IH 5 Proc IH 4 Proc IH 1 Proc Adv : - fast Drbks : -complex to implement/test/validate
  13. 13. Design Entities <ul><li>Procedural design </li></ul><ul><ul><li>Procedures </li></ul></ul><ul><li>Modular design </li></ul><ul><ul><li>Modules </li></ul></ul><ul><li>Object-oriented design </li></ul><ul><ul><li>Classes </li></ul></ul><ul><li>Multithreded, multiprocessors, multitasking </li></ul><ul><ul><li>Threads, tasks, processes </li></ul></ul>
  14. 14. Compiler: Functional view Lexical analysis Syntax analysis Semantic analysis Build symbol table Code generation input program program symbols symbolic program syntax tree symbol table analyzed program Object code
  15. 15. Compiler: Object oriented view Source program Syntax tree Symbol table Analyzed program Object code
  16. 16. Software Design Process Requirements Specification Architectural Design Functional Specification Architecture Chart UI Design Module/Algorithm Design UI Specification Database Design Module/Algorithm Specification Database Specification Design Activities API, algorithms database
  17. 17. Design Methods <ul><li>Informal ad hoc </li></ul><ul><ul><li>Formal requirements </li></ul></ul><ul><ul><li>Formal specifications </li></ul></ul><ul><li>Structured </li></ul><ul><ul><li>Models supported </li></ul></ul><ul><ul><ul><li>data-flow model - data transfers </li></ul></ul></ul><ul><ul><ul><li>entity-relation model - basic entities and relations </li></ul></ul></ul><ul><ul><ul><li>structural model - components and interactions </li></ul></ul></ul><ul><ul><ul><li>object-oriented model - objects, relationships and interactions, classes/methods </li></ul></ul></ul>
  18. 18. C++/Java C++ Classes, variables, functions class myclass { int myclassvariable; public: int myclass (int); ~myclass(); void function(int i) } Java Classes, variables, methods public class myclass { int myclassvariable; myclass (int){}; void function(int i){}; }
  19. 19. Architecture Chart HTML GUI WML GUI SQL Database Server WAP Terminal Web Terminal JDBC HTML WML Template files ASCII
  20. 20. Design Document Outline <ul><li>Software program overview </li></ul><ul><ul><li>broad terms overview, high level discussion of the design alternatives. </li></ul></ul><ul><ul><li>goals for the architecture, problem addressed. </li></ul></ul><ul><li>Subprograms and organization chart </li></ul><ul><ul><li>major clusters of functionality, communication and dependencies. </li></ul></ul><ul><li>Change scenarios </li></ul><ul><ul><li>most likely changes in the program and how each change will be addresses. </li></ul></ul><ul><li>Reuse analysis and buy vs build decisions </li></ul><ul><ul><li>arguments for what will be build, bought or reused. </li></ul></ul>
  21. 21. Approach to Standard Functional Areas <ul><li>External software interfaces ( APIs ) </li></ul><ul><li>User interface - prototype </li></ul><ul><li>Database organization - content, type of database </li></ul><ul><li>Data storage - non database data, file formats, major data structures </li></ul><ul><li>Key algorithms </li></ul><ul><li>Memory management </li></ul><ul><li>String storage - stiles, error messages </li></ul><ul><li>Concurrency/threads </li></ul><ul><li>Security - how the design will be affected </li></ul><ul><li>Localization </li></ul><ul><li>Networking - multi-user </li></ul><ul><li>Portability </li></ul><ul><li>Programming language </li></ul><ul><li>Error handling </li></ul>
  22. 22. IEEE Design Description Overview Std. 1016 <ul><li>SDD: Standard Design Description </li></ul><ul><ul><li>Introduction </li></ul></ul><ul><ul><li>Decomposition Description </li></ul></ul><ul><ul><li>Dependency Description </li></ul></ul><ul><ul><li>Interface Description </li></ul></ul><ul><ul><li>Detailed Design Description </li></ul></ul>
  23. 23. SDD Modular Design Methodology <ul><li>Introduction </li></ul><ul><ul><li>Purpose </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Definitions and acronyms </li></ul></ul><ul><ul><li>References </li></ul></ul><ul><ul><li>Overview </li></ul></ul><ul><li>Decomposition Description </li></ul><ul><ul><li>Module Decomposition </li></ul></ul><ul><ul><ul><li>Module 1 Description </li></ul></ul></ul><ul><ul><ul><li>Module 2 Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><li>Task Decomposition </li></ul></ul><ul><ul><ul><li>Task 1 Description </li></ul></ul></ul><ul><ul><ul><li>Task 2 Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul>
  24. 24. SDD Modular Design Methodology <ul><li>3. Dependency Description </li></ul><ul><ul><li>Module dependency Description </li></ul></ul><ul><ul><li>Task Dependency Description </li></ul></ul><ul><li>4. Interface Description </li></ul><ul><ul><li>Module Interface Description </li></ul></ul><ul><ul><ul><li>Module 1 Interface Description </li></ul></ul></ul><ul><ul><ul><li>Module 2 Interface Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><li>Task Interface Description </li></ul></ul><ul><ul><ul><li>Task 1 Interface Description </li></ul></ul></ul><ul><ul><ul><li>Task 2 Interface Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul>
  25. 25. SDD Modular Design Methodology <ul><li>5. Detailed Design Description </li></ul><ul><ul><li>Module Detailed Description </li></ul></ul><ul><ul><ul><li>Module 1 Detailed Description </li></ul></ul></ul><ul><ul><ul><li>Module 2 Detailed Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><li>Task Detailed Description </li></ul></ul><ul><ul><ul><li>Task 1 Detailed Description </li></ul></ul></ul><ul><ul><ul><li>Task 2 Detailed Description </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul>
  26. 26. SDD Object Design Methodology <ul><li>Introduction </li></ul><ul><ul><li>Purpose </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Definitions and acronyms </li></ul></ul><ul><ul><li>References </li></ul></ul><ul><ul><li>Overview </li></ul></ul><ul><li>Decomposition Description </li></ul><ul><ul><li>Class 1 Description </li></ul></ul><ul><ul><li>Class 2 Description </li></ul></ul><ul><ul><li>… </li></ul></ul>
  27. 27. SDD Object Design Methodology <ul><li>3. Dependency Description </li></ul><ul><ul><li>Object Interaction Description </li></ul></ul><ul><ul><li>Aggregation Description </li></ul></ul><ul><ul><li>Inheritance Description </li></ul></ul><ul><li>4. Interface Description </li></ul><ul><ul><li>Class 1 Interface Description </li></ul></ul><ul><ul><li>Class 2 Interface Description </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>5. Detailed Design Description </li></ul><ul><ul><li>Class 1 Detailed Description </li></ul></ul><ul><ul><li>Class 2 Detailed Description </li></ul></ul><ul><ul><li>… </li></ul></ul>
  28. 28. Detailed Design Formal Design Approach Formal Design Approach Very Formal Design Approach Informal Design Approach <ul><li>for a subprogram/module/object </li></ul><ul><li>done by the developer </li></ul>Project difficulty Programmer experience HIGH LOW HIGH LOW
  29. 29. Formal Methods <ul><li>(theory, logic, algebra). Large % of the software developed use formal methods. </li></ul><ul><ul><li>Formal specifications </li></ul></ul><ul><ul><ul><li>Way of discovering specification errors and presenting the application specification in a unambiguous way -fewer errors. </li></ul></ul></ul><ul><ul><li>Specification analysis and proof </li></ul></ul><ul><ul><li>Application verification/validation </li></ul></ul>
  30. 30. Critical Software Applications Development <ul><li>Costs of failure are high - </li></ul><ul><ul><li>Properties: safety, reliability, security . </li></ul></ul><ul><ul><li>Have high validation costs. </li></ul></ul><ul><li>Examples: </li></ul><ul><ul><ul><li>Air traffic control system ( Hall 1996 ) </li></ul></ul></ul><ul><ul><ul><li>Railway signaling systems ( Dehbonei and Mejia, 1995 ) </li></ul></ul></ul><ul><ul><ul><li>Spacecraft systems ( Easterbrook 1998 ) </li></ul></ul></ul><ul><ul><ul><li>Medical control systems ( Jackey 1997 ) </li></ul></ul></ul><ul><ul><ul><li>Software tool specification ( Neil 1998 ) </li></ul></ul></ul><ul><ul><ul><li>IBM’s CICS system ( Wordsworth 1991 ) </li></ul></ul></ul>
  31. 31. UML Overview <ul><li>UML </li></ul><ul><ul><li>Modeling language for specifying, visualizing, constructing and documenting software programs. </li></ul></ul><ul><ul><ul><li>Model elements, Notation and Guidelines </li></ul></ul></ul><ul><li>Motivation </li></ul><ul><ul><li>communication among project teams </li></ul></ul><ul><ul><li>tools for automation of software design/validation/production (same as component technology, visual programming) </li></ul></ul><ul><li>SW Program </li></ul><ul><ul><li>A set of nearly independent set of graphical diagrams </li></ul></ul>
  32. 32. UML Graphical Diagrams <ul><li>Use Case Diagram </li></ul><ul><li>Static Structure Diagrams </li></ul><ul><ul><li>Class/Object Diagram </li></ul></ul><ul><li>Behavior Diagrams </li></ul><ul><ul><li>Interaction Diagrams </li></ul></ul><ul><ul><ul><li>Sequence diagram </li></ul></ul></ul><ul><ul><li>Statechart Diagrams </li></ul></ul><ul><ul><li>Activity Diagrams </li></ul></ul><ul><li>Implementation Diagrams </li></ul><ul><ul><li>Component Diagram </li></ul></ul><ul><ul><li>Deployment Diagram </li></ul></ul>
  33. 33. Use Case Diagram <ul><li>Display the user interaction with the application </li></ul><ul><li>Provide an external view of the application </li></ul><ul><li>Basis for testing </li></ul><ul><li>Use Case Relationships </li></ul><ul><ul><li>Include - to avoid repetition of use cases </li></ul></ul><ul><ul><li>Generalization - describe a variation casually </li></ul></ul><ul><ul><li>Extend - declare extension points in the base case </li></ul></ul>
  34. 34. Use Case Diagram Check Grade Register Classes Database Query Authorize Student Input Grades Student Professor Registrar Staff Max Credits <<include>> <<include>> <<include>> <<include>> Include Generalization Use Case
  35. 35. Class Diagram <ul><li>Describes the type of objects and the static relationships ( associations and subtypes ) </li></ul><ul><li>Class </li></ul><ul><ul><li>attributes, multiplicity, generalization, role, constraints, operations </li></ul></ul><ul><li>Associations </li></ul><ul><ul><li>relations between instances of classes, with multiplicity (*, x, x..y | x, y  N) </li></ul></ul><ul><ul><li>navigability (unidirectional/bi-directional) </li></ul></ul>
  36. 36. Class Diagram Catalog Entry exam date : Date grade : String passed():Boolean Class subject : String professor : String gradedPNP():String 1 * * 1 If CatalogEntry.Student.isCurrent is “n” then Catalog.Entry.grade must be “N” Multiplicity: mandatory Association Generalization Class Constraint Job 0..1 Multiplicity: optional Attribute Operation Multiplicity: Many-valued Navigability Student name : String address : String ID : Long Integer isCurrent():String Graduate department: String isCurrent():String Undergraduate major: String isCurrent():String
  37. 37. Object/Class Diagrams <ul><li>Object diagram </li></ul><ul><ul><li>objects allocated at a certain point in time </li></ul></ul><ul><li>Classification -relation of an object to a type </li></ul><ul><ul><li>Single classification - single type, subtypes </li></ul></ul><ul><ul><li>Multiple classification - several types </li></ul></ul><ul><ul><li>Static classification - separation between types/states </li></ul></ul><ul><ul><li>Dynamic classification - change type within the subtyping structure </li></ul></ul>
  38. 38. Object/Class Diagrams Employee name Male Female Developer QA/Test Design Job <<dynamic>> Sex {complete} Discriminator Manager Software: MGMT name = “Name” MGMT * 1 Software PM: MGMT name = “Name” QA Manager: MGMT name = “Name” Software PM: MGMT name = “Name” Engineer: Developer name = “Name” Engineer: Design name = “Name” Engineer: QA/Test name = “Name” Engineer: Developer name = “Name” Object Diagram showing instances of the above class diagram Class Diagram with Multiple and Dynamic Classification Sex: M/F Sex: M/F Sex: M/F Sex: M/F Sex: M/F Sex: M/F Sex: M/F Sex: M/F
  39. 39. Statechart Diagram <ul><li>All possible states that a particular object can get into </li></ul><ul><li>How the object state changes as a result of events that reach the object </li></ul><ul><li>Enhancements </li></ul><ul><ul><li>Superstates </li></ul></ul><ul><ul><li>Concurrent Statechart Diagrams </li></ul></ul>
  40. 40. Statechart Diagram State C State B State A State D -describes the behavior of a model element such as an object or interaction Trigger condition A to B Trigger condition B to D Trigger condition C to A Trigger condition C to B Trigger condition B to C start self-transition transition state
  41. 41. Sequence Diagram <ul><li>Shows a number of example objects and the messages that are passed between these objects within the use case </li></ul><ul><li>Time on the vertical dimension and different objects on the horizontal dimension </li></ul><ul><li>Also valuable for concurrent processes </li></ul>
  42. 42. Sequence Diagram Initiate request Init servlet new Gdocument(); Connect to the database servlet.setDomaine(); servletgetConnection(); HTTP request on the server TCP/IP port 80 Database call prepareStatement() executeQuerry() Response to the SQL request Database call return Read data getString(); Generate HTML output doc.p(); HTML return return(); Display WEB page Web Client Web Server Database
  43. 43. Activity Diagram <ul><li>A state machine of the procedure itself, the states represent the performance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities </li></ul><ul><ul><li>Branch - conditional behavior, a single incoming transition and multiple outgoing transitions </li></ul></ul><ul><ul><li>Merge - multiple input transitions and one single output </li></ul></ul><ul><ul><li>Fork - parallel activities, one incoming transition and several outgoing transitions </li></ul></ul><ul><ul><li>Join - multiple input transitions and one single output </li></ul></ul><ul><ul><li>(*) Dynamic concurrency </li></ul></ul><ul><ul><li>Swimlanes - for clarity </li></ul></ul><ul><li>Recommended for: </li></ul><ul><ul><li>analyzing a use case, understanding workflow, describing a complicated sequential algorithm, dealing with multithreaded applications </li></ul></ul>
  44. 44. Activity Diagram Present lecture Prepare slides Turn on the projector Tune the projector [found projector] [no projector] Use blackboard Begin lecture Start Fork Join End
  45. 45. Component Diagram <ul><li>Structure of the code </li></ul><ul><li>Shows various components of the application and their dependencies </li></ul><ul><li>Component </li></ul><ul><ul><li>a physical module of the code </li></ul></ul><ul><li>Dependencies </li></ul><ul><ul><li>how changes to one component may cause other components to change </li></ul></ul>
  46. 46. Component Diagram WML Interface Search Engine Database query
  47. 47. Deployment Diagram <ul><li>Structure of the run time program </li></ul><ul><li>Physical relationships among software and hardware components </li></ul><ul><li>Node - a computational unit - in most cases a hardware device </li></ul><ul><li>Connection - communication path over which nodes interact </li></ul>
  48. 48. Deployment Diagram WAP Terminal WML Interface Server Search Engine Database query Component Communication Interface Application Connection Contained object(s) Node