The LaQuSo Repository is a framework that supports the verification and validation of software and is intended to be the heart of the LaQuSo Software Quality Analysis & Design Toolset (SQuADT). All artifacts produced during the life cycle of software system like requirements, specifications, designs, source code, test scripts, etc., can be stored in the repository. The artifacts are expressed using different formalisms like UML, Petri Nets, BPMN, BPEL, mCRL and accordingly different editors e.g. Rational Rose, Enterprise Architect, Yasper, Oracle BPEL Process Manager. Once the artifact has been stored it can be manipulated by two kinds of tools:
- Analysis tools
- Transformation tools
Formalisms, analysis tools and transformation tools that are available at the moment in the LaQuSo repository are listed below.
Formalisms- UML (Class diagram, Message Sequence Chart, State Diagram, Use Case diagram, Activity diagram (AD))
- Petri Net (PN)
- Business Process Modelling Notation (BPMN)
- Business Process Executing Language (BPEL)
- Micro Common Representation Language (mCRL2)
- Woflan (WOrkFLow ANalyzer)
- SAAT (Software Architecture Analysis Tool) / Metric View
- mCRL2 Tool Set
- UML(Activity Diagram) -> Petri Net
- BPMN -> Petri Net
- BPEL -> Petri Net
- Petri Net -> mCRL2
System designs expressed in UML and created by UML editors that can export model to XMI format like Rational Rose, Borland Together and Enterprise Architect can be analyzed with the SAAT Tool. This tool gives metrics that help to assess reusability, extendibility and maintainability. Furthermore, a user can transform activity diagrams of UML to Petri Nets and check the soundness properties of it.
The analysis of business processes is supported by the workflow analyzer Woflan that operates on Petri Nets and checks soundness properties of the workflow. The application of Woflan is extended to other formalisms like BPEL and BPMN by using transformation tools.
In addition, Petri Nets can be transformed to mCRL2 specifications and analyzed by the model checking tool mCRL2 in order to detect deadlocks and all possible paths that lead to it.
There are also a lot of other tools that are considered as possible candidates for the integration with LaQuSo Repository. We especially consider source code analysis tools and tools for automatic test generation. Tools used by our clients can be also taken into account for the integration with the repository.
Via a browser the SQuADT users can access the repository. The repository is tested with the three browsers displayed: Mozilla Firefox, Internet Explorer and Opera. The web pages of the repository are partly implemented with PHP technology and partly with ASP.NET technology.
Models are stored at the file system and some types of models are also parsed into the database. Apart from the models itselves, the structure of the model types, the relation between the structure of the model types and the actual models and the relation between the elements of different models are also stored in the database. Besides these types of model related data the management data is also stored. The management data exist of projects, users, models, model types, tasks, tools, tool servers, some others and relations between them.
The tools can produce reports and perform translations from one model type into another one, and are distributed over different servers that might run at different operating systems. When a user instructs the repository to invoke a tool on a model, the Tool Starter web service is invoked. The tool starter checks at which server the specified tool is located, and instructs the tools server which tool has to be invoked on which model. Because some tools might run for over an hour, this is done in a new thread, so the user can continue doing other things.
At the moment there are two different types of Command Executer web services. One of them is build on ASP.NET technology while the other one is build on Java technology. But because the interface and its functioning is the same, so the other web services that communicate with the Command Executer web services do not even notice the differences. When a Command Executer web service receives a command, it uses the Control web service to check whether this command is a valid command that came from the Repository. The Control web service is also used to report the status of the running tasks.
Because some model files exceed 100MB, a shared folder is used by a Command Executer web service to access the model files and to produce new models and reports. When a tool is finished the Result Processor web service is invoked to process the results.
The Repository Library is a code library containing data definitions, data operations and some other functionality, and is used by the components that are based on .NET technology.