Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 9 - 10 - 11 - 12 - Coggle Diagram
Chapter 9 - 10 - 11 - 12
Chapter 9 - Interaction-Oriented Software Architectures
9.2 Model-View-Controller (MVC)
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.
Widely used in web applications: MS ASP.Net, Java Swing
First introduced in 1980’s SmallTalk
Model: model of application’s logic
View: deal with graphic representation
Controller: contains the interface between model and view
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
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
9.3 Presentation-Abstraction-Control (PAC)
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
Overview
PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements
In PAC, the system is decomposed into
a hierarchy of
cooperating agents
Each agent has
three components
: Presentation, Abstraction, and 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
9.1 Overview
The interaction-oriented software architecture decomposes the system into
three major partitions
:
Data module
: provides the data abstraction and all core
business logic on data processing
Control module
: is responsible for visual or audio data output presentation and may also provide user input interface when necessary
View presentation module
: determines the flow of control involving view selections, communications between modules, job dispatching, and certain data initialization and system configuration actions
Key points
: separation of user interactions from data abstraction and business data processing
Chapter 10 - Distributed Architecture
10.2 Multi-tier
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
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.3 Broker Architecture Style
Overview
a middleware architecture
used in distributed computing to coordinate and facilitate communication between
registered servers and clients
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
Typical examples: CORBA, RPC, and RMI
Decompose the broker architecture into subcomponents
Broker
– provide service registration
Stub
(client-side proxy) – provide “stub” version of remote services, responsible for massaging messages
Skeleton
(server-side proxy) – encapsulates lower network details, dispatch requests to local service objects
Bridges
(optional) – for interaction with brokers
Network
– for interaction with brokers
Advantages
Server component implementation and location transparency,
Changeability and extensibility
Feasibility of run time changes of server components (add or remove server components)
Simplicity for clients to access server and server portability
Interoperability via broker bridges
Reusability
Disadvantages
Inefficiency due to the overhead of proxies
Low fault tolerance
Difficulty testing
10.1 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
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.4 Service-Oriented Architecture (SOA)
Advantages
Loosely-coupled connections
Interoperability
Reusability
Scalability
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
Chapter 11 - Component-Based Software Architecture
11.1 Overview
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
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 What is a component?
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
Why use components?
Reusability
Productivity
Composability
Adaptibility
Scalability
Reliability and many others
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)
Benefits
• Reusability of components
• System maintenance and evolution; easy to change and update the implementation without affecting the rest of the system
• Independency and flexible connectivity of components
• Independent development of components by different groups in parallel
• Productivity for the current and future software development
• Many OO design tools can also be used for component-based software development
Limitations
• Adaptation of components is an issue
• Few component-oriented dedicated design tools are available
• It can be difficult to find suitable available components to reuse
11.3 Principles of Component-Based Design
Figure out semantics of connections
Communication semantics important
Local: relatively easy
Remote: pay attention! many different call semantics
Think about INTERFACE, not the implementation
Chapter 12 - Heterogeneous Architecture
Heterogeneous architecture styles are used to combine benefits of multiple styles and to ensure quality and appropriateness
12.1 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
The process of selecting the architecture of a software system is closely related to requirements analysis
12.2 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
(3) Compute the weighted sum
12.3 Evaluation of Architecture Designs
usually depends on the expertise of software architects
However, tools available
Engineering handbook
Qualitative Evaluation of Architecture Styles
12.4 Evaluation of Architecture Designs
Many approaches available
ATAM (Architecture Trade-off Analysis Method)
SAAM (Software Architecture Analysis Method)
ARID (Active Reviews for Intermediate Designs)
SAAM
The SAAM analysis process generally consists of three stages:
Define a collection of design scenarios that cover the functional and nonfunctional requirements. Quality attributes should be reflected.
Perform an evaluation on all candidate architecture designs, using the collection of scenarios.
Perform an analysis on the interaction relationship among scenarios.
Quality Attributes
System expandability
More occupation types can be added
E.g., AmericanFarmer, AmericanBusinessOwner, etc.
System performance
Space efficiency a less concern
Be able to process millions of cases per day
System modifiability
System must be ready for such changes
Format of tax forms and the method of calculating tax rates change every year