To develop distributed applications requires to consider not only functional requirements but also non-functional requirements such as distributions, synchronizations, and scheduling policies. Specifying such non-functional requirements is necessary for supporting on-line capabilities of Autonomous Decentralized Systems (ADS). However, the existing design notations and methods do not address such needs sufficiently enough to develop ADS applications systematically using object-oriented technique. In this paper, we propose an object-oriented design-level support for specifying concurrent, distributed, and autonomous object behaviors in developing dynamic distributed applications. We develop a high-level meta-object protocol called diMOP to deal with object distributions, method synchronizations, and method scheduling policies. In addition, we develop Class Diagram Supporting diMOP (CDSM) and Dynamically Configurable Object Statemachine (DCOS) for specifying non-functional behaviors and dynamic configuration behaviors, by extending the ordinary class diagram and state diagram of UML. A development environment called diMOPer is implemented to support our approach.

Behavioral compatibility between subtypes and supertypes in object-oriented systems is a very important issue to enable the substitution between object types since it supports the extension and evolution of an object oriented system. In other words, the subtype must be guaranteed that it can provide all behaviors (operations) of the supertype for replacing the supertype with the subtype. Invocation consistency checking is one of techniques to verify behavioral compatibility between two object types. The technique confirms weather an object type can accept all sequence of operations of the other object type or not. The classical methods rule checks behavioral compatibility by verifying invocation consistency of two object types. The rule argues that subtypes meet behavioral compatibility with supertypes if the subtypes' preconditions of inherited operations are weakened and postconditions are strengthened. Noting that the classical methods rule is not sufficient for checking behavioral compatibility between objects, we propose an extended methods rule on the basis of the classical methods rule. Based on the proposed extended methods rule, we have implemented a tool, BCCT, to automatically check behavioral compatibility between two objects.