CS4311 Spring 2011 Software Architecture Dr. Guoqiang Hu Department of Computer Science UTEP

What Is Architecture? Dictionary definitions Examples: archangel, archenemy, archduke, archbishop matriarch, patriarch, monarch Arch as prefix or suffix: main, chief, principal, most important, highest, fundamental, basic, extreme or most characteristic, ruler, leader Architecture: The art and science of designing and erecting buildings Fundamental underlying design of buildings Style and method of design and construction of buildings Buildings and other structures

Everything has its architecture

Software architectures

What is software architecture? Framework Mechanism Way Shape Form Means Organization Arrangement The Big Picture !

Where Come the Software Architectures? Problem domains New problem domains can be invented! (WWW, Internet)

Software Architecture Definition Software architecture is the set of principle design decisions made about a software system. What design decisions? System structure Functional behavior Interaction Nonfunctional properties Implementation System goals, Stakeholders, Nontechnical considerations

Component Elements that encapsulate processing and data in a system’s architecture are referred to as software components. An architectural entity that (1)encapsulates a subset of the system’s functionality and/or data, (2)restricts access to that subset via an explicitly defined interface, and (3)had explicitly defined dependencies on its required execution context. Connector Elements that are tasked with effecting and regulating interactions among components. Application independent.

Configuration (Topology) A set of specific associations between the components and connectors of a software system’s architecture. Models An artifact that captures some or all of the design decisions that comprise a system’s architecture. Architectural modeling is the reification and documentation of those design decisions. Different models: structural vs. behavioral; static vs. dynamic; scope; etc.

Architectural style A named collection of architectural design decisions that (1)are applicable in a given development context, (2)constrain architectural design decisions that are specific to a particular system with that context, and (3)elicit beneficial qualities in each resulting system. Not about: specific systems; specific components; specific interaction mechanisms; specific configurations.

The Repertoire of Architecture Styles Client-Server architecture style Application context: Clients request services from a server Centralization of computation and data at the server Separation of user interface tasks from computation and data management and storage For examples: Websites, etc.

Components: Clients and server Connectors: Remote procedure call, network protocols Data elements: Parameters and return values are sent by the connectors Topology: Two-level, with multi-clients Qualities yielded: Centralization of computation and data at the server, with the information made available to remote clients. A single powerful server can service many clients. Cautions: Network bandwidth.

Three tier or n-tier architecture style Application context: Client-Server architecture style Multi-level services are needed For examples: Online banking systems, etc.

Dataflow architecture style Application context: Sequential data transformations are needed For examples: Data processing systems, etc. Pipe-and-Filter.

Components: Separate components, executing in order Connectors: (Remote) Procedure call, network protocols Data elements: Parameters and return values are sent by the connectors Topology: Linear Qualities yielded: Modularity, simplicity. Cautions: Concurrency.

Model-View-Controller architecture style Model: manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). View: manages the display of information. Controller: interprets inputs from the user, informing the model and/or the view to change as appropriate.

Application context: User interface changes more frequently than business logic Separate user interface design from complex business logic The application displays the same data in different ways User interface needs to support different physical devices (browser-based, PDAs, cell phones), whereas the business logic remains the same. A clean separation of these two parts accelerates the migration and minimizes the risk of introducing errors into the business logic For examples: Data visualization systems, etc.

Components: Model, View, and Controller Connectors: (Remote) Procedure call, network protocols Data elements: Parameters and return values are sent by the connectors Topology: Triangular Qualities yielded: Flexibility, separation of concern, multiple views. Cautions: New levels of indirection.

Layered architecture style (virtual machines) Application context: Ordered layered services are necessary Insulate upper layer from lower layer For examples: Network protocols, Java, operating systems, etc.

Components: Layers, offering a set of services to other layers, typically comprising several programs (subcomponents) Connectors: Procedure call Data elements: Parameters and return values are sent by the connectors Topology: Linear, for strict virtual machine; a directed acyclic graph in looser interpretations Qualities yielded: Clear dependence structure; Software at upper levels immune to changes of implementation within lower levels as long as the service specification are invariant; Software at lower levels fully independent of upper levels. Cautions: Efficiency

