Abstract
This
paper describes the specialized workflows supporting the interactions of
designers with the accessible experience in collaborative designing of the
software intensive system. The inclusion of such workflows in the designing
contributes to the increasing of its successfulness. Workflows are based on
pseudo-code programming of the interactions which are aimed at the designer
activity in the computer medium. Means of pseudo-code programming are developed
as the question-answer processor (oriented to question-answering).
Key words:
AUTOMATED DESIGNING;
EXPERIENCE; INTERACTION; QUESTION-ANSWER PROGRAMMING
1 Introduction
Nowadays the
development of the Software Intensive Systems (SISs) is estimated as the least mastered type
of engineering activities. The degree of the success in this engineering area
is about 35 % and such state of affairs is not being changed practically almost
20 last year [10].
The named state of affairs leads to the annual losses in hundred billion
dollars and these losses demand to analyze the reasons of negatives and to
search for the new means to increase the degree of the success. In a set of
discovered reasons the human factors (misunderstanding, ambiguity of reasoning
and the others) are recognized as the main source of failures.
We are deeply convinced that the essential role of human factors in the
successfulness of designing is being defined by the real time interactions of
designers with the experience used for designing the current state of the
system which should be created. The effectiveness of such interactions
principally depends on means supported the access of the designer to the own experience and collective
experience with their models presented in computer medium (or shortly to
the accessible experience).
The described understanding was used by the author for defining the
question-answer approach (QA-approach) to the conceptual solutions of project
tasks which are being implemented and registered in the form of question-answer
reasoning (QA-reasoning). Such type of solutions is based on the real time
access to the appropriate precedents the models of which:
·
will be found in the accessible experience, adjusted and included to the
current state of the solution;
·
and/or will be built and embedded in the solution and then will be included
to the accessible experience.
The approach has been evolved till the workflows named “Interaction with
Experience”. The workflows provide generating, registering and processing of
QA-reasoning in the instrumental medium named [11] WIQA (Working In Question
and Answers). There are different forms of QA-reasoning supported by WIQA. The
most effective form for conceptual solutions of tasks is pseudo-code program.
2
Interactions with Experience
2.1.
Working
Understanding of the Human Experience
The life of
any person exists and evolves via interactions with naturally artificial world.
The human side of interactions consists of behavioral units the most part of
which are repeatable. Such repeatable units of the human behavior which were
named “precedents”, are the corresponding conditioned reflexes after their
intellectual processing. Below we shall count that a system of precedents
models is a kernel of the human experience. It will play the role of the
working understanding of the human experience in this paper. The chosen
understanding will be coordinated with designing as the form of activity in
which widely use typical design actions (design precedents).
To specify
the used understanding we shall clarify the essence of precedent conceptually
and define its structure and content constructively. Conceptually “precedents are actions or decisions that have already
happened in the past and which can be referred to and justified as an example
that can be followed when the similar situation arises” [8].
As told above, any (project) precedent is being implemented according to
its model created by the human (designer) in the result of intellectual
processing of the definite unit of the behavior (designing activity). It is
possible to consider, that any precedent appears as a result of the
corresponding “experiment” executed by a human or a group of persons. Similar
“experiment” is being planned and being implemented in the definite conditions
for achieving the definite aims of the motivated experimenter(s).
Therefore, in general case the precedent can be presented by the following
logical scheme:
This model
is a human-oriented scheme the human interaction with which is able to activate
the internal logical process on the level of the second signal system in human
brains. So the model opens the possibility of the managed checking the fitness
of the estimated precedent. The model clearly presents the conditions of the
precedent fitness. It also opens the access to “codes” of the corresponding
precedent in the human brain. By the other words, the conditioned part of the
model is a source of questions the answers on which can be used for checking
the fitness of the corresponding precedent. Providing of the access to units of
the human experience is the basic kind of activity of consciousness.
The logical
model is a result of intellectual processing the corresponding behavioral unit
which was built in the result of solving the definite task Z(Pi). It
gives the right to bind with any precedent Pi its life cycle which
begins from the statement of the corresponding task Z(Pi). The
logical model can be interpreted as a formalized statement of this task. To
create this model the human should translate the textual form of statement
(textual model PT of precedent P ) in the logical formula PL.
In the end
of this item we shall note that for any person the mastered precedents exist as
the system of their models one part of which is localized in the human brain.
The other parts are being placed in the different accessible informational
sources. In our opinion the computer medium is the most rational of such
sources in designing of SIS.
2.2.
Interaction with Accessible Experience
The logical model of the precedent prompts a way for the use of the model
for the access to the “code” of the precedent in the human experience (to the
precedent representation in the human brain). This way is similar to the
logical programming of precedent conditions described by formulae of PL-type.
The simplest
version of PL-formula is the AND-OR-combination of M-, C-, U’- and
U’’-components each of which can be expressed by the question about its
meaning. Answering on these questions fills the PL-formula by the
content which allows computing the value of this formula.
Let us suppose that these questions have been extracted from the model and
been prepared for their visualization on the monitor screen. The human can read
the questions from the monitor and
compare “answers” from brain with answers ”written” in the model. In this case
the question-answer sequence and its content visualized on the screen will
manage the search actions of the human.
But in the solving the task Z(Pi) the marked questions were
discovered before PL-formula
will be built. In the suggested means these questions are formulated (in the
natural language) into QA-reasoning aimed at the conceptual solution of any
task of Z(Pi)-type. So the definite QA-reasoning can be interpreted
as the QA-model of the corresponding task Z(Pi) or the state
PQA in the life cycle of the precedent Pi. Interactions
with PQA-model are able to activate the “codes” of the necessary
precedent in the human brain.
Thus QA-reasoning used in the solution of the task can play the role of the
program (QA-program) which will manage the reuse of this solution as the
precedent. Such understanding is put in QA-programs below. QA-programs are
oriented on their execution by the human (in our case by the designer).
The other way of interactions with the human
experience is connected with the algorithmic usage of the natural language when, for example, plans in textual forms manage by
the executions of the reaction parts of precedents. In general case of SIS such
plans include commands any of which should initiate the actions or humans or
computers or instrumental means of the other types. Before executing of any
command it is read, recognized, understood, estimated by the human who should
prepare all what will be necessary for the corresponding acting.
All named preliminary mental actions are aimed
at the use of the human experience. The effectiveness of mental actions depends
on the presentation of commands which should help to the human in such actions
of consciousness. Thus any written command as the definite language sign
includes a question. Presentations of commands should correlate with dialog
processes of consciousness.
As told above the accessible experience
includes a set of models of experience which is presented in the computer
medium. Therefore designers should interact with such models also. In WIQA the
models present the precedents the logical scheme of which is described above.
Models of precedents are combined in the base of precedents (experience base)
the access to which has a question-answer type (will be described below). Thus
question-answer form of human-computer interactions (HCI) is used as for the
access to the human experience so for the access to the models of such
experience.
2.3.
Intellectual
Processor
One type of interactions with accessible experience is bound with the
designer who interacts with own experience. The basic reason of any task of
such interactions is the necessity of the inclusion to the designing the
appropriate precedent. The second type is bound with the search of the
appropriate precedent in the experience base which has been created in the
computer medium.
In WIQA the first type of interactions is being supported by models of
reasoning in the real time or reasoning which has been registered for solved
tasks the solutions of which were qualified as precedents. Moreover, reasoning
should be implemented by designers in the question-answer forms correlated with
the dialog nature of consciousness. Thus WIQA supports HCI provided the access
of the designer to precedent representations in the human experience and the
use of the chosen precedent model for the precedent reusing.
Such type of HCI is better to organize and materialize as means for
managing of the named designer activity. The promising kind of means for the
similar management is programs oriented on their execution by designers (not
computer).
There are two paradigms for programming one of which is declarative
programming and the second is imperative programming. WIQA supports both these
paradigms. The declarative programming is being implemented by the real time
interactions of the designer with QA-reasoning in the form of interactive
objects of the following types: “task”, “question” and “answer”. The basic
destination of such interaction is aimed at finding the answer for the definite
question. Therefore declarative programming will be named below as QA-modeling.
The typical extracted answer is the necessary model of the appropriate
precedent.
The imperative programming is based on the algorithmic usage of the natural
language when, for example, plans (techniques) are described as pseudo-code
programs prepared for their execution by a human.
The instruction for the reset of Outlook Express is an example of such
pseudo-code program:
O1. Quit all programs.
O2. Start On the menu Run, click.
O3. Open In the box regedit, type, and then OK the
click.
O4. Move to and select the following key:
HKEY_CURRENT_USER/Software/Microsoft/Office/9.0/Outlook
O5. In the Name list, FirstRunDialog select.
O6. If you want to enable only the Welcome to Microsoft Outlook
greeting, on the Edit menu Modify, click the type True in the
Value Data box, and then OK the click.
……………………………………………………….
O.10. On the Registry menu,
click Exit.
O11. End.
One can notice that this text indicates the steps of the instruction
(pseudo-code program) which human should execute as a “processor” including to
the “process” the actions with the own experience. Such processor will be named
[12] as an “intellectual processor” (or shortly I-processor) because we
understand the interactions of any human with own experience as a kernel of the
personal intellectual abilities.
The presented example demonstrates that I-processor collaborates with the
computer processor (K-processor) using it as the subordinated computer
assistant. In WIQA the collaboration provides by the question-answer means of
HCI. From this point of view the WIQA is a specialized processor of the
question answer type (QA-processor) supporting interactions between I-processor
and K-processor in collaborative designing of SISs.
Combining of
processors is schematically presented in Fig. 1 which is inherited and adapted
from Figure 1 of the ACM SIGCHI Curriculum for HCI [3].
Figure 1.
Collaboration
of processors
In the
scheme the question is understood by the author as the natural phenomenon which
appears (in human brains) at the definite situation when the human interacts
with the own experience. In this case the “question” is a symbolic (sign) model
of the appropriate question. Used understanding helps to explain the necessity
of fitting the “question” in QA-processes. Implicit questions and answers exist
in the reality while “questions” and “answers” present them as sign models. Let
us note the task is a type of questions.
3
Realated Works
The idea of the designer model as I-processor is inherited by the author
from publications [2] and [6] where described the
model human processor (MH-processor) as an engineering model of the human
performance in solving the different tasks in the real time. The especially
known application of the MH-processor is Executive Process-Interactive Control (EPIC) described
in detail in [6]. Means of EPIC support the programming of the human
interaction with the computerized system in the specialized command language
named Keystrok Level Model (KLM). A set of basic KLM actions includes the
following operators: K ‒ key press and release (keyboard), P ‒
point the mouse to an object on screen, B ‒ button press or release
(mouse), H ‒ hand from keyboard to mouse or vice versa and others
commands. MH-processor is defined [6] as a system of specialized
processors which solve the common task collaboratively. One of these processors
is a cognitive processor providing mental reasoning the type and content of
which are not specified.
It is necessary to underline that I-processor is similar to MH-processor
and includes the cognitive processor also. But the existence and work of this
component of I-processor are revealed through reasoning of the QA- type. This
feature is one of the main differences between MH-processor and I-processor.
Another important difference is the forms of programming (declarative and
imperative) on the base of QA-reasoning. Moreover, a set of basic commands of
the imperative programming includes typical commands of the typical pseudo-code
algorithmic language [13]. The other group of
works related to the suggested QA-approach
is connected with Question-Answering as a type of “an information retrieval in which a direct answer is
expected in response to a submitted query, rather than a set of references that
may contain the answers” [9].
There were
many different QA-methods and QA-systems which have been suggested,
investigated and developed in practice of the informational retrieval and
extraction [4]. Possible ways in the evolution of this subject area were marked
in the Roadmap Research [1] which is actual in
nowadays. This research has defined the system of concepts, classifications and
basic tasks of this subject area.
Applying concepts of the Roadmap Research we can assert that QA-means which
are necessary for working with precedents samples should provide the use of
“interactive QA” and “advanced reasoning for QA” [4]. In interactive QA “the questioner might want not only to reformulate the
question, but (s)he might want to have a dialogue with the system”. The advanced
reasoning is used by the questioner
who „expects answers which are outside the scope of written texts or structured
databases“[4]. From this point of view the useful informational sources for the
creation of precedents samples is mental reasoning in dialog forms.
4
Question Answer Medium
4.1.
Toolkit WIQA
The system WIQA has been developed as the QA-processor for the conceptual
designing of the SIS by the method of conceptual solving the project tasks
[11]. This method is based on the stepwise refining and QA-reasoning which are
being evolved in the frame of incremental designing.
Step by step this system was evolved as the
toolkit oriented on modeling of typical project tasks. The role of the basic
source of typical tasks fulfilled the Rational Unified Process (RUP) created by
corporation IBM [7]. The last version named WIQA.Net has been programmed on C#
at the platform of Microsoft.Net 3.5. The structure of WIQA, its functional possibilities and positive
effects are described in the publication [11]. The features of WIQA.Net (or shortly WIQA) are
reflected by its general components structure presented in Fig. 2.
Figure 2. Component structure
of WIQA
The toolkit is oriented on the collective designing of SISs when tasks are
appointed to members of the designer group. Appointments are supported by the
special component named “Orgstructure” (Organizational structure of the team).
The basic
component of WIQA is the QA-database which supports the real time working of
designers with tasks of designing for the current project. All tasks are
combined in the tasks tree supported the visual access of designers to its
units each of which is interpreted as the definite precedent used in designing
or will be executed by the user of the SIS.
The conceptual solution of any task Zi is being built with
the help of QA-reasoning which are being registered in the QA-protocol
fulfilled the role of the QA-model of the corresponding task. Units of the
QA-protocol which are accessible for designers on the monitor screen are
presented in Fig. 3.
Figure 3. QA-model of Task
In more details
any unit of the Z-, Q- or A-type is an interactive object the properties of
which are being opened when any special plug-ins are used. Thus interactive
tasks tree and a set of corresponding interactive QA-models of tasks present
the “intermediate” between developers and the current state of the designed SIS
existed in the computer environment.
This intermediate link opens opportunities for
the realization of new forms HCI which are additional for forms of HCI put into
the practice now. New forms are oriented to precedents and have the
question-answer type. One of the new forms of HCI is being realized as
pseudo-code programs which can be executed by I-processor so by K-processor
separately or collaboratively.
4.2.
Quiestion-Answer
Data
The definite set of Z-,
Q- or A-objects are available (to designers) via their visual “side” the structure of
which is presented in Fig. 4. On this side any
object is presented by its statement and index label which has unique code in
the QA-database and therefore it can be interpreted as an address of this
object (QA-object) in the QA-memory (QA-database). The content of such interactive objects are not limited only
their textual and graphical expressions which are accessible to the designer
via the main interface form. Other “sides” of any QA-object are accessible via
plug-ins of WIQA. Thus any QA-object has a set of features defined by
corresponding attributes and corresponding commands. The set of attributes
includes, for example, the statement, index label, type, name of responsible
person, time of last modifying. Below attributes of this set will be named as
“basic attributes”.
Nothing prevents to abstract from the sense appointed originally on
QA-objects and their combinations. On this base we define a type of data named
“QA-data” for definite abstraction of QA-objects and their combination if it
uses their subset of attributes and hierarchical structures for the combined
QA-objects. QA-data has been
used in WIQA and its application for presentations of organizational structures,
catalogs of libraries, systems of characteristics and the others of
descriptions for the structured constructs. Let us notice that the name of data
and its meaning can be presented rationally by Q-object and A-object
correspondingly. Any name includes the question about its meaning. Similar way
can be and will be used for the source code of the operator and the result of
its execution.
4.3.
Additional
Attributes
On one of
the previous steps of evolving the system of WIQA the plug-ins named
“Additional attributes” has been developed. This plug-ins support the
object-relational mapping which opens the possibility to create the program
object (C# class) for any chosen QA-object embedded to the QA-database.
Moreover, the designer can add the necessary additional attributes and
“commands” to the basic attributes and corresponding commands. The general
scheme of the object-relational mapping is presented in Fig. 4.
Figure 4. Generation of
additional attributes
After mapping any “line” of declaration of QA-data is existed as an object
(class) formed at C#. Such materialization of the “line” inherits all
attributes of the appropriate unit (“task” Z, “question” Q, “answer” A or the
unit of the others subtypes) in the QA-database. Moreover, this set of
attributes can be expanded by additional attributes {AAi} which can
be appointed to the “line” with the help plug-ins “Additional Attributes”.
So except the field “description” for writing the “line” of the source code
this “line” has a number of useful normative attributes (as told above type of
line “N”, unique index name “NJ”, owner of unit, time of last changing and the
others) and additional attributes (for example, for the data unit its type and
other corresponding characteristics). Models of Precedents
5 Question-Answer
Programming
5.1.
Declarative
QA-programming
Question-answer models, as well as any other models, are created “for
extraction of answers to the questions enclosed in the model”. Moreover, the
model is a very important form of the representation of questions, answers on
which are generated during interaction with the model. The essence of
QA-modeling is interactions of designers with artifacts included to the
QA-model of the chosen task in current states of artifacts. For such
interaction the designer can use the special set of QA-commands, their
sequences and a set of WIQA plug-ins.
As a whole the QA-model can be understood as a specialized SIS the
architectural structure of which is presented in Fig. 5.
Figure 5. Architectural views
of QA-model of task
Architecture is presented no more than in demonstration aims to show the
rich informational potential of the QA-model. The main source of the chosen
views was the set of typical tasks in the RUP-technology.
So any developer can get any programmed positive effect with the help of
QA-modeling as “answer” on question actually or potentially included in the
QA-model (Fig. 6).
Figure 6. QA-model as a
source of answers.
As it is
shown in this scheme any component of the QA-model is the source of answers
accessible for the developer as results of interactions with THE QA-model. At the same time the potential of the QA-model is not limited by the
questions planned at defining and creating the QA-model. Another source of
useful effects of QA-modeling is an additional combinatorial “visual pressure” of questions and answers
which is caused by influence on brain processes in their contacts with
components of the
QA-model.
5.2.
Emulation of
Typical Data and Operators
Broadening
of the abstract type of QA-data by means of additional attributes helps to
emulate any traditional data types such as scalars, arrays, records, lists,
stack, queue and the others. An example of keeping the array with elements of
integer type is presented in Fig. 7 where a set of additional attributes are
used for translating the array declaration to computer codes.
Figure 7. Emulation of array
Attributes
which are assigned for the array are visually accessible for the designer at
any time and can be used not only for translating. The designer can add useful
attributes to the set of array attributes for example for describing its
semantic features which will be checked in creating and executing the
QA-program. Any designer can create any necessary type of data as for
C#-programming so for pseudo-code programming.
The second type of pseudo-code
lines strings is intended for writing the operators. In other words, the symbol string of the “question”
can be used for writing (in this place) the operator in the pseudo-code
form. The fact or the result of the
operator execution will be marked or registered in the symbol string of the
corresponding “answer”.
The next step in the emulation of operators
is connected with taking into account types of operators. For simulating the
basic pseudo-code operators the next constructions were chosen the following of
them: Appoint, Goto, If-Then-Else, For, While-Do, Do-Until,
Command, Function and Procedure. Emulations
of QA-data and QA-operators are implemented in WIQA and provide the creation of
pseudo-code programs for different tasks.
5.3.
Specimens of QA-programs
As told
above QA-programs are oriented to the creation and use of precedents models.
Such orientation suggests the programming of the condition part and reaction
part of any precedent separately. The condition part should help to solve the
task of the precedent choice from the base of precedents. Such work has a
service type and it depends on the state of the base which changes during the
development of the SIS. Therefore the program of any precedent choice should be
easily changeable by the designer who is not the professional programmer
usually. QA-programming helps to solve this problem.
The typical
scheme of QA-programs for the conditioned parts has the following view:
QA-PROGRAM_1 (condition for the access to the precedent):
N1. Variable
V_1 / Comment_1?
V1.Value of
V_1.
N2. Variable
V_2 / Comment_2?
V2. Value of
V_2.
……………………………………………
NM. Variable
V_M / Comment_M?
VM. Value of
V_M.
N0. F =
Logical expression (V_1, V_2, …, V_M)?
V0. Value of
Expression.
End.
It is
necessary to notice that the designer can build or to modify or to fulfill
(step by step) the definite example of this program in the real time work with
the corresponding precedent which, it may be, designer creates. In the
presented typical scheme the logical expression of the choice is programmed as
the program function (QA-function).
In this example the strings of the Q-type are
marked by the label “N” (Name, Name of Variable) and string of the A-type are
marked by the label “V” (Value of Name). Marked index labels are defined as
subtypes for Q- and A-types. Additionally subtypes “O” (operator) and “E”
(executed) were appointed for marking the Q-lines and A-lines in descriptions
of operators. The subtype “O” was used in the pseudo-code program “Reset
Outlook” which can be executed by I-processor in the WIQA medium.
The reaction
part of the precedent has very often the technique type the possibility of
QA-programming of which was described above. If it is not so the designer can
create the reaction part in the prototype form as the QA-program. The next
typical scheme reflects the work with techniques programmed as QA-procedures:
QA-PROGRAM_2
(technique for the typical task):
O1.K_i, K_j,
…, PL_k ?
E1. *
O2. K_m, QA-P_n, …, K_q?
E2.*
………………………………
ON. K_s,
Pl_t, …, QA-P_v?
EN. #
End.
The program text includes the symbolic names K_x and
Pl-y for the Command and Plug-ins of WIQA and QA-P_z for the QA-program written
by means of WIQA. It is necessary to notice that all names of the types K_x,
Pl-y and QA-P_z are indicated positions on the monitor screen for initiating
the actions by touch of the designer. In such “points” of human-computer
interactions the suggested means of HCI are being combined with traditional
means of HCI. In the second typical scheme the symbols “*” and “#” (as “yes”
and “no”) indicate the facts of the execution for operators. Let us note that
in the typical case any string includes only one operator.
To demonstrate some language details in pseudo-code programming we shall
present a fragment of one more QA-program:
O 1.11 Procedure &DiscardPriority&
O 1.11.1 &P& := &Pmax&
O 1.11.2 Label &DP1&
O 1.11.3
&Priority& := &P&
O 1.11.4 CALL &GetTaskByPr&
O 1.11.5 &base& ->
&TaskPriority& := &base& -> &TaskPriority& + 1
O 1.11.6 CALL &ChangeTask&
O 1.11.7 &P& := &P& - 1
O 1.11.8 IF &P& < &base&
-> &Pmin& THEN &base& -> &NewPriority& :=
&Pmin& ELSE GOTO &DP1&
O 1.11.9 ENDPROC &DiscardPriority&
This procedure is used in plug-ins of WIQA named "System of
Interruptions" for the calculation of a priority of the interrupted
QA-program. The system of interruptions is created by means of pseudo-code
programming. The purpose was to estimate the potential of the created means of
pseudo-code programming. In this plug-ins the QA-programs have been translated
by the compiler (not by the interpreter) because they are processed by
K-processor. Therefore, A-lines of operators are excluded in the source code.
6 Means of
Interactions with Experience
6.1.
Precedent
Framework
There are
three ways for the appearance of the precedent and its model providing the
reuse. The first way is connected with the intellectual processing of the
definite behavior which was happened in the past but was estimated by the human
as a potential precedent for its reuse in the future. The second way is the
creation of the precedent in parallel with its first performance and the third
way is an extraction of the precedent model from another’s experience and its
models. In any of these cases if the precedent sample is being created as
fitting the logical framework and filling it by the appropriate content then
the human should solve the retrieval and extraction tasks of the necessary
information from useful sources.
WIQA
supports all of these ways any task of which designers solve with using the
uniform data (presented in Fig. 3) and actions. As a result any task (and the
task of precedent creation) can be presented by a set of its state in its life
cycle [14]. Any useful state is rationally formed as the specialized precedent
model helped in its reuse. Models PT, PQA and PL are
examples of such states.
Moreover,
with any useful state of the task solution the designer can bind the
subordinated task. This approach has
helped to define the precedent framework which integrates a system of its
models presented in Fig. 8.
Figure 8.
Life cycle of
integrated model of precedent
This system includes the following useful precedent models: PT ‒
textual precedent description, PL ‒ logical (predicate) model,
PG ‒ graphical (diagrammatic) model, PQA ‒
question-answer model, PI ‒ source program code and PE
‒ executed code. All of these models are included to the typical
materialization of the precedent in the precedents base.
The chosen specialized models of precedent correlate with the real time
practice of designing the SIS which is more fully reflected in RUP. Additionally
the composite structure of the precedent presentation and the specificity of
its production units were chosen for their usage by I-processor firstly and for
the usage by K-processor secondly.
6.2.
Experience
Base
In WIQA the
described models of precedents are combined in the experience base which has
two parts. The first part includes models for an invariant set of precedents
each of which supports the execution by the designer the definite technology
action or the typical designing technique. Such models are kept in the
specialized library of the pseudo-code programs the access to which provides by
the visualized catalog. The informational structure of the catalog is
implemented similarly the tasks tree with corresponding QA-protocols. It has
sections and subsections (analogical to tasks and subtasks) and models of
precedents (in forms of definite tasks with corresponding pseudo-code
programs).
The second
part named “Base of Precedents” is organized similarly the knowledge base of expert
systems [15]. Means of this base support the rough and strict access to the
necessary model. The rough access provides the search via the list of keywords
formed by the designer. The strict access is being implemented by the computing
of the access functions embedded to the model in the form of pseudo-code
functions.
6.3.
Means of
QA-programming
Means for
QA-programming have been developed and embedded to WIQA as its evolution. The
creation and use of QA-programs are being fulfilled in the operational medium
which additionally includes the following components:
·
editor of
QA-reasoning (QA-programs) supporting the back object-relational mapping (with
saving the appointed additional attributes);
·
interpreter
of QA-programs managing the step by step executing of the program operators by
I-processor (by the designer) who has an opportunity to activate the automatic
execution for the group of marked
operators;
·
system of
interruption providing the parallel execution of a number of QA-programs by
I-processor.
·
generator of
pseudo-code prototypes with the interface linkage;
·
compiler of the
QA-program transforming the source pseudo-code to the code which will be
executed by K-processor.
Creating of
the definite QA-program is beginning from the choice of the point in the tasks
tree and the declaration of the new task for this program. The index name of
this task will be used as the initial address for computing the index names for
any line of the source code of the QA-program which is written in the working
area of the text editor. The indexed copy of the source code is registered in
the editor memory and is visualized in the form of the QA-protocol. After
saving the current state of the source code its indexed copy transfers to the
QA-database. In any time any QA-program
from the database can be loaded to the editor.
Any
QA-program in any its state can be load to the interpreter for the execution.
Any executed operator of the QA-program is visualized in the special area of
the interpreter and in any time the designer can declare the new synonym for
the chosen keyword. There are other useful possibilities accessible for the
designer in the main interface forms presented tasks tree and QA-models of
tasks.
The reality
of the designer activity is a parallel work with many tasks at the same time.
Therefore, the special system of interruptions is included into WIQA. It gives
the possibility to interrupt any executed task or QA-program (if it is
necessary) for working with other tasks or QA-programs. The interruption system
supports the return to any interrupted task or QA-program to its point of the
interruption.
The
presented means of HCI open the effective possibilities for aspect-oriented
designing the traditional versions of HCI. For all usability metrics, which are
defined in the standard ISO/ MEK–9126, corresponding precedents were created.
All of them are united in the library of the typical tasks. Any task of this
library is programmed with the usage of QA-means so that the corresponding
usability metrics is accessible to designers as the definite interface
precedent. The created library consists of 73 typical tasks any of which can be
used for generating the necessary quantity of copies adjusted to the places of
their materializations in the implemented system.
When in current
solving of the project task the designer discovers the next “point of
human-computer interaction” then the appropriate metrics task is being included
to the tasks tree of the designed SIS. Such task has two subtasks one of which
is a pseudo-code program of the precedent condition. The second subtask is a
pseudo-code technique providing the inclusion of the chosen metrics into the
solution of the project task. In order
to simplify the use of the aspect-oriented technique the special plug-ins for
the interface prototyping has been developed and included to WIQA.
7
Conclusion
This paper represents new means of modeling and programming which are aimed
at increasing the effectiveness of the designer activity. Such means based on
QA-reasoning widely used in conceptual solutions of project tasks. Programming
of the conceptual activity helps to increase the level of its automation and by
that to reduce quantity of semantic faults and defects in designer solutions.
The suggested means manage the designer who should fulfill the role of
I-processor working under control of QA-programs in decisions of typical
project tasks.
The offered means are adapted at understanding of the designer activity as
the work based on precedents. Therefore pseudo-code language is defined and
built as the object-oriented language the potential of which is sufficient for
the expression of the necessary semantics.
QA-programming is being applied as to the precedents already mastered by
designer and for the precedents being created during designing.
Possibilities of QA-programming are implemented in the instrumental system
WIQA supported the work of designers with the precedent base in the corporate
network. Means of QA-programming include the interpreter of QA-programs for
their execution by designers and the compiler of QA-programs for the computer
execution. The use of QA-programming and the base of precedents are embedded to
conceptual designing supported by all means of WIQA.
The offered means have confirmed the practical usefulness in the
development of a number of SIS, including “Multi-agent system for simulation of surrounding the
sea vessel” and “Question-answer
expert system for ship collision avoidance”. Means of QA-programming was
used for developments plug-ins “System of human-computer interruptions” and
about 400 guides embedded to WIQA and also for the creation a set of
QA-programs for a number of specialized systems.
References
[1]
J. Burger, et al.
Issues, Tasks and Program Structures to Roadmap Research in Question &
Answering (Q&A), Tech. Rep. NIST, 2001.
[2]
S.K. Card, T.P.
Thomas, and A. Newell, The Psychology of Human-Computer Interaction. London:
Lawrence Erbaum Associates, 1983.
[3]
T. Hewett, et
al., ACM SIGCHI Curricula for
Human-Computer Interaction.ACM Technical Report. p. 162. 2002.
[4]
L.
Hirschman and R. Gaizauskas, Natural Language Question Answering: The View from Here. Natural
Language Engineering, 7 (Jul.2001), pp. 67-87. 2001.
[5]
F. Karray, M.
Alemzadeh, J. A. Saleh, and M. N. Arab, Human-Computer Interaction: Overview on
State of the Art Smart sensing and intelligent systems, 1, 1 (Jun.2008), pp.
138--159. 2008.
[6]
D. Kieras and
D.E. Meyer, An overview of the EPIC architecture for cognition and performance
with application to human-computer interaction. Human-Computer Interaction, 12 (Dec.1997), pp. 391--438, 1997.
[7]
P. Kroll, and
Ph. Kruchten, The Rational Unified Process Made Easy: A Practitioners Guide to
the RUP. Addison-Wesley. 2003.
[8]
Precedent. DOI= http://dictionary.reference.com/browse/precedent,
2011.
[9]
Question-Answering.
DOI= http://www.wordiq.com/definition/ Question_
answering, 2011.
[10]
Reports of
the Standish Group. DOI= http:// www.standishgroup.
com.
2011.
[11]
P. Sosnin, Means of question-answer interaction for
collaborative development activity. Advance in Human-Computer Interaction
Volume 2009, Hindawi Publishing Corporation, USA, p. 18. 2009.
[12]
P. Sosnin,
Question-Answer Approach To Human-Computer Interaction In Collaborative
Designing. // In proc. IASDIS: Human Computer Interactions, Freiburg, Germany,
2010, pp. 219-226.
[13]
P. Sosnin,
"Programming of Human-Computer Interactions in Development of Software
Intensive Systems ", International Journal of Computer Information Systems
and Industrial Management Applications ISSN 2150-7988 Volume 3 (2011), pp.
444-452.
[14]
P. Sosnin, V.
Maklaev Pseudocode Programming of Precedents in Conceptual Designing of
Automated Systems. In Proc. 5th International conf. Application of
Information and Communication Technologies (AICT’11), 2011, Baku, Azerbaijan,
766-770.
[15]
P. Sosnin, “Question-Answer Shell for Personal
Expert System”. Chapter in the book “Expert Systems for Human, Materials and
Automation.” Published by Intech, 2011,
pp. 51-74.