Software Engineering Concepts / Notes

With respect to the OO Approach, clearly and concisely explain the meaning of ...and give an example for each...

Class:
* A class is an Abstract Data Type that combines Data and Operations, hence a class possesses a name, attributes of certain data types and Operations.
* A class acts as a blue print to allow instantiations of objects which take on the classes attributes and operations.
* Classes mimic types of objects found in the real world (The OO Paradigm) but also display properties of inheritance (Generalisation / Specialisation yielding subclasses and super classes or parent./child classes) and class relationships.
Object:
*An object is an instantiation of a class, and inherits / takes on the attributes and operations of its class.
* An object has a unique name.*An object has operations that allow communications to other objects via messages.Operations
Operations are part of classes and instanced objects.
Operations give classes and thus objects functionality.
Operations may take input operands (that it operates on ) and have a return type
of a specific data type.
Association
* Classes have associations with one another in the form of class relationships.
Associations may be specialised relationships such as Generalisation/ Specialisation (inheritance) or Aggregation / Composition.
* An association is the most general type of relationship between two classes

* Not all Classes have associations with all other classes. - of course....

wikipedia:
In object-oriented analysis and in UML, an association between two classes represents a collaboration between the classes or their corresponding instances. Associations have direction; for example, a bi-directional association between two classes indicates that both of the classes are aware of their relationship.^[23] Associations may be labeled according to their name or purpose.^[24]Association Class
An Assoc. class can be modelled when more information is required from an existing association - eg
In UML its notation is a dotted / dashed line pointing o the association directly from the new class Box / Rubric.
Aggregation:
* Aggregation is a form of association between classes in which one class acts as a 'Whole' and another class acts as a part of that whole.
* Aggregation can be in a 'strong' form where it is known as 'Composition'
* Aggregation in a UML class diagram is indicated by hollow/clear diamond
at the 'Whole ' or parent end of the association.Eg. a Car and its various parts - wheels, sunroof, chassis, Body. A car Class is the class that acts as the Whole, the Wheels are a class that represents only part of the car
(Example from Lectures)
NB a class that 'part of a whole' is not necessarily a subclass



Composition:* as above Aggregation can be in a 'strong' form where it is known as 'Composition'
* composition results from a relation in which one class is the whole and one class is a part of that whole like aggregation, however with a composition relation the meaningful existance of the parts is dependent on the existance of the whole
ie a screen has pixels - the relation between pixels and screen is compositional - the screen is composed of pixels - with out the screen - the pixels don't exist


Message (needs more research)
A message is a form of communication from object to object that specifies a request for an action.
eg.
Operation:
* An operation is a component of a class (present in the definition of a class) that gives the class functionality.
* An operation may take one or more arguments and may have a return data type.
* Operations become a Design class's methods when Conceptual classes become 'Design Classes' or 'Implementation Classes'.

eg a class called 'Calculate' contains the Operation 'Add' that takes 2 arguments, and returns a datatype that can represent the sum of the two arguments.

* Operations may be public - visible to all other objects,
private - visible only to operations with in the same class, or
protected - visible to the objects of the same class instantiation or objects from subclasses of the root class for that object

Pattern
"A Pattern is a reusable template for solving problems according to best practice"

GRASP Patterns are often referred to in SE
(General Responsibility Assignment Software Pattern)

some examples of GRASPS 
are :

Low Coupling Pattern
High Cohesion Pattern
Information Expert Pattern

Graph Theory notes

Graph Theory Pop Quiz

* What is the best implementation, an adjacency List or Adjacency Matrix type implementation for a BFS Algorithm when dealing with a sparse graph ?

Why ?
 
What is the time complexity of the following algorithms:

* Dijkstra's shortest Path algorithm
* Kruskal's algorithm
* BFS
* DFS
*A* ?
* Dual Source Implementation of Dijkstra's Algorithm ?

* describe what an bipartite graph is...
 
* What is he number of edges of a connected undirected graph containing 47 vertices ?

* in what situation will Dijkstra's algorithm not function correctly?

* what does DAG stand for ?


