PRELIMINARY REPORT

CO7201 – MSc Individual Project Autumn Term 2019

COMPARISON OF SPECIFICATIONS

SYED WAQEE WALI

Student Id: 169049581

Supervisor: Dr. Jan Oliver Ringert

Second Marker: Dr. Rayna Dimitrova

Date of Submission: 25 October 2019

Word Count: 1715
DECLARATION
All sentences or passages quoted in this report, or computer code of any form
whatsoever used and/or submitted at any stages, which are taken from other people’s
work have been specifically acknowledged by clear citation of the source, specifying
author, work, date and page(s). Any part of my own written work, or software coding,
which is substantially based upon other people’s work, is duly accompanied by clear
citation of the source, specifying author, work, date and page(s). I understand that
failure to do this amounts to plagiarism and will be considered grounds for failure in
this module and the degree examination as a whole.

Name: Syed Waqee Wali

Date: 25 October 2019
Introduction
Motivations
In the existing world of iterative development methodologies, software model
specifications change and evolve continuously during different phases of software
lifecycle. Maintaining and keeping a track of these changes and their impact on the
system has attracted much interest in order to find ways for managing such differences
between versions. Though there are approaches to model version differencing, they focus
on syntactic differences more than semantic (what those changes imply in meaning).
A straightforward approach would be to compare and match the names and structures
in different versions of the specification. For example, consider the programmatical
expressions, x = x + 1 and x = x++. Even though the syntax is widely different, the
semantics of both expressions is same, i.e, to add 1 to the value of x. While this approach
works, changes that are similar in a syntactic way may differ semantically. For example,
if the same equation x = x + 1 is changed to x = x – 1, now, even if these look
similar, they are semantically opposite, i.e, the first expression adds 1 to the value of x
whereas the second one subtracts.
There needs to be a solution devised to find out such semantic changes between versions
of a specification to see what implications the changes could have on the system, and
how the system has evolved between iterations.
Alloy
Alloy is a language and tool used to model relational logic specifications and the
behavior of a system using complex structural constraints. An Alloy model is a collection
of definitions of constraints applied on a set of relations between structures of the
system as described in the specification. This collection can be used to model and check
the behavior of said system by generating instances of the model which satisfies those
definitions. Each instance can be validated by visualizing it using the Alloy Analyzer.
The language itself is based on the notion of relations and is heavily inspired by the
specification language – Z and the syntax resembles that of the Object Constraint
Language (OCL).
Alloy Analyzer
Alloy Analyzer provides automatic analysis for models created using Alloy and
incorporates a visualizing tool to study and monitor the solutions generated. It can also
compute if the specification is valid and if any instances of the model defined can be
generated. The Analyzer is comprised of a source editor to program the models and
constraints, compiling tools to compile and validate the model and a visualizer to view
the instances generated in a bounded scope.

Aims and Objectives

This project aims at extending the Alloy Analyzer in order to compare and find semantic
differences between variants of specifications of a system modelled using Alloy. This will
involve detecting syntactic and computing semantic differences between different
specifications of the modelled system. Semantic differences will be visualized as alloy
instances which are possible in one model and not the other.
For the scope of this project, we will be working with focus on the implementation aspect
of the comparison, and as such, support for only some elements of the Alloy language
will be covered with discussion on how the same can be applied to other elements. A
further research is also considered supporting all elements of the Alloy language,
depending on the outcomes of this project.

Requirements
Essential
• Extend the UI
In order to incorporate the computation of the differencing functionality we
will need to alter the Alloy Analyzer UI. We will need to add in a button to
select the two Alloy Modules opened in different tabs. We would need to add a
new view or revamp the existing editor views to allow side by side viewing of
the imported models, along with the required UI elements to initiate
comparison.
• Generate an Alloy Module
Once the files have been loaded and the comparison process has initiated, we
will need to perform a merger of the two alloy modules into one so that the
required constraints expressed in either of the modules can be converted into
two predicates, each depicting the constraints of one or the other module.
• Support run Commands
In the interest of comparing the two modules, we will need to find a way to
build the run command keeping in mind how scopes are defined in different
versions.
Recommended
• Version Tracking
So that easier comparison can be made between different versions of a module,
we will implement a version tracking system into Alloy Analyzer to load older
changes of a module and possibly diff check with the current version to point
out the changes in syntax.
• Handle Unique Signatures and Fields
There could be differences between the specification versions where a
signature or a field within the signature could be defined in one and not the
other. We will need to alter our algorithm to keep such discrepancies in
reference and decide if they impact the semantics of either versions.
• Support run Commands with Assertions
 We will also extend, if possible, the support for run command as mentioned in
the Essential Requirements section to ascertain the described assertions in
either modules.
Optional
• Highlight and Map Semantic differences to Syntactic
It would be helpful and productive to know what changes in the syntax
caused a particular change in the meaning of the specification of the system.
We would try and accomplish this by pointing out the differences in the
generated predicate and as a result highlighting what changes in the original
syntax of the versions of syntax caused the change.

