CS 501: Software EngineeringAdministrationData Intensive Systems: Merger of Two BanksMerger of Two Banks: OptionsMerger of Two Banks: Architectural OptionsArchitectural StylesCoupling and CohesionArchitectural Style: RepositoryArchitectural Style: Repository with Storage Access LayerArchitectural Style: Model/Controller/ViewArchitectural Style: PipeDistributed Computing: General ProblemArchitectural Style: Client/ServerNetwork ChoicesQuality of Network ServicesFirewallDistributed DataDistributed Data and ReplicationSlide 19Distributed Computing: Stateless Protocol v. StatefulStateless Protocol v. StatefulSlide 22Distributed Computing: The Domain Name SystemDistributed Computing: The Domain Name SystemDistributed Computing Domain Name SystemTime-Critical SystemsTime-Critical System: Autonomous Land VehicleTime-Critical System: Routers and Other Network ComputingTime Critical Systems: Web ServerTime-Critical System: Software DevelopmentSoftware Considerations of System ArchitecturesSoftware Considerations of System Architectures: PerformancePerformance: CD Controller for AutomobileSoftware Considerations of System Architectures: Multi-ThreadingTime-Critical System: Embedded Real-time SystemsSoftware Considerations: Embedded Real-time SystemsSoftware Considerations of System Architectures: Continuous Operation1CS 501 Spring 2005CS 501: Software EngineeringLecture 14System Architecture and Design 22CS 501 Spring 2005Administration3CS 501 Spring 2005Data Intensive Systems: Merger of Two BanksEach bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing.The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches. This is an example of working with legacy systems.4CS 501 Spring 2005Merger of Two Banks: Options??????AABB5CS 501 Spring 2005Merger of Two Banks: Architectural OptionsI. Convert everything to System A convert databasesretrain staffenhance System A (software and hardware)discard System B II. Build an interface between the databases in System A and System BIII. Extend client software so that it can interact with either System A or System B database6CS 501 Spring 2005Architectural StylesAn architectural style is system architecture that recurs in many different applications. See: Mary Shaw and David Garlan, Software architecture: perspectives on an emerging discipline. Prentice Hall, 19967CS 501 Spring 2005Coupling and CohesionCoupling is a measure of the dependencies between two subsystems. If two systems are strongly coupled, it is hard to modify one without modifying the other.Cohesion is a measure of dependencies within a subsystem. If a subsystem contains many closely related functions its cohesion is high.An ideal breakdown of a complex system into subsystems has low coupling between subsystems with high cohesion within subsystems.8CS 501 Spring 2005Architectural Style: RepositoryRepositoryInput componentsTransactionsExample: A digital libraryAdvantages: Flexible architecture for data-intensive systems.Disadvantages: Difficult to modify repository since all other components are coupled to it.9CS 501 Spring 2005Architectural Style: Repository with Storage Access LayerData StoreInput componentsTransactionsAdvantages: Data Store subsystem can be changed without modifying any component except the Storage Access.Storage AccessThis is sometimes called a "glue" layerRepository10CS 501 Spring 2005Architectural Style:Model/Controller/ViewModelControllerViewExample: An unmanned aircraftController: Sends control signals to the aircraft and receives instrument readings.Model: Translates data received from and sent to the aircraft into a model of flight performance. It uses domain knowledge about the aircraft and flight.View: Displays information about the aircraft to the user.11CS 501 Spring 2005Architectural Style: PipeExample: A three-pass compilerParserLexical analysisCode generationOutput from one subsystem is the input to the next.12CS 501 Spring 2005Distributed Computing: General ProblemAn application that is running on one computer wishes to use data or services provided by another:• Network connectionprivate, public, or virtual private networklocation of firewalls• Protocolspoint-to-point, multicast, broadcastmessage passing, RPC, distributed objectsstateful or stateless• Performancequality of service13CS 501 Spring 2005Architectural Style: Client/ServerExample: the WebFirefox clientApache serverThe control flows in the client and the server are independent. communication between client and server follows a protocol.In a peer-to-peer architecture, the same component acts as both a client and a server.14CS 501 Spring 2005Network ChoicesPublic Internet:Ubiquitous -- worldwideLow costPrivate network:Security / reliabilityPredictable performanceChoice of protocols (not constrained to TCP/IP)15CS 501 Spring 2005Quality of Network ServicesCriteria in choosing a system architecturePerformanceMaximum throughputLatencyVariations in throughputReal-time media (e.g., audio)BusinessSuppliers, costTrouble shooting and maintenance16CS 501 Spring 2005FirewallPublic networkPrivate networkFirewallA firewall is a computer at the junction of two network segments that:• Inspects every packet that attempts to cross the boundary• Rejects any packet that does not satisfy certain criteria, e.g.,an incoming request to open a TCP connectionan unknown packet typeFirewalls provide security at a loss of flexibility and a cost of system administration.17CS 501 Spring 2005Distributed Datatwo copies of the same data18CS 501 Spring 2005Distributed Data and ReplicationDistributed DataData is held on several computer systems. A transaction may need to assemble data from several sources.ReplicationSeveral copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used)With replicated data, the biggest problems are concurrency and consistency.19CS 501 Spring 2005Distributed Computing: Searching User interfaceserverUserDatabasesThis is an example of a multicast protocol.The primary difficulty is to avoid troubles at one site degrading the entire system (e.g., every transaction cannot wait for a system to time out).Broadcast Searching20CS 501 Spring 2005Distributed Computing:Stateless Protocol v.
View Full Document
Unlocking...