* can a connected graph have several components ?  
* Which algorithm would a Topological Sort make use of ?

* which algorithm is defined recursively out of either BFS or DFS ?

* What is a Digraph ?

* What is the difference between a connected graph and a 
disconnected graph ?

* How many types of connectedness can a Directed Graph have ?

* What is the meaning of weakly connected graph ?
 
* Describe the Shortest Path Compositionality Property ?

* How many bridges of Konigsberg were there back in the day when the problem was introduced to Edgar W. Dijkstra ?
:D you nerd

* Name 3 common applications of Graph theory
a)
b)
c)

more PBR - with photon maps

2D collision detection

http://devmag.org.za/2009/04/17/basic-collision-detection-in-2d-part-2/

clouds2

more cloud like test renders. The last two were quite slow...about an hour

the low-fi clouds (1 or 2 pixel samples) are about 1 min to render

 

clouds

simple displacement on a volume model

90 min render :|

Software Engineering Terminology, usecases, Dataflow diagrams.

COTS

Commercial Off the Shelf Software

SRS

System Requirements Specification, is an essential formal document describing in detail the requirements in the development of some software.
It is useful as a guide for software developers - ie programmers and clarifies exactly what is required to satisfy stakeholders wishes when developing the software. It also serves as a useful reference to developers and clients as to what has been agreed upon before moving further into developmental stages of SE (Software Engineering)

Actor (Use Case > UML)

An actor is an entity external to a software system. 
An actor is used in a use case to describe interactions between a software system and a user, or another system.

"The entity or class existing outside the system which is invovled with interacting with
the system."
"An actor assists in determining use cases."

"An actor activates and stimulates the system with input events or 
receives output events from the system. An actor plays the role of interaction with a use case."

"An actor (in a use-case) is anything that provides input or receives output from the system. "
 Actors in UML are noted with a simple-stick figure symbol.

Use Case

defn from my lecturer:

" A use case is a narrative description of domain processes in a structured prose format "

A use-case is a tool in the Software Engineers tool box for Software Requirements Elicitation - gathering an ordered set of requirements.
Use cases are usually created in the 1st stage of software development while developing a SRS. 
A use case has an actor - an external entity that interacts with the system being described. 
An actor is usually a human - ie the software system user, but can also be another system interacting with the system being described
ie a browser is a system interacting with another system - http or the web.
An electronic funds transfer system (EFTPOS here in Australia) is an example of a non-human actor.

Use cases are structured approaches to handling the scenarios informally have always been used to help understand requirements.

In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal.
wikipedia

Wikipedia: use case Diagram
http://en.wikipedia.org/wiki/Use_Case_Diagram


A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements.
http://searchsoftwarequality.techtarget.com/definition/use-case

A use case is a software and system engineering term that describes how a user uses a system to accomplish a particular goal. A use case acts as a software modeling technique that defines the features to be implemented and the resolution of any errors that may be encountered.
techopedia

Scenario (Use Case > UML)

a scenario is a single path through a use case
a sunshine scenario is a typical or common (80% common) path through a use case.

Extended Use-Case

an extended use-case 'drills down' into more detail and includes a sunshine scenario and several possible variations on the main scenario.

A variation is some path through a user's interaction with the  system that isnt typical - ie a student wishes to log in to the uni systems page and check her exam results, a variation to the sunshine scenario may describe - the user providing an incorrect password and requesting the system reset her password and provide a new one.

DFD (data-flow diagram)

A data flow diagram is a requirements engineering tool, just as a use case is. Its focus is on data, how the data is 'transformed' by processes , or simply processed. DFD's can be hierarchical - a high level DFD maybes contain processes that correspond to lower  level (more detailed) DFD's, with corresponding numbers...like Russian dolls...but not.

Diagrammatically - a DFD is comprised of four elements:
   Entities (external to the system) - represented by a rectangle
   Processes - represented by an ellipse or some times a rectangle with rounded corners.
   Flows represented by flow lines - the direction of which is indicated by an arrow
   Data Stores - represented by two horizontal paralell lines surrounding the name

Youtube video - DFD well explained

https://www.youtube.com/watch?v=QkKTxsMBdZs

