Microflow Integrated Development Environment - … for a Microflow Integrated Development...

2003-05-06

English Title Framework for a Microflow

Integrated Development Environment (MIDE)

Swedish Title

Ramverk för en utvecklingsmiljö för mikroflöden (MIDE)

A Master’s thesis by Johnny Olsson for the Program in Mathematics and Computer Science, at the Department of

Numerical Analysis and Computer Science Institution at KTH.

Thesis writer Johnny Olsson Supervisor Serafim Dahl Examiner Lars Kjelldahl Assigner Anders W. Tell

Abstract Framework for a Microflow Integrated Development Environment (MIDE) This report is the result of a Master’s project at the Program in Mathematics and Computer Science, Stockholm University. The project was performed at Open ebXML Laboratory in Kista in collaboration with Financial Toolsmiths. The report contains a description of the procedure of the Master’s project, a short introduction to ebXML and descriptions of other related programs. All of the programs used during the Master’s project have been open source programs. The main task for this Master’s thesis has been to investigate the best way to develop a framework that edits, tests and debugs Microflows. A Microflow is a chain of operations on an XML-document. A prototype for this framework has also been developed. The development of the prototype was performed with NetBeans. The programming language has been Java. This work was performed in collaboration with Anders W. Tell at Financial Toolsmiths.

Referat Ramverk för en utvecklingsmiljö för mikroflöden (MIDE) Denna rapport är resultatet av ett examensarbete på mate-matisk-datalogiska linjen, Stockholms universitet. Examens-arbetet har utförts på Open ebXML-laboratoriet i Kista i samarbete med Financial Toolsmiths. Rapporten innehåller en beskrivning av tillvägagångs-sättet för hur examensarbetet utfördes, en kort introduktion till ebXML och en beskrivning av hur relaterade program fungerar. Alla program som har an-vänts under utvecklingsarbetet har varit open-source-program. Huvuduppgiften för examensarbetet har varit att undersöka, hur ett ramverk som editerar, testar och debuggar mikroflöden (som är en kedja av operationer i ett XML-dokument), bäst skulle kunna utvecklas. Även en prototyp för detta ramverk har utvecklats. Prototypframställningen har skett med utvecklings-programmet NetBeans, programmeringsspråket har varit Java. Detta arbete har skett i samarbete med Anders W. Tell på Financial Toolsmiths.

Foreword Project management § This thesis is a Master’s project at the Programme in

Mathematics and Computer Science, Stockholm University. § The thesis work was to be executed as an open source

project based on the facilities given by Open ebXML Laboratory and the project workspaces available in Open ebXML and Open SHS.

§ The work was performed in cooperation with members of Open ebXML Laboratory and related domain experts.

§ The work was actively managed by an overview project plan and a document with a detailed list of current and open issues.

§ The work was performed at Open ebXML Laboratory facilities in Kista, Stockholm.

§ Any source code and other artifacts are covered by Open ebXML open source license unless otherwise agreed upon. All software design proposals were documented in UML using the ArgoUML application.

§ Software development was primarily performed using open source tools.

Participants Name Role Description

Johnny Olsson Thesis Writer Email: [email protected] Mobile: 070-522 67 16

Anders W. Tell Project Coordinator

Financial Toolsmiths AB Email: [email protected] Mobile: 070-546 66 03

Serafim Dahl Supervisor Nada/KTH Email: [email protected]

Lars Kjelldahl Examiner Nada/KTH Email: [email protected]

Contents 1 Introduction......................................................................................1

2 Background.......................................................................................3

2.1 NetBeans ....................................................................................3

2.2 Introduction to ebXML............................................................4

2.3 Introduction to JHotDraw.......................................................7 2.3.1 Classes in JHotdraw.......................................................8

3 Problem Analysis............................................................................12

3.1 Class generation......................................................................19

3.2 File structure for MIDE.........................................................21

4 Technique ........................................................................................24

4.1 MIDE development process...................................................24 4.1.1 Startup phase ................................................................24 4.1.2 Framework analysis phase...........................................24 4.1.3 Framework design phase .............................................25 4.1.4 Framework implementation phase .............................26 4.1.5 Testing module analysis phase ....................................26 4.1.6 Testing module design phase.......................................27 4.1.7 Testing module implementation phase.......................27 4.1.8 Debugging module analysis phase...............................27 4.1.9 Debugging module design phase .................................28 4.1.10 Debugging module implementation phase ...............28 4.1.11 Test and Evaluation phase.........................................28

4.2 Realization environment process .........................................29

5 Achievement Analysis ....................................................................30

5.1 MIDE-Framework Testing Strategy.....................................30 5.1.1 Test types.......................................................................30 5.1.2 Testing Principles .........................................................32 5.1.3 Test staff ........................................................................32 5.1.4 Test Cases ......................................................................32

5.2 Framework Evaluation Plan .................................................33 5.2.1 Evaluation of MIDE-Framework Design...................33 5.2.2 Evaluation of MIDE-Framework Appearance ..........34 5.2.3 Evaluation of MIDE-Framework Functionality ........34 5.2.4 Evaluation of MIDE-Framework Test Module .........34 5.2.5 Evaluation of MIDE-Framework................................35 Debugging Module.................................................................35

6 Conclusions .....................................................................................36

6.1 Future work ............................................................................37 6.1.1 Logic...............................................................................37 6.1.2 UI....................................................................................37 6.1.3 Menu ..............................................................................37

6.1.4 Selection.........................................................................38

References..........................................................................................40

Appendix ............................................................................................41

A.1 MIDE DTD.............................................................................41

A.2 Time plan................................................................................46

A.3 Example of a MIDE Xml-document ....................................47

A.4 The figures in MIDE..............................................................51

1

1 Introduction In all business collaboration and commerce software systems there exists one or more information exchange components. In ebXML the specification governing message interchange is named Transport, Routing and Packaging (TRP) and the pri-mary software component implementing the message inter-change is named ebXML Message Service Handler (MSH). Within the Open ebXML project a MSH is being implemented using what is being named Microflow. The Microflow comp-onent is the core part of a multi-protocol engine capable of handling many protocols such as low-level protocols (SOAP, IIOP...) and high-level business collaboration protocols (ebXML, RosettaNet, cXML...). A Microflow consists of many different pluggable and dynam-ically loadable Actions assembled at runtime into a dataflow. Each action is connected/wired to other actions using so called Handlers. A handler is connecting a single Outgoing Port with another Incoming Port. That is a so-called Execution Order. An Execution Order is all of the ways that information may be sent through the Microflow, such as start->action1->action2& action3 ->end. A Microflow also connects actions with Data-flows and Controlflows. Dataflow is how the information is sent through this special Actionflow, such as start->action1->action2->end. Controlflow is the way that the information is sent through the actions in the Microflow such as action1->action2. Information or Messages are sent through a Microflow and a result is later returned. The component uses threads and other concurrent technologies in order to achieve performance and low resource utilization. XML is often used to represent info-rmation in messages and therefore a number of XML related actions has been created such as XSLT transformation and XPath selector. The Xpath Selector may also be used in the IF-action as testing expression. Action, handler, and message implementations are stored in ActionPacks for easy access and distribution. Since many protocols use the same or similar technologies and methods it is possible handle multiple protocols with a relat-ively small number of actions, messages, etc.

2

The thesis work involves designing a development and testing environment for Microflows (MIDE). The MIDE must contain functionality for editing, packaging, and storage in XML of Microflows. It must also contain functionality for manual and automated testing and debugging of previously constructed Microflows. A rough sketch of how this MIDE could look like is presented in Figure 1.

Figure 1 A rough sketch of MIDE.

3

2 Background Before I could start the developing process I had to study some programs to see which was best suited for my project. My con-clusion was that the best program I could use was Netbeans. I also had to learn what ebXML and JHotdraw was all about. In this chapter I describe these three programs.

