This paper presents an experimental evaluation carried out in an academic environment. The goal of the experiment was to compare how different methods of documenting semantic information affect software reuse. More specifically, the goal was to measure if there were any differences between the methods with regard to the time needed to implement changes to existing software. Four methods of documentation were used; executable contracts, non-executable contracts, Javadoc-style documentation and sequence diagrams. The results indicate that executable contracts demanded more time than the other three methods and that sequence diagrams and Javadoc demanded the least time
This paper presents an experiment designed to compare a contract-based programming method with a standard programming method based on exceptions. The purpose was to evaluate if using contracts would shorten development time, if contracts would improve work satisfaction and if contracts would increase the quality of the resulting software program. The experiment was performed in a project work course for students in the computer science program at Karlstad University. The students were to solve an assignment in groups of four within a period of ten weeks. Half of the groups used the contract-based method and the other half used the exception-based method. We gathered data on time consumption and work satisfaction on daily forms for statistical analysis. The results indicate that there is a gain in the time spent on implementation of the assignment if the contract-based method is used, but no significant difference in total time consumption was found. The results also indicate that the work satisfaction was slightly higher in the groups using the contract-based method. The resulting program was analyzed for a range of quality metrics, but no significant differences were found
This paper presents a case study performed in an industrial project where we introduced and evaluated a method for supporting contract-based program development. The project constructed a large software system and involved around 30 people for 8 months. This paper reports on the designers' and programmers' attitudes towards programming by contract and how they perceived the effect the method had on their work. The results show that the designers and programmers were generally positive to contract-based program development and believed that the quality of their products would improve as an effect of the method
This report describes the study of an industrial software-development project during 1999, as seen from a semantic point of view. The project lasted about 6 months, included about 10 persons, and had a medium level of innovation and a high pace. The study was part of an ongoing research project at the department of computer science. It was performed by a researcher while he was participating as a team member in the project. The objective of the study was to gain a better knowledge of how semantic issues are managed in practice and to identify factors that may limit the possibilities to focus on semantics in a development project of this kind. The research group of the researcher is working on a development method with a focus on semantics, and the experiences will be useful for this work. The semantic modeling done during the project was mostly intuitive, but those parts of the product that were planned semantically had few errors. Design contracts were successfully used in part of the project. Although the project members were not used to working with design contracts, they soon learned to respect them. Lessons about semantics were learned, regarding as well the management, the work and the product. For management, the main lessons were that semantic planning pays off in terms of high development speed and low error rates and that changes in the specifications occurring during development must be managed. For the project work, the main lessons are that time and effort are saved if clear semantic specifications were given before the implementation and that communication between team members about semantics should be managed. In addition, the theoretical result that strong contracts may be weakened was confirmed. For the product, the main lesson is to adapt the semantics of a module to its intended usage pattern.
Due to the distributed nature of the growing field of Component Based Software Engineering (CBSE) and the increasing complexity of modern systems, the semantic aspects of software components must be well specified. In this literature survey, we have investigated how semantic integrity aspects are promoted and managed for components. The importance of semantic aspects and of preserving the semantic integrity is well known and well understood in academia for traditional object-oriented (OO) programming. Although component based programming has many similarities with OO programming, there are certain differences which may cause the semantic integrity to be managed differently. In component-based development, when components are downloaded to be used in systems that may or may not behave well, the responsibilities for the functionality and robustness are not as clear as in traditional programming
When designing a software module or system, a systems engineer must consider and differentiate between how the system responds to external and internal errors. External errors cannot be eliminated and must be tolerated by the system, while the number of internal errors should be minimized and the faults they result in should be detected and removed. This paper presents a development strategy based on design contracts and a case study of an industrial project in which the strategy was successfully applied. The goal of the strategy is to minimize the number of internal errors during the development of a software system while accommodating external errors. A distinction is made between weak and strong contracts. These two types of contracts are applicable to external and internal errors respectively. According to the strategy, strong contracts should be applied initially to promote the correctness of the system. Before release, the contracts governing external interfaces should be weakened and error management of external errors enabled. This transformation of a strong contract to a weak one is harmless to client modules