Difference between revisions of "Theory of Documentation"
(→Functional Sequences of Events) |
|||
(64 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | = Introduction = | |
+ | This is an unnecessary analysis of computer information systems in which I act like I know what I'm talking about in an effort to make a much more precise documentation framework. According to my intuition the odds of complete, well thought-out models of people <-> I.T. interaction approach zero. Yet, here is a system I pulled out of my ass using terminology that ''I hope'' I individually created--although more likely have heard before--and am here now to invent some ill-misconceived usage that probably runs oblique to the historic usage. | ||
− | + | = History and Motivation = | |
− | + | I have found that even if a system of documentation drives me personally insane--to those of whom it doesn't cause a mental state of dissociation--it still presents a significant challenge. When it comes to technical support of computer information systems, oft times people don't know what exactly they are looking for and it is at this ''exact'' instance that a ''precise'' system of arrangement with an understanding of where you are in the knowledge continuum is most necessary: Otherwise the time-consuming process of creating documentation is wasted as the knowledge isn't actually put to efficient use. | |
− | I have found that even if a system of documentation drives me personally insane--to those of whom it doesn't cause a mental state of dissociation--it still presents a significant challenge. When it comes to technical support of computer information systems oft times people don't know what exactly they are looking for and it is at this exact instance that a precise system of arrangement is most necessary: Otherwise the time-consuming process of creating documentation is wasted as the knowledge isn't actually put to efficient use. | + | |
Sets, classes, families, etc. are probably the most intuitive arrangement of systems as they follow from the fundamental thinking processes of the mind. Here I have come up with an informal model, although somewhat mathematical in nature, to address and classify every piece of the system in a more precisely ordered way. | Sets, classes, families, etc. are probably the most intuitive arrangement of systems as they follow from the fundamental thinking processes of the mind. Here I have come up with an informal model, although somewhat mathematical in nature, to address and classify every piece of the system in a more precisely ordered way. | ||
Line 9: | Line 9: | ||
Looking at this from the point of view of typical I.T. documentation it will seem rather unnecessary and abstract at first. Bear with me--I believe the analysis will result in a much more precise system. Then we can all find divinity. | Looking at this from the point of view of typical I.T. documentation it will seem rather unnecessary and abstract at first. Bear with me--I believe the analysis will result in a much more precise system. Then we can all find divinity. | ||
+ | = The Model = | ||
== Events of Things with Associated Actions == | == Events of Things with Associated Actions == | ||
− | + | *Our set-theoretic universe is the set of '''things''', of which each thing is in a certain immutable state, as well as a separate set of respective operations or '''associated actions''' on, or performed by, those things.<br /> | |
− | *Our universe is the set of '''things''', | + | **Each state of a thing is a separate element--That is, ''things with multiple states are actually multiple elements'' of individual things, each in their own single, certain, immutable state.<br /> |
− | **Each state of a thing is a separate element--That is, ''things with multiple states are actually multiple elements'' of individual things, each in their own | + | |
**An ''action can be the change of state, or the cause'' of a change of state.<br /> | **An ''action can be the change of state, or the cause'' of a change of state.<br /> | ||
**A ''thing has a separate state for each associated action'' it performs.<br /> | **A ''thing has a separate state for each associated action'' it performs.<br /> | ||
**Multiple things can be associated with a single action as well as multiple actions with a single thing--''things and actions can have n-way associations'', where n is a positive integer.<br /> | **Multiple things can be associated with a single action as well as multiple actions with a single thing--''things and actions can have n-way associations'', where n is a positive integer.<br /> | ||
− | * | + | *An unordered pair formed of a single ''thing'' with an ''associated action'' is called an '''event'''.<br /> |
**A ''sequence formed of multiple events'' using the shared associations of things or actions in each preceding or following event is called a '''sequence of events'''.<br /> | **A ''sequence formed of multiple events'' using the shared associations of things or actions in each preceding or following event is called a '''sequence of events'''.<br /> | ||
*The set of ''events that occur due to being caused'' by another event action are called '''secondary events'''.<br /> | *The set of ''events that occur due to being caused'' by another event action are called '''secondary events'''.<br /> | ||
Line 26: | Line 26: | ||
**With this model ''people'' are typically the primary actors.<br /> | **With this model ''people'' are typically the primary actors.<br /> | ||
− | The computer information systems we are dealing with can be broken down into things, actions, events, sequences and actors.<br /> | + | The computer information systems we are dealing with can be broken down into ''things'', ''actions'', ''events'', ''sequences'' and ''actors''.<br /> |
== Types of Actors == | == Types of Actors == | ||
+ | By building events from things and actions we are able to identify sequences of events and thus actors within these sequences. In actuality, primary actors aren't the result of our set building but the set building is precipitated out of the need to address the literal interaction of people (the primary actors) and computer information systems, in a figurative model. | ||
− | + | The types of actors are discerned by the role of the person causing the event. Furthermore, those sequences of events follow a classification order of which those roles follow from clear boundaries--in other words a role is more than arbitrary set but can be clearly defined. | |
− | + | ||
− | The types of actors are discerned by the role of the person causing the event. Furthermore, those sequences of events follow a classification order of which those roles follow from clear boundaries. | + | |
== Functional Sequences of Events == | == Functional Sequences of Events == | ||
− | |||
Computer I.T. systems are put in place to serve the purposes the people. Primary actors aren't a result from the system. | Computer I.T. systems are put in place to serve the purposes the people. Primary actors aren't a result from the system. | ||
+ | === Example: A person using a web browser to request a static web page from a remote server. === | ||
+ | *There is a clear ''sequence of events'' in which the person begins as a ''primary actor''. | ||
+ | *Some ''things'' in the sequence could be: the web-browser, networking protocols, and the web-server daemon. | ||
+ | *Some ''actions'' include changing the web-browser state to requesting a page, ''causing'' a change of state in the various protocols, which in turn causes the web server to change to the state of responding with the specific page. | ||
+ | *Every ''event'' except the first includes an ''autonomous actor'' | ||
+ | *Each event with an autonomous actor is precisely defined in that there is a clear cause and result. | ||
+ | **Each individual event has the notion of mathematical functionality or is a '''functional event'''. | ||
+ | *The overall sequence of events also has clear cause and result. | ||
+ | **Thus a mathematical notion comes into play as it is called (by me--the author who is ''acting'' knowledgeable) a ''functional sequence of events'' or just a '''functional sequence'''. | ||
+ | |||
+ | == Roles of Functional Sequences == | ||
+ | === Criterion Defined === | ||
+ | *A single event or single sequence of events in and of itself isn't really that complicated of a function since it is essentially a set of events that are either "activated" or not. | ||
+ | *Forming sets of events or sequences of events essentially composes a function from all the functional sequences the set contains. | ||
+ | **The new function can have multiple possible starting states or actions mapped by their respective functional sequences to the ending states or actions. | ||
+ | *Each set of functional sequences ''defined by specific criterion'' form a '''role'''. | ||
+ | **Example: The set of all functional sequences in support of listening for HTTP connections, and delivering content through those respective connections is a ''role'' of which we label a web server daemon. | ||
+ | |||
+ | === Example Criterion === | ||
+ | *Sets of functional sequences or events that reach the same respective functional sequences or events | ||
+ | *Sets of functional sequences or events that have a purpose of creating new things and actions and thus events | ||
+ | *Sets of functional sequences or events that have actions on--thus selecting specific (states of) ''things'' and thus subsets formed. | ||
+ | *Sets of functional sequences or events that remove things and actions. | ||
+ | |||
+ | == Primary Actor Procedures Within Roles of Functional Sequences == | ||
+ | *There are criterion that form (super-)sets of functional sequences that make up a role of which the ''functional sequences are not directly connected through autonomous events.'' | ||
+ | *These functional sequences are connected through a ''functional sequence outside of the model'' involving individual ''primary actors'' inside of the model. | ||
+ | *In terms of our model these functional sequences that lie outside of the model are called '''procedures of primary events''' or just '''procedures'''. | ||
+ | |||
+ | |||
+ | = Abstraction in the Model = | ||
+ | *Sets of functional sequences or events defined by specific criterion or '''roles''' can be abstracted into a new simplified set of things with states and associated actions. | ||
+ | **Example: A static web site could be modeled as the states of receiving requests and sending each page which encompasses all of the roles in support of it. | ||
+ | ***Notice that each level of abstraction can be expanded until we have the set of Boolean states of the physical machine or even the super-set of Boolean states of a quantum machine. | ||
+ | ***Yet, each role isn't defined by some unquantifiable notion but by specific criterion. | ||
+ | |||
+ | |||
+ | = Models = | ||
+ | Applying this I want to construct some models using this theory as a guideline, but not necessarily quantifying every notion as I refine the theory as well as the models. | ||
+ | == XM Hosting == | ||
+ | '''Dump-Zone Here''' | ||
+ | === Roles Brainstorm === | ||
+ | *CPU, Ram, Disk, Network Connection, Bare-Metal, Virtual Machine, Ubuntu, IPv4, IPv6, Apache httpd, Nginx, Web Server, PHP4, PHP5, PHP-FPM, PHP, Database, SQL, MySQL, Odin, Parallels, Plesk, Hosting, Client, Server, WWW, Web Browser, User Agent, SaltStack, Python, Perl, Programming, Language, Environment, | ||
+ | *Technical Support, Systems Administration, Product Management, Sales, Network Administration, | ||
+ | *VP of Operations, VP of Finance, Director of Business Systems, VP of Business Development, Director of Marketing, Director of Broadband Services, Director of Network Operations, Product Manager, Web Designer/Creative Manager, Sales Supervisor, Sales Team Member, Billing Team Member, Support Supervisor, Support Resource Group, Support Team Member, Stackable Lead Architect, Systems Administrator, Mail Systems Administrator, Lead Developer, Data Communications Administrator, Director of Web Hosting and Domains, Colocation Services Manager, Lead Software Engineer, | ||
+ | *Unlimited Shared Web Hosting, | ||
+ | === Roles by Type === | ||
+ | *Support | ||
+ | **Everything related to using established roles. | ||
+ | *Administration | ||
+ | **Everything related to establishing already existing roles and maintaining them. | ||
+ | *Development | ||
+ | **Everything related to creating new roles. | ||
− | + | = Links = | |
− | * | + | * [http://www.mkdocs.org/ http://www.mkdocs.org/] |
− | * | + | * [http://docbook.org/ http://docbook.org/] |
− | * | + | * [http://asciidoc.org/ http://asciidoc.org/] |
Latest revision as of 16:07, 8 March 2017
Contents
Introduction
This is an unnecessary analysis of computer information systems in which I act like I know what I'm talking about in an effort to make a much more precise documentation framework. According to my intuition the odds of complete, well thought-out models of people <-> I.T. interaction approach zero. Yet, here is a system I pulled out of my ass using terminology that I hope I individually created--although more likely have heard before--and am here now to invent some ill-misconceived usage that probably runs oblique to the historic usage.
History and Motivation
I have found that even if a system of documentation drives me personally insane--to those of whom it doesn't cause a mental state of dissociation--it still presents a significant challenge. When it comes to technical support of computer information systems, oft times people don't know what exactly they are looking for and it is at this exact instance that a precise system of arrangement with an understanding of where you are in the knowledge continuum is most necessary: Otherwise the time-consuming process of creating documentation is wasted as the knowledge isn't actually put to efficient use.
Sets, classes, families, etc. are probably the most intuitive arrangement of systems as they follow from the fundamental thinking processes of the mind. Here I have come up with an informal model, although somewhat mathematical in nature, to address and classify every piece of the system in a more precisely ordered way.
Looking at this from the point of view of typical I.T. documentation it will seem rather unnecessary and abstract at first. Bear with me--I believe the analysis will result in a much more precise system. Then we can all find divinity.
The Model
Events of Things with Associated Actions
- Our set-theoretic universe is the set of things, of which each thing is in a certain immutable state, as well as a separate set of respective operations or associated actions on, or performed by, those things.
- Each state of a thing is a separate element--That is, things with multiple states are actually multiple elements of individual things, each in their own single, certain, immutable state.
- An action can be the change of state, or the cause of a change of state.
- A thing has a separate state for each associated action it performs.
- Multiple things can be associated with a single action as well as multiple actions with a single thing--things and actions can have n-way associations, where n is a positive integer.
- Each state of a thing is a separate element--That is, things with multiple states are actually multiple elements of individual things, each in their own single, certain, immutable state.
- An unordered pair formed of a single thing with an associated action is called an event.
- A sequence formed of multiple events using the shared associations of things or actions in each preceding or following event is called a sequence of events.
- A sequence formed of multiple events using the shared associations of things or actions in each preceding or following event is called a sequence of events.
- The set of events that occur due to being caused by another event action are called secondary events.
- Secondary events can also be called autonomous events with their respective things called autonomous actors.
- A contrary set of events that do not occur as the result of other events actions, are primary events.
- The respective things in these primary events are called primary actors.
- The respective things in these primary events are called primary actors.
- Primary actors are the start of every sequence of events.
- With this model people are typically the primary actors.
- With this model people are typically the primary actors.
The computer information systems we are dealing with can be broken down into things, actions, events, sequences and actors.
Types of Actors
By building events from things and actions we are able to identify sequences of events and thus actors within these sequences. In actuality, primary actors aren't the result of our set building but the set building is precipitated out of the need to address the literal interaction of people (the primary actors) and computer information systems, in a figurative model.
The types of actors are discerned by the role of the person causing the event. Furthermore, those sequences of events follow a classification order of which those roles follow from clear boundaries--in other words a role is more than arbitrary set but can be clearly defined.
Functional Sequences of Events
Computer I.T. systems are put in place to serve the purposes the people. Primary actors aren't a result from the system.
Example: A person using a web browser to request a static web page from a remote server.
- There is a clear sequence of events in which the person begins as a primary actor.
- Some things in the sequence could be: the web-browser, networking protocols, and the web-server daemon.
- Some actions include changing the web-browser state to requesting a page, causing a change of state in the various protocols, which in turn causes the web server to change to the state of responding with the specific page.
- Every event except the first includes an autonomous actor
- Each event with an autonomous actor is precisely defined in that there is a clear cause and result.
- Each individual event has the notion of mathematical functionality or is a functional event.
- The overall sequence of events also has clear cause and result.
- Thus a mathematical notion comes into play as it is called (by me--the author who is acting knowledgeable) a functional sequence of events or just a functional sequence.
Roles of Functional Sequences
Criterion Defined
- A single event or single sequence of events in and of itself isn't really that complicated of a function since it is essentially a set of events that are either "activated" or not.
- Forming sets of events or sequences of events essentially composes a function from all the functional sequences the set contains.
- The new function can have multiple possible starting states or actions mapped by their respective functional sequences to the ending states or actions.
- Each set of functional sequences defined by specific criterion form a role.
- Example: The set of all functional sequences in support of listening for HTTP connections, and delivering content through those respective connections is a role of which we label a web server daemon.
Example Criterion
- Sets of functional sequences or events that reach the same respective functional sequences or events
- Sets of functional sequences or events that have a purpose of creating new things and actions and thus events
- Sets of functional sequences or events that have actions on--thus selecting specific (states of) things and thus subsets formed.
- Sets of functional sequences or events that remove things and actions.
Primary Actor Procedures Within Roles of Functional Sequences
- There are criterion that form (super-)sets of functional sequences that make up a role of which the functional sequences are not directly connected through autonomous events.
- These functional sequences are connected through a functional sequence outside of the model involving individual primary actors inside of the model.
- In terms of our model these functional sequences that lie outside of the model are called procedures of primary events or just procedures.
Abstraction in the Model
- Sets of functional sequences or events defined by specific criterion or roles can be abstracted into a new simplified set of things with states and associated actions.
- Example: A static web site could be modeled as the states of receiving requests and sending each page which encompasses all of the roles in support of it.
- Notice that each level of abstraction can be expanded until we have the set of Boolean states of the physical machine or even the super-set of Boolean states of a quantum machine.
- Yet, each role isn't defined by some unquantifiable notion but by specific criterion.
- Example: A static web site could be modeled as the states of receiving requests and sending each page which encompasses all of the roles in support of it.
Models
Applying this I want to construct some models using this theory as a guideline, but not necessarily quantifying every notion as I refine the theory as well as the models.
XM Hosting
Dump-Zone Here
Roles Brainstorm
- CPU, Ram, Disk, Network Connection, Bare-Metal, Virtual Machine, Ubuntu, IPv4, IPv6, Apache httpd, Nginx, Web Server, PHP4, PHP5, PHP-FPM, PHP, Database, SQL, MySQL, Odin, Parallels, Plesk, Hosting, Client, Server, WWW, Web Browser, User Agent, SaltStack, Python, Perl, Programming, Language, Environment,
- Technical Support, Systems Administration, Product Management, Sales, Network Administration,
- VP of Operations, VP of Finance, Director of Business Systems, VP of Business Development, Director of Marketing, Director of Broadband Services, Director of Network Operations, Product Manager, Web Designer/Creative Manager, Sales Supervisor, Sales Team Member, Billing Team Member, Support Supervisor, Support Resource Group, Support Team Member, Stackable Lead Architect, Systems Administrator, Mail Systems Administrator, Lead Developer, Data Communications Administrator, Director of Web Hosting and Domains, Colocation Services Manager, Lead Software Engineer,
- Unlimited Shared Web Hosting,
Roles by Type
- Support
- Everything related to using established roles.
- Administration
- Everything related to establishing already existing roles and maintaining them.
- Development
- Everything related to creating new roles.