2.1 NetBeans In the development of the MIDE-application I used an Open-Source program called NetBeans. NetBeans is an open source, modular IDE, written in Java. Since it is written in Java, it will run on any platform with a JVM. NetBeans is An IDE (Integrated Development Environment) that includes things such as an editor, tools for working with source code (Java, C++ and others), version control, and a lot more. Some of the advantages of it are:

• Advanced syntax highlighting, error checking code editor.

• Support for the Java, C, C++, XML and HTML languages.

• Support for JSP, XML, RMI, CORBA, JINI, JDBC and Serv-let technologies.

• Support for Ant, CVS and other version control systems.

• Pluggable support for compilers, debuggers and execution services.

• Visual design tools.

• Wizards and code generation and management tools.

• Support for including .jar files to the code.

• Advanced code completion for Java, HTML, XML and JSP.

All of my work is stored on Open ebXML Laboratories CVS in Kista. When I worked with the development of the MIDE-Application I was connected with that CVS through NetBeans. I also used some of the classes that Open ebXML Laboratories

4

had on that CVS in my development process, such as Model-Element, DefaultModelElement, and ModelElementListener.

2.2 Introduction to ebXML EbXML is a modular suite of specifications that enables enter-prises of any size and in any geographical location to conduct business over the Internet. Using ebXML companies now have a standard method to exchange business messages, conduct trading-relationships, communicate data in common terms, define, and register business processes. EbXML consists of a group of specifications that are maintained by the United Nations Centre for Trade Facilitation and Elect-ronically Business (UN/CEFACT) and OASIS. Once Business Processes and Business Documents are defined, you may store them in an ebXML registry along with CPP’s and CPA’s, classifications, and other objects. One goal of your ebXML project is to define a structure that organizes all this disparate information that is in one place. That structure is the Registry Information Model. It is important to notice that an ebXML registry does not store actual documents or specifications, but rather metadata about documents. It consists of a collection of RegistryEntry objects of various types, including Organizations, Packages, Slots (of info-rmation about an object), and Associations between objects. You may query the registry programmatically, and you may update it so that companies can add information. The structure of ebXML is presented in Figure 2.

5

Figure 2 structure of ebXML.

BusinessProcesses

Core / DomainComponents

CollaborationProtocol Profile

CollaborationProtocol Profile

CollaborationProtocol Agreement

BusinessServices /

Applications

BusinessServices /

ApplicationsPayload

BusinessDocuments

BusinessServiceInterface

BusinessServiceInterface

Design TimeRun Time

Transport

Registry / Repository

6

Trading partner information Trading partners need a mechanism to publish information about the Business Processes that they support along with specific technology implementation details about their capa-bilities for exchanging business information. This is accomp-lished through the use of a Collaboration Protocol Profile (CPP). The CPP is a document that allows a trading partner to express their supported Business Processes and Business Service Inter-face requirements in a manner where they can be universally understood by other ebXML compliant trading partners. A special business agreement called a Collaboration Protocol Agreement (CPA) is derived from two or more CPP’s. The CPA serves as a formal handshake between two or more Trading partners wishing to conduct business transactions using ebXML. Collaboration Protocol Profile The CPP contains essential information about the trading partner including, contact information, supported business processes, interface requirements, and message service require-ments. Each ebXML compliant Trading Partner should register their CPP(´s) in an ebXML compliant registry service. Collaboration Protocol Agreement A CPA is a document that represents the intersection of two CPP’s and is mutually agreed upon by both trading partners who wish to engage in e-business using ebXML. A CPA describes the message service and the business process require-ments that are agreed upon by two or more trading partners. A short example of a business scenario Company A has become aware of an ebXML registry that is accessible on Internet. Company A, after reviewing the contents of the ebXML registry decides to build and deploy its own ebXML compliant application. Company A then submits its own Business Profile Information to the ebXML registry. The Business Profile that is submitted to the ebXML registry desc-ribes the company’s ebXML capabilities and constraints, as well as its supported Business Scenarios. These Business Scenarios are XML versions of the Business Processes, in which the company is able to engage.

7

Company B discovers the Business Scenarios supported by Company A in ebXML registry. Company B then sends a request to company A stating that they would like to engage in a Business Scenario using ebXML. Before engaging in the scenario Company B submits a proposed Business Agreement directly to A’s ebXML compliant software interface. The proposed Business Agreement outlines the mutu-ally agreed upon business scenarios and specific agreements. The business agreement also contains information pertaining to the messaging requirements for transactions to take place, contingency plans, and security-related requirements. Comp-any A then accepts the Business Agreement. Company A and Company B is now ready to engage in e-Business using ebXML.

2.3 Introduction to JHotDraw JHotDraw is a Java GUI framework for technical and structured Graphics. It has been developed as a “design exercise” but is already quite powerful. Its design relies heavily on some well-known design patterns. JhotDraw’s original authors have been Erich Gamma and Thomas Eggenschwiler. JHotdraw contains classes for creating GUI applications. It provides abilities to connect figures, reshape figures and lot of other features, which I have used in the MIDE application. The MIDE application is built on top of JHotdraw, several other applications have been built using JHotdraw. A short selection of those applications is presented below. JARP JARP is a graphical composer for Place/Transitions Petri nets. It exports files to GIF, JPEG, PPM, PNG, ARP, PNML (XML based) and a proprietary JPN (JHotDraw based) file formats. An external tool called ARP provides the analysis. Joone − Java Object Oriented Neural Engine Joone is a java framework to create, train, and run neural networks. Its modular architecture permits to build whatever neural net, and it is expansible simply extending the base comp-onents provided with it. The aim of the project is to build a

8

professional environment to create and train neural networks in a distributed environment using the newest java technologies. Renew Renew is a graphical editor and a simulation environment for object-oriented Petri nets. It is an open source product and has been downloaded over 1000 times by more than 400 different users. ChemSense Chemistry whiteboard for education. (Porting existing drawing app to JHotDraw; in progress Dec 2001.) GOOSE GOOSE is a tool set for analyzing the design of object-oriented software systems. It is not (yet) built on top of JHotDraw. So far JHotDraw has been used only as an example for reverse-engin-eering object-oriented systems. JHotDraw is nice for this purp-ose, since it is really object-oriented, it is well known, and its source code is available. Pangaea Pangaea is a system that may distribute centralized Java prog-rams, based on static source code analysis and using arbitrary distribution platforms, such as RMI or CORBA, as a backend. Pangaea takes the idea of distribution transparency one logical step further: both the decision for an appropriate distribution strategy for a program, and the realization of that strategy on a particular distribution platform, are accomplished not only transparently, but also automatically. Pangaea’s user interface is an object graph editor written with JHotDraw. 2.3.1 Classes in JHotdraw In this section there is a collection of the classes in JHotdraw, with a short description of the class and the interesting sub-classes, which have been used during the development process for the MIDE application. Figure This class is the interface of a graphical figure. Every figure has one or more connectors, it also have one or more handlers. The

9

figure creates a connector on a position with connectAt (int x, int y). A figure may have different connectors on different loca-tions. A figure knows about its DisplayBox and can redraw itself. A figure may be a composition of several figures. Interesting subclasses AbstractFigure AbstractFigure provides default implementation for the Figure interface. All of the figures are a subclass of this class. ConnectionFigure Figures to connect Connectors provided by Figures. It contains a start connector an end connector and different connection lines depending on what ConnectionFigure it is. Line Connection A Line Connection is a standard implementation of the Conn-ection Figure interface Rectangle Figure This is the figure that the MIDE ActionFigure is created from.

10

Handle Handles are used to change a figure by direct manipulation. The handle knows about its figure and it has functions to loca-lize its place on its figure and to keep track on changes in its figure. Interesting subclasses LocatorHandle Delegates a locator request to the LocatorObject, to find the position (x, y) of the handle. AbstractHandle AbstractHandle provides default implementation for the Handle interface. ConnectionHandle This class creates a connection between two connectors. It also draws out the startconnector, which is the start of a ConnectionFigure. Locator Locators can be used to locate a position on a figure. Locator encapsulates the strategy to locate a handle on a figure. Interesting subclass AbstractLocator AbstractLocator provides default implementation for the Locator interface. Connector Connectors know how to locate a connection point on a figure. The connector knows which figure it belongs to; it may also find the start and end points on a ConnectionFigure. Connector has a DisplayBox that describes the figures area. Interesting subclasses AbstractConnector AbstractConnector provides default implementation for the Connector interface.

