Download Using knowledge in model-based software development

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Name mangling wikipedia , lookup

Java (programming language) wikipedia , lookup

Abstraction (computer science) wikipedia , lookup

Object-oriented programming wikipedia , lookup

Java performance wikipedia , lookup

Software quality wikipedia , lookup

Knowledge representation and reasoning wikipedia , lookup

Application Interface Specification wikipedia , lookup

C Sharp (programming language) wikipedia , lookup

Transcript
Using knowledge in modelbased software development
Enn Tyugu
Institute of Cybernetics of Tallinn University of
Technology
Why another SW technology?
• Software engineering (SE), being often a part of
the development of high-tech products, still lacks
high-tech tools for its own usage. Much manual
and routine work has to be performed in order to
get a software product.
• Software development is a knowledge-intensive
process, but knowledge usage is little supported
by the technology.
SW technologies
Spiral:
Waterfall:
Req. spec.
Reqirements spec.
Design
Testing
Design
Implementation
Implementaion
Testing
Agile (XP):
Req. & architecture
Impl. Impl. Impl. Impl.
Testing
Model-Based:
Domain engineering
Application engineering
Model-Based SW Technology
Domain engineering
Software assets
(Domain knowledge acquisition)
Application engineering
(Domain knowledge application)
Application
Software assets
Software assets are the reusable resources
used in application engineering:
• Domain specific language (textual and visual)
• Domain specific SW components
• Domain specific models
History
•
•
•
•
Simula
FGCS and Prolog
Knowledge-based system projects
Using metamodels
Best of existing MBSE
•
•
•
•
Simulation tools: Simulink, ...
NASA ISS SW technology
Visual modeling tools: EMF, MetaEdit, ...
UML-based methods
Using metamodels
This approach includes the usage of UML-based
models and metamodels. It concentrates either
on
• research of transformation rules for transforming
an initial specification (a model) into another
model or an executable code
• or development of rules that represent the
operational semantics that enables one
immediately to perform the required
computations.
Dynamic metamodeling example
Semantics Definition
Syntax
Definition
Metamodel
semantic
mapping
Semantic
metamodeling
Runtime metamodel
Operational rules
Graph
transformation
typed
rules
over
conforms to
Expression
conforms to
conforms to
conforms to
Transition System
Model
States
Gregor Engels
What is needed?
• Knowledge representation and handling methods
• Easy access to conventional programming tools -a general purpose programming environment
• DSL implementation tools
• DSL application environment
What is critical?
• Using knowledge for getting automatically a program (or
computations) out of available material (from the assets)
that are specs, components, models, ... .
• If this is achieved, then
– the program will be bug-free with respect to its
specification (model and goal)
– considerable amount of routine work (coding) will be
avoided
– maintenance and amendment of programs will be
easy.
Cooke, D. E., Barry, M., Lowry, M., Green, C. NASA’s Exploration
Agenda and Capability Engineering. IEEE Computer, vol 39, no. 1, 2006.
Requirements for development
• A crucial part of the model-based software development is
automation of the usage of software assets in the application
engineering phase. If we consider the result of the application
engineering just as a program, then we can say that an efficient
program synthesis method that uses the knowledge must be
available.
• A tool developed in this way should be supported by a software
technology that must have sufficient advantages compared to the
existing and widely used ones. (Consider all efforts already invested
in the development of various software technologies, e.g. the UMLbased ones.)
• To become a generally applicable technology, model-based software
development must provide at least the same programming support
as the existing general purpose frameworks (Java, .NET etc.) give
us.
Ideas for development 1
• A way to achieve this is to develop a framework that
merges knowledge-based technique with general
purpose programming.
• One can imagine building a knowledge-based tool on top
of Java by extending the Java language, for example,
just with comments that include the knowledge usable by
the tool. Doing this, one should carefully preserve all
Java possibilities for program development.
Ideas for development 2
• A tool can be useful only if it adds essential features to the existing
platform. These features could be: visual development of models
(specifications), user friendly knowledge representation means, easy
debugging of large knowledge-based software components,
automatic composition of large programs from specifications
(models).
• Knowledge-based part and procedural part of the system may have
separate name spaces. Only method names of classes should be
used in the KB part of a class.
• All Java types (including reference types) should be available in the
KB part.
Example domain
Let us take an electrical engineering domain – alternating current
cicuits as an example. Domain analysis gives us the following
required concepts:
– Complex numbers
im
mod
mod 2 = re 2 + im 2
arg
re
mod * sin(arg) = im
– Complex values of current i, voltage u, impedance z and conductivity g
that will depend on frequency f or cicular velocity ω, where ω = 2 π f.
– Elements of circuits: branch, resistor, capacitor, inductivity
– Fragments of circuits: series and parallel connection of subcircuits
(branches)
– Some instrumetation components: frequency characteristics,...
The first concept description
We need a knowledge representation language convenient for
engineers, i.e a language that that includes equations.
Here is an example of this language.
import java.util.*;
class Complex {/*@
specification Complex {
double re, im, arg, mod;
mod^2 = re^2 + im^2;
mod * sin(arg) = im;}
@*/
}
More concepts
class Branch {
/*@ specification Branch {
Complex z, i, u, g;
double f;
u.mod = i.mod * z.mod;
u.arg = i.arg + z.arg;
g.mod * z.mod = 1;
g.arg + z.arg = 0;
const double PI = Math.PI;
}@*/
}
class Resistor extends Branch {
/*@ specification Resistor super Branch
double r;
z.re = r;
z.im = 0;
}@*/
}
class Capacitor extends Branch {
/*@ specification Capacitor super Branch {
double omega, C;
g.re = 0;
g.im = omega * C;
omega = 2 * PI * f;
}@*/
}
class Inductor extends Branch {
/*@ specification Inductor super Branch
double omega, L;
z.re = 0;
z.im = omega * L;
omega = 2 * PI * f;
}@*/
}
Fragments of circuits
class Par extends Branch {
/*@ specification Par super Branch {
Branch x1, x2;
class Ser extends Branch {
/*@ specification Ser super Branch {
Branch x1, x2;
g.re = x1.g.re + x2.g.re;
g.im = x1.g.im + x2.g.im;
z.re = x1.z.re + x2.z.re;
z.im = x1.z.im + x2.z.im;
u = x1.u;
u = x2.u;
i = x1.i;
i = x2.i;
f = x1.f;
f = x2.f;
f = x1.f;
f = x2.f;
}@*/
}
}@*/
}
A real program component
public class Process {
/*@ specification Process {
double inp, out;
void res;
double min, step, max;
Port port;
alias draw = (*.drawing_ready);
[ inp -> out, draw ], min, step, max -> res {proc_run};
}@*/
public void proc_run(Subtask st, double start, double step, double finish) {
try {
for (double i = start; i <= finish; i+=step ) {
Object[] out = st.run( new Object[]{i});
}
}
catch (Exception e) {
e.printStackTrace();
}
}
}
The circuits DSL
res
resistance r
capacitor
capacity C
inductor
inductivity L
ser
Branches x1, x2
par
Branches x1, x2
process
port
in
out
a loop for out from
min to max with
increment step
A model
Solving a problem
Automatic program construction
Structural synthesis of programs (SSP) is a way to get programs
completely automatically from equations and Java methods. It uses
reasonably simple model specifications, where component specifications

