Minimal Model Semantics for Sorted Constraint Representation

Sorted constraint representation is a very useful representation in AI which combines class hierarchies and constraint networks.For such sorted constraint representation,a problem is how to generalize the idea of default inheritance to constraint network,where the attributes in a class or between different classes interact with each other via the network.To give a formal account for the defeasible reasoning in such representation,a general sorted constraint logic is proposed,and a minimal-model semantics for the logic is presented.     

Complexity-Theoretic Hierarchies Induced by Fragments of Gödel’s T

We introduce two hierarchies of unknown ordinal height. The hierarchies are induced by natural fragments of a calculus based on finite types and Gödel’s T, and all the classes in the hierarchies are uniformly defined without referring to explicit bounds. Deterministic complexity classes like logspace, p, pspace, linspace and exp are captured by the hierarchies. Typical subrecursive classes are also captured, e.g. the small relational Grzegorczyk classes ? _* ⁰ , ? _* ¹ and ? _* ² .     

Special issue on out-of-box experience and consumer devices

“Computer equipment is hard to choose, install, maintain, and, especially, operate” (Landauer 1995 In: The trouble with computers: usefulness, usability, and productivity). How many cables did you have to connect (and organise) before the personal office system was properly installed and put into use? How many set-up procedures and agreements did you have to complete before you could access your e-mail with your mobile phone or PDA? Did you lose any documents or applications when you replaced your old computer with a new one? Computers, mobile devices and information technology products are sometimes difficult to put into use because of the several operations required prior to their first use.     

Conceptual entropy and its effect on class hierarchies

All systems that undergo frequent change characteristically tend toward disorder. This is known as entropy and is recognized in all branches of science. Class hierarchies are shared structures which, if useful, undergo frequent change in the form of additional subclassing, modification to existing classes, and sometimes the restructuring of the hierarchy itself. Given this frequent change, we can expect class hierarchies to exhibit entropic tendencies, which we term conceptual entropy. Conceptual entropy is manifested by increasing conceptual inconsistency as we travel down the hierarchy. That is, the deeper the level of the hierarchy, the greater the probability that a subclass will not consistently extend and/or specialize the concept of its superclass. Constructing and maintaining consistent class hierarchies is one of the most difficult activities of object-oriented design. The article describes an automated classification tool that helps minimize conceptual entropy     

Design Strategy

Software designers and managers can find it challenging to agree on the "sweet spots" of their system that warrant their best design efforts. Most projects are short on time, budget, and resources. How can you stay ahead of the design curve, and where should you focus your design energies to gain the most leverage? The essence of strategy is that you must set limits on what you're trying to accomplish.     

Designing for recovery [software design]

How should you design your software to detect, react, and recover from exceptional conditions? If you follow Jim Shore's advice and design with a fail fast attitude, you won't expend any effort recovering from failures. Shore argues that a "patch up and proceed" strategy often obfuscates problems. Shore's simple design solution is to write code that checks for expected values upon entry and returns failure notifications when it can't fulfil its responsibilities. He argues that careful use of assertions allows for early and visible failure, so you can quickly identify and correct problems.     

Year 2000 work comes down to the wire

How much is the year 2000 problem going to cost you? How long is it going to take you to get ready? Can you make it in time? The authors offer some practical advice. They consider how a good project planning and project monitoring tool set will be extremely valuable. Cost estimating tools and models will be very important in answering trade-off questions and keeping a handle on the actual impact of the Y2K remediation effort     

Who ya gonna call! You're on your own [software usability design]

The issue here is not whether discount techniques should be used; they are inevitable. The issue is, in trying to do the best job you can with the ridiculously limited resources provided you, what should you do? How confident should you be in the techniques you are using? A bad design may come back and bite you. When you choose a technique to use in a hurry, you are placing your professional reputation and perhaps your job on the line. You deserve to know four things about any technique that you apply. The hit rate: How many real problems will this technique uncover? The false-alarm rate: How many (and what sorts) of things will it falsely identify as problems (that may not exist, but are costly and time consuming to “fix”)? What does it miss? What types of problems (and how many) does this technique not discover? The correct rejections: How confident are you in your discount technique's ability to flag problems? Discount techniques are not a substitute for the potent combination of analytic and empirical methodologies that usability professionals can bring to bear in designing and evaluating an interface     

Lazy behavioral subtyping

