Contract Wizard II: Developing a GUI

Transcription

1 Contract Wizard II: Developing a GUI PROJECT PLAN Diploma project Project period Student name Petra Marty Status 9 th semester address martypet@student.ethz.ch Supervisor name Karine Arnout

2 1. PROJECT DESCRIPTION Overview When thinking of new software development methods and tools, many people tend to view productivity as the major expected benefit. In object technology and especially in Eiffel, productivity benefits follow not just from the immediate benefits of the approach but from its emphasis on quality. [2] To be sure that our object-oriented software will perform properly, we need a systematic approach to specifying and implementing object-oriented software elements and their relations in a software system. Under the Design by Contract theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations and benefits that are involved in those communications. The specifications are called contracts. [3] Regrettably Design by Contract is still a specificity of the Eiffel programming language. It is not directly supported in most programming languages based on.net. With the Contract Wizard II tool it is possible to add contracts like preconditions, postconditions and invariants to an arbitrary.net assembly, even if it was not written in Eiffel. The contracted assemblies will contribute developing better quality software. Scope of the work Dominik Wotruba developed in his diploma thesis the business logic of the Contract Wizard II tool. [4] The existing work includes among other things: a parser to parse a.net assembly or XML files to produce an abstract syntax tree (ADT) a code generator for generating XML files where the contracts are stored and for generating Eiffel proxy classes with contracts a simple command line user interface for adding contracts The main work of my diploma thesis is to implement a GUI (Graphical User Interface) for the Contract Wizard II. Currently the contracts are added to an assembly through a command line user interface which is not user-friendly. I will also briefly discuss the possibility of adding Design by Contract support into the CLI (Common Language Infrastructure). [6] Intended results The idea is to have a usable product in the end, meaning usable by end-users. It is meant to provide the widest range of people with the power of Design by Contract. Therefore it is important to design a user-friendly and intuitive graphical user interface together with an understandable and helpful documentation. 1

3 The work consists of the following parts: Implementation GUI Test cases A graphical user interface will be implemented, allowing the user to add contracts to an arbitrary.net assembly, providing help where necessary. The GUI will be built with the EiffelVision2 library provided by ISE Eiffel. The functionality of the GUI and the Contract Wizard II in general will be shown with the bank account application, included in [4]. Furthermore the Contract Wizard II will be tested on the.net library 'mscorlib.dll' and if possible on other.net libraries. Documentation Developer manual User manual Thesis report The developer manual documents the software architecture, main classes and limitations of the tool. It describes the difficulties encountered during the implementation and explains how to extend the current version. The user manual describes how to use the Contract Wizard. The thesis report consists of the final developer manual, the final user manual and a theoretical part about adding Design by Contract support into the CLI. 2. BACKGROUND MATERIAL Reading list Chapters in OOSC2 [2] in particular: o Chapter 1: Software quality o Chapter 11: Design by Contract: building reliable software o Chapter 23: Principles of class design o Chapter 26: A sense of style o Chapter 28: The software construction process The.NET Contract Wizard [5] Software Source code of Contract Wizard II [4] 2

4 3. PROJECT MANAGEMENT Objectives and priorities Objective Priority* Software architecture 1 GUI 1 Test cases 2 Optimization 3 Developer manual 2 User manual 2 Thesis report 1 * 1 means highest priority, 3 means lowest priority Criteria for success The goal of the project is a usable GUI, the criteria for success is the quality of the software and the documentation. The result may be a partial implementation of the objectives without implying any penalty on the success of the project. Quality of software: Use of Design by Contract o Routine pre- and post conditions o Class invariants o Loop variants and invariants Careful design o Design patterns o Extendibility o Reusability o Careful abstraction Core principles of OOSC2 [2] o Command / query separation o Simple interfaces o Uniform access o Information hiding o etc. Style guidelines Correct and robust code Readability of source code Ease of use Quality of documentation: Completeness Understandable documentation Usefulness Structure 3

5 Method of work The technologies involved are: ISE EiffelBuild is used for a first construction of the GUI ISE EiffelStudio 5.4 is used for an accurate implementation Programming language: Eiffel [3] Quality management Quality will be ensured by: Weekly progress reports sent to the supervisor, if necessary a meeting with the supervisor will take place. Detailed progress report for each milestone Review of each milestone by the supervisor concluded by a meeting Validation of each milestone after review (see validation steps below) Testing of the software by application of different test cases Documentation (see documentation below) Documentation Progress reports o Short weekly progress reports consisting of the main task completed o Detailed reports for each milestone consisting of: The main tasks Eventual encountered difficulties Implementation, scope of the implementation Developer report: This manual documents the software architecture and its limitations, describes the difficulties encountered during the implementation, explains how the software could be extended and contains a section discussing the test cases. User manual: The user manual describes the usage of the tool Contract Wizard II Thesis report: The thesis report consists of the final developer manual, the final user manual and a theoretical part discussing adding Design by Contract support into the CLI Validation steps The validation of each milestone comprises: Report: Sending a detailed report and the relevant parts of the work to the supervisor for review Meeting: Organizing a meeting with the supervisor for presentation and discussion of the conducted work Revision: Revising parts or all of the work for this milestone, depending on the conclusion of the supervisor 4

6 4. PLAN WITH MILESTONES Project steps Milestone M1 M2 M3 M4 M5 M6 Objective Basic design of the software architecture. Further design will be done incrementally. Implementation of the GUI Test cases on.net assemblies Developer manual User manual Thesis report Deadline Milestone Deadline M1 07-May-2004 M2 09-Jul-2004 M3: 23-Jul-2004 M4 13-Aug-2004 M5 20-Aug-2004 M6 20-Aug

7 Tentative schedule Start End 26-Apr May May May May May Jun Jun Jun Jun Jul Jul Jul Jul Aug Aug Aug Aug Aug Sep-2004 Task Diploma Project Presentation P1: Intermediary presentation P1 P2: Final presentation P2 Design M1: Software architecture M1 Implementation M2: GUI M2 Testing M3: Testing on.net assemblies M3 Optimizations Documentation M4: Developer manual M4 M5: User manual M5 M6: Thesis report M6 After having designed the basic software architecture, it may be possible that the GUI implementation will be divided into sub-milestones. 6

8 REFERENCES [1] Chair of Software Engineering: Semester-/Diplomarbeiten; Online at: consulted in April [2] Bertrand Meyer: Object-Oriented Software Construction, 2nd edition, Prentice Hall, [3] Eiffel Software, consulted in April [4] Dominik Wotruba, Contract Wizard II, consulted in April 2004 [5] Karine Arnout and Raphaël Simon: The.NET Contract Wizard: Adding Design by Contract to languages other than Eiffel, IEEE Computer Society, TOOLS 39, Santa Barbara, USA, July 2001, p [6] N. Tran, C. Mingins and D. Abramson: Design and implementation of assertions for the common language infrastructure, IEE Proc.-Softw.,Vol.150, No.5, October 2003, p