Software Architecture

Dharmalingam Ganesan
Software Architecture – Insights
from Practice

2
What’s On The Agenda
● Software Architecture
● Introduction and Motivation
● Architecture vs. Design
● Software Connectors
● Software Architectural Styles
● Types of Styles
● Software Architecture Description
● Viewpoints, Views,
● Consistency across Views
● Architectural Perspectives and Quality
● Software Architecture for Product Lines
● Architecting for Variability and Commonality

3
Software Architecture
● Software architecture deals with the design of the high-
level structure of the software
● Assembly of architectural elements in some well-chosen
forms to satisfy requirements (including Reliability,
Scalability, Portability, etc)
● Software architecture = {Elements, Forms,
Rationale/Constraints}
● Software architecture deals with
● abstraction
● decomposition and composition
● styles

4
Architecture of Core Flight software
4
(BSP)

5
Why we need Software Architecture?
● Real-world systems are large and complex
● Need to divide-and-conquer
● Software architecture is used for:
● Distributing work to teams for developing components
(in parallel)
● Integrating components
● Planning and defining strategies for software testing
● Understanding the “big-picture” of the system
● Software architecture is for Project
Managers, Developers, Testers, Customers
(details next slides)

6
Use of Software Architecture for
Project Managers
● Managing large projects is a challenging task
● Software architecture can help managers through divide-
and-conquer strategy
● Project managers can use Software Architecture for:
● Assigning budget and effort for components
● Coordinating with architects, developers, testers, etc
● Assigning people with the right skills to the right components
(e.g., people with device-driver skills to Hardware/OS intensive
components)
● Tracking the project progress based on individual components
● Developing a business model or marketing strategy (e.g., selling a
part of the system, Open Source, Outsourcing)

7
Developers and Testers
● Developers should implement individual
components based on Software Architecture
● Developers need to understand Software
Architecture before making changes to
existing implementation
● Testers have to define test-strategy based on
Software Architecture, for example:
● Should low-level components be tested first,
high-level components be tested first, or a mix
● Testers may have to write mock-test or stubs
to unit-test individual components

8
System Builders
● Software Arch. is needed to compile, link, and
produce executables
● Developing Makefiles or build scripts requires
sound understanding of your architecture
● You can even generate Makefiles (or build
scripts) for each directory if you know your arch.
● Dependency rules are needed to compile the right
set of files when source code evolves

9
Architecture vs. (detailed) Design
● Difference lies in your context and how you see
● An architectural diagram in one context could
become a design diagram in another context
● For example:
● if you architect a component you may develop
architectural diagrams for it
● if the same component is used in another system,
then those arch diagrams become design diagrams

10
Architecture vs. (detailed) Design
● Architecture is concerned with global decisions
● Design is concerned with local decisions
● That is, architecture is concerned with the system-level
design decisions
● How components fit-together?
● What are the interfaces?
● System-level performance, scalability, security, etc.,
● Whereas design is concerned with sub-parts of the system
● How components are designed internally?
● Which algorithms to choose?

11
Software Connectors
●Connectors, for example:
●Procedure Call
●File
●Pipe
●Queue
●Socket
●Shared Memory
●Connectors are used for connecting
components

12
Components vs. Connectors
●Components provide application
functionality
● Connectors specify the protocol of
interaction among components
● Connectors are usually independent of
the application domain
● Connectors are often implemented by
programming languages or OS

13
(Some) Main Roles of Connectors
● Coordinator
● Wrapper
● Adaptor
● Monitor

14
Coordinator as a Connector
● Let us assume we want to draw a bar chart for
some stock data
● Also assume we have two components:
● CollectStockData – collects stock data to a file
● DisplayStockData – draws a graph based on the file
● How do we compose these two components?
● We need a coordinator that invokes:
1. CollectData
2. DisplayData

