DOC PREVIEW
UConn CSE 298/300 - Architectural Styles

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Software Architectures Chapter 2: Architectural StylesTaxonomy of Architectural StylesSlide 3Overall Framework Consider a Question-Based ApproachPipes and FiltersSlide 6Pipes and Filters Another ExampleADTs and OO ArchitecturesImplicit InvocationSlide 10Layered SystemsSlide 12RepositoriesInterpretersProcess Control ParadigmsClient/Server Single and Multi-Tier ArchitecturesSlide 17Example: Software Architectural StructureBusiness Process Model: Scanning and Initial Data EntryConcluding RemarksSWA-1.1CSE300Software ArchitecturesSoftware ArchitecturesChapter 2: Architectural StylesChapter 2: Architectural StylesProf. Steven A. Demurjian, Sr.Computer Science & Engineering DepartmentThe University of Connecticut191 Auditorium Road, Box U-155Storrs, CT [email protected]://www.engr.uconn.edu/~steve(860) 486 - 4818Copyright © 2000 by S. Demurjian, Storrs, CT.SWA-1.2CSE300Taxonomy of Architectural StylesTaxonomy of Architectural StylesData Flow SystemsData Flow SystemsBatch SequentialPipes and FiltersCall & Return SystemsCall & Return SystemsMain/Subroutines (C, Pascal)Object OrientedImplicit InvocationHierarchical SystemsVirtual MachinesVirtual MachinesInterpretersRule Based SystemsData Centered SystemsData Centered SystemsDBSHypertextBlackboardsIndependent Independent ComponentsComponentsCommunicating Processes/Event SystemsClient/ServerClient/ServerTwo-TierMulti-TierSWA-1.3CSE300Taxonomy of Architectural StylesTaxonomy of Architectural StylesEstablish Framework of … Establish Framework of … Components Building Blocks for Constructing SystemsA Major Unit of FunctionalityExamples Include: Client, Server, Filter, Layer, DBConnectorsDefining the Ways that Components InteractWhat are the Protocols that Mandate the Allowable Interactions Among Components?How are Protocols Enforced at Run/Design Time? Examples Include: Procedure Call, Event Broadcast, DB Protocol, PipeSWA-1.4CSE300Overall FrameworkOverall FrameworkConsider a Question-Based ApproachConsider a Question-Based ApproachWhat Is the Design Vocabulary?What Is the Design Vocabulary?Connectors and ComponentsWhat Are Allowable Structural Patterns?What Are Allowable Structural Patterns?Constraints on Combining Components & ConnectorsWhat Is the Underlying Conceptual Model?What Is the Underlying Conceptual Model?Von Newman, Parallel, Agent, Etc.What Are Essential Invariants of a Style?What Are Essential Invariants of a Style?Limits on Allowable Components & ConnectorsCommon Examples of UsageCommon Examples of UsageAdvantages and Disadvantages of a StyleAdvantages and Disadvantages of a StyleCommon Specializations of a StyleCommon Specializations of a StyleSWA-1.5CSE300Pipes and FiltersPipes and FiltersFilters:Filters:Invariant: Unaware of up and Down Stream BehaviorStreamed Behavior: Output Could Go From One Filter to the Next One Allowing Multiple Filters to Run in Parallel.SortSortSortSortMergeMergeConnectors for Flow Streams of I/OComponents with Input and OutputComponents are IndependentEntities. No Shared State!SWA-1.6CSE300Pipes and FiltersPipes and FiltersPossible Specializations:Possible Specializations:Pipelines - Linear SequenceBounded - Limits on Data AmountsTyped Pipes - Known Data FormatWhat is a Classic Example?What is a Classic Example?Other Examples:Other Examples:CompilersSequential ProcessesParallel ProcessesSWA-1.7CSE300Pipes and FiltersPipes and FiltersAnother ExampleAnother ExampleText Information Retrieval Systems Text Information Retrieval Systems Scanning Newspapers for Key Words, Etc.Also, Boolean Search ExpressionsUserSearchSearchControllerControllerSearchSearchDBDBQueryQueryResolverResolverTerm Term ComparatorComparatorDiskDiskControllerControllerCommandsCommandsProgrammingProgrammingControlControlResultResultDataDataSWA-1.8CSE300ADTs and OO ArchitecturesADTs and OO ArchitecturesWidespread Usage in the 1990’sWidespread Usage in the 1990’sAdvantages Are Well Known Advantages Are Well Known Disadvantages:Disadvantages:Interaction Required Object IdentityIf Identity Changes, It Is Difficult to Track All Affected Objects.objobjobjobjobjobjobjobjopopopopopop opopopop opopopConnectorsComponentsSWA-1.9CSE300Implicit InvocationImplicit InvocationSimilar to OO in the Sense that Components Can Similar to OO in the Sense that Components Can Call Services on Other ComponentsCall Services on Other ComponentsHow Does this Work?How Does this Work?Components Have List of Events they can Raise and List of Procedures to Handle EventsWhen Event is Raised, it is BroadcastAll Components that Have Procedure to Handle Broadcast Event will Act Upon itThe Component That Raised the Event has no Knowledge of Which Component(s) will Handle EventWhat are Some Examples?What are Some Examples?SWA-1.10CSE300Implicit InvocationImplicit InvocationAdvantagesAdvantagesNo Need to Know the Targeted ComponentsSingle Event can Impact Multiple ComponentsNew Event Handlers can Easily be AddedNew Events Can then be RaisedDisadvantagesDisadvantagesNo Control Over the Order of Processing When an Event is RaisedNo Control Over “Who” and “How Many” Process EventsVery Non-Deterministic System BehaviorSWA-1.11CSE300Layered SystemsLayered SystemsComponents - Virtual Machine at Each LayerComponents - Virtual Machine at Each LayerConnectors - Protocols That Specify How Layers InteractConnectors - Protocols That Specify How Layers InteractInteraction Is Restricted to Adjacent LayersInteraction Is Restricted to Adjacent LayersExamples: ISO Layers: Examples: ISO Layers: Physical, Data Link, Network, Transport, Session, Presentation and ApplicationUsersCorelevelBase UtilityUseful SystemsSWA-1.12CSE300Layered SystemsLayered SystemsAdvantages:Advantages:Increasing Levels of AbstractionSupport Enhancement - New LayersSupport for ReuseDrawbacks:Drawbacks:Not Feasible for All SystemsPerformance Issues With Multiple LayersDefining Abstractions Is Difficult.SWA-1.13CSE300RepositoriesRepositoriesKnowledge Sources Interact With the Blackboard.Knowledge Sources Interact With the Blackboard.Blackboard Contains the Problem Solving State Data.Blackboard Contains the Problem Solving State Data.Control Is Driven by the State of the Blackboard.Control Is Driven by the


View Full Document

UConn CSE 298/300 - Architectural Styles

Documents in this Course
Java Tool

Java Tool

58 pages

Load more
Download Architectural Styles
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Architectural Styles and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Architectural Styles 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?