1. Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Designing for NFPs Infosys, Mysore December 21, 2009

2. Foundations, Theory, and Practice Software Architecture 2 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 u Efficiency u Complexity u Scalability u Heterogeneity u Adaptability u Dependability

3. Foundations, Theory, and Practice Software Architecture 3 Designing for FPs Any engineering product is sold based on its functional properties (FPs) u TV set, DVD player, stereo, mobile telephone Providing the desired functionality is often quite challenging u Market demands u Competition u Strict deadlines u Limited budgets However, the system’s success will ultimately rest on its NFPs u “This system is too slow!” u “It keeps crashing!” u “It has so many security holes!” u “Every time I change this feature I have to reboot!” u “I can’t get it to work with my home theater!”

4. Foundations, Theory, and Practice Software Architecture 4 FPs vs. NFPs – An Example Microsoft Word 6.0 u Released in the 1990s u Both for the PC and the Mac u Roughly the same functionality u It ran fine on the PC and was successful u It was extremely slow on the Mac u Microsoft “solved” the problem by charging customers for downgrades u A lot of bad publicity

5. Foundations, Theory, and Practice Software Architecture 5 FPs vs. NFPs – Another Example Linux – “as-documented” architecture Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

6. Foundations, Theory, and Practice Software Architecture 6 FPs vs. NFPs – Another Example Linux – “as-implemented” architecture Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

7. Foundations, Theory, and Practice Software Architecture 7 Challenges of Designing for NFPs Only partially understood in many domains u E.g., MS Windows and security Qualitative vs. quantitative Frequently multi-dimensional Non-technical pressures u E.g., time-to-market or functional features

8. Foundations, Theory, and Practice Software Architecture 8 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

9. Foundations, Theory, and Practice Software Architecture 9 Overarching Objective Ascertain the role of software architecture in ensuring various NFPs u At the level of major architectural building blocks Components Connectors Configurations u As embodied in architectural style-level design guidelines

10. Foundations, Theory, and Practice Software Architecture 10 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 u Efficiency is a measure of a system’s resource usage economy What can software architecture say about efficiency? u Isn’t efficiency an implementation-level property?  Efficiency starts at the architectural level!

11. Foundations, Theory, and Practice Software Architecture 11 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

12. Foundations, Theory, and Practice Software Architecture 12 Multiple Interfaces to the Same Functionality Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

13. Foundations, Theory, and Practice Software Architecture 13 Software Connectors and Efficiency Carefully select connectors Use broadcast connectors with caution Make use of asynchronous interaction whenever possible Use location/distribution transparency judiciously

14. Foundations, Theory, and Practice Software Architecture 14 Distribution Transparency Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

15. Foundations, Theory, and Practice Software Architecture 15 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

16. Foundations, Theory, and Practice Software Architecture 16 Performance Penalty Induced by Distance Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

17. Foundations, Theory, and Practice Software Architecture 17 Complexity IEEE Definition u 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 u What about behavior?

18. Foundations, Theory, and Practice Software Architecture 18 Software Components and Complexity Separate concerns into different components Keep only the functionality inside components u 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

19. Foundations, Theory, and Practice Software Architecture 19 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

20. Foundations, Theory, and Practice Software Architecture 20 Architectural Configurations and Complexity Eliminate unnecessary dependencies Manage all dependencies explicitly Use hierarchical (de)composition

21. Foundations, Theory, and Practice Software Architecture 21 Complexity in Linux Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

22. Foundations, Theory, and Practice Software Architecture 22 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 u Heterogeneity is a software system’s ability to consist of multiple disparate constituents or function in multiple disparate computing environments u 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

23. Foundations, Theory, and Practice Software Architecture 23 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 u Results in architectural mismatch Distribute the data sources Replicate data when necessary

24. Foundations, Theory, and Practice Software Architecture 24 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 u Application functionality goes inside components Leverage explicit connectors to support data scalability

25. Foundations, Theory, and Practice Software Architecture 25 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

26. Foundations, Theory, and Practice Software Architecture 26 Adaptability Adaptability is a software system’s ability to satisfy new requirements and adjust to new operating conditions during its lifetime

27. Foundations, Theory, and Practice Software Architecture 27 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

28. Foundations, Theory, and Practice Software Architecture 28 Software Connectors and Adaptability Give each connector a clearly defined responsibility Make the connectors flexible Support connector composability

29. Foundations, Theory, and Practice Software Architecture 29 Composable Connectors Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

30. Foundations, Theory, and Practice Software Architecture 30 Architectural Configurations and Adaptability Leverage explicit connectors Try to make distribution transparent Use appropriate architectural styles

