CSC302 notes

## CSC302 Notes

### Challenges in Software

* Software engineering is important because it is increasingly becoming apart of every system
* projects are either...
	* Successful (37%)
	* Canceled (21%)
	* too late or over budget (42%)

### Differences in real time systems vs embedded systems

* Realtime systems
	* timing is very important and usually the system is pointless if it cannot get timing right, eg. unix scheduler

* Embedded system
	* A software system where its main purpose is not computations, example: mp3 player, digital watch. 90% of embedded systems have real-time system attributes in them

### Software failing

* classic example is the Arirane 5 which cost billions of dollars to fun and countless man hours to construct. Self-destructed after 37 seconds.
* cause: overflow exception when converting from a 64 bit floating point value to a 16 bit signed integer.
* what can we learn from this? Essentially that testing should be taken seriously and that the person giving you the specifications for the job needs to know every use case and scenario.

###Software requirements

* Software is designed for a purpose
	* if it doesnt work well then either...
		* the designer didnt have adequate understanding of purpose
		* we are using the software for a purpose different from the intended one
* **requirements analysis is about identifying this purpose**
* ![pic](http://i.imgur.com/dJg2Paz.png)
* problems in software are insane usually
	* no definitive solution to any problem
* Definitions
	* Abstraction
		* ignore finer details, think OOP object definition
	* Decomposition
		* partition a problem to study independently
	* Projection
		* essentially views in MVC, how do we view the data and in what parts
	* Modularization
		* split up the working pieces to localize change, do not make everything dependant on one another
* Examples of soft systems
	* generic software components
		* network services, core operating system functions
	* control systems
		* determined by physical processes to be controller, example being an aircraft flight control unit
	* information systems
		* automation is a good example, cannot be decoupled usually with the systems that they support, business support or web services are good examples

### Testing

* finding a requirements error in testing is 100x worse than finding a programming error in testing
* ![image](http://i.imgur.com/PnPt6bx.png)
* requirements analysis job
	* Need to identify
		* boundaries: problems to be solved
		* context: problem space
		* stakeholders: whose problem is it
		* goals: why 
		* scenarios: how will this software help
		* constraints: why 
		* risk: what are the things holding us back

### Modeling and advanced UML

#### UML

* kind of have to look at the slides for this part of the notes, lots of pictures and such

##### How do we get started on a project?

* We reverse engineer it!
* Find out the...
	* Structure of the code
		* Architecture and such
	* Behaviour of the code
		* Think state machine models
	* Function of the code
		* What exact functions does this let the user to?

##### Modeling notations (probably should know these)

* UML class diagrams(important)
* Use cases
	* Sort of like sequence diagrams but more of an overall picture
* UML Package diagrams
	* dependency modeling
* UML Statecharts
	* sort of like state-machines but for the entire program, used to fix deadlock
* UML sequence diagrams(important)
	* research what this looks like for real on the interwebs
	* ![a nice image](http://i.imgur.com/rOGhdvS.png)	
	* models on the x axis
	* time and exchange of data is represented going down the Y axis
	* when to use them
		* comparing design options
		* assessing bottlenecks
		* elaborating use cases

* Activity diagrams
	* higher lvl view of state-machine graphs

* An important photo...
	* ![image3](http://i.imgur.com/agiFITC.png)

* multiplicities on the lines between UML are very similar to ER diagrams from databases

##### Classes

* We use classes to group objects with...
	* similar properties
	* common behaviour
	* common relationships
	* common meaning

* Important reminder: Subclasses can override attributes and functions

* things to remember when writing down a full class object in UML
	* name of the class
	* visibility of var and functions
	* name of var and function
	* type or var
	* maybe a default value of var
	* multiplicity of var
	* parameters of funct
	* return value of funct

* composition
	* a class absolutely needs one of these
	* cannot live without it, example, car needs an engine, train needs a locomotive
* aggregation
	* these are model relationships that are okay with not being coupled together all of the time
	* example, car wants a person, trains wants a person
* these are just two of the many types of relationships two objects can have in UML
* If you took db you know all about multiplicities
* ![image2](http://i.imgur.com/luGggWK.png)
* make up some basic UML's with interfaces and classes and such(previous exams)

## More requirements analysis

### key distinctions

* requirements
* functions
* use cases
* domain concepts

* know the difference between an application domain and software domain, and the shared things in between them

##### application domain vs software domain

* Software domain
	* function and other random things private to software(computer specific)
* application domain
	* things our software cannot observe directly, example being gravity(real world)
* shared phenomena
	* stuff that can be shared between them, for example: touch sensors, processor load, etc


## Software Architecture

* Good architecture
	* minimizes coupling
		* dont need to know much about each other to interact
		* makes future changes easier
	* maximizes cohesion
		* contents of each modular are strongly inter-related 

* A good example of a reduced coupled system is the client-server model, servers do not need to know about how the clients interpret the data, just how to send the data out

* Example of a three layered architecture is essentially MVC, presentation layer, application logic and the storage layer

* UML packages
	* lots of different notations
	* some examples of package notation: ![image5](http://i.imgur.com/mSUhi9U.png)

* component design is also possible with packages
	* ![image6](http://i.imgur.com/AnIO8QU.png)

* Avoid dependency cycles when possible, for example: client & server 

* Layered systems
	* increase the level of abstraction as you go
	* can get complicated very fast

* open vs closed layers
	* closed layer
		* each layer uses a layer below it
* reduces impact of change, things aren’t getting thrown in every direction
* open layer
* still uses lower layers but any lower layer
does NOT minimize dependency injection

* 4 layered systems
* a layered system not mentioned yet is one that has the presentation layer -> application logic -> domain entities -> database
* essentially bunch of different domains that contain their own presentation layer and application logic but are using a shared database

* pipe and filter
	* we saw this with UNIX shell commands
	* signal processing

### Eclipse

* just read the slides LOL
* Eclipse is an integrated development environment (IDE). It contains a base workspace and an extensible plug-in system for customizing the environment. Written mostly in Java, Eclipse can be used to develop applications. 
* ![image 523873](http://i.imgur.com/2B1U84J.png)

SOLID:
						
* Single responsibility principle:
	* responsibility should be entirely encapsulated by the class

* Open/closed principle
	* open for extension, closed for modification
						
* Liskov substitution principle 
	* subtypes should be able to be substituted where the superclass is suppose to be

* Interface segregation principle
* Have objects/functions only depend on small, very specific interfaces, nothing too encompassing 
						
* Dependency inversion principle			
	* introduce abstraction layers between dependency layers if interactions become complex

#### Program types
* S-type programs
	* really formal type of problem, example: can you sort this list?
	* doesnt really define all too much, so basically a fucking shitty program

* P-type programs
	* Not super specific problems, relates more to a real world problem
	* evolves and stuff

* E-type programs
	* embedded, which means it becomes part of the world that it models
### Some software process things

* Waterfall model
	* very set in its ways
	* everything is done in steps
* xp

![image7263](http://i.imgur.com/29xU8J0.png)

* scrum
	* sprints, daily scrum, scrum teams

## Software Design Patterns

### Gang of Four

#### Four Developers wrote a highly influential book about the capabilities and the pitfalls of object oriented programming and the 23 software design patterns.

* Enrich Gamma
* Richard Helm
* Ralph Johnson
* John Vissides

### 23 Software Design Patterns

#### There are 3 different types of patterns. (B) Behavioral, (S) Structural, (C) Creational

Memento(B) 
		Gives the ability to restore an object to a previous state (undo)
Has 3 objects, caretaker, originator, memento
The idea:
Caretaker asks originator for memento object
Changes happen
To rollback, return memento object	


Observer(B)
The purpose of the observer pattern is to allow an object, called the "subject," that can change state to notify one or more other objects, called "observers," when it changes state.
example: A chat client might notify observers when a new message arrives
Needs an Observer <<Interface>>
Two main functions are notify() and update()

Chain of Responsibility(B)
Promotes idea of loose coupling by delegating commands to a chain of processing objects
example: A good example of this is an email filter, spam-filter, and urgent-filter.
Needs a Handler <<Interface>>
Idea:
Have many different functions that change an object, each doing one small task
Have object pass through many different functions to do one large task

Command(B)
Creates objects which encapsulates actions and parameters
The purpose of the command pattern is to define a set of functionality that can be executed at a later time.
Example: game that contains a game board, commands for moving up and down the game board, and a game that drives everything
Main function: execute()
Components: 
Client: The client is responsible for creating the command and initializing it with all of the information that it needs to be invoked.
Invoker: The invoker is responsible for determining when a command should be executed, such as in a response to a button being pressed or a menu item being selected.
Receiver: The receiver is an instance of the class that receives the action of the command.
		
State(B)
Sometimes your application can exist in one or more states and an action that is performed in your application will have a different impact depending on the state it is currently in. The state pattern identifies this need and provides an elegant solution for changing the behavior of your application depending on its current state.
example: a car and an acceleration state, which controls how quickly a car accelerates, as well as a driver test class.
Main functions: request() and handle()
Needs a state <<Interface>>
Components:
State: an interface or abstract base class that defines the action(s) that the application can perform when in different states
Concrete States: concrete implementations of the State interface or abstract base class that perform specific behaviors for a specific state
Context: contains a reference to the current state and delegates action requests to the concrete state implementation (accessed through the State interface or abstract base class using polymorphism)


Interpreter(B)
Specifies how to evaluate sentences in a language
idea:
have a class for each symbol

Strategy(B)
The strategy pattern provides a solution for problems in which you want to choose between different algorithms that solve the same problem.
Example: choosing a specific sorting algorithm based on the size or nature of the data to be sorted
Main Function: execute()
Needs a strategy <<Interface>>
Components:
The strategy: is an interface that defines the functionality to be performed. For example, the strategy might define a method called sort() or sendFile()
The concrete strategies: provide different implementations of the strategy. For example, there might be a BubbleSortStrategy and a QuickSortStrategy: both sort data, but using different algorithms
The context: is a class that contains a concrete strategy, referenced through its strategy interface. There might be a context that contains the bubble sort strategy and a context that contains the quick sort strategy.
The client: is a class in your application that invokes the strategy through the context class

Iterator(B)
Provide a way to access elements of an aggregate object sequentially without exposing its underlying representation
Example: a book collection, a library, and a book iterator that returns books from any book collection
Main functions: createIter() and next()
Needs aggregate <<Interface>> and iterator <<Interface>>
Components:
Aggregate: this is a base class or an interface implemented by the ConcreteAggregate and defines a mechanism for obtaining an iterator. In Java terms, the Collection class is an example of an aggregate: it is an interface that all collection classes must implement that defines the iterator() method from which you can obtain an iterator
ConcreteAggregate: this is a class that either extends the Aggregate (if it is a class) or implements it (if it is an interface.) In Java, examples of concrete aggregates are ArrayList, HashMap, and TreeSet.
Iterator: an interface or base class that defines iteration methods. Java defines an Iterator interface that concrete iterators implement.
ConcreteIterator: classes that implement the Iterator methods and provide a mechanism for clients to traverse over the concrete aggregates members
Client: a consumer of a concrete aggregates members through an iterator interface.

Template Method(B)
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Redefine the steps in an algorithm without changing the algorithm's structure. Just like a “boiler plate.”
Example: execute a JDBC query against a database
Is Java’s Abstract Class

Mediator(B)
Defines how objects interact
Example: Airplanes communicate with the tower rather than with one another — the tower becomes the mediator.
Idea:
Create a mediator object
Mediator object interacts with 2 or more other objects
Only mediator object is allowed to interact with other objects

Visitor(B)
Follows open/close principle
Separates Object from algorithm, ability to add new operations without modifying the structure
Example: 
Idea:
Object accepts visitor object
Visitor object then take object and applies method to it

Adapter(S)
Allows interface of existing class to be used in another interface
Example: a Car class that will know how to work with different engines by invoking methods such as start(), stop(), accelerate(), and decelerate()
Idea:
Wraps object in an adapter object
Converts the object’s interface to one expected by another interface

Proxy(S)
A wrapper class functioning as an interface to something else, it acts as a placeholder for another object to control access to it.
Example: The idea of a distributed programming is not that your application should find a remote service, open a channel to that service, and invoke its functionality, but rather it should interact with a local object that handles all of the remoting details for it(a proxy).
Idea:
Wraps an object in a proxy object
Any interface to the object, proxy handles first
After handle, passes to wrapped object

Bridge(S)
Decouples abstraction from its implementation, so they can vary independently
Used when classes varies often
Example: a set of Animal objects and a set of feeding objects. The animals eat, but they eat differently. The feeding objects are used by animals to eat their food, but they perform differently.
Idea:
Split object into an implementor and Abstraction
The abstraction calls functions from implementer using the adapter pattern


Composite(S)
Partitioning design pattern, a group of objects to be treated as single instance object
Used when using multiple objects in the same way
Example: a drawing of a car, you might have components named tires, doors, and body and rather than draw an individual tire, door, or body, you draw the car and it in turn draws the tires, doors, and body. Furthermore, the class hierarchy is defined as such that a car is a drawable object, as are tires, doors, and bodies, so your code that draws individual objects can just as easily draw “composite” objects.
Idea:
Create composite object
Add objects to composite object
methods are used on all the objects in the composite object

Decorator(S)
Allows adding behavior without affecting behaviors of other objects of same class
Example:  a MathOperation interface that exposes a single method: execute(), that accepts a variable number or arguments. From the MathOperation I derived two implementations: AddOperation and MultiplyOperation. I then created aMathOperationDecorator abstract class that serves as the base class for all decorators, and two decorator implementation classes: LoggingDecorator and PerformanceDecorator. TheLoggingDecorator prints the name of the MathOperation class, its arguments, and its results to the standard output device and the PerformanceDecorator records the amount of time the operation takes to execute and prints that to the standard output device.
Idea:
Wrap object in decorator

Facade(S)
An object that provides simplified interface to a larger body of code
Very similar to API
Example: a BookFacade class that exposes a business method, findByAuthor(), that abstracts the application from the underlying data persistence strategy.
Idea:
An object that takes an existing interface and creates simplified versions of essential methods
`The Facade JSON API which will change the world.`

Flyweight(S)
Minimizes memory by sharing as many data with similar objects as possible
Example: If a query returns 100 books and there are 100 users executing the query then there will be 10,000 books in memory.With the FlyWeight pattern if the query returns 100 books and 100 users execute the query there are only 100 books kept in memory because they are cached. 
Idea:
Create glyph object that maps to objects
All objects are that are mapped by the glyph have the same attribute

Builder(C)
The builder design pattern delegates the construction of an object to a builder class that, depending on the input, constructs an object on your application’s behalf. The object is assembled by a “director” that executes methods on a specific builder type.
Example: if the image is a JPEG then the JPEG reader is returned, but if the image is a GIF then the GIF reader is returned.
Requires a Builder <<Interface>>
main functions is build()


Factory Method(C)
In Factory pattern, we create object without exposing the creation logic to the client and refer to newly created object using a common interface.
Example: Sometimes you will define your factory method to only create a specific implementation of the interface, such as when combined with the DAO pattern: it returns a DAO implementation for the currently configured database. Your application uses the factory method pattern so that the implementation class can be changed by a runtime configuration change
Idea:
Create interface
Create classes implementing interface
Create a factory based on classes/interface (parameter could be a string defining the type of object for instance)
Get object by creating the factory and calling get `getObject(String param)` function for instance

Abstract Factory(C)
Abstract Factory patterns work around a super-factory which creates other factories.
Example: When using the factory pattern, a class calls a factory method to create a class instance that implements a specific interface. In this example, the DBDAO interface presumably contains methods for interacting with a database and the MySQLDBDAOImpl and OracleDBDAOImpl classes provide specific implementations of that interface for interacting with MySQL and Oracle, respectively.
Idea:
Create interfaces
Create classes implementing interfaces
Create a factory based on classes/interface (parameter could be a string defining the type of object for instance)
do this for all classes
Create a factory which produces these factories
Get object by creating the factory of factories, produce a specific factory and calling get `getObject(String param)` function for instance


Prototype(C)
The primary difference between the prototype and builder patterns is in their implementation details: while the builder pattern creates an object and configures it at runtime, the prototype clones an existing object and changes its behavior at runtime. The core notion behind the prototype pattern is modifying an existing object at runtime.
Example: a video game that contains various types of monsters. It uses the prototype pattern as a solution for creating specific types of monsters depending on the terrain. For example, a flying monster might not do so well in the water.
Requires prototype <<Interface>>
Main function Clone()

Singleton(C)
Sometimes an application does not want to have multiple instances of the same object in memory, such as when that object is representing a unique object in the application or in the model it is defining.
Example: model your computer, you probably only have one (or two) monitor, one wireless network card, one video card, and so forth. For each of these objects it would not make sense to have multiple objects when there is only one underlying piece of hardware.

Main Things to know, test yourself 


Behaviour(CCIIMMOTSSV)
Structureur(ABCDFFP)
Creationalur(ABFPS)
Command 
Chain-of-responsibility
Interpreter
**Iterator
Mediator
Memento
**Observer
Template
State
Strategy
Visitor

**Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

**Abstract Factory
**Builder
Factory Method
Prototype
**Singleton

Real-time systems VS Embedded systems
Application Domain VS Machine Domain
Hard Systems VS  Soft systems
Validation VS Verification
Black-box VS White-box (testing)
Open VS Close layer
7 Types of interaction frames
10 Types of testingConway’s Law
3 Types of programs 
SOLID
Names of the GoF