The confluence of component based development, model driven development and software product lines forms an approach to application development based on the concept of software factories. This approach promises greater gains in productivity and predictability than those produced by incremental improvements to the current paradigm of object orientation, which have not kept pace with innovation in platform technology. Software factories promise to make application assembly more cost effective through systematic reuse, enabling the formation of supply chains and opening the door to mass customization. Categories and Subject Descriptors D.2.2 [Design Tools and Techniques], D.2.11 [Software

Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products. Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level. This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.

A number of approaches have been proposed to achieve separation of concerns. Although all these approaches form suitable candidates for separating cross-cutting concerns in a system, one approach can be more suitable for implementing certain types of concerns as compared to the others. This paper proposes a hybrid approach to separation of concerns. The approach is based on using the most suitable approach for implementing each cross-cutting concern in a system. The discussion is based on using three different approaches: composition filters, adaptive programming and aspect-oriented programming to implement cross-cutting concerns in SADES, a customisable and extensible object database evolution system.

Software engineers are under tremendous pressure to develop new system versions in less time. The authors show the benefits of explicitly identifying the common and variable aspects of the different versions of a system.

communication types are used as rst-class objects that represent abstractions over the interaction of objects. They encapsulate and enforce invariant behavior in object communications, can achieve the reduction of complexity of object interactions, and can achieve reusability of object interaction types. Besides being a variant of Before/After Interceptor, the abstract communicate types are Component Wrappers and implement a form of Explicit Export/Import.

Component-orientation is an emerging paradigm that promises components that are usable as prefabricated black-boxes. But components

This paper discusses the use of C for the design of digital systems. The paper distinguishes a number of different approaches towards the use of programming languages for digital system design and will discuss in more detail how C can be used for system modeling and refinement, for simulation, and for architecture design.

The ultimate goal of all computer science is the program. The performance of programs was once the noblest function of computer science, and computer science was indispensable to great programs. Today, programming and computer science exist in complacent isolation, and can only be rescued by the conscious co-operation and collaboration of all programmers. The universities were unable to produce this unity; and how indeed, should they have done so, since creativity cannot be taught? Designers, programmers and engineers must once again come to know and comprehend the composite character of a program, both as an entity and in terms of its various parts. Then their work will be filled with that true software spirit which, as “theory of computing”, it has lost. Universities must return to programming. The worlds of the formal methods and algorithm analysis, consisting only of logic and mathematics, must become once again a world in which things are built. If the young person who rejoices in creative activity now begins his career as in the older days by learning to program, then the unproductive “scientist ” will no longer be condemned to inadequate science, for their skills will be preserved for the programming in which they can achieve great things. Designers, programmers, engineers, we must all return to programming! There is no essential difference between the computer scientist and the programmer. The computer scientist is an exalted programmer. By the grace of Heaven and in rare moments of inspiration which transcend the will, computer science may unconsciously blossom from the labour of the hand, but a base in programming is essential to every computer scientist. It is there that the original source of creativity lies. Let us therefore create a new guild of programmers without the class-distinctions that raise an arrogant barrier between programmers and computer scientists! Let us desire, conceive, and create the new program of the future together. It will combine design, user-interfaces, and programming in a single form, and will one day rise towards the heavens from the hands of a million workers as the crystalline symbol of a new and coming faith. 1 1

The class concept is central in OO programming (OOP) to implement abstract data types and enforce encapsulation. Type hierarchy has been regarded as a useful technique for consistency during extension. Yet, the importance of class and type hierarchy extends beyond their technical merits. Specifically, a class classifies objects and a type hierarchy classifies classes. Classification is fundamental to design, and its place in program evolution and programming language structure can be elucidated through formal symmetry models. Symmetry is the interplay between an invariant and the possibility of change. This paper discusses the importance of classification in OOP and shows the connection between classification and symmetry in class and type hierarchies.

Object-oriented software engineering did not reach all productivity objectives expected in the beginning. A lack of methodical support results in low comprehensibility of code and documentation. Reusability was attained only in projects, in which a system family was the target. This paper examines different attempts with respect to their systematic support for development of system families. Based on Domain Analysis, there is introduced an evolutionary methodology for reaching multiple use of software engineering results. The approach starts from an existing system and offers a pragmatic and systematic way to describe common and variable parts of systems explicitly and comprehensively. Based on this descriptions, the development of systems with high adaptability and maintainability is attainable. Generative Programming is mentioned as a new software paradigm offering a way to simplify the implementation process by utilization of meta-programming.