Software projects are considered success when:
1. Completed on time,
2. Without exceeding resources budget.
In software development there are many unknown factors.
Developers do not know which software parts work well with which software/hardware parts.
In theory, anything can be done - but at differing time/resource costs.
Worst risks to time/resources should be addressed first:
1. Business/Development Team should organize a meeting and consider dangers/risks - not only from technological/scientific perspective,
2. Dangers/Risks should be analyzed and prioritized, from worst to least,
3. Unknown factors are risks as well, the less we know - the worse risk/danger potential,
4. Research & Prototyping are tools for assessing whether something can be done within given time/resources budget costraints. This should be one of the first phases of development.
Without these steps, unhandled risks can backfire in form of excess of resources needed, and/or in form of software development time exceeding the deadline(s).
As time flows, reality changes and customer requirements might change as well.
This is also risk, usually handled by extra time and resources allocation to project's total costs - as well as by adopting iterative development methods / as opposed to outdated 'waterfall' model, in which customers' requirement changes are not allowed by business contract /.
High quality projects should also offer 'limited warranty' time - where bugfixing and minor corrections are included in project's cost, for a given time - after closing the project.
Software quality procedures allow for faster and less expensive changes - both bugfixing and functionality changes - but customers usually do not know how to assess software's quality, and prefer to not overinvest in quality procedures they can't understand.
Friday, 17 May 2019
Sunday, 24 March 2019
'Immobilizer' Software Protection Method.
... i got a hint of this secret high-tech project during my professional career.
Basics of making it work are:
- Connection to server(s). Without it software/hardware 'freezes' and activity is logged in persistent memory.
- Part of code downloading from server.
- Cooperation with a detective agency, in case of suspicious activity detected by AI.
Breaking it is hard, requires reverse-engineering and provides only a 'snapshot' of software, denying updates.
Perhaps using Events is a good idea for decoupling objects and propagating lockdown state across parts of the protected application.
--
Obfuscators are also good tools that help to protect software.
Basics of making it work are:
- Connection to server(s). Without it software/hardware 'freezes' and activity is logged in persistent memory.
- Part of code downloading from server.
- Cooperation with a detective agency, in case of suspicious activity detected by AI.
Breaking it is hard, requires reverse-engineering and provides only a 'snapshot' of software, denying updates.
Perhaps using Events is a good idea for decoupling objects and propagating lockdown state across parts of the protected application.
--
Obfuscators are also good tools that help to protect software.
Wednesday, 5 September 2018
Linda & Tuple Space.
Introduction.
Linda & tuple space are work of Gelernter.
Linda is name derived from porn actress: Linda Lovelace, who later became 'a born again Christian' and a spokeswoman for the anti-pornography movement.
-=- Linda Lovelace. -=-
Linda is a language or notation that is used with tuple spaces, a mechanism that has uses in processes concurrency & synchronization.
There's one big and global tuple space. Processes communicate with each other by putting in the tuple space messages, and by retrieving from tuple space.
Processes are isolated, do not need to know anything about each other, processes do not need to exist at the same time. This helps to decouple objects, increasing software's quality.
'Tuple Space' has uses in the 'Token Game' - for modelling 'places', where tokens are stored, as well. Token Game uses Petri Nets idea, abstracted & concretized different way. Petri Nets are also called P/T Nets or Places / Transition Nets.
Tuple Type, Signature & State.
Tuple's signature is ordered list of data types stored in a tuple.
Tuple has statically determined length.
Tuple's state is it's values written in a binary format, concatenated.
In original work of Gelernter, tuple wasn's a type so a tuple could not contain tuples within. For 'Project Wraithstar's' purposes, tuple is a type.
Simple operations on the tuple space.
* Output(t)
Because of Linda being distributed asynchronous mechanism with the buffer of unlimited size, operation that puts a tuple into space is a nonblocking operation.
Tuple Space should be treated as a Multi-Set, that allows for putting multiple tuples of the same signature and state.
Operation Output(t) puts a tuple into a tuple space. If a tuple t is already present in the tuple space, another copy of t is put in the tuple space.
* Input(s)
A blocking operation that removes a tuple from space. Argument for this method is tuple's signature, for example:
Input(x: int32, c: char) / exact syntax in 'Ola' Programming Language is to be determined still /
If at a given moment there's no tuple with a given signature in the tuple space, then a process performing Input is blocked until requested tuple appears in the tuple space.
In original work of Gelernter, if tuple space contains many tuples with a given signature, then a choice of removed tuple is nondeterministic. There's a rule of fairness in original work as well, but for purpose of 'Project Wraithstar' - we'll assume that tuples with a given signature are put and removed as in a FIFO queue. Similarly processess that attempt to remove a tuple should use a timestamp associated with a request, as a part of UUID / Universally Unique ID /.
* Read(s)
Similar to Input(s), Read(s) retrieves a tuple with it's data from the tuple space - but does not remove it from tuple space.
Read(s) is a blocking operation, and depending on timestamps & UUIDs processess removing or retrieving tuple might be awakened in varying orders & amounts.
* Try_Input(s) and Try_Read(s).
Nonblocking versions of Input(s) and Read(s) methods.
Selective Choice.
There's option of specifying values of tuple's selected elements, of a tuple we wish to remove / retrieve from a tuple space.
For example we can remove a tuple with a signature (int32, char, int32) whose first value is 3. Appropriate instruction looks as follows:
Input(3, c: char, x: int32)
There are differencies between instruction semantics:
- Input (x, c)
- Input (x: int32, c)
- Input (x, c: char)
- Input (x: int32, c: char)
Gaps.
Linda has one more extension. In the tuple space, there can be stored tuples with 'gaps'.
'Gap' is a 'value' of a specified type, that 'matches' to any value of this type.
Gaps are noted as a star with a type.
For example, a tuple:
(3, * : char, 'a', * : int32)
Is a tuple with a signature:
(int32, char, char, int32)
Containing two gaps: on a second and fourth position.
Such tuple can be retrieved or removed from a tuple space, by performing any of given operations:
Input (3, 'c', x: char, 8)
Input (i: int32, x: char, 'a', j: int32)
Let's notice that every 'gap' has a strictly given type.
For putting gapped tuples into space, method Output can be used. In a gap-place we'll just write a type with a variable name, but variable name has no meaning here.
Output (3, c: char)
Will put into tuple space a tuple, that on a second coordinate has a type and is a gap.
Links.
- Linda as Database Management System,
- A written lecture about Linda, in a polish language,
- Linda & Concurrency,
- Tuple Data Type.
Linda & tuple space are work of Gelernter.
Linda is name derived from porn actress: Linda Lovelace, who later became 'a born again Christian' and a spokeswoman for the anti-pornography movement.
-=- Linda Lovelace. -=-
Linda is a language or notation that is used with tuple spaces, a mechanism that has uses in processes concurrency & synchronization.
There's one big and global tuple space. Processes communicate with each other by putting in the tuple space messages, and by retrieving from tuple space.
Processes are isolated, do not need to know anything about each other, processes do not need to exist at the same time. This helps to decouple objects, increasing software's quality.
'Tuple Space' has uses in the 'Token Game' - for modelling 'places', where tokens are stored, as well. Token Game uses Petri Nets idea, abstracted & concretized different way. Petri Nets are also called P/T Nets or Places / Transition Nets.
Tuple Type, Signature & State.
Tuple's signature is ordered list of data types stored in a tuple.
Tuple has statically determined length.
Tuple's state is it's values written in a binary format, concatenated.
In original work of Gelernter, tuple wasn's a type so a tuple could not contain tuples within. For 'Project Wraithstar's' purposes, tuple is a type.
Simple operations on the tuple space.
* Output(t)
Because of Linda being distributed asynchronous mechanism with the buffer of unlimited size, operation that puts a tuple into space is a nonblocking operation.
Tuple Space should be treated as a Multi-Set, that allows for putting multiple tuples of the same signature and state.
Operation Output(t) puts a tuple into a tuple space. If a tuple t is already present in the tuple space, another copy of t is put in the tuple space.
* Input(s)
A blocking operation that removes a tuple from space. Argument for this method is tuple's signature, for example:
Input(x: int32, c: char) / exact syntax in 'Ola' Programming Language is to be determined still /
If at a given moment there's no tuple with a given signature in the tuple space, then a process performing Input is blocked until requested tuple appears in the tuple space.
In original work of Gelernter, if tuple space contains many tuples with a given signature, then a choice of removed tuple is nondeterministic. There's a rule of fairness in original work as well, but for purpose of 'Project Wraithstar' - we'll assume that tuples with a given signature are put and removed as in a FIFO queue. Similarly processess that attempt to remove a tuple should use a timestamp associated with a request, as a part of UUID / Universally Unique ID /.
* Read(s)
Similar to Input(s), Read(s) retrieves a tuple with it's data from the tuple space - but does not remove it from tuple space.
Read(s) is a blocking operation, and depending on timestamps & UUIDs processess removing or retrieving tuple might be awakened in varying orders & amounts.
* Try_Input(s) and Try_Read(s).
Nonblocking versions of Input(s) and Read(s) methods.
Selective Choice.
There's option of specifying values of tuple's selected elements, of a tuple we wish to remove / retrieve from a tuple space.
For example we can remove a tuple with a signature (int32, char, int32) whose first value is 3. Appropriate instruction looks as follows:
Input(3, c: char, x: int32)
There are differencies between instruction semantics:
- Input (x, c)
- Input (x: int32, c)
- Input (x, c: char)
- Input (x: int32, c: char)
Gaps.
Linda has one more extension. In the tuple space, there can be stored tuples with 'gaps'.
'Gap' is a 'value' of a specified type, that 'matches' to any value of this type.
Gaps are noted as a star with a type.
For example, a tuple:
(3, * : char, 'a', * : int32)
Is a tuple with a signature:
(int32, char, char, int32)
Containing two gaps: on a second and fourth position.
Such tuple can be retrieved or removed from a tuple space, by performing any of given operations:
Input (3, 'c', x: char, 8)
Input (i: int32, x: char, 'a', j: int32)
Let's notice that every 'gap' has a strictly given type.
For putting gapped tuples into space, method Output can be used. In a gap-place we'll just write a type with a variable name, but variable name has no meaning here.
Output (3, c: char)
Will put into tuple space a tuple, that on a second coordinate has a type and is a gap.
Links.
- Linda as Database Management System,
- A written lecture about Linda, in a polish language,
- Linda & Concurrency,
- Tuple Data Type.
Sunday, 15 July 2018
Software Development & Quality.
Introduction.
There are many methods for ensuring that software development proceeds smoothly, and there are methods for ensuring and measuring software artifacts' quality.
Artifacts are documents:
- design model,
- application code,
- automated tests code,
- documentation,
- configuration files,
- resource files as art or other data,
- ...
Code's Quality.
For a code quality's practices, see if You wish:
- A few thoughts on code quality...
Teamwork vs. Showoff.
Teamwork is Professional, needless showoff is NOT Professional.
Code should be written & documented in a simple way, so other co-workers can understand it with ease.
This friendly approach - of making teamwork easier helps the most newcomers - either beginner programmers, or programmers who worked with different Programming Language(s), Tools, Ecosystem, Technology(-ies).
Automated Testing.
For automated testing article, see if You wish:
- Automated Tests.
Design & Modelling.
Software models, often presented in a graphical way, are tools to look at software's design from a 'bird's view', to grasp whole picture.
Software modelling and design's goal is to abstract & simplify project.
Designs should be as simple and as abstract as possible - as this allows for easier code modifications as reality and customer's needs change.
... but of course modelling a single object with name 'idea' is too unreasonable interpretation of above words.
There are 'views' of a model as well - each view serves a purpose - each of views is a transformed model, both reduced and filled with details, to emphasize it's purpose.
For example we can have model consisting of every of car's parts, then we can produce a view of engine - fuel interaction. Unneccessary parts for this view are omitted, and more details about heat, and other aspects can be provided in view's documentation.
Models and views can be more or less exhaustive and detailed, and always should be unambiguous.
There are many methods for ensuring that software development proceeds smoothly, and there are methods for ensuring and measuring software artifacts' quality.
Artifacts are documents:
- design model,
- application code,
- automated tests code,
- documentation,
- configuration files,
- resource files as art or other data,
- ...
Code's Quality.
For a code quality's practices, see if You wish:
- A few thoughts on code quality...
Teamwork vs. Showoff.
Teamwork is Professional, needless showoff is NOT Professional.
Code should be written & documented in a simple way, so other co-workers can understand it with ease.
This friendly approach - of making teamwork easier helps the most newcomers - either beginner programmers, or programmers who worked with different Programming Language(s), Tools, Ecosystem, Technology(-ies).
Automated Testing.
For automated testing article, see if You wish:
- Automated Tests.
Design & Modelling.
Software models, often presented in a graphical way, are tools to look at software's design from a 'bird's view', to grasp whole picture.
Software modelling and design's goal is to abstract & simplify project.
Designs should be as simple and as abstract as possible - as this allows for easier code modifications as reality and customer's needs change.
... but of course modelling a single object with name 'idea' is too unreasonable interpretation of above words.
There are 'views' of a model as well - each view serves a purpose - each of views is a transformed model, both reduced and filled with details, to emphasize it's purpose.
For example we can have model consisting of every of car's parts, then we can produce a view of engine - fuel interaction. Unneccessary parts for this view are omitted, and more details about heat, and other aspects can be provided in view's documentation.
Models and views can be more or less exhaustive and detailed, and always should be unambiguous.
Tuesday, 1 May 2018
Causal Notation.
Purpose.
This is a Causal Notation's initial draft, it's intended to have uses in Causal Proofs, Causal Analysis,
Causal Modelling, Causal Design, Causal Programming & Causal Automated Tests.
Additional practical notes.
This model is not detached from Reality, it applies to concurrent, non-realtime systems. Hence, we consider unknown delays in model & notation.
Are realtime systems detached from Reality?
Generally they are not - but for many solutions they are too expensive and slow to make. Hence, in many niches and solutions they are too unreal to be worthwhile.
Proving that programs or program parts will complete in a given maximum amount of time, is not possible using these tools. Using statistical-allowance of errors, including completion-time-related errors and forming contracts that way might be possible, but there's always a risk.
While time is counted very precisely by computer clocks, there are delays caused by code execution - every instruction takes a time to perform. Exact amount of delay depends on instruction(s), on processor(s) and on operating system and other software layers, if there are any.
Therefore, clock-events, objects creation and interaction are associated with delays, and response to clock-events usually is associated with delays.
Profilers, either built-in a programming language, or added manually or provided by thrid-party tools - are a good way of measuring average, worst and best delays statistically on a given hardware-software infrastructure unit.
See also, if You wish: Correctness.
Types.
Ca: a cause,
R: a result, an abstract object type that can evaluate to a boolean value,
De: discrete event, either a cause or result,
Co: a condition,
Te: a timeframe.
Cns: a conditions set,
B: a boolean expression,
Cto: a clock-events bound condition; it's state contains exact time of appearance and time of disappearance,
t: a time measured in milliseconds since beginning of year 1 A.D.
O: observer object - observes clock events, causes & conditions appearance, existence and disappearance, as well as origination, hold time, and cessation, then reacts with events that can result in cause(s) and/or condition(s) appearance and disappearance, as well as origination and cessation.
Definitions.
Cto := (t1, t2) - - Condition that appears at time t1 or a little later, and disappears at t2 or a little later,
Cto := (t, ...) - Condition that appears at a time t or a little later, and disappears when program stops,
Cto := (..., t) - Condition that appears during program's initialization, and disappears at time t or a little later,
Ten := Com - a timeframe Ten is defined as in-between of a condition Com appearance and disappearance.
Cnsn := Con1, Con2, ... - a conditions set Con is defined as a collection of conditions Con1, Con2, ...
Cnsn := Cnsm1, Cnsm2, ..., Cop1, Cop2, ... - a conditions set Cnsn,
is defined as a collection of:
* conditions Cop1, Cop2, ...,
* conditions from conditions sets Cnsm1, Cnsm2, ...
Origination - an objects starts to affect Reality.
Hold - an object keeps affecting Reality.
Cessation - an object ceases to affect Reality.
Appearance - an object appears in Reality.
Existence - an object exists in Reaiity.
Disappearance - an object disappears from Reality.
In different sources - Buddhist or other - these ideas might be defined differently.
In many cases, but not all:
* appearance means origination,
* existence means hold,
* disappearance means cessation.
Can object exist and not affect Reality?
* depends on how we define a Reality,
* a part of Reality is also a Reality,
* we can play with ideas of objects with or without meaning,
* we can play with ideas of physical and nonmaterial objects,
* we can play with ideas of redefining what 'affecting' means, and with 'affecting threshold',
* does observation affect Reality?,
* ...
This has uses in modelling, for example, as models are simplified representation of interresting Reality's parts.
Appearance, Existence, Disappearance, Origination, Hold & Cessation.
Can := App Dem - a discrete event Dem makes a cause Can to appear.
Can := App Com - a condition Com makes a cause Can to appear.
Can := App Cnsm - a conditions set Cnsm makes a cause Can to appear.
when Bn : Com - condition Com appears and exists for as long as Bn is true.
Rn := Ap Dem in Tep - a result Rn evaluates to true if a discrete event Dem appears in a timeframe Tep.
Rn := Ap Com in Tep - a result Rn evaluates to true if a condition Com appears in a timeframe Tep.
Rn := Ap Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm appears in a timeframe Tep.
Rn := Dis Cam in Tep - a result Rn evaluates to true if a cause Cam disappears in a timeframe Tep.
Rn := Dis Com in Tep - a result Rn evaluates to true if a condition Com disappears in a timeframe Tep.
Rn := Dis Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm disappears in a timeframe Tep.
Rn := Ex Cam in Tep - a result Rn evaluates to true if a cause Cam exists in a timeframe Tep.
Rn := Ex Com in Tep - a result Rn evaluates to true if a condition Com exists in a timeframe Tep.
Rn := Ex Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm exists in a timeframe Tep.
Rn := Ori Dem in Tep - a result Rn evaluates to true if a cause Dem originates in a timeframe Tep.
Rn := Ori Com in Tep - a result Rn evaluates to true if a condition Com originates in a timeframe Tep.
Rn := Ori Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm originates in a timeframe Tep.
Rn := Ces Cam in Tep - a result Rn evaluates to true if a cause Cam ceases in a timeframe Tep.
Rn := Ces Com in Tep - a result Rn evaluates to true if a condition Com ceases in a timeframe Tep.
Rn := Ces Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm ceases in a timeframe Tep.
Rn := H Cam in Tep - a result Rn evaluates to true if a cause Cam holds in a timeframe Tep.
Rn := H Com in Tep - a result Rn evaluates to true if a condition Com holds in a timeframe Tep.
Rn := H Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm holds in a timeframe Tep.
Links.
See also, if You wish:
* The 'Causal Programming Paradigm'.
* Causal Automated Tests.
This is a Causal Notation's initial draft, it's intended to have uses in Causal Proofs, Causal Analysis,
Causal Modelling, Causal Design, Causal Programming & Causal Automated Tests.
Additional practical notes.
This model is not detached from Reality, it applies to concurrent, non-realtime systems. Hence, we consider unknown delays in model & notation.
Are realtime systems detached from Reality?
Generally they are not - but for many solutions they are too expensive and slow to make. Hence, in many niches and solutions they are too unreal to be worthwhile.
Proving that programs or program parts will complete in a given maximum amount of time, is not possible using these tools. Using statistical-allowance of errors, including completion-time-related errors and forming contracts that way might be possible, but there's always a risk.
While time is counted very precisely by computer clocks, there are delays caused by code execution - every instruction takes a time to perform. Exact amount of delay depends on instruction(s), on processor(s) and on operating system and other software layers, if there are any.
Therefore, clock-events, objects creation and interaction are associated with delays, and response to clock-events usually is associated with delays.
Profilers, either built-in a programming language, or added manually or provided by thrid-party tools - are a good way of measuring average, worst and best delays statistically on a given hardware-software infrastructure unit.
See also, if You wish: Correctness.
Types.
Ca: a cause,
R: a result, an abstract object type that can evaluate to a boolean value,
De: discrete event, either a cause or result,
Co: a condition,
Te: a timeframe.
Cns: a conditions set,
B: a boolean expression,
Cto: a clock-events bound condition; it's state contains exact time of appearance and time of disappearance,
t: a time measured in milliseconds since beginning of year 1 A.D.
O: observer object - observes clock events, causes & conditions appearance, existence and disappearance, as well as origination, hold time, and cessation, then reacts with events that can result in cause(s) and/or condition(s) appearance and disappearance, as well as origination and cessation.
Definitions.
Cto := (t1, t2) - - Condition that appears at time t1 or a little later, and disappears at t2 or a little later,
Cto := (t, ...) - Condition that appears at a time t or a little later, and disappears when program stops,
Cto := (..., t) - Condition that appears during program's initialization, and disappears at time t or a little later,
Ten := Com - a timeframe Ten is defined as in-between of a condition Com appearance and disappearance.
Cnsn := Con1, Con2, ... - a conditions set Con is defined as a collection of conditions Con1, Con2, ...
Cnsn := Cnsm1, Cnsm2, ..., Cop1, Cop2, ... - a conditions set Cnsn,
is defined as a collection of:
* conditions Cop1, Cop2, ...,
* conditions from conditions sets Cnsm1, Cnsm2, ...
Origination - an objects starts to affect Reality.
Hold - an object keeps affecting Reality.
Cessation - an object ceases to affect Reality.
Appearance - an object appears in Reality.
Existence - an object exists in Reaiity.
Disappearance - an object disappears from Reality.
In different sources - Buddhist or other - these ideas might be defined differently.
In many cases, but not all:
* appearance means origination,
* existence means hold,
* disappearance means cessation.
Can object exist and not affect Reality?
* depends on how we define a Reality,
* a part of Reality is also a Reality,
* we can play with ideas of objects with or without meaning,
* we can play with ideas of physical and nonmaterial objects,
* we can play with ideas of redefining what 'affecting' means, and with 'affecting threshold',
* does observation affect Reality?,
* ...
This has uses in modelling, for example, as models are simplified representation of interresting Reality's parts.
Appearance, Existence, Disappearance, Origination, Hold & Cessation.
Can := App Dem - a discrete event Dem makes a cause Can to appear.
Can := App Com - a condition Com makes a cause Can to appear.
Can := App Cnsm - a conditions set Cnsm makes a cause Can to appear.
when Bn : Com - condition Com appears and exists for as long as Bn is true.
Rn := Ap Dem in Tep - a result Rn evaluates to true if a discrete event Dem appears in a timeframe Tep.
Rn := Ap Com in Tep - a result Rn evaluates to true if a condition Com appears in a timeframe Tep.
Rn := Ap Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm appears in a timeframe Tep.
Rn := Dis Cam in Tep - a result Rn evaluates to true if a cause Cam disappears in a timeframe Tep.
Rn := Dis Com in Tep - a result Rn evaluates to true if a condition Com disappears in a timeframe Tep.
Rn := Dis Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm disappears in a timeframe Tep.
Rn := Ex Cam in Tep - a result Rn evaluates to true if a cause Cam exists in a timeframe Tep.
Rn := Ex Com in Tep - a result Rn evaluates to true if a condition Com exists in a timeframe Tep.
Rn := Ex Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm exists in a timeframe Tep.
Rn := Ori Dem in Tep - a result Rn evaluates to true if a cause Dem originates in a timeframe Tep.
Rn := Ori Com in Tep - a result Rn evaluates to true if a condition Com originates in a timeframe Tep.
Rn := Ori Cnsm in Tep - a result Rn evaluates to true if a conditions set Cnsm originates in a timeframe Tep.
Rn := Ces Cam in Tep - a result Rn evaluates to true if a cause Cam ceases in a timeframe Tep.
Rn := Ces Com in Tep - a result Rn evaluates to true if a condition Com ceases in a timeframe Tep.
Rn := Ces Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm ceases in a timeframe Tep.
Rn := H Cam in Tep - a result Rn evaluates to true if a cause Cam holds in a timeframe Tep.
Rn := H Com in Tep - a result Rn evaluates to true if a condition Com holds in a timeframe Tep.
Rn := H Cnsm in Tep - a result Rn evaluates to true if a condition set Cnsm holds in a timeframe Tep.
Links.
See also, if You wish:
* The 'Causal Programming Paradigm'.
* Causal Automated Tests.
Monday, 30 April 2018
Causal Automated Tests.
About.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
In the 'Causal Programming Paradigm', each of state changes, as well as methods entrances, having control within, and control leaving can cause conditions appearance, existence, and disappearance event notifications. Methods' leave events contain return values, if applicable.
In the 'Causal Programming Paradigm', causes appearances and disappearances can cause event notifications.
How automated tests are perfomed in this paradigm, then?
1. Test registers for neccessary event notifications,
2. Test runs a method to be tested - which can contain one or many objects/methods.
3. Test gets report of the events raised and analyzes their types, order of appearance and state.
4. Test returns a value - either true or false, which says whether it was success or failure.
Links.
See also, if You wish:
- Invariants,
- Causes & Conditions,
- The 'Causal Programming Paradigm'.
Automated Unit & Integration tests / pl: zautomatyzowane testy jednostkowe i integracyjne / are not proofs, but these are practical as well - reducing bugfixing costs extremely significiantly at a very small price. There are more benefits to using Automated Tests, for example Mental Harness of Unit & Integration Tests enables one to proceed more boldly, faster, thinking on higher abstraction levels without worryig about minor bugs, relying on tests to handle that. These also can use Invariants.
In the 'Causal Programming Paradigm', each of state changes, as well as methods entrances, having control within, and control leaving can cause conditions appearance, existence, and disappearance event notifications. Methods' leave events contain return values, if applicable.
In the 'Causal Programming Paradigm', causes appearances and disappearances can cause event notifications.
How automated tests are perfomed in this paradigm, then?
1. Test registers for neccessary event notifications,
2. Test runs a method to be tested - which can contain one or many objects/methods.
3. Test gets report of the events raised and analyzes their types, order of appearance and state.
4. Test returns a value - either true or false, which says whether it was success or failure.
Links.
See also, if You wish:
- Invariants,
- Causes & Conditions,
- The 'Causal Programming Paradigm'.
Correctness.
Introduction.
Proving code's correctness / pl: dowodzenie poprawności kodu / can be done, but is very difficult & expensive so far.
Depending on purpose, code's correctness proofs are neccessary / for example: the nuclear reactor's software, airplane controls /, or not / for example: a non-commercial webpage /.
In reality, automated tests are enough for many applications, and proofs are used only in mission - critical software parts, because of the costs measured in programmers' work time and in other resources.
Too often even the simple automated tests are omitted in programmers' work - as customers mistakenly think that it costs less to just pay for bugfixing, than to pay for quality. But customers often lack knowledge neccessary to check code's quality, so they prefer to not pay for quality, while expecting it still.
Causal Proofs.
... i think that with coming of the 'Causal Programming Paradigm', proving code's correctness might become easier, automated testing as well.
With this paradigm, software analysis will be similar to observing a space - play, a play of causes & conditions.
Computation is calculation with side effects, depending on hardware & software, machines can compute either well or not so well.
In the Causal Programming Paradigm, cause's result appears when cause appears and conditions exist for long enough after cause's appearance.
Program's result is achieving certain results - either once, or continually, over a given time.
Idea of algorithm's correctness proof, therefore, is proving that a proper cause will appear, and proper conditions will exist for long enough, in a given timeframe.
See also, if You wish: Causes & Conditions.
Concurrency & Real Time.
Timeframe can be counted either using Real Time Clock, in case of Realtime programming languages, or defined as 'within brackets' of causes, countercauses, conditions and counterconditions appearance, existence or disappearance - in case of programming languages without Realtime mechanisms, as for example: 'Ola' Programming Language.
In a Nonrealtime Concurrent Systems, Real Time Clock can be used as well, but not so precisely.
Concurrency is not the same as Realtime Support Mechanisms, and considering either or both is not a small cost when proving program's correctness. In simpler words: Nonrealtime Concurrent Systems are faster usually than Realtime Concurrent Systems, but lack the Hard Pessimistic Time Constraints - often work faster, but occasionally are too slow. Realtime systems, when written correctly, do not fail at all - but are slower on average.
Nonrealtime Concurrent Systems are also cheaper and easier in making than Realtime Concurrent Systems, and market niche for these languages is much larger. People do not need expensive and over-ambitious solutions for most of simpler tasks, afterall.
Both the Realtime Concurrent Systems, as well as the Nonrealtime Concurrent Systems can work in Real Time, can have user interface that affect their behaviour. The 'Starcraft 2' Computer Game by Blizzard Entertainment is an example of the Nonrealtime Concurrent Program masterpiece - it works smooth and fast, but occassinally 'hiccups' - slows down for a while. Being a Nonrealtime Program it's much cheaper, and is faster on average.
'Starcraft 2' is the game of the 'RTS' - 'Real Time Strategy' Computer Games Genre, as it works in Real Time, Concurrently coordinating software parts. By the Computer Sciences Linguistics it is not a Realtime System, however, as it doesn't adhere to Pessimistic Time Contraints of the Realtime Systems. There's the difference between Computer Science's 'Realtime' meaning and the Common Sense's 'Real Time' meaning. The RTS Computer Game Genre illustrate this difference well enough, i think.
Quality & Professional Practices.
In formal proofs of program's correctness, minimalism is important too, code should have as little of side-effects as possible - only desired ones, if possible - as unwanted side effects, causes & conditions, can complicate proofs or interfere with results.
'The less code the better', SOLID, DRY / 'Don't repeat yourself' / & other ideas are important when considering 'Code Quality Metrics'.
Links.
See also, if You wish:
* Invariants,
* Causal Notation.
Proving code's correctness / pl: dowodzenie poprawności kodu / can be done, but is very difficult & expensive so far.
Depending on purpose, code's correctness proofs are neccessary / for example: the nuclear reactor's software, airplane controls /, or not / for example: a non-commercial webpage /.
In reality, automated tests are enough for many applications, and proofs are used only in mission - critical software parts, because of the costs measured in programmers' work time and in other resources.
Too often even the simple automated tests are omitted in programmers' work - as customers mistakenly think that it costs less to just pay for bugfixing, than to pay for quality. But customers often lack knowledge neccessary to check code's quality, so they prefer to not pay for quality, while expecting it still.
Causal Proofs.
... i think that with coming of the 'Causal Programming Paradigm', proving code's correctness might become easier, automated testing as well.
With this paradigm, software analysis will be similar to observing a space - play, a play of causes & conditions.
Computation is calculation with side effects, depending on hardware & software, machines can compute either well or not so well.
In the Causal Programming Paradigm, cause's result appears when cause appears and conditions exist for long enough after cause's appearance.
Program's result is achieving certain results - either once, or continually, over a given time.
Idea of algorithm's correctness proof, therefore, is proving that a proper cause will appear, and proper conditions will exist for long enough, in a given timeframe.
See also, if You wish: Causes & Conditions.
Concurrency & Real Time.
Timeframe can be counted either using Real Time Clock, in case of Realtime programming languages, or defined as 'within brackets' of causes, countercauses, conditions and counterconditions appearance, existence or disappearance - in case of programming languages without Realtime mechanisms, as for example: 'Ola' Programming Language.
In a Nonrealtime Concurrent Systems, Real Time Clock can be used as well, but not so precisely.
Concurrency is not the same as Realtime Support Mechanisms, and considering either or both is not a small cost when proving program's correctness. In simpler words: Nonrealtime Concurrent Systems are faster usually than Realtime Concurrent Systems, but lack the Hard Pessimistic Time Constraints - often work faster, but occasionally are too slow. Realtime systems, when written correctly, do not fail at all - but are slower on average.
Nonrealtime Concurrent Systems are also cheaper and easier in making than Realtime Concurrent Systems, and market niche for these languages is much larger. People do not need expensive and over-ambitious solutions for most of simpler tasks, afterall.
Both the Realtime Concurrent Systems, as well as the Nonrealtime Concurrent Systems can work in Real Time, can have user interface that affect their behaviour. The 'Starcraft 2' Computer Game by Blizzard Entertainment is an example of the Nonrealtime Concurrent Program masterpiece - it works smooth and fast, but occassinally 'hiccups' - slows down for a while. Being a Nonrealtime Program it's much cheaper, and is faster on average.
'Starcraft 2' is the game of the 'RTS' - 'Real Time Strategy' Computer Games Genre, as it works in Real Time, Concurrently coordinating software parts. By the Computer Sciences Linguistics it is not a Realtime System, however, as it doesn't adhere to Pessimistic Time Contraints of the Realtime Systems. There's the difference between Computer Science's 'Realtime' meaning and the Common Sense's 'Real Time' meaning. The RTS Computer Game Genre illustrate this difference well enough, i think.
Quality & Professional Practices.
In formal proofs of program's correctness, minimalism is important too, code should have as little of side-effects as possible - only desired ones, if possible - as unwanted side effects, causes & conditions, can complicate proofs or interfere with results.
'The less code the better', SOLID, DRY / 'Don't repeat yourself' / & other ideas are important when considering 'Code Quality Metrics'.
Links.
See also, if You wish:
* Invariants,
* Causal Notation.
Subscribe to:
Posts (Atom)