Showing posts with label language design. Show all posts
Showing posts with label language design. Show all posts

Wednesday, 20 August 2014

Design by Contract and Security

I've worked with design-by-contract for a long while; in fact its use as an essential programming concept was brought to my attention by one of my professors who didn't just teach it but demanded it as a fundamental part of any design or program. It remains today an integral technique in my toolbox of programming and design techniques. As an aside, Eiffel supports DbC as part of its programming model; it makes it one of the most elegant and easy languages not just to program in but to develop in.

DbC of course is related to the validation that one should make on web page forms and various concepts in strong typing of functions etc. Generalising DbC into other areas such as security, privacy should be an obvious step, but one seemingly not taken.

Via Schneier's brilliant security blog is a link to an article entitled Security As A Class Of Interface Guarantee. It is a long read but one more than worthwhile for software developers certainly; and maybe for any security and privacy engineers too. Actually if there's one article on security and development you read today it must be this one! Here's small sample:
Security Is Part Of Every Interface 
I prefer to think of security as a class of interface guarantee. In particular, security guarantees are a kind of correctness guarantee. At every interface of every kind — user interface, programming language syntax and semantics, in-process APIs, kernel APIs, RPC and network protocols, ceremonies — explicit and implicit design guarantees(promises, contracts) are in place, and determine the degree of “security” (however defined) the system can possibly achieve. 
Design guarantees might or might not actually hold in the implementation — software tends to have bugs, after all. Callers and callees can sometimes (but not always) defend themselves against untrustworthy callees and callers (respectively) in various ways that depend on the circumstances and on the nature of caller and callee. In this sense an interface is an attack surface — but properly constructed, it can also be a defense surface.

At the end of the article is a suprise link to a tweet :-)

Obvious isn't it...?!

Wednesday, 30 May 2012

Semantic Isolation (Pt.1)

Working with Ora Lassila we have been discussing and working on the definition of the term "data silo" in order to clarify our ideas of semantic isolation when applied to databases, data assets and the interoperability and integration of the information contained within.

The term "silo" when applied to databases, data and information is interesting in that it occurs in a number of statements, such as, "my app data is siloed" or "we need to break the data silos" and so on.

The meaning of the term however is mixed in its usage and thus its usage is inconsistent and misleading in many cases; quite simply it is used to cover a large number of overlapping scenarios.

Understanding the scope and meaning of this term in its various contexts is central to understanding the interoperability problem in a practical sense. In a workshop today I have heard the term used in a large number of ways and also applied to the notion of interoperability: The term "silo" has been used to mean (at least!)
  • The data is siloed because it exists in its own database infrastructure
  • The data is siloed because it is on accessible via some access control
  • The data is siloed because it is in its own representation format
  • The data is siloed because it is not understandable/translatable (semantics)
We can present these are some kind of "lock-in" or "siloing continuum", where those usages on the left are more related to physical aspects and those on the right to more semantic in the information sense:




