No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
A Study on the Component Based Architecture for Workflow Rule Engine and Tool
Abstract
The component based development and architecture technology have the potential to be more powerful than traditional. In this
paper, we propose 4 views for architecture development, which are use case view, logical view, component view and implementation
view. We present component based architecture through ABCD pattern in a component viewpoint. In addition, we apply 4 viewpoints
for workflow rule and tool development and propose each design. We present the user interface of actuality developed workflow
engine and tool in implementation view. It actually allowed the various stakeholders to find what they want to know about
the software architecture. This architecture viewpoints separation accurately will accurately reflects the practice in development
of real software systems. Also, we expect to decrease the complexity of implementation, improve reuse and reconfiguration
and productivity in workflow system and similar domain.
Workflow technologies are becoming pervasive in the area of space. They enable the execution of space business processes in distributed and ubiquitous computing environments. However, there are some problems such as cross-platform workflow which need to be solved urgently in space test and launch. Aiming at enhancing the efficiency of space test and launch, the distributed workflow engine model of the space test and launch based on JMX was designed. And the workflow engine routing control algorithm was proposed. At last, the performance of the workflow engine system was analyzed. The model was applied in a launch base successfully. The actual operation tests show that: the proposed design model was rational and effective. It enabled changing the engine process dynamically and enhancing the flexibility of the engine system. Furthermore, it enabled setting workflow engines according to the task and application of the test and launch departments. The performance and efficiency of the space test and launch system was improved greatly.
The long time and cumbersome process of spacecraft test have hampered the development of China's space industry. In order to improve the launch success rate, shorten the test time, optimize the test process, a new type of implementing project of the test and launch flow was proposed based on the theory of system engineering. In addition, this paper introduced the idea of workflow into the area of spacecraft test. A new workflow management system of spacecraft test based on Web service was built. It solved the complexity and deficiencies of system integrating ability in current workflow system. And it simplified the flow pattern, reduces the modeling complexity, supports visualizing modeling and enhances the system integrating. Particularly, the framework can propose a series of feasible solutions and give us higher-level of efficiency in improving the quality of spacecraft test.
Aiming at solving the problem of the change in world acquisition model, a new acquisition strategy which was called the acquisition based on capacity and simulation was proposed. It will enhance the efficiency of our defense acquisition. Particularly, this paper has newly contrived a workflow management system according to the strategy. The proposed strategy was achieved by information technology. Large and complex acquisition management work processes can be changed easily in the workflow management system. And the processes can be added, deleted and joined expediently. It solved the diversity and the uncertainty methods of the large and complex acquisition. The framework can propose a series of feasible solutions and give us higher-level of efficiency in improving the quality of workflow models.
This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various `stakeholders' of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed...
MEMS (microelectromechanical system) fabrication can be organized as three sub-processes, that is, the front-end process, the wafer cap process, and the back-end process. The coordination between the releases of raw wafers to the two parallel sub-processes, the front-end process, and the wafer cap process, is always an important issue. Previous research work has developed synchronization rules to create effective coordination. In this paper, new synchronization rules and dispatching rules are developed and they are evaluated with more release rules. From this much more extensive simulation experiment, it is found that there are significant two-factor and three-factor interactions among these three types of rules and we have to consider them all together in order to achieve the best performance for the MEMS fabrication system. Moreover, the complicated relationship between the performances (cycle time and total work-in-process) is also indicated.
The 4 + 1 View Model describes software architecture using five concurrent views, each of which addresses a specific set of concerns: The logical view describes the design's object model, the process view describes the design's concurrency and synchronization aspects; the physical view describes the mapping of the software onto the hardware and shows the system's distributed aspects, and the development view describes the software's static organization in the development environment. Software designers can organize the description of their architectural decisions around these four views and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth view. The architecture is partially evolved from these scenarios.The 4+1 View Model allows various stakeholders to find what they need in the software architecture. System engineers can approach it first from the physical view, then the process view; end users, customers, and data specialists can approach it from the logical view; and project managers and software-configuration staff members can approach it from the development view.
This paper proposes a UML-based software maintenance process. The process is guided by architectural descriptions and existing architectural models. The descriptions are given as variants of UML profiles describing the styles and rules relevant for a particular application domain. A reverse engineering subprocess, combining top-down and bottom-up reverse engineering activities, aims at constructing the architectural models. Resulting models are investigated in a model analysis subprocess. The models are checked against the profiles to find violations against the given architectural rules when maintaining and developing the subject system, and they are further analyzed using a set of UML model processing operations. The proposed approach is applied for maintaining a large-scale product platform architecture and real-life product-line products built on top of this platform. The model analysis results of the case study are discussed.
Software component consumers are entitled to trusted components. This panel addresses the criteria for trusted components and presents generally accepted definitions for all terms used to describe both software components and the methods and processes required to verify trusted software components.
The definition of business component architecture represents a challenging goal in component-based software engineering. Despite the several approaches to this subject, difficulties still arise when designing and assembling components to provide an integrated solution. The problem we focus on this work is the absence of rules that make use of analysis models to guide the architect throughout the specification of a component-based architecture. This lack of support results in a series of laborious and nonautomated activities. In order to increase the abstraction level of the business component architecture specification task and reduce design efforts, this work presents a practical proposal aimed at generating business components from analysis models. To achieve this goal, some rules and procedures have been researched and evolved, guiding the software architect during the development process.
Components defined in software architecture have two features: as basic elements of the architecture, they must conform to the architectural constraints and in the meantime, similar to the common components, they should be designed flexibly enough to be able to be developed independently for the late third party integration. However, these two important issues have always been handled separately from different point of views, which leads to the extra work, confusions in the program structures as well as the difficulty in maintenance. This paper presents a basic model of the architecture-based components implementation to band these two issues together. It firstly describes a novel design pattern, triple-C pattern which stands for Components-Communicate-through-Connector. This pattern not only emphasizes that implementation must completely conform to the architectural definition, but also attempts to change the fundamental way of components communication with suggesting provided service should be transferred through the connector instead of directly between the client and server components. Second, it describes a novel ADL JCMPL, toolset JCMP and techniques to keep architectural conformance in the implementation as well as support the architectural integration from separate components. Finally, this model is evaluated in a case study.
Grid workflow can be defined as the composition of grid application services which execute on heterogeneous and distributed resources in a well-defined order to accomplish a specific goal. Uncertainties within grid environments pose new challenges for grid workflow management systems such as lacking central control and undedicated resource sharing. In this paper, we provide a workflow enactment engine together with an XML-based workflow language (xWFL). The workflow engine supports a just in-time scheduling system, thus allowing the resource allocation decision to be made at the time of task execution and hence adapt to changing grid environments. We also show that an event-driven scheduling architecture using tuple spaces provides a highly flexible approach for executing large scale complex grid workflows.
Developing and using various component forms as building blocks
can significantly enhance software-based system development and use,
which is why both the academic and commercial sectors have shown
interest in component-based software development. Indeed, much effort
has been devoted to defining and describing the terms and concepts
involved. Briefly, we describe software components as units of
independent production, acquisition, and deployment that interact to
form a functional system. We identify a set of issues organized within
an overall framework that software developers must address for
component-based systems (CBS) to achieve their full potential
To help us identify and focus on pragmatic and concrete issues related to the role of software architecture in the design and development of large systems, we conducted a survey of a variety of software systems used in industrial applications. Our premise, which guided the examination of these systems, was that software architecture is concerned with capturing the structures of a system and the relationships among the elements both within and between structures. The structures we found fell into several broad categories: conceptual structure, module structure, code structure, and execution structure. These categories address different engineering concerns. The separation of such concerns, combined with specialized implementation techniques, decreased the complexity of implementation, and improved reuse and reconfiguration. We observed that in practice, software architecture played an important role throughout the development process: specification, design, functional decompo...
This article provides a brief overview of some of the important architecture related efforts. What is software architecture? In this article a software architecture is loosely defined as the organizational structure of a software system including components, connectors, constraints, and rationale [2][3]. Dewayne Perry and David Garlan, the editors of a special issue of IEEE Transactions on Software Engineering (expected fall 94), are working on a more formal and standardized definition. Software Architecture Science
Software Architecture Technology Guide
- F Svoboda
- D Creps
Component Classification for CBD Repository Construction
- H K Kim
- E J Han
- H J Shin
- C H Kim