scispace - formally typeset

Proceedings ArticleDOI

A component based approach to scientific workflow management

29 Jan 2002-Vol. 583, Iss: 1, pp 155-160

TL;DR: The issues of adopting a component product line based approach and the experiences of software reuse are discussed.

AbstractCRISTAL is a distributed scientific workflow system used in the manufacturing and production phases of HEP experiment construction at CERN. The CRISTAL project has studied the use of a description driven approach, using meta-modelling techniques, to manage the evolving needs of a large physics community. Interest from such diverse communities as bio-informatics and manufacturing has motivated the CRISTAL team to re-engineer the system to customize functionality according to end user requirements but maximize software reuse in the process. The next generation CRISTAL vision is to build a generic component architecture from which a complete software product line can be generated according to the particular needs of the target enterprise. This paper discusses the issues of adopting a component product line based approach and our experiences of software reuse.

Topics: Software product line (62%), Workflow engine (61%), Scientific workflow system (59%), Software architecture (56%), Workflow (55%)

Summary (3 min read)

1. Introduction

  • As component technology gradually evolves and matures so system developers will gradually migrate from systems composed of interoperable objects to those composed of interoperable components.
  • Component-based software development is concerned with constructing software artifacts by assembling prefabricated configurable building blocks.
  • The creation and evolution of graphical models to visualize specific aspects of software artifacts is another view.
  • What is required is some software development process that couples these high-level development approaches with implementation approaches.
  • The issues and the team’s experience of software reuse are discussed.

2. Motivation

  • CRISTAL is a scientific workflow system[1] that is being used to control the production and assembly process of the CMS Electromagnetic Calorimeter (ECAL) detector at CERN Geneva.
  • Detector production is a collaborative effort with production centres distributed across many institutes worldwide.
  • The production process is unusual in that only one final product is manufactured; however the types of parts from which it is assembled could consist of many versions.
  • Workflow management can be applied to diverse applications from banking to manufacturing.
  • CRISTAL has taken an object-oriented approach describing all parts, manufacturing & production tasks, manufacturing & production data using meta-modeling techniques.

3. Software Product Lines

  • The product family problem is well known.
  • A software product line [2,3] is a set of software systems that share a common set of features that satisfy a specific market demand.
  • The key idea is to build shared assets that can be instantiated and combined to develop instances of the product line.
  • The application domain is reasonably clear in their particular example but the issues that surround a common architecture and components are less so.
  • The following explore these issues in further depth based on their software engineering experiences.

3.1 Software Architecture

  • A product line software architecture[4] is the central artifact in product line engineering because it provides the framework for developing and integrating shared assets and must be common to all the products.
  • It is these specific requirement variations that define the particular product line.
  • The problem is how to best manage and include mechanisms for this variation. [5].
  • And in object orientation the use of inheritance, delegation and meta-models.
  • In their experience in building workflow systems one of the benefits of meta-modeling is that with careful analysis and use of descriptive classes a core generic software architecture can be developed to support almost any type of workflow system.

3.2 Reusable Components

  • Product line engineering practice advocates the generation and application of generic software assets that are reusable across a family of target products.
  • It suggests analyzing common and variable product characteristics to define scope of reuse, identify reusable components with a suitable level of generality.
  • The expected benefits are production of quality cost-effective software, rapid application development and improved maintenance.
  • It emphasizes strategic planned reuse rather than opportunistic reuse.
  • The following section discusses the implementation issues of software reuse and its application to components and component based development and the final part of the paper attempts to link the two together.

4. Software Reuse

  • Early efforts focused on small-grained reuse of software code.
  • The authors experience over the past 10 years of building object-oriented systems has convinced us that most reuse has come from higher-level design artifacts.
  • One explanation appears to be that the cost of creation and use of these smallgrained assets often outweighed the modest gains.
  • Usually the great thing about standards is that there are lots to choose from.
  • UML is the universal OAD modeling standard used by OMG member organizations and Microsoft.

