| The reuse of software components has long been promised as a main benefit of software engineering, allowing software systems to be quickly composed from independent entities of functionality. However, assumptions about how a component can be correctly used are encoded within its implementation. This makes reuse difficult, as these constraints are often not communicated to clients. Even if they are available to clients, they are usually provided in a non-formal form such as documentation, or must be inferred from the component's source code.; Common approaches to this problem look to formalize these implicit assumptions. However, previous methods often focus on higher level component properties and system wide connections, ignoring the fundamental interactions a single component supports. In addition, most of these approaches rely on static type checking to verify correct component reuse. This requires the specification of not only the component's correct usage, but the behavior of its clients as well. Also, static verification limits the number of properties that can be constrained due to the limited information available at compile time.; The lips specification language provides a clear, simple, yet powerful way to communicate a component's local usage constraints on its instantiation by, and interaction with, clients. The lips toolset provides automatic generation of a lips Container that enforces a given set of usage constraints at runtime. This enforcement simplifies component development and ensures correct runtime behavior.; In this dissertation we show that usage constraints are fundamental in understanding how a component can be used, and that their formal specification provides the information necessary to avoid certain types of component usage problems. A new concept of a component client is also presented that allows the automatic enforcement of usage constraints to each interaction of a component. We show how the dynamic enforcement of these usage constraints is a practical and useful method that simplifies component and client development, as well as ensuring correct component usage. Finally, we illustrate how the lips component concept is the beginning of a unified component concept that combines and extends the different component concepts supported by commercial component models. |
