Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Programming in role oriented concurrent context...

SECR 2019
November 15, 2019

Programming in role oriented concurrent contexts with ROCOCO

Cevat Balek
İstanbul Technical University
SECR 2019

Since object orientation fundamentally and even solely relies on inheritance and hierarchical relationship between classes rather than cooperation of network of objects in a bounding context, the absence of a locus in the code to capture the form of function is considered as a fundamental deficiency of object oriented programming. Lack of such a place in the code to depict the interaction of objects decreases programmer’s comprehension and responsibility about what the system as a whole does at run time. This deficiency is compensated by means of non-code artifacts such as analysis and design diagrams, test scenarios, test scripts, and the like. As concurrency gradually becomes the new norm of computation, this work merges Data Context Interaction (DCI) which is a promising technique to capture the form of function and Simple Concurrent Object Oriented Programming (SCOOP) techniques with Role Oriented Concurrent Contexts (ROCOCO) method to enhance DCI code to reflect not only sequential but also concurrent interactions of objects at run-time in source code by relaxing single-threaded constraint of DCI Execution Model.

SECR 2019

November 15, 2019
Tweet

More Decks by SECR 2019

Other Decks in Programming

Transcript

  1. PROGRAMMING IN ROLE ORIENTED CONCURRENT CONTEXTS WITH ROCOCO Cevat Balek

    Nadia Erdoğan İstanbul Technical University, Faculty of Computer and Informatics Engineering
  2. FIRST, THERE WAS VOID ➤ In engineering or art disciplines,

    still except software development, architecture has always been about ➤ to capture VOID ➤ by defining FORM ➤ to let both the stability and creativity happening ALIVE within the generated space ➤ Technical details and even measurements come later ➤ In software development, however, we ignore the very essense of form relying only on metrics such as coupling and cohesion, # of lines
  3. PATTERN LANGUAGES ➤ Christopher Alexander introduced pattern languages in 1970s.

    ➤ A PATTERN — PLACE TO WAIT ➤ In places where people end up waiting, create a situation which makes the waiting positive. ➤ Fuse the waiting with some other activity—newspaper, coffee, pool tables, horseshoes; something which draws people in who are not simply waiting. ➤ And also the opposite: make a place which can draw a person waiting into a reverie; quiet; a positive silence Gertrud & Cope
  4. STRUCTURE EVOLVES IN TIME ➤ TEST OF TIME: Thinking too

    ahead in time and hardening the structure too early based on immature decisions without considering time will destroy the ALIVENESS of the architecture ➤ Timeless thinking is completely different and the very basic idea is the awareness of radically different rates of change of different parts of a solution ➤ Only then, we start to begin understanding the effects and importance of FORM & VOID
  5. “ … several acts of building, each one done to

    repair and magnify the product of the previous acts, will slowly generate a larger and more complex whole than any single act can generate -Christopher Alexander
  6. PARADIGM SHIFT ➤ As with other Newtonian and engineering methods,

    software or even computing itself has born from male principle in charge ➤ crisp determination ➤ command and control, etc. ➤ It is not so wrong to state that even the very first idea about the possibility of computers originated in military researches in 1930s ➤ Female principle, which is ignored for centuries is gaining importance now disguised as systems thinking ➤ awareness of environment ➤ feelings > intellect, etc.
  7. LOOK AT THE KEYS IN YOUR KEYBOARD: AREN’T THEY MILITARY?

    ➤ command ➤ enter ➤ return (to base) ➤ control ➤ escape ➤ shift? (yes, even that) ➤ Can we blame the military for dominating the rest of the industry? ➤ However, this is not enough to explain what’s really going on here ➤ Root cause of the problem is the way we think, our thought process ➤ We ignored female principle everywhere: in education, at work, …
  8. SYSTEMS THINKING: SCIENCE FOR LIVING SYSTEMS ➤ We don’t scare

    to look at really complex problems any more ➤ We are aware of them and develop methods to deal with them ➤ This is just a little bit off the road on our old way of thinking
  9. CAN YOU SAY SOFTWARE IS NOT A LIVING SYSTEM? ➤

    Do you think Von-Neumann architecture will survive? ➤ Well, it is the foundation of all computing so far ➤ It won’t be completely forgotten but it may fade away ➤ WERE THERE AN ALTERNATIVE?
  10. “ In computer terms, Smalltalk is a recursion on the

    notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole -like data structures, procedures and functions which are the usual paraphernalia of programming languages- each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. -Alan Kay
  11. OO AS WE KNOW IT (NOW) ➤ Although there are

    methods (procedures) like Start, Stop and Accelerate, car is depicted from an angle of view which highlights data perspective ➤ This view is too narcissist ➤ Interaction with environment (such as road) is not designed ➤ There is no where to save the collaborative code in the source ➤ when a human sits on the driver seat (as the driver) how the car collaborates?
  12. CLASS ORIENTED IS NOT OBJECT ORIENTED (NOT EVEN CLOSE) ➤

    Systems thinker says that a system is more than the sum of its parts ➤ Is it enough to state that a car has 1 steering wheel and 4 tyres, etc. ? ➤ Defining only the structure is not enough to design a living system ➤ Interactions should also be defined in bounding contexts (recursively)
  13. DATA-CONTEXT-INTERACTION ➤ DCI decouples inheritance mechanism from specifying the behavior

    in code and restricts the use of classes to only where they are needed and effective most: DATA ➤ DCI is a natural extension to object orientation to include use cases and the like directly in the code which are thought so far only as analysis artifacts ➤
  14. DCI EXECUTION MODEL ➤ DCI aligns well with end user

    ➤ DCI frees the data objects ➤ DCI allows contextual codes where the objects collaborate ➤ All the code to orchestrate the objects in a context is in the contextual code, they do not need to be coded in the objects ➤ DCI execution model does not address multi-thread ➤ ROCOCO addresses this issue by applying SCOOP principles
  15. ROCOCO = DCI + SCOOP ROCOCO applies SCOOP to enable

    concurrency in a DCI way of role orientation ROCOCO is also a late Baroque ornamental and theatrical style to create surprise and the illusion of motion and drama
  16. ROCOCO USAGE EXAMPLE ➤ from, to and money objects are

    data objects ➤ these data objects are being used in MoneyTransfer context which knows all the actions and information about bank transfer, commissions, etc. ➤ @separate means that these objects may live in separate threads (concurrency regions) ➤ @RolePlayers maps each role to the data object which will play that role in the context
  17. ROCOCO CONTEXT ➤ In ROCOCO, a context is a class

    annotated with @Context ➤ The main responsibility of a context is to bring data objects together that will interact as role players within the context ➤ Good contexts are stateless, so a warning can be given if there is any field in the context which is not annotated with @RoleMap ➤ Context is constructed in an atomic call, once established, the role players do not change
  18. ROCOCO TRANSFORMATION ➤ DCI to OOwR (object oriented code with

    roles) transformation processes only DCI annotations and leaves SCOOP annotations intact. With this transformation, the DCI code will be reduced to OOwR code so that OOwR to ROCOCO transformation is possible through SCOOP which is designed for OO may be applied later. After this stage, transformed (expanded) OOwR source code will include all information about role oriented aspects of the computation. ➤ OOwR to ROCOCO transformation processes the SCOOP related annotations left intact by the DCI to OOwR transformation described above. ➤ ROCOCO uses eclipse JAVA Development Toolkit to perform source code to source code transformation and JSCOOP (an experimental port of SCOOP to JAVA)
  19. ROCOCO BENEFITS Allows DCI in concurrent settings: animation/collaboration is a

    readable code IDE understands the programmer Correctness proofs becomes easier Complete independence of objects from interfaces via data method adapters paves a way to let the compiler decide optimally whether to run the routine concurrently or not