Coordinator as a Connector …
void collectStockData(File outputFile, …) {
/* Connect to the Stock Server */
…
/* Write stock data to the output file */
outputFile.write(…);
}
void displayStockData(File inputFile, …) {
/* Extract data from inputFile */
dataSet = readLines(inputFile)
…
/* Draw chart using dataSet */
…
ui.drawBarChart(dataSet);
}
void my_main() {
/* Collect stock data to a file */
collectStockData(dataFile);
/* Display the stock data */
displayStockData(dataFile);
}
coordinator

16
Wrapper as a Connector
● Let us assume we want to log the important
events of the system
● Apache’s Log4j is a popular library for logging
● If components of the system use Log4j directly,
there are a few problems:
● Not easy to replace Log4j by another library
● Possibly the layouts of log are different (hard to
analyze)
● Solution: Develop a wrapper to Log4j
● This wrapper acts as a connector to the Log4j
library

Wrapper as a Connector …
…
import org.apache.log4j.ConsoleAppender;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.EnhancedPatternLayout;
…
/**
* This class provides common logger wrapper to facilitate the customized usage
* of Apache log4j logger.
*/
public class LogService
{
// For current instance (singleton)
private static LogService instance = null;
// Log4j logger
private static Logger logger = null;
…
Wrapper

18
Adaptor as a Connector
● Adaptors are often used to handle mismatches in
interfaces of components
● Enables interaction of independently developed
mismatched components
● For example:
● Let Component A writes data to a pipe
● But Component B can read data only from a file
● How can we put A and B to work together?
● Solution: We need a Connector C that reads data
from the pipe (until EOF) and write to the file
from which B can read

Adaptor as a Connector …
void collectStockData(PipedWriter pw, …) {
/* Connect to the Stock Server */
…
/* Write stock data to the pipe */
pw.write(…);
}
void displayStockData(File inputFile, …) {
/* Extract data from inputFile */
dataSet = readLines(inputFile)
…
/* Draw chart using dataSet */
…
ui.drawBarChart(dataSet);
}
void my_adaptor() {
/* Collect stock data to a file */
PipedReader pr;
PipedWriter pw;
pw.connect(pr);
collectStockData(pw);
/* read from the pipe and write to a file*/
File dataFile = writeToFile(pr);
/* Display the stock data */
displayStockData(dataFile); …
Adaptor

20
Monitor as a Connector
● In practice, connectors are also used to monitor
the running system
● For example:
● all data written to a socket connector is logged by
the write method
● Counts number of write and read calls
● Time of write and read
● This data can be used by the
architects/developers for understanding the real-
traffic and improve system performance
● Run-time load balancing

21
● Types of Styles

22
Architecture Style of Historical
Buildings – Some Examples
● Dravidian Architecture characteristics:
● pyramidal towers of colossal height dominating the
surrounding landscape for miles around
● the rectangular enclosures one within the other
● the use of the flat roof and the entire absence of the
arch or dome;
● dependent on intricate carved stone

23
Families of Dravidian Architecture

24
Composition and Structure of
Dravidian Temples
1. The principal part, the actual temple itself, is called
the Vimana. It is always square in plan, and
surmounted by a pyramidal roof of one or more
stories; and it contains the cell in which the image of
the god or his emblem is placed.
2. The porches, which always cover and precede the
door leading to the cell.
3. Gate-pyramids , which are the principal features in
the quadrangular enclosures that surround the
more notable temples.
4. Pillared halls -- used for various purposes, and
which are the invariable accompaniments of these
temples.

25
Mughal Architecture Style – Taj
Mahal
● the architectural design of Taj Mahal uses the
interlocking arabesque concept:
● each element is complete in itself, yet it integrates
perfectly to look as though it is a part of the main
structure.
● The corners of the platform are truncated to form
an unequal octagon.
● Self-replicating symmetry and geometry of
architectural elements are the ruling principles in
the design of Taj.

26
Families of Mughal Architecture Style

27
Families of Gothic Architecture

28
Architectural Styles - Benefits
● Explains the nature of components used
● Explains the topology
● way the system (e.g., building) is structured
● Help to build a family of systems
➢Let us learn about Software Architecture Styles

29
Some Software Architectural Styles
● Layer
● Pipe-and-Filter
● Publish-Subscribe
● Implicit-Invocation
● Styles for Net-Centric Systems
● Client-Server
● Peer-to-Peer

30
Layered Style
● The system is organized as a collection of layers
based on abstraction levels
● Typically, Components of the lowest-level layer
interacts with the underlying OS or Hardware
● Topology: A Layer uses services offered by its
adjacent low-level layer (via API)
● (Static) Control-flow is from the top layer to the
bottom layer
● At run-time, due to callbacks the control can flow
from the bottom layer to the top layer

31
Layered Style - Benefits
● Enables incremental testing from the bottom to
top layer
● Plug-out and Plug-in of a layer with a new layer
conforming to the same API
● Helpful in producing variants of a product
● Helps to distribute the work to different teams
● Often different teams work on different layers

32
Layered Style - Liabilities
● It is hard to decompose the system into different-
levels of abstraction
● What to abstract and what-not-to abstract requires
experience and business knowledge
● Also, defining API’s for each layer is challenging
● Especially hiding implementation details at the interface
level
● (Some-cases) Performance problems due to
indirections
● Implementation might skip layers
● Duplicate or cloned code to escape layer-usage rules
● Exceptions from low-level layers must also be
abstracted

33
Pipe-and-Filter Style
● Famous in Unix environment
● find . –name “*.c” | xargs cat | wc –l
● The above instruction count the total number of
lines in all c files
● find command list the files with .c extension
● cat command concatenates all files (using xargs)
● wc –l counts the number of lines
● Pipes (|) facilitate the co-ordination of filters (i.e.,
commands)
● Topology: Upward filter writes to a pipe and
downward filter reads from the pipe

35
Pipe-and-Filter Style - Benefits
● Filters are not directly coupled to each other
● Filters can be composed with different filters to
produce new configurations
● Helps in producing system variants
● Filters can be tested independently
● Filters can be executed concurrently

36
Pipe-and-Filter Style – Liabilities
● It is hard to share data between non-adjacent
filters
● Error handling is very difficult
● If one intermediate filter fails then other filters
might get wrong-data
● Not easy to propagate errors upwards
● System could be in trouble if filters disagree on the
interaction protocol

37
Publish-Subscribe Arch Style
● Components don’t interact directly
● Components publish messages to a connector
(e.g. a message bus)
● Components subscribe to messages of interest to
the connector
● The connector delivers corresponding messages
to components
● Components often run asynchronously

Publish-Subscribe
Inter-task Message Router (SW Bus)
Transponders
Commands
Real-time Telemetry
(UDP)
Comm Cards
File downlink
(CFDP)
Summit
Chip
Mass
Storage
System
CFDP File
Transfer
File
Manager
Local
Storage
Data
Storage
Event
Services
Executive
Services
Time
Services
1553 Bus
Support
Software
Bus
Command
Ingest
Telemetry
Output
Table
Services
EDA
CMemor
yScrubber
Self
Test
Memor
yDwel
l
Instrument
Manager
Checksum
Memor
yManager
GN&C
Applications
(4)
Mission Apps
cFE core App
CFS Applications
Stored
Commanding
Software
Scheduler
Health
&Safety
Manager
House-
keeping
Limit
Checker

39
Publish-Subscribe - Benefits
● Components are not coupled to each other
● New components can be added/removed at run-
time
● Components can also dynamically unsubscribe to
subscribed messages
● New variants of the system can be produced with
different configurations of components
● The connector takes care of delivering messages
to components

40
Publish-Subscribe - Liabilities
● There is overhead due to the connector’s routing
algorithm
● Actual topology is known only at run-time
● Hard to analyze the implemented system because
the control and data-flow information are not
easy to track
● The correctness of the connector is very crucial
● If the message bus is not reliable then messages
might be delivered to wrong subscribers

41
Implicit Invocation Style
● Components call other components implicitly
● Components register their interest to certain
events to other components
● When events happen all interested components
(i.e., event listeners) get invoked implicitly
● This style is commonly found in UI
● For example, please call me “if mouse click event
happens”

42
Implicit Invocation Style - Benefits
● Components don’t know the identify of
components they interact
● A component can be composed with a different
component

43
Implicit Invocation Style - Liabilities
● System structure is often not intuitive
● Static analysis of the source code to extract the
architecture is very hard due to indirections
● The model is event driven. One event is triggered
by the occurrence of another event
● Proving/testing correctness of the system can be
hard

44
Arch Styles for Net-Centric systems
● Components of a distributed system often run in
different computers
● Components communicate through connectors:
● Remote procedure calls (as in RMI)
● Brokers (as in CORBA)
● Sockets (TCP/UDP)

45
Client-Server Arch. Style
● Two types of components: Client, Server
● Client request the server for its service
● Server give response to the client
● Client and Server can run in different machines
asynchronously
● Connectors (e.g., Sockets) help connecting clients
to servers

46
Client-Server Arch Style …
SAM DsDm
SDIF
MOC Client
OAM c s
c
s
s
s
s
s
SVE
c
c
c
c
c c
s s
c
c
s
SNI
F
c
c
c
c
c
c
NCCD
S
s
s
s
s
s
s
DASs
c
s
s s s s s s
c
Client-side
Socket
s
Server-side Socket

47
Client-Server Arch. Style - Benefits
● Intuitive structure based on request/response
paradigm
● Clear separation of responsibilities among the
client and server
● Many clients can use a server
● Client and server can run concurrently

48
Client-Server Arch. Style - Liabilities
● Server must handle heavy traffic (if applicable)
● Also Load balancing is needed
● Additional complexity due to:
● Thread creation/termination per connection , or
● Thread pool management, or
● Managing queue of requests from clients
● Must be prepared to handle network failures

49
Composing Styles
● Often large systems are made of many different
styles
● For example:
● the high-level structure could be a layer, and
● components within a layer could follow
publish/subscribe architecture style
● two adjacent layers could interact through a pipe
● Styles can be safely composed as long as they
don’t violate style constraints

50
Composing Styles …
● In practice, often performance is the main criteria
for
● selecting the styles
● composing the styles
● Architects typically perform a trade-off analysis
or based on their experience select and compose
styles
● Select and compose styles based on quality
properties (e.g., Usability, Performance) for your
system

53
● Types of Styles

54
Software Architecture Description
● There is no common consensus on what an architecture
description (AD) should contain
● Typically, AD contains system-level design decisions that
are of concern to the whole system and everyone should
be aware of
● AD should contain, for example:
● High-level components,
● Connectors that connect the components
● Protocol of interactions among components
● Error handling strategy – how exceptions are handled?
● Concurrency model – how multiple clients are handled by
a single server?
● Data or information flow – how data/information is
passed between components?

55
Describing Software Architecture
using Views
● How to best describe Software Architecture
is a topic of on-going R&D
● In literature, views are used to describe
● Each view address one concern, for example:
● Structural view shows the decomposition of
system
● Behavioral view shows how components
interact at run-time
● Deployment view shows how components
are assigned to hardware elements

56
Viewpoints and Views (IEEE 1471
Standard Defn)
● A view is a representation of all or part of
an architecture, from the perspective of
one or more concerns which are held by
one or more of its stakeholders.
● A viewpoint is a collection of patterns,
templates and conventions for constructing
one type of view.

Viewpoints, Views, and Architectural
Description
Viewpoint View
Architectural
Description
defines 0..n
1 .. n
•An architectural description is a collection of one or more views.
•A viewpoint is used to define (the structure and content of) zero
or more views.
•The structure and content of a particular view is defined by
exactly one viewpoint.

58
Some Approaches for Describing
●Kruchten “4 + 1” View
●Siemens View
●SEI View
●Philips View
●Rozanski and Woods View

59
Kruchten 4 + 1 View
Viewpoint Definition
Logical The logical representation of the system’s functional
structure.
Process The concurrency and synchronization aspects of the
architecture.
Development The design-time software structure, identifying modules,
and subsystems.
Physical The identification of the nodes that the system’s software
will be executed on and the mapping of other architectural
elements to these nodes.
Scenarios
(+1)
A set of functional usage scenarios to illustrate how the
views work together.
As a driver to discover architectural elements during the
architectural design.

60
Siemens View
Conceptual The conceptual functional structure of the system that
defines a set of conceptual components linked by a set of
connectors.
Module The concrete structure of the subsystems and modules that
will be realized in the system, the interfaces exposed by the
modules, the intermodule dependencies, and any layering
constraints in the structure.
Execution The runtime structure of the system in terms of processes,
threads, interprocess communication elements, and so on
along with a mapping of modules to runtime elements.
Code The design-time layout of the system as source code and the
intermediate and delivered binary elements created from it.

61
SEI View
Viewtype Definition
Component
and Connector
It is concerned with the sytem’s runtime functional
elements, their behaviors, and their interactions.
The following styles defined for this viewtype all relate
to commonly occurring runtime system organizations:
• Pipe-and-Filter
• Shared-Data
• Publish-Subscribe
• Client-Server
• Peer-to-Peer
• Communicating-Processes

62
SEI View…
Viewtype Definition
Module The module viewtype is concerned with the how the software
comprising the system is structured as a set of
implementation (code) units.
The following styles are defined for the Module viewtype:
• Uses: for capturing inter-module usage dependencies
• Generalization: for capturing commonality and variation
(inheritance) relationships between modules
• Decomposition: for specifying how modules are composed
from simpler elements
• Layered: for specifying how modules are arranged in layers
according to their level of abstraction

63
SEI View …
Viewtype Definition
Allocation It is concerned with how relationships between the different
parts of the system and different aspects of their
environment are captured.
The following styles are defined for this viewtype:
• Deployment: for specifying how software elements are
mapped to elements of the deployment environment
• Implementation: for specifying how software modules are
mapped to the development environment (such as their
location in a codebase)
• Work assignment: for mapping software modules to those
responsible for creating, testing, and deploying them.

64
Philips View (BAPO)
Viewpoint Primary Focus
Business Goals of the business
Architecture Decisions based on Business Goals
Process Policies and Planning. E.g., change management, Version
Control, Project plans
Organization Structure of development teams, and reporting hierarchy.

Rozanksi and Woods View
Functional Viewpoint
Information Viewpoint
Concurrency Viewpoint
Development Viewpoint
Deployment Viewpoint
Operational Viewpoint
The Functional, Information, and Concurrency
viewpoints characterize the fundamental
organization of the system.
The Development viewpoint exists to support
the system’s construction.
The Deployment and Operational viewpoints
characterize the system once in its
live environment.

67
Rozanksi and Woods View …
Information Describes the way that the architecture
stores, manipulates, manages, and
distributes information.
The aim of this viewpoint is to identify
structure, ownership, latency, references,
and data migration.
Operational Describes how the system will be operated,
administered, and supported when it is
running in its production environment.
Installing, managing, and operating the
system are the concerns of interest to this
viewpoint.

View Relationships
Deployment
View
Operational
View
Software
Structure
Development
View
Functional
View
Information
View
Concurrency
View
defines operation of
defines
deployment of
defines implementation
constraints for

69
Functional View (some examples)
● Cranefoot is a tool for visualizing Pedigrees
(family history tree) used in genetic studies

70
Dependency Structure of Cranefoot

71
Mapping Structural Elements to Files

72
Execution View of Cranefoot
Cranefoot runs on a single thread in a single machine
– thus no separate process view was documented

73
Consistency across Views
● Views helped us with the partitioning the
representation of our architecture
● But, the challenge is how to ensure consistency
between them
● How to ensure that the structures, features, and
elements that appear in one view are compatible
and in alignment with the content of other views?

74
Consistency across Views …
● Consistency is a vital characteristics of our Architecture
Description
● Without consistency, the system:
● will not work properly
● will not achieve its design goals
● may even be impossible to build
● Arguably, no tools automate consistency between views
● Ensuring consistency comes down to the skill,
thoroughness, and diligence of the architect
● Checklists could help during reviews (coming next)

75
Functional and Concurrency View
Consistency – Sample Checklist
● Goal: To ensure that the functional elements are
all mapped to a task that will allow them to
execute and the inter-element interactions are
supported by the IPC mechanisms if required
➢Is every functional element in the Functional
view mapped to a concurrent element (a process
or thread) responsible for its execution in the
Concurrency view?

76
Functional and Deployment View
● Goal: To ensure that each of the functional
elements is correctly mapped to its deployment
environment.
➢Has each functional element been mapped to a
processing node to allow it to be executed?
➢Where functional elements are hosted on
different nodes, do the network models allow the
required element interactions to occur?

77
Functional and Deployment View
Consistency – Sample Checklist …
➢Are functional elements that need to interact
extensively hosted as close together as possible?
➢Are the specified network connections sufficient
for the needs of the interelement interactions that
will be carried over them (in terms of capacity,
reliability, security, and so on)?
➢Is the hardware specified in the Deployment view
the most efficient solution for hosting the
specified functional elements?

78
Functional and Operational View
● Goal: To ensure that each of the specified
functional elements can be installed, used,
operated, and supported.
➢Does the Operational view make it clear how
every functional element will be installed?
➢Does the Operational view explain how each
functional element will be monitored and
controlled in the production environment?

79
Information and Concurrency view
Consistency
● Goal: To ensure that the concurrency structure of the
system does not cause data access problems and that
the proposed information structure is compatible
with the concurrency structure.
➢Does the concurrency design imply concurrent access
to any of the system’s data elements?
● If so, have the data elements been protected from
concurrent access problems?
➢If functional elements that share data elements are
packaged into different OS processes, has a suitable
inter-process data-sharing mechanism been defined?

80
Information and Deployment View
Consistency
● Goal: To ensure that the proposed deployment
environment provides the resources required to support
the defined information structure.
➢ Does the Deployment view include enough storage to
support the information specified by the Information
view?
➢ If large volumes of information need to be moved, is
sufficient bandwidth available so that this can be achieved
without performance issues?
➢ Does the Deployment view reflect the requirements for
backup and recovery as addressed by the Info. View?

81
Concurrency and Development view
Consistency
● Goal: To ensure that the concurrency structure specified in the
concurrency view can be built and tested in the development
environment specified by the Development view.
➢ If the concurrency structure is complex, are sufficient design
patterns specified in the Development view to guide its
implementation?
➢ Does the code structure defined in the Development view
support the packaging of the system’s functional elements into
the operating system processes specified by the Concurrency
view?
➢ Does the test approach defined in the Development view
support the concurrency structure specified in the Concurrency
view?

82
Architectural Perspectives
● A viewpoint advises on how to create and
describe a particular type of architectural
structure (e.g., Concurrency, Information)
● A perspective provides advice relating to the
cross view concerns of a particular quality
property (e.g., Security, Performance)
● Architectural perspectives provide a framework
for structuring knowledge about how to design
systems to achieve quality

83
Examples of Applying Perspectives
to Views
Security Performance Availability Evolution
OperationalConcurrencyInformationFunctional
PERSPECTIVES
VIEWS
Information
Security
(Access control)
Functional
Evolution
(extension points,
flexible interfaces)
Concurrency
Performance
(shared resources,
blocking, queuing)

84
Structure of a Perspective
● the Concerns that the perspective is addressing
● the Applicability of the perspective to the different
possible architectural views
● a set of possible Activities for achieving the
quality property
● a set of proven Architectural Tactics or strategies
● a list of common Problems and Pitfalls
● a Checklist to ensure nothing has been forgotten
➢Let us see an example of Security perspective

85
Concerns of Security Persp.
● Policy (the actions that difference principals can
perform on sensitive resources)
● Threats (the security threats that the system faces)
● Governance (the mechanisms for implementing
the policy securely, including authentication,
authorization, confidentiality, integrity and
accountability)
● Availability (ensuring that attackers cannot
prevent access to a system)
● Detection and Recovery from Breach (allowing
recovery when security fails)

86
Views applicable to Security
● Deployment view
● Adding security related hardware and software
● Development view
● Setting system wide security related standards
● Functional view
● Partitioning the system differently to allow
controlled access to sensitive parts

87
Activities for Security
● Identification of sensitive resources
● Definition of a security policy
● Creation of a threat model
● Design of a security implementation
● Assessment of security risk

88
Architectural tactics for Security
● Application of recognized security principles:
● Example: least privilege, auditing
● Principal identification mechanisms
● Access control mechanisms
● Information protection mechanisms
● Provision of security administration
● Use of 3rd party security technology

89
Problems and Pitfalls of Security
● Complex security policies
● Use of unproven security technology
● Not designing for secure failure conditions
● Not providing effective admin facilities
● Leaving security as an afterthought
● Use of ad-hoc technology to enforce security
● Driving the process by technology choice rather
than security threats

90
Checklist for Security
● Is there a clear policy that defines which
principals are allowed to perform which
operations on which resources?
● Is the security policy as simple as possible?
● Have security requirements been reviewed with
external experts?
● Has each threat identified in the threat model
been addressed to the extent necessary?
● …

91
Core set of Perspectives
Perspective Purpose
Security Ensure who can perform what actions on resources
Performance
and Scalability
Ensure the system’s ability to predictably execute within
its mandated performance req. and to handle increasing
processing volumes
Availability
and Resilience
Ensure the system’s ability to be fully or partly
operational. Effectively handle failures.
Evolution Ensure the system’s flexibility to change

92
Other Perspectives
Perspective Purpose
Internationalization Ensure the system’s independence from any
particular language, country or cultural group.
Accessibility Ensure the ability of the system to be used by people
with disabilities.
Usability Ensure that people who interact with the system can
easily work effectively.
Regulation Ensure the ability of the system to comply with local
and international laws, regulations, policies, etc.,
Development
Resource
Ensure that the system can be designed, built, and
operated within constraints around people, budget.
Licensing Ensure that the system has appropriate licensing
mechanism in place according to marketing plans.

Using Perspectives
Analyse and
Understand Key
requirements
Create a Candidate
Architecture
Apply Perspectives Modify Architecture
Perform “Formal”
Architectural
Evaluation
(e.g., Scenario-based
methods ATAM,
SAAM)
[Unacceptable
properties]
[acceptable properties]

94
● Types of Styles

96
Software Product Line - Examples

98
SPL Definition
● A software product line is a set of software-intensive
systems sharing a common, managed set of features
that satisfy the specific needs of a particular market
segment or mission and that are developed from a
common set of core assets in a prescribed way.
● SPL
● take economic advantage of commonality
● bound variation
● PRODUCT LINES = STRATEGIC REUSE

100
Motivation for SPL
● Achieve large scale productivity gains
● Improve time to market
● Enable mass customization
● Get control of diverse product configurations
● Improve product quality
● Increase predictability of cost, schedule, and
quality
➢The product line architecture is central to success

101
Architecting for SPL
● Two of the fundamental needs in defining an
architecture for a product line are
● to be able to generalize or abstract from the
individual products to capture the important
aspects of the product line
● to be able to instantiate an individual product
architecture from the product line architecture
● Having a product line implies having a generic
architecture from which the individual product
architectures can be derived in some manner

102
Architecting for SPL …
● Use Architectural styles to handle variation
● For example, a Pipe-and-Filter style can be used to
produce different product instances
● Select Filters of interest and produce new config.
● Use a Layered architectural style to “hide” variations
in OS and Hardware
● Important to define Abstract APIs with alternative
implementations
● Use a Publish-Subscribe style for:
● Substituting various publishers and subscribers
● Plug-in new publishers and subscribers
● Run-time adaptation

Architecture-level Variability
Inter-task Message Router (SW Bus)
Transponders
Commands
Real-time Telemetry
(UDP)
Comm Cards
File downlink
(CFDP)
Summit
Chip
Mass
Storage
System
CFDP File
Transfer
File
Manager
Local
Storage
Data
Storage
Event
Services
Executive
Services
Time
Services
1553 Bus
Support
Software
Bus
Command
Ingest
Telemetry
Output
Table
Services
EDA
CMemor
yScrubber
Self
Test
Memor
yDwel
l
Instrument
Manager
Checksum
Memor
yManager
GN&C
Applications
(4)
Mission Apps
cFE core App
CFS Applications
Stored
Commanding
Software
Scheduler
Health
&Safety
Manager
House-
keeping
Limit
Checker

104
Variation within Components
● Configurable component (e.g., Properties, #ifdef)
● Variation is supported within the component
● Select appropriate values for config. parameters
● Enable/disable parts of code using config. param.
● Extensible component (e.g., Inheritance)
● Consists of an extensible base
● Variable parts are separate sub-components
● Generic and specific functionality are separated
● Abstract component (e.g., Java Interface)
● Only the interface is provided
● Different products must provide own implementation
● Suitable when implementation differs a lot

105
Example: Variation within OS
Abstraction Layer
● Software Bus requires a communication mechanism
internally
● The OS abstraction layer offers two implementations:
● Socket, or
● Queue
● At preprocessing time this variation point must be
resolved
● Software Bus uses the same API for both
communication mechanisms

Variation within OS Abstraction
Layer…
/****************************************************************************************
MESSAGE QUEUE API
****************************************************************************************/
#ifdef OSAL_SOCKET_QUEUE
int32 OS_QueueCreate (uint32 *queue_id, const char *queue_name, uint32 queue_depth
uint32 data_size, uint32 flags) {
…
socket(AF_INET, SOCK_DGRAM, 0); …
}
#else
/* ---------------------- POSIX MESSAGE QUEUE IMPLEMENTATION -------------------- */
int32 OS_QueueCreate (uint32 *queue_id, const char *queue_name, uint32 queue_depth
uint32 data_size, uint32 flags) {
….
mq_open(name, O_CREAT | O_RDWR, …);
}

107
References/Further reading
1. P. Kruchten. Architectural Blueprints – The “4+1” View Model of the Software Architecture. IEEE Software
12(6), Nov 1995, pp. 42-50.
1. D. Ganesan. The Software Architecture of Cranefoot. - An independent analysis by Fraunhofer,
Maryland, USA, 2009.
1. D. Ganesan, M. Lindvall, C. Ackermann, D. McComas, and M. Bartholomew. Verifying Architectural
Design Rules of the Flight Software Product Line. IEEE Proceedings of Software Product Line Conference,
2009.
1. N. Rozanski, E. Woods. Software Systems Architecture. Addison-Wesley.
1. R. N. Taylor, N. Medvidovic, E. M. Dashofy. Software Architecture. Foundations, Theory, and Practice.
Addison-Wesley.
1. M. Shaw, D. Garlan. Software Architecture – Perspectives on an Emerging Discipline. Prentice Hall, 1996.
1. F. Buschmann et al. Pattern-Oriented Software Architecture. Addison-Wesley, 2001.
1. J. Mehdi, A. Ran, and F. van der Linden. Software Architecture for Product Families: Principles and
Practice. Addison-Wesley, 2000.

108
References/ Further Reading
9. C. Hofmeister et al. Generalizing a Model of
Software Architecture Design from Five Industrial
Approaches. IEEE Proceedings of Working
Conference on Software Architecture, 2005.

Software Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Architecture

Similar to Software Architecture (20)

More from Dharmalingam Ganesan

More from Dharmalingam Ganesan (20)

Recently uploaded

Recently uploaded (20)

Software Architecture