Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software design principles


Published on

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

Software design principles

  1. 1. Software Design Principles
  2. 2. Software Design Principles 1Being presented byMr. Ritesh Singh
  3. 3. Thanks. 1Special thanks to Ms. Charu Jain for this initiave
  4. 4. Introduction 4Software: A set of programs which helps user to executeits task using the systemDesign: creation of a plan to construct a systemPrinciples: Rules or laws to be followedDemystifying the subjectDemystifying the subject
  5. 5. Objectives 5• Clearly understand the software designprinciples• Follow the structured approach for the softwaredesign• Understand different models
  6. 6. System Models 6System : A collection of components placed together to perform a task whichis beyond components’ individual capability.
  7. 7. System Models 7Types of System ModelProcessData-processingClassificationCompositionStimulus-response• data flow diagram• entity relation diagram• object class/inheritance diagram• State transition diagram• Used to show the principalactivities
  8. 8. System Models :: Data processing Model 8Data-flow ModelsTypes of System ModelProcessData-processingClassificationCompositionStimulus-response
  9. 9. System Models :: Data-flow Models 9• Used to model the way data is processed in the system• Notation Used:Rounded corner rectangle -> Processing stepsRectangle -> Data StoresArrows -> Flow of data
  10. 10. System Models 10Types of System ModelProcessData-processingClassificationCompositionStimulus-response
  11. 11. System Models :: Composition Model 11Data-flow ModelsTypes of System ModelProcessData-processingClassificationCompositionStimulus-response
  12. 12. System Models :: Semantic-data Model 12• Semantics of data• Identifies entity in a database, their attributesand explicit relationship b/w themNotation Used:<Name><name>An entityInput CardinalityOutput Cardinality<name> An entity orRelation attribute
  13. 13. System Models 13Types of System ModelProcessData-processingClassificationCompositionStimulus-response
  14. 14. System Models :: Classification Model 14Data-flow ModelsTypes of System ModelProcessData-processingClassificationCompositionStimulus-response
  15. 15. System Models :: Object Model 15• Represent both data and its processing• Combination of some of uses of DFD and SDMNotation Used:<class name><Attribute><Service>Object Class
  16. 16. System Models :: Data Dictionaries 16• List of name used by the systems, arranged alphabetically.Advantage: mechanism for name management store of organization information which can link analysis, design,implementation, and evaluationNames* -> entities, types, relations, attributes or services
  17. 17. Software Design 17What is software design?"all the activities involved in conceptualizing,framing, implementing, commissioning, andultimately modifying complex systems“-Wikipedia
  18. 18. Software Design:: Activities 18ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  19. 19. Software Design 19To put it simply:"the activity following requirements specificationand before programming."DesignRequirementSpecification Programming
  20. 20. Software Design:: Activities 20ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  21. 21. Software Design 21ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  22. 22. Software Design :: Process 22What is a process?A series of actions or steps taken toachieve an end.Action 1 Action 2 Action 3 Action 4 Action nPROCESS
  23. 23. Software Design :: Process 23Design Activities (Actions):ArchitecturalDesign1AbstractSpecification2
  24. 24. Software Design :: Process 24InterfaceDesign3ComponentSpecification4
  25. 25. Software Design :: Process 25DataStructureDesign5AlgorithmDesign6
  26. 26. Software Design :: Process 26Sub-systems making up the system andtheir relationshipsArchitecturalDesign1
  27. 27. Software Design :: Process 27For each sub-system, an abstract specification ofthe services it provides and the constraintsunder which it must operate is produced.AbstractSpecification2
  28. 28. Software Design :: Process 28Developing a method for two (or more) modulesin a system to connect and communicateInterfaceDesign3
  29. 29. Software Design :: Process 29Services are allocated to different components andthe interfaces of these components are designed.ComponentDesign4
  30. 30. Software Design :: Process 30The data structures used in the systemimplementation is designed in detail and specified.DataStructureDesign5*Data Structure : storing and organizing data
  31. 31. Software Design :: Process 31A specific method to create a mathematical processin solving problems.AlgorithmDesign6*Algorithm : step-by-step procedure for calculations
  32. 32. Software Design:: Activities 32ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  33. 33. Software Design 33ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  34. 34. Software Design :: Methods 341. Data flow model: data transformations2. Entity relation model: logical data structures being used3. Structural model: System components and their interactionsare documented4. Object oriented model: a model of how objects arecomposed of other objects and, usually, an object usemodel which shows how objects are used by other objects.
  35. 35. Software Design:: Activities 35ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  36. 36. Software Design 36ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  37. 37. Software Design :: Description 37Role:•Basis for detailed implementation•communication medium between designers of sub-systems•Info to system maintainers about the original intentions of the system designersNotations Used:Graphical notationsProgram description languagesInformal text
  38. 38. Software Design :: Description 381. Graphical notations:• Display the relationships between the components making up the designand to relate the design to the real-world system.• Most useful for giving an overall picture of the system.2. Program description languages:• use control and structuring constructs based on programming languageconstructs but also allow explanatory text and additional types ofstatement to be used.• intention of the designer is expressed rather than the details of how thedesign is to be implemented.3. Informal text:1. Information about design rationale or non-functional considerations maybe expressed using natural language text.Continue..
  39. 39. Software Design:: Activities 39ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  40. 40. Software Design 40ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  41. 41. Software Design :: Strategies 411. Functional design:• functional viewpoint, starting with a high-level view and progressivelyrefining this into a more detailed design.• Example: Jackson Structured Programming and the Warnier-Orr method2. Object oriented design:• system is viewed as a collection of objects rather than as functions.• JSD is a design method that falls somewhere between function orientedand object oriented design.*JSD : Jackson System Develpment
  42. 42. Software Design:: Activities 42ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  43. 43. Software Design 43ProcessProcessMethodsMethodsDescriptionDescriptionStrategiesStrategiesQualityQuality
  44. 44. Software Design :: Quality 44• The design components should be cohesive• Loosely coupledCoupling the independence of components.• looser the coupling, easier it is to adapt the design.Good Design Efficient code
  45. 45. Architectural Design 45What is a it?Initial design process of identifying sub-systemand establishing a framework for sub-systemcontrol and communication
  46. 46. Architectural Design 46System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  47. 47. Architectural Design :: System Structuring 47System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  48. 48. Architectural Design :: System Structuring 48• Decompose a system into a set of interacting sub-systems• Notations Used:• Box -> Sub system• Boxes within boxes -> sub-system has been decomposed tosub-systems• Arrow -> direction of data and/or controlSystem structuring Repository model Client-server model Abstract machine model
  49. 49. Architectural Design :: System Structuring 49System structuringRepository model Client-server model Abstract machine model• Data is held in a central database• Accessed by all sub-systemsProject repositoryDesigneditorCodeGeneratorDesignanalyzerReportGeneratorProgrameditorDesigntranslator
  50. 50. Architectural Design :: System Structuring 50System structuring Repository modelClient-server model Abstract machine model• Distributed sys model• Standalone servers offer service to sub-sys (clients)• A networkNetworkCatalogserverVideoserverClient 1PictureserverHypertextserverClient 2 Client 4Client 3
  51. 51. Architectural Design :: System Structuring 51System structuring Repository model Client-server modelAbstract machine model• Layered• Layers provide a set of service to layer above• Supports incremental development• Changeable and portableClient 2Client 2Operating systemDatabase ManagementObject ManagementVersion Management
  52. 52. Architectural Design 52System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  53. 53. Architectural Design :: Control Models 53System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  54. 54. Architectural Design ::Control models 54• Control flow b/w sub-systemControl modelsCentralized control Event-based Control
  55. 55. Architectural Design ::Control models 55Control modelsCentralized control Event-based Control• One sub-system designated as the system controllerSystemControllerComputationProcessSensorProcessesActuatorProcessesFaultHandlerLaserInterface
  56. 56. Architectural Design ::Control models 56Control modelsCentralized control Event-based Control• Driven by externally generated eventsBroadcast models Interrupt-driven models• Broadcast to all, but particularsub-system responds to it• Used in Real time sys• Interrupt handler
  57. 57. Architectural Design 57System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  58. 58. Architectural Design :: Control Models 58System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  59. 59. Architectural Design ::Modular Decomposition 59Modular DecompositionObject-oriented design Data-flow models• Sys is decomposed intoa set of communicating objects• Sys is decomposed intofunctional modules• Also called Pipeline Approach
  60. 60. Architectural Design 60System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  61. 61. Architectural Design :: Control Models 61System StructuringControl modelsModular decompositionDomain-specific architecturesActivities Involves
  62. 62. Architectural Design :: Domain-specific architecture 62Domain-specific ArchitectureGeneric models Reference models• Abstraction of manyreal systems• contains Principal characteristics• Describe a larger class of systems• Informs Sys Architect about thatClass of sysGeneric models Vs. Reference modelsDerived from “bottom-up”from existing systemDerived from “top-down”from existing system
  63. 63. Summary 63 System Models Software Design Architecture Design
  64. 64. Thank you for your time. 1