Rococo ile role yönelimli eş zamanlı programlama
Programming in role oriented concurrent contexts with Rococo
Yazar: CEVAT SERKAN BALEK
Danışman: PROF. DR. TAKUHİ NADİA ERDOĞAN
İstanbul Teknik Üniversitesi / Fen Bilimleri Enstitüsü / Bilgisayar Mühendisliği Ana Bilim Dalı / Bilgisayar Mühendisliği Bilim Dalı
Derece: Yüksek Lisans, 2019
Konu: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol = Computer Engineering and Computer Science and Control

Özet:
Rol tabanlı programlama ve eş zamanlı programlama konularında ayrı ayrı pek çok çalışma yapılmış ve pek çok araç geliştirilmiş olmasına rağmen, nesnelerin bir bağlam içerisinde birlikte çalışılabilirliğini özellikle eş zamanlı programlama açısından da ele alan çalışmaların sayısı azdır. Nesneye yönelim, rol tabanlı programlama ve nesneye yönelimli eş zamanlılık konularında literatür araştırması yapılarak, nesneye yönelimin en temel eksikliği, temelde sadece kalıtımı ve dolayısıyla sınıflar arasındaki hiyerarşik ilişkiyi baz alması nedeniyle işlevselliğin biçemini doğru yakalayacak bir kod yapısının oluşmasına mahal vermemesi olarak tespit edilmiştir. Kodda davranışı kolayca okuyup inceleyebilecek bağlama ait bir yerin mevcut olamaması nedeniyle, bu eksikliğin analiz ve tasarım diyagramları, test senaryoları ve test betikleri gibi kod dışındaki mecralar ile bertaraf edilmek zorunda kalındığı pek çok çalışmada dile getirilmiştir. Sistemin çalıştırma anında ne yaptığına dair programcının bilişsel hakimiyeti ve sorumluluk hissiyatı günden güne azalmaktadır. Hem nesnelerin birlikte çalışabilirliğini koda aynen yansıtabilmek hem de eş zamanlı programlamaya makul bir çözüm oluşturmak üzere, Data Context Interaction (DCI), Design by Contract (DbC) ve Simple Concurrent Object Oriented Programming (SCOOP) teknikleri, rol tabanlı ve eş zamanlı nesneye programlama yapmaya olanak veren ROCOCO tümleşik geliştirme ortamı eklentisinde birleştirilmiştir.  Böyle bir eklentinin mevcut olmadığı günümüz tümleşik gelitirme ortamlarından bir adım ötede, örneğin bir kullanım senaryosu analizi ile oluşturulan UML eserlerinde kendini belli eden kullanım senaryoları, ön koşullar, garantiler, aktörler (roller) -ve dolayısıyla iletişim veya birlikte çalışma diyagramları- gibi daha önceden kodun içinde doğrudan yer bulamayan ve dolayısıyla kod ile kontrol edilemediği için programcının dolaylı olarak sorumlu hissetmediği kavramları da doğrudan kod içinde kullanarak çok daha sağlam ve okunabilir bir etkileşim kodu geliştirilebilecektir. Programcının hem davranışsal hem de eş zamanlılık anlamında ne yaptığı konusunda ek bilgilerin formal olarak tanıtılabildiği tümleşik geliştirme ortamı ise, programcıya daha reaktif uyarılarda bulunarak yapısal hataların oluşmasına mahal vermeyecek ve kodun eş zamanlı olarak beklendiği gibi çalışması için gereken kaynak kod dönüşümünü yapabilecektir. Bu çalışma ile, DCI çalıştırma modelindeki tek ipliklilik kısıtı da ilk kez kaldırılmıştır.