4.1 Patterns

  • Patterns focus on reuse of abstract designs and software architecture, which is usually, described using graphical modeling notation.
  • The patterns that the authors have reused in the construction of their workflow management system[9] have evolved out of years of proven design experience.
  • Although made up of graphical diagrams the documentation provides a vocabulary and concept understanding amongst the team.
  • In the object oriented community well known patterns are named, described and cataloged for reuse by the community as a whole.
  • UML diagrams are able to describe pattern structure but provides no support for describing pattern behavior or any notation for the pattern template.

4.2 Frameworks

  • A framework is the term given to a more powerful and large grained object oriented reuse technique.
  • When specialized for a particular application then it is called an application framework and Fayad[11] identifies three categories: System Infrastructure where frameworks are applied to operating systems, network communications and GUI’s. Middleware applied to ORBs and transactions Enterprise Frameworks which address domains such as telecommunications, business, manufacturing.
  • Framework requirements are defined by software vendors or standards organizations for example IBM’s San Francisco Project, FASTech’ FACTORYworks, and Motorola’s CIM Baseline. Fingar[12] maintains that most frameworks should capture workflows since they provide the necessary modeling capabilities for constructing any business process.
  • Blackbox frameworks are structured and extended using object composition and delegation.
  • 5 Component frameworks are specialized frameworks that are designed to support components.

4.3 Components

  • It both provides and requires services based on specified interfaces [13].
  • Unlike classes, components contain implementation elements such as source, binary executable or scripts.
  • They package implementation and because of interface based design can be replaced.

5. Modeling Components

  • In the top part of the figure the long hand notation for a component is shown complete with attributes and operations.
  • The two interfaces of the component are shown as so-called “lollipops”.
  • Both proxies and the component itself are held in a component container.
  • Several of the classifiers in the EJB and COM + versions of the pattern are UML stereotypes, that is user-customized extensions to the language and not part of standard UML.
  • A very important issue is the need for support to allow developers to model components earlier in the software life cycle.

6. Conclusions

  • Reusable large grain software artifacts identified at the analysis and design phase must be evolved in a consistent manner to their realizable implementation counterparts at runtime.
  • Currently there is a semantic gap between object and component-based modeling.
  • Although the universal modeling language UML 1.3 does provide notation for components a number of major issues have been identified which restrict support for the major component technologies.
  • OO Frameworks promise a new vehicle for reuse but the concepts are still being evolved.
  • So in conclusion complete life cycle component-based product engineering is not a reality, but there are signs that progress is being made.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

1
Available on CMS information server
CMS NOTE 2001/024
The Compact Muon Solenoid Experiment
Mailing address: CMS CERN, CH-1211 GENEVA 23, Switzerland
CMS Note
April 30, 2001
A Component Based Approach to Scientific Workflow
Management
J.-M. Le Goff, Z. Kovacs
CERN, Geneva, Switzerland
N. Baker, P. Brooks, R. McClatchey
Centre for Complex Cooperative Systems, Univ. West of England, Frenchay, Bristol BS16 1QY UK
Abstract
CRISTAL is a distributed scientific workflow system used in the manufacturing and production phases of HEP
experiment construction at CERN. The CRISTAL project has studied the use of a description driven approach,
using meta-modelling techniques, to manage the evolving needs of a large physics community. Interest from
such diverse communities as bio-informatics and manufacturing has motivated the CRISTAL team to re-engineer
the system to customize functionality according to end user requirements but maximize software reuse in the
process. The next generation CRISTAL vision is to build a generic component architecture from which a
complete software product line can be generated according to the particular needs of the target enterprise. This
paper discusses the issues of adopting a component product line based approach and our experiences of software
reuse.
Keywords: Components, Workflow Management, Multi-Layer Architectures, Meta-Objects