11

LocatorConnector LocatorConnector locates connection points with the help of a Locator. This is a class for receiving a connection; this class draws out the receiver object. It also draws out the endconn-ector, which is the end of a ConnectionFigure. Tool A tool defines a mode of the drawing view. Tool is a structure that has possibilities to interact with the interface. Interesting subclasses AbstractTool AbstractTool provides default implementation for the Tool interface. Connectiontool This is a tool that may be used to connect Figures, to split connections and to join two segments of a connection. It also changes visibility for the figures when the figures are chosen. CreationTool This class is used to create the different figures in JHotdraw. SelectionTool This class is used to select figures and thereafter manipulate them. Commands Command encapsulates an action to be executed. MIDE uses most of the command-classes in JHotdraw. Some of the commands that are used are InsertImageCommand, Delete-Command, GroupCommand, CutCommand, CopyCommand, and PasteCommand.

12

3 Problem Analysis During the development process I used a technique called Model Driven Architecture (MDA). With MDA you start with the creation of the UML-diagrams and then generates java classes from them. I chose the MDA process for the devel-opment of my project because it seemed like the most suitable development process for my special development process. The most important thing in the beginning of my process was to create a complete and relevant underlying model for my MIDE-application. I made most of the decisions in this phase with consultation of Anders W Tell. All of the models and Class diagrams in this section have been made in Rational Rose. The flow model should have all the things that are relevant for the MIDE-application. Then I worked out this flow model (figure 3) that is the underlying model for the MIDE-application. The MIDE-application has an ActionFlowDefinition and with help from it all the relevant information and figures are presented in all of the windows in the application.

MessageDefinition ClassifierDefinition PinDefinition

0..1 0..n 0..1 0..n

Type

FlowModel

ContainerDefinition

ProcessorDefinition

contains

DataflowDefinition

ContextDefinition

InputPinDefinition

1

1

+flow 1

+destination 1

ControlFlowDefinition

GroupActionDefinition

OutputPinDefinition

0..n 1

+flow 0..n +source 1

ActionFlowDefinition 1

1

1

1 processes

0..n

0..1

0..n

0..1

resul ts

1

1

1

1

controlflows

1 1 1 1 dataflows

0..n

1

0..n

1

groupActions

1 1

1 1 arguments

ActionDefinition

contextUsage 0..n

0..n

0..n

0..n

availableInput

0..1

0..*

+action 0..1

+inputPin 0..*

0..n

1

+consequent 0..n

+predecessor 1

1

0..n

+successor 1

+antecedant 0..n

0..n 1

0..n 1 hasActions

0..n 1..n

0..n 1..n

availableOutput 0..n 0..1 +outpin 0..n

+action 0..1 0..n

1

0..n

1

Action

PortHandlerDefinition

ExecutionOrderDefinition

0..* 0..*

executionOrder

HandlerDefinition

PortDefinition 1

1

1

1

in

1...

1

1...

1

out

0..* 1 0..* 1 porthandlers

BindingDefini tion

0..n 1 0..n 1 Bindings 1

1 1

1 handler

1

1

1

1

from

1

1

1

1

to

Figure 3 Flow model for the application.

13

ExecutionOrder is all of the ways that information may be sent through the actionflow, such as start->action1->action2 & action3->end. An ExecutionOrder contains several bindings. A Binding consists of a from-port, a to-port and a handler. Both the from-port and the to-port knows which Action it belongs to. All of the bindings between actions have handlers. Handlers are a way to manipulate or investigate the result that action1 sends to action2, but the most common handler is the forward hand-ler. The forward handler only sends the information further to the next action. Figure 4 presents the model of the Execution-Order.

ExecutionOrderDefinit ionHandlerDefinition

ActionFlowDefinit ion

0..*0..*

executionOrder

BindingDefinition0..n1 0..n1

Bindings

11

11

handler

ActionDefinition

Name : Stringid : in t

readOnly : Boolean

10..n

10..n

Act ion

PortDefinition

1

1

1

1

from

1

1

1

1

to

1

1

1

1

in

1

1..n

1

1..n

out

Figure 4 ExecutionOrder model.

Dataflow is how the information is sent through this special Actionflow, such as start->action1->action2->end. The Action-FlowDefinition may have several DataFlows. The DataFlow contains of a source pin, a source action, a destination pin and a destination action. The model of the DataFlow is presented in Figure 5.

14

P i n D e f i n i t i o nD a t a f l o w D e f i n i t i o n

A c t i o n F l o w D e f i n i t i o n

1

1

1

1

d a t a f l o w s

O u t p u t P i n D e f i n i t i o n

0. . .

1

0 . . .

1

1

1

1

1

I n p u t P i n D e f i n i t i o n

1

1

1

+ d e s t i n a t i o n1

0. . .

0 . . .

0 . . .

0 . . .

A c t i o n D e f i n i t i o n

1

0 . . .

1

0 . . .

A c t i o n

1 . . .

0 . . .

1 . . .

0 . . .

a v a i l a b l e O u t p u t

0 . . .

0 . . .

+ a c t i o n 0 . . .

+ o u t p i n0 . . .

0 . . .

0 . . .

0 . . .

0 . . .

a v a i l a b l e I n p u t

0 . . *

0 . . .

0 . . *

+ a c t i o n

0 . . .

+ i n p u t P i n

Figure 5 Dataflow Model.

The MideUIManager is the class that controls and creates all of the editors, inspectors, viewers, panel inspectors and the MideMainWindow that is used in the application. Those internal relations are shown in Figure 6.

editors

viewers

inspectors

figures

Versioned

getSpecification()getSpecificationVersion()

getImplementation()getImplementationVersion()getImplementationVendor()

(from util)

Panel(from editors)

Panel(from editors)

TesterUIFrame(from ui)

FilesystemUIPanel

FileSystemUIFrame

DebuggerUIFrame(from ui)

Editor

(from editors)

Viewer

(from viewers)

Inspector

(from inspectors)

MIDEFrame

EditorEntry

ViewerEntry

InspectorEntry

MIDEMainWindow

MIDEFrameEntry

1

0..*

1

0..*

PanelInspector(from presentation)

MideUIManager

0..*0..*

registeredEditors

0..*0..*

registeredView...

0..*0..*

registeredInspectors

11

0..*0..*

activeFra...

MIDEInspector

11contains

PanelInspectorEntry

0..*0..*

activePanelInspectors

1

0..*

1

0..*

Figure 6 UI for MIDE.

One of the panelinspectors that is been created is the Mide inspector; it contains MideDiagram, MideOutlinePanel, Detailpanel and MideInspectorBinder who all are JPanels. The internal structure of this is presented in Figure 7. The Mide-Diagram is the panel where the actual actionflow is drawn. The detail panel is the so-called information panel that shows all of the existent information about the current selected item in the other panels. With MideOutlinePanel you may search around

15

in the ActionFlowDefinition to find out all the information about for example action1’s outputpins. MideInspectorBinder delegates changes in the panels to each other so that every panel is correctly updated.

O u t L i n e P a n e l O u t L i n e B i n d e r

J F r a m e( f r o m s w i n g )

J P a n e l( f r o m s w i n g )

D e t a i l B i n d e r M i d e D i a g r a m B i n d e r M i d e O u t l i n e B i n d e rD e t a i l P a n e l M i d e D i a g r a m

M i d e I n s p e c t o r B i n d e r

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

M y P a n e l I n s p e c t o r

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

M o d e l E n u m N o d e T a g g e d V a l u e N o d e

M i d e O u t l i n e P a n e l

10 . . *

10 . . *

1

0 . . *

1

0 . . *

1

0 . . *

1

0 . . *

J P o p u p M e n u S h o w e r

1

1 . . *

1

