Search This Blog

Loading...

Tuesday, July 29, 2014

2D collision detection

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

Thursday, July 17, 2014

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









if there was a place called fallopia - maybe it would have clouds like this :)

Wednesday, July 16, 2014

Tuesday, July 15, 2014

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

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.


Follow by Email

Loading...