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.

/pdf/software-factories-assembling-applications-with-patterns-xya3gxl3f7.pdf

Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools

The Palladio component model for model-driven performance prediction

http://www.koziolek.de/docs/Koziolek2010-PE-preprint.pdf

Performance evaluation of component-based software systems: A survey

Component-based development (CBD) is an important emerging topic in software engineering, promising long-sought-after benefits like increased reuse, reduced time to market, and, hence, reduced software production cost. The cornerstone of a CBD technology is its underlying software component model, which defines components and their composition mechanisms. Current models use objects or architectural units as components. These are not ideal for component reuse or systematic composition. In this paper, we survey and analyze current component models and classify them into a taxonomy based on commonly accepted desiderata for CBD. For each category in the taxonomy, we describe its key characteristics and evaluate them with respect to these desiderata.

Software Component Models

The emerging field of semantic web technologies promises new stimulus for Software Engineering research. However, since the underlying concepts of the semantic web have a long tradition in the knowledge engineering field, it is sometimes hard for software engineers to overlook the variety of ontology-enabled approaches to Software Engineering. In this paper we therefore present some examples of ontology applications throughout the Software Engineering lifecycle. We discuss the advantages of ontologies in each case and provide a framework for classifying the usage of ontologies in Software Engineering.

/pdf/applications-of-ontologies-in-software-engineering-4aadeeg4oe.pdf

Applications of Ontologies in Software Engineering

Foreword. 1. Component Systems. Component Goals. Component Principles. Component Forms. Example: Microsoft Word. What a Component Isn't. Component and System Architectures. System Architectures. Component Architectures. Specifying Contracts. Usage Contracts. Realization Contracts. Interfaces versus Component Specifications. Model Levels. Summary. 2. The Development Process. Workflows. The Impact of the Management Process. The Evolution of Software Processes. Accommodating Change. Workflow Artifacts. The Specification Workflow. Component Identification. Component Interaction. Component Specification. Summary. 3. Applying UML. Why Do We Need This Chapter at All? Tools. Extending UML with Stereotypes. Precision, Accuracy, and Completeness. UML Modeling Techniques. Business Concept Model. Use Case Model. Use Case Diagrams. Use Case Descriptions. Use Case Instances. Inclusions, Extensions, and Variations. Business Type Model. Types. Structured Data Types. Interface Type. Invariants. Interface Specification. Interface Specification Package. Information Model. Operation Specification. Component Specification. Component Object Interaction. Specification, Not Implementation. Component Architectures. Summary. 4. Requirements Definition. Business Processes. Business Concept Model. System Envisioning. Use Cases. Actors and Roles. Use Case Identification. Use Case Descriptions. Quality of Service. Summary. 5. Component Identification. Identifying Interfaces. Identifying System Interfaces and Operations. Make a Reservation. Take Up Reservation. Identifying Business Interfaces. Create the Business Type Model. Refine the Business Type Model. Define Business Rules. Identify Core Types. Create Business Interfaces and Assign Responsibilities. Allocating Responsibility for Associations. Creating Initial Interface Specifications. Existing Interfaces and Systems. Component Specification Architecture. System Component Specifications. Business Component Specifications. An Initial Architecture. Summary. 6. Component Interaction. Discovering Business Operations. Some Simple Interactions. Breaking Dependencies. Maintaining Referential Integrity. Component Object Architecture. Controlling Intercomponent References. Completing the Picture. Refining the Interfaces. Factoring Interfaces and Operations. Summary. 7. Component Specification. Specifying Interfaces. Operation Specification. Interface Information Models. Pre- and Postconditions. A Systematic Process. From Business Type Model to Interface Information Model. Invariants. Snapshots. Exactly What Does a Postcondition Guarantee? Specifying System Interfaces. Business Rule Location. Specifying Components. Offered and Used Interfaces. Component Interaction Constraints. Inter-Interface Constraints. Factoring Interfaces. Summary. 8. Provisioning and Assembly. What Do We Mean by Target Technology? Components Realize Component Specifications. Realization Mappings and Restrictions. Operation Parameters. Error and Exception Handling Mechanisms. Interface Inheritance and Interface Support. Operation Sequence. Interface Properties. Object Creation. Raising Events. Application Architecture Correspondence. Business Components. Subcomponents. Integrating Existing Systems. Purchasing Components. Assembly. Summary. A Final Thought. References. Index. 0201708515T04062001

John Cheesman

Papers

Uml Components: A Simple Process for Specifying Component-Based Software