Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software architecture (2.Design space (2.4 Software Connectors (The…
Software architecture
2.Design space
2.1.Overview
A software architect is responsible for proposing a concrete architecturethat best supports the detailed design and implementation of a specific project.
In its simplest form, a software architecture design is a set of software elements connected by a set of connectors.
In terms of the static structure, a software element can be a package, a class, a component, or a loadable library.
In the rest of this chapter we discuss the design space for software architectures and put in perspective the fundamental concepts behind the latest implementation technologies.
2.2 Types of Software Structures
2.2.1 Software Static Structure
A software project is typically implemented in multiple files.
At software development time, the main software elements are source code modules or files.
The connectors at this level are module dependent.
Direction
Synchronization
Sequence
At software deployment time, the elements are binary versions of the project modules and Hies
Classes are the basic building blocks of Java software. Packages support the hierarchical and static organization of a large Java program as "logical and name space" managing units.
Java units declared inside other units, such as packages, classes, or interfaces, yield a tree-like hierarchy
Managing static structures involves layers of abstraction and of refinement showing visibility and encapsulation, respectively.
A linear client-server relation
A tree-like hierarchy of refinement relations
2.2.2 Software Runtime Structure
At runtime a project consists of one or more threads, processes, functional units, and data units. These elements may run on the same computer or on multiple computers across a network.
The connectors at this level inherit attributes from their source-code structure counterparts, along with the other attributes
Multiplicity
Distance and connection media
Universally invocable
Self-descriptive
2.2.3 Software Management Structure
A large software project is normally designed and implemented by several project teams, each having its well-defined responsibilities at specific SDLC process stages.
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
2.3 Software Elements
At runtime each software element has well-defined functions and connects to the other elements into a dependency graph through connectors.
The basic guidelines for mapping runtime elements into
their implementations
If an element is reentrant, it can be implemented by a thread or a process. Reentrant elements are usually more efficient because they avoid many synchronization issues and support shared thread or process pools. However, business logics may not allow some elements to be reentrant
If an element is not reentrant and multiple threads or processes need to communicate with it, it must be run on separate threads or processes in order to be thread-safe (meaning that the system behavior is not affected by the multiplicity of threads executing concurrently).
A complex element can be expanded into a subsystem with its own elements and connectors. A well-defined interface should be used to encapsulate the subsystem's design and implementation details from the existing architecture.
If an element has high multiplicity and its performance is important to the global system performance, an application server (a software system running business logics) should be used for the element's implementation so that it can take advantage of thread and resource pooling, data caching, and dynamic element life cycle management to conserve resources.
If the elements contain heavy computations for deployment at a particular location, a cluster of processors will enhance CPU data processing power. The cluster size and the elements' mapping to the cluster computers should be done carefully to balance each cluster's computation load and minimize the total communication
traffic on the cluster's network.
If an element is assigned complex but well-defined functions, similar to those of some commercial off-the-shelf software components, and the performance of this element is not critical, then it is more cost-effective to use an existing software component to implement the element's functions.
A complex element can be transformed into a sequence of vertical layered elements if each layer provides a virtual machine or interface to its immediate upper-layer element, and each layered element hides away some low-level system details from the upper layers.
A complex element can be transformed into a sequence of horizontally tiered elements if the business logic can be achieved by processing data with a sequence of discrete processing stages, and these processing stages can be implemented by tiered elements with well-defined interfaces and balanced workloads.
2.4 Software Connectors
The connectors in a software architecture are refined during the design process and are heavily influenced by a project's deployment environment.
Software connectors are classified according to many attributes, including synchronization mode, initiator, implementation type, active time span, fan-out, information carrier, and environment.
Based on the connector's initiator, we can classify all connectors into two categories: one-initiator connectors and two-initiator connectors, as shown in Figure 2.2 (b)
The information flow on a connector can be implemented using various information carriers, as shown in Figure 2.2 (c).
Based on the implementation type, a connector may be classified as signaturebased or protocol-based, as shown in Figure 2.2 (d).
Connector active time refers to when an operation request or message is sent over a connector. Connectors may be classified into programmed connectors and event-driven connectors, as shown in Figure 2.2 (e).
Based on the connector span between incident elements, we classify the connectors as local connectors or networked connectors, as shown in Figure 2.2 (f).
Based on connector fan-out (the number of elements one element can connect to) we classify connectors as 1—1 connectors and 1—* connectors, as shown in Figure 2.2 (g).
Based on connector environment, which is the implementation technology or supporting platforms of a connector's two incident elements, we classify connectors into homogeneous connectors and heterogeneous connectors, as shown in Figure 2.2 (h).
Heterogeneous connectors are usually implemented with the broker design
pattern.
2.5 An Agile Approach to Software Architecture Design
Traditional software architecture designs, fundamentally based on a waterfall model
Figure 2.5 shows a possible design, in which the client GUI module receives data retrieval criteria from the client and presents the selected data to the client in a graphical user interface.
The connector between the client GUI module and the data retrieval & processing module now has a new networked attribute, as shown in Figure 2.6.
HTML and HTTP based data presender are shown in Figure 2.7.
Web architecture is shown in Figure 2.8.
2.6 Summary
Software architecture determines the overall structure of a software system and greatly impacts its quality
Each type of structure consists of elements and connectors and their constraint attributes, which are derived from the
requirements specification
A good architecture solution is typically based on multiple architecture styles for different subsystems or for different system abstraction levels.
1.Introduction
Software Architecture: Bridging Requirements and
Implementation
The architecture design provides a blueprint and guideline
for developing a software system based on its requirement analysis specification.
Software design depends on the Software Requirement Specification (SRS)
produced by analysis in the first step of SDLC.
Quality Attributes
Quality attributes are identified in the requirement analysis
process.
Implementation attributes (not observable at runtime)
Runtime attributes (observable at runtime)
Business attributes
In many cases, no single architecture style can meet all quality attributes simultaneously
Architecture Styles
An architecture style (also known as an "architecture pattern") abstracts the common properties of a family of similar designs. An architecture style contains a set of rules, constraints, and patterns of how to structure a system into a set of elements and connectors
elements that perform functions required by a system
connectors that enable communication, coordination, and cooperation among elements
constraints that define how elements can be integrated to form
the system
attributes that describe the advantages and disadvantages of the
chosen structure
Software Architecture Design Guidelines
Think of what to do before thinking of how to do it
Think of abstract design before thinking of concrete design
Think of nonfunctional requirements early in the design process
Think of software reusability and extensibility as much as possible
Try to promote high cohesion within each element and loose coupling between elements
Tolerate refinement of design
Avoid ambiguous design and over-detailed design
Overview
The goal of software design is to build a model that meets all customer requirements and leads to successful implementation
Software architects and designers are involved in this process.
Software architecture design has emerged as an important part of software development
Characteristics of OOP
Encapsulation
No direct access is granted to the data, instead it is hidden. To gain access to the data, you interact with the object responsible for the data
HR Departments are an example of real-life encapsulation
Security
Reliability
Polymorphism
Two different objects respond to the same request message in their own unique way; objects can respond to messages in their own unique implementation
Polymorphism is done through a process called overloading
Inheritance
Where classes and objects can be derived from parent classes and objects, inheriting all the characteristics and methods and then extending them
Objects
A structure for incorporating data and the procedures for working on that data
Abstraction
Refers to the ability to filter out unnecessary or unimportant information; when you interact with objects in the world you only want to focus on that which is important for the task you are wanting to carry out
Due to this, when two different objects interact with the same object, they will often deal with a different set of attrubutes
Data Flow Architecture
Pipe & Filter
Similar to Batch Sequence
Independent modules
Data connectors
Difference
Connectors are stream oriented
Concurrent processing
Basic Concepts
Data Source
Data Sink
Filter
Does not even have to know identity of i/o streams
Process data and write to output stream
Does not wait for batched data as a whole
Reads data from input data stream
Pipe
Moves data from one filter to another
Two types: character or byte streams
Data Flow Methods
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
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.
Classification of Filters
Active Filter
pulls in data and push out the transformed data (pull/push)
It works with a passive pipe that provides read/write mechanisms for pulling and pushing
Passive filter
Lets connected pipe to push data in and pull data out.
The filter must provide read/write mechanisms in this case.
Advantages
Concurrency is high.
Reusability is easy – plug and play
Modifiability: Low due to coupling between filters
Simplicity: Clear
Flexibility: High, very modular design
Lower latency
Disadvantages
Not suitable for dynamic interactions
Data standards (ASCII, XML?)
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
Difficult to configure a P&F system dynamically.
Error handling issue
Categories
Many sub-categories exist
Batch Sequential
Pipe & Filter
Process Control
To adopt which one depends on the nature of the problem
What is data flow architecture
Whole system as transformation of successive sets of data
System decomposed into modules
Connection can be
Files, Buffers, Pipes
IO Stream
No interaction between modules
Modules do not need to know identity of each other
Batch Sequential
Traditional data processing model
Widely used in 1950’s – 1970’s
Example: mainframe computers using COBOL
implement Batch Sequential
Usually done in batch processing language or shell script
DOS Batch File
Direct implementation in coding
Benefits
Simple division between sub-systems
Each sub-system can be a stand-alone
Limitation
No interactive interface
No concurrency and low throughput
High latency
Pros and Cons
Benefits
Better for situations where no precise formula for deciding the manipulated variable
Can be completely embedded
Limitations
Requires more sensors to monitor system states
Data-Centered Software Architecture
Blackboard
Flow of logic
Determined by current data status -----> Data driven
New data -> trigger event -> knowledge source take action -> response to event -> new data -> change logic flow
Domain
solving immature - complex AI problems
The problem spans multiple disciplines
Optimal, partial, or approximate solution is acceptable
Exhausted searching is impossible.
Pros
Scalability
Concurrency
Cons
Overview
Components
Software Component Agents
Data Store
A centralized data store that is shared by all surrounding software components
Repository
Control flow logic
By client
Access Repository via
Interactively
Public Diagram
Domain
large complex information system
Data transactions drive the control flow
Pros
Integrity: easy to backup/restore
Scalability + Reusability
Cons
Reliability + Availibility
High dependency
Cost
Variants
Virtural Repository
On top of physical repository
== view in DB -> Simplify DB structure
Security mângement
Distributed repository system
(distributed database system)
All data are distributed over all sites linked by network
Data are replicated ---> Improve reliability and local accessibility
Hierarchical Architecture
Main/Subroutine Architecture
How Sub-routine Call is Supported
by Assembly
Protect old register values by pushing to stack
Set parameters in register
Call the subroutine
by High Level Language
Much more convenient
Much more tricky!
Parameter passing
Purpose
Encourage re-use of modules
Idea
System decomposed into sub-routines
A “main” program calls sub-routines and accomplishes task
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
Summary
Probably the oldest and most widely used architecture
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
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
Applicable Design 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
Many applications can not fit this architecture
Exception and error handling
Virtual machine
Variation of Layered Approach
Idea
Provide a virtual interpretation layer that separates
Application
Physical machine layer
i.e., Software/Components run on simulation layer
Applicable Design Domain
Suitable for solving a problem by simulation or translation
Sample applications such as interpreters of microprogramming, XML processing, script command language execution...
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
Master-Slave
A variant of main-subroutine architecture
It supports Fault tolerance and system reliability
In this architecture
The slaves provide replicated services to the master
The master selects a particular result among slaves by certain selection strategies.
Diagram
Block diagram
Class diagram
Characteristics
Applicable domain Where reliability is crucial
IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
Asynchronous implicit invocation communications
Two different modes
Non-buffered
Buffered
Also called publisher-subscriber or producer-consumer patterns
Subscribers are interested in some events or messages issued by a publisher
Consumers are interested in some events or messages issued by a producer
Message-Based Architecture
Publish-Subscribe Messaging (P&S)
is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board.
Message topic publishers and subscribers are not aware of each other.
One difference between P&S from P2P is that each topic message can have multiple consumers.
The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system.
Publishers and subscribers have a timing coupling dependency.
A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription
Applicable Domain
Suitable for a software system where the communication between a producer and a receiver
The provider wants the components not to depend on information about other components' interfaces
allows a component to send information to another and to continue to operate on its own without waiting for an immediate response.
Point-to-Point Messaging (P2P)
a point-to-point structure between producer and consumer
A P2P messaging architecture is composed of message queues, senders, and receivers.
Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queues.
The queue retains all messages they receive either until the messages are consumed or expire.
allows multiple message receivers but one and only one of them will get the message
have no timing dependencies, receiver can still get the message even it was not available when the sender sent the message
It is much more reliable than simple event-listener based system we discussed earlier.
Benefits
Providing high degree of anonymity between message producer and consumer.
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
Increased complexity of the system design and implementation
Non-Buffered Event-Based Implicit Invocations
breaks the software system into two partitions: Event sources and event listeners.
The event registration process connects these two partitions
There is no buffer available between these two parties
Observer pattern is another name used for this type of architecture.
Subscribers is an event listener and register themselves with the event source.
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
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 or
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 Software Architecture
The buffered message-based software architecture breaks the software system into three partitions
Message producers
Message consumers
Message service providers
Message service providers
message queue : one-to-one
message topic: one-to-many
This architecture is also considered data-centric.
are used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication.
a peer-to-peer client-server architecture.
The high degree of independency between components within the messaging system is one of its most important features.
Its high scalability, interoperability in heterogeneous networks
3.Models
UML for Software Architecture
Overview
Is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system
UML offers a standard way to draw a system's blueprints including conceptual notions
is widely used as a guideline for software requirement analysis and design documents, which are the basis for software development.
UML can be used to model the problem domain
UML provides several modeling diagrams that can be grouped into two major categories: structural (static) and behavioral (dynamic).
Diagrams
Behavioral Diagrams
Class Diagram
provides a static view of the system
can be derived from use-case diagrams or from text analysis
of the given problem domain.
describe each individual class with its type, interface, properties, and methods.
A class diagram may be refined from time to time during the software development life cycle.
Object Diagram
is used to describe a sample subset of objects in the system at a specific point in time.
shows a snapshot of class instance connection and interaction.
Many other behavioral diagrams (sequence diagrams, communication diagrams and interact diagrams) may make reference to the object diagram
Composite Structure Diagram
used to describe the composition of interconnected elements or the collaboration of runtime instances.
There are two basic notations in a composite structure diagram: collaboration (represented using a dashed eclipse) and structured class (represented using a rectangular box).
Component Diagram
A component is a deployable, reusable building block used in software design and development.
Each component has an interface to expose its services and hide its implementations.
is the contract between a reusable component and its clients.
Package Diagram
represented by a tabbed folder that indicates where all
included classes and subpackages reside.
shows the dependency relationship between packages in which a change of one package may result in changes in other packages
help reduce the dependency complexity and simplify relationships among groups of classes
Structural Diagram
depicts the physical configuration of the software system deployed on hardware server nodes and the network between the nodes (defined as protocols).
Component diagrams are the basis for deployment diagrams
All components in the system must be deployed on servers to provide services via network protocols.
Deployment Diagrams
Use Case Diagram
Activity Diagram
State Machine Diagram
Interaction Overview Diagram
Sequence Diagram
Communication or Collaboration Diagram
Timing Diagram
Architecture View Models
Overview
View Model
The Scenario View
The Logical or Conceptual View
The Development or Module View
The Process View
The Physical View
The User Interface View
Overview
specifies a high level of software system abstraction
specify the deployment configuration of all components and connections
a software architecture design must conform to the project's functional and nonfunctional requirements
Every software architecture must describe its collection of components and the connections and interactions among these components