Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture, image, image, image, 103-1032887_2-head-arrow-arrow…
Software Architecture
KietHA
Chapter 2 - Software Architecture Design Space
2.1 Type of Software Structure
Software Static Structure
Software project is typically implement in multiple files
Deployment descriptors
Binary software component module
Executable files
Library files
Other resource files
Module dependent
Direction
If module A invokes a method of module B during execution, there is a unidirectional connector from module A to module B
Synchronization
A method invocation can be synchronous or asynchornous
Sequence
Some connector must be used in a particular sequence
Software Structure Java
Classes
Files
Packages
Managing Static Structure
A linear client- server relationship is formed when a component provides primitive abstraction to another component
A tree-like hierarchy of refinement relations is formed when an abstraction is implemented, and recursively divides into subcomponents
Software Running Structure
Multiplicity
One element can be connected to multiple elements if it needs to invoke methods of multiple elements at runtime.
Distance and connection media
Two connected element may communicate in the same thread, in the same process , on the same computers, or on different computers across a network
Universally invocable
A connector with this attribute set to true allows any external software system to invoke the methods at the connector’s target
Self-descriptive
A connector with this attribute set to true allows any external software system to invoke its target method without pre-installation of any software specific to the method.
Software Management Structure
Used for project resource allocation
Some software architecture are best implemented by a particular software management structure
2.2 Software Elements
Elements is reentrant
Implement by thread or a process
Element is NOT reentrant and multiple threads or process need to communicate with it
Must be run on separate threads or processes in order to be in thread-safe
Element has high multiplicity and its performance is important to the global system performance
Should be used for element's implement
Element contain heavy computations for at a particular location
A cluster of processors will enhance CPU data processing power
Element is assigned complex but well-define functions and performance of this element is not critical
Use an existing software component to implement the element's function
A complex element
Expanded into a subsystem with its own elements or connectors
Each layer provides a virtual machine/interface to immediate upper-layer element, each layered hide away low-level system detail from upper layers.
Transformed into sequence of vertical layered elements
Business logic can be achieved by processing data with sequence of discrete processing stages
Transformed into a sequence of horizontally tiered elements
2.3 Software Connectors
Connector refinement is heavily influenced by a project’s deployment environment
Map element
Two elements are mapped to single process
Connector can be mapped to local method invocation
Two elements are mapped to two different processes on the same computer
Connector can be mapped to local message queue or a pipe
Two elements are mapped to two different computers
Remote method invocation/web service invocation can be use to refine the connector between them
Classify
Base on the connector's synchronization mode
Blocking connectors
Allows one of its incident elements to send a request to another and wait for a response.
Non-blocking connectors
Allows one of its incident elements to send a request to another and continues its execution without waiting for a response.
Connector type – initiator
One-Initiator connectors
Allows one of the two connected elements initiates the request, but not another way around
Two-Initiator connectors
Either of the two elements can make the request
Base on the implementation type
Signatured-based
Used to request one type of operation
Protocol-based
Implement multiple operation types with a single binding signature
Based on information carries
Variable
Environment resource
Method
Messages
Based on arrived time
Program
Even-drive
Callback
Based on connectors span
Local connectors
Network connectors
Base on connectors fan-out
1 - 1 connectors
Connecting two elements only
1 - * connectors
Connecting one element with a variable number of elements of same type
Based on connector environment
Homogeneous connectors
Implement with the same programing language and software framework and run on the same operating system.
Heterogeneous connectors
Implement with the different programing language and software framework and run on the different operating system.
2.4 An Agile Approach to Software Architecture Design
Disadvantage of waterfall model
Do not emphasize the iterative refinement nature
Do not use element and connector attributes to capture the key architecture requirements of a software project
If the deployment environment change, the architecture design much start from scratch
Advantage of agile model
Maximizes the reuse of
Architecture
Design
Implementation investment
The delayed binding of software connectors for more flexible implementation decisions
The seamless integration of multiple architecture in realizing different subsystem or levels or the same systems.
Chapter 3 - Model for Software Architecture
3.1 UML for Software Architecture
Definition
A typical object-oriented analysis and design notation tool that provides many useful analysis diagram and even generate code skeleton
A graphical language for visualizing, specifying, constructing and document the artifacts of a software-intensive
Provides several modeling diagrams
Structural diagrams
Object diagram
Shows a snapshot of class instance connection and interaction.
Objects are the instances of classes.
Is used to describe a sample subset of objects in the system at a point of time.
Composite structure diagram
Describe the composite of interconnected elements or the collaboration of running instances
Two basic notations
Structured class
Collaboration
Component diagram
A deployable, reusable building block use in software design and development
Deployment diagram
Depict the physical configuration of the software system deployed on hardware server nodes and the network between the nodes
This diagram is generated in the later phase of software development life cycle.
All components in the system need to be deployed on servers to provide services via network protocols.
Component diagrams are the basis for the deployment diagram
The link between nodes is the network connection depicted by the network protocol
The deployment diagram is widely used to model and design distributed software systems.
A resource can be a hardware device or a deployed software subsystem.
Class diagram
It captures the vocabulary of the designed system.
Describe each individual class with its type, interface, properties, and methods
Provides static view of the system
Packages diagram
Allow the organization of all closely related classes in a well-formed manner to be placed in one “container.”
A package is represented by a tabbed folder that indicates where all included classes and sub packages reside.
Packages play a similar role as a directory for grouping files in a file system
Can organize functionally related classes in the same package so that these classes can access each other within a default accessibility or visibility.
Can also organize related packages in a same parent package to build a class and package hierarchy just like.NET class library and Java API.
Package organization is namespace sharing; in this way, all classes in the same package have a unique name but they may have same name in different packaged (namespaces).
Behavior diagrams
Use Case diagram
Describe user requirements in terms of system functionality (use cases) as a contract between the user (actors) and the software system.
Activity diagram
Describe complex business processes
Describe complex business processes; they typically involve complex workflow, decision making, concurrent executions, exception handling, process termination, etc. ,
State machine diagram
Are widely used for embedded systems and device software analysis and design.
It is an event-oriented diagram where the software elements in the system change their states in response to external or internal stimuli
They are ideal for specifying the internal behavior of object.
Sequences diagram
Time-oriented interaction diagram showing the chronological sequences of messages between object
Interaction overview diagram
Describes the control flow of the interactions rather than message.
It is a variant of the Activity Diagram.
The nodes in a Interaction Overview Diagram represent either interactions reference to some existing diagrams (ref) or interaction basic element.
Communication or Collaboration diagram
It summarizes how objects in the system receive and send messages from/to other objects.
It is an extension of the static object diagram where the links between objects represent the association relationships.
Timing diagram
It combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time.
It is often used in time-critical systems such as real time operating system, embedded system design, etc.
3.2 Architecture View Model
The scenario view
Describes the functionality of the system
Describe how the system provides service to the user and how user will useservice
Helps to make the software architecture consistent and validated against functional and non-functional requirements.
The logical conceptual view
Based on application domain entities necessary to implement the functional requirements.
It focuses on functional requirements and the main building blocks and key abstractions decomposing of the system.
The view basically is an abstraction of the system's functional requirements.
The development or module view
The development view describes the software static organization of the system modules.
It is derived from the logical view.
Modules such as namespaces, class library, sub-system, or packages are building blocks that group classes for further development and implementation.
The physical view
Describes installation, configuration, and deployment of the software application.
It concerns itself with how to deliver the deployable system.
It is particularly of interest in distributed or parallel systems.
The user interface view
Is the user interface (UI) view giving user-computer clear interface view while hiding implementation details.
This view may be provided as a series of screen snapshots or a dynamic, interactive prototype demo.
The process view
The process view focuses on the dynamic aspects of the system, i.e., its execution time behavior.
This view is also derived from logical view.
This view is an abstraction of processes or threads dealing with process synchronization and concurrency.
3.3 Architecture Description Language(ADL)
Definition
A notation specification providing syntax and semantics for defining software architecture.
A formal specification language with well define syntax and semantics
Usages
Describe architecture components and their connection, interface and configuration.
Provides designers with ability to decompose component, combine component and define interface of components.
Requirement
Composision
Abstraction
Reuse
Configuration
Heterogeneity
Analysis
Chapter 1 - Introduction to Software Architecture
1.1 Overview
Goal of software design
Leads to successful implementation
Build a model requirement that meets all customer requirements
what is the architecture design?
Define relationship between major structural elements of the software, the style and design patterns
Who is responsible for developing the architecture design?
Designers
Software architects
Why the software architecture design so important?
A good software design will
Make a system traceable for implementation and testing
Reduces the risks associated with software production
Helps development team work together in an orderly fashion
Leads to software products that have higher quality attributes
A poor design may result in a deficient product
Not reusable
Does not meet system requirements
Not adaptive to future requirement changes
Exhibit unpredictable behavior, or performs badly
When is software design conducted?
Software requirement analysis
Software design
Software development
Testing
Quality assurance, maintenance and evolution
What is outcome of the software architecture design?
An overall representation of the software to be build
1.2 Software architecture: Bridging Requirement and Implementation.
Architecture elements can be
A whole system
A module, subsystem, object, or binary software such as a DLL
A JavaBean, EJB, CORBA or web component.
Two aspects of software requirement.
Specifies the functionality of the software system
Specifies system qualities, constraints and behavior
Software architect's tasks
Perform static partition and decomposition of the system into sub systems and communication among subsystems
Establish dynamic control relationships among different of term in subsystem
Message dispatching
Data flow
Control flow orchestration
Consider and evaluate alternative architecture styles that suit the problem domain at hand
1.3 Architecture Styles (Architecture pattern)
Why architecture style is so important
Because each style has a set of quality attribute that it promotes
Multitier architecture
Data server
Manages data querying and updating.
Middleware server
Get request from client element
Processes the requests base on business logic
Sends a data request to the back-end tier
Client
GUI interface presentation
Accepting user request
Rendering results
Key component
Element that perform functions required by a system
Connectors that enable communication, coordination and cooperation among elements
Contracts that define how elements can be integrated to form the system
Attributes that describe the advantages and disadvantages of the chosen structure
An architecture style containts
Pattern of how to structure a system into a set of elements and connectors
Set a rules
Constraints
1.4 Quality Attributes
Implementation attributes (not observable at run time)
Interoperability
Maintainability and expensibility
Testability
Portability
Scalability
Flexibility
Runtime attributes(Observable at runtime)
Availability
Security
Performance
Usability
Reliability
Maintainability
Business attributes
Lifetime
Time to market
Cost
Typical quality attribute tradeoff pairs
Tradeoff between space and time
Tradeoff between reliability and performance
Tradeoff between scalability and performance
1.5 Software Architecture Design Guidelines
Avoid ambiguous design and over-detailed design
Try to promote high cohesion within each elements and loose between elements
Think of nonfunctional requirements early in the design process
Think of what to do before thinking of how to do it
Think of abstract design before thinking concrete design
Think of software reusability and extensibility as much as possible
Tolerate refinement of design
ThienNH
Chapter 4Object-Oriented Paradigm
OO principles : encapsulation, inheritance, and polymorphism
■ Encapsulation: Often called information hiding, the purpose of
encapsulation is to separate interface from implementation
Inheritance: A class can inherit from its base class. Inheritance allows software reuse, hence improving the effectiveness of software development
Polymorphism: Polymorphism refers to the ability of an object to behave differently and assume different forms based on its inheritance hierarchy
Polymorphism includes vertical override operations between parent classes and derived classes, and horizontal overloading operations within the same class
Introducing the Object-Oriented Paradigm
Classes and Objects:
A class groups together related data and their operations.
An object is an
instance of a class
A class defines the attributes and behaviors shared by all
of its objects.
Relationships: composition, aggregation, association, and inheritance
association: An association is a connection between classes, a semantic connection (link) between objects of the classes involved in the association
Aggregation is a special case of association. A kind of “whole-part” relationship. Parts do not have to share the same lifespan as owner. In UML, aggregation is represented using a hollow diamond arrowhead.
Composition is a stronger variant of the "owns a“ relationship Composition is more specific than aggregation. Requirement: the lifespan of “components” and “owner” involved in a composition relationship must be same. Is represented using a solid diamond arrowhead
Chapter 5 Data Flow Architectures
Batch Sequential
Traditional data processing model
Widely used in 1950’s – 1970’s
Example: mainframe computers using COBOL
Usually done in batch processing language or shell script
DOS Batch File
Direct implementation in coding
Applicable domains of batch sequential architecture:
Data are batched
Intermediate file is a sequential access file.
Benefits:
Simple divisions on subsystems
Each subsystem can be a stand-alone program
Limitations:
It does not provide interactive interface
■ Implementation requires external control.
■ Concurrency is not supported and hence throughput remains low
High latency
Pipe and Filter Architecture
Pipe and filter architecture is another type of data flow architecture where the flow is driven by data.
There are three ways to make the data flow
Push only (Write only)
A data source may push data in a downstream
A filter may push data in a downstream
Pull only (Read only)
A data sink may pull data from an upstream.
A filter may pull data from an upstream.
Pull/Push (Read/Write)
A filter may pull data from an upstream and push transformed
data in a downstream
There are two types of filters: active and passive
An active filter
A passive filter
Process Control Architecture
suitable for the embedded system
A process control system must have the following process control data:
Controlled variable: a target controlled variable
Input variable: a measured input data
Manipulated variable: can be adjusted by the controller
types of subsystems: an executor processing unit and controller unit
Chapter 6 Data-Centered Software
Architecture
Data-centered software architecture is characterized by a centralized data
store that is shared by all surrounding software components.
Repository architectures
Data store is passive
Clients of the data store are active
Applicable domains of repository architecture:
Suitable for large, complex information systems where many software
component clients need to access them in different ways
Benefits:
-Data integrity: easy to back up and restore
System scalability and reusability of agents: easy to add new software
components because they do not have direct communication with each other
Limitations
Data store reliability and availability are important issues.
High dependency between data structure of data store and its
agents
Cost of moving data on network if data is distributed.
Related architecture:Layered, multi-tier, and MVC
Blackboard architectures
Data store is active
Clients are inactive/passive
The blackboard architecture was developed for speech recognition applications in the
1970s
Blackboard system:
A common knowledge base, the "blackboard", is iteratively updated by a diverse knowledge sources
starting with a problem specification and ending with a solution
Benefits:
Scalability: easy to add or update knowledge source
Concurrency: all knowledge sources can work in parallel since they
are independent of each other
Supports experimentation for hypotheses.
Limitations
Due to the close dependency between the blackboard and knowledge source
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge.
Related architecture: Implicit invocation architecture such as event-based, MVC architecture
Consists of two types of components: Data store and Software component agent
SangNV
Chapter 7
HIERARCHICAL ARCHITECTURE
General Rules
Upper layers
provide more abstract functionality in the form of user interfaces
Command line interpreter
GUI
Shell programming
Middle layers
provide more domain dependent functions
Business logic
Core processing
etc.
Services at lower level
provides more specific functionality down to fundamental utility services
I/O services
Transaction
Scheduling
etc.
Security services
Main/Subroutine Architecture
Purpose
Encourage re-use of modules
Idea
System decomposed into sub-routines
A “main” program calls sub-routines and accomplishes task
Function Call Supported by Assembly
Protect old register values by pushing to stack
Set parameters in register
Call the subroutine
Jump, Long Jump, Call instruction
Software Interrupt
Function Call Supported by High Level Language
Much more convenient
Much more tricky!
Parameter passing
Pass by value
the subroutine only uses the passed data but cannot change it.
Pass by reference
the subroutine may change the value of data referenced by the parameter
Design
Usually Requirement Spec. Specified in Data Flow Diagram (DFD)
Objective: Map from DFD to Main/Subroutine design
DFD
Two types of flow
Transform Flow
input data get processed and results in output data (sequential)
Transaction Flow
depending on input data, take different control actions (branch)
Mapping Process
Identify transform and transaction flows
Map each flow into a subroutine
Generally: a main process controls the overall flow
Benefits
Easy to decompose the system
Can still be used in sub-system of OO design
Limitation
Globally shared data are vulnerable
Tight coupling may cause ripple impacts as compared to OO design
Master-Slave
Architecture
Supports
Fault tolerance
System reliability
Idea
The
slaves
provide replicated services to the master
The
master
selects a particular result among slaves by certain selection strategies
Characteristics
Parallel computing and accuracy of computation
Applicable domain
Where reliability is crucial
Layered Architecture
Idea
functionality grouped into layers
upper layer invokes func. in lower layer
Physical Implementation
Functions in one layer usually organized in one package
Some times deployed as services
Example
OSI 7-layer Network Stack
OS (driver, kernel, system call, application)
Web service (ip, tcp, http, xml, SOAP, WSDL, BPEL, UDDI)
Applicable Domains
For systems that can be divided between portions providing generic services to the application of the system
For applications which have classes that are close related each other
Benefits
Incremental software development
Enhanced independence of upper layer to lower layer
Enhanced reusability and interchangeability
Component-based technology is a suitable
Promotion of portability
Limitations
Lower runtime performance
Exception and error handling
Many applications can not fit this architecture
Virtual Machine
Idea
Provide a virtual interpretation layer that separates
Application
Physical machine layer
i.e., Software/Components run on simulation layer
Applicable Domain
Suitable for solving a problem by simulation or translation
Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language
Benefits
Portability and machine platform independency
Simplicity of the software development
Simulation for non-native and disaster working model
Limitations
Slow execution of the interpreter
Additional overhead due to the new layer
Chapter 8
IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
Asynchronous implicit invocation communications
Two different modes
Non-buffered
(Observer pattern)
The non-buffered event-based implicit invocation architecture breaks the software system into two partitions
Event sources
Event listeners
Subscribers
Event registration process connection
There is no buffer available between these two parties.
Once an event is fired off by an event source, all corresponding subscribers are notified, which then take corresponding actions.
Applicable Domain
Suitable for interactive GUI component communication and Integrated Development Environment (IDE) tools.
Suitable for applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications.
Suitable for the implementation of state machines.
Suitable when event handlings in the application are not predictable.
Benefits
Framework availability: Many vendor APIs such as Java AWT and Swing components available.
Reusability of components: Easy to plug-in new event handlers without affecting the rest of the system.
System maintenance and evolution: Easy to update both of event sources and targets.
Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at run-time.
Possibility of parallel execution of event handlings.
Limitations
Difficult to test and debug the system
Hard to predict and verify responses and the order of responses from the listeners.
The event source cannot determine
when a response finished
the sequence of all responses.
Reliability and overhead of indirect invocations may be an issue.
There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
Buffered Message-Based
(Data-centric)
The buffered message-based software architecture breaks the software system into three partitions
Message producers
Message consumers
Message service providers.
They are connected asynchronously by either a
message queue : one-to-one
message topic: one-to-many
Idea
a sender sends out a message and it does not care much of the response from the receivers except for guaranteed message delivery; it is typically implemented as a Message-Oriented Middleware (MOM) providing a reliable message service on a distributed system.
Build applications supporting asynchronous communication.
Reliable
Scalable
flexible distributed
Peer-to-peer client-server architecture
Point-to-Point Messaging (P2P)
Producer
Consumer
Compose
message queues
senders
receivers
requires every message sent to the message queue must be processed successfully by a consumer
much more reliable than simple event-listener based system we discussed earlier.
Publish-Subscribe Messaging (P&S)
hub-like architecture
topic message can have multiple consumers.
Meaning
Message
a structured data with a message id, message header, property, and a body
Messaging
a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.
A messaging client can produce and send messages to other clients, they can also consume messages from other clients
1 more item...
Applicable Domain
Suitable for a software system where the communication between a producer and a receiver needs buffered message-based asynchronous implicit invocation for performance and distribution purposes.
The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced.
Benefits
Providing high degree of anonymity between message producer and consumer.
The message consumer does not know who produced the message (user independence), where the producer lives on the network (location independence), or when the message was produced (time independence).
Supporting for concurrency among consumers and between producer and consumers.
Providing scalability and reliability of message delivery; reliability mechanisms include
Supporting batch processing.
Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
Limitations
Capacity limit of message queue. This is not an inherent limitation but an implementation issue that can be eased if the queue is implemented as a dynamic data structure (e.g., linked lists).
However, there is an absolute limit based on available memory. It is also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents.
Complete separation of presentation and abstraction by control in each agent generate development complexity since communications between agents only take place between the control of agents.
Increased complexity of the system design and implementation
A message receiver can still receive messages even if it is not running at the time the message was sent.
In an event-based invocation system the event handler must be ready in order to be able to intercept an event and take an action upon that event.
This architectural style is commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture.
Chapter 9
INTERACTION ORIENTED ARCHITECTURE
Key Idea
Decomposes user-interaction software
Control module
Flow of control of view presentation
Communication between modules
Job dispatching
Certain data initialization
System configuration
View presentationmodule
Visual or audio data output presentation
Provide user interface when necessary
Data module
All core business logic on data processing
Provides data abstraction
Benefits
Loose coupling
Exchangeability
Maintainability
Extensibility
Separation of user interactions from data abstraction and business logic
Major Categories
Model View Controller (MVC)
Key Idea
Model
model of application’s logic
Concept
The Model manages the behavior and data of the application domain.
The model responds to requests for information about its state (usually from the view), and
responds to instructions to change state (usually from the controller).
View
deal with graphic representation
Concept
The View renders the model into a form suitable for interaction, typically a user interface element.
Multiple views can exist for a single model for different purposes.
A view port typically has a one to one correspondence with a display surface and knows how to render to it.
Controller
contains the interface between model and view
Concept
The Controller receives user input and initiates a response by making calls on model objects.
A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
Version
MVC-I
Controller/View
Takes care of input/output, interface to model
Model
In charge of business logic
MVC-II
Controller
View
Model
completely separate view and controller
Applicable domain
Suitable for where multiple views needed for a single data model and the graphics interfaces prone to data changes.
There are clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications.
Benefits
Easy to plug in new or change interface views,
Very effective for developments (team working by different professionals)
Limitations
Does not fit agent-oriented application such as robotics applications
Multiple pairs of controllers and views make data model change expensive
The division between the View and the Controller is not very clear in some cases
Presentation-Abstraction-Control (PAC)
PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements.
PAC: hierarchy structure for interacting or cooperating agents
Key idea
An agent
Components
Control
Abstraction
Presentation
responsible for one function
Usage
PAC is suitable for distributed systems where all agents are distantly distributed and each agent has its own functionalities with data and interactive interfaces.
Sometimes, middle level agents, the interactive presentations are not required.
Applicable domain
Suitable for where there are many cooperating agents in a hierarchical structure.
The coupling among the agents is expected very loose
Benefits
Supporting multi-tasking, multi-viewing
Supporting agent reusability and extensibility
Easy to plug in new agent or replace an existing agent
Supporting concurrency
Limitations
Overhead due to the control bridge.
Difficult to design agents
DangMNN
Chapter 10: Distributed Architecture
10.1 Overview
A distributed system is a collection of computational and storage devices connected through a communications network
Two important elements of designing a distributed system
Network topology
The way in which entities are organized to form a connected network
Communications mode
The method by which components communicate with each other
Many models available
Client-server architecture
Multi-tier architectures
Broker architecture such as CORBA, and the service-oriented architecture (SOA)
10.2 Client-Server
The client-server model is the most commonly distributed system architecture
It is
based on two communicating processes,
Running on different processors
Decomposes a system into two major subsystems
Client
Server
The server process receives the request ,carries it out, and sends a reply to the client.
Two tier: client and server
Advantages
Responsibility separation such as user interface presentation and business logic processing
Reusability of server components
Disadvantages
Lack of heterogeneous infrastructure to deal with the requirement changes
Security complications
Server availability and reliability
Testability and scalability
10.3 Multi-tier
At least 3 tiers
Front-end tier - User interface presentation tier
Middle-end tier - Business logic tier
Back-end tier - DB management tier
Advantages of multi-tier over two-tier architecture.
Enhanced reusability and scalability by adding the middle tier
Middle layer is easy to change
Have portable and nonproprietary design and implementation
Middle layer can provide multi-threading support
Reduces traffic on the network
Cons
Difficulty in testing due to lack of testing tools
Adding multiple servers in the system makes the server reliability and availability even more critical
10.4 The Broker architectural style
Transparently distribute aspects of the software system to different nodes
An object can call methods of another object without knowing that this object is remotely located.
CORBA is a well-known open standard that allows you to build this kind of architecture.
Broker Style
Typical middleware arch. from mid 1990’s
Key Idea
Service provider register services through broker
Clients discover services through broker
Clients submit requests to broker
Broker massages requests from clients and relay results from service provider
Broker Architecture
Sub-components include
Broker
It coordinates communications, passing on request and returning replies
It stores all servers’
It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.
Stub
Mediates between the client and the broker and providing additional transparency between them.
To the client, a remote object appears like a local one.
The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server.
The stud is generated at compilation time and deployed at client side to be used as a proxy for client
Skeleton
It is also generated by service interface compilation and deployed at server side
Encapsulates low-level system specific networking functions like client proxy and provides high level APIs to mediate between the server and the broker
It receives and unpacks the requests, unmarshals the arguments, and calls the appropriate service.
When receives the result back from the server, it also marshals results before sending it back to the client.
Bridges
Optional component
Hide implementation details when two brokers interoperates
Can translate requests and parameters from one format to another
Network
Connects components using designated protocol standards such as
TCP/IP
OIIP
SOAP
The request carries data in a message document or method invocation format.
Advantages
Server component implementation and location transparency
Changeability and extensibility
Feasibility of run time changes of server components (add or remove server components)
Disadvantages
Inefficiency due to the overhead of proxies
Low fault tolerance
Difficulty testing
10.5 Service-Oriented Architecture (SOA)
What is SOA?
A Service Oriented Architecture (SOA) starts with a businesses process.
In this context, a service is a business functionality that is well-defined, self-contained, independent from other services, and published and available to be used via a standard programming interface.
Software manages business processes through a SOA with well-defined and standard interfaces that can build, enhance, and expand their existing infrastructure more flexible.
SOA services can be extensively reused within a given domain or product line, and even among legacy systems.
Loose coupling of service–orientation provide great flexibility for enterprises to make use of all available service recourses regardless of platform and technology restrictions.
The connections between services are conducted by common and universal message oriented protocols such as the SOAP Web service protocol, which can deliver requests and responses between services loosely.
A connection can be established statically or dynamically.
Advantages of SOA
Loosely-coupled connection: Loose-coupling is the key attribute of SOA.
Each service component is independent from other services due to the stateless service feature.
The implementation of a service will not affect the application of the service as long as the exposed interface is not changed.
It makes SOA software much easier to evolve and update.
Interoperability: Technically any client or any service can access other services regardless of their platform, technology, vendors, or language implementations.
Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier.
SOA based business application development comes much more efficient in term of time and cost.
Scalability: Loosely coupled services make themselves easy to scale.
The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute.
Chapter 11 Component Based Architecture
11.1 Introduction
Component-based Architecture used to
Divide a problem into sub-problems
Each sub-problem is associated with a component
Interface plays an important role
Motivation
Components are highly reusable
A component encapsulates the functionality and behaviors of a software element into a reusable and self-deployable binary.
Use of COTS or developed in-house components
Increases overall reliability
Can greatly reduce development cost
Important points
A component is a deployable software package that can provide services to its client
It may require services from other components
It remains self-contained and substitutable as long as it interface is unchanged.
11.2 Components Vs. OO design
A component-oriented represents a higher level of abstraction than an equivalent OO design
The component-oriented design defines components and connections between them instead of classes and connections between classes
In component-oriented design
First identify all components and their interfaces
Advantages over CO design
Reduced time in market
Lower development costs by reuse of the existing components, and
increased reliability with reuse of the existing components
11.3 What is Component?
A component is a modular (cohesive), deployable (portable), replaceable (plug-and –play), and reusable set of well-defined functionalities that encapsulates its implementation and exports it as a higher-level interface.
A UML component can be mapped to any target technology component
11.4 Why use components?
Reusability
Productivity
Composability
Adaptibility
Scalability
Reliability and many others
11.5 Component Implementation
Usually consists of a set of class files
Abstract Interface
Concrete Implementation Classes
Note
Some IDE tools support visualization of components, e.g., VS Studio .Net Toolset
However, it does not mean that each component should have such a visual representation
11.6 Why Interface & Implementation?
Separation of Interface and Implementation allows changeability!
11.7 Principles of Component-Based Architecture
Figure out semantics of connections
Communication semantics important
Local: relatively easy
Remote: pay attention! many different call semantics
Think about INTERFACE, not the implementation
11.8 Component Level Design
Before the design phase, we have
Use case modeling
Business concept modeling
Use case diagrams
Describes user interactions with the system which indicate all necessary operations of the component
We can map use case diagram to the provided service interfaces of the first-cut component specification
A collaboration diagram
s an identifiable slice of functionality that describes a meaningful service involving several concepts.
A collaboration diagram ----> the implementation of a use case
For each use case U, there will be a collaboration diagram “encapsulated” in a component C.
Use case component implementation
Business concept diagram
Depicts the relationships of the business process entities in the domain
Extract business process entities that can exist independently without any associated dependency on other entities.
Recognize and discover these independent entities as new components.
Starts from Use Case Diagram
May also need business concept diagram
Mapping
Use case 🡪 interface provider
conceptual classes 🡪 modules of components
If necessary, big components can be further decomposed
Chapter 12: Heterogeneous Architecture
12.1 Overview
Motivation
Not likely One Architecture Suffices
Think About Designing a Castle
Walls
City Hall
Civilian Housing ...
Heterogeneous architecture styles are used to combine benefits of multiple styles and to ensure quality and appropriateness.
Real-World Projects Are Complex!
Heterogeneous Architecture
Many ways to have heterogeneous arch.
Hierarchical
Components composed using on arch
Each component internally using a different one
Mixture of Arch
E.g., filter of a pipe&filter arch. accesses central DB
12.2 METHODOLOGY OF ARCHITECTURE DECISION
Methodology of Architecture Decision
A Designer Has To
Exhaust all possible solutions
Pick up the best one
Task here
Given the list of architectural styles
Pick up the best one
Process of Choosing Style
Architecture Style Heavily Depends on Requirement Analysis
12.3 QUALITY ATTRIBUTES
Used to make architectural decision
Common Quality Attributes
Efficiency (time and space)
Functionality (completeness, interoperability)
Portability (hardware independence, installability)
Reliability (error tolerance, availability)
Usability (user interface, learnability)
Architectural Decision Procedure
Determine the required quality attributes in requirement analysis
Quantify the quality attributes
Many can be directly quantified
Many should be assigned qualitative values first, then quantified
Compute the weighted sum
12.4 SELECTION OF ARCHITECTURE STYLES
Methods of Evaluating Arch. Style
Largely depends on designers’ expertise
However, tools available
Engineering handbook
Qualitative Evaluation of Arch. Styles
12.5 EVALUATION OF ARCHITECTURE DESIGNS
Evaluate System Arch. Design
Many approaches available
ATAM (Architecture Trade-off Analysis Method)
SAAM (Software Architecture Analysis Method)
ARID (Active Reviews for Intermediate Designs)
SAAM (Software Architecture Analysis Method )
Idea: Evaluate design against Scenarios
Scenario
Similar but different from use case
Can contain situations not included in the scope of the project
Design Objective: Tax Report Processor
Functionality
Process tax return forms
Information incorporated into an tax payer object
The object’s type determined by occupation of the tax payer
E.g., AmericanLayer, AmericanProfessor, etc
Quality Attributes
System expandability.
More occupation types can be added
E.g., AmericanFarmer, AmericanBusinessOwner, etc.
System performance
Be able to process millions of cases per day
Space efficiency a less concern
System modifiability
Format of tax forms and the method of calculating tax rates change every year.
System must be ready for such changes
12.6 Selection of Architecture Styles
Data Flow
Batch & Sequential
Pipe & Filter
Process Control
Data Centric
Repository
Blackboard
Hierarchy
Main-Subroutine
Master/Slave
Layered
Virtual Machine
Implicit Invocation
Event Based
Buffered Message
Interaction Based
MVC
PVC
Distributed System
Client Server
Multi-tier
Broker
SOA
Component Based
Candidate
