OO Summary (Homework 9-11)
【History & Significance of Specification Language】
In the last 40 years, a large number of sepcification language have been proposed for the software system. In the short time since 1998, at least 19 object-oriented methods have been proposed in book form and many more have been propsed in conference and journal papers.[1] Defining specifications of the method may help reduce software errrors and improve correctness of programs. In object-oriented programs, better specification methods are in great need, such as abstract variables, state abstraction, heap, inspector methods, since methods may influence each other.[2]
C. A. R. Hoare[3] proposed a specification method based on the connection between a precondition, a program, and a description of the result of its execution. Hoare's method helped laid a foundation for the development of specification and provided theoretical basis for interface in a class. Since software system is getting more complicated, method provided by Hoare needs improvement to adapt to great extension on scale and function. One of the key points of improving Hoare's method is to apply formational specification to classes and employ preconditions and postconditions to describe each function in order to performance behavior of the class.
To build correct specification for class, researchers have tried different aspects, such as abstract variables, interface specification, abstract state, inspector method, etc., and have made great progress.
J. V. Guttage[4] employed abstract data types to reduce the complexity of design and realization for large scale softwares. B. Meyer[5] propsoed design by contract and continued precise defination of functions. Yoonsik[6] tried to use model method and model variables to solve the problem and built the JML specification method, which avoided the disorder of actual code and abstract sepcification. Some researchers also employed abstract state to define a sepcification of a class, such as D. Hoffman and J. Hatecliff.
These improvements of specification language may assist in the design of better programming languages as well as the self-proof of correctness in each function or class.
【About JSF Bug】
(1) Bug Form
* This form shows the 10th JSF bug. Both the 9th and 11th JSF bug is none.
(2) Reason
The most important reason why I failed to reach True in repOK is that I didn't know how to check its correctness at the first time. After learning how to check it, I rechecked all my repOK function in each class and corrected the errors.
(3) Improvement
* REQUIRES:
/* For Example */
* EFFECTS:
/* For Example */
【About Function Bug】
* From my bug list, the connection between JSF design and correctness of function is not obvious. However, my intuitive feeling is that the more easier to design a specification for a certain function, the less errors the function will have.
【Clue & Reflection on JSF】
While designing specifications for each function, I have always judging the reason why it is important and why it is worthy of a lot of time to write the JSF sepcification.
The most difficult problem I met with JSF is that some functions are too easy to write a specification while the others are too long to write. I suppose this problem would mostly due to the not right habit for writing a specification, since the right way should be design - write JSF - realize function. If carried out in the suggested way, the whole program frame would first come out together with the specification before all codes are finished. The programmer will have a better clue of what to code next and the connection between each function.
JSF can serve as a helpful method to check the correctness of each function. After finishing the code of each function, one can check the "REQUIRES", "MODIFIES", and "EFFECTS" of it in order to analyze whether my function has reached all the requirements or not. It's also more convenient for testers to understand the duty of each function and class in order to better understand the testee's program.
When designing sepcifications, things that I consider are: responsibility or duty of the function or class, the connection between present function and its previous or post functions, the role each function plays in the class, how to describe function in the shortest and the most precise way, etc.
One suggestion about JSF is that if possible, it's better for student to acquire a kind of specification language that is actually used in realife engineering project.
【Something to Share】
In these three projects, I got much less bugs than before and made more friends in the procedure, even though I didn't know who they are! I had quite good communication experience with each testers and testees. Maybe it's because of my luck, however, I have a strong feeling that my skills on how to express myself in a humble and friendly way and how to make others understood myself has improved a lot. Also, it's a very important ability to stand in the others' shoes and consider others' feelings while arguing with each other.
After more than ten projects and tests, I begin to find my own pace on finishing projects and testing others. The first and most important thing is to perfect my own project. A heart with fairness also plays a great role in obtaining pleasure communication experience. The top priority task when learning a course shoulde not be about scores but about how to gain skills and how to better perform in one's future career. Holding this kind of opinion, I enjoyed more during this course and have seen my growth.
【Reference】
[1] Wieringa R. A survey of structured and object-oriented software specification methods and techniques[J]. Acm Computing Surveys, 1998, 30(4):459-527.
[2] 王伟, 丁二玉, 骆斌. 基于抽象状态的类的行为规格化方法[J]. 计算机科学, 2016, 43(s1):457-460.
[3] Hoare C A R. An axiomatic basis for computer programming[J]. Communications of the Acm, 1969, 12(1):53-56.
[4] Guttag J V, Horowitz E, Musser D R. Abstract Data Types and Software Validation[J]. Communication of the ACM, 1978: 21 (1): 1048-1064.
[5] Meyer B. Applying "Design by Contract"[JJ. Computer,1992, 25 (1 0):40-51.
[6] Cheon Y,Leavens G T,Sitaraman M,et al. Model Variables: Cleanly Supporting Abstraction in Design By Contract[J]. Soft ware-practice &'Experience ,2003 ,35 (6) : 583-599.
