School of computer science and informatics, cardiff university

Download 174.27 Kb.

Page	6/14
Date	06.08.2017
Size	174.27 Kb.
	#28007

1 2 3 4 5 6 7 8 9 ... 14

Schedule of Experiment

With a limited amount of time to carry out this experiment, it was important to draw up a schedule of tasks and goals to ensure sufficient progress, as well as having some contingency time available if the thesis is delayed in some way, such as more time spent on software development. The following schedule includes approximate lengths of time that are estimated to be required.

Conduct research on both object-oriented and aspect-oriented paradigms, through relevant and appropriate sources (approximately 3 weeks)
Design and implement the Java system of the code, adhering to the rules stated previously (approx. 3 weeks)
Analyse the resulting program, and identify any crosscutting concerns which can be re-implemented using AspectJ techniques
Taking the identified concerns, design and implement the AspectJ system (approx. 4 weeks)
Compare the two paradigms through use of research literature, measuring runtime and length of code implemented, measuring comprehension using a survey (see below), and making comments on the design process and any limitations or difficulties. (approx. 2 weeks)
Report on the findings within the thesis. (approx. 3-4 weeks)

Surveying

When analysing aspect-oriented programming, it is important to gauge the opinions of others in areas which are more difficult to analyse myself. When working in software development, it is important to be able to read the code of another programmer and to understand the purpose of classes and methods, as well as their behaviour. A survey was written for this purpose, based on the code written.

Since aspect-oriented programming is not widely used, or indeed widely taught, it would have been difficult to carry out this survey assuming that the responders would have experience in using languages like AspectJ. Instead of looking at the actual coding process, the questionnaire is based on the concepts of readability and comprehension. This requires some background knowledge, and so an appendix was included in the questionnaire to introduce the key concepts and ideas behind the paradigm, and some information on the syntax used for aspects, using some of the sources read during the research period. This appendix was based on the background section of this report. The only assumption made for the questionnaire was that anyone wishing to respond to it would need experience using Java and object-oriented concepts, otherwise it would have been difficult to reach an effective comparison.

Once the responders are introduced to the concepts, they would be asked a series of questions looking at the syntax of AspectJ, and their ability to comprehend the control flow during both Java and AspectJ versions. In addition, questions were added to assess the experience of the user when comprehending functionality in both versions, their opinions of the paradigm before and after the practical questions, and the benefits and drawbacks they feel exist. The questionnaire is included as an appendix.

Testing

In their assessment of aspect-oriented programming, Grevoka et al [11] and Alexander [1] both cite testing as an emerging concept as there is still a lack of information due to the aspect-oriented paradigm not having as much real-world experience to draw an efficient testing policy, and state that existing testing principles are “tailored for OO programming” [11]. Because of it, it felt important to define a testing plan that could be achieved within the available timeframe as part of the methodology.

The standard testing techniques of unit, integration and regression testing are all designed for object-oriented programming, and should be used for this methodology due to their consistent use otherwise the comparison would not be balanced fairly so that both paradigms involved are shown to the best of their abilities. The most sensible approach is to develop each requirement separately, and then combine them over time to identify potential bugs. However, testing of a GUI is not suited to unit testing, especially when using the Model-View-Controller pattern which ensures the logic behind action is kept apart from the interface. When it comes to testing the interface, a test plan including a test for each potential user action, listed with an intended result, achieves the same standard of results as using unit testing as part of the development environment.

Since the base code for an aspect-oriented approach is coming from the Java system, and that that system would be developed first, the focus on AspectJ testing could deal solely with the aspect being implemented. As these have not be identified as part of this methodology, the testing process has to be defined at an abstract level. Aspects can be considered as a unit due to its similarity to classes, but rather than testing functionality, aspect testing is concerned with the pointcut(s) advising the correct points in execution, and that the advice is used in the correct way.

Relational Database

Without a functioning database, neither version of the system will function correctly. Some sort of persistent storage was required, and this section briefly discusses the database model used. As mentioned in the best practice section, a relational database model was chosen. This particular model was chosen because of its requirement of primary keys, which uniquely identify a particular row, making querying the database much simpler as these can be referred to by other tables in the form of foreign keys, as well as its tendency to match the real world through the use of relationships and cardinality. A file-based system could have been used instead, although there would potentially be issues³ with storage space, not so much with this program but certainly with those of a higher scale. The use of a relational database also reduces data redundancy [32], something which could be difficult if a file-based system had multiple file formats, as well as the fact it is centralised, whilst a file-based system would most likely be stored in separate workstations, making concurrent use of data difficult.

In accordance with the best practice criteria, the tables used were assigned according to the different types of data stored, such as separate tables for customers, staff, accounts and transactions. In addition, to save on redundant data, some attributes reference other tables by an integer value, referring to; for example, the types of account available are listed in a separate table. A full diagram of the finished database can be found in Appendix C.

Directory: PATS2
PATS2 -> Microsoft Azure Services

Download 174.27 Kb.

Share with your friends:

1 2 3 4 5 6 7 8 9 ... 14