Design: HOW to implement a systemDesign IssuesDesignSystem DesignSlide 5Design PrinciplesDesign Principles (cont.)Slide 8System ArchitectureSubsystem IdentificationSubsystemSubsystem DiscussionSubsystem RelationshipsClient-Server RelationshipPeer-to-Peer RelationshipStrategies for DecompositionsLayered SubsystemsExample: Layered architectureClosed ArchitecturesOpen ArchitecturesProperties of Layered ArchitecturesPartitioned ArchitecturesEx: Partitioned ArchitectureTypical Application ArchitectureSystem TopologyEx: Pipeline TopologyEx: Star ToplogyModularityAbstractionAbstraction (cont.)Cohesion(Weak) Types of cohesiveness(Better) Types of cohesivenessExample: Poor CohesionExample: Good CohesionCouplingCoupling (cont.)Information HidingSlide 39Abstract data typesIdentifying ConcurrencyDetermining Concurrent TasksManagement of Data StoresFile Data StoresDatabase Data StoresSlide 46Global ResourcesSoftware Control MechanismInternal ControlExternal ControlProcedure-driven systemsEvent-Driven SystemsConcurrent SystemsBoundary ConditionsIdentify Trade-off PrioritiesTopic Design: HOW to implement a systemGoals:Satisfy the requirementsSatisfy the customerReduce development costsProvide reliabilitySupport maintainabilityPlan for future modificationsTopic Design IssuesArchitectureUser InterfaceData TypesOperationsData RepresentationsAlgorithmsTopic DesignSystem design (high level design)Focus on architectureIdentification of subsystemsObject design (lower level design)Modules and their implementationsFocus on data representations and algorithmsTopic System DesignChoose high-level strategy for solving problem and building solutionDecide how to organize the system into subsystemsIdentify concurrency / tasksAllocate subsystems to HW and SW componentsTopic System DesignMajor conceptual and policy decisionsApproach for management of data storesAccess mechanism for global resourcesSoftware control mechanismHandle boundary conditionsPrioritize trade-offsTopic Design PrinciplesConsider alternative approachesDo pro and con analysisDelay decisions until superior choice is clearIsolate decisions so alternative implementations can be evaluated laterAvoid unnecessary embellishmentsBut don’t oversimplifyTopic Design Principles (cont.)Make design traceable to requirementsUse uniform documentation styleReuse existing designs when possibleKeep design simple unless performance, maintainability, etc. DEMAND otherwiseTopic Design Principles (cont.)Define interfaces between modules carefullyConsider how to handle the unexpectedDon’t code!!Document decisionsReview, review, review . . .Topic System ArchitectureOverall organization of system into subsystemsDecide basic interaction patternsNumerous architectural styles for different applicationsArchitecture provides context for detailed design decisionsTopic Subsystem IdentificationDivide system into a manageable number of componentsEach major component is a subsystemSubsystem groups components with common properties/functionTopic Subsystem Collection ofClassesAssociationsOperationsEventsConstraintsInterrelated Good cohesionWell-defined, small interface with other subsystemsLow coupling Identified by the service it providesTopic Subsystem DiscussionProvide services for other sub-systemsGroup of related functionsShare a common purposeDivide system into components (>20)Subsystems are decomposed . . .Module is the lowest level of subsystemTopic Subsystem RelationshipsClient-Server relationshipClient subsystems actively drive the system by requesting services provided by a server subsystemPeer-to-peer relationshipSubsystems interact and communicate to accomplish a common goalTopic Client-Server RelationshipServer supplies services for clientsNeed not know identity of clientsNeed not know interface of clientsClient calls serverClient knows interface of serverServer performs some service and returns a resultTopic Peer-to-Peer RelationshipSubsystems call one anotherThe results of/responses to calls may not be immediately visibleSubsystems must know the interfaces of other subsystemsMore likely to have communication dependenciesTopic Strategies for DecompositionsLayers: Horizontal decompositionOpen ClosedPartitions: Vertical decompositionSystem topology: General decompositionsTopic Layered SubsystemsSet of “virtual” worldsEach layer is defined in terms of the layer(s) below itKnowledge is one way: Layer knows about layer(s) below itObjects within layer can be independentLower layer (server) supplies services for objects (clients) in upper layer(s)Topic Example: Layered architectureInteractive Graphics ApplicationWindows OperationsScreen OperationsPixel OperationsDevice I/O OperationsTopic Closed ArchitecturesEach layer is built only in terms of the immediate lower layerReduces dependencies between layersFacilitates changeTopic Open ArchitecturesLayer can use any lower layerReduces the need to redefine operations at each levelMore efficient /compact codeSystem is less robust/harder to changeTopic Properties of Layered ArchitecturesTop and bottom layers specified by the problem statementTop layer is the desired systemBottom layer is defined by available resources (e.g. HW, OS, libraries)Easier to port to other HW/SW platformsTopic Partitioned ArchitecturesDivide system into weakly-coupled subsystemsEach provides specific servicesVertical decomposition of problemTopic Ex: Partitioned ArchitectureOperating SystemFileSystemProcessControlVirtual Memory Manage-mentDeviceControlTopic Typical Application ArchitectureApplication packageWindow graphicsScreen graphicsPixel graphicsOperating systemComputer hardwareUser dialogue controlSimulation packageTopic System TopologyDescribe information flowCan use DFD to model flowSome common topologiesPipeline (batch)Star topologyTopic Ex: Pipeline TopologyLexical analyzerSemantic analyzerCode generatorCode optimizersource programtoken streamabstract syntax treecode sequenceobject codeCompiler:Topic Ex: Star ToplogyMonitoring system:SafeHome softwareSensorsControl panelAlarmTelephone linesensor statusdisplay informationcommands, dataOn/Off signals, alarm typenumber tonesTopic