Academia.eduAcademia.edu

Figure from:Valmont: a language for workflow programming

See full PDFdownloadDownload figure
Figure 5. Design Change Form

Figure 5 Design Change Form

Related Figures (3)

concerns the execution and management of a change of re- quirements for an existing software component. The pro- cess 1S in itiated in response to the modification of a require- ment unit. It begins with a project leader scheduling and as- signing t he various engineering tasks in the process. These include modification of the corresponding design unit, mod- ification testing o activities of the test plan, modification of the unit test, and f the modified unit. During the execution of these the project leader monitors their progress. The process description specifies constraints on the process in- cluding t he ordering of some of the tasks, the kinds of per- sonnel responsible for each task, as well as conditions for task initi fied) con ation and termination. The tasks and the (simpli- trol flows between them are depicted in Figure 1. “Monitor Progress” is a task that interacts with all the other tasks in “Develop Change and Test Unit”. Figure 1. Control Flows in the ISPW-6 Soft- ware Change Process
concerns the execution and management of a change of re- quirements for an existing software component. The pro- cess 1S in itiated in response to the modification of a require- ment unit. It begins with a project leader scheduling and as- signing t he various engineering tasks in the process. These include modification of the corresponding design unit, mod- ification testing o activities of the test plan, modification of the unit test, and f the modified unit. During the execution of these the project leader monitors their progress. The process description specifies constraints on the process in- cluding t he ordering of some of the tasks, the kinds of per- sonnel responsible for each task, as well as conditions for task initi fied) con ation and termination. The tasks and the (simpli- trol flows between them are depicted in Figure 1. “Monitor Progress” is a task that interacts with all the other tasks in “Develop Change and Test Unit”. Figure 1. Control Flows in the ISPW-6 Soft- ware Change Process
Figure 3. Relationships between Agents tion, ror example in line 2-4 and 25-20. Ihe pre-denned attribute “LEADER” of “Project-Team” is registered in line 38. Since a team member can hold more than one position, it is sometime necessary to speci fy the capacity of a team member. In line 38, “David” serves in the “Project-Team” as a “Software_Engineer” rather t han other capacities (e.g. “Quality_Assurance_Engineer”’) that he may hold. Teams can form a team hierarchy using t he inclusion relationship. For instance, the “Project_Team” in “France” is included in the “Configuration_Control_Board using the AFFILIATION clause in ” team. This is specified ine 25.
Figure 3. Relationships between Agents tion, ror example in line 2-4 and 25-20. Ihe pre-denned attribute “LEADER” of “Project-Team” is registered in line 38. Since a team member can hold more than one position, it is sometime necessary to speci fy the capacity of a team member. In line 38, “David” serves in the “Project-Team” as a “Software_Engineer” rather t han other capacities (e.g. “Quality_Assurance_Engineer”’) that he may hold. Teams can form a team hierarchy using t he inclusion relationship. For instance, the “Project_Team” in “France” is included in the “Configuration_Control_Board using the AFFILIATION clause in ” team. This is specified ine 25.
Figure 9. System Architecture 5 System Architecture The architecture that supports Valmont is sketched in Figure 9. The system is implemented using OPJ (Orthog- onal Persistent Java) [2] which provides orthogonal persis- tence [3], distribution support [20] as well as transaction support [9]. With OPJ, data of any type including proce- dures can be made persistent by attaching to a persistent root. There is no need to explicitly translate run-time data structures to persistent data structures such as to a database. An extended form of the Uniform Resource Locator (URL) called Persistent Object Locator (POL) is used to globally name any object in any persistent store. Conditions can be associated to objects to control their access and usage from remote locations. Transaction primitives are provided as OPJ object classes which can be used by expert users to build application specific transaction models. Such intro- duction of transactional behaviour can even be done dynam- ically without requiring re-building of the system or its ap- plications. Less experienced users can define transactional applications by simply using the already defined transaction classes.
Figure 9. System Architecture 5 System Architecture The architecture that supports Valmont is sketched in Figure 9. The system is implemented using OPJ (Orthog- onal Persistent Java) [2] which provides orthogonal persis- tence [3], distribution support [20] as well as transaction support [9]. With OPJ, data of any type including proce- dures can be made persistent by attaching to a persistent root. There is no need to explicitly translate run-time data structures to persistent data structures such as to a database. An extended form of the Uniform Resource Locator (URL) called Persistent Object Locator (POL) is used to globally name any object in any persistent store. Conditions can be associated to objects to control their access and usage from remote locations. Transaction primitives are provided as OPJ object classes which can be used by expert users to build application specific transaction models. Such intro- duction of transactional behaviour can even be done dynam- ically without requiring re-building of the system or its ap- plications. Less experienced users can define transactional applications by simply using the already defined transaction classes.