Compare vision and goals

• portability concerns: Developments need to be reused at least as part of product lines, and beyond. For that, an adequate granularity for decomposition is needed. The market of RTOSes and middlewares for embedded systems is still very heterogeneous, each comes with its specific features. Most middleware used in such systems are in house middleware. In order to cope with this myriad (plethora) of technologies,  traditional  approaches have focused on the provision of  common layers to abstract the underlying capabilities. But these approaches suffer from different problems: maintaining RTOS/middleware abstraction layers is overly costly, and sometimes finding some common semantics of considered APIs is tricky and the outcome often is loss of semantics.
  
  
• reusability concerns: Developments need to be reused at least as part of product lines, and beyond. Most reusability problems come from the fact that implicit dependencies are present in building-blocks (e.g classes). These dependencies can be of different types: to other implementations, to specific files (programming language level). Thus, a clean declaration of dependencies of building blocks is needed.
  
  (put that in footnote): Additionally, the notion of reuse can be linked to the previous item listed: "portability", since "portability" means "reusability in a different RTOS / middleware environment", as well as "hardware" environment: portability is an enabler for reusability across different platforms.
  
  
• integration concerns: gathering and making the developments of different parties collaborate gracefully traditionally represents most of the efforts to deliver a product.
  
  - expertise under-exploitation concerns: with traditional approaches, experts can not only focus on their added value, but also must master the technologies.
  
  
• time to market:
  
  
• cost in production:
  
  
• need for improvement of productivity:
  
  
  How are/can these issues be addressed by component based approches ?
  
  - portability: We want to emphasize that the approach taken by Compare is not to deal
  with portability  via provision of common APIs wrapping different possible RTOS or
  middleware targets, and is fundamentally different. We take full advantage of 
  component-orientation to move to descriptions and accompanying mappings to
  target platforms, which allows to make a big step forward in terms of portability.
  
    On a more technical side, we have to provide suitable mechanisms to replace the programming of timers, mutexes and so on, by a declarative specification of the behavior.  The result is
  is that we end up with "golden-source" stripped from non-functional aspects, and these
  aspects are supported fully separately via the component-container pattern.
  
  - reusability: component based approaches are enforcing the (formal) definition of dependencies via description languages: in the case of CCM, the IDL3 language is used to define functional dependencies, and component descriptors (XML based) to define technical dependencies.
  The dependencies are twofold:
    -description of component binaries in terms of target processor architecture, needed libraries, ...
    - description of component assemblies together with technical features needed to be applied.
  
   Another key feature of component orientation enhancing reusability results from the production of "component packages". They encapsulate  component binaries as well as their descriptors.
  
  Footnote:  Reusability profits from the definition of domain standard interfaces.
  (in a team, company, or industry-wide). The use of components can promote
  adoption of such standards.
  
  A suitable granularity has to be found for reuse. This is sometimes domain related. Component
  technologies are appropriate for wrapping functions to be reused as part of product-lines, at the
  granularity envisioned by the system designer.
  
  - integration: a component based approach comes with a set of engineering rules for components (example: programming rules, among others), which can be applied in a transverse manner in teams collaborating for the elaboration of a product. Having these rules followed imply composability, which means: integration.
  
  
  What and how we do.
  
  The goal of the Compare project is to primarily focus on the "Separation of concerns", as it will be a quite important enabler for portability and reusability. Going into separation of concerns leads to making the transition from "programming" to "describing", and most of this involves the introduction of formalisms to provide these descriptions.
  
  
  - encapsulation and gatewaying of legacy: reusing previous developments or systems which did conform to ad-hoc or different technology spaces is very difficult.