<###
- highly sequential - cannot progress to next stage without finishing the current
- advantages: it fixes requirements early, models like this SHOULD identify problems early in design process
- in reality, it kinda sucks. No one actually uses it
###Concurrent Engineering###
- like waterfall, but you start working on the next stage as soon as you have something to work with
- advantages: might need less documentation, projects need not be divided into smaller projects, testing could reveal problems earlier
- disadvantages: milestones aren't as clear, progress is difficult to track, poor communication can lead to disaster given parallel design stages
###[V-Model](http://upload.wikimedia.org/wikipedia/commons/e/e8/Systems_Engineering_Process_II.svg)###
- another variant of the waterfall model
- goal is to link between the early and late stages (e.g. Verification and validation link to requirements and architecture)
- very similar to waterfall, shares advantages and disadvantages
###[Spiral Model](http://upload.wikimedia.org/wikipedia/commons/e/ec/Spiral_model_%28Boehm,_1988%29.svg)###
- project is split into a number of smaller projects - go through the stages for that small project, then again, again, etc.
- risk-oriented - each sub-project addresses 1+ risks
- advantages: addresses biggest risks first, when changes are least expensive; progress is visible to customer + managements
- disadvantages: may not be possible to identify sub-projects
##Software Development Tactics##
###Scrum###
- work is broken down into a series of *sprints* (short cycles of a specified length, like 30 days)
- dev team reviews the items in the backlog at the beginning of the spring and sets goals
- daily meetings to keep on track during sprint
- advantages: short iterations - lots of opportunity for input and feedback; daily meetings = lots of co-ordination; encourages breaking software down into manageable units
- disadvantages: does not scale to large teams; daily meetings = excessive overhead; at the deadline, development ends whether the code is finished or not
###[Test-Driven Development](http://upload.wikimedia.org/wikipedia/commons/9/9c/Test-driven_development.PNG)###
- when adding a new feature, dev writes tests and then the feature is developed until the test passes
###Behaviour Driven Development###
###Extreme Programming###
###Kanban###
#L25: Refactoring#
- refactoring is the changing of code to improve code quality (making it easier to understanding) using local, semantics-preserving changes to the code
- **local:** refactoring should only change the parts of the program that you're re-factoring.
- **semantics-preserving:** the behaviour of the refactored code should be identical to the behaviour of the original code
##Types of Refactoring##
- **composing methods:** change what code belongs to which method
- **moving features between objects:** put fields, methods, classes in different places
- **organizing data:** change how data is stored
- **simplifying conditionals:** make your ```if``` statements easier to understand
- **making method calls simpler:** change how methods relate to each other
- **generalizations:** similar to moving features, but related to the inheritance hierarchy
##Refactoring Algorithm##
1. Create unit tests (if needed)
2. Run unit tests
3. Make changes
4. Re-run unit tests
5. Evaluate results
##Lists of Refactoring##
- techniques that allow for more abstraction:
- **encapsulate field:** force code to access field with getter and setter methods
- **generalize type:** create more general types to allow for more code sharing
- **replace conditional with polymorphism:** use inheritance and virtual dispatch instead of a conditional
- techniques for breaking code apart into more logical pieces
- **extract method:** pull out part of a larger method into a new method
- **extract class:** moves code from existing class into a new class
- **extract variable**
- **extract magic constant**
- techniques for integrating code that's needlessly spread apart:
- **inline method:** integrate a copy of the body of a method into its calling method
- **inline class:** put all of the fields and methods of a class into another class and erase the original
- techniques for improving names and location of code
- **move method/field:** move to a more appropriate class or source file
- **rename method/field:** change to a name that better reveals its purpose
- **pull up:** in OOP, move to a superclass
- **push down:** in OOP, move to a subclass
##Design Antipatterns##
###The Blob###
- has too much of the code and logic in one class
- solution: extract methods and classes so that responsibilities are properly distributed
###Lava Flow###
- dead code that is useless, but no one wants to remove because they're afraid of breaking something
- solution: remove. Test with unit tests that nothing broke. If something did, revert back
###Functional Decomposition###
- this happens when non-OOP devs design and implement an application in OOP
- can be very complex because the devs will devise "clever" ways of replicating their methods in an OOP architecture
- solution: extract classes, merge duplicate code, create methods such that there is defined structure
###Copy-and-Paste Programming###
- code reused by copy and pasting leads to maintenance problems
- could have duplicate methods
- solution: extract common elements and make them generic
###Poltergeists###
- classes with very limited roles and effective life cycles, aka objects that pop in, do one thing, then vanish
- solution: inlining their functionality into other objects
###Golden Hammer###
- when people try to shoe-horn a specific architecture as the solution to everything
- solution: refactor the code to a more appropriate architecture or design
###Exceptions as Control Flow##
- exceptions should not be part of the normal flow of the program
- solution: instead of ```try-catch``` block where the catch block does something, refactor so the condition is checked in advance
###Spaghetti Code###
- program that contains little or no structure
- solution: all refactoring techniques, until some structure is formed
#L26: Interval & Watchdog Timers#
##Timers##
- used to perform a task occasionally or reset a system that's stuck
###Interval Timers###
- appropriate for recurring timers
- can use ```Handler``` to implement interval timers:
```
Handler h = new Handler();
Runnable r = new Runnable() {
public void run() {
//execute the task
h.postDelayed(this, delayInMS);
};
h.postDelayed(r, delayInMS);
```
- then you can cancel an upcoming task like so: ```h.removeCallbacks(r);```
###True Interval Timer
- ```Handler``` isn't a **true** interval timer, because it doesn't interrupt the processor should
- can simulate an interval timer more closely with the ```Timer``` class, which runs in a different thread
- however, other threads can't do updates to the UI
```
Timer t = new Timer();
t.schedule(new TimerTask() {
@Override
public void run() {
runOnUiThread(timerTick);
}
}, firstDelayMS, repeatIntervalMS);
Runnable timerTick = new Runnable() {
@Override
public void run() {
Toast.makeText(getApplicationContext(), "ding!", Toast.LENGTH_SHORT).show();
}
};
```
###Watchdog Timers###
- watchdog timers can observe that a system appears to be stuck and take some action
- after setting up a watchdog timer, the system needs to indicate before the limit of the timer, that everything is okay (at which point the timer is reset)
####Implementing Watchdogs with Interval Timers####
- set the timer interval to be the largest allowable time for task to take. Start timer
- if the timer fires, the tasks took too long
- timer event handler should execute, so it can deal with the situation (for instance, by killing the task)
#L27: Verification & Validation; SW Maintenance#
- **verification:** assume a set of requirements and establish that the product satisfies the requirements
- forms: testing, static analysis (computers pore over the code or design)
- **validation:** making sure the requirements are the right ones
- forms: beta testing
##Formal Methods##
- a bunch of techniques for verifying that code conforms to a specification (aka, code performs the way you want it to be)
##Software Maintenance##
- **corrective maintenance:** correct known defects
- **adaptive maintenance:** keep a software product usable in a changing environment
- **perfective maintenance:** improve performance or maintainability
- **preventive maintenance:** correct faults in the program before they manifest
#L28: Simulation#
##Why Simulate?##
- system may not exist yet (e.g. proposed plane design)
- system may be costly to use
- system may be dangerous to use (dangerous to make a mistake on)
- system may be disrupted by use
- don't have enough access to system
##Simulation Models##
###Continuous vs Discrete Simulation##
- continuous models represent a system with continuously changing state variables
- might be used to simulate an analog circuit
- digital models represent a system with discrete state changes
- might be used to simulate a digital circuit
###Dynamic vs Static Simulation###
- dynamic models represent a system as it evolves over time; recomputes state of system
- static models represent a system at one point - you feed it some conditions and it tells you the result
- useful for what-if simulations ("If I sell these at $4, how many will I sell?")
###Deterministic vs Stochastic Simulation###
- deterministic models exactly computers the simulated state of the system at every step
- subject to inaccuracies in the calculations
- stochastic models use randomness to estimate the expected behaviour without computing the behaviour of each particle
- relies on the underlying randomness of the system components
#L29: Software Statistics#
- if you want to study this topic, do it on your own. I'm not writing notes for it.
#L30: Software Bricolage; Licenses#
##Software Bricolage##
- in the real world, you pretty much never have to *actually* start a project from scratch.
- given a goal to accomplish, follow these steps:
1. **Forage**
- look for software that does what you want
- software may be in a number of different languages
- if what you found adequately meets your needs, wooo, you're done
2. **Tinker**
- figure out what the software actually does, experiment with it, modify it
- if what you have isn't what you need, repeat between steps 1 and 2
3. **Weld**
- combine the pieces you've foraged
- potential real-world problems
- missing and conflicting dependencies
- impedance mismatches (Software A produces output in XML, software B requires input in CSV. Must be bridged)
4. **Grow**
- start to actually build the code you need
5. **Doubt**
- avoid re-inventing the wheel
- be familiar with what's in the libraries; ask authors of libs
6. **Refactor**
- clean up your code and make it more general
- improve interactions between your code and the outside code
##Software Licenses##
- software licenses tell you how a piece of software can be used or distributed
###Types of Licenses###
- **Proprietary Licenses:**
- They're all different. The rights you have are specifically defined; that's all you have.
- **GPL (GNU General Public License):**
- open source software license; a copyleft example of copyright law
- ensures that code can be used, copied, modified and redistributed freely
- can't use this code in propertiary programs -> all changes made must be licensed under GPL or a compatible license
- **LGPL (Lesser GPL):**
- intended for software libraries
- the code (once compiled) can be linked to a propertiary program without having to re-license the program
- the library code itself, must follow restrictions as if it were GPL
- **BSD:**
- open source license, very permissive
- effectively allows any use of the code, but disclaims liability
- **Mozilla License:**
- open source license from Mozilla Group
- allows for "mixed" source code - any file license directly under the Mozilla license must be available in source form, but not all files in a program must be licensed under the Mozilla license
- **Public Domain:**
- no copyright owner, can be used by anyone for anything
#L31: Android IV#
##Networking##
###Performing Networking Operations###
- need these permissions to do any networking:
```
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
```
- to check if user is connected to a network:
```
ConnectivityManager connMgr = (ConnectivityManager)
getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo networkInfo = connMgr.getActiveNetworkInfo();
if (networkInfo != null && networkInfo.isConnected()) {
... // Do useful work
}
```
- since networks are unstable and can take a long time, should not perform network operations on main thread; instead, use a background task (class: ```ASyncTask```)
- here is an example of a defined ```ASyncTask```:
```
private class DownloadWebpageTask extends AsyncTask<String, Void, String> {
@Override
protected String doInBackground(String... urls) {
// params comes from the execute() call: params[0] is the url.
try {
return downloadUrl(urls[0]);
} catch (IOException e) {
return "Unable to retrieve web page. URL may be invalid.";
}
}
// onPostExecute displays the results of the AsyncTask.
@Override
protected void onPostExecute(String result) {
textView.setText(result);
}
}
```
- when an asynchronous task is executed, it goes through 4 steps:
1. ```onPreExecute()```, invoked on UI thread before task is executed. Normally used to set-up the tasks (e.g. show a progress bar in the UI); optional
2. ```doInBackground(Params...)```, invoked in background thread after ```onPreExecute()```; used to perform background computation. Result of computation must be returned by this step and will be passed back to the last step; step can also use ```publishProgress(Progress...)``` to publish 1++ units of progress on UI thread
3. ```onProgressUpdate(Process...)```, invoked on the UI thread after a call to ```publishProgress(Process...)```. Used to display any form of progress in UI; optional
4. ```onPostExecute(Result)```, invoked on UI thread after the background computation finishes
- to cancel a task, you can call ```cancel(boolean)```, which makes ```isCancelled()``` return true; ```doInBackground``` should check to see if task has been cancelled (and then stop doing its thing)
- after task is cancelled, ```onCancelled``` is called instead of ```onPostExecute```
###Actually Downloading a Page###
```
// Given a URL, establishes an HttpUrlConnection and retrieves
// the web page content as a InputStream, which it returns as
// a string.
private String downloadUrl(String myurl) throws IOException {
InputStream is = null;
// Only display the first 500 characters of the retrieved
// web page content.
int len = 500;
try {
URL url = new URL(myurl);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setReadTimeout(10000 /* milliseconds */);
conn.setConnectTimeout(15000 /* milliseconds */);
conn.setRequestMethod("GET");
conn.setDoInput(true);
// Starts the query
conn.connect();
int response = conn.getResponseCode();
Log.d(DEBUG_TAG, "The response is: " + response);
is = conn.getInputStream();
// Convert the InputStream into a string
String contentAsString = readIt(is, len);
return contentAsString;
// Makes sure that the InputStream is closed after the app is
// finished using it.
} finally {
if (is != null) {
is.close();
}
}
}
// Reads an InputStream and converts it to a String.
public String readIt(InputStream stream, int len) throws IOException, UnsupportedEncodingException {
Reader reader = null;
reader = new InputStreamReader(stream, "UTF-8");
char[] buffer = new char[len];
reader.read(buffer);
return new String(buffer);
}
```
###Cloud Sync and Merge Conflicts###
- can sync you app with the cloud so user data is not lost; Google provides an API for small amounts of data for storing user preferences, high scores, notes, etc.
- I'm not going to show the code for using it - you might want to check out the lectures notes for that
- it's possible that you can end up with sync conflicts (user has 2+ devices, >1 of them try to save data to cloud)
- some simple solutions to follow:
- Newer is better: In this case, choose to store the timestamp in the cloud save data
- Value Judgement: Choose based on what is defined as "best" (e.g if saving high scores, keep the highest score)
- Merge: Merge by union (e.g. if data represents set of levels unlocked, resolved data is the union of the two conflicting sets)
#L32: Software Architecture Patterns#
##Software Architecture##
- general, re-usable solution on structuring a piece of software
- all pieces of software contain:
- logic: the software does some work
- data: stores and/or retrieves data
- UI: presents and accepts info/commands
##The Monolith##
- application in which all elements are combined into a single, self-contained program
- no defined modules, no components, no clear lines between different parts of the program
- simple to understand, faster to write - but difficult to maintain
- things become interconnected and can become difficult or impossible to change
##Client-Server Architecture##
- two roles in the system - client and server - and they communicate with a request-response message pattern
- client sends a request to the server, server sends a response back
- server: logic and data elements; client: UI
##Three-Tier Architecture##
- similar to client-server but UI, logic and data are all separate
- *presentation tier:* top-most level; UI
- *logic tier:* co-ordinates application, processes commands, makes logical decisions and evaluations, perform calculations, etc. Also moves data between the two surrounding layers
- *data tier:* information is stored and retrieved from a database or file system
- it is possible for logic tier to be further divided (n-tier architecture)
- note: client-server interaction could exist between any two adjacent tiers in the system
##Model-View-Controller Architecture##
- divides the software application into three different parts - Model, View, and Controller
- **Model:** holds represent knowledge (e.g. an object, or structure of objects), and the methods/functions; tells the view and controller if object has been updated
- **View:** a representation of the model; can have multiple views
- **Controller:** accepts input and converts it into commands for the model or view
- [a representation of MVC control flow](http://upload.wikimedia.org/wikipedia/commons/a/a0/MVC-Process.svg)
##Modular Architecture##
- the tiers, or the client and server, might be too complicated to build in a monolith
- instead of having one monolith "server" program, you might create it out of separate modules that are responsible for different aspects of the server work
- that way, modules may be replaced or upgraded independently of others
#L33: Software Communication Patterns#
- looking at the architecture of communication within programs
##Pipes and Filters Architecture##
- **pipe:** takes input, performs action on the data, and outputs the result
- can transform data
- **filter:** takes input, and will either accept it (appear in the output) or reject it (no output appears)
- read-only: do not change data
- various pipes and filters can be combined to form a *pipeline*
##Blackboard Architecture##
- has a common knowledge base and set of agents who work on the base
- **Software Agents/Knowledge Sources:** the agents of the system
- **Blackboard:** the shared repository of problems and partial solutions; the input and outputs from the agent
- **Moderator:** controls the flow of access to the system so agents do not interfere with each other
- not applicable to a lot of problems, but can be used to solve problems that would otherwise not be solvable
##Publish-Subscribe Architecture##
- communication takes place by passing messages
- **Publisher:** sender of a message; does not know who the receivers are
- **Subscribers:** receivers; register their interest in certain kinds of messages without knowledge of any publishers
- **Brokers:** (optional) connects the publishers and subscribers indirectly; publisher can publish the message here so the subscribers can collect it at their convenience
- filtering messages:
- **Topic-Based:** have a list of topics, publishers write in these topics, subscribers listen to that channel
- e.g. I create an ECE 155 channel, and I id that a message is intended for that channel
- **Content-Based:** messages are delivered to a subscriber if the content matches what they're looking for
- e.g. a subscriber might get sent all messages containing the text "ECE 155"
##Peer-to-Peer Architecture##
- the different nodes (computers or programs) in the network both supply and receive resources
- major advantage is that their ability to serve content increases as more requests come in
#L34: Security#
##Properties of Embedded Systems##
- **Physical Access:** a lot of security measures are easily defeated given physical access to a device; many embedded systems are, well, embedded in the world and not kept under security
- contrast an ATM to a server
- **Limited Resources:** embedded devices have limited processing power to spend on running security checks
- **Hard to Update:** may be difficult or impossible to update an embedded system to patch a security vulnerability
- **Connectivity:** lots of embedded devices are connected (to the internet or other systems), which provides a gateway for attack
##Attacks on Embedded Systems##
- **Physical Tampering:** a user with physical access to the device could open it up and read data, attach listening devices, etc.
- **Denial-of-Service Attack:** system is flooded with requests that overwhelm its ability to respond
- can take the form of an *exhaustion attack*, where the attacker causes the system to run its battery down faster
- **Sensor Tampering:** damaging or disabling the sensors to bypass the system (e.g. feeding in false input, or smashing a camera)
##Countermeasures##
- **Encryption:** encrypt all sensitive data so attackers can't read it, even if they have access to the device
- **Defeating DOS Attacks:** defeat to defend all kinds of attacks, but can be mitigated
- limit the rate at which requests are entered (e.g. can only send x messages in n seconds)
- **Monitoring:** might have secondary software processes to check on the health and status of the system, and its sensors/actuators
###Encryption and Salting###
- given a RSA encryption system, it can be detected when the same message is sent twice
- solution: randomize every instance of encryption with an additional message (Initialization Vector) that can be passed along in plaintext
- example: password salting
- in old UNIX systems, usernames and hashed passwords were stored in ```/etc/passwd```; if two users had the same password, you could tell
- now, they add and display a "salt" (a randomly generated string, unique to each user), which is added to the password when it is hashed
- so if my password was butts123, and my salt was q3j4oi329nfd, the input to the encryption function would be "butts123q3j4oi329nfd"
##Authentication vs Authorization##
- **Authentication:** verifies who the user is; can be done with un/pw, fingerprint scan, key card, etc.
- **Authorization:** verifies what the user is allowed to do
##Access Control##
- operating systems control access to files as part of the file system
###Unix-Style Permissions###
- every file has an owner, and a group
- separate permissions can be set for the owner, the group, and others
- 3 basic permissions: read, write, execute
- permissions represents using 10 bits:
- 1 directory bit - set if the file is actually a directory
- 3 bits for owner permissions - read, write, execute (each bit set to 1 if that action is allowed)
- 3 bits for group permissions
- 3 bits for others permissions
- permissions can be displayed as 10 characters, where r=read, w=write, x=execute, and - = permission, and d= directory
- example: -rwxrw-r--
- it's a file; owner can read-write-execute; group can read-write, others can read
- can also be displayed as a 3-bit octal number, where r=4, w=2, x=1; add the values of the permissions granted
- example: 752
- owner can rwx, group can rx, others can r
###Access Control Lists###
- in SELinux (Security Enhanced Linux) and NTFS (Windows NT File Systems), files are protected by access control lists
- each file can have as many security descriptors as we like, which specifies the permissions a specific user or group can have
- permissions are not limited to rwx
###Role-Based Access Control###
- in RBAC, a set of roles is created, users are assigned roles, and access is granted or denied based on the roles a user has
- assignment is simpler: if there are many files that should only be accessed by sysadmin, easier to add a new user to the sysadmin role than to explicitly add that user to each file's ACL
- can also have relation between roles (e.g. Engineer may have all the permissions as Technicians, and more, therefore set up the system so that the engineer role subsumes the technician role)
##Malicious Software##
- **Viruses:** propagates by inserting itself into and becoming part of another program; often attached to executables
- **Worms:** like viruses in that they spread copies and can do damage, but need no hosts - it's a standalone piece of software; exploit a vulnerability of the system and spread on its own
- **Trojans:** users are tricked into installing it in their system; usually consist of client and server (victim installs server, attackers controls remotely with client)
#L35: Library Card#
]]>