1 . . *

Figure 7 MIDE editing class diagram.

The figures in MIDE are based upon some JHotDraw figures, and the relations between them are shown in Figure 8. An actionfig may have an InPinFigure, an OutPinFigure, an InportFigure and several OutPortFigures.

Figures

ConnectionFigures

AbstractFigures

HandlerFig

ExecLineFig ControlFlowLine DataflowLine

Pinfigure

InPinFigure OutPinFigure OutportFigure InportFigure

ActionFig

1

1

1

1

inpin

1

1

1

1

outpin

1..n

1

1..n

1

Outport

1

1

1

1

Inport

PortFigure

Figure 8 The figures in MIDE. .

Because of lack of time I did not manage to develop the testing and the debugging windows that was specified. But I created a flow model for a test suite (figure 9) and the debugging suite

16

(figure 10) so that the application could be developed further if someone should continue where I left the project.

DebugInvocation

addBreakpoint()step()removeBreakpoint()addTrace()enterBreakpoint()

(from debugger)

Debugger

Execute()Stop()Step()enterBreakpoint()

(from debugger)

0..*0..*

invocations

0..*

1

0..*

1

owner

ui

Versioned(from util)

TestResult

Status()

TestStepResult

TestStepEvaluation

11

generate

TestCaseResult

TestStepRun

11

TestCaseEvaluation

Evaluate()

11

generates

TestStepname : String

11

evaluator

11

step

TestCaseMonitor

11

0..*0..*

TestCaseController

TestDefinition

TestContext

TestGroupRun

0..*0..*

TestCaseDefinition

name : Stringversion : String

Evaluate()AssembleMessages()AssembleContexts()

11

evaluator

0..*0..*

steps

11

case

controller

TestDefinitionRun

0..*0..*

TestGroupDefinition

name : String

0..*0..*

11

group

0..*0..*

casesTestSuiteDefinition

ID : DataID

11

t...

1..*1..*

groupsTester

11

definitions

TestInvocation

FinalEvaluation()

TestMonitor

start : DateTimeend : DateTime

Execute()

TestRun

0..*0..*

testR...

11

11

11

monitor

Figure 9 The flow model for a test suite.

ActionInvocation

getMessageProxyNo()getMessageProxy()

getMessageProxyAll()addMessageProxy()

removeMessageProxy()selectMessageProxy()

selectMessageProxyAll()

(from runtime)

PortHandler

process()Wait()

(from runtime)

u i

FlowModel

(from definitions)

DebugTrace

TimePrintText : String

Debugger

Execute(inv : DebugInvocation)Stop(inv : DebugInvocation)Step(inv : DebugInvocation)enterBreakpoint(inv : DebugInvocation, brk : BreakpointPortHandler)

DebugSessionDefinition

11currentSession

PortHandlerDefinition

(from definitions)

ConditionDefinition

DebugInvocation

addBreakpoint(brk : Breakpoint)step()removeBreakpoint(brk : Breakpoint)addTrace(trace : DebugTrace)enterBreakpoint(brk : BreakpointPortHandler)

0..*

1

0..*

1

0..*0..*

invocations

1

0..*

1

0..*owner

BreakpointDefinition

enabled : Boolean = truetrace : Boolean = truePrintText : String0..*1 0..*1

definedAt

BreakpointPortHandler

Trace()enterBreakpoint(brk : BreakpointPortHandler)

instantiates

Condition

Breakpoint

enabled : Boolean = truetrace : Boolean = true

enterBreakpoint(brk : BreakpointPortHandler)

0..*

1 +breakpoint

0..*

+invocation1

breakpoi...

1

0..*

1

0..*

1

1

1

1

Figure 10 the flow model for a debugging suite.

17

With help from Anders W. Tell I generated the Java classes from the uml-diagrams. The classes have support for undo-activity and for Vetoable. Vetoable is a way to lock a value from changing. The undoactivity collects all the things that are perf-ormed into an undostack, for easy undoing if wanted. After that I started with the programming part of my Master’s thesis. When you load an Xml-file into the MIDE-application, MIDE creates an actionflow with all of the information that existed in the Xml-document. All of the changes on the Actionflow in MIDE directly change the Actionflow. All of the different wind-ows in MIDE read the information from the same Actionflow. When the application creates an ActionFlowDefinition the ActionFlowDefinition becomes the ModelManagement for the whole structure, and has itself as its ModelRoot. Every other class that is created has the creator as its ModelRoot. This is a good structure to have because then every class knows its creator and may use its special functions and get its variables if necessary. Every class is also a ModelElement and with the structure built in the class generation and some Open ebXML classes it becomes pretty easy to deploy those classes with some listeners that also is implemented by Open ebXML Laboratory. The listeners that I have used in the framework are Model-ElementListener and ModelElementVetoableListener. Where ModelElementListener is the listener for changes in a certain class and ModelElementVetoableListener is a listener for stopping a certain variable to change in that class. This struc-ture below explains the internal structure for the model.

18

ModelManagement

ModelRoot

ModelElement

Model- ElementListener

ModelElement- VetoableListener

DefaultModelElement

UndoManager

ModelElementInfo

ModelAttribute

ModelAssociation

Info

modelRoot

modelManagement

Undomanager

roots

Figure 11 The model structure for MIDE.

19

3.1 Class generation The class generation produces many classes. It generates an ActionFlow_DOMReader and ActionFlow_SaxWriter. These classes operates the loading/saving XML-files into MIDE. For each class I generate I get 6 classes from it. For example when I generated the ActionDefinition-Class I received Action-DefinitionImpl, ActionDefinition, ActionDefinitionInfo, Action-DefinitionValidator, ActionDefinitionFactory and ActionDefin-itionTest. ActionDefinition This class is the interface for the ActionDefinition. ActionDefinitionImpl This class implements all of the functions in its interface (ActionDefinition). It also has all of the attributes and assoc-iations that ActionDefinition should have. ActionDefinitionInfo All of the attributes and associations that ActionDefinition has are described in this Class. It is also in this class the changes of the attributes and associations takes place. An attribute is a name value or similar an association is toAction or something similar. ActionDefinitionValidator This class is for the validation of the ActionDefinition-Class. ActionDefinitionFactory This class is the critics-class for the ActionDefinition-Class. ActionDefinitionTest This class is for the testing of the ActionDefinition-Class The class generation also generates some Undoactivity for all the setters in the implementation classes. For example a setName (String newName) function looks like:

20

Public void setName (String newName) 1. FireVetoable to see if it is ok to change this value. 2. SetModelRoot to set a new ModelRoot if it is necessary. 3. Addundo (new AddRemoveAction (old, new)) add this

action to the undostack. 4. fName = newName change the name. 5. fireAttributeValueChanged (info, old, new) inform all the

classes that listen to this class that this value has been changed.

21

3.2 File structure for MIDE To be able to get an overview of the generated classes and the classes I created myself I was forced to structure the classes into packages. In this section I am going to describe them roughly. On the top of the file system I have Open ebXML and Tool-smith’s packages, in Open ebXML I put the things that may be interesting for the other on the Open ebXML Laboratory and the rest is in the package Toolsmiths Openebxml/Comp/presentation/main/ Contains some UI classes that may be interesting for building editors such as Diagram, DiagramBinder, OutlineBinder and PanelInspector. Openebxml/Comp/presentation/Util/ A package for the binding functions in a frame, with the classes BindingManager and Versioned. Toolsmiths/Mide/Appl This is a package with the start classes for the MIDE-application. Toolsmiths/Mide/Debugger In this package the big future work contender debugger exists. Breakpoint, DebuggerUIFrame, DebuggerUIPanel and ConditionDefinition is some of the classes that are in this package. Toolsmiths/Mide/Deployer This package is for the opportunity to deploy different envir-onments for different users of the framework. In this package there is a lot to do. Toolsmiths/Mide/Framework/Definitions/ All the definitions in the framework are in this package. This package was the destination of the generated classes from the class generation.

22

