FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W777162> ?p ?o ?g. }

• W777162 abstract "Over the past few years, the notion of building software from components has become popular again. The goal is to produce systems by adapting and linking off-the-shelf modules from a pool of interchangeable components. To turn this idea into reality, the formal descriptions of software components need to specify more than the type signatures of their exported services. At a minimum, they should contain assertions about critical properties of a component’s behavior. By monitoring such behavioral contracts at run-time, language implementations can pinpoint faulty components, and programmers can replace them with different ones. In this paper, we study the notion of behavioral contracts in an object-oriented setting. While the use of behavioral contracts is well-understood in the world of procedural languages, their addition to object-oriented programming languages poses remarkably subtle problems. All existing contract enforcement tools for Java fail to catch flaws in contracts or blame the wrong component for contractual violations. The failures point to a lack of foundational research on behavioral contracts in the OOP world. 1 Components, Contracts, and Classes In 1969, McIlroy [16] proposed the idea of reusable software components. In a market place with reusable components, software manufacturers produce interchangeable software components with well-specified interfaces. Programmers assemble systems from these off-the-shelf components, possibly adapting some with wrapper code or adding a few new ones. When a component fails to live up to its promises, a programmer replaces it with a different one. When a manufacturer improves a component, the programmer can improve the final product by replacing the link to the old component with a link to the new one. To make this component market work, component interfaces should state more than the type signatures of exported and imported items. Ideally, interfaces should specify the entire behavior of a component; realistically, interfaces should at least specify essential aspects of the behavior. The earliest suggestion along those lines came from Parnas [20], who wanted correctness assertions in module interfaces. More recently, Beugnard, Jezequel, Plouzeau, and Watkins [2] proposed that components should come with four levels of interface descriptions: 1. syntactic aspects (type systems, i-o dependencies); 2. behavioral guarantees (weak or strong logical assertions); 3. concurrency guarantees and warnings; 4. quality of service statements. They refer to such rich interfaces as contracts. This paper focuses on behavioral contracts. The usefulness of contracts depends on their enforcement. Unless contracts are verified or monitored, there is no assurance that the software works properly. Hence, it is paramount that contracts have a precise meaning and that the language implementation enforces the meaning of contracts. In particular, contract violations must be pinpointed as precisely as possible, because blaming the wrong component manufacturer (a person, a department, or an external supplier) or providing the wrong explanation for a failure may cause economic damage. Object-oriented programming languages (OOPL) have strongly embraced the notion of components and behavioral contracts. For example, Meyer’s [17] Eiffel explicitly incorporates the notion of “programming by contract.” More precisely, an Eiffel class plays the role of a component. A programmer can express behavioral contracts via logical assertions about the calling context, the return of a method, and as invariants across calls. Eiffel supports these contracts with a run-time monitoring system. If a pre-condition fails, Eiffel blames the caller of the method; if a post-condition fails, it assigns the blame to the method. Recently, several research teams have adapted Eiffel’s notion of “programming by contract” to Java [5, 8, 10, 15]. Unfortunately, unlike contract monitoring tools for procedural languages, none of those for object-oriented languages do not live up to their promises. As it turns out, catching contract violations and assigning blame properly poses subtle problems. More concretely, we believe that the problems of existing tools are due to a lack of foundational work on contracts and contract violations. There is little work on the semantics of behavioral contracts, contract monitoring, and contract violations. In this paper, we present the idea of behavioral contracts for object-oriented languages in general and for Java in particular. Although we study this problem in the context of Java, the issues that we address are common to any component mechanism that includes objects. Then we discuss how the existing contract enforcement tools fail to deal with contracts properly. Finally, we formulate a challenge for the foundational software engineering community, namely, the design of a semantics of contracts and contract violations for behavioral contracts. In the next section we briefly introduce four Java contract tools. In section 3 we look at concrete examples for which the tools fail and analyze why. In section 4, we formulate the contract enforcement problem and discuss several options concerning its solution. Section 5 discusses related work and the last section is a brief summary. 2 Behavioral Contracts in the OOP World In Java, it is natural to argue that behavioral contracts should be associated with Java interfaces. Following Eiffel’s early example [17], contracts should be logical assertions—boolean expressions involving the program’s variables—about methods and classes. More concretely, a programmer can specify pre-conditions and post-conditions on a method.1 Also following Eiffel’s example, the run-time system should monitor the logical assertions about classes and methods. In particular, it should signal the failure of a pre-condition or post-condition. In Eiffel’s case, the system blames the caller of a method when a pre-condition fails, and it blames the method itself when the post-condition fails. Useful contracts are not necessarily complete descriptions of a method’s behavior. Requiring completeness would demand much more logic training for programmers than currently available. Instead, useful contracts often specify just some essential aspects of a method’s behavior. Consider the following example: . . . String get file name(); // The method interactively queries the user for the // name of an existing file. // @post: System.file exists(@ret) The informal constraint expresses the complete behavior of the method in English. The quasi-formal post-condition specifies that the result of the method is a string for which the file exists predicate succeeds. Here is a second example: . . . void click button(Button btn); // The method simulates a user click on the button btn // It is only feasible to click on a button when the button’s // top-level window is visible and has the focus. // @pre: f Window w = System.get top level focus window(); // w.contains(btn) // && btn.is enabled() // && btn.is shown() g 1 Eiffel also allows programmers to specify invariants. We ignore invariants here, because dealing with preand post-conditions poses a sufficiently rich set of problems." @default.
• W777162 created "2016-06-24" @default.
• W777162 creator A5000905628 @default.
• W777162 creator A5053894822 @default.
• W777162 creator A5081388086 @default.
• W777162 date "2001-01-01" @default.
• W777162 modified "2023-09-27" @default.
• W777162 title "Object-oriented Programming Languages Need Well-founded Contracts" @default.
• W777162 cites W13195792 @default.
• W777162 cites W1535444145 @default.
• W777162 cites W1555946950 @default.
• W777162 cites W1577016947 @default.
• W777162 cites W1584704555 @default.
• W777162 cites W1601712140 @default.
• W777162 cites W1605934935 @default.
• W777162 cites W1627776297 @default.
• W777162 cites W1659048632 @default.
• W777162 cites W1783929070 @default.
• W777162 cites W1946281402 @default.
• W777162 cites W1980280740 @default.
• W777162 cites W2015937909 @default.
• W777162 cites W2081814494 @default.
• W777162 cites W2084726176 @default.
• W777162 cites W2105142318 @default.
• W777162 cites W2107995193 @default.
• W777162 cites W2115484804 @default.
• W777162 cites W2165121897 @default.
• W777162 cites W2493901668 @default.
• W777162 cites W590909255 @default.
• W777162 hasPublicationYear "2001" @default.
• W777162 type Work @default.
• W777162 sameAs 777162 @default.
• W777162 citedByCount "4" @default.
• W777162 crossrefType "journal-article" @default.
• W777162 hasAuthorship W777162A5000905628 @default.
• W777162 hasAuthorship W777162A5053894822 @default.
• W777162 hasAuthorship W777162A5081388086 @default.
• W777162 hasConcept C115903868 @default.
• W777162 hasConcept C154945302 @default.
• W777162 hasConcept C199305712 @default.
• W777162 hasConcept C199360897 @default.
• W777162 hasConcept C2781238097 @default.
• W777162 hasConcept C34165917 @default.
• W777162 hasConcept C41008148 @default.
• W777162 hasConcept C73752529 @default.
• W777162 hasConceptScore W777162C115903868 @default.
• W777162 hasConceptScore W777162C154945302 @default.
• W777162 hasConceptScore W777162C199305712 @default.
• W777162 hasConceptScore W777162C199360897 @default.
• W777162 hasConceptScore W777162C2781238097 @default.
• W777162 hasConceptScore W777162C34165917 @default.
• W777162 hasConceptScore W777162C41008148 @default.
• W777162 hasConceptScore W777162C73752529 @default.
• W777162 hasLocation W7771621 @default.
• W777162 hasOpenAccess W777162 @default.
• W777162 hasPrimaryLocation W7771621 @default.
• W777162 hasRelatedWork W1510681389 @default.
• W777162 hasRelatedWork W1523582170 @default.
• W777162 hasRelatedWork W1589047548 @default.
• W777162 hasRelatedWork W1994037692 @default.
• W777162 hasRelatedWork W2035908051 @default.
• W777162 hasRelatedWork W2042769377 @default.
• W777162 hasRelatedWork W2058676784 @default.
• W777162 hasRelatedWork W2061118358 @default.
• W777162 hasRelatedWork W2062692134 @default.
• W777162 hasRelatedWork W2104800879 @default.
• W777162 hasRelatedWork W2109888608 @default.
• W777162 hasRelatedWork W2128986004 @default.
• W777162 hasRelatedWork W2132270811 @default.
• W777162 hasRelatedWork W2133887144 @default.
• W777162 hasRelatedWork W2142097119 @default.
• W777162 hasRelatedWork W2149618060 @default.
• W777162 hasRelatedWork W2154228928 @default.
• W777162 hasRelatedWork W2164439101 @default.
• W777162 hasRelatedWork W2170014513 @default.
• W777162 hasRelatedWork W2500374215 @default.
• W777162 isParatext "false" @default.
• W777162 isRetracted "false" @default.
• W777162 magId "777162" @default.
• W777162 workType "article" @default.