Experimental Actions With Conceptual Objects

Experimental Actions With Conceptual Objects

DOI: 10.4018/978-1-5225-2987-3.ch003
OnDemand PDF Download:
List Price: $37.50


In the previous Chapter, we described the direction of decreasing the differences between interactions of a human with natural and computer environments. The basic feature of this direction is to create appropriate conditions for the real-time intertwining of both types of interactions in designer's activity. In this Chapter, we pay our attention to such kind of designer's activity as solving the project tasks at the conceptual stage of designing. We consider these tasks as a dynamic system described as a project theory of a substantially evolutionary type. Such position leads to useful inheritances from the scientific practice. The basic inheritances are the becoming of the theory of the project and applying the thought experiments. The becoming of the theory is coordinated with the use of the stepwise refinement (based on question-answer analysis) and design thinking in their applications to the solving the project tasks. Conceptual experiments are considered as means for verifying the theory constructs.
Chapter Preview

1. Substantially Evolutionary Approach To Designing The Systems

1.1. Theorization in Designing the Systems

In its initial settings, and even in the title, the SEMAT-approach stresses the need for theorizing the foundations of software engineering. In the same time, the normative document “Kernel and Language for Software Engineering Methods, Version 1.1” does not include constructive answers about the creation and use of appropriate theories in the development of software systems.

Even with the coordination of positions on the initiative SEMAT and in the early stages of evolution in SEMAT, A. Cocburn criticized this aspect of the approach (Cockburn, 2010). In recent years, there were a numerous attempts to offer versions of theorization. Some of these attempts and their results were presented in four workshops on General Theory of Software Engineering (GTSE 2011-2015) and 5th International Workshop on Theory-Oriented Software Engineering (2016). At the same time, it can be stated that the satisfactory general theory is absent till now.

Typically, after workshop its results have been generalized, and, for example, such report for the second workshop indicated that the theory should “explain and predict software engineering phenomena at multiple levels, including social processes and technical artifacts, should synthesize existing theories from software engineering and reference disciplines, should be developed iteratively, should avoid common misconceptions and atheoretical concepts, and should respect the complexity of software engineering phenomena” (Johnson, 2013).

Reports of the next workshop extended features that must find their embodiment in content and responsibility of a GTSE, for example, the report on results of the third workshop marked papers of following authors:

Ralph (Ralph, 2014) who “distinguished between variance theories (which predict a dependent variable regarding independent variables) and process theories (which explain how a phenomenon occurs).”

Ng (Ng, 2014) who “proposed a software engineering approach informed by Essence. It posits

that every software project is unique and sensitive to its context.”

Very often, researchers, which were participated in attempts to build the general theory have referenced on the paper (Sjoberg, 2006) that includes an analysis of assignments of theories and a way for creating the useful theories oriented on their applications in software engineering.

In their research, authors of this paper referenced on the following classification that was specified in (Sjoberg, 2006):

  • 1.

    Analysis: Theories of this type include descriptions and conceptualizations of “what is.” Also included are taxonomies, classifications, and ontologies.

  • 2.

    Explanation: Theories of this type explicitly explain. What constitutes an explanation is a nontrivial issue. However, a common view is that an explanation answers to a question of why something is – or happens (rather than what happens).

  • 3.

    Prediction: These theories are geared towards predicting what will happen, without explaining why.

  • 4.

    Explanation and Prediction: Theories of this type combine the traits of II and III and correspond to what many consider a “standard” conception of empirically-based theories.

  • 5.

    Design and Action: These theories describe “how to do” things, that is, they are prescriptive.

Additionally, the paper (Sjoberg, 2006) analyzed following steps that help to build the certain theory:

  • 1.

    Defining the Constructs of the Theory.

  • 2.

    Defining the Propositions of the Theory.

  • 3.

    Providing Explanations to Justify the Theory.

  • 4.

    Determining the Scope of the Theory.

  • 5.

    Testing the Theory Through Empirical Research.

Then, in An Initial Theory for UML-Based Development in Large Projects, for demonstrating this way, these steps have been applied for building “An Initial Theory for UML-Based Development in Large Projects.” The developed theory was evaluated by authors with the use of following characteristics:

  • Testability as the degree to which theory is constructed such that empirical refutation is possible.

  • Empirical support as the degree to which theory is supported by empirical studies that confirm its validity.

  • Explanatory power as the degree to which a theory accounts for and predicts all known observations within its scope is simple in that it has few ad hoc assumption, and relates to that which is already well understood.

  • Parsimony as the degree to which theory is economically constructed with a minimum of concepts and propositions.

  • Generality as the breadth of the scope of a theory and the degree to which the theory is independent of specific settings.

  • Utility as the degree to which a theory supports the relevant areas of the software industry.

For our reasoning that will be lower, we note one more paper (Perry, 2015), which was called “Theories, Theories Everywhere,” and where its author claimed that a general theory of software engineering must have “two logical parts: design and evaluation, D and E, each of which as a theory T.” On the base of an analysis of this position, the author “delineate a rich variety of theories related to D and E and consider these to be sub-theories critical to understanding the relationships between the theories in D and E.”

In specifications of analysis results, it is used such construct as model M the essence of which clarifies the following assertion « a theory T (a more or less abstract entity) is reified, represented, satisfied, etc., by a model M (a concrete entity).» In the paper (Perry, 2015), the important place occupies dividing the theories that correspond D and E on sub-theories among which, for example, we mark following sets of them: Theories of Behavior and Constraints, Theories of Model Structure, Theories of Interface Usability, Theories of Usefulness, Theories about Evaluating Models and Theories about Evaluating Theories.

Complete Chapter List

Search this Book: