Difference between revisions of "PKC Workflow/Process"

From PKC
Jump to navigation Jump to search
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
# [[PKC Workflow/Work Breakdown Structure]]
# [[PKC Workflow/System Verification|System Verification by TLA+]]  
# [[PKC Workflow/TLA Workflow]]  
# [[PKC Workflow/Jenkins Integration|Jenkins Integration]]
# [[PKC Workflow/Jenkins Integration]]
# [[PKC Workflow/Docker Registry|Docker Registry]]
# [[PKC Workflow/Task/Docker Installation]]
# [[PKC Workflow/Meeting and Communication|Meeting and Communication]]
# [[PKC Workflow/Meeting and Communication|Communication]]
# [[PKC Workflow/Issues|Issues]]
# [[PKC Workflow/Issues|Issue]]
# [[PKC Workflow/Updates|Updates]]
# [[PKC Workflow/Updates|Updates]]
# [[All activities]]
# [[All activities|All activities]]


<noinclude>  
<noinclude>  
Line 12: Line 11:


When describing a process in the macroscope, it is always a verb. The input/output is defined according to the function's specification.
When describing a process in the macroscope, it is always a verb. The input/output is defined according to the function's specification.
Inputs - [Process] -> Outputs
<graphviz>
<graphviz>
digraph G {
digraph G {
Line 39: Line 37:
* Everything is a list  
* Everything is a list  
    
    
Inputs -> Process -> Outputs
Process -> Process
<graphviz>
<graphviz>
digraph G {
digraph G {
Line 55: Line 49:
</graphviz>
</graphviz>


== States and Local Variables==  
== State ==  
In a process, there are data generated alongside but isn't intended to serve as the output or expose outside the process.  In programming, it corresponds to [https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html Module and Localization].  In [[PKC Workflow]], the following pages
In a process, there are data generated alongside but isn't intended to serve as the output or expose outside the process.  In programming, it corresponds to [https://reference.wolfram.com/language/tutorial/ModularityAndTheNamingOfThings.html Module and Localization].  In [[PKC Workflow]], the following pages serve as this kind of localized resource.
serve as this kind of localized resource.
# [[PKC Workflow/Meeting and Communication|Meeting and Communication]]
# [[PKC Workflow/Meeting and Communication|Meeting and Communication]]
# [[PKC Workflow/Issues|Issue]]
# [[PKC Workflow/Issues|Issue]]
Line 66: Line 59:
[[wikipedia:Modular programming|Modular programming]] is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. A Process in [[Logic Model]] could be divided into SubModels.  [[How Logic model relates with SubModels]]
[[wikipedia:Modular programming|Modular programming]] is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. A Process in [[Logic Model]] could be divided into SubModels.  [[How Logic model relates with SubModels]]
All the submodels in [[PKC Workflow]]:  
All the submodels in [[PKC Workflow]]:  
 
=== System Verification ===
{{LogicModel
{{LogicModel
|name = TLA Workflow  
|name = PKC Workflow/System Verification
}}
}}
 
=== Jenkins Integration  ===
{{LogicModel
{{LogicModel
|name = PKC Workflow/Jenkins Integration   
|name = PKC Workflow/Jenkins Integration   
}}
}}
 
=== Docker Registry ===
{{LogicModel|name=PKC Workflow/Task/Docker Installation}}
{{LogicModel|name=PKC Workflow/Docker Registry}}
 
 
 
 
 
 
== Branch primitive ==
[https://reference.wolfram.com/language/guide/FlowControl.html FlowControl primitives of Mathematica]
 
</noinclude>
</noinclude>

Latest revision as of 04:32, 30 August 2021

  1. System Verification by TLA+
  2. Jenkins Integration
  3. Docker Registry
  4. Meeting and Communication
  5. Issues
  6. Updates
  7. All activities


When describing a process, it could be confusing as a process relates some inputs to outputs. The information entity such as Issue could mean either a process of issuing or the issue result presenting as a page.

When describing a process in the macroscope, it is always a verb. The input/output is defined according to the function's specification. <graphviz> digraph G {

   rankdir=LR
   input [URL="PKC Workflow/Input"];
   process [URL="PKC Workflow/Process"];
   output [URL="PKC Workflow/Output"];
   input->process;
   process->output;

} </graphviz>


There are 2 possible reasons why the input/output might be incomplete:

  1. Stateful functions which cause side effects or dependence on global variables: It is the trade-off when using functional representation. To stick to the functional representation style, we should think about how to reorganize the function so that it is closer to stateless.
  2. Not capturing the input/output that a function cares about: Ideally, every input/output should be captured at least in low precision (type system). But since there are complexity and obscurity when describing real-world knowledge, it is possible that the input/output is incomplete.


When describing the inner structure of a process, there are more kinds of modeling methods (we can see this in the complexity of programming). It is feasible to add more structure (corresponding to different semantics) but note that a compact structure (desired traits of knowledge representation) is preferable.

Loop

In the simplest form, the process is the mapping of input to output. To describe the recurring event in the project, we add a Loop structure on top of it. See the LoopingConstructs Primitive in Mathematica The diagram representing the function with loop will be:

  • (Need to specify the LISP processing language, which is its origin)
  • Everything is a list

<graphviz> digraph G {

   rankdir=LR
   input [URL="PKC Workflow/Input"];
   process [URL="PKC Workflow/Process"];
   output [URL="PKC Workflow/Output"];
   input->process;
   process->process [label="recursive"];
   process->output;

} </graphviz>

State

In a process, there are data generated alongside but isn't intended to serve as the output or expose outside the process. In programming, it corresponds to Module and Localization. In PKC Workflow, the following pages serve as this kind of localized resource.

  1. Meeting and Communication
  2. Issue
  3. Activities
  4. Updates and reports

Subprocess

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. A Process in Logic Model could be divided into SubModels. How Logic model relates with SubModels All the submodels in PKC Workflow:

System Verification

Logic Model (PKC Workflow/System Verification) Template:LogicModel 08 30, 2021
Abstract Specification
Context
  1. To analyze a system correctly before it is implemented, a language to model the system and automatic tools to prove the system is required.
  2. TLA+ is a high-level language for modeling programs and systems--especially concurrent and distributed ones.
Goal
  1. To state the system's preferred conditions and determine them.
Success Criteria
  1. The specified properties are determined.
Concrete Implementation
Given Inputs When Process is executed... Then, we get Outputs
  1. Software/TLA+ Tools
  2. PKC System Specification
  3. Knowledge/TLA+ Tools
  1. PKC System Result
  2. Producer-Consumer System example
Boundary/Safety Conditions of PKC Workflow/System Verification
  1. Determine what the PKC system should achieve.
  2. Finish within 1 week of time

Jenkins Integration

Logic Model (PKC Workflow/Jenkins Integration) Template:LogicModel 08 30, 2021
Abstract Specification
Context
  1. The Universal Data Abstraction includes data scheme of Page/File/Service.
  2. Jenkins is an automation server for users to interact with services.
Goal
  1. To integrate automation server with PKC to build a workflow engine
Success Criteria
  1. Users could manipulate programmable objects on other application in PKC page.
Concrete Implementation
Given Inputs When Process is executed... Then, we get Outputs
  1. Jenkins setup
  2. A service namespace
  1. Specify a namespace to express the interaction with service.
  2. Activity:Learn Lua
  3. Create a Lua based module which takes parametrized inputs.
  1. A complete service namespace.
  2. A module serving as interface for users to interact
Boundary/Safety Conditions of PKC Workflow/Jenkins Integration
  1. Finish within 1 week of time

Docker Registry

Logic Model (PKC Workflow/Docker Registry) Template:LogicModel 08 30, 2021
Abstract Specification
Context
  1. The Mediawiki container on thewiki.us contains software which are constantly changing.
Goal
  1. Specify and docker registry workflow of PKC and test.
Success Criteria
  1. The process are investigated and streamlined.
  2. Users follow and improve the workflow.
  3. The tags are named properly.
Concrete Implementation
Given Inputs When Process is executed... Then, we get Outputs
  1. Docker
  2. Docker registry tutorial
  3. Image Naming
  1. Pull and build a docker registry image from the official website. [1].
  2. For the target container to be versioned, commit the container.
  3. Push to the local registry and then test whether it succeeded.
  4. Install some extensions and make a software version from it.
  1. All Images
Boundary/Safety Conditions of PKC Workflow/Docker Registry
  1. By now we only test the workflow on thewiki.us server. More servers should be tested in the future.