We're very, very happy to have Dr. Consel with us
today. Um, he comes from the university and
also works at a research government research lab called Inria
in France. Uh, he has served on the
faculty at Yale at OGI. And at the University
of Rennes in France. Uh, he is a
dear colleague. I've known him for about 20 years
and working in programming languages and domain specific languages.
And today he's going to give us to talk about
some of his newer work in software design that uses
some ideas for programming languages. So [inaudible]
Thank you very much. Thank you so much.
This is, uh this is really great for
me. Uh, it's been 2 days here,
uh, spending, uh, 2 days talking to,
uh to people here. Great discussions. Uh,
and thank you for enlightening me. Thank you so
much. Um, so I'm going to try to
deliver a talk that's going to be at least try
as good as the quality of the discussions I've had
with people here. Uh, So what I'm going
to talk about is, um, Atlanta Research that
we've been working on for the past five years with
quite a few PhD students working on that, and
uh, post docs and researchers. Um,
our goal in this project was to leverage principles and
techniques from programming languages. Um, and especially domain
specific languages, too, uh, to to really
propose, uh, a new software development approach.
Uh, that would, uh, be driven by
uh, design description of the program essentially trying
to design a program rather before programming it for real
Um, for the purpose of this talk,
I'll be using a an example of what I call
a cooker alert. So, uh, just to
give you a little idea of what this, uh
this working example is going to do, Uh
this is something that that this is an application
that will, um, warn a user when the
cooker stays on for too long than some alert is
going to be sent to the user. Uh,
in order to, uh, make a decision as
to whether to turn off the cooker, or,
um, I'll keep it on. Um, So
this this is kind of a typical the kind of
applications that we will be looking at in this talk
where we have, uh, networked entities that we
want to orchestrate to realize a particular task. Okay
Um, so given what I've done before,
the logical thing to do for, uh, an
area like that would be to, uh, to
address this area by developing a domain specific language.
So the idea of a domain specific language briefly described
is you will provide some, uh, domain specific
concepts notations, semantics, um, in the form
of a language. And you realize the implementation of
that language with an interpreter or compiler and the benefits
of the approaches that you will have in terms of
software development. You hope that you're going to have
some language that's going to be concise, you know
abstract enough because a lot of the knowledge has
been kind of captured within the implementation of the language.
Uh, you'll be able to do some interesting
software verification because if you have some critical properties in
that domain, what you want to do is to
design the language such that it includes it. It
takes into account the properties that you are interested in.
So typically, some properties are not decidable
in general, in general purpose languages. But what
you will do is that you, you know,
carefully craft the design of that language such that some
properties can be can be decidable. So verification
is good using domain specific languages. And, of
course, some software execution properties like performance or robustness
of things. You can get there because you have
some kind of, you know, maybe domain specific
optimizations that you can perform, uh, you know
as you and encapsulate in an interpreter or compiler
to get robustness or performance. So this approach is
domain specific language approach has been, uh, studied
for, uh, you know, years, almost
decades now, um, it's been very successful in
in in a wide range of areas. I mean
uh, lots of researchers and and and and
myself, we've We've worked on on this approach in
very different areas, like operating systems networking, multimedia
telephone, Uh, so this is
this has been very, very interesting, but the
problem is that we we see that there's still a
gap between uh huh, the results that we're getting
in domain specific languages and mainstream programming languages. It's
still a niche to some extent. Okay, It's
still attacking, you know, niche areas, and
, uh, and making contributions. There but the
mainstream programming languages is kind of, uh, you
know, as much impacted as we would wish by
this research. So about five years ago, we
decided to try to combine the two and and and
one of the reasons why is that? You know
, usually when you talk about domain specific languages,
people will say, Well, yes, but there
are some non standard concepts that you're proposing in your
domain specific language. There's some some learning curve,
uh, to to use that language or or the
scope is very narrow. For every, you know
, niche. I need to learn a new language
, and that's kind of a problem. Uh,
the problem is the fact that there are lots of
a p I is out there that you want to
use and and the problem is that those DSL s
those domain specific languages are kind of disconnected from all
those a p I s and and that's a problem
because you're not leveraging, you know, the existing
, uh, the existing libraries you have out there
and another problem is the development environment. I mean
, you know, you have very sophisticated, very
rich programming environments like eclipse, for instance, and
what you'd like to do is to benefit from these
tools and again, domain specific language is not really
connect very well with those things. So the question
is, how can we get the best of the
of both worlds so we can get, you know
, domain specific benefits and general purpose languages. So
our approach there is, too is really to,
uh, combine the two. And and one of
the things that we want to do is that the
first thing is, we want to We don't want
to replace general purpose languages. Okay, because it's
just, you know, it's useless to fight against
that. So So what we want to do is
to compliment general purpose languages by introducing a phase prior
to programming, which is called designing. Okay,
we okay? It's just designing. What it means
is that we want to essentially raise the level of
obstruction. Not not to to be to express the
intent of the programmer directly, using a programming language
, but to express that intent in a decorative way
. Uh, another thing we want to do is
we don't want to have a design, language or
design approach that is general purpose that we know about
a lot of specification languages, for instance, informal
methods that are general general purpose. The problem you
have there is that, um because this general purpose
when you want to somehow target okay, the approach
to a particular area, it takes a lot of
effort. Okay, So we wanted we wanted to
to propose a paradigm that with our design approach,
Okay. And I'll tell you a little bit about
that afterwards. And the reason One of the reasons
why we wanted to do that was, in fact
, to retain the DSL benefits. Okay, that
we enjoyed in our previous work. Okay, um
, we wanted to have an actual language. So
that's the programming language side of things. Uh,
we wanted really to have an actual language. And
we wanted that language that design language, uh,
to be a paradigm specific in terms of syntax and
in terms of semantics. And I'll show you precisely
what I mean by that, um, and of
course, we wanted to go beyond the kind of
a contemplative approach, um, of, uh,
and we wanted to provide a compilation process that would
take a design would compile. Okay. That design
into something concrete for the programmer. And specifically what
we wanted was to generate a customized programming framework,
Um, customize with respect to the design, of
course, we wanted to have a well defined semantics
for our language so that we could do some verification
and essentially leverage the specificities of our paradigm. I
mean, that's again retaining the domain specific language benefits
. We wanted the programming to be driven by the
design. I mean, if you're spending your time
designing something, you want to get something out of
it. So you want to get programming support?
That's one. But you want to also want to
get some program verification. Okay, So, uh
, so, uh, so the programming, uh
, we want to ensure that the programming is gonna
be, uh, conform is gonna be in conformance
with the design, and and for that, we're
gonna we're gonna leverage the, uh, the programming
support that we're generating the programming framework that we're generating
. And the other thing is that we want again
to bridge, uh, domain specific languages and general
purpose languages by generating this programming framework. And what's
interesting here is that we're going to be able by
doing that that we're going to be able to,
uh, to leverage, uh, the the the
all the all the tools and the runtime environment,
you know, and the host support that we can
have given the target the target and general purpose language
that we're going to choose. So let me show
you how Winston she ate that kind of list of
general ideas here. Uh, so the designing we're
going to have a declarative language. Essentially, uh
, that I'll show you in a minute with a
concrete example. Um, by the way, please
, if you have any questions, uh, don't
hesitate to interrupt as far as the paradigm. So
we chose one paradigm that we thought was general enough
to capture a bunch of areas that we're targeting,
and that's a sense compute control paradigm. And I'll
show you concretely what it is. Uh, next
slide. Uh, the language, the design language
that we came up with has a name. It's
called Dia Spec. And again, we're gonna see
, uh, concrete examples of that. The compilation
work. What we do is that we compile our
dia spec language into Java programming frameworks. Okay,
there are customized with respect to a given design.
We do some verification at design time, compile time
and run time. And as far as programming,
what we can do is that we can somehow enforce
the programmer. Uh, we can we can make
sure that the programmer conforms to the design by leveraging
the type system of Java. Okay. And as
far as support since we're going to we were generating
java code. So then we can have our approach
completely integrated into the development environment of Java, like
eclipse. And we can, of course, use
a P i s and other other tools we have
. Okay, so now, uh, let me
show you what this, uh, sense computer control
paradigm. Looks like it's a very general. Um
, it's a very general approach. Uh, that
is being used in a in A in A in
a range of area. The idea is that you
have some external environment here. Okay, that you
want to do measurements on. So to do measurements
on this environment, you're going to have some entities
. Okay, uh, sensors, typically, sensors
can be hardware sensors or, uh, software sensors
. Um, this is the sense part of the
sense computer control paradigm. You collect raw data,
and you, uh, feed them to other kinds
of components. We call them context components. Those
components will be in charge of essentially processing these raw
data, aggregate them, filter them, interpret them
okay to a century, Um, make them amenable
to the application level. Uh, and that's the
compute phase of the sense compute control paradigm. When
some decision needs to be made, some actions need
to be taken. Then the another, uh,
component kind of component comes into the picture. And
those are controller components. They get context data,
okay. And they're supposed to compute some actions that
will later be performed on the environment. So the
computer orders that go into another facet of those entities
, which is called the actions. So this is
essentially the actuator, uh, facet of these entities
, okay. And that's going to have an effect
on the external environment. And that's the control.
A step of the sense computer control paradigm. Okay
, So, in fact, I mean, you
see that as being a physical environment, but it
could be a, uh, digital environment. I
mean, this could be a network, okay?
And this could be sensors, you know, sensing
for instance, uh, the available bandwidth or the
loss of packets and things like that. And you
can take actions by maybe, uh, having an
influence on the the country. The admission control process
, for instance. Okay, so there are many
examples using science complete control paradigm. Like, uh
, you know, robotics is one avionics, uh
, everything that has to do with home automation and
and and some mobile applications. Okay, so let
me then show you a concrete example of an application
. Okay. Being designed and written using our approach
. So, uh, so this is this is
the picture where we have the senses. Here we
have the activities here. We have the context components
here and the controller components here. Okay, we'll
go back to our cooker alert example. Okay.
And we'll look step by step. How we go
about designing this cooker alert example. It's a simplified
version of that cooker alert. There are some evolutions
of that, but I'll show you the simple version
of it. So we start by declaring the sensors
and actuators of our application. So here, for
instance, we have this cooker okay, that has
to two devices attached to it. One that measures
the electric consumption. The other one is a switch
. Essentially. Okay, so here we declare this
device. So here you can see that this is
a very, uh, paradigm specific design language.
We have this keyword device here that declares an electric
meter that extends a class of sensor, which is
the sensor thing here. And all it does is
that it declares a source of information, which is
the current electric consumption as a float. That's all
it does is very high level, kind of interface
, like decoration. As you can see here,
it doesn't say whether we're pulling information from the electric
meter or whether the electric meter is gonna push information
into, uh, its clients. Okay. And
you'll see how we go about expressing that information later
on. Right now, it's just a source of
information. That's all it is. All right,
We have the switch here, which is another device
, which is, uh, it extends the actuator
class, and it has two actions. The on
action and the action. Okay. The actions can
be understood as interfaces interfaces. Okay. All right
. So, of course, there are many other
many other devices here. Um, let me.
Then go a little bit into the details of that
application. You can see you have two devices here
. You have a clock. Okay. That will
periodically, uh, essentially invoke that component here.
Okay, The alert component. And when that's done
, what you want to do is that you want
to see what's the electric consumption? Okay, to
decide whether or not you should send an alert to
the user. Okay, so we're going to define
the alert component. As you can see, this
is a really a component declaration. It says that
that alert component is going to produce integer values.
And here you can see you have what we call
an interaction contract that will provide information about how this
component interacts with other components. Okay, so what
this is saying in a very maybe verbal this way
when provided takes second from clock. So when when
this guy here provides me with some time information,
get the consumption from the electric meter. As you
can see here, we are giving now some details
about who's pushing information. Who is getting information.
Okay. The pull push information here is being given
in this interaction contract here. Okay, And when
that's done, maybe we'll publish some value. Maybe
we'll publish some integer value. Okay. All right
. And we're saying maybe because in fact, we
won't publish any new value if the we realized that
the cooker has been on for, uh, some
time, but not too much. Okay, um
, let me show you the notify component now.
So if we do get a message, uh,
from the alert okay to the notified component. So
here's the specification of that component. What it says
is that when I'm being provided an alert from the
alert component, then I'm going to do an action
, which is to ask a question to a TV
prompter. So this is how we're going to interact
with the user. We're going to prompt the user
, okay? To decide whether or not he or
she wants to turn off the cooker. Okay.
And now we're going to get the answer to that
question through the remote control. Okay, so,
I mean, we we didn't really invent that application
. Uh, this is some work that we're doing
with some some research project we have for assisted living
technology where we're trying to apply that work to uh
, assisted living for the elderly. And, uh
, this is a typical problem that arises, Uh
, with when you have some some cognitive deficiencies is
that to forget about things that you've done like,
and it happens to everybody. I mean, just
forget you just forgot that you forgot you had something
on the stove. And so and the idea that
we had as well was to use devices that were
, uh, common, uh was, uh,
easy to use. Okay. For elderly users.
And, of course, the remote control of the
TV is something very, very easy to use.
Okay, so now we're prompting something okay to the
user, and the user is supposed to give us
an answer. So this remote turn off component here
, okay, is doing is producing a boolean value
. It's maybe published and says when I get an
answer from the user using the remote control. Okay
, well, I get is that I'll just check
that the cooker is still on. Okay. And
, uh, if that's the case, then I'll
just call the turn off component that is supposedly going
to turn off the cooker. So here is the
turn of component. There's something interesting about it is
that when when it gets when it gets a value
from the remote turn of component. As you can
see here, the only action that it's supposed to
do is to turn off the cooker. And right
there you can see already that the designer has given
us some interesting information because what it says essentially,
is that that application. If if I can make
sure that the implementation is in conformance with that design
, what happens that that application is completely unable to
turn on the cooker by itself? Okay, and
that's expressed in a pretty concise way in the design
. Okay, and that's that's important when you're doing
, you know, uh, software development. That's
kind of, uh, intertwined with, uh,
vulnerable users. Okay, so let's see what we
get for those decorations. What do we get for
that? Okay, so for every design unit,
Okay, some piece of code is going to be
generated and usually takes the form of an abstract class
in Java. So let's look at this example here
. Okay. The, uh, the alert,
context, component context declaration. We can see that
this thing here is being compiled into an abstract class
okay, which is called abstract alert here. Okay
, but remember, we want I mean, this
is where we actually bridge, uh, the our
design language with the general purpose language. Okay,
this is the place where, okay, you declared
your components. Now you need to implement them.
Okay. And what we're going to do is that
where we will assist you in doing that by generating
those abstracts classes. And what you have to do
is that you have to extend those abstract abstract classes
in order to implement those components. So here,
for instance, we we extend the abstract alert class
, okay. To define this alert class. Okay
, Uh, if you are working in a development
environment like eclipse, what this is going to do
is that this is going to generate a skeleton.
Okay? Where you have to essentially fill the holes
. Okay, that you have to implement in order
to finish your your implementation work. So here,
for instance, we had, of course, this
we have We need to have some kind of a
call back. Okay. Something that says remember here
It says when provided six second. Okay, So
what it means is that that component is going to
be invoked every time the clock. Okay, uh
, generates a tick second. Okay. So,
uh, so this is what's happening here. We
have this, uh, this procedure here that we
have this method here that we have to to,
uh, to implement. Okay, This is because
we have a when provided six seconds. So we
have generated an abstract method that we now have to
implement. Okay. Uh, of course, this
is getting, you know, the tick. Second
, whatever value that device here is generating, okay
, it's producing, and we have discovered parameter here
, okay? And that discovered parameter is going to
be the key thing. Two the enabling parameter to
actually get our hands on the electric meter. Because
so far, we don't have the electric meter.
So we got we got the clock Essentially, that
invoked us, push some value into us. Uh
, in order to find out whether we we go
, We went over the cooker, went over the
the time limit, but now we have to,
uh, we have to get our hands on the
electric meter in order to know whether, uh,
you know, the this this cooker is still on
. Okay, and we have a may be published
here. So this is, uh this is a
type that were generated, which is an alert value
publishable. That's that's all generated by our, uh
, generator of of programming, farm works. Okay
, uh, so let's see how we implement.
Okay, So So, uh, Eclipse, for
instance, generated that skeleton, and now we need
to fill the holes. Okay, so we're essentially
implementing okay, what we're supposed to do, okay
. When the clock invokes that component, Uh,
okay, so we we do some some calculation here
to make sure that, uh, to determine whether
or not, uh, we've went over the limit
. Um, what's interesting here is that this is
this is something that we, uh we need to
do in order to implement. That component is,
as I said, to get our hands on the
the electric meter. Okay. And we do that
by this discover parameter that allows us to with this
with this request here. Okay, What we do
is that we're discovering the electric meter. Okay,
so, I mean, the details are not important
here, but what you should see is that,
uh, we are doing a discovery of the electric
meter by, uh, you know, a symbolic
name here. Okay, So what it means is
that when we installed, okay, the infrastructure for
our user. Okay, we we installed the electric
meter, and we declared the fact that, of
course, the electric meter was in the kitchen.
Okay, So that the application can Then when it
gets deployed, okay, can get the electric meter
of the cooker. Okay. Again, All that
was generated automatically. And one thing that's interesting is
that you can only discover the things that were declared
in your design. Okay, so there's no way
you can mess around with other devices that weren't in
the design. Okay? And that's a That's a
key thing. You can only discover What what is
, uh, in conformance with the design. And
here, Okay, you have to return a value
of the type alert value publishable. And again,
we're leveraging the, uh, type system of java
, you know, to force the programmer to produce
the value of that type. And, uh,
so if we have gone over the time limit of
the cooker being on, then we will publish that
value, uh, to, uh, the component
that will send an alert on the TV, and
that's we're gonna, you know, tag that as
true. Okay, so that means that value gets
published. Otherwise the value gets, uh, this
false value, which means it doesn't get published.
Okay, Um all right, so So that's the
example we I wanted to show you, and and
I wanted to, uh for you to see that
the framework generator actually does a really good job of
generating all the kind of boilerplate code that we don't
want to deal with. Okay? And well,
the programmer concentrates on is really the the application logic
. Okay, All the kind of the bookkeeping and
all that, okay, is completely abstracted away.
Okay, so, uh, as I said,
I mean, this is kind of a project that's
been going on for five years, so we've covered
quite a quite some ground in in this in this
approach. Uh, one thing we did was to
, uh, essentially, uh, define a methodology
. That's kind of driven by this design language.
Okay, Uh, and that that is what exactly
should you do? And how should you? Should
you leverage the suite of tools that we're providing you
with? Okay. To develop applications. Um,
what we did as well was to, uh uh
huh. To define precisely what we meant by this
functional design. And this is what I showed you
in those interaction contracts. Okay, so we we
we came up with this this way of expressing the
functional design of an application, and we showed the
kind of program verifications that could be done based on
this contract declaration. Um, we also showed how
you can leverage those decorations to generate programming frameworks.
Okay. And that that's very important in the sense
that, uh, as I said, it supports
the programming, but also, it kind of forces
the programmer to implement, uh, certain aspects of
the application. And for that, we're leveraging again
. The type system of Java. Yes, language
. Is there more to Yes. Yes, yes
, yes. There are other things. Like,
you know, you can You can, um You
can, For instance, um, so I said
, maybe published, but there's also always published or
not published, So you may wonder why we insisted
on all these variations Is because sometimes you want to
make sure that, for instance, if you're getting
some, uh, some critical, Um uh signal
from a from a sensor. You want to make
sure that that there will be a functional chain Okay
, up to some, uh, actuator. Okay
, for some critical situations. So, for instance
, the sure that the fire detector, for instance
, is always linked to some alarm, for instance
. Okay, that you will trigger, uh,
whenever you know, that guy sends a signal.
Okay. Uh, what I was thinking about is
, is there any way to represent state? So
, for example, in this figure, supposed that
you wanted to model the safety requirement that if the
user ignores five requests, you're going to turn the
car off regardless of anything else. Okay. You
need some state? Yes. Yes, you can
express it, but you can express it at the
Java level. Okay. Uh, it is not
as it is now. It is not is not
the case. So I understand. Uh, so
this is a This is a discussion I had yesterday
, and and there's there's some details that I'm kind
of grossing over here, which is that there's one
thing that's really critical is exactly where you're going to
You're going to You're going to position the design language
I mean, if you say too little, okay
, you won't generate much. And the programmer is
not going to have, you know, some benefit
for the time spend designing things. If you say
too much, then the programming is useless. I
mean, there's nothing to be done there. It's
and you are somehow, you know, replicating the
work of a of A programming language. So there's
really a balance to strike between those two things.
And you're right. I mean, this could be
a very critical requirement in a particular domain. Okay
? And one could imagine that adding that, you
know, dimension to our design language. If it
were critical in in the in the in the particular
domain. Yes. Yes. Yeah. Um,
okay. So? So that generative programming approach here
is interesting. In a sense that you you really
can, um, uh, generate a lot of
code that obstructs over things like, um uh,
for instance, Uh, we we we've seen we've
seen devices here, but nothing tells us whether there
are real devices or simulated devices. Okay, So
, in fact, we built something. I'll show
you very small video where you can see that we
can simulate actually uh, an environment. Okay.
A physical environment. We don't have to have,
uh, uh, you know, only concrete devices
, or it can be a mixture of the two
. Okay, so we have done some work on
simulation. Okay, Um, we also did some
work on having different kind of underlying distributed technology.
So we use, uh, we use sip,
which is a session initiation protocol. We used corba
. We use web services. We don't know what's
the underlying distributed technology? Um, we did some
work on non functional design as well. So some
work on declaring air handling okay, at the design
level, which is, which is something that people
hadn't really uh, investigated before? Like, how
can you express air handling? Usually you do that
, uh, using, try and catch directly in
the program. And everybody knows that this is,
you know, it's it's it's getting the code is
getting very messy with that, And and there are
some critical decisions that are buried in the code.
You would like to raise the level of that into
the design so that things become more easier to reason
about. And, uh So So we did some
work there. We did some work in quality of
service contracts as well, because again functional. Once
you get the functional design, it's a great vehicle
to actually express other dimensions of the design. Okay
, so we did things in quality of service contracts
as well. And this is to explain to give
a little context here. We were working with a
company in the UNIX domain, and this is this
is really, uh, concerns that they had and
and in fact, we we ended up doing some
some some some piece of work where we we kind
of gathered, uh, the functional and non functional
design for a particular application, which is the autopilot
kind of showing the, you know, how are
, you know, pieces of of of research here
kind of fit together in a in a full fledged
realistic application. Uh, and and there's some work
that we reported on the on the description of the
whole too sweet. Okay, so that's kind of
give you a picture of what we've done. Let
me show you a little example here on the access
control, you'll see how we do the simulation.
What we wanna do here is to control the access
to, uh, rooms in the building. We
do some simulation of a digital building of agents moving
around. So I'll show you what what our tool
does. And it's a hybrid simulation, because here
you have some components that are actual software components running
for real. Um, so here's what we have
. Uh, so this is this is the layout
. We have a we have some, some physical
layout, and we have logical layout on the top
of it to show limits of rooms and things like
that. And we have little agents here that we
can move around. Um, and here you have
the timeline. Uh, and right. You have
location and other other things. Um, miss,
you killed? Yeah. Yeah. So the first
thing here is Agnes are Our agent is gonna so
you can see here. You have a motion detector
that went on, and you can see the visualization
of that. So then we can move agents around
. So here, for instance, we locked those
two rooms, okay? And when Agnes is gonna
go around, she's gonna be denied the access of
this room. Um right. And then then we're
unlocking those doors and and and allowing Agnes to enter
a room. And here you will see that the
motion detector. So here the lock is open,
and then the motion detector. Uh, Okay,
So this is just an example to show you that
, actually, the this code, this application okay
, is the same, whether it's simulated or whether
it's run on the on the real on the real
, uh, environment. Okay. And the other
example, uh, how am I doing in terms
of time? Uh, Okay. So just wrap
it up 15 minutes. Okay. Good. Uh
, so a little bit of time to explain what
the autopilot is. It's a real It's a real
size application that we actually spend a lot of time
working with. The people in Talas, this unique
company. Um, I wanted to get the requirements
that they're using in real life. Um, it's
safety. Critical system. Of course. We wanted
to capture the functional and nonfunctional requirements, and we
used, of course, we didn't use a real
plane. We used a realistic simulator, which is
flight gear. Maybe some of some of you know
that, uh, and interestingly, we did a
kind of we duplicated that work for not a pilot
for drones. The drones. Um Right, so
So this is this is, uh this is part
actually of the autopilot. A visual representation of that
in our dia spec language. So I won't go
into the details of the whole thing. But just
you have some some senses here that are, um
, kind of multi functionality. The initial unit.
Uh, there's the air unit and and and so
on, so forth, the autopilot and a route
manager. And I'll show you a little video afterwards
where you will see those panels, especially the autopilot
gooey. And the route manager that will be shown
on the screen. And the initial unit is a
critical component of an autopilot. Okay, It has
the position of the of the plane, the role
, the heading. So this is a critical component
. And when that component fails, Okay, the
the autopilot needs to be, uh, turned off
. Essentially. Okay. And that's a requirement.
I mean, there are lots of requirements about this
, but this is like the one I want to
illustrate. Uh, today, Um Okay, so
right. So we can have a failure here and
what we need to do in order to be in
conformance with the requirements is that we want to have
on the side here. Still in in our language
. Okay. This kind of, uh, supervisory
layer that's gonna monitor, uh, so this is
really directly using our approach for declaring errors. Okay
, So we want to capture here a failure of
those key components and what we want to do in
accordance to the requirements is to eventually deactivate the autopilot
. And again, this is something you want to
see in the design because this is something that appears
in the requirements. Um, interestingly, for the
purpose of the simulation, we have some, uh
, senses that are emulated, okay. And others
that are real, uh, real, uh,
real devices. So the route manager and the autopilot
, we are actual gooey that that are implemented.
Uh, well, on the on the desktop,
but right and and right that right. So it's
a hybrid simulation that regard. Okay, so So
here, let me show you a bit about what
we have here is the route manager here that we're
gonna use. Okay, This would be what the
pilot would have to to to to use so so
it can change intermittent points. It can change the
final heading. Uh, and as you as you
change those guys, then the essentially the plane is
gonna is gonna change route. Uh, here we
have the control display unit, Uh, that the
pilot will have, and this is essentially saying how
those devices are behaving. Okay, so if one
fails, Okay, the pilot sees that it's failing
, and this is our panel that we added to
inject faults. Okay. Um right. And And
this is this is the the autopilot Okay, that
we can, uh, we can control, so
So we can engage the autopilot. So this is
going to start with the the autopilot being engaged.
Uh, oops. No. Okay, So the
autopilot is engaged, and we're going to show you
that the autopilot is indeed engaged by moving the route
here. Okay. And as you can see,
when you move that, uh, the the plane
changes its route. OK, then we're going to
inject a fault in the inertial unit. So that's
being detected. That's of course, one thing that
that is in the requirement, and as you can
see now, we're changing the route, OK?
And the plane doesn't change Okay, so that's what
you want as a behavior. Um, Then we're
gonna make you know, uh, trigger backup initial
unit. We're gonna engage the autopilot, okay?
And and and and now it can be re engaged
. It can be active because everything is fine.
And now you can see that the autopilot is back
on, okay, It's just to show you that
, you know. So it was kind of interesting
, because again, it's not. It's interesting because
you have this abstraction layer that allows you to run
on a simulator. And it's interesting because you can
test your software prior to deploying it, and and
it's interesting as well because we were able to show
to these people that they could actually see the requirements
being expressed in the design at a high level.
Okay, Uh, so so we're actually using this
technology for the for assisted living in general and and
home automation Home automation in general. Uh, we
We we see that as a kind of an app
store of applications. Okay, that you can you
can actually deploy. And we have this independence with
respect to the devices because we have this abstraction layer
. That's pretty useful because we can be very technology
independent. Um, okay. Expanding on that work
, uh, we are doing, uh we're doing
some work on user evaluation of design driven software development
. I mean, one thing we want to show
is whether or not we're You know how much we're
gaining by doing this design driven software development. Okay
, compared to doing java from scratch. Okay,
so you have no design, uh, phase.
Okay. Uh, so we started some work.
Unfortunately, the postdoc working on that left, So
we, we we we stopped. But hopefully we'll
start again on scalability. We have some work going
on because we are part of a project. I'm
sure there are projects like that here. It's a
smart city project where it's an interesting technology, actually
. That's being deployed in France. It's actually deployed
. Uh, you know, like, as of
now, it's already deployed in France. You have
the senses, and later on, we'll have activities
that are essentially spread everywhere in the city. There
are low band with senses, and they, uh
, they only require very few antennas. Okay,
so for the whole city of Bordeaux, which is
about one million people, uh, you have.
I think something like four or five antennas, which
is not much. Uh, and that's that's the
force of this technology and the census because they don't
emit too much. Okay, uh, they don't
consume battery much, so their lifetime is about,
I think, five or 10 years I can't remember
because they emit, like, every, you know
, three minutes or something like that. So So
it can be deployed just about everywhere. It can
be deployed in a say, uh, you have
some a billboard, for instance. Okay. And
that you can put a little, you know,
censor there. That's going to make sure that you
know that billboard is functioning, for instance. Okay
, you can put that just about everywhere. Uh
, and so So we're part of this consortium.
Uh, and, uh, the idea there is
that we're gonna have lots of senses, of course
, spread across the city. And there's some scalability
, uh, thing that we will be interested in
doing because we are part of this consortium in order
to bring the kind of app store, if you
wish. Idea. Okay. Like there is this
great technology. Fine. We need to have lots
of applications that will leverage that infrastructure and provide services
to users whether they be, you know, municipalities
or, you know, officials like, uh,
you know, government organizations or whatever or commercial companies
. So we need that. And so they were
most interested in this APP store idea. Um,
okay, leveraging further leveraging the design is for certification
. This is what we're doing with the avionics company
. Design driven evolution, the design driven testing,
you know, just again leveraging the design to do
more. Uh, and and then there's one thing
that, uh, one piece of work that we
just finished that well, we just finished. We
finished one step of it because this much more to
come. Uh, and and that's the idea.
Is that so? We we have this design paradigm
and we do functional design. We do non functional
design, and that's fine. This is more or
less what I showed you very quickly. The problem
is that we are not, um, remember,
we were interested in, in in, in having
a software that's deployed with vulnerable users. Okay,
that's kind of embedded in their life in their daily
activities. And in order to do that in a
safe way we really want to take into account in
the design user interaction dimension. Okay, So what
we did was to introduce in our design language this
this user interaction. Okay, uh, enabling a
designer to express what an application requires as far as
interaction with the user. Okay, so that's part
of the thing. Okay? Part of the of
our approach, Another part of the approach is whenever
we target a group of users, Okay, we
want to characterize this group of users. Okay,
There's this group of users have memory problems. Uh
, executive function problem. Uh, you know,
sensory problems. Okay. We want to characterize that
group of population that the group of users that we're
targeting a set of applications for okay, in order
to then be able to match. Okay, The
what the application requires from the user and what the
user is capable of of providing. Okay, Yes
, I've actually done so. So we're doing We're
doing that with some, uh, cognitive scientists in
Bordeaux. Yes. So this is my last slide
. So please, if you have questions, Yeah
, that we have time for a couple of questions
so earlier. I can describe this a paradigm.
So what I took that to mean is that what
you envision here is potentially standing. The model that
you develop, as we were language into other kinds
of applications remains. You're not proposing a fixed target
for all applications, but but do you have thoughts
about what other kinds of applications were made? You
might be able to incorporate Paradigm? Yeah. I
mean, so So, so far, we're working
on different, different directions. One is, um
, simple, you know, building home automation.
Actually, the the former student of mine is doing
this technology transfer, and this is where they're they're
heading as far as creating a startup on using the
company. Uh, using this technology, Um,
another track is assisted living. I mean, this
is what I talked about. Yet another one is
, um, avionics. I mean, this is
the other the other track I talked about, but
I I think it's pretty open. I mean,
we we we did some work on, uh,
mobile applications as well, because, you know,
a smartphone has a lot of senses and activities,
so you can imagine that a bunch of applications could
be nicely expressed using that, uh, using that
paradigm. Okay, so and really, the rest
is open. I mean, we've had some contacts
with the automobile industry as well. I mean,
they're they're, you know, they're they're essentially,
you know, there are problems there. I mean
, I don't know how it is here, but
there's this trends in in, uh, in Europe
, where they try to have the equivalent of an
app store in the car where you can essentially,
you know, get some interesting applications using using information
, using the sensors and actuators of the of the
car. So you use the GPS, you use
some information about how much gas you have. You
know what's your favorite? You know, a gas
station or restaurants or whatever. And you can you
can, you know, imagine lots of things that
will use senses of the car. Like you know
how it's functioning or use. You know, other
things, like GPS or, you know, screens
or, uh and so on and so forth.
So So, um, you know this This is
, uh yeah, it seems pretty. It seems
pretty, uh, pretty open. And, uh
, I guess the way I like to see it
is that there's a lot of problems can be solved
with this paradigm. And it's just like the object
oriented paradigm. You have to kind of, you
know, frame your brain into this thing. And
then and then you know, the solution can be
expressed more or less. Yeah, just go.
I was about to say Okay, Sean, if
you have a domain that is veterans, president,
non imperative language, White job, for example,
you would express it in collected language. Or perhaps
in first one when you, um first of all
, I guess what skin is your approach to?
Designed to blind? Um, is it more amenable
at the top end DSL itself, or would you
change the underlying implementation? Well for you? So
if I had to to to to target a different
language than than than an object oriented language, right
? Uh, so I think one thing we we
we I mean the requirements. If we had to
change the target language, the requirements would be to
have a type system that would allow us to,
uh uh and force the design declarations. You know
, uh, during the programming phase. I mean
, this is really what we want is is in
order to leverage. I mean, you want to
leverage the design as much as possible. And the
thing that the way you can do that is by
leveraging the type system. So So this would this
would be a requirement, Uh, and definitely programming
frameworks. I mean, this is something that we
, you know. I mean, your question is
really right on target because we were really trying to
see how we can generalize that idea, uh,
to generalize in terms of different paradigms and and generalize
in terms of different target language. And indeed,
there is a kind of almost a philosophical question,
which is, you know, what constitutes a programming
framework and, you know, and it's an open
question. I mean, we've looked at the literature
and we we didn't find, you know, uh
, anything, you know, specific as to.
So we we understand intuitively what a programming framework is
, but we don't have any neither, you know
, formal definition or, you know, something that
that that goes across languages. So, for instance
, what is a programming framework in a functional language
? I mean, that's that's an open question.
Uh, it isn't just it isn't just Dr scheme
. I agree. I agree. So so?
So I I don't have any good answer to your
question. Uh, but, uh I mean,
this is definitely something that we're most interested in exploring
is yeah. Uh, I was years ago.
So when when they claim devices using extends actuator,
I forget. Oh, I was only inviting.
Why did use implements us? Because there's some devices
. Mhm, actually there. Oh, they are
. Yes. Yes, there are. There are
. There are. So we use a range of
technology. We use a Z wave. We use
zig b we use I mean all those all those
technology and are available in, uh, you know
, in the stores. Uh, I can you
know, they have those, um, those,
um uh uh How's he called? Plug, plug
. Remote plug. Okay, essentially something where you
can you can You can control the electricity. Okay
. Um so you you put that in your in
your socket? Uh, and and and then you
can You have that in the Z wave technology,
for instance. And you can control the you can
control the light. For instance, you can you
can you can branch something and you can plug something
, and then you can control, but you can
do two things with that. You can you can
turn on and off. Okay? And you can
also, uh, so this is the accurate aside
. Okay? But you have also a sensing side
in a sense that those, uh, module,
uh, those modules allow you to also test the
electricity, the electric meter. So they have a
sensor side of things. What was your question about
the target language? I'm sorry, extending the class
rather than using an interface. Oh, I'm sorry
. So the interface could allow functionality for either kind
of a sensor or actuator? Yes, to the
extent restricted your Oh, right, right, right
. You're right. In fact, so this is
kind of a toy example, but in the in
the description we have, you do extend device,
okay. As opposed to extend sensor or extend actuator
, you extend the device, okay. And and
in fact, the device can have, you know
, in the same decoration, you can have actuate
ng kind of the, uh, decoration of actuators
and decoration of sources of information. So So in
the same declaration, the language allows you to declare
devices that have those many facets In fact, many
sensing facets, many activating facets. Is that is
that AM I answering your question? So I just
want to remind everybody because close down that this afternoon
from 4-5 and I think there's cider and goodies or
something like that And he really welcomes, uh,
meeting students here. So anyone here, people who
didn't make the talks are invited to come and meet
him again and talk to him more length. So
thank you very much, yes.