A component based approach to scientific workflow management
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
References
116 citations
"A component based approach to scien..." refers methods in this paper
...[5] Discusses methods to model and capture this variation....
[...]
87 citations
"A component based approach to scien..." refers background or methods in this paper
...Kobryn[14] shows that this component framework pattern applies to both EJB as well as COM+....
[...]
...Figure 3 adapted from Kobryn[14] illustrates this common pattern using UML notation....
[...]
48 citations
37 citations
"A component based approach to scien..." refers background in this paper
...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....
[...]
6 citations
"A component based approach to scien..." refers methods in this paper
...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....
[...]