cs446.tex

\documentclass[]{article}
\usepackage{etex}
\usepackage[margin = 1.5in]{geometry}
\setlength{\parindent}{0in}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{listings}
\usepackage{color}
\usepackage{mathtools}
\usepackage{multicol}
\usepackage{pgfplots}
\usepackage{qtree}
\usepackage{xytree}
\usepackage[lined]{algorithm2e}
\usepackage{float}
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl}
\usepackage[pdftex,
  pdfauthor={Michael Noukhovitch},
  pdftitle={CS 446: Software Design and Architecture},
  pdfsubject={Lecture notes from CS 446 at the Unversity of Waterloo},
  pdfproducer={LaTeX},
  pdfcreator={pdflatex}]{hyperref}

\usepackage{cleveref}
\usepackage{enumitem}

\definecolor{dkgreen}{rgb}{0,0.6,0}
\definecolor{gray}{rgb}{0.5,0.5,0.5}
\definecolor{mauve}{rgb}{0.58,0,0.82}

\lstset{
  language=C,
  aboveskip=3mm,
  belowskip=3mm,
  showstringspaces=false,
  columns=flexible,
  basicstyle={\small\ttfamily},
  numbers=none,
  numberstyle=\tiny\color{gray},
  keywordstyle=\color{blue},
  commentstyle=\color{dkgreen},
  stringstyle=\color{mauve},
  breaklines=true,
  breakatwhitespace=true,
  tabsize=4
}

\theoremstyle{definition}
\newtheorem*{defn}{Definition}
\newtheorem{ex}{Example}[section]
\newtheorem*{theorem}{Theorem}

\setlength{\marginparwidth}{1.5in}
\setlength{\algomargin}{0.75em}

\DeclarePairedDelimiter{\set}{\lbrace}{\rbrace}

\definecolor{darkish-blue}{RGB}{25,103,185}