Toolsmiths/Mide/Framework/Test/ During the development process I created some small test programs to test all of the classes in the framework, all of those test things exists in this package. Toolsmiths/Mide/Project In this package all the commands in the project that is used in the different editors are. Such as delete, insert image amongst others. It is also used to store information about different users in different projects. Toolsmiths/Mide/Runtime/ This package includes things that are used by the framework in the runtime environment. Different Actions, Containers, Conf-iguration, Context, Expressions, Handlers, Invocations, Mess-ages, Processors and Streams should be implemented in this package for the framework to work as a Runtime environment. Toolsmiths/Mide/Test In this package the test environment exists, some of it are impl-emented but much work needs to be performed here to get it functional for the complete framework. Toolsmiths/Mide/UI The entire user interface for the application is in this package, in the top package there is panels and frames that are used in the application. Toolsmiths/Mide/UI/Editors/ In this package there is editors for editing different things in the framework. Toolsmiths/Mide/UI/Figures/ The figures in the actionflow such as Actions, DataFlowLine, Pins and ports mm are implemented in this package. Toolsmiths/Mide/UI/Inspectors/ In this package there is editors for editing different things in the framework.

23

Toolsmiths/Mide/UI/Viewers/ In this package there is editors for editing different things in the framework. Toolsmiths/Mide/UI/Resources/ The resources the framework use is in this package, such as the different icon figures in the framework and the Xml files that is saved/loaded by the program.

24

4 Technique The project is divided in two parallel processes: MIDE frame-work development and realization environment. The first proc-ess is iterative and involves analysis, design and proof of conc-ept implementation of a MIDE framework for managing Micro-flows and related resources. The second process involves estab-lishing a development environment for the later phases in the framework development process.

4.1 MIDE development process The development process is divided in three processes. These three are framework development process, testing module development process and debugging module development process. All of these processes include analysis, design and implementation phases. 4.1.1 Startup phase This was the phase where I installed correct programs and all the other things to make the project to run smoothly. 4.1.1.1 Activities

§ Write detailed project plan. 4.1.2 Framework analysis phase § Study the current design and implementation of Microflow

system and related components. § Study the usage of generic Integrated Development Envir-

onments (IDE) from a use-case perspective. § Divide potential MIDE users into categories. 4.1.2.1 Activities

§ Literatures studies: Design and implementation of currently available tools (IDE´s) for programming languages devel-opment, available development tools research, OMG Model Driven Architecture including UML, related open source frameworks, Java libraries.

§ Literature search through Internet.

25

4.1.2.2 Deliverables

§ Analysis and requirements report including a list of relevant MIDE use-cases.

§ Framework evaluation plan for how the final proof-of-concept implementation should be evaluated.

§ Create test strategy documents for how the final proof-of-concept implementation should be tested.

4.1.3 Framework design phase § Create a design of a graphical user interface and framework

for editing, packaging personalized development of Microflows. Design is to be based on framework analysis report.

All design phases should have the following requirements: § The design should use and/or extend existing open source

framework(s). § The design should be flexible, extensible and customisable

allowing new types of Microflow components and Action-Packs to be developed.

§ Software design must be captured in UML using ArgoUML application.

§ Design patterns and frameworks should be used in the design.

§ Design work should be performed iteratively in small steps, possible interleaved with implementation of certain soft-ware components.

4.1.3.1 Activities

§ Create design, using UML as modelling tool. § Study relevant design patterns to use in the framework

implementation. 4.1.3.2 Deliverables

§ UML models of framework design. § MIDE framework description document including a list of

prioritised functionality that should be implemented in the proof-of-concept phase.

26

4.1.4 Framework implementation phase § Create proof-of-concept implementation of proposed MIDE

framework. All of the implementation phases should have the following requirements. § The implementation is performed in Java, using exist ing

Java libraries developed within Open ebXML project and libraries currently development by Java Community Proc-ess. Other open source libraries may also be used.

§ Implementation should be interleaving with unit tests. Unit tests are to be based on JUnit code library or other relevant code testing frameworks.

4.1.4.1 Activities

§ Create implementation plan. § Implement framework, component by component § Regression and unit tests using JUnit. 4.1.4.2 Deliverables

§ Java source-code. § Systems and component documentation. § MIDE Framework graphical user interface (GUI). § Update framework document. 4.1.5 Testing module analysis phase § This phase is for analysing the testing module in MIDE. 4.1.5.1 Activities

§ Framework design review. § Analyse how the testing module should collaborate with

MIDE. § Literatures studies: Design and implementation of currently

available tools (IDE´s) for programming languages devel-opment, available development tools research, OMG Model Driven Architecture including UML, related open source frameworks, Java libraries.


27

4.1.6 Testing module design phase § Create a design of a graphical user interface and framework

for testing personalized development of Microflows. Design is to be based on testing module analysis report.

4.1.6.1Activities

§ Create testing module design, using UML as modelling tool.

§ Study relevant design patterns to use in the testing implementation.

4.1.7 Testing module implementation phase § Create proof -of-concept implementation of proposed

MIDE framework testing module. 4.1.7.1 Activities

§ Create implementation plan. § Implement testing module, component by component § Regression and unit tests using JUnit. 4.1.7.2 Deliverables

§ Java source code. § Systems and component documentation. § The testing module for MIDE. § Update framework document. 4.1.8 Debugging module analysis phase § This phase is for analysing the debugging module in MIDE. 4.1.8.1 Activities

§ Framework design review. § Analyze how the debugging module should collaborate

with MIDE. § Literatures studies: Design and implementation of currently

