ABSTRACT:
By the increasing needs of software industry, software systems became more complex constructions than ever before. As a result of increasing complexity in software systems, functional decomposition of these systems gains the status of the most important aspect in the software development process. Dividing problems to sub-problems and producing specific solutions for divided parts makes it easier to solve the main problem.
Component Based Software Engineering is a way of developing software systems that consists of logically or functionally decomposed components which integrated to each other by the help of well-defined interfaces. CBSE relies on architectural design of a software system.
Planning phase and implementation of a software project may differ time to time. Because of the complexity of software systems, solving specific problems may affect the architecture of the whole system. Inspite of sophisticated software engineering processes and CASE tools there is still a large gap between the planned and implemented architecture of software systems. Finding deviations from architecture in source code is a non-trivial task requiring tool support.
Since, matching operation of designed software architecture and implemented software architecture needs to check design documents against implementation code. This manual checking operation is nearly impossible for major software systems. Software Architecture Checker provides a great approach to check the architecture of any software system. This bachelor thesis examines the approach behind the Software Architecture Checker.
REQUIREMENTS
This section presents information about Software Architecture Checker’s requirements. First of all we will give information about the actors that will use the planned software system. Later on we will discuss Use-Case Model and present Use-Case. We will conclude this section with a presentation of the functional requirements of the Software Architecture Checker.
Actors:
Because of the Software Architecture Checker is a sub-module for VizzAnalyzer, actors of the Software Architecture Checker and VizzAnalyzer exactly match each other. As already defined by there are two different actors for this system: The first actor of this system will be end-user who is intended to be experienced in analysis and design of a software project. Generally Software Architects, Software Analysts, Software Designer or Project Managers could fit in end-user actor group.
Features:
This section describes the features of the Software Architecture Checker. These features that can be seen are derived from the problem domain analysis and will help to define the requirements of the software system.
Use Cases:
This Section describes Use-Cases of the Software Architecture Checker. For better understanding of Use-Cases, we will clarify the Use-Case model first and later on we will describe each Use-Case in detail.
Requirements:
This section provides information about functional requirements of the Software Architecture Checker. There are three types of requirements level: Essential, Desirable and Optional. All these requirements are derived from Use-Case descriptions.
ARCHITECTURE
Software Architecture Checker is going to be a sub module for VizzAnalyzer. Because of this requirement it is very important to design Software Architecture Checker as an Eclipse plug-in which can extend the specification of existing VizzAnalyzer implementation.
Architecture of Eclipse:
Eclipse Rich Client Platform stands on plug-in based extensible architecture. Since Eclipse Integrated Development Environment is also a specified set of specialized plugins over Eclipse RCP. Eclipse supplies several extension points to implement such extensible architecture. New tools or plugins like JDT or PDE extends platform over these extension points.
The Eclipse Architecture.
Plug In Model Of Eclipse:
Eclipse architecture supports plug-ins that can be easily integrated. The “plugins” folder inside the Eclipse installation directory contains the needed information to integrate plug-ins.
Plug-ins that work on Eclipse platform may also interact with each other. Each plug-in is defined by a manifest file that is called “plugin.xml”. The Eclipse platform activates and integrates all plug-ins in “plugins” directory with the help of this manifest file.
Architecture of Software Architecture Checker:
The Software Architecture Checker consists of different components. In that way it is possible to use Software Architecture Checker either as an API or application.
DESIGN AND IMPLEMENTATION
In the previous section we described the architecture of Software Architecture Checker. This section covers the design and implementation of Software Architecture Checker. First of all, we will look at the class diagram of the Software Architecture Checker. After describing the class diagram and design aspects we will continue with describing implementation of this System.
Class Diagram
The Configuration component consists of:
- Configuration
- ComponentsModel
- Component
- RulesModel
- Rule Classes
The Analyzer core component is AnalyzerCore class;
The Eclipse plug-in UI component consists of:
- Architecture Checker Handler
- Architecture Checker Wizard
- Component Definition WizardPage
- Rule Definiton Wizard Page Classes;
IMPLEMENTATION OF SOFTWARE ARCHITECTURE CHECKER
Previously we have seen the design model of Software Architecture Checker. This section provides information about implementing the Software Architecture Checker. We will give information about how did we use extension points of Eclipse and how did we configured plug-in entry points.
Plugin.xml:
As we already described in chapter four, Eclipse plug-ins stored in “plugins” directory of Eclipse installation path and configured through plugin.xml file.
Package Structure of Software Architecture Checker:
Implementation of Software Architecture Checker consists of several different packages. These packages created through functional decomposition of software Architecture Checker. In other words each component of designed system relies on its own package.
CONCLUSION
In this thesis, we described a methodology to define software components and their intercommunication. This methodology is used to develop an approach in solving the problem.
As stated before in first chapter, the problem was design and implementation of an Eclipse plug-in to define and check the architecture of a software system. Since definition support for software components and interfaces is not supplied by any programming languages, including java, it is a non-trivial job. Solving this problem was quite important because architecture of a software system is not easily controllable in manual ways.
Design documents like class diagrams, sequence diagrams and implementation code of program should be checked against each other. Manual checking operation is not possible especially for big projects. VizzAnalyzer has developed an approach for call-operations of the software system.
Our component and rule definition approach is used together with VizzAnalyzer’s call operation approach to check the implemented software architecture is as designed or not. To solve the problem we discussed goals and criteria before.
The first goal was defining the components of software system. This goal has been met by abstraction of a software component to the Component class and second wizard page of user interface. Component Definition Wizard Page class provides a user interface to define a software component.
Second goal was defining sub-components for components. This goal has been met by parent-child associati on between instances of Component class and component definition user interface.
The third goal was mapping defined components to the implementation of the software system. A software component is expected to consist of several classes. This goal is met by regular expression field of a component. Those classes can be defined by regular expressions.
The fourth goal is defining rules between already defined components. This goal is met by Rule Definiton Wizard Page class which provides user interface to define rules between already defined components. And rules are derived from call-operations which are supplied by VizzAnalyzer framework.
The fifth goal was reporting violations of the given software system through given component and rule definition. This goal has been met by reporting abilities of Software Architecture Checker. Violations can be reported both in XML and raw text format.
The sixth goal was grouping the defined components in the graph file supported by VizzAnalyzer. Also a modified call-graph, which contains parameters of components and violations, is generated and met this goal. Since all goals are met clearly we can result that the problem is successfully solved.
Personally it was a great experience for me to solve this problem. I learned a lot of things about Eclipse and plug-in architecture. I studied various approaches for software architecture and importance of software architecture. Iam sure that I will use this experience in my future studies or works. On the other hand, since Software Architecture Checker will be a part of VizzAnalyzer, it is very motivating to be able to participate in development of VizzAnalyzer.
FUTURE WORK
The implementation of Software Architecture Checker is successfully met all goals and criteria but some more optional requirements appeared during the development phase. It would be better if Software Architecture Checker could present an import/export mechanism for defined component and also for defined rules.
Since it can remember the configuration between different sessions but if Eclipse exits these configurations also get lost. On the other hand documentation of the implemented System should be done. Both end user and developer need some documentation for using the Software Architecture Checker or adding more features.
Source: Vaxjo University
Author: Yasin Bahtiyar