Exam #2 review

CSCI 578
Software Architectures
Exam #2 Review
Materials you are responsible
for
• Chapters 9-17 in the text book
– Also Chapter 8 on Architectural Analysis
since we didn’t cover this in the first exam
• All lecture material from Implementation
Architectures through People, Roles
and Teams (Week 15)
• Homework #3 and Course Project
• Dave Kale’s lecture, Eric Dashofy’s
lecture
Exam
• Closed book, closed note
• Format
– Write in answers
– No multiple choice
Material Review
• Implementing Architectures
– Mapping problem of design decisions to
implementation artifacts (code, executables, etc.)
– Common Element Mapping
• Understand how components, connectors, interfaces,
configurations are reified in the actual system
implementation
– One way versus Round-trip Mapping
– Architectural Implementation Frameworks
• a piece of software that acts as a bridge between a
particular architectural style and a set of implementation
technologies
Material Review
• Architectural implementation framework examples
– stdio, java.io, iostream => pipe and filter
• Evaluating architectural implementation frameworks
– Platform support, fidelity, matching assumptions, efficiency,
size, cost, ease of use, reliability, robustness, availability of
source code, portability, long-term maintainability and
support
• Middleware
– Represents the implementation-level reification of software
connectors
• New Frameworks
– Avoid constructing these unless you have to!
Material Review
• Applied Architectures
– 8 limitations (“fallacies”) of distributed computing
(Deutsch & Gosling)
•
•
•
•
•
•
•
•
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn’t change
There is one administrator
Transport cost is zero
The network is homogeneous
Material Review
• Applied Architectures
– REST/WWW
• Architectural principles
– Resources, resources include metadata + bits, context free
communication (stateless), small set of well defined
methods, representation metadata for caching, presence of
intermediaries to distributed computation/workload
– Akami
• Caching of content and localized delivery architecture
– Google MapReduce/GFS
• Distribution of computation/parallelization and data over
a commodity cluster of machines
Material Review
• Applied Architectures
– Grid Protocol Architecture (Globus)
– P2P Architectures
• Napster, Gnutella
• Skype
• Bittorrent
• Overall 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.
Material Review
• Designing for Non-Functional Properties (NFPs)
– 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
Material Review
• 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, Complexity, Scalability,
Heterogeneity, Adaptability, Dependability
Material Review
• Security and Trust
– “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
• Design Principles
– 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
Material Review
• Security and Trust
• Design Principles
– 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
Material Review
• Decentralized
– 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
Material Review
• 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
Carol
• Open
decentralized
application
• Independent
buyers/sellers
• Potentially
malicious
participants
• Need to
counter threats
Bob
Alice
Decentralized
Auctioning
Marvin
(malicious)
Mallory
(malicious)
Impersonation
Bob
Alice
Bob is reliable and everyone
has a good opinion about Bob
“I am Bob”
Mallory
(malicious)
Fraudulent Actions
Alice pays
for the items
Marvin “seller”
(malicious)
Marvin does
not ship the items
Alice “buyer”
Misrepresentation
Bob
Alice
Bob is reliable and everyone
has a good opinion about Bob
“Bob is unreliable”
Mallory
(malicious)
Bob
Collusion
Alice
Bob is reliable and everyone
has a good opinion about Bob
“Bob is unreliable”
Marvin
(malicious)
Mallory
(malicious)
Addition of Unknowns
Carol
(new entrant in the system)
Bob has no information
about Carol; he is not sure
whether to interact with Carol
Bob
Carol is new and does not
know Alice; she is not sure
whether to interact with Alice
Alice
Material Review
• PACE Architecture
HTTP Sender Custom Protocols Multicast Manager
Communication
Manager
Communication
Layer
Multicast Handler
Key
Manager
External
Information
Credentia
l
Manager
Application Trust Rules
APPLICATION
Trust
Manager
Trust
Layer
Internal
Information
Information
Layer
Signature Manager
Material Review
• 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
Material Review
• 4 Major Deployment Activities
– Planning
– Modeling
– Analysis
– Implementation
Material Review
• Deployment Implementation
–
–
–
–
–
–
–
–
–
Release
Install
Activate
Deactivate
Update
Adapt
Reconfigure
De-install or remove
De-release or retire
Material Review
• Code Mobility Paradigms
– Remote evaluation
• Re-deploy needed component at runtime from a source
host to a destination host
• Install component on the destination host
– Code-on-demand
• Same as remote evaluation, but roles of target and
destination hosts are reversed
– Mobile agent
• Migration of a stateful software component that needs
some remote resources to complete its task
Material Review
• 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.
• Reference architectures are still architectures (since
they are also sets of principal design decisions)
– Distinguished by the presence of explicit points of variation
(explicitly “unmade” decisions)
Material Review
• DSSA Definition (Hayes-Roth)
• 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. (“variation points”)
Material Review
• DSSE and Product Line Architectures
– Product Lines
• A set of related products that have substantial
commonality
Material Review
• People, Roles and Teams
– Architect desired skills
•
•
•
•
•
•
•
•
•
•
•
Software development expertise
Domain expertise
Communicator
Strategist
Consultant
Leader
Technologist
Cost estimator
Cheerleader
Politician
Salesperson
Material Review
• Pitfalls of the architecture team
– Imbalance of skills
• Lack of software development experience
• Lack of domain expertise
– Lack of authority
• Team acts as committee
– Life in ivory tower
– Confusing tools/techniques/methodologies with
architectures
– Procrastination