Inheritance combined with late binding allows flexible code reuse but complicates formal reasoning significantly, as a method call’s receiver class is not statically known. This is especially true when programs are incrementally developed by extending class hierarchies. This paper develops a novel method to reason about late bound method calls. In contrast to traditional behavioral subtyping, reverification of method specifications is avoided without restricting method overriding to fully behavior-preserving redefinition. The approach ensures that when analyzing the methods of a class, it suffices to consider that class and its superclasses. Thus, the full class hierarchy is not needed, and incremental reasoning is supported. We formalize this approach as a calculus which lazily imposes context-dependent subtyping constraints on method definitions. The calculus ensures that all method specifications required by late bound calls remain satisfied when new classes extend a class hierarchy. The calculus does not depend on a specific program logic, but the examples in the paper use a Hoare style proof system. We show soundness of the analysis method. The paper finally demonstrates how lazy behavioral subtyping can be combined with interface specifications to produce an incremental and modular reasoning system for object-oriented class hierarchies.     

Incremental reasoning with lazy behavioral subtyping for multiple inheritance

Object-orientation supports code reuse and incremental programming. Multiple inheritance increases the possibilities for code reuse, but complicates the binding of method calls and thereby program analysis. Behavioral subtyping allows program analysis under an open world assumption; i.e., under the assumption that class hierarchies are extensible. However, method redefinition is severely restricted by behavioral subtyping, and multiple inheritance may lead to conflicting restrictions from independently designed superclasses. This paper presents a more liberal approach to incremental reasoning for multiple inheritance under an open world assumption. The approach, based on lazy behavioral subtyping, is well-suited for multiple inheritance, as it incrementally imposes context-dependent behavioral constraints on new subclasses. We first present the approach for a simple language and show how incremental reasoning can be combined with flexible code reuse. Then this language is extended with a hierarchy of interface types which is independent of the class hierarchy. In this setting, flexible code reuse can be combined with modular reasoning about external calls in the sense that each class is analyzed only once. We formalize the approach as a calculus and show soundness for both languages.     

Supporting Roadmapping of Quality Requirements

Would slightly better performance be significantly more valuable from a market perspective? Would significantly better performance be just slightly more expensive to implement? When dealing with performance, usability, reliability, and so on, you often end up in difficult trade-off analysis. You must take into account aspects such as release targets, end-user experience, and business opportunities. At the same time, you must consider what is feasible with the evolving system architecture and the available development resources.Quality requirements are of major importance in the development of systems for software-intensive products. To be successful, a company must find the right balance among competing quality attributes. How should you balance, for example, investments for improved usability of a mobile phone's phone book and better mobile positioning? In the context of quality requirements, decision making typically combines market considerations and design issues in activities such as roadmapping, release planning, and platform scoping. Models that address requirements prioritization in a market-driven context often emphasize functional aspects. (For a comparison of other relevant techniques with Quper, see the sidebar.) Quper provides concepts for reasoning about quality in relation to cost and value and can be used in combination with existing prioritization approaches.     

Abstracts & Commentary

Abstract

Whether you are responsible for ensuring the availability of your enterprise network or you are a chief technology officer or information security manager, you will likely ask yourself these questions: How much should I spend on security? Am I more secure today than I was yesterday? What metrics can I use to measure whether my security is improving or not? When can I stop patching so I can get back to doing real work?     

Efficient Transitive Closure Reasoning in a Combined Class/Part/Containment Hierarchy

Class hierarchies form the backbone of many implemented knowledge representation and reasoning systems. They are used for inheritance, classification and transitive closure reasoning. Part hierarchies are also important in artificial intelligence. Other hierarchies, e.g. containment hierarchies, have received less attention in artificial intelligence. This paper presents an architecture and an implementation of a hierarchy reasoner that integrates a class hierarchy, a part hierarchy, and a containment hierarchy into one structure. In order to make an implemented reasoner useful, it needs to operate at least at speeds comparable to human reasoning. As real-world hierarchies are always large, special techniques need to be used to achieve this. We have developed a set of parallel algorithms and a data representation called maximally reduced tree cover for that purpose. The maximally reduced tree cover is an improvement of a materialized transitive closure representation which has appeared in the literature. Our experiments with a medical vocabulary show that transitive closure reasoning for combined class/part/containment hierarchies in near constant time is possible for a fixed hardware configuration. Received 10 January 2000 / Revised 25 November 2000 / Accepted in revised form 9 February 2001     