Thanx Eddie Woo !

All four elements must be labelled with appropriate names.
   Entity names are typically nouns - Customer, Staff, Manager, Owner
   Processes typically have names starting with a verb and being reasonably descriptive.

Notes 

a data flow line shouldn't be bidirectional - there should be a separate flow line for either direction
a entity can be either a source or a sink
a source provides input data to the system
a sink receives output data from the system
data stores and processes should not display 'black holes' or be 'miracles'
    a 'black hole' is a data store node or process with data flowing into it but no out
    a 'miracle' is a data store node process node that creates data from nothing
    (...only an entity - source can behave like this).
all data-flows are associated with a process
data-stores are internal - make sure they resided with in the  system boundary
( there should only be one system boundary per DFD)

DFD don'ts...

* don't expect to get your diagram perfect 1st time - creating them is an iterative process.
* everything (all 4 elements) need to have a label with a meaningful name
* don't have data stores that are sources or sinks - as above
* don't have data-flows that are not associated with a process
* don't have data-stores outside of your system boundary - where the Entities should reside.


Non-functional requirements

...can be used to judge the operation of a system - rather than the behaviour of a system which is determined by functional requirements.

examples are:
Performance - response times, usability, games are an example of software where response time is important. BioMechanical software - another example.

Safety

Security
An abstract machine model or layered model lends itself well to security - ie The structure of an Operating system with the central kernel or the layered approach of the OSI model for networking.

Availability 
...describes how  soft ware can maintain some functionality despite some component of it failing. an analogy is that of a plane with more than one engine. if one engine dies, there is still hope of a safe landing from the other engine.

Reliability
Dependability
Maintainability : describes how easily software can be changed, eg replacement of a component.
with poor maintainability, replacing a component with affect many other dependednt components and be a costly and difficult process.

If software is structured in a layered fashion such as the OSI model for networking, then 
components can be replaced with out too many problems, provided their interface system is maintained.

non functional requirements will vary depending on the software type, ie system critical  software 
(ie missle launching control software vs a game of chess)

UML (Unified Modelling Language)

a tool in the developer's tool chest, for describing software systems. UML provides a formal framework for creating diagrams to describe software systems. ie Use Case Diagram and DFD (Data Flow Diagrams) are examples of UML diagrams.

subgraphs

Euler Circuits

is the square of an even integer always even ?

how many prime numbers are there ?

how many ?

a Discreet math problem...

How many integers are NOT divisble by 3,7 or 9 ?

import java.math.*;
import static sun.util.calendar.CalendarUtils.mod;
       
public class Divisible {
    public static void main(String[] args) {
        int count = 0;
        for (int i = 2; i < 1000; i++){
            if (
                mod(i,3)== 0 ||
                mod(i,7)== 0 ||
                mod(i,9)== 0){
            count++;
            }           
        }
      // print the tally - 998 - all those divisible by 3,7 or 9
        count = (1000-2)-count;
    System.out.println(count);
    }
}

example of proof by contradiction - root 2 is irrational

PBR home-brewed car shader tests

I read over my old pre-PBR car shader attempt
and the notes on odforce and updated my shader to work for PBR

the flecs are simple perlin - i experimented with mixing a bunch of patterns
but in the end this gave just as good results.

HDRI only

 geo 'studio' lights and 2 intensities flecs, animation tested

 

 different procedurals for flecs

PBR and Displacement tests

PBR Test Subsurface Scattering

Single SSS Algorithm, Intensity 1, 3x3 pixel Samples

    Attenuation  [.5,1,2,4,8,16,322,64,128]

 

PBR tests - Default Surface Model

PBR render tests

All renders here have :
an Environment light with the same HDR map
an additional spot for shadow casting (Raytrace unless otherwise specified)
1 Diffuse Bounces allowed

Defualt Surface Shading Model

Mantra > Properties > Pixel Samples:

Magnifications of the same renders.

from left to right:

3x3 (default)
2x2
1x1
0x0 (no samples)

Diffuse Bounce Limit [0,1,2]

Reflection Bounce Limit [1,2,3,10]