Machine Learning and Software EngineeringSeparated by a Common Language

Amel BennaceurThe Open University, UK

SEMLA 2019

From Instructions to Collaboration

2

School University

PhD

Three Generations of SE

3

1st Gen: Explicit Instructions 2nd Gen: Through Examples

3rd Gen: Through Collaboration

In This Talk

●Case 1: ML and SE (Synthesis) for Interoperability(https://www.connect-forever.eu)

●Case 2: ML and SE for Socio-Technical Resilience(https://stretchproject.org/)

4

Illustrating the Interoperability Challenge

Collaboration in Emergency Scenarios

5

Heterogeneous Interfaces

What actions do the component offer?How do we interact with a component?What protocol is used by the component?

, Behaviour , and Middleware

Highly-dynamic and complex environments

Mediator Synthesis

6

Running-SystemLevel

Model Level

Model Extraction Model Extraction

Translator Synthesis

Controller Synthesis

Middleware Synthesis

Domain knowledge(Ontology)

1

2

3

Mediator

Matching processes

ControllerModel of System 1

Model of System 2

System 1 System 2

Assuming the fidelity of the models, the composed system is

guaranteed to be ‘correct’

Modelling Components

7

ì Ontology-based functional semanticsì Capability

The high-level functionality of a systemì Interface

A set of observable actionsì Automata-based behavioural semantics

ì The way the observable actions are coordinated

ì At both application and middleware layersApplication → Business logicMiddleware → Communication

& coordination protocol

Capability (CapWDAV) Requires fileManagement

Interface signature (IWDAV)

Behaviour

<Authenticate, {Username, Password}, {Authorisation}> <Lock, {SourceURI}, {Acknowledgment}><MoveFile, {SourceURI,DestinationURI}, {Acknowledgment}><ReadFile, {SourceURI}, {File}><Unlock, {SourceURI}, {Acknowledgment}> ...

Authenticate

Lock

MoveFile/ReadFile/WriteFile

Unlock

Logout

Behaviour (WDAV)

SendHTTPRequest[Authenticate] [Username, Password]

ReceiveHTTPResponse[Authenticate] [Authorisation]

However, many systems only advertise their interface

descriptions

Learning the Component Model

● Input ●The interface signature of the component

●Outputs●The capability of the component:

What the component does●The behaviour of the component:

How the component achieves its capability

●Algorithms●Supervised learning for inferring capability●Automata learning for extracting behaviour

8

Networked System 1

LoginGetTemperature

GetHumidityLogout

Provides weatherBehaviour

Capability

Login

GetTemperature

GetHumidity

Logout

??

Learning to Infer Capabilities

9

Statistical Learning

SVM

Design time

Trainingexamples

Ontology

Categorisationfunction

b c

a d

Thing

Interface 1 ⟼aInterface 2 ⟼bInterface 3 ⟼d

Categorisationfunction

Runtime

Interface description

Ontologyconcept

Learning to Infer Capabilities

●Classify systems into categories according to their WSDL interface description

1. Apply standard techniques from text categorisation ● Support Vector Machines

2. Extract the distinguishing features● Use the bag-of-words representation: a histogram

of the words occurring in the document to categorise

Design time

10

Learning to Infer Capabilities

3. Represent a WSDL interface description as a feature vector ● WSDL contains various types of “text”: comments,

method and parameter names

Runtime

11

<wsdl:message name="GetWeatherByZipCodeSoapIn"> <wsdl:part name="parameters"

element="tns:GetWeatherByZipCode" /> </wsdl:message> <wsdl:message name="GetWeatherByZipCodeSoapOut">

<wsdl:part name="parameters" element="tns:GetWeatherByZipCodeResponse" />

</wsdl:message>

Extracted bag-of-words feature vector: get:4, weather:4, by:4, zip:4, code:4, soap:2, out:1, response:1

The Benefits of Capability Learning

● Learned capabilities speed up matching●Provides an efficient coarse-grained compatibility check, before

considering mediator synthesis● Capabilities must be equal or ontologically related (subclass)

12

The Downside

●Experimental rather than a systematic process

● Incorrect components descriptions

●Prevent good connections from being made

●Matching or goal satisfaction fails and cause bad connections to be made

●Matching succeeds when it should not and cause good connections to fail through incorrect synthesis

●Feedback loop may capture failures13

Automata Learning for Extracting Component Behaviour

● Incrementally construct a deterministic finite automaton that matches the behaviour of the component on the basis of test-based interaction with the system. ●Based on L* algorithm●Start with the most general behaviour that allows any sequence of the operations of the interface to be executed ●Test and refine when an interaction errors, aka a counterexample, is discovered

14

Automata Learning for Extracting Component Behaviour

15

GetWeatherLogin

Logoutt0

Networked System 2

Login

GetWeather

Logout

Login Logout

GetWeather

t1

t2Login

Logout

GetWeather

Counterexample 1GetWeather Login

GetWeatherLogin Logout

Counterexample 2

On Using L* for Behaviour Extraction

●Strong assumptions about the systems to learn●Must be able to reset the system●Must have a wrapper for communicating with the system

●In most cases, no guarantees about completeness or convergence of the learnt behaviour (in general case)

●Some interesting properties to build upon●The learnt model evolve through refinement by discovering counterexample

16

Requirements-Driven Synthesis

17

Component 1 Component 2

Component 3 Component 4

Operational Environment E

Component 1Component 2

Component 4

Secure Operational Environment

Mediator

Objective123

Selecting and configuring componentsMaking components collaborate

Identify adequate adaptation strategy

Requirements analysis1

Feature Selection Features-driven Mediator Synthesis2 3

Adaptation strategy

Selected features

Requirements R

Capabilities

Technique

Mediator synthesis

Feature modelling + Constraint programming

Goal modelling12

3

Does it work?

18

19

Putting it Together

20

wind

AtmosphereThing

Nothing

Ontology

weatherInfoHumidityTemperature

GetHumidityLogout

Login

GetWeather

LogoutLogin

GetTemperature4

Mediator

req.login

req.getWeather

req.logout

prov.getTemperatureprov.getHumidityprov.logout

prov.loginEmergentMiddleware

Login(password,.username):.tokenGetWeather(token):.weatherInfoLogout(token):

Binding:'SOAP,RPC

<functionality name="C2Weather" kind="required"> <operation>Weather<operation> <output> WeatherInformation</output></functionality>

Interface

C2 Model (weather projection)

Behaviour

Capability

Login GetWeather

Logout

!Login(username,!password):!token!GetHumidity(token):!humidity!GetTemperature(token):!temperature!Logout(token):!acknowledgmentBinding:'HTTP

<functionality name="WeatherStation" kind="provided"> <operation>Weather<operation> <output> WeatherInformation</output></functionality>

InterfaceWeather station Model

Behaviour

Capability

Login

GetTemperature

GetHumidity

Logout

Discovery Synthesis ExecutionLearning

Towards a Learning-based Mediator Synthesis

●What is the impact of learning on mediator synthesis?

●Can the synthesised mediator help improve the learning process?

●What combined guarantees/assurance can be provided?

21

In This Talk

●Case 1: ML and SE (Synthesis) for Interoperability

●Case 2: ML and SE for Socio-Technical Resilience

22

Circles of Support for Community Healthcare

23

FAMILY

HEALTH CARERS

SOCIAL CARERS

COMMUNITY

PATIENT

SPOUSE

CHILDREN

…

HOSPITAL CONSULTANTS

GENERAL PRACTITIONERS

SOCIAL WORKERS

COMMUNITY NURSES

TECHNOLOGY

NEIGHBOURS

VOLUNTEERS

…

How to monitor, maintain, and adapt circles of supports?

4

Betty

Elaine Sally

Diana

InterventionReview & Monitoring

GP

Adapting Circles of Supports

24

Minimise Social Isolation

- Matching the capabilities of CoS and actions to perform- Planning the sequence/rank of actions to perform either by the participants themselves or their CoS- Enacting/implementing the plan

InterventionPlanning3

- Rule based- Trend analysis

DataAnalysis

Likelihood of social isolation

2

Direct - Automatic: motion, water, door sensors - Manual: mood buttonsIndirect - e.g., sleep, physical activity

DataCollection

Data

1

Requirements, Design, Implementation

25

4 Amel Bennaceur, Thein Than Tun, Yijun Yu, and Bashar Nuseibeh

such as events, objects, states and variables. Some phenomena belong to the world,and some phenomena belong to the machine. Since the world and the machine areconnected, their phenomena overlap (Fig. 1).

Environment Phenomena Machine Phenomena

Requirements (R)Domain Properties(D)

Program (P )Specification (S)

Fig. 1 World, machine, and specification phenomena

Typically the machine observes some phenomena in the environment, such asevents and variables, and the machine can control parts of the environment by meansof initiating some events. This set of machine observable and machine controllablephenomena sits at the intersection between the machine and the world, and they arecalled specification phenomena (S). There are also parts of the environment that themachine can neither control nor observe directly. Indicative statements that describethe environment in the absence of the machine or regardless of the machine are oftencalled assumptions or domain properties (D). Optative statements expressing somedesired properties of the environment that are to be brought about by constructingthe machine are called requirements (R). Crucially, requirement statements are neverabout the properties of the machine itself. In fact, Zave and Jackson assert that allstatements made during RE should be about the environment. That means that dur-ing RE, the engineer has to describe the environment without the machine, and theenvironment with the machine. From these two descriptions, it is possible to derivethe specification of the machine systematically [51].

Accordingly, Zave and Jackson suggest that there are three main kinds of arte-facts that engineers would produce during the RE process:

(i) statements about the domain describing properties that are true regardless ofthe presence or actions of the machine,

(ii) statements about requirements, describing properties that the users want to betrue of the world in the presence of the machine, and

(iii) statements about the specification describing what the machine needs to do inorder to achieve the requirements.

These statements can be written in natural language, formal logic, semi-formal lan-guages, or indeed in some combination of them, and Zave and Jackson are not pre-scriptive about that. What is important is their relationship, which is as follows:

The specification (S), together with the properties of the domain (D),should satisfy the requirements (R): S,D ` R.

Requirements Engineering 7

Requirement ID: Requirement Type:

Event/use case:

Description:

Rationale:

Source:

Customer satisfaction /dissatisfaction:

Fit criterion:

Supporting materials:

History: Date that the requirement was first raised, dates of changes, date of deletion, dates of consolidation of the requirement

Additional material that is important to the requirements

A measure (1-5) of how pleased/dipleased the client will be if the product delivers an implementation of the requirement

Quantified goals that the product has to meet

The person or group who raised the requirement

The reason behind the requirement’s existence

A natural language statement as to what is required

The context of the requirement is broken into smaller pieces using business events in use cases

Categorise the requirement Unique identifier

Fig. 2 Volere Template (adapted from [95]) Double check permissions to reproduce the template

2.3 Processes

Requirements often permeate throughout many parts of systems development (seeFig. 3). At the early stages of system development, requirements have a signifi-cant influence on system feasibility. During system design, requirements are used toinform decision-making about different design alternatives. During systems imple-mentation, requirements are used to enable system function and sub-system testing.Once the system has been deployed, requirements are used to drive acceptance teststo check whether the final system does what the stakeholders originally wanted.In addition, requirements are reviewed and updated during the software develop-

System feasibility

RequirementsEngineering

Design

Implementation

Running System

Architecture choice

Testing &Prototyping

Acceptance testingEvolution

The problem space The solution space

Fig. 3 RE and software development activities

ML vs SE

26

It is all about data It is all about models

Implement to understand Understand to implement

Focus on the whole Divide and conquer

Machine Learning Software Engineering

Mathematics

Thank you

Further Information

● Home page: http://amel.me

● Group: http://sead.open.ac.uk/

● [ICSE18] Machine learning for software engineering: models, methods, and applications. ICSE – Technical Briefing

● [TCPS17] Feature-driven Mediator Synthesis: Supporting Collaborative Security in the Internet of Things. ACM Transactions on Cyber-Physical Systems

● [TSE15] Automated synthesis of mediators to support component interoperability. IEEE Transactions on Software Engineering, 41(3): 221-240, 2015

● …

28