2
1. Introduction
As component technology gradually evolves and matures so system developers will gradually migrate from
systems composed of interoperable objects to those composed of interoperable components. One of the main
motivations for this migration is the potential of software reuse and its associated benefits of cost reduction and
time to market of software products. Component-based software development is concerned with constructing
software artifacts by assembling prefabricated configurable building blocks. However software reuse is
concerned with more than binary components. For many organizations it is the generation and application of
generic software assets that are reusable across a family of target products. Binary components are just one view
of the software development process. The creation and evolution of graphical models to visualize specific aspects
of software artifacts is another view. What is required is some software development process that couples these
high-level development approaches with implementation approaches. This paper opens with a brief discussion of
the context and motivations for this research followed by an outline of software product lines. The issues and the
team’s experience of software reuse are discussed. The final part of the paper concentrates on the divide between
object based modeling and component based development, which is preventing software reuse from reaching its
full potential.
2. Motivation
CRISTAL is a scientific workflow system[1] that is being used to control the production and assembly process of
the CMS Electromagnetic Calorimeter (ECAL) detector at CERN Geneva. Detector production is a collaborative
effort with production centres distributed across many institutes worldwide. The production process is unusual in
that only one final product is manufactured; however the types of parts from which it is assembled could consist
of many versions. The evolution of the detector will take many years and during this process the history of
versioned parts must be captured. The ultimate detector will be part of a high energy physics experiment
therefore collection and storage of manufacturing & production data is just as important as control of the process.
This stored data not only gives the “as built” view of the final system but has been designed as a warehouse to
provide “calibration views”, “maintenance views” and other views not yet conceived by the designers. It is these
specialized aspects which characterize CRISTAL as a scientific workflow system. A general workflow system is
used to coordinate and manage execution of the thousands of tasks and activities that occur in any complex
enterprise. Workflow management can be applied to diverse applications from banking to manufacturing. In each
case the system must be capable of describing and storing the tasks and activities of the domain to be automated,
executing and co-ordinating the tasks and storing the outcomes. CRISTAL has taken an object-oriented approach
describing all parts, manufacturing & production tasks, manufacturing & production data using meta-modeling
techniques. As a consequence of the uncertainty and specialized nature of the application the core meta-model of
the CRISTAL workflow system has the potential to be applied to almost any workflow or enterprise resource
management application. The motivation to achieve this potential has stemmed from requests to apply the core
CRISTAL technology to bio-informatics and general manufacturing domains. However a number of problems
remain to be solved in order to develop our workflow software to cope with the demands of such a diverse
product family range.
3. Software Product Lines
The product family problem is well known. A software product line [2,3] is a set of software systems that share a
common set of features that satisfy a specific market demand. The key idea is to build shared assets that can be
instantiated and combined to develop instances of the product line. Similar to a manufactured product line
software products will:-
Pertain to an application domain and market
Share an architecture and
Be built from reusable components
The application domain is reasonably clear in our particular example but the issues that surround a common
architecture and components are less so. The following explore these issues in further depth based on our
software engineering experiences.

3
3.1 Software Architecture
A product line software architecture[4] is the central artifact in product line engineering because it provides the
framework for developing and integrating shared assets and must be common to all the products. Naturally the
common user requirements map to the standard architecture but product specific requirements must map to
variations provided for by the architecture. It is these specific requirement variations that define the particular
product line. The problem is how to best manage and include mechanisms for this variation. [5] Discusses
methods to model and capture this variation. Standard computing mechanisms to cope with variation are:-
Alternate selection using “if then else” flow control
Alternate selection using parameters
And in object orientation the use of inheritance, delegation and meta-models.
In our experience in building workflow systems one of the benefits of meta-modeling is that with careful analysis
and use of descriptive classes a core generic software architecture can be developed to support almost any type of
workflow system. A discussion of the concepts and benefits of meta-modeling is not in the scope of this paper but
more details can be found in [6].
Applying the meta-modeling approach to a product line of workflow managers (that is workflow managers for
production of aircraft, cars, kitchens etc.) would necessitate describing the activities and items to configure the
architecture to the particular work flow manager in the product line. Compared with a more software component
based approach where the actual product line goes through a software build process where variational
components are linked in or omitted according to the features of the target product. The former approach makes
for a configurable adaptive architecture but the second is required to support a product line.
3.2 Reusable Components
Product line engineering practice advocates the generation and application of generic software assets that are
reusable across a family of target products. It suggests analyzing common and variable product characteristics to
define scope of reuse, identify reusable components with a suitable level of generality. The expected benefits are
production of quality cost-effective software, rapid application development and improved maintenance. It
emphasizes strategic planned reuse rather than opportunistic reuse. That is it is not just about libraries, class
hierarchies or configurable architectures. This is reuse at a very high level disconnected from implementation
issues. The following section discusses the implementation issues of software reuse and its application to
components and component based development and the final part of the paper attempts to link the two together.
4. Software Reuse
Software reuse is not a new concept as Figure 1 illustrates. Early efforts focused on small-grained reuse of
software code. Our experience over the past 10 years of building object-oriented systems has convinced us that
most reuse has come from higher-level design artifacts.
Figure 1: A History of Software Reuse.
1960’s
Subroutines
1970’s
Modules
1980’s
Objects
1990’s
Components
2000
Frameworks

