Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture and Design Illuminated CH2 - Coggle Diagram
Software Architecture
and Design Illuminated CH2
Chapter 2:
Software Architecture Design Space
2.1 Overview
A software architect's responsibility:
proposing a concrete architecture that best supports the detailed design and implementation of a specific roject.
Based on quality attributes
Software architect must understand the
software architecture's design space:
design alternatives that can support functional and
non-functional requirement specifications
Design Space
2.2 Type Of Software Structures
2.2.1 Software Static Structure
A software project is typically implemented in
multiple files. This includes
Executable files
Library files
Binary software component modules
JavaBeans
DLL
Deployment descriptors
Others resources files
At software development time
The main software elements are source code files
Each modules has assigned functional and nonfunctional attributes
API defined for modules separates module's interface and implementation
The connectors at this level are in the form of module dependency
Static connectors may exhibit some attributes
Direction
If module A invokes a method of module B during execution, there is a connection from module A to module B
Synchronization
Can be synchronous or asynchronous
Sequence
Some connectors must be used in a particular sequence.
At deployment time:
The element are binary versions of the project modules and files.
Several source code modules may be packaged into the same deployment unit
The connectors in the deployment structures are basically as those for the source module
structures
2.2.2 Software Runtime Structure
These elements may run on the same computer or
on multiple computers across a network
A runtime project consists of elements:
Web services
Processes
Threads
Distributed objects
Software runtime structures serve as the technical backbone of architecture designs and provide the basis from which other structures are derived.
Runtime Connectors inherit attributes from their source-code structure counterparts, with a few extraattributes
Multiplicity
One element can be connected to multiple elements if it needs to invoke methods of multiple elements at runtime. e.g, web service, client-server
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
Media can be
Copper/optical
Wired/wireless LAN
Decides the system performance and reliability
Universal invocable:
A connector with this attribute set to true allows any external software system to invoke the methods at the connector;s target, irrespective of hardware/software platform, and programming languages
Important for heterogeneous system.
Sefl-descriptive:
A connector with this attribute set to true allows any external software system to invoke its target method without preinstallation of any software specific to the method.
It allows clients to choose service providers dynamically.
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.
2.3 Software Elements
What is Software Element?
At runtime, element is a component of a
system
Has well-defined functions
Usually interface is public and fixed, and
Implementation can change with the time
Connected with with other via connector
Software Architects Job
Map functional requirements to software elements
The following are the basic guidelines for
mapping runtime elements into their
implementations:
Rule 1: Reenntrant
Reentrant describes a computer program or routine that is written so that the same copy in memory can be
shared by multiple users
A computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then
safely called again ("re-entered") before its previous invocations complete executing.
A programmer writes a reentrant program by making sure that no instruction modify the contents of variable values in other instructions within the program.
Commonly required in
operating systems and in applications intended to be
shared in multi-use systems
Rule 2: Handle Bottle-Neck First
Treat bottle-neck functionality using the following approaches
(1) Wrap it as a separate and highly independent module
(2) Improving its efficiency by replication
(3) Depending on computing needs, allocate cluster or multiCPU computers for bottle-neck modules in deployment
Rule 3: Make Things Simple
If a module is tool large
Split it into smaller ones
Vertical Layers
Each upper layer calls the functionality of lower layers
Typical Example: OS and Network
Horizontal Layers
Business logic divided into a sequence of stages
Example: pipeline
2.4 Software Connectors
What is Software Connectors?
Connects the modules of a system
Should be refined within the design process.
Connector refinement is heavily influenced by a project’s
deployment environment
Usually determines the quality attributes of a system
Efficiency
Reliability
Availability
Security
Can be classified into many categories
Software Connectors Guideline
During the refinement of the software architecture
If the two elements are mapped to a single process, the
connector could be mapped to a local method invocatio
If the two elements are mapped to two different processes on the same computer, then the connector could be mapped to a local message queue or a pipe
If the two elements are mapped to two different computers, then remote method invocation or Web service invocation could be used for the architectural refinement for the corresponding connector between them
Connector type – Based on Synchronization
Blocking
A blocking connector allows one of its incident elements to
send a request to another and wait for a response
The element will be blocked from further execution until it
receives a response.
Non-blocking
A non-blocking connector 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
It only allows one of the two connected elements initiates the request, but not another way around
E.g., web-browser and web server
Two Initiator
either of the two elements can make the request
E.g., call-back between two subsystems, the two subsystems must be connected by a two-initiator
connector
Information Carrier
Connector information Career
Variable
for elements in the same process
Environment resource
for elements in different processes of the same system
Method
Local invocation
Remote invocation
Message…
Connector Implementation type
Signature based
Usually method invocation
Signature: the method name plus the list of parameter types
Method parameter indicates operation type
Protocol based
A protocol-based connector can implement multiple operation types with a single binding signature
E.g., HTTP, SMTP, etc.
Programmed vs. Event Driven
Based on connector’s active time
Programmed
A method call will be made at a time specified at programming
time
Event-driven
All elements that need be notified of the event will register as listeners of the event source
When the event happens, all the registered listener elements will be notified for potential reaction
Method callback can be considered as a special case of this event-driven mechanism
Local vs. Networked
Depending on connector span
Local
Network
Typical examples:
Local method invocation, function call (local)
Distributed Remote Method Invocation (RMI)
Remote Procedure Call (RPC
Network Connectors need more efforts
Invocation semantics (tricky)
Reliability (hard)
Security (problematic, e.g. RPC)
However, desperately by distributed computing environments
Homogeneous vs. Heterogeneous
Homogeneous:
both elements must be on the same platform
Heterogeneous:
both elements can be on different platforms.
2.5 An Agile Approach to Software Architecture Design
Key: Iterative Refinement
Traditional Water-Fall Approach
Big gap between
Requirement specification
Software Architecture
Iterative Refinement
Refine designs based on changing requirement
Example: Stand Alone Data Presenter
Requirement: serving data to a single user
Extension: Networked Data Presenter
Extension: Web Based Data Presenter
Requirement changed: client needs to access data
via Internet
Deployment
Conclusion: the basic structure not changed but the
details can be refined