Tuesday, July 29, 2014
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
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
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.
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.
Subscribe to:
Posts (Atom)
Posts