4
Very little code has been reused, except class library reuse mainly confined to client-side user interfaces. So why
so little reuse at the code level? One explanation appears to be that the cost of creation and use of these small-
grained assets often outweighed the modest gains. But another important factor is that the underlying software
technology is moving so fast, especially true in software projects with long time scales. For example object
technology has witnessed, in a short space of time Smalltalk, ADA, C++, Java, EJB, COM+, Active X and OMG
CORBA.
Where we have experienced more success in reuse of software artifacts is with visual modeling languages such as
Object Modeling Technique (OMT) and the Unified Modeling Language (UML)[7]. The creation and evolution
of graphical models using UML has allowed us to specify, visualize, construct and document the artifacts of the
software systems we have built. Building UML models has provided a structure for problem solving and allowed
us to contemplate large-scale system problems. Derived from OMT, UML version 1.1 was adopted as an Object
Management Group (OMG) standard in November 1997 with a recent minor version, UML 1.3, adopted in
November 1999. Usually the great thing about standards is that there are lots to choose from. However in contrast
to the rapidly changing implementation software technology, UML is the universal OAD modeling standard used
by OMG member organizations and Microsoft. Perhaps because of this stability we have over the years been able
to reuse large-grained architectural frameworks and patterns which have been captured in UML. The term’s
pattern, framework, component are somewhat overloaded and the following subsections provide working
definitions and discuss reuse issue experiences.
4.1 Patterns
A Pattern[8] is a solution schema expressed in terms of objects & classes for recurring design problems within a
particular context. Patterns focus on reuse of abstract designs and software architecture, which is usually,
described using graphical modeling notation. So in UML this is specification is done using interaction, class and
object diagrams. The patterns that we have reused in the construction of our workflow management system[9]
have evolved out of years of proven design experience. Although made up of graphical diagrams the
documentation provides a vocabulary and concept understanding amongst the team. Documentation describes
heuristics for use and applicability although this is not modeled in UML. In the object oriented community well
known patterns are named, described and cataloged for reuse by the community as a whole. We have not only
used many well-known patterns but in the domain of workflow management discovered new patterns. It has
enabled us to make use of design patterns that were proven on previous projects and is a good example of reuse at
the larger grain level. UML diagrams are able to describe pattern structure but provides no support for describing
pattern behavior or any notation for the pattern template. UML 1.4, which is in draft stage, will enhance the
notation for patterns.
4.2 Frameworks
A framework is the term given to a more powerful and large grained object oriented reuse technique. It is a
reusable semi-complete application that can be specialized to produce custom applications [10]. It specifies a
reusable architecture for all or part of a system and may include reusable classes, patterns or templates.
Frameworks focus on reuse of concrete design algorithms and implementations in a particular programming
language. Frameworks can be viewed as the reification of families of design patterns. When specialized for a
particular application then it is called an application framework and Fayad[11] identifies three categories:
System Infrastructure where frameworks are applied to operating systems, network communications and
GUI’s.
Middleware applied to ORBs and transactions
Enterprise Frameworks which address domains such as telecommunications, business, manufacturing.
Framework requirements are defined by software vendors or standards organizations for example IBM’s San
Francisco Project, FASTech’ FACTORYworks, and Motorola’s CIM Baseline. Fingar[12] maintains that most
frameworks should capture workflows since they provide the necessary modeling capabilities for constructing
any business process. He states that workflow management is one of the elements common to all e-commerce
applications and is essential. Many proponents of frameworks go so far as to suggest that workflow mechanisms
should eliminate the need for most application programming in the workplace.
Frameworks can also be classified according to the techniques used to extend them. Whitebox frameworks rely
on OO language features such as inheritance and dynamic binding. Blackbox frameworks are structured and
extended using object composition and delegation.