1≤i≤m
(si,1si,2…si,ki(Ui,1(si,1)Ui,2(si,2) …Ui,ki(si,ki)  Vi(i(si,1,si,2,…si,ki))) )
 u1u2…uk(X1(u1)X2(u2) …Xk(uk)  Y(F(u1,u2,…uk, 1, 2,… m)))
are represented in a simpler (propositional) form
 (U  V { })  (X  Y{F})
1≤i≤m
i
i
i
or quite often even
X  Y{F}
See: P. Grigorenko, E. Tyugu. Higher-Order Attribute Semantics of Flat Declarative
Languages. Computing and Informatics. v.28, No. 2, 2010;
E. Tyugu. Grigori Mints and Computer Science. In: S. Feferman, W. Sieg, V. Kreinovich, V.
Lipschitz, Ruy de Queiroz (Eds.) Proofs, Categories and Computations: Essays in honor of
Grigori Mints. Dov Gabbay’s College Publications, 2010.
Benchmarking of the synthesizer
(Y1&G1  A1)  B1,
(A1  (B1&G1&Z1))  X1,
Y1&X1&U1  A,
Z1 ↔ B2,
Y1 ↔ U2,
...
(Yn&Gn  An)  Bn,
(An  (Bn&Gn&Zn))  Xn,
Yn&Xn&Un  An,
Zn-1 ↔ Bn,
Yn-1 ↔ Un,
U1&Zn ├ B1;
where n > 1
n=2
n=4
n=6
n=10
SSP Prover <0.01 0.05
36.24
--
STRIP(check) <0.01 0.34
3781
--
STRIP(prove)
<0.01
--
--
--
iLeanCoP
0.01
--
--
--
iLeanSeP
0.02
--
--
--
PITP
<0.01
0.05
15.73
--
LJT
<0.01
0.05
35.15
--
Gandalf
0.01
0.19
0.53
7.55
P. Grigorenko. Higher-order attribute semantics of
flat languages. Ph. D. TUT, 2010.
The technology
Project
ontology (1)
Domain engineering
Code components
(classes) (2)
Application
engineering
Automatic
steps
Components (4)
Specification
(scheme or text) (6)
Logical
formulae (7)
Algorithm (8)
Visual
rerpesentation (3)
Requirements (5)
Executable
code (9)
The domain engineering
technology
• Problem(s) analysis, use cases
• Domain analysis:
– Domain concepts
– Domain ontology, incl. inheritance and part-of
relations between the concepts
– Problems-related concepts
– List of components
– Computational content of components.
The tool: CoCoViLa
CoCoViLa is a software tool for model-based
software development with a visual language
support that performs automatic synthesis of
programs from logical specifications. It is tightly
integrated with Java: it is written in Java, uses
advanced features of Java, and it supports
programming of new software components in
Java almost without restrictions.
http://www.cs.ioc.ee/cocovila
Support of domain and application
engineering
CoCoViLa consists of two runnables: Class Editor
and Scheme Editor.
• The Class Editor is a tool for domain engineering, it
is used for implementing visual languages for
different problem domains.
• The Scheme Editor is a tool for application
engineering -- drawing schemes, compiling and
running programs defined by scheme and a goal.
Rich components
A component “Boiler”:
Boiler.gif
B
... .xml
Boiler.java
BoilerDaemon.java
Rich component
(metaclass, visual class)
Rich component is a description of a domainspecific concept used for describing models. It is
a class, extended with information needed for
automatic usage of the class, and also for visual
handling of instances of the class. It is therefore
also called visual class. A rich component may
have four parts:
• visual part – its image, pop-up window etc.
• specification (a logical part)
• program component
• daemon (a permanently running thread).
Package
Package is a collection of rich components
and schemes related to an application
domain, collected in a package folder and
supplied with a package description file in
xml format.
A package supported by the Scheme
Editor is an implementation of a domainspecific language.
Specification language
1) Declaration of variables
type id, id, ...;
The type is a primitive type, a class, or a metaclass.
Examples:
int i,step;
Boiler b;
2) Binding
a = b;
Binding is an equality, where a, b are variables.
3) Equation
Example:
x = 2* y*sin(alpha);
Specification language continued
3) Axiom
precondition -> variable{name-of-method}
Example:
x,y -> z{P}
This axiom specifies that a method P can be used for calculating z
int P(int a, int b) {…}
4) Alias
alias name = (list of names);
Examples:
alias state = (*.state);
alias in = (x1, x2);
A real application: security exprt
system
J. Kivimaa, A. Ojamaa, E. Tyugu. Managing Evolving Security Situations. MILCOM 2009:
Unclassified Proceedings, October 18-21, 2009, Boston, MA. Piscataway, NJ: IEEE, 2009, 1 - 7.
Appliaction: simulation in mechatronics
Grosschmidt, G.; Harf, M. (2009). COCO-SIM - Object-oriented Multi-pole Modelling and Simulation
Environment for Fluid Power Systems. Part 1: Fundamentals. International Journal of Fluid Power,
Vol. 10, No. 2, 2009, pp. 91 - 100. Part 2: Modelling and simulation of hydraulic-mechanical loadsensing system. International Journal of Fluid Power, Vol. 10, No. 3, 2009, pp. 71 - 85
Application: composition of services
R. Maigre, P. Küngas, M. Matskin, E. Tyugu. Handling Large Web Services Models in a Federated
Governmental Information System. Proc. 3-rd International Conference on Internet and Web Applications
and Services. IEEE Computer Society & CPS, 2008, p. 626 – 631