Cours management et analyse stratégique pdf, tutoriel & guide de travaux pratiques en pdf.

The Component Perspective

The investment in developing a software component can be very high and the risk involved cannot be ignored4. Reuse of software components bears many advantages, in particular the availability of software solutions for a well-defined problem that cost only a small fraction of the price to develop them, because their price is shared among all software projects (re-)using them. A fundamental question with components is how to communicate with the rest of the world, by relying on a standard for interoperability. In fact, most of the component standards have to define how to represent the data they use to communicate and of to define their interfaces in a language independent way. Component standards like COM, CORBA, JNI and RMI define a programming model, the semantic thereof, and a language to define their interfaces. The main achievement of these standards was to open the borders across different software systems, and allow interoperability among them. However, the border remains, and crossing it is more like crossing a state border than a city border. JNI, as an example, requires the developer to convert the interface by using some tools, to access all fields using a method, and to explicitly take care of the object pinning to avoid their collection. This solution lacks the automatic propagation of the component’s interface. CORBA also suffers from the same problem: in the GNOME project, where components can be accessed through using various programming languages, the time gap between a component release and the release of the wrappers for accessing it from other languages can take up to eight months [dI02]. Microsoft’s .NET platform improves the situation by adding the interface definitions5 to the components and forcing all the language to define their interfaces using the common model. In this way, every component can be understood by all languages that understand the common model and it becomes readily available without need to create interface conversions. The availability of well-integrated simple to use solutions for creating and using software components will play an important role in enabling a real component-oriented development and market therefore.

The System and Compiler Perspective

Providing support for components and interoperability requires creating software systems to provide this support. In particular, these systems must allow be created around the component model which becomes the vehicle of all information in the system. These systems require reflection capabilities to be able to inspect but also design the components. Java institutionalized the use of reflection for inspection purposes, in .NET the reflection API supports metadata and code emission, Aos allows inspection and is intermediate-language agnostic by allowing multiple loaders (possibly including a jitter). The common platform is a huge gain for language and compiler developers, because it provides much functionality, which they would otherwise have to design themselves. This is quite obvious when comparing the Sable and the Jaos JVMs: in Sable most of the effort was spent creating a complete system, like the data-layout design, whereas Jaos main efforts where in the mapping of Java’s object model to Active Oberon’s object model and the implementation of the just-in-time compiler. In the last decades, language developers often faced the dilemma of either implementing a whole compiler and system or to provide a language to C translator (choice that most of them took, for obvious reasons). The transition from to a system providing support for language interoperability is less difficult than it seems. In practice, this requires to move some parts of the compiler, in particular the symbol table and possibly the back-end, to the system to be available for all compilers. Thus, the availability of software platform exposing a higher-level abstraction and metadata services is a tremendous simplification for language and compiler designers, which are freed from many details and become model mappers instead of bit fiddlers.