5
Component frameworks are specialized frameworks that are designed to support components. D’Souza[13]
describes a component based framework as a collaboration in which all the components are specified with type
models; some of them may come with their own implementations. To use the framework you plug in components
that fulfill the specifications. Three main industrial examples of component frameworks are OMG’s Corba
Component Model (CCM) Enterprise Java Beans (EJB) and Microsoft’s COM+.
4.3 Components
Are defined as a package of software that can be independently replaced. It both provides and requires services
based on specified interfaces [13]. It conforms to architectural standards so that it can plug in and interoperate
with other components. The granularity of components can vary from an instance of single to many classes and
can be a significant part of a system, consistent with the goal of reuse. Unlike classes, components contain
implementation elements such as source, binary executable or scripts. Components are binary-replaceable things
and this distinction more than anything else sets them apart from classes. They package implementation and
because of interface based design can be replaced. This means that when a new variant of a component is created
it can replace a previous without recompiling other components, provided it conforms to the same interface.
Software developers can build applications by assembling components rather than designing and coding.
In order to gain the payoff in software reuse as advocated by product line engineering there some difficulties to
be resolved. Compared with classes and patterns which are modeled at analysis and design phase components are
modeled at implementation phase. This in our experience is a particular problem where we have so much
invested in graphical models. The essence of the problem is how does a collection of classes modeled at the UML
OAD level, become implementation components. This raises the follow-up question; is UML capable of
component modeling? Although components have become the de facto standard for desktop development this is
not the case for server development. In summary leading component architectures have matured and evolved to
support enterprise application. What is not clear is whether graphical modeling languages and tools can support
the leading component architectures to deliver the goals of product-line engineering. The following section
discusses these issues.
Figure 2: UML Component Notation
5. Modeling Components
A component in UML is a software artifact that exists at runtime. The notation for modeling components in UML
is shown in Figure 2. In the top part of the figure the long hand notation for a component is shown complete with
attributes and operations. This particular component is realized by two interfaces, interface One and interface
Two. Underneath is shown the shortened notation where almost all of the detail is hidden. The two interfaces of
the component are shown as so-called “lollipops”. UML components are typical found in implementation related
component diagrams and deployment diagrams.
The ability to model component frameworks is just as essential as being able to model components. Although
component frameworks vary they do conform to a common architectural pattern. Figure 3 adapted from
Kobryn[14] illustrates this common pattern using UML notation. The pattern is represented by the UML 1.4
ellipse with dashed perimeter and contains a number of classifiers. The client represents an entity that requests a
<<Interface>>
One
Component Name
Attributes
Operations
+ op1( )
<<Interface>>
Two

References
More filters

Book
Frank Buschmann1
01 Jan 1996
TL;DR: Patterns.
Abstract: Patterns. Architectural Patterns. Design Patterns. Idioms. Pattern Systems. Patterns and Software Architecture. The Pattern Community. Where Will Patterns Go? Notations. Glossary. References. Index of Patterns.

2,637 citations