31. Foundations, Theory, and Practice Software Architecture 31 Dependability Dependability is a collection of system properties that allows one to rely on a system functioning as required u Reliability is the probability that a system will perform its intended functionality under specified design limits, without failure, over a given time period u Availability is the probability that a system is operational at a particular time u Robustness is a system’s ability to respond adequately to unanticipated runtime conditions u Fault-tolerant is a system’s ability to respond gracefully to failures at runtime u Survivability is a system’s ability to resist, recognize, recover from, and adapt to mission-compromising threats u 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

32. Foundations, Theory, and Practice Software Architecture 32 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

33. Foundations, Theory, and Practice Software Architecture 33 Software Connectors and Dependability Employ connectors that strictly control component dependencies Provide appropriate component interaction guarantees Support dependability techniques via advanced connectors

34. Foundations, Theory, and Practice Software Architecture 34 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

35. Foundations, Theory, and Practice Software Architecture 35 Security, Trust, and Privacy Security u “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

36. Foundations, Theory, and Practice Software Architecture 36 Confidentiality, Integrity, and Availability Confidentiality u 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 u Maintaining the integrity of information means that only authorized parties can manipulate the information and do so only in authorized ways. Availability u Resources are available if they are accessible by authorized parties on all appropriate occasions.

37. Foundations, Theory, and Practice Software Architecture 37 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

38. Foundations, Theory, and Practice Software Architecture 38 Design Principles for Computer Security (cont’d) 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

39. Foundations, Theory, and Practice Software Architecture 39 Architectural Access Control Models Decide whether access to a protected resource should be granted or denied Discretionary access control u Based on the identity of the requestor, the resource, and whether the requestor has permission to access Mandatory access control u Policy based

40. Foundations, Theory, and Practice Software Architecture 40 Discretionary Access Control Database AComponent QInterface F AliceRead-Write; Always BendYes BobRead-Write; Between 9 and 5 FoldNo CharlesNo accessSpindleNo DaveNo accessMutilateYes EveRead-only; Always NoneNo

41. Foundations, Theory, and Practice Software Architecture 41 Mandatory Access Control Bob: Secret Alice: Confidential Tom: Top Secret Arrows show access (read/write) privileges What about just appending?

42. Foundations, Theory, and Practice Software Architecture 42 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 Static analysis of architectures coupled with dynamic checking

43. Foundations, Theory, and Practice Software Architecture 43 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

44. Foundations, Theory, and Practice Software Architecture 44 Trust management can serve as a potential countermeasure u Trust relationships help peers establish confidence in other peers 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

45. Foundations, Theory, and Practice Software Architecture 45 Marvin (malicious) Carol Bob Alice Mallory (malicious) Decentralized Auctioning Decentralized Auctioning Open decentralized application Independent buyers/sellers Potentially malicious participants Need to counter threats

46. Foundations, Theory, and Practice Software Architecture 46 Bob Alice Mallory (malicious) “I am Bob” Bob is reliable and everyone has a good opinion about Bob Impersonation

47. Foundations, Theory, and Practice Software Architecture 47 Alice “buyer” Alice pays for the items Marvin “seller” (malicious) Marvin does not ship the items Fraudulent Actions

48. Foundations, Theory, and Practice Software Architecture 48 Bob Alice Mallory (malicious) “Bob is unreliable” Bob is reliable and everyone has a good opinion about Bob Misrepresentation

49. Foundations, Theory, and Practice Software Architecture 49 Bob Alice Mallory (malicious) “Bob is unreliable” Bob is reliable and everyone has a good opinion about Bob Marvin (malicious) Collusion

50. Foundations, Theory, and Practice Software Architecture 50 Carol (new entrant in the system) Bob Alice Bob has no information about Carol; he is not sure whether to interact with Carol Carol is new and does not know Alice; she is not sure whether to interact with Alice Addition of Unknowns

51. Foundations, Theory, and Practice Software Architecture 51 Background: Trust Management Trust u 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 u Expectation about an entity’s behavior based on past behavior [Abdul-Rahman, 2000] u May be used to determine trust Two types of trust management systems u Credential and Policy-based u Reputation-based

52. Foundations, Theory, and Practice Software Architecture 52 Role of Trust Management Each entity (peer) must protect itself against these threats Trust Management can serve as a potential countermeasure u Trust relationships between peers help establish confidence Two types of decentralized trust management systems u Credential and policy-based u Reputation-based

53. Foundations, Theory, and Practice Software Architecture 53 Architecture and Trust Management Decentralized trust management has received a lot of attention from researchers [Grandison and Sloman, 2000] u Primary focus has been on developing new models But how does one build a trust-enabled decentralized application? u How do I pick a trust model for a given application? u And, how do I incorporate the trust model within each entity?

54. Foundations, Theory, and Practice Software Architecture 54 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 u Software architectural style for trust management (PACE) Result – entity architecture consisting of u components that encapsulate the trust model u additional trust technologies to counter threats

