Difference between revisions of "Template:LogicModel"
(80 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
<noinclude> | |||
{{:Logic Model}} | |||
{|class=wikitable | </noinclude> | ||
|''' | {| class="wikitable margin-left: 10px;" style="width: 95%; border-width: 5px; margin: auto;" | ||
| | |- | ||
{{: | ! Logic Model ([[{{{name}}}]]) [[Has LogicModel::Template:LogicModel]] [[Was created on::{{#invoke:CurrentDate|getDate|{{REVISIONMONTH}}|{{REVISIONDAY}}|{{REVISIONYEAR}}|}} ]] | ||
|- | |||
| | |||
{| class="wikitable margin-left: 0px;" style="width: 100%; margin: auto;" | |||
|+ style="caption-side:top;"|<small>Abstract Specification</small> | |||
|- | |||
!style="width: 10%"| '''[[{{{name}}}/Context|Context]]''' | |||
|| {{:{{{name}}}/Context}} | |||
|- | |||
!style="width: 10%"| '''[[{{{name}}}/Goal|Goal]]''' | |||
|| {{:{{{name}}}/Goal}} | |||
|- | |||
!style="width: 10%"| '''[[{{{name}}}/Criteria|Success Criteria]]''' | |||
|| {{:{{{name}}}/Criteria}} | |||
|} | |||
|- | |- | ||
| | | | ||
| | {| class="wikitable margin-left: 0px;" style="width: 100%; margin: auto;" | ||
|+ style="caption-side:top;"|<small>Concrete Implementation</small> | |||
|- | |- | ||
|''' | !style="width: 33%"| '''Given [[{{{name}}}/Input|Inputs]]''' !!style="width: 33%"| '''When [[{{{name}}}/Process|Process]] is executed...''' !!style="width: 33%"| '''Then, we get [[{{{name}}}/Output|Outputs]]''' | ||
{{: | |||
|- | |- | ||
| | | {{:{{{name}}}/Input}} | ||
|| {{:{{{name}}}/Process}} | |||
|| {{:{{{name}}}/Output}} | |||
|} | |||
|- | |- | ||
| | | | ||
{| class="wikitable margin-left: 0px;" style="width: 100%; margin: auto;" | |||
|+ style="caption-side:top;"|Boundary/Safety Conditions of [[{{{name}}}/Boundary|{{{name}}}]] | |||
|{{:{{{name}}}/Boundary}} | |||
|} | |||
|} | |||
[[Category:Contract]] | [[Category:Contract]] | ||
[[Category:Logic Model]] | [[Category:Logic Model]] |
Latest revision as of 08:43, 27 April 2023
Context
A Logic Model is capturing the logic or causal relations in a project of interest. All projects in PKC will be modeled using Logic model, and will be universally managed in a consistent namespace with a common global clock in the form of entropy pool. On the highest level, a Logic model has seven top level keys, they are Context, Goal, Success criteria, Inputs, Process, Outputs, and a set of Boundary conditions. It is also useful to know the meaning of logic through the book called:From Frege to Godel[1].
Goal
The goal of using a logic model to represent projects is to offer a unifying construct[2] that captures the common properties in project management. This will help reuse and apply experience and insights into project management across the widest range of applications possible.
Success criteria
A good Logic model has a common set of success criteria. The three common properties in projects are:
- Soundness: A sound project should be able to demonstrate/prove its internal logical consistency.
- Precision: All activities and resources in a project are accounted for in precise measures.
- Terminable: A project should be able to reach a concluding state.
Outputs
This is an instrument for one to quickly organize thoughts and create a Design Contract with the rest of the world. It can be considered as being the Monad of functional programming and in mathematical logic/Category Theory. Logic Model can be thought of a data structure that captures the different facets of a morphism, which is a kind of universal component in algebra, functional programming, and in topology. A Logic Model is the Monadic design pattern for all of the above applications. It provides the idealized data structure to approximate and standardize all the abstract structures mentioned before.
Process
To deliver outputs from inputs, the intermediary is the process. It can also be considered as an executable function, that must satisfy the soundness, precision, terminable conditions. Moreover, it can be encoded into a function shown as follows:
Process Implementation
A process can be analogously represented as an action or a task in daily life. Computationally, it can be abstractly thought of as a module that defines required inputs and outputs while performing the actual job. An example of such module can be found in the implementation of Ansible automation tool.
An example of Logic Model in a PKC
Logic Model (Meta Logic Model) Template:LogicModel 04 27, 2023 | ||||||
---|---|---|---|---|---|---|
| ||||||
| ||||||
|
Inputs
The syntax for filling up the Template is as two parts. The top part, surrounded by a blue dashline, is the abstract specification of a function. Describing what it is. The bottom part, surrounded by a red dashline, is the concrete implementation, revealing the resources and strategies to realize the cause-effect linkage between the abstraction specification with the concrete implementation and execution. The two parts, top and bottom of a Logic Model is shown below: (The blue part represents the abstraction specification, or the signature of a function. The red part represents the concrete implementation, which can be considered as the body of a function. Then, all techniques for functional composition can be applied to Logic Model, and henceforth, applied to anything that Logic Model represents.
Boundary Conditions
All projects should have limiting boundaries. As projects of the same time accumulate operational data, it is more likely to identify systematic limitations and can be explicitly stated. It is similar to the notion of exception capture in modern programming languages.
Logic Model ([[{{{name}}}]]) Template:LogicModel 04 27, 2023 | ||||||
---|---|---|---|---|---|---|
| ||||||
| ||||||
|
- ↑ van Heijenoort, Jean (2002). From Frege to Gödel: A Source Book in Mathematical Logic, 1879-1931. local page: Harvard University Press. ISBN 9780674324497.
- ↑ Lehner, Marina (2014). "All Concepts are Kan Extensions":Kan Extensions as the Most Universal of the Universal Constructions (PDF) (Bachelor). local page: Harvard College. Retrieved June 28, 2021.