Book
01 Oct 1998
TL;DR: This chapter discusses Model Frameworks as Templates, a model framework for component-based development, and its applications in architecture, management, and user experience.
Abstract: Preface. I. OVERVIEW. 1. A Tour of Catalysis. Objects and Actions. Refinement: Objects and Actions at Different Scales. Development Layers. Business Modeling. Model Frameworks as Templates. Zooming In on the Software: System Context. Requirements Specification Models. Components. Assigning Responsibilities. Object-Oriented Design. The Development Process. Three Constructs Plus Frameworks. Three Levels of Modeling. Three Principles. Summary. II. MODELING WITH OBJECTS. 2. Static Models: Object Attributes and Invariants. What Is a Static Model? Object State: Objects and Attributes. Implementations of Object State. Modeling Object State: Types, Attributes, and Associations. Static Invariants. The Dictionary. Models of Business Models of Components. Static Models: Summary. 3. Behavior Models: Object Types and Operations. Object Behavior: Objects and Actions. More Precise Action Specifications. Two Java Implementations of a Calendar. Type Specification of Calendar. Actions with Invariants. Interpreting an Action Specification. Subtypes and Type Extension. Factoring Action Specifications. State Charts. Outputs of Actions. Subjective Model: The Meaning of Containment. Type Specifications: Summary. Programming Language: Classes and Types. 4. Interaction Models: Use Cases, Actions, and Collaborations. Designing Object Collaborations. Actions (Use Cases) Abstract Complex Interactions. Use Cases Are Joint Actions. Actions and Effects. Concurrent Actions. Collaborations. Uses of Collaborations. Collaboration Specification. Collaborations: Summary. 5. Effective Documentation. What's It All For? Documentation Is Easy and Fun, and It Speeds Design. Reaching the Documentation Audience. The Main Documents: Specification and Implementation. Documenting Business Models. Documenting Component Specifications. Documenting Component Implementations. Summary. III. FACTORING MODELS AND DESIGNS. 6. Abstraction, Refinement, and Testing. Zooming In and Out: Why Abstract and Refine? Documenting Refinement and Conformance. Spreadsheet: A Refinement Example. Spreadsheet: Model Refinement. Spreadsheet: Action Refinement. Spreadsheet: Object Refinement. Spreadsheet: Operation Refinement. Refinement of State Charts. Summary. Process Patterns for Refinement. Pattern 6.1 The OO Golden Rule (Seamlessness or Continuity). Pattern 6.2 The Golden Rule versus Other Optimizations. Pattern 6.3 Orthogonal Abstractions and Refinement. Pattern 6.4 Refinement Is a Relation, Not a Sequence. Pattern 6.5 Recursive Refinement. 7. Using Packages. What Is a Package? Package Imports. How to Use Packages and Imports. Decoupling with Packages. Nested Packages. Encapsulation with Packages. Multiple Imports and Name Conflicts. Publication, Version Control, and Builds. Programming Language Packages. Summary. 8. Composing Models and Specifications. Sticking Pieces Together. Joining and Subtyping. Combining Packages and Their Definitions. Action Exceptions and Composing Specs. Summary. 9. Model Frameworks and Template Packages. Model Framework Overview. Model Frameworks of Types and Attributes. Collaboration Frameworks. Refining Frameworks. Composing Frameworks. Templates as Packages of Properties. Templates for Equality and Copying. Package Semantics. Down to Basics with Templates. Summary of Model Framework Concepts. IV. IMPLEMENTATION BY ASSEMBLY. 10. Components and Connectors. Overview of Component-Based Development. The Evolution of Components. Building Components with Java. Components with COM+. Components with CORBA. Component Kit: Pluggable Components Library. Component Architecture. Defining Cat One-A Component Architecture. Specifying Cat One Components. Connecting Cat One Components. Heterogeneous Components. Pattern 10.1 Extracting Generic Code Components. Pattern 10.2 Componentware Management. Pattern 10.3 Build Models from Frameworks. Pattern 10.4 Plug Conformance. Pattern 10.5 Using Legacy or Third-Party Components. Summary. 11. Reuse and Pluggable Design Frameworks in Code. Reuse and the Development Process. Generic Components and Plug-Points. The Framework Approach to Code Reuse. Frameworks: Specs to Code. Basic Plug Technology. Summary. Pattern 11.1 Role Delegation. Pattern 11.2 Pluggable Roles. 12. Architecture. What Is Architecture? Why Architect? Architecture Evaluation with Scenarios. Architecture Builds on Defined Elements. Architecture Uses Consistent Patterns. Application versus Technical Architecture. Typical Four-Tier Business Architecture. User Interfaces. Objects and Databases. Summary. V. HOW TO APPLY CATALYSIS. 13. Process Overview. Model, Design, Implement, and Test-Recursively. General Notes on the Process. Typical Project Evolution. Typical Package Structure. Main Process Patterns. Pattern 13.1 Object Development from Scratch. Pattern 13.2 Reengineering. Pattern 13.3 Short-Cycle Development. Pattern 13.4 Parallel Work. 14. How to Build a Business Model. Business Modeling Process Patterns. Pattern 14.1 Business Process Improvement. Pattern 14.2 Make a Business Model. Pattern 14.3 Represent Business Vocabulary and Rules. Pattern 14.4 Involve Business Experts. Pattern 14.5 Creating a Common Business Model. Pattern 14.6 Choose a Level of Abstraction. Modeling Patterns. Pattern 14.7 The Type Model Is a Glossary. Pattern 14.8 Separation of Concepts: Normalization. Pattern 14.9 Items and Descriptors. Pattern 14.10 Generalize and Specialize. Pattern 14.11 Recursive Composite. Pattern 14.12 Invariants from Association Loops. Video Case Study: Abstract Business Model. Video Business: Use Case Refinement. Pattern 14.13 Action Reification. 15. How to Specify a Component. Patterns for Specifying Components. Pattern 15.1 Specify Components. Pattern 15.2 Bridge Requirements and Specifications. Pattern 15.3 Use-Case-Led System Specification. Pattern 15.4 Recursive Decomposition: Divide and Conquer. Pattern 15.5 Make a Context Model with Use Cases. Pattern 15.6 Storyboards. Pattern 15.7 Construct a System Behavior Spec. Pattern 15.8 Specifying a System Action. Pattern 15.9 Using State Charts in System Type Models. Pattern 15.10 Specify Component Views. Pattern 15.11 Compose Component Views. Pattern 15.12 Avoid Miracles, Refine the Spec. Pattern 15.13 Interpreting Models for Clients. Video Case Study: System Specifications. System Context Diagram. System Specification. Using Model Frameworks. 16. How to Implement a Component. Designing to Meet a Specification. Pattern 16.1 Decoupling. Pattern 16.2 High-Level Component Design. Pattern 16.3 Reifying Major Concurrent Use Cases. Pattern 16.4 Separating Facades. Pattern 16.5 Platform Independence. Pattern 16.6 Separate Middleware from Business Components. Pattern 16.7 Implement Technical Architecture. Pattern 16.8 Basic Design. Pattern 16.9 Generalize after Basic Design. Pattern 16.10 Collaborations and Responsibilities. Pattern 16.11 Link and Attribute Ownership. Pattern 16.12 Object Locality and Link Implementation. Pattern 16.13 Optimization. Detailed Design Patterns. Pattern 16.14 Two-Way Link. Pattern 16.15 Role Decoupling. Pattern 16.16 Factories. Pattern 16.17 Observer. Pattern 16.18 Plug-Points and Plug-Ins. Video Case Study: Component-Based Design. Appendix A: Object Constraint Language. Appendix B: UML Perspective. Appendix C: Catalysis Support Tools, Services, and Experiences. Notes. Glossary. Index. 0201310120T04062001

