CS 501: Software EngineeringAdministrationData Intensive Systems Example: A Small-town StockbrokerA Database ArchitectureReal-time TransactionsReal-time Transactions & Batch ProcessingStock Broker: Interface DiagramPractical considerations to include in Architecture and SpecificationArchitectural StylesArchitectural Style: PipeArchitectural Style: Master File UpdateArchitectural Style: RepositoryArchitectural Style: Repository with Storage Access LayerData Intensive Systems: Merger of Two BanksMerger of Two Banks: OptionsMerger of Two Banks: Interface between the DatabasesMerger of Two Banks: Architectural OptionsSlide 18Data Intensive Systems: Distributed DataArchitectures for Distributed ComputingArchitectural Style: Client/ServerArchitectural Style: Three Tier ArchitecturePowerPoint PresentationNetworks: Quality of Network ServicesNetworks: ChoicesNetworks: Routers and Other Network ComputingNetworks: FirewallDistributed Data: ReplicationDistributed Computing: Distributed CachesDistributed Computing: Distributed CachesSlide 31Slide 32Time-Critical SystemsTime-Critical System: Buffering a CD Controller for AutomobileTime Critical System: Architectural Style - DaemonTime Critical System: Architectural Style - Model/Controller/ViewTime-Critical System: Autonomous Land VehicleTime Critical System: Autonomous Land VehicleSoftware ConsiderationsSoftware Considerations: Time-Critical SystemSoftware Considerations: PerformanceSoftware Considerations: Multi-ThreadingSoftware Considerations: Embedded Real-time SystemsSlide 44Software Considerations: Continuous OperationCoupling and Cohesion1CS 501 Spring 2008CS 501: Software EngineeringLecture 14System Architecture and Design 22CS 501 Spring 2008Administration3CS 501 Spring 2008Data Intensive SystemsExample: A Small-town Stockbroker• TransactionsReceived by mail or over telephoneFor immediate or later action• Complex customer inquiries• Highly competitive market4CS 501 Spring 2008A Database ArchitectureDatabases:•Customer and account database•Financial products (e.g., account types, pension plans, savings schemes)•Links to external databases (e.g., stock markets, mutual funds, insurance companies)5CS 501 Spring 2008Real-time TransactionsCustomer & account databaseProducts & services databaseExternal servicesReal-time transactions6CS 501 Spring 2008Real-time Transactions & Batch ProcessingCustomer & account databaseProducts & services databaseExternal servicesReal-time transactionsBatch processingData input7CS 501 Spring 2008Stock Broker: Interface DiagramCustomerDBProductDBOnLineTRBatchTRExternal8CS 501 Spring 2008Practical considerations to include in Architecture and Specification•Real-time service during scheduled hours with batch processing overnight•Database consistency after any type of failuretwo-phase commitreload from checkpoint + logdetailed audit trail•How will transaction errors be avoided and identified?•How will transaction errors be corrected?•How will staff dishonesty be controlled?These practical considerations may be major factors in the choice of architecture.*9CS 501 Spring 2008Architectural 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, 199610CS 501 Spring 2008Architectural Style: PipeExample: A three-pass compilerParserLexical analysisCode generationOutput from one subsystem is the input to the next.11CS 501 Spring 2008Architectural Style: Master File UpdateMaster file updateData input and validationMailing and reportsExample: billing system for electric utilityAdvantages: Efficient way to process batches of transactions.Disadvantages: Information in master file is not updated immediately.Customer services12CS 501 Spring 2008Architectural 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.13CS 501 Spring 2008Architectural 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" layerRepository14CS 501 Spring 2008Data 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. These systems are examples of Repository Architectural Style.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.15CS 501 Spring 2008Merger of Two Banks: Options??????AABB16CS 501 Spring 2008Merger of Two Banks: Interface between the DatabasesAccounts databaseBatch inputTeller transactionsAccounts databaseBatch inputTeller transactionsBank ABank BBoth systems follow the repository style17CS 501 Spring 2008Merger 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 database18CS 501 Spring 2008Merger of Two Banks: Interface between the DatabasesAccounts databaseBatch inputTeller transactionsAccounts databaseBatch inputTeller transactionsBank A Bank BData exchange APIProblem Accounts databases are rarely exactly equivalent.Data trans-formData trans-form19CS 501 Spring 2008Data Intensive Systems: Distributed DataDistributed DataData is held on several computer systems. A transaction may need to assemble data from several sources.20CS 501 Spring 2008Architectures for Distributed Computing An 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 service21CS 501 Spring 2008Architectural Style: Client/ServerWeb example: Serving static pagesFirefox clientApache serverThe control flows in the client and the
View Full Document
Unlocking...