\usepackage{hyperref}
\hypersetup{
    colorlinks,
    citecolor=darkish-blue,
    filecolor=darkish-blue,
    linkcolor=darkish-blue,
    urlcolor=darkish-blue
}
\newcommand{\lecture}[1]{\marginpar{{\footnotesize $\leftarrow$ \underline{#1}}}}

\makeatletter
\def\blfootnote{\gdef\@thefnmark{}\@footnotetext}
\makeatother

\begin{document}
	\let\ref\Cref

	\title{\bf{CS 446: Software Design and Architecture}}
	\date{Spring 2016, University of Waterloo \\ \center Notes written from Victoria Sakhini's lectures.}
	\author{Michael Noukhovitch}

	\maketitle
	\newpage
	\tableofcontents
	\newpage

	\section{Mobile Application}
	\subsection{Overview}
	A mobile application is structured of mulitple layers: \textbf{presentation}, \textbf{business}, and \textbf{data}. 
	\subsection{Design Considerations}
	\subsubsection{Client Type}
	\begin{description}
		\item[Rich] local processing required, must work in ocassionally connected scenario
		\item[Thin] can depend on server processing and will always be fully connected
		\item[Rich Internet Application] requires a rich UI and only limited access to local resources (+ maybe portably to other platforms)
	\end{description}

	\subsubsection{Devices to Support}
	Consider
	\begin{itemize}
		\item screen size and resolution
		\item cpu power
		\item memory and storage space
		\item dev tool availability
		\item user requirements, org constraints
		\item specific hardware requirements
	\end{itemize}

	\subsubsection{Connectivity}
	If internet access is required, plan for intermittent or unavailable network connection
	\begin{itemize}
		\item caching
		\item state management
		\item batch communications
	\end{itemize}

	\subsubsection{Device Constraints}
	Think of platform constraints, mainly:
	\begin{itemize}
		\item memory
		\item battery life
			\begin{itemize}
				\item processing requirements
				\item backlighting
				\item memory I/O
				\item wireless connections
			\end{itemize}
		\item responsiveness of design
		\item security
		\item network bandwidth
	\end{itemize}

	\subsubsection{Architecture}
	\begin{itemize}
		\item layered architecture (multiple layers can be on device)
		\item reuse and maintainability
		\item smallest footprint possible
	\end{itemize}

	\subsection{Design Issues}
	\subsubsection{Authentication/Authorization}
	\begin{itemize}
		\item security and reliability
		\item think about more than single user
	\end{itemize}

	\subsubsection{Caching}
	\begin{itemize}
		\item improve performance
		\item support offline work
		\item decide on what to cache based on limited resources
	\end{itemize}
	\textbf{lazy acquisition} defer acquiring resources as long as possible

	\subsubsection{Communicaion}
	\begin{itemize}
		\item wifi, wired, bluetooth
		\item secure communication
		\item wireless is unreliable
	\end{itemize}
	\begin{description}
		\item[active object] support async processing by encapsulating service request and completion response
		\item[communicator] encapsulate internal details of communication 
		\item[entity translator] transforms message data types into business types for requests and reverses for responses
		\item[reliable sessions] end to end reliable message transfer
	\end{description}

	\subsubsection{Configuration Management}
	\begin{itemize}
		\item how to handle device resets
		\item how to allow configuration (OTA, from some host?)
	\end{itemize}

	\subsubsection{Data Access}
	\begin{itemize}
		\item low bandwidth
		\item high latency
		\item intermittent connectivity
	\end{itemize}
	\begin{description}
		\item[active record] include data access object within domain entry
		\item[data transfer object] object storing data transported between processes, reducing method calls
		\item[domain model] business objects that represent entities in a domain and relationships between them
		\item[transaction script] organize logic for each transaction in a single procedure, making calls directory to DB (or through wrapper)
	\end{description}

	\subsubsection{Device Specifics}
	\begin{itemize}
		\item screen size
		\item orientation
		\item memory, storage space
		\item network bandwidth
		\item connectiviy
		\item OS
		\item hardware constraints
	\end{itemize}

	\subsubsection{Exception Management}
	\begin{itemize}
		\item prevent sensitive exception details from being revealed to the user
		\item improve application robustness
		\item keep application in consistent state after an error
	\end{itemize}

	\subsubsection{Logging}
	\begin{itemize}
		\item log only essentials because of size constraints
		\item may need to synchronize logs with server
	\end{itemize}

	\subsubsection{Power Management}
	\begin{itemize}
		\item power is limiting design factor
		\item research communication protocols and their effect on battery life
	\end{itemize}

	\subsubsection{Synchronization}
	\begin{itemize}
		\item secure communications OTA
		\item handle connection interruptions
	\end{itemize}
	\begin{description}
		\item[sync design pattern] component installed on device tracks changes to data and tells server when connected
	\end{description}

	\subsubsection{Testing}
	Mobile debugging is costly, so make sure to invest heavily in testing beforehandas emulators may not be adequate to simulate a device in debugging.

	\subsubsection{UI}
	\begin{itemize}
		\item build mobile first
		\item design for simplicity
		\item design around blocking operations (since user can only see once screen at a time)
	\end{itemize}
	\begin{description}
		\item[application controller] object that contains all the flow logic 
		\item[MVC] separate the data, presentation, and actions into three separate classes
			\begin{itemize}
				\item model manages behaviour and data (logic)
				\item view manages information display
				\item controller manages user input
			\end{itemize}
		\item[MVP] same as MVC but presenter manages presentation logic and interaction between view and model
		\item[pagination] separate content into individual pages
	\end{description}

	\subsubsection{Validation}
	\begin{itemize}
		\item protect device and application
		\item improve usability
		\item validate client-side and server-side
	\end{itemize}

	\section{Software Architecture}
	\subsection{Definition}
	No perfect definition but AINSI/IEEE defines it as
	
	\begin{quote}
	recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 
	\end{quote}

	major concepts
	\begin{itemize}
		\item processing/functionality/behaviour
		\item data/information/store
		\item interaction/communication/coordination
	\end{itemize}
	
	\subsection{Components}
	\textbf{component} encapsulates processing and data
	\begin{itemize}
		\item encapsulates a subset of the system's functionality and/or data
		\item restricts access to that subset via an explicitly defined interface
		\item has explicitly defined dependencies on its required execution context
		\item typically provides application-specific interface
	\end{itemize}

	\subsection{Connectors}
	\textbf{connector} effecting and regulating interactions among components
	\begin{itemize}
		\item can be simple procedure calls or shared data access
		\item provide application independent interaction facilities
	\end{itemize}
	functions:
	\begin{itemize}
		\item modelling arbritrary complex interactions
		\item aiding system evolution (w/ flexibility)
		\item support for connector interchange 
	\end{itemize}

	\subsubsection{Roles}
	\begin{itemize}
		\item communication
			\begin{itemize}
				\item supports different communication mechanisms (procedure call, message passing)
				\item constraints on commincation structure (pipes)
				\item constriaints of quality of service (persistence)
				\item separates communication from computation
			\end{itemize}
		\item coordination
			\begin{itemize}
				\item determine computation control
				\item control delivery of data
				\item separate control from computation
				\item elements of control are in communication, conversion, facilitation
			\end{itemize}
		\item conversion
			\begin{itemize}
				\item interaction of mismatched components (adaptors, wrappers)
				\item mismatches based on interaction
					\begin{itemize}
						\item type
						\item number
						\item frequency
						\item order
					\end{itemize}
			\end{itemize}
		\item facilitation
			\begin{itemize}
				\item mediate and streamline interaction of components intended to interoperate
				\item govern access to shared data
				\item ensure performance profiles (load balancing)
				\item provide sync mechanisms (critical sections, monitors)
			\end{itemize}
	\end{itemize}

	\subsubsection{Types}
	\begin{itemize}
		\item procedure call
		\item data access
		\item event
		\item stream
		\item linkage
		\item distributor
		\item arbitrator
		\item adaptor
	\end{itemize}

	\subsubsection{In Practise}
	To select a connector, determine:
	\begin{itemize}
		\item interaction and interconnection needs
		\item roles to be fulfilled (e.g. communication)
		\item each connector's:
			\begin{itemize}
				\item type (e.g. stream)
				\item dimensions (e.g. delivery)
				\item values for each dimension (e.g. best effort, once, at most once \dots)
			\end{itemize}
		\item if multi-type, atomic connector compatibilities
	\end{itemize}


	\subsection{Configuration}
	\textbf{configuration} (topology) set of specific associations between components and connectors \\

	non-functional constraints:
	\begin{itemize}
		\item technical: technologies to use, usually non-negotiable
		\item business: design constraints for business reasons, usually non-negoitiable
		\item quality: quality attributes, usually for users
	\end{itemize}

	\subsection{Architecture Views}
	\textbf{logical view} 
	\begin{itemize}
		\item decompose the system structure into software components and connectors
		\item Map functionality/requirements/use cases onto the components
		\item concern: functionality
		\item audience: devs and users
	\end{itemize}
	\textbf{process view}
	\begin{itemize}
		\item model dynamic aspects of architecture
		\item describe how processes/threads communicate
		\item concern: functionality, performance
		\item audience: devs
	\end{itemize}
	\textbf{development view} 
	\begin{itemize}
		\item static organization of the software code artifacts
		\item mapping between the logical view and the code is also required
		\item concern: reuse, portability, build
		\item audience: devs
	\end{itemize}
	\textbf{physical view}
	\begin{itemize}
		\item define the hardware environment (hosts, networks, storage, etc.) where the software will be deployed
		\item mapping b/w logical and physical also necessary
		\item concern: performance, availability, scalability, reliability
		\item audience: dev ops
	\end{itemize}

	\subsection{Quality Attributes}
	\textbf{performance} how much work the application needs to do in a given time
	\begin{itemize}
		\item throughput: amount of work to do in unit time (transactions per second)
		\item response time: latency in processing a transaction (guaranteed vs average)
		\item deadlines: limited window to complete a transaction
	\end{itemize}

	\textbf{scalability} how well a solution works when a problem size increases, what can increase?
	\begin{itemize}
		\item request load (e.g. more users)
		\item simulataneous connections
		\item data size
		\item deployment
	\end{itemize}

	\textbf{modifiability} how easy it is to change the application for new funcitonality \\

	\textbf{security} understanding security requirements and devising mechanisms to support them, most commonly
	\begin{itemize}
		\item authentication
		\item authorization
		\item encryption
		\item integrity
		\item non-repudiation
	\end{itemize}

	\textbf{availability} proportion of required time a system is usable
	\begin{itemize}
		\item downtime is caused by failures in applications
		\item recoverability is close to availability
	\end{itemize}

	\textbf{integration} ease with which application can be incorporated into broader context (data integration, providing an API) \\

	\textbf{portability} how easily an application can be executed on different hardware/software than what it was developed for
	\begin{itemize}
		\item good portability comes from modularity
		\item will depend on libraries and platform choices
	\end{itemize}

	\textbf{testability} how easy is it to test an application
	\begin{itemize}
		\item more complex = more difficult to test
	\end{itemize}

	\textbf{supportability} how easy it is to support once deployed
	\begin{itemize}
		\item support involves diagnosing and fixing problems
		\item good supportability involves built-in facilities (e.g. in-depth logs)
	\end{itemize}

	\textbf{implementability} how easy it is to implement

	\section{Middleware Architectures}
	\subsection{Introduction}
	\textbf{middleware} connect software components so they can use exchange info with easy-to-use mechanisms, layer of software between application and OS
	\begin{itemize}
		\item location, service discovery, replication
		\item protocol handling, quality of service
		\item sync, concurrrency, storage
		\item access control, authentication
	\end{itemize}
	examples of offerings
	\begin{itemize}
		\item app updates
		\item messaging and notification services
		\item integration brokering 
		\item device detection 
		\item location API
		\item asset transcoding
		\item mobile analytics
		\item capacity offload
		\item app-level security
	\end{itemize}

	\subsection{Layers}
	Comes in four layers (from bottom):
	\begin{itemize}
		\item transport
		\item application servers
		\item message brokers
		\item business process orchestrators
	\end{itemize}

	\subsubsection{Transport}
	basic pipes
	\begin{itemize}
		\item sending requests and moving data
		\item making communication straightforward in distributed architectures
	\end{itemize}
	examples:
	\begin{itemize}
		\item message-oriented middleware
		\item distributed OS
		\item SOAP
	\end{itemize}

	\subsubsection{Application Server}
	on top of transport, provides:
	\begin{itemize}
		\item transaction
		\item security
		\item directory services
	\end{itemize}
	examples:
	\begin{itemize}
		\item .NET
		\item JEE
		\item CCM
	\end{itemize}

	\subsubsection{Message Brokers}
	on top of either application server or transport, provides message processing engine:
	\begin{itemize}
		\item fast message transformation
		\item features for defining how to exchange and manipulates route messages between components
	\end{itemize}
	examples:
	\begin{itemize}
		\item Mute
		\item WebSphere Message Broker
		\item SonicMQ
	\end{itemize}

	\subsubsection{Business Process Orchestrators}
	on top of message brokers, support workflow-style applications
	\begin{itemize}
		\item provide tools to describe business processes
		\item execute and manage intermediate states during execution
	\end{itemize}

	\section{Architectural Analysis}
	\subsection{Introduction}
	\textbf{architectural analysis} the activity of discovering important system properties using system's architectural models
	\begin{itemize}
		\item analyzing the architecture we have designed and modeled
	\end{itemize}

	\subsection{Goals}
	\textbf{completeness} (internal and external)
	\begin{itemize}
		\item external: fulfill system's requirements using correct notation
		\item internal: fully model all elements and properly capture all design decisions
	\end{itemize}
	\textbf{consistency} ensure that different model elements do not contradict each other (internal)
	\begin{itemize}
		\item name
		\item interface: consistent return values, paramters \dots
		\item behaviour: consistent behaviour of elements (e.g. 0-indexed or 1-indexed)
		\item interaction: consistent function calls on object (e.g. should still be able to call \texttt{remove} on empty queue)
		\item refinement: relationships must be maintained between high and lower level models (e.g. can't override lower level design decisions)
	\end{itemize}
	\textbf{compatibility} adheres to guidelines and constraints (external)
	\begin{itemize}
		\item the adopted style/styleguide
		\item reference architecture
		\item architectural standard
	\end{itemize}
	\textbf{correctness} architectural model fulfills system spec, and implementation fulfills model (external)
	\begin{itemize}
		\item \textit{fulfillment} is key to correctness
		\item account for non-functional elements, properties
	\end{itemize}

	\subsection{Cohesion/Coupling}
	Two extra goals
	\begin{description}
		\item[cohesion] whether components fit cleanly with minimal overlap and extras
		\item[coupling] whether components and connectors have excessive interaction
	\end{description}
	\begin{itemize}
		\item component/connector-level
			\begin{itemize}
				\item does each component and connector provide specific service correctly
				\item does the composition of components and connectors do this
			\end{itemize}
		\item subsystem/system-level: analyze compositions of components and connecttors to form subsystem, then complete system
			\begin{itemize}
				\item pairwise conformance of two interacting components in terms of interface
				\item over-all properties as sub-systems and system is built
			\end{itemize}
		\item data exchanged
			\begin{itemize}
				\item structure: data typing, organization
				\item flow through system: point-point, client-server \dots
				\item properties: performance, security, statefulness \dots
			\end{itemize}
		\item consistency at different abstraction levels
			\begin{itemize}
				\item refined models stay consistent with higher levels
			\end{itemize}
		\item comparison of architectures
			\begin{itemize}
				\item composition (of components and connectors)
				\item interactions (of components and connectors)
				\item characteristics of data exchange
			\end{itemize}
	\end{itemize}

	\subsection{Characteristics}
	We are interested in several ``key concerns''
	\begin{itemize}
		\item structural (static): connectivity of components
			\begin{itemize}
				\item lowel level components contained in higher level composite
				\item points of network distribution and concurrency paths
			\end{itemize}
		\item behavioral (static): individual component/connector functionalities
			\begin{itemize}
				\item composite and collaborative functionalities (especially w/ off the shelf components, connectors)
			\end{itemize}
		\item interaction (dynamic):  number and type of connectors and protocols
			\begin{itemize}
				\item timing 
				\item synchronicity
				\item buffering
			\end{itemize}
		\item non-functional (static/dynamic): properties across whole system
			\begin{itemize}
				\item security
				\item performance
				\item quality
			\end{itemize}
	\end{itemize}

	\subsection{Levels of Formality}
	level of formality in analysis requires levels of formality in models used
	\begin{itemize}
		\item informal (box-line) models
			\begin{itemize}
				\item high level analysis 
				\item performed manually with little automation
			\end{itemize}
		\item semi-formal models (e.g. UML)
			\begin{itemize}
				\item deeper level of analysis
				\item requires a little training 
				\item partial automation
			\end{itemize}
		\item formal models (e.g. Wright, Acme)
			\begin{itemize}
				\item very deep analysis
				\item requires good understanding of syntax + semantics used
				\item better automation
			\end{itemize}
	\end{itemize}

	\subsection{Types}
	\textbf{static analysis} without executing models
	\begin{itemize}
		\item structural concerns
	\end{itemize}
	\textbf{dynamic analysis} executing/simulating models
	\begin{itemize}
		\item behaviour
		\item interaction
		\item some non-functional properties
	\end{itemize}
	\textbf{scenario-driven analysis} asserting a property for entire system 
	\begin{itemize}
		\item can be static of dynamic
		\item very food for specific non-functional across whole system
	\end{itemize}
	
	\subsection{Technique Categories}
	\subsubsection{Inspection and Review}
	requires
	\begin{itemize}
		\item preparation for inspection
		\item preparation of participants
		\item review/analysis of architectural material
		\item anaysis of review results and recommended actions
		\item follow-up and closeout
	\end{itemize}
	\begin{itemize}
		\item Goals: completeness, consistency, correctness, and compatibility
		\item Scope: spans components, connectors and the complete system; also includes data-exchange and compatibility to reference architecture and compliance to standards
		\item Concerns: structural, behavioral, interaction and non-functional
		\item Types of models: mostly semi-formal
		\item Types of analysis: best for static analysis and scenario-based
		\item Automation: manual
		\item Stakeholders: all stakeholders may participate
	\end{itemize}

	\subsubsection{Model}
	uses system's architectural descriptions and manipulation of the model
	\begin{itemize}
		\item Goals: internal completeness, consistency, correctness
		\item Scope: spans components, connectors and the complete system; also includes data-exchange and compatibility to standards
		\item Concerns: mostly structural
		\item Types of models: mostly semi-formal to formal
		\item Types of analysis: best for static analysis of connectivity, interface \dots
		\item Automation: partially automated
		\item Stakeholders: technical stakeholders
	\end{itemize}

	\subsubsection{Simulation}
	software simultion of the architecture model
	\begin{itemize}
		\item Goals: completeness, consistency, correctness, and compatibility
		\item Scope: entire system, specific subsystem, data exchange
		\item Concerns: behavioral, interaction, non-functional
		\item Types of models: formal
		\item Types of analysis: dynamic, scenario-based
		\item Automation: mostly automated
		\item Stakeholders: all stakeholders may participate
	\end{itemize}

	\section{Architecture Design}
	\subsection{Frameworks}
	\begin{itemize}
		\item n-tier client server
			\begin{itemize}
				\item web clients $\rightarrow$ web server $\rightarrow$ application server $\rightarrow$ databases
			\end{itemize}
		\item messaging
			\begin{itemize}
				\item clients $\rightarrow$ queue $\rightarrow$ server
			\end{itemize}
		\item publish-subscribe
			\begin{itemize}
				\item publisher $\rightarrow$ topic $\rightarrow$ subscriber
			\end{itemize}
		\item broker
			\begin{itemize}
				\item senders $\rightarrow$ (inport) broker (outport) $\rightarrow$ reciever
			\end{itemize}
		\item process coordinator
			\begin{itemize}
				\item process request $\rightarrow$ process coordinator $\rightarrow$ result
					\begin{itemize}
						\item step 1 $\rightarrow$ server 1
						\item step 2 $\rightarrow$ server 2
						\item \dots
					\end{itemize}
			\end{itemize}
	\end{itemize}

	\subsection{Complex Frameworks}
	\subsubsection{C2}
	\textbf{C2} indirect invocation where independednt components communicate only through message routing connectors with rules
	\begin{itemize}
		\item no component-component links
		\item connector-connector links allowed
		\item requests go \textit{up} in architecture
		\item notifications flow \textit{down} in architecture
		\item no circularity
	\end{itemize}
	characteristics:
	\begin{itemize}
		\item state components in upper layers
		\item control logic in middle layers
		\item interface components in lower layers
	\end{itemize}

	\subsubsection{Distributed Objects}
	COBRA
	\begin{itemize}
		\item objects are all separate
		\item procedure calls only interface to objects
		\item adaptor interface between object and state
	\end{itemize}

	\subsection{Validation}
	increase the confidence that architecture is fit for purpose
	\begin{itemize}
		\item scenarios: come up with scenarios that test quality requirements
			\begin{itemize}
				\item choose the quality attribute (scalability)
				\item come up with a stimulus (user load doubles in 3 weeks)
				\item find response (server scaled to two clusters)
			\end{itemize}
		\item prototypes
			\begin{itemize}
				\item proof of concept: can the architecture satisfy requirements
				\item proof of technology: does the tech selected behave as expected
			\end{itemize}
	\end{itemize}

	\subsection{Finding a Design}
	\begin{itemize}
		\item analogy searching: examine other fields for ideas that are analagous to the problem
		\item brainstorming: rapidly generate many different ideas and thoughts
		\item literature searching: examine current state-of-art and read about subject
		\item morphological charts: identify all functions, means to do function, choose means that work
		\item removing mental blocks: change problem to one you can solve
		\item control design strategy: identify and review critical decisions
		\item insights from reqs: find improvements to exisiting systems from reqs
		\item insights from implementation: use constraints on implementation to narrow down
	\end{itemize}

	\section{Security and Trust}
	refer to CS458 notes

	\subsection{Security Models}
	\subsubsection{CCAC}
	\textbf{connector-centric architectural access control} safeguards resources based on the connections a requesting program has
	\begin{itemize}
		\item if no connections to resource, deny
		\item if direct connections to resource, allow
		\item else accumulate the safeguards needed to get from the requestor to object and check if the requestor has necessary priveleges
	\end{itemize}

	\subsection{Trust Management}
	\subsubsection{Overview}
	\begin{description}
		\item[trust] subjective probability that an agent will do something to affect your actions
		\item[reputation] expectation about entities behaviour
		\item[decentralized] no central authority to coordinate and control
		\item[trust management] how entities establish and maintain trust relationships
	\end{description}
	\begin{itemize}
		\item credential and policy-based
		\item reputation-based
	\end{itemize}
	\textbf{trust model} describes trust information and how it
	\begin{itemize}
		\item is used to establish trust
		\item is combined to determine trustworthiness
		\item is modified in response to experiences
	\end{itemize}
	\subsection{Threats}
	Ways decentralized systems can be attacked:
	\begin{itemize}
		\item impersonation
		\item fraudulent actions
		\item misrepresentation
		\item collusion 
		\item additions of unknowns
	\end{itemize}
	Ways to combat threats:
	\begin{itemize}
		\item authentication: combat impersonation and repudiation
		\item separation of internal and external data: resolve conflicts
		\item making trust visible: shouldn't be localized to one component
		\item comparable trust: should be able to measure it somehow
	\end{itemize}

	\subsection{Architectural Style}
	communication unit
	\begin{itemize}
		\item handles interactions with other entities
		\item no dependencies
	\end{itemize}
	information unit
	\begin{itemize}
		\item stores trust and app-specific info
		\item depends on interactions with entities to get info
	\end{itemize}
	trust unit
	\begin{itemize}
		\item computes trusworthiness and guides trust-related decisions
		\item depends on communication and information
	\end{itemize}
	application unit
	\begin{itemize}
		\item app-specific functionality
		\item enables local decision making
		\item builds on other three units
	\end{itemize}

	\subsection{PACE}
	\textbf{Practical Architectural approach for Composing Egocentric trust} a trust-centered architecture based off of C2
	\subsubsection{Communication Layer}
	\begin{itemize}
		\item multiple protocol handlers translate internal events into external messages and vice-versa
		\item communication manager creates and manages protocol handlers
		\item signature manager signs requests and verifies notifications
	\end{itemize}
	\subsubsection{Information Layer}
	separates internal beliefs of a peer from reported info of other peers
	\begin{itemize}
		\item internal info stores internal beliefs
		\item external info stores messages from others
	\end{itemize}
	\subsubsection{Trust Layer}
	incorporates different trust models and algorithms
	\begin{itemize}
		\item key manager generates unique public-private keys
		\item credential manager keeps track of peers identities
		\item trust manager requests public keys from peers and responds to revocations
	\end{itemize}
	\subsubsection{Application Layer}
	encapsulates user-interface and app-specific components
	\begin{itemize}
		\item application trust rules encapsulates chosen rules for assigning trust and supports trust relationships
	\end{itemize}

	\section{Design Patterns and Styles}
	\subsection{Architecture Styles}
	\begin{itemize}
		\item event-driven architecture
		\item pipes and filters
		\item multi-layered architecture
		\item p2p architecture
	\end{itemize}
	\url{https://cs.uwaterloo.ca/~rtholmes/teaching/2015winter/cs446/slides/SE2_09-10-11_arch-styles.pdf}
	\subsection{Design Patterns}
	\begin{itemize}
		\item observer
		\item composite
		\item facade
		\item command
		\item state
		\item strategy
		\item visitor
		\item decorator
		\item proxy
		\item mobile code
		\item interpreter
	\end{itemize}
	\url{https://cs.uwaterloo.ca/~rtholmes/teaching/2015winter/cs446/slides/SE2_17_design-patterns.pdf}





\end{document}