Abstract:
Despite the huge number of studies carried out and tools developed for role oriented programming and concurrent programming, there are only a few studies addressing the interoperability of concurrent objects in concurrent contexts. Based on a comprehensive research on object orientation and role oriented programming, the most fundamental deficiency of object orientation has been identified as the absence of a locus in code to capture the form of function because object orientation as we know it fundamentally and even solely rely on inheritance and hierarchical relationship between classes. In many studies, it is shown that this deficiency of  lacking a place in code that can easily be read to examine the behavior is eliminated by means of non-code channels such as analysis and design diagrams, test scenarios and test scripts, etc.
The programmer's cognitive mastery and sense of responsibility about what the system will do at run time decreases day by day. In this study, Data Context Interaction (DCI), Design by Contract (DbC) and Simple Concurrent Object Oriented Programming (SCOOP) techniques are combined in ROCOCO (Role Oriented Concurrent Contexts) eclipse plugin extention to reflect the interoperability of concurrent objects in the code.
One step ahead of today's integrated development environments where no such plug-in exists, a much more robust and readable interaction code can be developed by being able to code concepts that have not previously been directly located in the code and therefore could not be controlled by the code thus prevented the programmer from feeling responsible for what she really can't directly read in the code. An integrated development environment where additional information can be formally introduced about what the programmer is doing in both behavioral and concurrent terms is able to convert the source code to run concurrently as programmer depicted and will not let structural errors show up by giving more reactive warnings to the programmer. One of the greatest contribution of this thesis is the relaxation of the single-thread constraint in DCI execution model by synthesizing DCI with SCOOP and DbC ideas. ROCOCO reduces the role orientation which is done in DCI way to object orientation by transforming the code just after compilation time, and SCOOP handles concurrency for this object oriented code without losing the interactivity of IDE and programmer. 
Remembering the visions of scientists who laid the foundation for object orientation half a century ago is very important in terms of understanding where the object orientation is actually aimed at. Alan Kay, one of the visionaries of object orientation, states the necessity of designing the computer as an extension of human mind, and adds that a good information system, a good education system and even a good programming environment should more or less understand what the end user, student, and even the programmer as the current user of the system is trying to accomplish through the connection of the computer and human mind. He spoke of the importance of creating a sense of immediacy by not letting too much delay in giving information, showing the result of what was done or warning about what is about to be done wrong. Trygve Reenskaug, the inventor of the Model View Controller (MVC) method, which is as old as object orientation, manifested MVC as a link between the human mind and the computer and stated that a good user interface allows direct manipulation of objects stored in computer's memory by the end user.
Advances in techology and ever increasing compuational power opens up new frontiers for programming world too. We can now start to speak about programs generating other programs, programs generating test cases by constraining the case space and even tools to prove that the code will completley work as expected or not by exploiting the formal specifications which were provided by the programmer. The modern integrated development environments (IDE) should be able to intract more throughly with programmer by immediately recognizing the impacts of her current amendments in the source code and warn her if anything may go wrong. This dialogue like interaction between IDE and programmer is important for maintaining the focus of the programmer on the code without waiting to observe what the software will do at run time. Thesis provides ROCOCO (Role Oriented Concurrent Contexts) as a plug-in to provide an environment for the programmer to code with full support on both role oriented and concurrent programming from the IDE which understands the intent of her by exploiting annotations and warns her at complite time about the structural errors her recent amendments on code will cause without the need to test the code at run time.              
James Coplien and Trygve Reenskaug spoke about how the pendulum in object orientation has shifted since the mid-1990s, and how a mechanical software architecture that focuses more on software quality metrics, coupling and cohesion than on the pairing with human mind moved us away from the essence of object orientation. Maria Siniaalto and Pekka Abrahamsson's work on Test Driven Development (TDD) not only supports this rhetoric on the over-importance of coupling and cohesion, but also gives a good idea of how big the unreadable behavioral code can actually be in the source code. For good testing of a source code, the TDD code being written is twice or three times the size of the original source code. This has two consequences:
1. The programmer should be responsible for the behavioral code which can only be exposed now as test scripts. Unaware of this responsibility, the programmer left the work to the tester with peace of mind. Worse, no one is aware of this situation.
2. At least two or three times the code maintenance required for the original program to run correctly must be performed for the test code to ensure that the test code is working and testing correctly.
When the code does not reveal exactly to how the sofware will behave at run time, the behavior is expressed with various analysis and design artifacts such as Unified Modeling Language (UML) collaboration and UML activity diagrams. Test scripts were coded with the xUnit family (JUnit, NUnit, etc.) to make sure that the software behaves as desired. The point we want to emphasize with these examples is that the deep need for all these techniques points to a very basic problem, a fundamental deficiency in object orientation; the absence of a place in code to describe behavior.
ROCOCO exploits the fact that the communication between the context and the data objects which play some role in that context is one way in DCI way role orientation. Data objects are not aware about the contexts they may play a role within, but contexts know at construction time all it needs to know about each data object as a role player. In DCI, formation of contexts are atomic, i.e. all data objects are bound to the context as role players at the time when the context is constructed. Therefore, we can take the source code line where the context instance is constructed as the reference for ROCOCO transformation to reduce the role oriented code to object orientated code. As programmer continues to use the IDE, each context construction code is visited by Java Development Toolkit (JDT) observers of the ROCOCO plugin. The specialized context class will be suffixed with _asCalledFrom_SourceCodeFileName_Line# and role classes in that context class will be rename refactored with data object classes which will play those roles at that specific source code line by the ROCOCO plug-in.
On each such line, different types of contexts which will employ different types of role player data objects are possible. Since the communication between contexts and data objects as role players is one way in DCI, we can use each such line as an anchor and let the ROCOCO plug-in generate the necessary context classes and generate the modified client code which is constructing that specific context on that specific source code line. ROCOCO makes a necessary assumptiong as a constraint that each context has only one interaction code which is called maestro(). Since there is only one interaction code, ROCOCO can immediately generate the code to call maestro() method just after the it visits the reference source code line for context construction.
Suppose that the data objects are created by the programmer as follows: 

