Alternative: allow changes in either architecture or implementation
Matching assumptions
Requires round-trip mappings and maintenance strategies
Easy to construct intra- and inter-process P&F applications
Can be assisted (to a point) with automated tools
Concurrency can be an issue; many calls are blocking
Efficiency
Architecture Implementation Frameworks
Ideal approach: develop architecture based on a known style, select
Users have fine-grained control over, e.g., buffering
technologies that provide implementation support for each architectural
Very high efficiency mechanisms (memory mapped I/O, channels) not
element
available (but are in java.nio)
This is rarely easy or trivial
Recall the C2 Style
Few programming languages have explicit support for architecture-level
Layered style
constructs
with event-based
Support infrastructure (libraries, operating systems, etc.) also has its own
communication
sets of concepts, metaphors, and rules
over two-way
To mitigate these mismatches, we leverage an architecture implementation
broadcast
framework
buses
Definition: An architecture implementation framework is a piece of software
Strict rules on
that acts as a bridge between a particular architectural style and a set of
concurrency,
implementation technologies. It provides key elements of the architectural
dependencies,
style in code, in a way that assists developers in implementing systems that
and so on
conform to the prescriptions and constraints of the style.
Many frameworks developed for
different languages; focus on two
Canonical Example
The standard I/O (‘stdio’) framework in UNIX and other operating systems
alternative Java frameworks here
Perhaps the most prevalent framework in use today
Framework #1: Lightweight C2 Framework
Style supported: pipe-and-filter
16 classes, 3000 lines of code
Implementation technologies supported: concurrent process-oriented
Components & connectors extend abstract base classes
operating system, (generally) non-concurrent language like C
Concurrency, queuing handled at individual comp/conn level
Messages are request or notification objects
More on Frameworks
Frameworks are meant to assist developers in following a style
Evaluating Lightweight C2 Framework
But generally do not constrain developers from violating a style if they
Platform support
really want to
Available with all Java implementations on many platforms
Developing applications in a target style does not require a framework
Fidelity
But if you follow good software engineering practices, you’ll probably end
Assists developers with many aspects of C2 but does not enforce these
up developing one anyway
constraints
Frameworks are generally considered as underlying infrastructure or substrates
Leaves threading and queuing policies up to individual elements
from an architectural perspective
Matching assumptions
You won’t usually see the framework show up in an architectural model, e.g.,
Comp/conn main classes must inherit from distinguished base classes
as a component
All messages must be in dictionary form
Efficiency
Same Style, Different Frameworks
For a given style, there is no one perfect architecture framework
Lightweight framework; efficiency may depend on threading and queuing
Different target implementation technologies induce different frameworks
policy implemented by individual elements
stdio vs. iostream vs. java.io
Framework #2: Flexible C2 Framework
Even in the same (style/target technology) groupings, different frameworks
73 classes, 8500 lines of code
exist due to different qualitative properties of frameworks
Uses interfaces rather than base classes
java.io vs. java.nio
Threading policy for application is pluggable
Various C2-style frameworks in Java
Message queuing policy is also pluggable
Evaluating Frameworks
Evaluating Flexible C2 Framework
Can draw out some of the qualitative properties just mentioned
Platform support
Platform support
Available with all Java implementations on many platforms
Target language, operating system, other technologies
Fidelity
Fidelity
Assists developers with many aspects of C2 but does not enforce these
How much style-specific support is provided by the framework?
constraints
Many frameworks are more general than one target style or focus on a
Provides several alternative application-wide threading and queuing policies
subset of the style rules
Matching assumptions
How much enforcement is provided?
Comp/conn main classes must implement distinguished interfaces
Matching Assumptions
Messages can be any serializable object
Styles impose constraints on the target architecture/application
Efficiency
Frameworks can induce constraints as well
User can easily swap out and tune threading and queuing policies without
E.g., startup order, communication patterns …
disturbing remainder of application code
To what extent does the framework make too many (or too few) assumptions?Implementing Pipe and Filter Lunar Lander
Efficiency
Framework: java.io
Frameworks pervade target applications and can potentially get involved in
Implementing as a multi-process application
any interaction
Each component (filter) will be a separate OS process
To what extent does the framework limit its slowdown and provide help to
Operating system will provide the pipe connectors
improve efficiency if possible (consider buffering in stdio)?
Going to use just the standard input and output streams
Other quality considerations
Ignoring standard error
Nearly every other software quality can affect framework evaluation and
Ignoring good error handling practices and corner cases for simplicity
selection
A note on I/O:
Size
Some messages sent from components are intended for output to the console
Cost
(to be read by the user)
Ease of use
These messages must be passed all the way through the pipeline and
Reliability
output at the end
Robustness
We will preface these with a ‘#’
Availability of source code
Some messages are control messages meant to communicate state to a
Portability
component down the pipeline
Long-term maintainability and support
These messages are intercepted by a component and processed
We will preface these with a ‘%’
Middleware and Component Models
This may all sound similar to various kinds of middleware/component
First: GetBurnRate component
frameworks
Loops; on each loop:
CORBA, COM/DCOM, JavaBeans, .NET, Java Message Service (JMS), etc.
Prompt user for new burn rate
They are closely related
Read burn rate from the user on standard input
Both provide developers with services not available in the underlying
Send burn rate to next component
OS/language
Quit if burn rate read < 0
CORBA provides well-defined interfaces, portability, remote procedure
Second: CalcNewValues Component
call…
Read burn rate from standard input
JavaBeans provides a standardized packaging framework (the bean) with
Calculate new game state including game-over
new kinds of introspection and binding
Send new game state to next component
Indeed, architecture implementation frameworks are forms of middleware
New game state is not sent in a formatted string; that’s the display
There’s a subtle difference in how they emerge and develop
component’s job
Middleware generally evolves based on a set of services that the developers
Third: DisplayValues component
want to have available
Read value updates from standard input
E.g., CORBA: Support for language heterogeneity, network transparency,
Format them for human reading and send them to standard output
portability
Instantiating the application
Frameworks generally evolve based on a particular architectural style that
java GetBurnRate | java CalcNewValues | java DisplayValues
developers want to use
Takeaways
Why is this important?
java.io provides a number of useful facilities
By focusing on services, middleware developers often make other decisions
Stream objects (System.in, System.out)
that substantially impact architecture
Buffering wrappers
E.g., in supporting network transparency and language heterogeneity, CORBA
OS provides some of the facilities
uses RPC
Pipes
But is RPC necessary for these services or is it just an enabling technique?
Concurrency support
In a very real way, middleware induces an architectural style
Note that this version of the application would not work if it operated in
CORBA induces the ‘distributed objects’ style
batch-sequential mode
JMS induces a distributed implicit invocation style
We had other communication mechanisms available, but did not use them to
Understanding these implications is essential for not having major problems
conform to the P&F style
when the tail wags the dog!
We had to develop a new (albeit simple) protocol to get the correct behavior
Resolving Mismatches
Implementing Lunar Lander in C2
A style is chosen first, but the middleware selected for implementation does
Framework: Lightweight C2 framework
not support (or contradicts) that style
Each component has its own thread of control
A middleware is chosen first (or independently) and has undue influence on
Components receive requests or notifications and respond with new ones
the architectural style used
Message routing follows C2 rules
Strategies
This is a real-time, clock-driven version of Lunar Lander
Change or adapt the style
First: Clock component
Change the middleware selected
Sends out a ‘tick’ notification periodically
Develop glue code
Does not respond to any messages
Leverage parts of the middleware
Second: GameState Component
and ignore others
Receives request to update internal state
Hide the middleware in components/connectors
Emits notifications of new game state on request or when state changes
Does NOT compute new state
Building a New Framework
Occasionally, you need a new framework
Just a data store
The architectural style in use is novel
Third: GameLogic Component
The architectural style is not novel but it is being implemented on a platform
Receives notifications of game state changes
for which no framework exists
Receives clock ticks
The architectural style is not novel and frameworks exist for the target
On clock tick notification, calculates new state and sends request up
platform, but the existing frameworks are inadequate
Fourth: GUI Component
Good framework development is extremely difficult
Reads burn rates from user and sends them up as requests
Frameworks pervade nearly every aspect of your system
Receives notifications of game state changes and formats them to console
Making changes to frameworks often means changing the entire system
Lastly, main program
A task for experienced developers/architects
Instantiates and connects all elements of the system
New Framework Guidelines
Takeaways
Understand the target style first
Here, the C2 framework provides most all of the scaffolding we need
Enumerate all the rules and constraints in concrete terms
Message routing and buffering
Provide example design patterns and corner cases
How to format a message
Limit the framework to the rules and constraints of the style
Threading for components
Do not let a particular target application’s needs creep into the framework
Startup and instantiation
“Rule of three” for applications
We provide the component behavior
Choose the framework scope
Including a couple new threads of our own
A framework does not necessarily have to implement all possible stylistic
We still must work to obey the style guidelines
advantages (e.g., dynamism or distribution)
Not everything is optimal: state is duplicated in Game Logic, for example
Avoid over-engineering
Limitations of the Distributed Systems Viewpoint
Don’t add capabilities simply because they are clever or “cool”, especially if
The network is reliable
known target applications won’t use them
Latency is zero
Simulation-Based Analysis in a Nutshell
Analysis Goals – any
These often add complexity and reduce performance
Bandwidth is infinite
Analysis Scope – any
Limit overhead for application developers
The network is secure
Analysis Concern –behavioral, interaction, and non-functional properties
Every framework induces some overhead (classes must inherit from
Topology doesn’t change
Architectural Models – formal
framework base classes, communication mechanisms limited)
There is one administrator
Analysis Types – dynamic and scenario-based
Try to put as little overhead as possible on framework users
Transport cost is zero
Automation Level – fully automated; model mapping may be manual
Develop strategies and patterns for legacy systems and components
The network is homogeneous
Stakeholders – any
Almost every large application will need to include elements that were not WWW’s Architecture
built to work with a target framework
The application is distributed (actually, decentralized) hypermedia
Develop strategies for incorporating and wrapping these
Architecture of the Web is wholly separate from the code
Example – XTEAM
eXtensible Tool-chain for Evaluation of Architectural Models
There is no single piece of code that implements the architecture.
Concurrency
Targeted at mobile and resource-constrained systems
Concurrency is one of the most difficult concerns to address in implementation
There are multiple pieces of code that implement the various components of
Combines two underlying ADLs
Introduction of subtle bugs: deadlock, race conditions…
the architecture.
xADL and FSP
Another topic on which there are entire books written
E.g., different Web browsers
Maps architectural description to adevs
Concurrency is often an architecture-level concern
Stylistic constraints of the Web’s architectural style are not apparent in the
An OTS event simulation engine
Decisions can be made at the architectural level
code
Implements different analyses via ADL extensions and a model interpreter
Done carefully, much concurrency management can be embedded into the
The effects of the constraints are evident in the Web
Latency, memory utilization, reliability, energy consumption
architecture framework
One of the world’s most successful applications is only understood adequately
Consider our earlier example, or how pipe-and-filter architectures are made
from an architectural vantage point.
concurrent without direct user involvement
Closing Remarks
REST Principles
Architectural analysis is neither easy nor cheap
[RP1] The key abstraction of information is a resource, named by an URL.
Generative Technologies
The benefits typically far outweigh the drawbacks
With a sufficiently detailed architectural model, various implementation
Any information that can be named can be a resource.
Early information about the system’s key characteristics is indispensable
artifacts can be generated
[RP2] The representation of a resource is a sequence of bytes, plus
Multiple analysis techniques often should be used in concert
Entire system implementations
representation metadata to describe those bytes. The particular form of the
“How much analysis?”
Requires extremely detailed models including behavioral specifications
representation can be negotiated between REST components.
This is the key facet of an architect’s job
More feasible in domain-specific contexts
[RP3] All interactions are context-free: each interaction contains all of the
Too many will expend resources unnecessarily
Skeletons or interfaces
information necessary to understand the request, independent of any requests
Too few will carry the risk of propagating defects into the final system
With detailed structure and interface specifications
that may have preceded it.
Wrong analyses will have both drawbacks
Compositions (e.g., glue code)
[RP4] Components perform only a small set of well-defined methods on a
With sufficient data about bindings between two elements
resource producing a representation to capture the current or intended state of
The Mapping Problem
Implementation is the one phase of software engineering that is not optional
that resource and transfer that representation between components. These
Maintaining Consistency
Architecture-based development provides a unique twist on the classic problem Strategies for maintaining one-way or round-trip mappings
methods are global to the specific architectural instantiation of REST; for
It becomes, in large measure, a mapping activity
Create and maintain traceability links from architectural implementation
instance, all resources exposed via HTTP are expected to support each
Maintaining mapping means ensuring that our architectural intent is reflected
elements
operation identically.
in our constructed systems
Explicit links in a database, in architectural models, in code comments can
[RP5] Idempotent operations and representation metadata are encouraged in
all help with consistency checking
support of caching and representation reuse.
Common Element Mapping
Components and Connectors
Make the architectural model part of the implementation
[RP6] The presence of intermediaries is promoted. Filtering or redirection
Partitions of application computation and communication functionality
When the model changes, the implementation adapts automatically
intermediaries may also use both the metadata and the representations within
Modules, packages, libraries, classes, explicit components/connectors in
May involve “internal generation”
requests or responses to augment, restrict, or modify requests and responses in
middleware
Generate some or all of the implementation from the architecture
a manner that is transparent to both the user agent and the origin server.
Interfaces
Recall Pipe-and-Filter
An Instance of REST — Data Elements
Programming-language level interfaces (e.g., APIs/function or method
Components (‘filters’) organized linearly, communicate through characterResource
signatures) are common
stream ‘pipes,’ which are the connectors
Key information abstraction
State machines or protocols are harder to map
Filters may run concurrently on partial data
Resource ID
Configurations
In general, all input comes in through the left and all output exits from the right Representation
Interconnections, references, or dependencies between functional partitions Framework #1: stdio
Data plus metadata
May be implicit in the implementation
Standard I/O framework used in C programming language
Representation metadata
May be externally specified through a MIL and enabled through middleware
Each process is a filter
Resource metadata
May involve use of reflection
Reads input from standard input (aka ‘stdin’)
Control data
Design rationale
Writes output to standard output (aka ‘stdout’)
e.g., specifies action as result of message
Often does not appear directly in implementation
Also a third, unbuffered output stream called standard error (‘stderr’) not REST — Connectors
Retained in comments and other documentation
considered here
Modern Web Examples
Dynamic Properties (e.g., behavior):
Low and high level operations
client - libwww, libwww-perl
Usually translate to algorithms of some sort
getchar(…), putchar(…) move one character at a time
server - libwww, Apache API, NSAPI
Mapping strategy depends on how the behaviors are specified and what
printf(…) and scanf(…) move and format entire strings
cache - browser cache, Akamai cache network
translations are available
Different implementations may vary in details (buffering strategy, etc.)
resolver - bind (DNS lookup library)
Some behavioral specifications are more useful for generating analyses or
tunnel - SOCKS, SSL after HTTP CONNECT
Evaluating stdio
testing plans
Platform support
REST — Components
Non-Functional Properties
Available with most, if not all, implementations of C programming language
User agent
Extremely difficult to do since non-functional properties are abstract and
Operates somewhat differently on OSes with no concurrency (e.g., MS-DOS)
e.g., browser
implementations are concrete
Fidelity
Origin server
Achieved through a combination of human-centric strategies like inspections,
Good support for developing P&F applications, but no restriction that apps
e.g., Apache Server, Microsoft IIS
reviews, focus groups, user studies, beta testing, and so on
have to use this style
Proxy
Matching assumptions
Selected by client
One-Way vs. Round Trip Mapping
Architectures inevitably change after implementation begins
Filters are processes and pipes are implicit. In-process P&F applications
Gateway
For maintenance purposes
might require modifications
Squid, CGI, Reverse proxy
Because of time pressures
Efficiency
Controlled by server
Because of new information
Whether filters make maximal use of concurrency is partially up to filter
Derivation of REST Key choices in this derivation include:
Implementations can be a source of new information
implementations and partially up to the OS
Layered Separation (a theme in the middle portion of diagram) is used to
We learn more about the feasibility of our designs when we implement
increase efficiencies, enable independent evolution of elements of the system,
Framework #2: java.io
We also learn how to optimize them
Standard I/O framework used in Java language
and provide robustness;
Keeping the two in sync is a difficult technical and managerial problem
Object-oriented
Replication (left side of the diagram) is used to address latency and contention
Places where strong mappings are not present are often the first to diverge
Can be used for in-process or inter-process P&F applications
by allowing the reuse of information;
One-way mappings are easier
All stream classes derive from InputStream or OutputStream
Limited commonality (right side) addresses the competing needs for
Must be able to understand impact on implementation for an architectural
Distinguished objects (System.in and System.out) for writing to process’
universally understood operations with extensibility.
design decision or change
standard streams
-The derivation is driven by the application(!)
Two way mappings require more insight
Additional capabilities (formatting, buffering) provided by creating
REST: Final Thoughts
Must understand how a change in the implementation impacts architecturecomposite streams (e.g., a Formatting-Buffered-InputStream)
REpresentational State Transfer
level design decisions
Style of modern web architecture
Evaluating java.io
One strategy: limit changes
Platform support
Web architecture one of many in style
If all system changes must be done to the architecture first, only one-way
Available with all Java implementations on many platforms
Web diverges from style on occasion
mappings are needed
Platform-specific differences abstracted away
e.g., Cookies, frames
Works very well if many generative technologies in use
Fidelity
Doesn’t explain mashups
Often hard to control in practice; introduces process delays and limits
Good support for developing P&F applications, but no restriction that apps Commercial Internet-Scale Applications
implementer freedom
have to use this style
Akamai
Analysis Technique Categories
Inspection- and review-based
Model-based
Simulation-based
Architectural Inspections and Reviews
Architectural models studied by human stakeholders for specific properties
The stakeholders define analysis objective
Manual techniques
Can be expensive
Useful in the case of informal architectural descriptions
Useful in establishing “soft” system properties
E.g., scalability or adaptability
Able to consider multiple stakeholders’ objectives and multiple architectural
properties
Inspections and Reviews in a Nutshell
Analysis Goals – any
Analysis Scope – any
Analysis Concern – any, but particularly suited for non-functional properties
Architectural Models – any, but must be geared to stakeholder needs and
analysis objectives
Analysis Types – mostly static and scenario-based
Automation Level – manual, human intensive
Stakeholders – any, except perhaps component vendors
Example – ATAM
Stands for architectural trade-off analysis method
Human-centric process for identifying risks early on in software design
Focuses specifically on four quality attributes (NFPs)
Modifiability
Security
Performance
Reliability
Reveals how well an architecture satisfies quality goals and how those goals
trade-off
ATAM Business Drivers
The system’s critical functionality
Any technical, managerial, economic, or political constraints
The project’s business goals and context
The major stakeholders
The principal quality attribute (NFP) goals
ATAM Scenarios
Use-case scenarios
Describe how the system is envisioned by the stakeholders to be used
Growth scenarios
Describe planned and envisioned modifications to the architecture
Exploratory scenarios
Try to establish the limits of architecture’s adaptability with respect to
system’s functionality
operational profiles
underlying execution platforms
Scenarios are prioritized based on importance to stakeholders
ATAM Architecture
Technical constraints
Required hardware platforms, OS, middleware, programming languages, and
OTS functionality
Any other systems with which the system must interact
Architectural approaches that have been used to meet the quality requirements
Sets of architectural design decisions employed to solve a problem
Typically architectural patterns and styles
ATAM Analysis
Key step in ATAM
Objective is to establish relationship between architectural approaches and
quality attributes
For each architectural approach a set of analysis questions are formulated
Targeted at the approach and quality attributes in question
System architects and ATAM evaluation team work together to answer these
questions and identify
Risks  these are distilled into risk themes
Non-Risks
Sensitivity points
Trade-off points
Based on answers, further analysis may be performed
Model-Based Architectural Analysis
Analysis techniques that manipulate architectural description to discover
architectural properties
Tool-driven, hence potentially less costly
Typically useful for establishing “hard” architectural properties only
Unable to capture design intent and rationale
Usually focus on a single architectural aspect
E.g., syntactic correctness, deadlock freedom, adherence to a style
Scalability may be an issue
Techniques typically used in tandem to provide more complete answers
Model-Based Analysis in a Nutshell
Analysis Goals – consistency, compatibility, internal correctness
Analysis Scope – any
Analysis Concern – structural, behavioral, interaction, and possibly nonfunctional properties
Architectural Models – semi-formal and formal
Analysis Types – static
Automation Level – partially and fully automated
Stakeholders – mostly architects and developers
Model-Based Analysis in ADLs
Wright – uses CSP to analyze for deadlocks
Aesop – ensures style-specific constraints
MetaH and UniCon – support schedulability analysis via NFPs such as
component criticality and priority
ADL parsers and compilers – ensure syntactic and semantic correctness
E.g., Rapide’s generation of executable architectural simulations
Architectural constraint enforcement
E.g., Armani or UML’s OCL
Architectural refinement
E.g., SADL and Rapide
ADLs’ Analysis Foci in a Nutshell
Architectural Reliability Analysis
Reliability is the probability that the system will perform its intended
functionality under specified design limits, without failure
A failure is the occurrence of an incorrect output as a result of an input value
that is received, with respect to the specification
An error is a mental mistake made by the designer or programmer
A fault or a defect is the manifestation of that error in the system
An abnormal condition that may cause a reduction in, or loss of, the
capability of a component to perform a required function
A requirements, design, or implementation flaw or deviation from a desired
or intended state
Reliability Metrics
Time to failure
Time to repair
Time between failures
Assessing Reliability at Architectural Level
Challenged by unknowns
Operational profile
Failure and recovery history
Challenged by uncertainties
Multiple development scenarios
Varying granularity of architectural models
Different information sources about system usage
Architectural reliability values must be qualified by assumptions made to deal
with the above uncertainties
Reliability modeling techniques are needed that deal effectively with
uncertainties
E.g., Hidden Markov Models (HMMs)
Architectural Reliability Analysis in a Nutshell
Simulation-Based Analysis
Requires producing an executable system model
Simulation need not exhibit identical behavior to system implementation
Many low-level system parameters may be unavailable
It needs to be precise and not necessarily accurate
Some architectural models may not be amenable to simulation
Typically require translation to a simulatable language
Caching to the max
Google
Google distributed file system (GFS)
MapReduce
Data selection and reduction
All parallelization done automatically
Architectural Lessons from Google
Abstraction layers abound: GFS hides details of data distribution and
failure, for instance; MapReduce hides the intricacies of parallelizing
operations;
By designing, from the outset, for living with failure of processing, storage,
and network elements, a highly robust system can be created;
Scale is everything: Google’s business demands that everything be built
with scaling issues in mind;
By specializing the design to the problem domain, rather than taking the
generic “industry standard” approach, high performance and very costeffective solutions can be developed;
By developing a general approach (MapReduce) to the data
extraction/reduction problem, a highly reusable service was created.
Decentralized Architectures
Networked applications where there are multiple authorities
In other words
Computation is distributed
Parts of the network may behave differently, and vary over time
Grid Protocol Architecture
Coordinated resource sharing in a distributed environment
E.g., Folding-at-home
GLOBUS
A commonly used infrastructure
“Standard architecture”
Fabric manages low-level resources
Connectivity: communication and authentication
Resource: sharing of a single r.
Collective: coordinating r. usage
Peer-to-Peer Architectures
Decentralized resource sharing and discovery
Napster
Gnutella
P2P that works: Skype
And BitTorrent
Peer-to-Peer Style
State and behavior are distributed among peers which can act as either clients
or servers.
Peers: independent components, having their own state and control thread.
Connectors: Network protocols, often custom.
Data Elements: Network messages
Topology: Network (may have redundant connections between peers); can
vary arbitrarily and dynamically
Supports decentralized computing with flow of control and resources
distributed among peers. Highly robust in the face of failure of any given
node. Scalable in terms of access to resources and computing power. But
caution on the protocol!
Insights from Skype
A mixed client-server and peer-to-peer architecture addresses the discovery
problem.
Replication and distribution of the directories, in the form of supernodes,
addresses the scalability problem and robustness problem encountered in
Napster.
Promotion of ordinary peers to supernodes based upon network and processing
capabilities addresses another aspect of system performance: “not just any
peer” is relied upon for important services.
A proprietary protocol employing encryption provides privacy for calls that are
relayed through supernode intermediaries.
Restriction of participants to clients issued by Skype, and making those clients
highly resistant to inspection or modification, prevents malicious clients from
entering the network.
Mobile Robotics
Manned or partially manned vehicles
Uses
Space exploration
Hazardous waste disposal
Underwater exploration
Issues
Interface with external sensors & actuators
Real-time response to stimuli
Response to obstacles
Sensor input fidelity
Power failures
Mechanical limitations
Unpredictable events
Flight Simulators: Key Characteristics
Real-time performance constraints
Extremely high fidelity demands
Requires distributed computing
Must execute at high fixed frame rates
Often called harmonic frequencies
Coordination across simulator components
All portions of simulator run at integral multiple of base rate
e.g. if base rate = 60Hz, then 30Hz, 15Hz, 12Hz, etc.
Every task must complete on time
Delays can cause simulator sickness
Continuous evolution
Very large & complex
Millions of SLOC
Exponential growth over lifetime of simulator
Distributed development
Portions of work sub-contracted to specialists
Long communication paths increase integration complexity
Expensive verification & validation
Direct by-product of above characteristics
Mapping of Simulation SW to HW components unclear
Efficiency muddies abstraction
Needed because of historical HW limitations
How Is the Complexity Managed?
New style
“Structural Modeling”
Based on
Object–oriented design to model air vehicle’s
Sub-systems
Components
Real-time scheduling to control execution order
Goals of Style
Maintainability
Integrability
Scalability
Style principles
Pre-defined partitioning of functionality among SW elements
Restricted data- & control-flow
Data-flow through export areas only
Decoupling objects
Small number of element types
Results in replicated subsystems
Objects fully encapsulate their own internal state
No side-effects of computations
Narrow set of system-wide coordination strategies
Employs pre-defined mechanisms for data & control passing
Enable component communication & synchronization
F-Sim In The Structural Modeling Style
Five basic computational elements in two classes
Executive (or infrastructure)
Periodic sequencer
Event handler
Synchronizer
Application
Components
Subsystems
Each of the five has
Small API
Encapsulated state
Severely limited external data upon which it relies
Takeaways
A great architecture is the ticket to runaway success
A great architecture reflects deep understanding of the problem domain
A great architecture probably combines aspects of several simpler architectures
Develop a new architectural style with great care and caution. Most likely
you don’t need a new style.
What Is an NFP?
A software system’s non-functional property (NFP) is a constraint on the
manner in which the system implements and delivers its functionality
Example NFPs
Efficiency
Complexity
Scalability
Heterogeneity
Adaptability
Dependability
Designing for FPs
Any engineering product is sold based on its functional properties (FPs)
TV set, DVD player, stereo, mobile telephone
Providing the desired functionality is often quite challenging
Market demands
Competition
Strict deadlines
Limited budgets
However, the system’s success will ultimately rest on its NFPs
“This system is too slow!”
“It keeps crashing!”
“It has so many security holes!”
“Every time I change this feature I have to reboot!”
“I can’t get it to work with my home theater!”
FPs vs. NFPs – An Example
Microsoft Word 6.0
Released in the 1990s
Both for the PC and the Mac
Roughly the same functionality
It ran fine on the PC and was successful
It was extremely slow on the Mac
Microsoft “solved” the problem by charging customers for downgrades
A lot of bad publicity
Challenges of Designing for NFPs
Only partially understood in many domains
E.g., MS Windows and security
Qualitative vs. quantitative
Frequently multi-dimensional
Non-technical pressures
E.g., time-to-market or functional features
Design Guidelines for Ensuring NFPs
Only guidelines, not laws or rules
Promise but do not guarantee a given NFP
Necessary but not sufficient for a given NFP
Have many caveats and exceptions
Many trade-offs are involved
Overarching Objective
Ascertain the role of software architecture in ensuring various NFPs
At the level of major architectural building blocks
Components
Connectors
Configurations
As embodied in architectural style-level design guidelines
Efficiency
Efficiency is a quality that reflects a software system’s ability to meet its
performance requirements while minimizing its usage of the resources in its
computing environment
Efficiency is a measure of a system’s resource usage economy
What can software architecture say about efficiency?
Isn’t efficiency an implementation-level property? Efficiency starts at the
architectural level!
Software Components and Efficiency
Keep the components “small” whenever possible
Keep component interfaces simple and compact
Allow multiple interfaces to the same functionality
Separate data components from processing components
Separate data from meta-data
Software Connectors and Efficiency
Carefully select connectors
Use broadcast connectors with caution
Make use of asynchronous interaction whenever possible
Use location/distribution transparency judiciously
Architectural Configurations and Efficiency
Keep frequently interacting components “close”
Carefully select and place connectors in the architecture
Consider the efficiency impact of selected architectural styles and patterns
Complexity
IEEE Definition
Complexity is the degree to which a software system or one of its
components has a design or implementation that is difficult to understand
and verify
Complexity is a software system’s a property that is directly proportional to
the size of the system, number of its constituent elements, their internal
structure, and the number and nature of their interdependencies
Software Components and Complexity
Separate concerns into different components
Keep only the functionality inside components
Interaction goes inside connectors
Keep components cohesive
Be aware of the impact of off-the-shelf components on complexity
Insulate processing components from changes in data format
Software Connectors and Complexity
Treat connectors explicitly
Keep only interaction facilities inside connectors
Separate interaction concerns into different connectors
Restrict interactions facilitated by each connector
Be aware of the impact of off-the-shelf connectors on complexity
Architectural Configurations and Complexity
Eliminate unnecessary dependencies
Manage all dependencies explicitly
Use hierarchical (de)composition
Scalability and Heterogeneity
Scalability is the capability of a software system to be adapted to meet new
requirements of size and scope
Heterogeneity is the quality of a software system consisting of multiple
disparate constituents or functioning in multiple disparate computing
environments
Heterogeneity is a software system’s ability to consist of multiple disparate
constituents or function in multiple disparate computing environments
Portability is a software system’s ability to execute on multiple platforms
with minimal modifications and without significant degradation in functional
or non-functional characteristics
Software Components and Scalability
Give each component a single, clearly defined purpose
Define each component to have a simple, understandable interface
Do not burden components with interaction responsibilities
Avoid unnecessary heterogeneity
Results in architectural mismatch
Distribute the data sources
Replicate data when necessary
Software Connectors and Scalability
Use explicit connectors
Give each connector a clearly defined responsibility
Choose the simplest connector suited for the task
Be aware of differences between direct and indirect dependencies
Avoid placing application functionality inside connectors
Application functionality goes inside components
Leverage explicit connectors to support data scalability
Architectural Configurations and Scalability
Avoid system bottlenecks
Make use of parallel processing capabilities
Place the data sources close to the data consumers
Try to make distribution transparent
Use appropriate architectural styles
Adaptability
Adaptability is a software system’s ability to satisfy new requirements and
adjust to new operating conditions during its lifetime
Software Components and Adaptability
Give each component a single, clearly defined purpose
Minimize component interdependencies
Avoid burdening components with interaction responsibilities
Separate processing from data
Separate data from metadata
Software Connectors and Adaptability
Give each connector a clearly defined responsibility
Make the connectors flexible
Support connector composability
Architectural Configurations and Adaptability
Leverage explicit connectors
Try to make distribution transparent
Use appropriate architectural styles
Dependability
Dependability is a collection of system properties that allows one to rely on a
system functioning as required
Reliability is the probability that a system will perform its intended
functionality under specified design limits, without failure, over a given time
period
Availability is the probability that a system is operational at a particular
time
Robustness is a system’s ability to respond adequately to unanticipated
runtime conditions
Fault-tolerant is a system’s ability to respond gracefully to failures at
runtime
Survivability is a system’s ability to resist, recognize, recover from, and
adapt to mission-compromising threats
Safety denotes the ability of a software system to avoid failures that will
result in (1) loss of life, (2) injury, (3) significant damage to property, or (4)
destruction of property
Software Components and Dependability
Carefully control external component inter-dependencies
Provide reflection capabilities in components
Provide suitable exception handling mechanisms
Specify the components’ key state invariants
Software Connectors and Dependability
Employ connectors that strictly control component dependencies
Provide appropriate component interaction guarantees
Support dependability techniques via advanced connectors
Architectural Configurations and Dependability
Avoid single points of failure
Provide back-ups of critical functionality and data
Support non-intrusive system health monitoring
Support dynamic adaptation
Security
“The protection afforded to an automated information system in order to attain
the applicable objectives of preserving the integrity, availability and
confidentiality of information system resources (includes hardware, software,
firmware, information/data, and telecommunications).”
National Institute of Standards and Technology
Confidentiality, Integrity, and Availability
Confidentiality
Preserving the confidentiality of information means preventing
unauthorized parties from accessing the information or perhaps even being
aware of the existence of the information. I.e., secrecy.
Integrity
Maintaining the integrity of information means that only authorized parties
can manipulate the information and do so only in authorized ways.
Availability
Resources are available if they are accessible by authorized parties on all
appropriate occasions.
Design Principles for Computer Security
Least Privilege: give each component only the privileges it requires
Fail-safe Defaults: deny access if explicit permission is absent
Economy of Mechanism: adopt simple security mechanisms
Complete Mediation: ensure every access is permitted
Design: do not rely on secrecy for security
Separation of Privilege: introduce multiple parties to avoid exploitation of
privileges
Least Common Mechanism: limit critical resource sharing to only a few
mechanisms
Psychological Acceptability: make security mechanisms usable
Defense in Depth: have multiple layers of countermeasures
Architectural Access Control Models
Decide whether access to a protected resource should be granted or denied
Discretionary access control
Based on the identity of the requestor, the resource, and whether the
requestor has permission to access
Mandatory access control
Policy based
Connector-Centric Architectural Access Control
Decide what subjects the connected components are executing for
Regulate whether components have sufficient privileges to communicate
through the connectors
Provide secure interaction between insecure components
Propagate privileges in architectural access check
Participate in deciding architectural connections
Route messages according to established policies
Decentralization
No centralized authority to coordinate and control entities
Independent peers, with possibly conflicting goals, interact with each other and
make local autonomous decisions
Presence of malicious peers in open decentralized applications
Need for measures to protect peers against malicious attacks
Some Threats of Decentralization
Impersonation: Mallory says she is Bob to Alice
Fraudulent Actions: Mallory doesn’t complete transactions
Misrepresenting Trust: Mallory tells everyone Bob is evil
Collusion: Mallory and Eve tell everyone Bob is evil
Addition of Unknowns: Alice has never met Bob
Decentralized Auctioning
Open decentralized application
Independent buyers/sellers
Potentially malicious participants
Need to counter threats
Background: Trust Management
Trust
Trust is a particular level of the subjective probability with which an agent
assesses that another agent will perform a particular action in a context that
affects his actions [Gambetta, 1990]
Reputation
Expectation about an entity’s behavior based on past behavior [AbdulRahman, 2000]
May be used to determine trust
Two types of trust management systems
Credential and Policy-based
Reputation-based
Role of Trust Management
Each entity (peer) must protect itself against these threats
Trust Management can serve as a potential countermeasure
Trust relationships between peers help establish confidence
Two types of decentralized trust management systems
Credential and policy-based
Reputation-based
Architecture and Trust Management
Decentralized trust management has received a lot of attention from
researchers [Grandison and Sloman, 2000]
Primary focus has been on developing new models
But how does one build a trust-enabled decentralized application?
How do I pick a trust model for a given application?
And, how do I incorporate the trust model within each entity?
Approach
Select a suitable reputation-based trust model for a given application
Describe this trust model precisely
Incorporate the model within the structure (architecture) of an entity
Software architectural style for trust management (PACE)
Result – entity architecture consisting of
components that encapsulate the trust model
additional trust technologies to counter threats
Key Insights
Trust
Cannot be isolated to one component
Is a dominant concern in decentralized applications and should be
considered early on during application development
Having an explicit architecture is one way to consistently address the crosscutting concern of trust
Architectural styles
Provide a foundation to reason about specific goals
Facilitate reuse of design knowledge
Allow known benefits to be leveraged and induce desirable properties
Design Guidelines: Approach
Identify threats of decentralization
Use the threats to identify guiding principles that help defend against the
threats
Incorporate these principles within an architectural style focused on
decentralized trust management
PACE Architectural Style
Basis: C2, a layered event-based style
Allows the natural structuring of the four functional units according to their
dependencies
Facilitates reuse
Extensive tool support
The resultant architectural style is called PACE (Practical Architectural
approach for Composing Egocentric trust)
Functional Units
Communication
Responsible for external interaction with other peers including data
collection and transmission; does not depend upon data storage or analysis
Information
Store all data including internal beliefs and reported information
Trust
Responsible for trust computation and managing credentials; depends upon
internal data for computation
Application
Application-specific components including user interface; Builds upon
services provided by the other three
PACE: Communication Layer
Multiple protocol handlers. Translate internal events into external messages
and vice-versa
Creates and manages protocol handlers
Signs requests and verifies notifications
PACE: Information Layer
Separates internal beliefs from reported information
Stores internal beliefs persistently
PACE: Trust Layer
Incorporates different trust models and algorithms; can assign trust values to
notifications receivedStores internal beliefs persistently
Generates unique public-private key pairs
Maintains local cache of other peers’ identities; requests public keys from
peers and responds to revocationsStores internal beliefs persistently
PACE: Application Layer
Domain-specific trust rules; includes context of trust
User-interface and application-specific components
Countering Fraudulent Actions
User sends request for trust information
Others respond
Responses are verified and tagged with trust values
User sees these messages and makes an informed decision
Post-interaction, user can change trust information
What Are Deployment and Mobility?
Deployment is the process of placement of a system’s software components on
its hardware hosts
Changing the deployment of a component during runtime is called migration
or redeployment
Migration or redeployment is a type of software system mobility
Mobility entails a superset of deployment issues
Deployment and Mobility Challenges
Widely distributed target processors
Target processors embedded inside heterogeneous devices
Different software components may require different hardware configurations
System lifespans may stretch over decades
Software system evolution is continuous (requiring redeployment)
Mobile code may mandate that running, stateful components be redeployed
Software Architecture and Deployment
A system is deployed to a set of hosts or sites
Each site provides a set of resources needed by the system’s components
Hardware
Network
Peripheral devices
System software
Other application software
Data resources
Resources may be exclusive or sharable
How Is Deployment Changing ?
Then
Complete Installation procedure for software system on CD ROM
Entire software system installation
Now
Software producers and consumers cooperating and negotiating.
“Update” of Software Systems
Deployment, Architecture, and Quality of Service
Deployment Architecture: allocation of s/w
…
…
→
—
—
—
—
Two-node “SCARI” SDR with just device drivers loaded
SDR in xADL 2.0
Same radio with one waveform deployed
SDRs in xADL 2.0
By applying product line techniques to SDRs
Can manage different configurations of the radio
Deploying components on alternative hosts
Deployments with
No waveforms
One waveform
Different combinations of waveforms
Can show radio in different states as radio starts up or transitions from one
waveform to another
Adaptation
Change is endemic to software
perceived and actual malleability of software induces stakeholders to initiate
changes, e.g.:
Users want new features
Designer wants to improve performance
Application environment is changing
Adaptation: modification of a software system to satisfy new requirements and
changing circumstances
Goals of this Lecture
Characterize adaptation, showing what changes, why, and who the players are
Characterize the central role software architecture plays in system adaptation
Present techniques for effectively supporting adaptation, based on an
architecture-centric perspective
Sources and Motivations for Change
Corrective Changes
Bug fixes
Modification to the functional requirements
New features are needed
Existing ones modified
Perhaps some must be removed
New or changed non-functional system properties
Anticipation of future change requests
Changed operating environment
Observation and analysis
Changes Arising from Product Line Forces
Creating a new variant
Change at branch point
E.g.: Adding an integrated TV/DVD device to a TV product line
Creation of a new branch point
Merging product (sub)lines
Rationalizing their architectures
Motivation for Online Dynamic Change
Non-stop applications
software cannot be stopped because the “application” cannot be stopped
E.g., 24/7 systems
Maintaining user or application state
stopping the software would cause the user to lose (mental) context
saving and/or recreating the software’s application state would be difficult or
costly
Re-installation difficulty
applications with complex installation properties
E.g., software in an automobile
Stewart Brand’s Shearing Layers of Change
“How Buildings Learn – What happens after they’re built” examines how and
why buildings change over time
Categorization of types of change according to the nature and cost of making a
change
Shearing Layers in a Building
The Six Shearing Layers
Site: the geographical setting, the urban location, and the legally defined lot
its boundaries and context outlast generations of ephemeral buildings.
Structure (“the building”): the foundation and load-bearing elements
perilous and expensive to change, so people don’t
Skin: exterior surfaces
change every ~20 years, to keep up with fashion, technology, or for repair
The Six Shearing Layers (cont’d)
Services: working guts of a building: communications wiring, electrical
wiring, plumbing, sprinkler systems, etc.
Reference architectures are still architectures (since they are also sets of
Space Plan: interior layout – where walls, ceilings, floors, and doors go
principal design decisions)
Stuff: chairs, desks, phones, pictures, kitchen appliances, lamps, hair brushes
Distinguished by the presence of explicit points of variation (explicitly
things that switch around daily to monthly
“unmade” decisions)
The Six Shearing Layers
Site
Different Kinds of Reference Architecture
Complete single product architecture
Structure
A fully worked out exemplar of a system in a domain, with optional
Skin
documentation as to how to diversify
Services
Can be relatively weak due to lack of explicit guidance and possibility that Space Plan
example is a ‘toy’
Stuff
Incomplete invariant architecture
Changing Component Interiors
Points of commonality as in ordinary architecture, points of variation are
A component’s performance may be improved by a change to the algorithm
indicated but omitted
that it uses internally
Invariant architecture with explicit variation
Capabilities that facilitate component adaptation
Points of commonality as in ordinary architecture, specific variations
Knowledge of self and exposure of this knowledge to external entities
indicated and enumerated
Knowledge of the component’s role in the larger architecture
Pro-active engagement of other elements of a system in order to adapt
Example Reference Architecture
Structural view
Change of Component Interface
of Lunar Lander
In many cases adaptation to meet modified functional properties entails
DSSA
changing a component’s interface
Invariant with
Adaptors/wrappers are a popular technique to mitigate “ripple effect”
explicit points
but, subsequent changes to previously unmodified methods become even
of variation
more complex
Satellite relay
Connector Change
Sensors
Typically changes to connectors are motivated by
The desire to alter non-functional properties
Product Lines
A set of related products that have substantial commonality
such as distribution of components, fault-tolerance, efficiency,
In general, the commonality exists at the architecture level
modifiability, etc.
One potential ‘silver bullet’ of software engineering
increased independence of sub-architectures in the face of potential
Power through reuse of
failures
Engineering knowledge
improved performance
Existing product architectures, styles, patterns
The more powerful the connector the easier architectural change
Pre-existing software components and connectors
E.g., connectors supporting event-based communication
What is the downside?
Domains vs. Product Lines
Domain
Change in the Configuration
Consumer electronics
Changes to the configuration of components and connectors represents
Avionics
fundamental change to a system’s architecture
Compilers
Effectively supporting such a modification requires working from an explicit
Video games
model of the architecture
Product Line
Many dependencies between components will exist, and the architectural
Sony WEGA TVs
model is the basis for managing and preserving such relationships
Boeing 747 Family
Change Agents and Context (1)
GNU compiler suite
Change Agents – Identity and Location
Suite of games built on same engine
The processes that carry out adaptation may be performed by
human
Business vs. Engineering Product Lines
Business Product Line
automated agents
A set of products marketed under a common banner to increase sales and
a combination thereof
market penetration through bundling and integration
If an adaptation agent is part of a deployed application from the outset, the
Engineering Product Line
potential is present for an effective adaptation process
A set of products that have substantial commonality from a
Agent may have access to contextual information
technical/engineering perspective
E.g., periodically a user of a desktop OS is notified when an OS or
Generally, business product lines are engineering product lines and vice-versa,
application upgrade is available
but not always
Change Agents and Context (2)
Applications bundled after a company acquisition
Knowledge
Chrysler Crossfire & Mercedes SLK V6
Agent might need knowledge to mitigate adaptation risk
Agent has to know the constraints that must be retained in the modified
Capturing Product Line Architectures
Common: features common to all products
system
A: features specific to product A
If the system’s architectural design decisions have been violated,
B: features specific to product B
architectural recovery will be required
Product A = Common + A
Degree of Freedom
Product B = Common + B
Freedom that the engineer has in designing the changes
Greater freedom  large solution space
A Product-Line Architecture
Definition: A product-line architecture captures the architectures of many
By learning the constraints of the system, the coherence of the architecture
related products simultaneously
can be retained
Generally employs explicit variation points in the architecture indicating
Architecture-Centric Adaptation
where design decisions may diverge from product to product
In the absence of explicit architecture the engineer is left to reason about
adaptation
Product Component Table
Helps us decide whether creating a product line is viable or feasible
from memory
from source code
Group Components into Features
Not a mechanical process
Architecture can serve as the primary focus of reasoning about potential
Attempt to identify (mostly) orthogonal features, or features that would be
adaptations
beneficial in different products
Descriptive architecture is the reference point
Reconstitute Products from Features
Activities, Agents, and Entities
Use technical and business knowledge to identify which combinations form
Adaptation management and evolution management can be separated into three
feasible or marketable products that will be constructed
types of activities
Strategic refers to determining what to do
Modeling Product Line Architectures
Architectural models need to be diversified with information about variation
Tactical refers to developing detailed plans for achieving the strategic goals
points and features
Operations refers to the nuts-and-bolts of carrying out the detailed plans
Not all ADLs have good support for this
Categories of Techniques
Exceptions include
Observing and collecting state
Koala
Analyzing data and planning change
xADL 2.0
Describing change descriptions
These ADLs have explicit support for capturing variation points
Deploying change descriptions
Effecting the change
Selection
Product-line selection is the process of extracting a single product architecture Architectures/Styles that Support Adaptation
(or smaller product line) from an architectural model that contains explicit
Explicit models
points of variation
First-class connectors
ADLs such as Koala and xADL 2.0 can do selection automatically with tools
Adaptable connectors
Message-based communication
Product Lines for Evolution
Products in a product line don’t have to exclusively capture alternatives
…others?
They can also capture variation over time
Architectures/Styles Supporting Adaptation
Application programming interfaces (API)
Product Lines for ‘What-If’ Analysis
In addition to alternative products and different versions of the same product,
Scripting languages
product lines can capture different potential products
Plug-ins
Selection can be used to quickly generate product architectures for potential
Component/object architectures
products
Event interfaces
These can be checked for certain properties or subjected to more rigorous
The Special Problems of On-the-fly Change
analysis for feasibility or quality
The principle of quiescence
Can also be used to generate new product ideas
A node in the active state can initiate and respond to transactions.
The state identified as necessary for reconfiguration is the passive state,
Implementation Issues
Important to partition implementations along variation-point boundaries
node must respond to transaction
Keeping evolving architectures and version-controlled source repositories (e.g.,
not currently engaged in a transaction that it initiated
RCS, CVS, Subversion) in sync
it will not initiate new transactions
Unifying Products with Different Heritage
Often, the idea to create a product line emerges after several products have
been implemented and commonality is noticed
Strategies include
No product line
It may be more expensive to create a product line or there may not be
enough commonality
One master product
One product architecture becomes the basis for the product line
Hybrid
A new product line architecture emerges out of many products
Seems ideal but can be hard in practice
Architectural Styles, DSSAs, Product Lines
Architectural Styles
Can be general or domain-specific
Provides general guidelines for diverse kinds of applications; focus on –ility
development
DSSAs
Domain specific; includes elaborate domain model and specific reference
architecture
Product lines
Explicit set of related products with common aspects
Objectives
Concepts
What is domain-specific software engineering (DSSE)
The “Three Lampposts” of DSSE: Domain, Business, and Technology
Domain Specific Software Architectures
Product Lines
Relationship between DSSAs, Product Lines, and Architectural Styles
Examples of DSSE at work
Koala
An ADL and tool-set for developing product lines of consumer electronics
A successor to Darwin in terms of structural modeling
One of the first ADLs to capture points of variation explicitly
Has tight bindings to implementations such that architecture descriptions can
be “compiled” into application skeletons
Lunar Lander in Koala
No product line features yet
Note similarities to Darwin, xADL 2.0
xADL 2.0 Archipelago visualization is derived from Koala
Lunar Lander PL in Koala
Switch construct routes calls to one of two potential data stores
‘Diversity interface’ lets game logic component select callee from external
config component
Same IDataStore interface ensures call compatibility
Software Defined Radios
Variation points in radio configuration, board configuration, software
configuration
SDR in xADL 2.0
A domain-specific software architecture (DSSA)
Domain Model
A domain model is a set of artifacts that capture information about a domain
Functions performed
Objects (also known as entities) that perform the functions, and on which the
functions are performed
Data and information that flows through the system
Standardizes terminology and semantics
Provides the basis for standardizing (or at least normalizing) descriptions of
problems to be solved in the domain
Domain dictionary : Defines vocabulary for the domain
Information model : Describes the entities and data in the domain
Feature model : Defines how entities and data combine to provide features
Operational model : Defines how data and control flow through entities
(Partial) Domain Dictionary
Info Model: Context Info Diagram
Defines high-level entities
Defines what is considered inside and outside the domain (or subdomains)
Defines relationships and high-level flows
Info Model: Entity-Relationship Diagram
Defines entities and cardinal relationships between them
Info Model: Object Diagram
Defines attributes and operations on entities
Closely resembles class diagram in UML but may be more abstract
Feature Model: Feature Relationship Diagram
Describes overall mission operations of a system
Describes major features and decomposition
Feature Model: Use Case Diagram
Defines use cases within the domain
Similar to use case models in UML
Feature Model: Representation Diagram
Defines how information is presented to human users
Operational Model: Data Flow Diagram
Focuses on data flow between entities with no notion of control
Operational Model: Control Flow Diagram
Focuses on control flow between entities separate from data flow
Operational Model: State Transition Diagram
Focuses on states of systems and transitions between them
Resembles UML state diagrams
Reference Requirements
Mandatory
Must display the current status of the Lunar Lander (horizontal and vertical
velocities, altitude, remaining fuel)
Must indicate points earned by player based on quality of landing
Optional
May display time elapsed
Variant
May have different levels of difficulty based on pilot experience (novice,
expert, etc)
May have different types of input depending on whether
Auto Navigation is enabled
Auto Throttle is enabled
May have to land on different celestial bodies
Moon
Mars
Jupiter’s moons
Asteroid
Domain-Specific Software Architecture
Definition: Definition. A domain-specific software architecture (DSSA)
comprises:
a reference architecture, which describes a general computational framework
for a significant domain of applications;
a component library, which contains reusable chunks of domain expertise;
and
an application configuration method for selecting and configuring
components within the architecture to meet particular application
requirements.
Reference Architecture
Definition. Reference architecture is the set of principal design decisions that
are simultaneously applicable to multiple related systems, typically within an
application domain, with explicitly defined points of variation.