Ali Arsanjani

The component paradigm starts with the assertion of an assembly-oriented view of software engineering, building software applications by wiring together the ports and connectors of a set of pre-fabricated parts (components) within a component context. This paradigm is an evolution of the notion of the object paradigm: an object having identity, state, and behavior; a component exposing services, contracts, and manners and is, most importantly, configurable without requiring intrusive changes for using it [1]. Modularization and separation of concerns (for example, interface from implementation) are key elements of this paradigm. Parnas stated in 1972 that modules, or as they have evolved today, components, have boundaries defined by how we choose to hide, not just data or methods, but design decisions [2]. These design decisions often pertain to a component's manners: the rules governing how it behaves in a context. This externalization process adds a further dimension of separation of concerns by allowing data, behavioral specification, and even a business language to be externalized as metadata to be used to modify the contextual behavior of the component at runtime. In this special section, we explore the problems and solutions encountered in industry and academia around the world when using the component paradigm in building software systems?specifically, to support business domains.