Date post: | 12-Jan-2016 |
Category: |
Documents |
Upload: | berniece-carroll |
View: | 212 times |
Download: | 0 times |
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