Java Native Interface idioms for C++ class hierarchies

The Java^TM Native Interface (JNI) provides a set of mechanisms for implementing Java methods in C or C++. JNI is useful for reusing C and C++ code repositories within Java frameworks. JNI is also useful for real‐time systems, where compiled C/C++ code executes performance‐critical tasks, while Java code executes system control and feature tasks. Available JNI literature concentrates on creating Java proxy classes that allow Java clients to interact with C++ classes. Current JNI literature does not discuss Java proxies for entire C++ inheritance hierarchies; that is the topic of this paper. Our experience in reusing C++ class hierarchies within a Java framework has uncovered a set of useful techniques for constructing Java proxy class hierarchies that mirror their C++ counterparts. This report gives both high level design guidelines and specific programming idioms for constructing Java class hierarchies that serve as proxies for C++ counterparts. We begin by discussing opportunities for reuse within a proxy class hierarchy, as well as problems caused by differences between the Java and C++ approaches to inheritance. The two most significant differences are due to C++ support for invocation of a member function based on the static type of its class, and C++ support for multiple implementation inheritance. Two example C++ class hierarchies provide the basis for a set of sections that present the design guidelines and that codify the programming idioms. This work could serve as the basis for an automatic generator of Java proxy class hierarchies. Copyright © 2000 John Wiley & Sons, Ltd.     

Four ways to improve security

How can you tell if an IT security product (or a product that includes security components) can secure your application? How can you be certain that a product will fully deliver on its claims that it will protect against malice in a deployed environment? Unfortunately, few vendors - and even fewer customers - can make these judgments. The article won't make you a security wizard, but it will give you a feel for what to look for in, and when to be concerned about, a vendor's claims. To ensure that a product has a chance of being secure; customers should check that vendors use adequate approaches in four primary areas. In order of importance (and maturity and availability), they are: quality-control (QC) mechanisms; cryptographic primitives; hardware assist mechanisms; and separation mechanisms.     

Remark on balanced incomplete block designs,near-resolvable block designs,and <Emphasis Type="Italic">q</Emphasis>-ary constant-weight codes

We prove that any balanced incomplete block design B(v, k, 1) generates a nearresolvable balanced incomplete block design NRB(v, k ? 1, k ? 2). We establish a one-to-one correspondence between near-resolvable block designs NRB(v, k ?1, k ?2) and the subclass of nonbinary (optimal, equidistant) constant-weight codes meeting the generalized Johnson bound.     

民族的才是世界的——浅谈传统文化与现代设计

提到北欧国家的产品,也许你会马上联想到简洁和精细,提到日韩的产品,也许你又会联想到精致和唯美,但提到中国的产品,你会联想到什么?你会感觉很难用简单的词来描述。为什么呢?原因就是中国的产品缺乏自己的设计风格。21世纪的市场竞争,是设计的竞争,而设计的竞争背后则是文化的较量,如何深入理解和应用传统文化元素,将传统的中国元素与现代设计合理结合,并为我们的设计增添附加值,值得我们深入研究。     

Thinking in parallel: four steps to Parlog

If you are familiar with Prolog but not with Parlog then this tutorial is aimed at you. In what follows I attempt to:

? explain the basics of Parlog

? demonstrate that Parlog programs can be powerful and elegant

? discuss the relationship of Parlog to Prolog, and

? identify some resources which will take you further.

These are what I call ‘four steps to Parlog’.     

Why is technology transfer so hard?

If you were the vice president of software in a company with 10,000 software personnel, what would you do to make sure your software team had state-of-the-art tools and methodologies? At a more fundamental level, how would you and your staff even find out what they are and whether your current tools and methodologies are good, bad, or average? That is the crux of two major challenges to the software community: How do we evaluate tools and methods for effectiveness? How do we deploy better tools and methods once they have been identified? Unfortunately, the software industry lacks standard measurements and benchmarks for evaluating the effectiveness of programming tools and languages, design approaches, or almost any other kind of technology. Purchasing and acquisition decisions are often made on the basis of unsubstantiated vendor claims. Moreover, once a new tool or methodology is acquired, deployment is often slow. Tools are acquired without considering training needs, or if training is considered, it's not readily available due to schedule pressures