1,127 citations


"A component based approach to scien..." refers background in this paper

  • ...It both provides and requires services based on specified interfaces [13]....

    [...]

  • ...D’Souza[13] describes a component based framework as a collaboration in which all the components are specified with type models; some of them may come with their own implementations....

    [...]


Proceedings ArticleDOI
21 May 1999
TL;DR: The PuLSETM (Product Line Software Engineering) methodology is developed for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts and captures and leverages the results from the technology transfer activities with industrial customers.
Abstract: Software product lines have recently been introduced as one of the most promising advances for efficient software development. Yet upon close examination, there are few guidelines or methodologies available to develop and deploy product lines beyond existing domain engineering approaches. The latter have had mixed success within commercial enterprises because of their deployment complexity, lack of customizability, and especially their misplaced focus, that is on domains as opposed to products. To tackle these problems we developed the PuLSETM (Product Line Software Engineering) methodology for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. This is achieved via product-centric focus throughout the phases of PuLSETM, customizability of its components, incremental introduction capability, maturity scale for structured evolution, and adaptations to a few main product development situations. PuLSETM is the result of a bottom-up effort: the methodology captures and leverages the results (the lessons learned) from our technology transfer activities with our industrial customers. We present in this paper the main ideas behind PuLSETM and illustrate the methodology with a running example taken from our transfer experience.