available tools (IDE's) for programming languages development, available development tools research, OMG Model Driven Architecture including UML, related open source frameworks, Java libraries.


28

4.1.9 Debugging module design phase § Create a design for a debugging module for debugging

personalized development of Microflows. Design is to be based on debugging module analysis report.

4.1.9.1 Activities

§ Create design, using UML as modelling tool. § Study relevant design patterns to use in the debugging

module implementation. 4.1.10 Debugging module implementation phase § Create proof-of-concept implementation of proposed

debugging module. 4.1.10.1 Activities

§ Create implementation plan. § Implement debugging module, component by component. § Regression and unit tests using JUnit. 4.1.10.2 Deliverables

§ Java source code. § Systems and component documentation. § Debugging module for MIDE. § Update framework document. 4.1.11 Test and Evaluation phase Proof-of-concept implementation is to be tested and finally evaluated according to previously created plans.

4.1.11.1 Activities

§ Execute test strategy § Quality control. § Perform GUI framework evaluation. § Write final evaluation report. 4.1.11.2 Deliverables

§ The final report.

29

4.2 Realization environment process § Establish development and implementation environment

(tools, compilers, editors, databases etc.). § Build and evaluate related applications, tools, open source

frameworks, etc.

30

5 Achievement Analysis In this chapter I describe how the evaluation and testing of MIDE should be done.

5.1 MIDE-Framework Testing Strategy The test strategy is divided into four subtests Unit Testing, System Integration Testing, User Sign-off Acceptance Testing, Performance Testing and End-User Testing. If some minor errors are found then The Programmer will fix those. Unit testing is a test on component-by-component basis in the framework. System Integration Testing is a test of the frame-work may work together with the system. User Sign-off Accept-ance Testing is a test if the project manager accepts the frame-work. End-User Testing is a test for the end-user of the frame-work. Performance testing is a test if the framework works under critical circumstances. 5.1.1 Test types In this section I describe the different types of tests that is needed to test the program in a proper way. 5.1.1.1 Unit Testing

MIDE unit testing is intended to be the testing the functionality of all the components that is added to the MIDE framework. The programmer will perform testing on each of the compo-nents that may be tested. The programmer will use JUnit with JUnit´s capability of regression testing for the conducting of the tests. The goal is to make sure that the components functionality is fulfilled according to the requirements. Action pack test This test is for testing the action packs so that they work as according to the requirements. 5.1.1.2 System Integration Testing

MIDE System Integration Testing is intended to make sure that the system components, after modification, still function together as they are supposed to, and that the unchanged

31

components of the system are not adversely impacted. During this testing phase, focus is placed on exercising the system internals. System Integration Testing includes testing of how MIDE may open, save, load files etc. Testers are to ensure that all probable conditions are included in the test cases and they are expected to create test cases and enter them via MIDE framework the demands on the system 5.1.1.3 Performance Testing

Performance Testing is designed to simulate to determine whether the system may handle the load of all processes that will run concurrently in production. The goal in performance testing is to identify those jobs that are not being dispatched efficiently and make tuning changes to ensure the system is able to process all jobs efficiently within hardware and software capacity. The results of the performance test may also help determine at what frequency certain jobs are performed. The testers typically authors test scripts to ensure all production processes are accur-ately represented. Testing should encompass all the things MIDE would be doing in a typical production day. Performance testing typically has a defined beginning and end time so that all processes may be kicked off concurrently, and may be engaged to monitor and records statistics on system load to determine the results of the test. 5.1.1.4 Extreme Test

This is a test that is conducted under critical circumstances to find errors and bottlenecks that occurs. 5.1.1.5 User Sign-off Acceptance Testing

During User Sign-off Acceptance Testing, testing focuses on business use of the system. Users are expected to prepare the test data. Testing should simulate real business cycles.

32

Based on their review of the testing results, the functional owners will determine whether the system is ready to be moved into production. 5.1.1.6 End-User Test

End-User testing is a test for a person that is going to use the framework for finding errors/bottlenecks in the everyday use. 5.1.2 Testing Principles • Purpose of the testing is to execute the system with the

intent of finding errors/bottlenecks. • A necessary part of a test case is a definition of the expected

results. • Test cases must be written for invalid and unexpected, as

well as valid and expected, input conditions. • A good test case is one that has a high probability of

detecting an undiscovered error. • If a particular section of a system seems to be much more

error prone than other sections, then additional testing eff-orts are best focused against this error-prone section. This is because the probability of the existence of more errors in a system section is proportional to the number of errors already found in this section.

• If a particular section of a system is much more used than other sections, then additional testing efforts are to be used on that section.

5.1.3 Test staff The Programmer Johnny Olsson The Project manager Anders W. Tell End-User Testers: 1−2 people. 5.1.4 Test Cases Here should the test cases bee when the testing should occur.

33

5.2 Framework Evaluation Plan In the Framework Evaluation Plan I examined how the devel-opment process worked out, to see what was wrong in the development process and what was good about it. It is also an evaluation of the MIDE-Framework to see if the program work as required and if the framework is easy-to-use and nice to look at. My plan is that some of my collaborate partners in the Open ebXML Laboratory are going to help me with some of the evaluation parts. This evaluation is going to take place after the implementation of the whole framework that includes the editing environment for the framework, the testing module development process and the debugging module development process. 5.2.1 Evaluation of MIDE-Framework Design In this evaluation phase the important part of the evaluation is on the Analysis, Design Implementation part of the framework development. To see what could have been performed different and what was good about the development process of the MIDE-Framework. I am going investigate if MIDE follow all of its requirements and specifications. I am going to evaluate if the program follow its UML-diagram, furthermore that the use-cases exists and is working in the program and also that all of the requirements in the earlier analysis and design phases is fulfilled. This evalua-tion phase should answer the following questions. • Did I follow the original development process? • If the framework follows its UML-Diagram? • If the framework design follows the specifications of it? • Does the framework include all of its use-cases? • Which use-cases doesn’t the framework include? Why? • Does the framework follow the analysis report for the

framework?

34

5.2.2 Evaluation of MIDE-Framework Appearance In the evaluation of the MIDE-Framework Appearance phase the programmer will ask his evaluation partners to look at the MIDE-Framework Appearance. They should evaluate the framework according to user-friendliness and if the framework environment looks comparable to other similar frameworks. User-Friendliness is if it is easy to understand abbreviations, the icons in the framework, the names on the menu and all the other names on the functions in the framework. It is also if the environment look like other similar programs. The questions to be answered in this section are. • Does the framework look like other similar programs? • Are the icons in the framework easy to understand? • Are the abbreviations easy to understand? • Are the function names in the framework easy to

understand? • Are the names in the menus of the framework easy to

understand? • Does the framework have an easy to understand help

section? 5.2.3 Evaluation of MIDE-Framework Functionality This is an examination that uses the test strategy to evaluate if the frameworks different functionalities work. The things to answer in this section are. • Is it easier to use the most common actions in the frame-

work? • Are the functions in the framework complicated to use? • Do all of the functions work as required? 5.2.4 Evaluation of MIDE-Framework Test Module An evaluation of the testing module in the MIDE-Framework in order to see that the program fulfil all of the requirements and specifications, that had been worked out during the testing module analysis & design phase. It is also an evaluation of the testing module implementation process. • Do the test part of the framework work as required?

35

• Does the testing module in the framework follow the analysis report for the testing module in the framework?

5.2.5 Evaluation of MIDE-Framework Debugging Module An evaluation of the debugging module in the MIDE-Frame-work in order to see that the program fulfil all of the require-ments and specifications, that had been worked out during the debugging module analysis & design phase. It is also an evaluation of the testing module implementation process. • Do the debugging part of the framework work as required? • Does the debugging module in the framework follow the

analysis report for the debugging module in the framework?

36

6 Conclusions The goal that I had was to create a framework (MIDE) for editing, debugging, and testing Microflows. The MIDE-appl-ication also had to have functionalities to load and save a Microflow. When you load a Microflow into the editing environment it should appear in the editing window, it also loads in the tree structure of the loaded actionflow into the tree window. I created a framework and an editing environment for it. I also created UML-diagrams for testing and debugging, but because of lack of time I did not manage to create the testing environment and the debugging environment. I did not calculate the time that it would take to develop the framework correctly; I guess that this is a common problem among programmers. I should not have been so time optimistic during the project. The class generation produced many classes that gave me a little problem. If I forgot something in the orig-inal UML-diagrams such as a type on a variable, then I had to change those things in several classes later on, that also cost me much time. Another mistake I did was that because of economical reasons I was forced to finish up the programming part at the end of July, instead of working parallel with the Master’s thesis and the development of the prototype. I started the project in late Febr-uary and I only got economical support from CSN until late May, so I had to work during the summer starting 1st of July. When you write the report after the development process, it takes longer time to write about the essential material in your development process because you have to remember all of the things you have performed. During the development process I wrote a framework evalua-ion plan and a testing strategy. Because of lack of time I did not manage to go through with all of the evaluations and testing that should have been performed. The framework was incomp-ete in the way that testing and debugging environment was not

37

implemented so the evaluation and testing is part of the future work for this project.

6.1 Future work In the future the framework that I have created is supposed to be used by the Open ebXML Laboratory in their research and development of the ebXML language, but then they need to implement the things that I left out. The following is a list of the things that have been left undone in the project because of lack of time. 6.1.1 Logic This is the logics section of the framework, where all of the definitions to the different things in the framework are. • Handler Connection with a handler definition. Handler connection is not implemented; it should have a

reference to its handler definition and a nice figure in it. • ExecutionOrderDefinition for the FlowConnection should

be implemented. • BindingDefinition for the FlowConnection should be

implemented. 6.1.1.1 Toolbar

• Tools for creating PortHandler’s should be implemented for easier adding of PortHandler’s in the actionflow.

6.1.2 UI • Popup menu for the figures in MideDiagram should be

implemented; with different actions in it depending on what figure that is chosen.

PopupMenues in OutLinePanel should be different for different nodes, and all the actions required should be taken cared of.

• Update OutLinePanel properly when a figure is inserted/deleted in the midediagram.

6.1.3 Menu • ControlFlow and DataFlow-commands in the menu is not

yet created.

38

6.1.4 Selection • If you click on a connection in midediagram it should open

a special details panels for that with the right properties. • When you double click on a figure an inspector or a viewer

should be shown. • Restructure the Info classes are left to be performed. AttributeInfo and AssociationInfo are two different

information’s, it is needed to take a good look over the info files to change them to its right information.

• Cut copy paste may be desirable command for midediagram. Those should be implemented in the future.

• Enumeration Node is a node for Enumerations such as Bindings.

A special popup menu is required for it and the presentation in the DetailPanel require a little more thoughts.

• Special tree nodes for all of the different ModelElement’s. As it is now MIDE contains ModelElementNode,

TaggedValueNode, ModelManagementNode, ModelEnumNode, and ModelAttributeNode.

That should be changed so that every type has its own Node, for example a PortHandlerTreeNode who creates a special Popup Menu.

• Fix the OutLinePanel Tree so that it is better. The OutLinePanel Tree has to look better, by changing the

nodes to special nodes for every object that is easily acquired.

• Tools for the different Connections. If you want a special connection for example a binding

between two ports it could be nice to have a tool for that. As it is now you get by default an ExecutionOrder connection between the actions dragged between.

• Critics in MIDE (lower left). Critic about the model should be displayed here. • Log panel. Implement the Log Panel with connections to the

midediagram and the OutLinePanel inserted in DetailPanel. • Critics panel. Implement the Critics Panel with connections to the

midediagram and the OutLinePanel inserted in DetailPanel.

39

• Documentation Panel. Implement the Documentation Panel with connections to

the midediagram and the OutLinePanel inserted in DetailPanel.

• Help panel. Implement the Help Panel with connections to the

midediagram and the OutLinePanel inserted in DetailPanel. • Documentation (Comment) in the model. The model is not implemented with Comment so the

classes should have that feature. • Undoactivity in MIDE. It is a feature that should be implemented. Some of it works

with the JHotDraw undo manager. • OutLinePanel. The lower part of OutLinePanel has not been implemented. • Testing Window. This is a testing window in the same way as

myPanelInspector with the ability to test the ActionFlows represented in MIDE.

• Debugging Window. This is a debugging window in the same way as myPanelInspector with the ability to test the ActionFlows represented in MIDE.

• Polygon line. Implementation of a polygon line with 2 or 3 handles so

that you may redirect them in the midediagram. • FilesystemUIFrame For displaying and using the file system.

40

References 1. Oasis UN/CEFACT, EbXML Technical Architecture

Specification, v1.0.4, 16 Feb 2001. 2. Model Driven Architecture (MDA), Architecture Board

ORMSC, 9/7-2001, Document Number ormsc/2001-07-01 3. John Zukowski, Definite Guide to Swing for Java 2, Apress,

Second Edition, 2000. 4. Alan Koltok & David R. R. Webber, ebXML-The new global

standard for doing business over the Internet, New Riders, First edition, September 2001.

5. Douglas Scmidt, Michael Stal, Hans Rohnert & Frank Buschmann, Pattern-oriented software architecture-patterns for concurrent and networked objects, Wiley, Volume 2, 2000.

6. Chuck Cavaness, Geoff Friesen and Brian Keeton, Using java 2 standard edition, que, Special edition, December 2000.

7. Sean McGrath, Xpipe – An XML Processing Methodology, XML SIG, NY USA, 12 Feb 2002.

8. Gentleware AG, Response to the UML 2.0 Diagram Interchange RFP, Version 1.0, 22 Oct 2002.

9. Stephen Mohr & Scott Woodgate, Professional Biztalk, Wrox Press LTD, 2000.

Literature search through the Internet

1. Norman Walsh & Eve Maler, XML Pipeline Definition Language Version1.0, Sun Microsystems, 28 Feb 2002, www.w3.org/TR/xml-pipeline. Last visited 27 Feb 2003.

2. Links to JHotdraw sites http://www.jhotdraw.org/, http://jhotdraw.sourceforge.net. Last visited 27 Feb 2003.

3. NetBeans website http://www.netbeans.org/about/ide/index.html Last visited 27 Feb 2003.

41

Appendix In this appendix you can see a DTD and the xml-file that is used in MIDE, my time plan for the project and the figures in MIDE.

A.1 MIDE DTD This is the document type definition (DTD) for the Xml-documents that the framework may handle. <?xml version="1.0"?>    <!DOCTYPE actionflow [ <!ELEMENT documentation (#PCDATA)> <!ELEMENT taggedvalue (#PCDATA)> <!ATTLIST taggedvalue name NMTOKEN #REQUIRED> <!ELEMENT classifier (#PCDATA)> <!ATTLIST classifier type NMTOKEN #REQUIRED> <!ELEMENT dataflow (documentation?,taggedvalue*)> <!ATTLIST dataflow

sourceaction IDREF #REQUIRED sourcepin NMTOKEN #REQUIRED destinationaction IDREF #REQUIRED destinationpin NMTOKEN #REQUIRED > <!ELEMENT dataflows (dataflow*)> <!ELEMENT controlflow (documentation?,taggedvalue*)> <!ATTLIST controlflow from IDREF #REQUIRED to IDREF #REQUIRED > <!ELEMENT controlflows (controlflow*)> <!ELEMENT handler (#PCDATA)> <!ATTLIST handler code NMTOKEN #REQUIRED >

42

<!ELEMENT fromaction (EMPTY)> <!ATTLIST fromaction name NMTOKEN #REQUIRED outport NMTOKEN #REQUIRED > <!ELEMENT toaction (EMPTY)> <!ATTLIST toaction name NMTOKEN #REQUIRED > <!ELEMENT binding (fromaction?, toaction?,handler,documentation?,taggedvalue*)> <!ATTLIST binding id ID #IMPLIED name (start|end|forward) #REQUIRED > <!ELEMENT executionflows (binding*)> <!ELEMENT inpin (classifier?)> <!ATTLIST inpin name NMTOKEN #REQUIRED multiplicity CDATA #IMPLIED ordering CDATA #IMPLIED > <!ELEMENT outpin (classifier?)> <!ATTLIST outpin name NMTOKEN #REQUIRED multiplicity CDATA #IMPLIED ordering CDATA #IMPLIED > <!ELEMENT porthandler (#PCDATA)> <!ATTLIST porthandler code CDATA #REQUIRED > <!ELEMENT inport (porthandler*)> <!ELEMENT outport (porthandler*)> <!ATTLIST outport name NMTOKEN #REQUIRED > <!ELEMENT exceptionport (porthandler*)> <!ATTLIST exceptionport name NMTOKEN #REQUIRED >

43

<!ELEMENT action (inpin, outpin, inport, outport, exceptionport,documentation?,taggedvalue*)> <!ATTLIST action code CDATA #REQUIRED id ID #REQUIRED readonly NMTOKEN #REQUIRED > <!ELEMENT subaction (action*)> <!ELEMENT value (#PCDATA)> <!ELEMENT variable (classifier?, value)> <!ATTLIST variable name NMTOKEN #REQUIRED > <!ELEMENT variables (variable*)> <!ELEMENT groupaction (variables, subactions, documentation?,taggedvalue*) > <!ATTLIST groupaction id ID #REQUIRED > <!ElEMENT pinref (EMPTY)> <!ATTLIST pinref action IDREF #REQUIRED pin NMTOKEN #REQUIRED > <!ELEMENT arguments (pinref*)> <!ELEMENT results (pinref*)> <!ELEMENT actionflow (arguments, results, actions, dataflows, controlflows, executionflows, documentation?, taggedvalue*)> <!ATTLIST actionflow id ID #IMPLIED > ]>   <actionflow id="identifier of Flow"> <arguments> <pinref action="" pin="reftoPin"> </arguments> <results> <pinref action="" pin="reftoPin"> </results> <actions>

44

<action code="org.xxx.className" id="" readonly=""> <inpin name="" multiplicity="" ordering=""> <classifier type="java"> java.lang.Integer </classifier> </inpin> <outpin name="" multiplicity="" ordering=""> </outpin> <inport> <porthandler code="className"> config </porthandler> </inport> <outport name=""> <porthandler code="className"> config </porthandler> </outport> <exceptionport name=""> <porthandler code="className"> config </porthandler> </exceptionport> <documentation> text text... </documentation> <taggedvalue name="nameOfTag"> value </taggedvalue> </action> <groupaction mustIsolate ="boolean" id="actionID> <variables> <variable name="" > <classifier type="java"> java.lang.Integer </classifier> <value>value</value> </variable> </variables> <subactions> <action> </action> </subactions> <documentation> text text... </documentation> <taggedvalue name="nameOfTag"> value </taggedvalue> </groupaction> </actions> <dataflows> <dataflow sourceaction="actionID" sourcepin="pinName" destinationaction ="" destinationpin =""> <documentation> text text... </documentation> <taggedvalue name="nameOfTag"> value </taggedvalue> </dataflow> </dataflows> <controlflows> <controlflow from="actionID" to="actionID"> <documentation> text text... </documentation> <taggedvalue name="nameOfTag"> value </taggedvalue>

45

</controlflow> </controlflows> <executionflow> <binding id="" type="start|end|forward"> <fromaction name="actionName" outport="nameOfPort"/> <toaction name="actionName"/> <handler code="className"> configInfo </handler> <documentation> text text... </documentation> <taggedvalue name="nameOfTag"> value </taggedvalue> </binding> </executionflow> </actionflow>

46

A.2 Time plan

Week Phase Activities Deliverables Date

1 Start up and analysis

§ Literature studies § Write time plan § Write detailed project

plan

§ Detailed Project plan

2002-02-25 -

2002-03-03

2-3 Analysis § Use cases

§ Test strategy § Analysis report § Framework

evaluation plan

2002-03-04 -

2002-03-17

4-6 Framework design

§ Specification and time plan § Framework (MIDE)

UML § Framework

document

2002-03-18 -

2002-04-07

7-9 Framework implementation

§ Framework (MIDE) GUI § Update framework

document

2002-04-08 -

2002-04-28

10 Analysis and Design for the testing module

§ Framework design review

2002-04-29 -

2002-05-05

11-12 Implementation and evaluation for the testing module

§ The testing module for MIDE § Update framework

document

2002-05-06 -

2002-05-19

13 Analysis and design for the debugging module

§ Framework design review

2002-05-20 -

2002-05-26

14-15 Implementation and evaluation for the debugging module

§ The debugging module for MIDE § Update framework

document

2002-05-27 -

2002-06-09

16-17 Testing and evaluate MIDE

§ Execute framework evaluation plan

§ Quality control

2002-06-10 -

2002-06-23

18-20 Final report

§ Finish framework document

§ Minor bug fixing § Clean-up

§ Final Report

2002-06-24 -

2002-07-14

47

A.3 Example of a MIDE Xml-document <?xml version="1.0"?> <!DOCTYPE af:actionflow SYSTEM "test0517_actionflow.dtd"> <af:actionflow af:id="flowid" xmlns:af="http://www.toolsmiths.se/namespaces/actionflow"> <af:results/> <af:arguments/> <af:actions> <af:action af:name="action1" af:id="actionid1"> <af:inpin af:name="inpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:inpin> <af:outpin af:name="outpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:outpin> <af:inport> <af:porthandler>config</af:porthandler> </af:inport> <af:outport af:name="outport1"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport2"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport3"> <af:porthandler>config</af:porthandler> </af:outport> <af:exceptionport af:name="exceptionport1"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:exceptionport af:name="exceptionport2"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:documentation>documentation about action 1</af:documentation> <af:taggedvalue af:name="posX">68</af:taggedvalue> <af:taggedvalue af:name="posY">104</af:taggedvalue> </af:action> <af:action af:name="action2" af:id="actionid2"> <af:inpin af:name="inpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:inpin> <af:outpin af:name="outpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier>

48

</af:outpin> <af:inport> <af:porthandler>config</af:porthandler> </af:inport> <af:outport af:name="outport1"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport2"> <af:porthandler>config</af:porthandler> </af:outport> <af:exceptionport af:name="exceptionport1"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:exceptionport af:name="exceptionport2"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:documentation>documentation about action 2</af:documentation> <af:taggedvalue af:name="posX">287</af:taggedvalue> <af:taggedvalue af:name="posY">108</af:taggedvalue> </af:action> <af:action af:name="action3" af:id="actionid3"> <af:inpin af:name="inpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:inpin> <af:outpin af:name="outpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:outpin> <af:inport> <af:porthandler>config</af:porthandler> </af:inport> <af:outport af:name="outport1"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport2"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport3"> <af:porthandler>config</af:porthandler> </af:outport> <af:exceptionport af:name="exceptionport1"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:exceptionport af:name="exceptionport2"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:documentation>documentation about action 1</af:documentation>

49

<af:taggedvalue af:name="posX">275</af:taggedvalue> <af:taggedvalue af:name="posY">247</af:taggedvalue> </af:action> <af:action af:name="action4" af:id="actionid4"> <af:inpin af:name="inpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:inpin> <af:outpin af:name="outpin1" af:multiplicity="mult"> <af:classifier af:type="java">class java.lang.String</af:classifier> </af:outpin> <af:inport> <af:porthandler>config</af:porthandler> </af:inport> <af:outport af:name="outport1"> <af:porthandler>config</af:porthandler> </af:outport> <af:outport af:name="outport2"> <af:porthandler>config</af:porthandler> </af:outport> <af:exceptionport af:name="exceptionport1"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:exceptionport af:name="exceptionport2"> <af:porthandler>config</af:porthandler> </af:exceptionport> <af:documentation>documentation about action 1</af:documentation> <af:taggedvalue af:name="posX">426</af:taggedvalue> <af:taggedvalue af:name="posY">117</af:taggedvalue> </af:action> </af:actions> <af:dataflows> <af:dataflow af:sourceaction="action1" af:sourceactionid="actionid1" af:sourcepin="outpin1" af:destinationaction="action2" af:destinationactionid="actionid2"> <af:documentation>dataflowdocumentation</af:documentation> <af:taggedvalue af:name="nameOfTag">value</af:taggedvalue> </af:dataflow> </af:dataflows> <af:controlflows> <af:controlflow af:from="action1" af:fromid="actionid1" af:to="action2" af:toid="actionid2"/> </af:controlflows> <af:executionflow> <af:binding af:id="bindid1" af:type="forward">

50

<af:fromaction af:name="action1" af:id="actionid1" af:outport="outport2"/> <af:toaction af:name="action2" af:id="actionid2"/> <af:handler af:code="class org.openebxml.mide.framework.definitions.logic.impl.ClassifierDefinitionImpl">configInf</af:handler> <af:documentation>binding between action1 and action2</af:documentation> </af:binding> <af:binding af:id="bindid2" af:type="forward"> <af:fromaction af:name="action1" af:id="actionid1" af:outport="outport1"/> <af:toaction af:name="action3" af:id="actionid3"/> <af:handler af:code="class org.openebxml.mide.framework.definitions.logic.impl.ClassifierDefinitionImpl">configInf </af:handler> <af:documentation>binding between action2 and action3</af:documentation> </af:binding> <af:binding af:id="bindid3" af:type="forward"> <af:fromaction af:name="action2" af:id="actionid2" af:outport="outport1"/> <af:toaction af:name="action4" af:id="actionid4"/> <af:handler af:code="class org.openebxml.mide.framework.definitions.logic.impl.ClassifierDefinitionImpl">configInf</af:handler> <af:documentation>binding between action2 and action4</af:documentation> </af:binding> </af:executionflow> <af:documentation>documentation about the actionflow</af:documentation> <af:taggedvalue af:name="posX">500</af:taggedvalue> <af:taggedvalue af:name="posY">100</af:taggedvalue> </af:actionflow>

51

A.4 The figures in MIDE In figure 12 all of the figures and connections in MIDE are presented, it is in fact an Actionflow with a controlflow, dataflow and an executionorder between two actions. The aggregate figure below the flowmodel is a way to present aggregated actions.

Figure 12 The figures in MIDE.

Microflow Integrated Development Environment - … for a Microflow Integrated Development...

Documents

Transcript of Microflow Integrated Development Environment - … for a Microflow Integrated Development...