Styles and Greenfield DesignHeterogeneous StylesC2 StyleC2 Style (cont’d)C2 LLKLAXKLAX in C2Distributed Objects: CORBACORBA Concept and ImplementationCORBA LLObservationsStyle Summary (1/4)Style Summary, continued (2/4)Style Summary, continued (3/4)Style Summary, continued (4/4)Design RecoverySyntactic ClusteringSemantic ClusteringWhen There’s No Experience to Go On…Analogy SearchingBrainstorming“Literature” SearchingMorphological ChartsRemoving Mental BlocksControlling the Design StrategyInsights from RequirementsInsights from ImplementationCopyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.Styles and Greenfield DesignSoftware ArchitectureLecture 6Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture2Heterogeneous StylesMore complex styles created through composition of simpler stylesREST (from the first lecture)Complex history presented later in courseC2Implicit invocation + Layering + other constraintsDistributed objectsOO + client-server network styleCORBAFoundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture3C2 StyleAn indirect invocation style in which independent components communicate exclusively through message routing connectors. Strict rules on connections between components and connectors induce layering.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture4C2 Style (cont’d)Components: Independent, potentially concurrent message generators and/or consumersConnectors: Message routers that may filter, translate, and broadcast messages of two kinds: notifications and requests.Data Elements: Messages – data sent as first-class entities over the connectors. Notification messages announce changes of state. Request messages request performance of an action.Topology: Layers of components and connectors, with a defined “top” and “bottom”, wherein notifications flow downwards and requests upwards.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture5C2 LLSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture6KLAXSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture7KLAX in C2Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture8Distributed Objects: CORBA“Objects” (coarse- or fine-grained) run on heterogeneous hosts, written in heterogeneous languages. Objects provide services through well-defined interfaces. Objects invoke methods across host, process, and language boundaries via remote procedure calls (RPCs).Components: Objects (software components exposing services through well-defined provided interfaces)Connector: (Remote) Method invocationData Elements: Arguments to methods, return values, and exceptionsTopology: General graph of objects from callers to callees.Additional constraints imposed: Data passed in remote procedure calls must be serializable. Callers must deal with exceptions that can arise due to network or process faults.Location, platform, and language “transparency”. CAUTIONFoundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture9CORBA Concept and ImplementationSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture10CORBA LLSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture11ObservationsDifferent styles result inDifferent architecturesArchitectures with greatly differing propertiesA style does not fully determine resulting architectureA single style can result in different architecturesConsiderable room for Individual judgmentVariations among architectsA style defines domain of discourseAbout problem (domain)About resulting systemFoundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture12Style Summary (1/4) Style Category & Name Summary Use It When Avoid It When Language -influenced styles Main Program and Subroutines Main program controls program execution, calling multiple subroutines. Application is small and simple. Complex data structures needed. Future modifications likely. Object -oriented Objects encapsulate state and accessing functions Close mapping between external entities and internal objects is sensible. Many complex and interrelated data structures. Application is distributed in a heterogeneou s network. Strong independence between components necessary. High performance required. Layered Virtual Machines Virtual machine, or a layer, offers services to layers above it Many applications can be based upon a single, common layer of services. Interface service specification resilient when implementation of a layer must change. Many levels are required (causes inefficiency). Data structures must be accessed from multiple layers. Client -server Clients request service from a server Centralization of computation and data at a single location (the server) promotes manageability and scalability; end -user processing limited to data entry and presentation. Centrality presents a single -point -of-failure risk; Network bandwidth limited; Client machine cap abilities rival or exceed the server ’s.Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture13Style Summary, continued (2/4) Data-flow styles Batch sequential Separate programs executed sequentially, with batched input Problem easily formulated as a set of sequential, severable steps. Interactivity or concurrency between components necessary or desirable. Random-access to data required.