Challenges
• Alloy – Learn the Alloy specification and understand how its automated analyses
work.
• Research – Research available material on Alloy and explain how Alloy is best
suited for the differencing problem.
• Implementation – Implementation of an algorithm to compute differences not
limited to syntactic but also semantic inconsistencies.
• Modelling –
o Provide an easy to understand real world specification of a system and
annotate it in the Alloy Analyzer.
o Produce syntactically different but semantically similar versions of the
same model.
o Provide enough examples of different versions to prove that proposed
solutions work.

Reading List
[1] Daniel Jackson. 2006: Software Abstractions: Logic, Language, and Analysis.
Cambridge, Massachusetts, London: MIT Press.
[2] Maoz, Shahar and Ringert, Jan and Rumpe, Bernhard. (2010). A Manifesto for
Semantic Model Differencing. 6627. 194-203. 10.1007/978-3-642-21210-9_19.
[3] Daniel Jackson. (2002). Alloy: a lightweight object modelling notation. ACM Trans.
Softw. Eng. Methodol. 11. 256-290. 10.1145/505145.505149
[4] Daniel Jackson. (2019). Alloy: a language and tool for exploring software designs.
Commun. ACM 62. 66-76. 10.1145/3338843
[5] Maoz, Shahr and Ringert, Jan. (2015). A framework for relating syntactic and
semantic model differences. In Proceedings of the 18th International Conference on
Model Driven Engineering Languages and Systems (MODELS '15). IEEE Press,
Piscataway, NJ, USA, 24-33.
[6] Grönniger, H., Ringert, J.O. and Rumpe, B. (2009). System Model-Based Definition of
Modeling Language Semantics. Formal Techniques for Distributed Systems, pp.152–166
[7] Tim Nelson, Natasha Danas, Daniel J. Dougherty, Shriram Krishnamurthi: The power
of "why" and "why not": enriching scenario exploration with provenance.
ESEC/SIGSOFT FSE 2017: 106-116

Methodology
An Example
Consider the following example of different versions of a Customer and their Addresses
specification modelled using Alloy:
module ca1 module ca2

sig Customer{ sig Customer{

livesAt: lone Address, livesAt: lone Address,
} }

sig Address{} sig Address{}

fact { fact {
all c1, c2: Customer | livesAt in Customer
c1.livesAt = c2.livesAt lone -> lone Address
implies c1 = c2 }
}
run {} for 5
run {} for 5

As it is easily noticeable, the fact clause in both modules is drastically different in terms
how it is denoted syntactically. However, in terms of semantics, both these declarations
are same. Both clauses constraint that only one Customer must live at a single Address.
How the proposed solution works
We will build an algorithm to merge both the versions of the specifications as follows:
module caMerged

sig Customer{
livesAt: lone Address,
}

sig Address{}

pred pred1 {
all c1, c2: Customer |
 c1.livesAt = c2.livesAt implies c1 = c2
}

pred pred2 {
livesAt in Customer
lone -> lone Address
}

run {pred1 and not pred2} for 5

Where pred1 and pred2 are predicates generated by converting the constraints (fact)
from two different versions of the specification. Simultaneously, a run command is also
generated to execute instances for the generated predicates. The implication of this
command is for the Alloy Analyzer to find instances of the model specification where the
constraints from the first predicate pred1 hold true but not from those of pred2. If an
instance of such a command can be executed, we can say that there is a difference in the
semantics of both the versions. However, if no such instance could be generated, this
would imply that both the versions are semantically similar.
Testing
An Incremental and Iterative approach towards development and implementation will
be taken to tackle and achieve the requirements. Each task as discussed in the Project
Plan below, incorporates testing and validation of the task before marked as being
complete. A final rigorous and complete testing of all accumulative tasks and functions
will be performed to ensure that changes to the codebase hasn’t impacted the original
functionality of Alloy and the Analyzer in a negative manner.
Plan

Description of Individual Tasks

1. Understand and learn Alloy language – learning the Alloy language framework
and the accompanying Alloy Analyzer.
2. Modelling manual semantic differencing – manually modelling some basic
specifications to get an idea of what procedures need to be followed to automate
the same.
3. Altering the UI – changing the UI of the Alloy Analyzer as described in the
requirements.
4. Basic differencing in code without scopes – start to build the basic algorithm to
automate differencing (without scopes).
5. Basic differencing in doe with scopes – advancing developments on the base
algorithm to include scopes.
6. Essential requirements – development to satisfy essential requirements.
7. Recommended requirements – development to satisfy recommended requirements.
8. Optional requirements – development to satisfy optional requirements.
9. Final thorough testing – a final rigorous and complete testing of the system with
the added functionalities.
* exact dates to be confirmed
Risk Factors
• The author has no previous knowledge of Alloy and the Alloy Analyzer. In order
to satisfy the requirements and aims of the project, it is necessary for the author
to learn and understand the Alloy framework thoroughly. This can be achieved
through rigorous practice and modelling using the Alloy Analyzer on the author’s
part.
• The latest version of Alloy as available for general use is version 5, but the work
focused on for the scope of this project will be carried out on version 4.2. As the
Alloy language’s official website points out about older versions not working on
MacOs, the work carried out in this project may not work on MacOs operating
systems.
• As the author is also working part-time throughout the duration of the project,
time management is of highest priority and should be managed in the most
efficient manner.