Shared state architecture style Application context: Collaborate and communicate through a shared repository For examples: Wikipedia, etc.

Components: Independent programs, blackboard Connectors: Direct memory access; procedure call; database query Data elements: Data stored in the blackboard Topology: Star topology, with the blackboard at the center Qualities yielded: Complete solution do not have to be planned; shared evolving views; collaboration made simple. Cautions: Data consistency

Rule-based architecture style Application context: Rule-based expert system (Rules and Inference engine) The problems can be solved by repeated resolving a set of predicates. For examples: Expert systems, etc. Components: User interface, inference engine, knowledge base Connectors: Procedure call; shared data access Data elements: Facts and queries Topology: Tightly coupled three-tier Qualities yielded: Rules can be dynamically modified. Cautions: The number of rules, order of rules

Interpreter architecture style Application context: Interactive command interpretation For examples: “Basic”, DOS or UNIX command shells, etc. Components: User interface, command interpreter Connectors: Procedure call; shared data access Data elements: Commands Topology: Tightly coupled three-tier Qualities yielded: Highly dynamical behavior. Cautions: Efficiency

Mobile code architecture style Application context: Moving code is more efficient than moving data Dynamically customizing local processing through inclusion of external code. For examples: JavaScript, ActiveX controls, Grid computing, etc. Components: Execution dock, code compiler/interpreter Connectors: Procedure call, packaging tool Data elements: Code Topology: Network Qualities yielded: Dynamic adaptability. Cautions: Security

Publisher-Subscriber architecture style Application context: Producers and Consumers of information Dynamically publishing and registering for information. For examples: News dissemination, etc. Components: Publishers, subscribers, proxies for managing distribution Connectors: Procedure call, network protocols Data elements: Subscriptions, notifications, published information Topology: Network Qualities yielded: High efficient one-way dissemination.

Event-based architecture style Application context: Independent components communicating solely by sending and receiving events These is no classification of components into publishers and subscribers. For examples: User interface, Markets-monitoring system, etc. Components: Event generator/consumer Connectors: Event-bus Data elements: Events Topology: Event-bus Qualities yielded: Highly scalable, easy to evolve, effective for highly distributed, heterogeneous applications. Cautions: No guarantee if or when a particular event will be processed

Peer-to-Peer architecture style Application context: A network of loosely coupled autonomous peers Each peer acting both as a client and a server Both information and control are decentralized and distributed For examples: File sharing systems, etc. Components: Independent Peers (clients and servers) Connectors: Custom network protocol Data elements: Network messages Topology: Network Qualities yielded: Decentralized computing with flow of control and resources distributed among peers. Highly robust in the face of failure. Scalable in terms of access to resources and computing power. Cautions: When information retrieval is time critical; security

Constraints Imposing Discussion of Styles Cons: Save time and energy to focus on essentials Feeling of certainty Providing baseline knowledge and languages for communication Promote understanding design decisions Pros: Combination, modification, and creation of styles

Design pattern A design pattern is a named and well-known problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs, implementations, variations, and so forth. It attempts to codify existing tried-and-true knowledge and principles. A design pattern names, abstracts, and identifies the key aspects of a common design structure that can make it useful for creating a reusable design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

The pattern of the presentation of design patterns (1)Name of the design pattern: the vocabulary (2)Applying context: the situation giving rise to the design problem (3)Problem: a recurring problem arising in that situation (4)Solution: a proven solution to that problem (5)Discussion: any relevant information/knowledge of the design pattern The categories of design patterns (1)Creational patterns: deal with object creation mechanisms (2)Structural patterns: identifying the way to realize relationships (3)Behavioral patterns: identify common communication patterns between objects and realize these patterns (4)Concurrency patterns: deal with multi-threaded programming paradigm