CSCI 578 Software Architectures

Slides:



Advertisements
Similar presentations
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #12-1 Chapter 12: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Advertisements

Applied Architecture & Styles Not all problems can be solved by following a simple, uniform design solution. Most will require some invention or innovation.
A Cooperative Approach to Support Software Deployment Using the Software Dock by R. Hall, D. Heimbigner, A. Wolf Sachin Chouksey Ebru Dincel.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Designing for NFPs Software Architecture Lecture 19.
PACE: An Architectural Style for Trust Management in Decentralized Applications Girish Suryanarayana Justin Erenkrantz Scott Hendrickson.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Security and Trust Software Architecture Lecture 21.
Deployment and Mobility of Software Software architecture must eventually be “realized” ---- that is –a) implemented and – b) deployed Deployment is the.
1 Design Principles CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 13, 2004.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Security and Trust Software Architecture Lecture 21.
Design Principles Overview Principles Least Privilege Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least.
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Designing for NFPs Software Architecture Lecture 19.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Applied Architectures Eunyoung Hwang. Objectives How principles have been used to solve challenging problems How architecture can be used to explain and.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Security potpourri INF 123 – Software architecture (Slides from Dick Taylor and Crista Lopes) 1.
Matthew Moccaro Chapter 10 – Deployment and Mobility PART II.
Security and Trust By Troy Lee. Overview Security Design Principles Architectural Access Control Access Control Models Connector-centric Architectural.
By Swetha Namburi.  Trust  Trust Model ◦ Reputation-based Systems ◦ Architectural Approach to Decentralized Trust Management.
DISTRIBUTED COMPUTING Introduction Dr. Yingwu Zhu.
Distributed Computing Systems CSCI 4780/6780. Distributed System A distributed system is: A collection of independent computers that appears to its users.
Distributed Computing Systems CSCI 4780/6780. Geographical Scalability Challenges Synchronous communication –Waiting for a reply does not scale well!!
Integrated Systems Division Service-Oriented Programming Guy Bieber, Lead Architect Motorola ISD C4I 2000 OOPSLA Jini Pattern Language Workshop Guy Bieber,
9 Systems Analysis and Design in a Changing World, Fourth Edition.
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.
Software Deployment and Mobility. Introduction Deployment is the placing of software on the hardware where it is supposed to run. Redeployment / migration.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Applied Architectures, Part 2 Software Architecture Lecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CSCI 578 Software Architectures Exam #2 Review. Materials you are responsible for Chapters in the text book All lecture material from Implementation.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Designing for NFPs Infosys, Mysore December 21, 2009.
Distributed Computing Systems CSCI 4780/6780. Scalability ConceptExample Centralized servicesA single server for all users Centralized dataA single on-line.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
Fall 2008CS 334: Computer SecuritySlide #1 Design Principles Thanks to Matt Bishop.
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
1 Chapter 12: Design Principles Overview –There are principles for many kinds of design Generally, a design should consider: Balance, Rhythm, Proportion,
June 1, 2004© Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Slide #13-1 Design Principles CS461/ECE422 Computer Security I Fall 2008 Based on slides provided by Matt Bishop for use with Computer Security: Art and.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Security and Trust Software Architecture.
Distributed Systems Architecure. Architectures Architectural Styles Software Architectures Architectures versus Middleware Self-management in distributed.
CSCI 578 Software Architectures Exam #1 Review. Materials you are responsible for Chapters 1-7 in the text book All lecture material through intro to.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Deployment and Mobility Software Architecture Lecture 12.
CS457 Introduction to Information Security Systems
Chapter 8 Environments, Alternatives, and Decisions.
An Introduction to Software Engineering
CSCI 578 Software Architectures
Software Connectors.
Distributed Systems CS
Distribution and components
Security Engineering.
Chapter 18 MobileApp Design
CHAPTER 1 INTRODUCTION:
Software Architecture Lecture 19
CSCI 578 Software Architectures
Software Connectors – A Taxonomy Approach
CSCI 578 Software Architectures
Software Architecture
Software Architecture Lecture 20
CSCI 578 Software Architectures
How to Mitigate the Consequences What are the Countermeasures?
Software Connectors.
An Introduction to Software Architecture
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Distributed Systems CS
Message Queuing.
Strategic Sponsors Sponsors and Partners Gold Sponsors Silver Sponsors.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Introduction to SOA Part II: SOA in the enterprise
Design Principles Thanks to Matt Bishop 2006 CS 395: Computer Security.
CSCI 578 Software Architectures
Presentation transcript:

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) Course Project C2SADEL material/addendum

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 Akami 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 Overall takeaways 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 Design Principles “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 Bob Alice Mallory (malicious) Decentralized Auctioning Open decentralized application Independent buyers/sellers Potentially malicious participants Need to counter threats Marvin (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 does not ship the items Marvin “seller” (malicious) Alice “buyer”

Misrepresentation Bob Alice Bob is reliable and everyone has a good opinion about Bob “Bob is unreliable” Mallory (malicious)

Collusion Bob 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) Carol is new and does not know Alice; she is not sure whether to interact with Alice Bob has no information about Carol; he is not sure whether to interact with Carol Alice Bob

Communication Manager Application Trust Rules Material Review PACE Architecture Communication Layer Information Trust Communication Manager External Internal Key Manager Signature Manager Application Trust Rules HTTP Sender Custom Protocols Multicast Manager Multicast Handler Credential A P P L I C A T I O N

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 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