Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chap 9 -12 - Coggle Diagram
Chap 9 -12
Chapter 12 Heterogeneous Architecture
Heterogeneous Architecture
Many ways to have heterogeneous arch.
(1) Hierarchical
Components composed using on arch.
Each component internally using a different one
(2) Mixture of Arch.
E.g., filter of a pipe&filter arch. accesses central DB
Methodology of Architecture Decision
Question: Is the job of design to find one feasible solution?
No!
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
Limitation of the resources + different requirements (user’s in 80’s don’t care too much about crash of computers!)
Why does not DOS in 80’s runs in Kernel Mode?
Example:
Design of
MS-Controller
Requirements
Interact with Inventory for smooth supply-chain
Manage all stage computers for coordinating process
Architecture Selection: Layered Style
Core-Engine Module
Architecture Selection?
Event-Based!
Assembly Line Started
Retrieve list of orders of the day.
Send requests to inventory for parts
Parts delivered at one stage
Based on part code, find the order which uses it and update the information.
When all parts ready, triggers the all parts ready event.
Core Engine
All parts ready for an order
Schedule job to one of assembly lines
Consult business logic about split of manufacture process
Map “logical stages” to physical stages
Chassis arrived at one stage
Send job details to the stage computer
Parts malfunction
Send instruction: “Pull the chassis off line ...”
Send emergency parts retrieval requests
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
(1) Determine the required quality attributes in requirement analysis
(2) Quantify the quality attributes
Many can be directly quantified
E.g., time efficiency by throughput, latency, etc.
Many should be assigned qualitative values first, then quantified
E.g., “Excellent” 100, “Average” 50, ...
(3) Compute the weighted sum
Methods of Evaluating Arch. Style
Largely depends on designers’ expertise
However, tools available
Engineering handbook
E.g., typical applications such as DB app., Web App. – typical designs in textbook/handbook
Qualitative Evaluation of Arch. Styles
See diagram in next slide
Evaluate
Many approaches available
ATAM (Architecture Trade-off Analysis Method)
SAAM (Software Architecture Analysis Method)
ARID (Active Reviews for Intermediate Designs)
Similar to Order Processing System
Which architecture style to use?
MVC
Good for separating presentation and business logic
Component Based Architecture
Good for functional division
SOA vs. CBA
Disadvantages of CBA (compared with SOA)
Older technique than SOA
No directory service such as UDDI (service yellow page)
Benefits
Better efficiency
No need to convert to XML, use binary data exchange
Can be stateful (unlike SOA)
No need for directory service because all components are well known inside
Finalists
Batch Sequential + Repository
Layered or Multi-tier
Service Oriented Architecture (SOA)
Component Based Architecture (CBA)
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
Example:
Given an online registration system
Sample scenario: what if the internal registration form is changed?
It tests the “modifiability” of the system
Selection of Architecture Styles
Component Based
Candidate: suits loosely coupled services provided by OCV. It has very good support from UML. The architecture is very similar to SOA, except that SOA provides service directory (such as UDDI) to locate services, which is not needed here. Cons: data representation may not be as flexible as XML (semi-structured) representation in SOA.
Distributed System
Client Server
Ruled out: the model does not suit the multiple components and multiple tasks of OCVS.
Multi-tier
Candidate: similar to layered system.
Broker
Ruled out: low efficiency and difficulty in testing.
SOA
Candidate: suits loosely coupled services and departments.
Hierarchy
Main-Subroutine
Ruled out: OCVS has to support multiple tasks (e.g., order processing, inventory management and prediction, etc.). There is no need for a central coordinator.
Master/Slave
Ruled out: similar to Main-program-Subroutine.
Layered
Candidate: the services of OCV can be classified into layers.
Virtual Machine
Ruled out: OCVS is not in its application domain (e.g., machine simulation and porting of existing systems)
Data Flow
Batch & Sequential:
Candidate: suitable for order processing process. Cons: low efficiency, assembly line support not covered yet.
Pipe & Filter:
Ruled out: data transferred among dept. is not stream
Process Control:
Ruled out: OCVS not in its application domain (e.g., embedded systems)
Data Centric
Repository
Candidate: suits the needs for storing customer data and product configuration. Cons: the pure model forbids communication among system components.
Blackboard
Ruled out: OCVS not quite in its app. domain. Debugging and testing very hard
Implicit Invocation
Event Based
Ruled out: OCVS does not fall in its application domain (e.g., GUI applications)
Buffered Message
Ruled out: OCVS does not fall in its application domain.
Interaction Based
MVC
Ruled out: Although the web portal subsystem which interacts with customers may be a good candidate using MVC, the OCVS system has many other non-interactive sub-systems. Hence MVC is not the most appropriate architecture style for OCVS.
PVC
Ruled out: similar reason as MVC.
Motivation
Real-World Projects Are Complex!
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.
C. 10 Distributed Architecture
Overview
Distributed System
Is a collection of computational and storage devices connected through a communications network. Components are distributed
Two important issues
Topology: the way components connected
Model: the method they communicate with each other
Client-Server
The most commonly distributed system architecture
It has two communicating processes
Running on different processors
So, it is decomposed into two major subsystems
Client
Server
Server process receives the request, carries it out, and sends a reply to the client
Two tier
Front-end tier focuses on the user interaction
Back-end tier focuses on business logic and database management
Advantages
Separation of responsibilities 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
Fat clients with presentation and business logic together
Multi-tiers
At least 3 tiers
Front-end tier - User interface presentation tier
Middle-end tier - Business logic tier
Manages business logic and execution
Back-end tier - DB management tier
Handles database
Advantages of multi-tier over two-tier architecture
Middle layer is easy to change
Have portable and nonproprietary design and implementation
Enhanced reusability and scalability by adding the middle tier
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
Broker Architecture 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.
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
Sub-components include
Broker – provide service registration
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 (client-side proxy) – provide “stub” version of remote services, responsible for massaging messages
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 (server-side proxy) – encapsulates lower network details, dispatch requests to local service objects
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) – for interaction with brokers
Optional component
Hide implementation details when two brokers interoperates
Can translate requests and parameters from one format to another
Network – for interaction with brokers
Connects components using designated protocol standards
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
Disadvantages
Inefficiency due to the overhead of proxies
Low fault tolerance
Difficulty testing
Message Broker Architecture
Advantages
Reusability and maintainability: Loose coupling between the client and server component leads to easy maintenance and extension
on both sides.
Flexibility: Invocation-oriented or document-oriented messaging; message heading and body can be altered for specific purposes.
Disadvantages
Overhead, indirection complexity, and difficulty in debugging and testing due to the new protocol stack added
Service-Oriented Architecture (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.
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
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
Reusability
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 Software Architecture
Overview
Divides a problem into
subproblems
each associated with component partitions
The
interfaces
of the components play
important
roles
Motivation
: component
reusability
a component
encapsulates
the functionality and behaviors of a software element into a reusable and self-deployable
binary unit
Designs can make use of existing reusable commercial off-the-shelf (
COTS
) components or ones
developed in-house
They may
produce reusable components
for future reuse
=> increases overall system reliability
A
component
is a deployable software package that can provide services to its clients
It may also itself require
services
from other
components
.
A component remains self-contained and substitutable as long as its interface is unchanged.
vs Object-Oriented design
Represents a
higher level of abstraction
than an equivalent object-oriented design; the former defines
components and connections between them
instead of classes and connections between classes
A
component
is a higher-level concept, usually incorporating
more than one class
=> in component-oriented design we
first identify all components and their interfaces
Advantages over OO design
:
reduced time in market
lower development costs by reuse of existing components
increased reliability with reuse of existing components
Challenge
: to design components in such a way as to make it possible to adapt existing components in order to reuse them
Standard component frameworks
: COM/DCOM, JavaBean, EJB, CORBA, .NET, web services, and grid services.
What Is a 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
UML component notation
:
The circle interface symbol, called
provided port
, represents the services the component provides
The cup-like interface symbol, called
required port
, represents the services the component requires from other components
Why use components?
reusability
productivity
composability
adaptability
scalability
reliability
many other features
Component must have a
clear functionality
and be
self-contained
.
Components must be designed and developed for
easy reuse
.
Components should be very
reliable
.
It should be
easy to replace
or adapt any existing components.
It should also be possible to scale the service capacity by replacing components to increase functionality in the system
Component Implementation
Usually consists of a set of class files
Abstract Interface
Concrete Implementation Classes
Why Interface & Implementation?
Separation of Interface and Implementation allows
changeability
!
Principles of Component-Based Design
Connections of Components
Three categories of connections:
•
Ball and cup
(b2c or c2b) connection: connects two internal or two external components
•
Ball to ball
(b2b) or
cup to cup
(c2c) delegation: connects an external ball (cup) port to an internal ball (cup) port
•
I/O stream connection
Component-based software design is
design by contract
. The contract specifies the
interface
between the component and its clients.
we can substitute any component in the system
Connectors connect components, specifying and ruling their interaction.
Component-Level Design Guidelines
Before the design phase, we have:
Use case modeling
Business concept modeling
Use case diagrams
describe user interactions with the system which indicate all necessary operations (interfaces) of the component
We can map use case diagrams to the provided service interfaces of the first-cut component specification
The business concept diagram
The business concept diagram
depicts the relationships of the business process entities in the domain.
We can
extract
the business process entities that can exist independently without any associated dependency on other entities.
We can
recognize and discover
these independent entities as
new components
A
collaboration
is any identifiable slice of functionality that describes a meaningful service involving, in general, several concepts
A collaboration can be seen as the
implementation of a use case
.
=> Thus, for each use case U, there will be a collaboration diagram “encapsulated” in a component C
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
Applicable Domain
Applications where the
interface contracts
between subsystems are clear
Applications that
require loose coupling
between the components and where many reusable components are available
Suitable for the
class library system
organization (.NET class library and Java API are built in component architecture)
Evaluation
Benefits
:
Reusability
of components.
System
maintenance and evolution
Independency
and
flexible connectivity
of components.
Independent development
of components by different groups in parallel.
Productivity
Many
OO design tools
can also be used for component-based software development.
Limitations
:
Difficult to find suitable available components to reuse.
Adaptation of components is an issue
Few component-oriented dedicated design tools are available.
C.9 Interaction-Oriented Software Architectures
Interaction oriented SW architecture
More and more SW involve user input/output interaction, so specific user interfaces to software design.
Decomposes the system into
Data module
Provides data abstraction
All core business logic on data processing
Control module
Flow of control of view presentation
Communication between modules
Job dispatching
Certain data initialization
System configuration
View presentation module
Visual or audio data output presentation
Provide user interface when necessary
Separation of user interactions from data abstraction and business logic
Many view presentation in different data formats
Multiple views is supported for the same data set.
Even for a specific view presentation, the view or interface may need to change so often, so the loose coupling between data abstraction and its presentation is helpful. This is supported in this style.
Overview
Software has to interact with people
From 1950’s, existing human-computer-interaction
Punched Cards (1950’s)
Teletype Terminal (1970’s)
Personal Computer + Keyboard (1970’s)
Color Monitor + Mouse + GUI (1980’s)
Multimedia + Speech Recognition (1990’s)
Model View Controller (M-V-C)
Key Idea
Model: model of application’s logic
View: deal with graphic representation
Controller: contains the interface between model and view
Widely used in web applications
Concept for model
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).
Concept for View
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.
Concept for Controller
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.
MVC-I
Simplified System
Controller/View
Model
Controller/View
Takes care of input/output, interface to model
Model
In charge of business logic
MVC-II
Is a further development from the MVC-I architecture
The View module and the Controller module are separate
Applicable domains
Interactive applications where multiple views are needed for a single data model and the interfaces are prone to frequent data
changes.
Clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications concurrently.
Benefits
Many MVC vendor framework toolkits are available.
Multiple views synchronized with same data model.
Easy to plug in new or change interface views
Very effective for developments (team working by different professionals)
Limitations
Not suitable for agent-oriented applications such as interactive mobile and robotics applications
Multiple pairs of controllers and views based on the same data model make any data model change expensive.
The division between the View and the Controller is not 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.
Key Idea
Hierarchy structure for interacting or cooperating agents
Each agent has three components
Presentation
Abstraction
Control
Each agent responsible for one function
Sometimes all agents share the same control
Provides interaction between agents
Within each agent there are no direct connections between the abstraction component and presentation component
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
Support of multitasking and multiviewing
Support agent reusability and extensibility
Easy to plug in new agent or replace an existing one
Support for concurrency where multiple agents run in parallel in different threads or on different devices or computers
Limitations
Extra time lost due to the control bridge between presentation and abstraction and the communication of controls among agents
Difficult to design agents
Complete separation of presentation and abstraction by control in each agent generates development complexity since communications between agents only take place between the controls of agents.