1. Introduction

The Spider environment [17, 19] has changed the textual paradigm of programming into a visual paradigm [5] of direct manipulation and edition of application and user interface components. Spider stimulates a component oriented approach [20] of software development where collections of objects can be reused and built in an evolutionary software life cycle. The environment?s main objective is to give support to the construction of large applications starting from prefabricated components in a given application domain.
Visual programming provides an environment where programs ? not only user

interfaces ? are built by the direct manipulation of icons. Visual composition joins the visual paradigm with a component oriented approach. We can also define visual composition as the interactive development of applications by the direct manipulation of reusable components. This approach deals directly with the complexity of large systems. The complexity is controlled in such a way that the system becomes easier to be developed, tested, and debugged, increasing flexibility and understanding. That is achieved by the use of abstractions specially tailored for a given domain, reuse and visualizations. The objective is to have the developer as a creator of components and not as the creator of large applications that are difficult to maintain and to develop. The applications are built by the composition of components created by different developers that together define the functionality they want. In visual composition the programmer?s role is minimized. The focus is on software composition and reuse. Conventional programming languages are used to develop reusable software components and not to develop specific applications. What one calls ?components? are the main computational elements of the Spider environment. Components are high level objects built through textual or visual programming. Components defined by text (primitive components) are implemented in conventional and/or script languages. Components defined by pictorial elements (composite components) are implemented by the direct manipulation of other components. The components define what we may call a ?construction block library?, from which one can choose the elements one needs from a wide variety of components.
As described above, the software development process in the Spider environment has two main roles. The first is related to the development of reusable components, this role is performed by a special developer that we will call ?fabricator?. The other is related to the construction of application by visual composition. This role is performed by the developer who we will call ?builder?. We believe that fabricators should be developers who are highly specialized, and builders may be less so. The visual paradigm works as a bridge between fabricators and builders.
We observe that current textual and visual languages are not expressive enough to represent the richness in semantic properties and development features of different application domains. In order to cope with this problem, we have been introduced the ?architecture? concept in the environment. Architecture is an implementation model for a given application domain, for which the abstractions, composition rules and editor behavior have been specially tailored.
Fabricators build architectures based on domain analysis [2,6]. Using domain analysis as a starting point; fabricators build and select appropriate components. When a builder uses an architecture, he selects the components that will help him to build the application. The component composition is restricted to the composition rules defined