392 citations


"A component based approach to scien..." refers methods in this paper

  • ...Several methods have been published: Catalysis (supports component modeling), Unified Process (Limited support for components), KoBra and Pulse[15] (under development but designed to support both components and product line engineering)....

    [...]


Journal ArticleDOI
TL;DR: To achieve coherence and manage the complexity and change inherent in multiple e-commerce applications, an overarching structure is needed—an application architecture to provide companies with the speed and agility they need to compete in Internet time.
Abstract: 61 F orward-thinking companies have come to realize that e-commerce is neither just a buy-side nor sell-side packaged application. They have learned that mission-critical business opportunities abound and they must implement many e-commerce initiatives along the way to building the virtual corporation that thrives in the Digital Economy. To them, e-commerce is an infrastructure for a whole new way of doing business. They have learned if they extend their business processes across company boundaries and integrate them with their suppliers' and customers' business processes something totally new starts to happen. E-commerce applications can be categorized into the four major groupings shown in Figure 1. On the sell side of most companies, I-Market applications include online catalog management, order management , trading communities, marketing and advertising, while Customer Care applications involve customer self-service, customer relationship management and business intelligence support. On the buy side, Vendor Management Systems automate the procurement of indirect operating resources including sourc-ing, bid/ask buying and custom supplies catalogs. Extended Supply Chain Management includes collab-orative forecasting and planning, scheduling and logistics. These are general categories, and some companies such as GE and Home Depot already have identified more than 70 e-commerce opportunities for competitive advantage and business concept innovation. To achieve coherence and manage the complexity and change inherent in multiple e-commerce applications , an overarching structure is needed—an application architecture. Joined electronically, companies operating in the Digital Economy must share a common foundation for integrating their unique business processes and embrace the software component paradigm as the way forward. Their core business processes are embedded in legacy, enterprise resource planning (ERP) and client/server systems. In order to retarget these internal systems outward, common inter-enterprise application functions are needed. As shown in the inner oval of Figure 1, information boundaries, workflow/process management , trading services, searching The software paradigms of component-based frameworks for e-commerce promise to provide companies with the speed and agility they need to compete in Internet time.

150 citations


"A component based approach to scien..." refers background in this paper

  • ...Fingar[12] maintains that most frameworks should capture workflows since they provide the necessary modeling capabilities for constructing any business process....

    [...]


Proceedings ArticleDOI
16 May 1999
TL;DR: PuLSE-Eco, a technique especially developed to address the aforementioned issues, is introduced, with a complete product-centric orientation done via product maps, the separation of concerns achieved through the definition and operationalization of strategic business objectives, and diverse types of analyses performed upon product maps allowing scoping decisions based on these objectives.
Abstract: Product line scoping is a critical activity because it elicits the common realms upon which the different products of a product line can be optimally engineered with respect to economies of scope. This, in turn, upper bounds the overall economic benefits that can be accrued from product line based development. Inherently, product line scoping is difficult because of the complexity of the factors that must be taken into account. Many are not known a priori. Traditional scoping approaches (from domain engineering) have focused on the notion of application domains. However, domains proved difficult to optimally scope and engineer from an enterprise standpoint because a domain captures extraneous elements that are of no interest to an enterprise which must focus on particular products, whether existing, under development, or anticipated. Hence, the domain view provides a flawed economic basis for making a scoping decision. We introduce PuLSE-Eco, a technique especially developed to address the aforementioned issues. Its main characteristics are: a complete product-centric orientation done via product maps, the separation of concerns achieved through the definition and operationalization of strategic business objectives, and last, diverse types of analyses performed upon product maps allowing scoping decisions based on these objectives. We illustrate the technique with a running example.

145 citations


"A component based approach to scien..." refers background in this paper

  • ...A software product line [2,3] is a set of software systems that share a common set of features that satisfy a specific market demand....

    [...]