You are currently browsing the category archive for the ‘Software development’ category.

There is an attractive presentation about presenting knowledge from the various roles like practicians, software people, and scientists: How to tell stuff to the computer. It describes a triangle (see below), whose corners are practical domain knowledge (lower left corner), software artifacts (top corner) and science (low right corner). The picture proposes some technologies inside the triangle. The most important things in the triangle are – in writer’s opininion – the steps in the lines connecting corners.

Triangle of Knowledge Representation (KR, see http://www.lisperati.com).

In his/hers conclusion the writer forecasts that in future there is a revolution, caused by descriptive logics (see http://www.lisperati.com/tellstuff/conclusion.html). I warmly agree that conclusion, because logic has a very strong role in the framework of symbolic analysis.

Instead, it is difficult to see what is the beef in the desriptive logic here: http://www.lisperati.com/tellstuff/dl.html, the text contains traditional monolitic Lisp. However, the idea of the title: Marriage of Logic and Objects is a very good vision. I have had the same goal in the architecture of AHO hybrid objects. Furthermore, there is a solid contact surface between semantic web and symbolic analysis (see more).

Symbolic and holistic approach for estimating knowlege produced by the software

The triangle (above) is useful as a base for illlustrating software development and its knowledghe representation, too.  In the lower triangle (see below) I have named the corners respectively: Domain knowlege, source of program and information system (IS) pragmatics caused by the software.

Software Knowledge Representation (SKR). (Laitila 2010)

The last corner is not science as in the triangle about, but it simulates all purposes to understand the software and its value as an empiric product. The last corner is then an attempt to get empiric and practical research information from the implemented software. It is then a large approach. It has two sides:

  1. problem specific approach supported by reverse engineering and
  2. holistic approach in order to evaluate the whole

There some essential roles in the figure. All essential information is thought to be stored into an imagined megamodel (specification, resource information, sprints, tests etc).

The three lines are:

  1. The left line describes software development, to code.
  2. The line from top to the right lower corner is symbolic analysis containing the technology spaces: GrammarWare, ModelWare, SimulationWare and KnowledgeWare. For practical purposes there is a problem reasonign technology (PRT) close to the right corner.
  3. The bottom line is a problem, because there is no direct support for estimating how does a system satisfy all possible user needs, but there are some technologies to create end user services so that they can be mapped into code and remain visible in the system. SOA, aspects, Zachman architecture and metrics are some means for that purpose.

Some links:

Advertisements

Thought and thinking are mental forms and processes, respectively (“thought” is both). Thinking allows beings to model the world and to represent it according to their objectives, plans, ends and desires. Words referring to similar concepts and processes include cognition, sentience, consciousness, idea, and imagination


Programming is a way of thinking and planning code. He/ske uses mental models for that. The output of programmer's thinking are symbols.

The chain of the programmer’s work is described by the theory J.S.Bruner’s theory of Enactive, iconic, symbolic representations of knowledge.

Some relevant links to describe programmer’s mental models from the cognitive approach are:

The main purpose of this blog has been to express the huge approach considering symbolic analysis and its relevant references in core computer science. There are exactly 100 posts in it just now.

However, it is hard to realize what is the function of analysis in that wide approach. In order to clarify that wide scope we suggest a new term to illustrate the whole functionality of symbols to allow expressing key ideas of computer science using symbols.

Symbol Driven Engineering

When MDE (Model Driven Engineering) is a discipline to support software development using models, we propose Symbol Driven Engineering,  SDE is a discipline to support software development using symbols. In this blog there are now 15 posts about symbolic computation.  The best relevance for SDE can be found at the post: https://symbolicanalysis.wordpress.com/2009/11/12/symbol-is-the-core-of-computer-science/

SDE can be used in programming in order to emphasize the role of symbols and their semantics in formulating new code.

SDE is an umbrella term for symbolic analysis, too.

The main formalism of SDE comes from four technology spaces: GrammarWare, ModelWare, SimulatioWare and KnowledgeWare.

Below the purpose of SDE for corrective maintenance is shown.

Some links:

SWRL:

SWRL is a Semantic Web Rule Language, which combines OWL and RuleML

An OWL ontology in the abstract syntax contains a sequence of axioms and facts. Axioms may be of various kinds, e.g., subClass axioms and equivalentClass axioms. It is proposed to extend this with rule axioms.

axiom ::= rule

A rule axiom consists of an antecedent (body) and a consequent (head), each of which consists of a (posibly empty) set of atoms. A rule axiom can also be assigned a URI reference, which could serve to identify the rule.

rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')'
antecedent ::= 'Antecedent(' { atom } ')'
consequent ::= 'Consequent(' { atom } ')'

Informally, a rule may be read as meaning that if the antecedent holds (is “true”), then the consequent must also hold. An empty antecedent is treated as trivially holding (true), and an empty consequent is treated as trivially not holding (false). Rules with an empty antecedent can thus be used to provide unconditional facts; however such unconditional facts are better stated in OWL itself, i.e., without the use of the rule construct. Non-empty antecedents and consequents hold iff all of their constituent atoms hold, i.e., they are treated as conjunctions of their atoms. As mentioned above, rules with conjunctive consequents could easily transformed into multiple rules each with an atomic consequent. This principles leads to an atomistic approach, similar to Symbolic Analysis.

OWL’s atom is like this:

atom ::= description '(' i-object ')'
	 | dataRange '(' d-object ')'
	 | individualvaluedPropertyID '(' i-object i-object ')'
	 | datavaluedPropertyID '(' i-object d-object ')'
	 | sameAs '(' i-object i-object ')'
	 | differentFrom '(' i-object i-object ')'
	 | builtIn '(' builtinID { d-object } ')'
builtinID ::= URIreference

Let’s see AHO to compare it into the atom of Symbolic Analysis.

Comparing RuleML and Prolog

Prolog:

discount(customer,product1,’5.0 percent’) :-
premium(customer),regular(product).

The corresponding XML-query in RuleML:

<imp>
<_head>
<atom>
<_opr><rel>discount</rel></_opr>
<var>customer</var>
<var>product</var>
<ind>5.0 percent</ind>
</atom>
</_head>
<_body>
<and>
<atom>
<_opr><rel>premium</rel></_opr>
<var>customer</var>
</atom>
<atom>
<_opr><rel>regular</rel></_opr>
<var>product</var>
</atom>
</and>
</_body>
</imp>

Example:

A simple use of these rules would be to assert that the combination of the hasParent and hasBrother properties implies the hasUncle property. Informally, this rule could be written as:

hasParent(?x1,?x2) and hasBrother(?x2,?x3) ==> hasUncle(?x1,?x3)

In the abstract syntax the rule would be written like:

Implies(Antecedent(hasParent(I-variable(x1) I-variable(x2))
		   hasBrother(I-variable(x2) I-variable(x3)))
	Consequent(hasUncle(I-variable(x1) I-variable(x3))))

From this rule, if John has Mary as a parent and Mary has Bill as a brother then John has Bill as an uncle.

In RuleML it is:

<ruleml:imp>
  <ruleml:_rlab ruleml:href="#example1"/>
  <ruleml:_body>
    <swrlx:individualPropertyAtom  swrlx:property="hasParent">
      <ruleml:var>x1</ruleml:var>
      <ruleml:var>x2</ruleml:var>
    </swrlx:individualPropertyAtom>
    <swrlx:individualPropertyAtom  swrlx:property="hasBrother">
      <ruleml:var>x2</ruleml:var>
      <ruleml:var>x3</ruleml:var>
    </swrlx:individualPropertyAtom>
  </ruleml:_body>
  <ruleml:_head>
    <swrlx:individualPropertyAtom  swrlx:property="hasUncle">
      <ruleml:var>x1</ruleml:var>
      <ruleml:var>x3</ruleml:var>
    </swrlx:individualPropertyAtom>
  </ruleml:_head>
</ruleml:imp>

In Prolog it is:

hasUncle(X1, X3):-

hasParent(X1, X2), hasBrother(X2, X3).

Comparison: Semantics of Semantic Web and Symbolic Analysis

Some differences between the Semantic Web policy and the one of Symbolic Analysis.

Atom Condition on Interpretation
C(x) S(x) ∈ EC(C)
D(z) S(z) ∈ EC(D)
P(x,y) <S(x),S(y)> ∈ ER(P)
Q(x,z) <S(x),L(z)> ∈ ER(Q)
sameAs(x,y) S(x) = S(y)
differentFrom(x,y) S(x) ≠ S(y)
builtIn(r,z1,…,zn) <S(z1),…,S(zn)> ∈ D(f)

In Symbolic Analysis all definitions are clauses. The clause has its Prolog-based syntax, being a fact. However, the principles and the main goal have many similar features.

Some links

OBS:

Atom is a system for distribution of information on the web (see http://semtext.org/atom/atom-semweb.htm). It is also a project that aims to create weblog and syndication formats and APIs that the developers can unite behind, allowing future progress in these fields without the political and technical problems that have plagued developers over recent years. The project was initiated by Sam Ruby, and is being developed collaboratively on a Wiki.

From Wiki: A programming language is an artificial language designed to express computations that can be performed by a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine, to express algorithms precisely, or as a mode of human communication.

A programming language is a notation for writing programs, which are specifications of a computation or algorithm.[1] Some, but not all, authors restrict the term “programming language” to those languages that can express all possible algorithms.

All Turing complete languages can implement the same set of algorithms.

Some links:

  1. Language
  2. Programming paradigms (Wiki)

From Wiki:

A language is a system for encoding and decoding information. In its most common use, the term refers to so-called “natural languages” — the forms of communication considered peculiar to humankind.

Mathematics and computer science use artificial entities called formal languages (including programming languages and markup languages, and some that are more theoretical in nature). These often take the form of character strings, produced by a combination of formal grammar and semantics of arbitrary complexity.

A programming language is a formal language endowed with semantics that can be used to control the behavior of a machine, particularly a computer, to perform specific tasks. Programming languages are defined using syntactic and semantic rules, to determine structure and meaning respectively.

Programming languages are used to facilitate communication about the task of organizing and manipulating information, and to express algorithms precisely. Some authors restrict the term “programming language” to those languages that can express all possible algorithms; sometimes the term “computer language” is used for artificial languages that are more limited.

Links:

  1. Formal languages.
  2. Programming languages.

From Wiki: Feature Oriented Programming (FOP) or Feature Oriented Software Development (FOSD) is a general paradigm for program synthesis in software product lines.

Some links:

  1. FeatureHouse: Language-Independent, Automated Software Composition.

Reverse engineering is a process to transform software via GrammarWare, typically via ModelWare, to Knowledge in order to answer the questions, typical for MaintenanceWare. This process can be modelled as a chain of automata A1 to A7, where user is the last link of the chain.

Reverse_engineering_Automata

FIGURE 3.

There is an explanation for the figure on page 58 in the book.

Software development is a process to convert user (project) requirements to knowledge related topics (KnowledgeWare) and via optional models (ModelWare) to a grammar related notation (GrammarWare), the code (software) to be executed in hardware.

Erkki Laitila, PhD (2008) computer engineer (1977)