We obviously can create a more granular continuum (indeed that's what a continuum should allow) but the point here is to at least to present some kind of ordering over the differing uses of the term. The ordering runs from physical deployment and implementation through to abstract semantics.

Now it seems that when people talk about "breaking the [data] silos" they are actually referring to enabling interoperability of the data between differing services; and often this is addressed at the physical database or access control level. Occasionally the discussion gets mixed and syntax and representation of data is addressed.

Interoperability of information starts at the semantic level and works in reverse (right to left) through the above continuum; physical, logical, access control and syntax should not prevent sharing and common understanding of data. For example, if one tackles interoperability of information by standarising on syntax or representation (eg: JSON vs XML) then the resultant will be two sets of data that can't be merged because they don't have the same meaning; similarly at the other end of the continuum centralising databases (physically or logically) doesn't result in interoperability - maybe easier system management but never interoperability of information.

Interestingly I had an extremely interesting discussion about financial systems and that interoperability between these is extremely high even at the application (local usage) level and this is simply because the underlying semantics of any financial system is unified. The notions of profit, loss, debit, credit and translations between the meanings of things such as dollars, yen, euros, pounds and the mathematics of financial values is formally defined and unambiguously understood; even if the mechanics if financial and economic systems isn't, but that's a different aspect altogether.

Also an important points here is that the link between financial concepts to real-world concepts and objects is well relatively easily definable. Indeed probably all real-world concepts and objects have their semantics defined in terms of financial transactions and concepts. Thus siloing of data probably can only occur in the financial world at the access control level.

The requirements for breaking the silos is easily understood as the ability to cross-reference two different data-sets and be sure (within certain bounds) that the meaning of the information contained there is is compatible. We want to perform things such as "1 + one equals 2" and be sure that the concept of "one" is the same as "1", the definition of "+" matches the concept of "+" applied to things such as "1","2" etc as well as things such as "one","two" etc. In this case the common semantics of "1" and "one" has been defined...fortunately.

It is vitally important to understand that if we can unify data sets through translations via common semantics then the siloing of data breaks and we get data liberation or what some call data democratisation. Unification of semantics however is faught with difficulties [1] but is the key prerequisite to integration and interoperability and ultimately a more expansive usage of that information.


References:

[1]Ian Oliver, Ora Lassila (2011). Integration "In The Large". Position paper accepted at the W3C Workshop on Data and Services Integration, October 20-21 2011, Bedford, MA, USA


Sunday, 4 March 2012

Progams are models

Funny how some themes tend to recur through computer science and a post on "Enso Blog" turned up this gem: Why I don’t consider Programs to be Models:

My main point here, however, is that I prefer to not think of programming languages as modeling languages. The reason is that, for me, a modeling language must be about what behavior is desired, not how to implement that behavior.

I spent a huge amount of time working on this, especially in the context of the MDA and actually trying to convince people that a description in some language such as UML was just as valid and concrete as a description in some executable programming language - though it was ironic often that something in SDL was considered a program but something in UML was considered a model.

At the time there was parallel work on something called 'executable modelling' - though interestingly that particular group never wanted to discuss what they meant by either term 'executable' or 'model'...in the end turned out because of this failing to even attempt to address these terms that particular approach (if it was even a valid approach given its lack of semantics) failed.

The posting mentioned earlier refers to another blog entry on the subject by Zef Hemel in his post Models are Programs. I tend to agree wholly with the point made there and thus indirectly with his PhD thesis: Methods and Techniques for the Design and Implementation of Domain-Specific Languages though a little surprised that mention wasn't made to some of the work in this area on specifications, especially the classic Fuchs' Specifications Are (Preferably) Executable.

However I can see the discussion on specifications versus programs lurking there but whichever way you look at things, a little abstraction reveals these things are all the same anyway.

So, after setting this up, while I don't agree with the first point and agree with the second, I do think there is an interesting taxonomic or ontological question on what makes a model different from a specification from a program - not to mention what makes something "executable" or not.

But to specifically address the point that modelling languages are about desired behaviour and not implementation is flawed in the sense that all programming languages are an abstraction - just depends on how deep you want to go.

Anyway, its late and I'll need to dig out from the recesses of my brain some of the work I made in this area but always nice to see these things haven't been resolved and still stir controversy :-)

References.
 
Johan Lilius , Ian Oliver (2007). Towards a Formal Definition of Model Driven Development (2007). Technical Report. Åbo Akademi.

Friday, 13 January 2012

Conferences

Always good to start a year off with a few conferences to be actively involved in:

And for each a short summary of their content:


Diagrams 2012:
Diagrams is the only conference series that provides a united forum for all areas that are concerned with the study of diagrams, including architecture, art, artificial intelligence, cartography, cognitive science, computer science, education, graphic design, history of science, human-computer interaction, linguistics, logic, mathematics, philosophy, psychology, and software modelling. The conference attracts a large number of researchers from virtually all these related fields, positioning Diagrams as a major international event in the area.
VL/HCC 2012:
From the beginning of the computer age, people have sought easier ways to learn, express, and understand computational ideas. Whether this meant moving from punch cards to textual languages, or command lines to graphical UIs, the quest to make computation easier to express, manipulate, and understand by a broader group of people is an ongoing challenge.
VLC 2012:
Visual languages mediate human and computer interaction. For some visual languages this mediation is straightforward; using a mouse to access a drop-down menu is well-known to computer users. For others, this mediation can be enriched via sketch and gesture recognition. This is made possible by advances in commodity hardware. More formal visual languages allow experts to accurately specify complex systems, such as software architecture or chemical molecules. A visual language can also encompass complex human-computer interaction such as navigating a set of semantically linked videos. Indeed, precision of semantics underlies visual languages and computation. 
UbiCOMM 2012:
The rapid advances in ubiquitous technologies make fruition of more than 35 years of research in distributed computing systems, and more than two decades of mobile computing. The ubiquity vision is becoming a reality. Hardware and software components evolved to deliver functionality under failure-prone environments with limited resources. The advent of web services and the progress on wearable devices, ambient components, user-generated content, mobile communications, and new business models generated new applications and services. The conference makes a bridge between issues with software and hardware challenges through mobile communications.    




    Wednesday, 8 June 2011

    Wadler's Law part 2

    The original discussion about Walder's Law can be found here. There's a nice discussion about syntax and semantics between a couple of posters - there's a little misunderstanding which sparked this, but then it generated a superb comment (highlighed below).

    [–]almafa 9 points 1 day ago
    This is of course absolute truth. On the other hand, I think syntax is important.
    [–]Peaker 3 points 1 day ago
    Semantics are more important.
    [–]almafa 4 points 1 day ago
    I didn't compare the importance of syntax to the importance of semantics, I just noted that syntax is important, too.
    [–]munificent 1 point 2 hours ago
    Personally, I believe humans are unable to separate the two.

    :-)