55. Foundations, Theory, and Practice Software Architecture 55 Key Insights Trust u Cannot be isolated to one component u Is a dominant concern in decentralized applications and should be considered early on during application development u Having an explicit architecture is one way to consistently address the cross-cutting concern of trust Architectural styles u Provide a foundation to reason about specific goals u Facilitate reuse of design knowledge u Allow known benefits to be leveraged and induce desirable properties

56. Foundations, Theory, and Practice Software Architecture 56 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

57. Foundations, Theory, and Practice Software Architecture 57 PACE Architectural Style Basis: C2, a layered event-based style u Allows the natural structuring of the four functional units according to their dependencies u Facilitates reuse u Extensive tool support The resultant architectural style is called PACE (Practical Architectural approach for Composing Egocentric trust)

58. Foundations, Theory, and Practice Software Architecture 58 Functional Units Communication u Responsible for external interaction with other peers including data collection and transmission; does not depend upon data storage or analysis Information u Store all data including internal beliefs and reported information Trust u Responsible for trust computation and managing credentials; depends upon internal data for computation Application u Application-specific components including user interface; Builds upon services provided by the other three

59. Foundations, Theory, and Practice Software Architecture 59 Application Layer Communication Layer Information Layer Trust Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N PACE Components

60. Foundations, Theory, and Practice Software Architecture 60 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 Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N

61. Foundations, Theory, and Practice Software Architecture 61 Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N Separates internal beliefs from reported information Stores internal beliefs persistently PACE: Information Layer

62. Foundations, Theory, and Practice Software Architecture 62 Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N Incorporates different trust models and algorithms; can assign trust values to notifications received Generates unique public-private key pairs Maintains local cache of other peers’ identities; requests public keys from peers and responds to revocations PACE: Trust Layer

63. Foundations, Theory, and Practice Software Architecture 63 PACE: Application Layer Domain-specific trust rules; includes context of trust User-interface and application- specific components Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N

64. Foundations, Theory, and Practice Software Architecture 64 Communication Layer Information Layer Trust Layer Application Layer Communication Manager External Information Internal Information Key Manager Signature Manager Trust Manager Application Trust Rules HTTP SenderCustom ProtocolsMulticast Manager Multicast Handler Credential Manager A P P L I C A T I O N 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

65. Foundations, Theory, and Practice Software Architecture And Now, Something Completely Different 65

66. Foundations, Theory, and Practice Software Architecture Computing with Tiles A tile: u a square u labels on 4 sides Tiles attach u when labels match [Winfree 1998]

67. Foundations, Theory, and Practice Software Architecture Computing with Tiles A tile: u a square u labels on 4 sides Tiles attach u when labels match [Winfree 1998]

68. Foundations, Theory, and Practice Software Architecture Tile Interaction Tiles can stick to assemblies:

69. Foundations, Theory, and Practice Software Architecture Tile Interaction Tiles can stick to assemblies

70. Foundations, Theory, and Practice Software Architecture What Can Tiles Do? Assemble u linear polymers [Adleman et al. 2001] u squares [Rothemund et al. 2001, Adleman et al. 2001, 2002] u arbitrary computable shapes [Soloveichik et al. 2004] Count [Winfree 1998, Moisset et al. 2005, Barish et al. 2005] Compute binomial coefficients [Winfree 1998, Rothemund et al. 2004] Emulate Turing machines [Winfree 1998] i.e. Compute [Brun 2006, Brun 2007, Brun 2008] u Add u Multiply u Factor u Solve NP-complete problems

71. Foundations, Theory, and Practice Software Architecture Solving 3-SAT with Tiles (x 2  ¬x 1  ¬x 0 )  (¬x 2  ¬x 1  ¬x 0 )  (¬x 2  x 1  x 0 )

72. Foundations, Theory, and Practice Software Architecture Solving 3-SAT with Tiles (x 2  ¬x 1  ¬x 0 )  (¬x 2  ¬x 1  ¬x 0 )  (¬x 2  x 1  x 0 )

73. Foundations, Theory, and Practice Software Architecture Mapping the Model to a System Each node deploys tiles of a single type Initial mapping Node discovery Replication of seeds Recruitment of new nodes to complete the crystal

74. Foundations, Theory, and Practice Software Architecture Challenges Doing this in an actual system u Fault tolerance u Security Active components Active state Scale Overhead of explicit connectors Ensuring adherence to the model

75. Foundations, Theory, and Practice Software Architecture Tile Architectural Style 75

76. Foundations, Theory, and Practice Software Architecture Privacy Preservation Data u Each node knows very little u It is hard to control the entire input Algorithm u One tile type implies nothing u It is hard to learn all the tile types u Knowing the tile types does not reveal the algorithm 76

77. Foundations, Theory, and Practice Software Architecture Data Privacy 77