CS4311 Spring 2011

Software Architecture

Dr. Guoqiang Hu

Department of Computer ScienceUTEP

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

Everything has its architecture

Software architectures

Software architectures

Software architectures

Software architectures

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 styleApplication 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