In het stuk ‘Het verkeerde beeld van politieke correctheid’ tracht Francisco van Jole een aantal kritiekpunten op ons boek ‘Over politieke correctheid’ te formuleren. Kritiek achten we mooi meegenomen, dat is immers goed voor het debat. Toch vinden we een aantal kritiekpunten onterecht. De manier waarop stelling genomen wordt is een casein-point met betrekking tot hoe onderwerpen snel worden herleid tot ‘foute’ meningen, gekoppeld aan de identiteit van auteurs, iets waar we in ons boek juist uitgebreid op ingaan. https://joop.bnnvara.nl/opinies/politiek-incorrect-of-juist-te-politiek-correct LinkedIn: https://www.linkedin.com/in/gertjangeling/ https://www.linkedin.com/in/gerben-bakker-50148818/
Most object-oriented (OO) practitioners recognize the value of Design by Contract as a methodology for improving software quality. It is at the heart of the Eiffel language and of the Object Constraint Language (OCL) of UML. However, there are precious few languages that provide such intrinsic support for Design by Contract, and C++ is one language that does not. This article presents two new mechanisms for emulating Design by Contract in C++ that take advantage of language features defined in the recent standard, and for which widespread compiler support is now becoming available. One mechanism has been used in the development of software components in Computational Physics and is based on the Standard Template Library (STL); the other provides Design by Contract support across an inheritance hierarchy in C++ in accordance with the Liskov Substitutability Principle(LSP).(1)
An accumulating body of evidence strongly indicates a local tissue renin-angiotensin system in the pancreas of a various species. In contrast to the majority of tissues that primarily express the angiotensin type 1 (AT1) receptor, the pancreas is one of the few tissues that contain a significant proportion of the AT2 subtype. Moreover, our findings indicate a greater distribution angiotensin II binding sites in the exocrine pancreas. Although the physiological aspects of a local pancreatic renin-angiotensin system remain largely unexplored, recent studies in our laboratory utilizing an acinar cell model demonstrate both functional AT1 and AT2 receptors. Indeed, we show that the AR42J cell line expresses all components of an angiotensin system including the mRNA for renin, angiotensinogen, angiotensin converting enzyme (ACE), AT1a, AT1b and AT2 receptors. Thus, these cells may be of particular value to study the interplay of the AT1 and AT2 receptors to regulate cell growth and potentially exocrine function.
SmallEiffel, a highly successful open-source implementation of Eiffel developed under the direction of Dominique Colnet at LORIA in France, uses a number of particularly original and innovative compilation techniques. In this article Colnet and his colleague Olivier Zendra raise the veil and show how they have taken advantage of global system analysis techniques to achieve a high degree of performance in the SmallEiffel compilation process and the resulting code.
The achievement of efficient implementations Is still considered an open problem in the distributed object-oriented programming languages field. In this article, we present an approach to implement distributed objects in a reasonable, efficient way. This approach is based on the use of a protocol that allows objects to be migrated and replicated. The basic idea is to reduce the overhead of remote invocations among objects by making them local. The effectiveness of our scheme requires a strict programming model, in which object invocations must be enclosed between pairs of acquire and release operations, and operations are classified in commands or queries. Details of a thread-based implementation are presented. Experiments with a parallel matrix multiply program and a parallel branch and bound program, executed in three different architectures, demonstrate that significant speedups can be obtained.
In last month’s edition of JOOP we started a series of columns discussing the problems with teaching object-oriented programming to first year students. We talked about requirements for an object-oriented teaching language and analysed how close different languages come to fulfil these requirements. We also mentioned one important aspect: the importance of the environment. In short: a suitable programming environment is crucial for the success of an introductory course. Of all the problems reported by educators connected to teaching object-orientation, problems with the environment used were the most frequent and the most severe. Because of this importance, we devote this month’s column to the discussion of environments. Again, the context we focus on is the suitability of environments for first-year teaching.
Of the recent Eiffel extensions previewed in the last column (Extension Season, June 1999, see http://www.inf.ethz.ch/personal/meyer/publications/joop/extensions.pdf), some are intended to clean up and simplify existing mechanisms, but a few significantly raise the expressive power of the language. The most spectacular of these is agents, a new mechanism for manipulating operations as objects — so important on its own that it deserves a presentation of its own.
classes which form high-level specifications are particularly useful. Students inspect the specification for a non-implementable, abstract class like reproducible in order to determine which behaviours to implement in the specialized classes below. Here again, assertions provide the semantic richness which fleshes out the specification. The ISE Eiffel4 EiffelBench development environment, although idiosyncratic by Microsoft Windows standards, is affordable, and the same source will compile and run on a full range of Unix and Windows platforms. The Project SimOcean The major part of the practical component is centred on a programming project. We are indebted to Richard Wiener for the initial design, SimOcean, which he developed both in C++ and Eiffel [5]. The project is initially presented to students as a complete, running, although rudimentary system. Figure 1 shows the overall structure of the system as produced by ISE’s EiffelCase tool. SimOcean is extremely successful as a student project for a number of reasons. As shown in the figure, the system is structured so that the classes divide naturally into subsystems: the application cluster, comprising the simulation, ocean and location classes; the marine cluster which defines the hierarchy of ocean creatures performing in the simulation; the timing framework, which manages the activation of the ocean creatures; and a small library cluster of utility classes such as random and based_counter. The Ocean is essentially a twodimensional array, wrapped, containing locations which in turn may contain a marine object. Depending on their type, marine creatures can possess the ability to move, reproduce, predate on other creatures, starve and die. The marine hierarchy provides a rich canvas for exploring, understanding and enacting concepts such as abstract specifications (reproducible, predator) for class specialization (adding new marine creatures), and for discovering commonality, generalizing abstractions up the inheritance hierarchy. The timing cluster is a true framework, and is an excellent pedagogical tool for reinforcing many of the software engineering lessons associated with design by contract. Students used to scanning the complete code of a class in order to understand how to use it are initially annoyed that they are expected to use such seemingly complex abstractions as linked_priority_queue without a word of explanation. It takes some time to sink in that the entire timing subsystem is encapsulated from the user’s perspective, with only one routine in class timeable needing to be ‘effected’ in order to make use of the whole framework! We have actually found it more effective to introduce the topic of framework reuse after the students have been through this process. Here too Eiffel proved its value: students find it easy to maintain a “system” view of the software. It is very easy to move to and from a graphical view of the static software architecture and the textual notation, the classes encoded in Eiffel. When the system must be modified, we find that students discover commonality in classes and abstract code upwards in the inheritance hierarchy quite naturally, not hindered by problems such as those associated with virtual classes in C++. The fact that they do so, so readily without prompting, is further evidence of the structural view facilitated by the Eiffel notation.
There is general consensus in the software literature that real-time systems are difficult to model, specify, and design. It is an important and challenging task to develop an intuitive and easyto-use, yet coherent and concise method for specifying such systems. The Object-Process Methodology (OPM) graphically specifies systems in a single unified model that describes the staticstructural and behavioral-procedural aspects of a system by a set of Object-Process Diagrams. In this research paper we present OPM/T, as an extension of OPM for specification of reactive and real-time systems. A detailed telephone call example demonstrates the power of OPM/T to express such notions as timing constraints, events, conditions, exceptions, and control flow constructs. Pertinent Subjects analysis and design methods, real-time systems, design patterns.
Currently, there's a gap in the software development process. On one side is the natural language used to describe customer problems and requirements. On the other side lie the formal languages used for analysis, design and programming. This article describes techniques for bridging the gap by transforming natural language into rhetoric suitable for conceptual modeling.