@separate Hesap kaynak = new Hesap(IBAN_kaynak);
@separate Hesap hedef = new Hesap(IBAN_hedef);
@separate Para para = new Para(50);
Also suppose that the context in which these data objects will be role players are:
@RolePlayers(
	mappings = { 
		"Source=kaynak",
		"Destination=hedef",
		"Banknote=para"
		},
	adapters = {
		"Destination.credit = _Destination.deposit(b);"
		}
	) 
@separate MoneyTransfer moneyTransfer = new MoneyTransfer();
A programmer who encounters the above code will recognize that role orientation is being used at this point, even if she has no knowledge of the subject. Programmer clearly understands the intent of the code by looking at the @RolePlayers annotation.  Programmer will also notice that, although the role classes are Source, Destination and Banknote, the data objects which will play these roles will be of type Hesap and Para. ROCOCO visits necessary nodes, which are in this case a variable declaration nodes, in JAVA Abstract Syntax Tree to find declared types of data objects. For example, Source role is mapped onto kaynak object which is decpared as type of Hesap. Also, the SCOOP @separate annotation specifies that the context itself can live concurrently on a different processor. 
With ROCOCO, after specifying the role oriented and concurrent intent of her code, programmer feels safe that IDE will warn her whether there is a structural problem or not in her code which may lead to a problem or crush at run-time.
Following code is an example of the only interaction code in the context, maestro().
public class ROCOCO_MoneyTransfer {
	…
	@await(condition="!s.isBusy()&&!d.isBusy()&&!b.isBusy()
	&&s.acquire()&&d.acquire()&&b.acquire()")
	public void maestro (
		@separate Hesap s,
		@separate Hesap d,
		@separate Para b {
			b.setBanknote += s.commission(b);
			s.debit(b);
			b.setBanknote -= s.commission(b);
			d.credit(b);
			s.release();d.release();b.release();
		}
	}
	…
}
Here, another SCOOP @await annotation is used to specify the await condition. 
The main contribution of the thesis is to demonstrate that it is possible to build an interactive development environment which will let the programmer specify not only the concurrent or role oriented code alone but specify both role oriented and concurrent code together, and to relax the single-threaded contstaint of DCI by this synthesis.     
We hope that this thesis work, which is based on annotations only, will find a response in industry and we will have more realiable interactive development environments.