dc.contributor.advisor | D'Souza, Deepak | |
dc.contributor.author | Gopinathan, Madhu | |
dc.date.accessioned | 2010-12-07T04:41:30Z | |
dc.date.accessioned | 2018-07-31T04:39:59Z | |
dc.date.available | 2010-12-07T04:41:30Z | |
dc.date.available | 2018-07-31T04:39:59Z | |
dc.date.issued | 2010-12-07 | |
dc.date.submitted | 2009 | |
dc.identifier.uri | https://etd.iisc.ac.in/handle/2005/952 | |
dc.description.abstract | Large, software intensive systems are typically developed using a feature oriented development paradigm in which feature specifications are derived from domain requirements and features are implemented to satisfy such specifications. Historically, this approach has been followed in the telecommunications industry. More recently, in the automotive industry, features (for e.g. electronic stability control, collision avoidance etc.) are being developed as part of a software product line and a suitable subset of these features is integrated in an automobile model based on market requirements. Typically, features are designed independently by different engineering teams and are integrated later to create a system. Integrating features that are designed independently is extremely hard because the interactions between features are not understood properly and any incompatibilities may lead to costly redesign.
In this thesis, we propose a framework for developing feature based systems such that even if features are incompatible, they can be integrated without redesign. Our view is that a feature based system consists of a base system and multiple features (or controllers), each of which independently advise the base system on how to react to an input so as to conform to their respective specifications. Such a system may reach a point of “conflict” between two or more features when they do not agree on a common action that the base system should perform. Instead of redesigning one or more features for resolving a conflict, we propose the novel notion of “conflicttolerance”, which requires features to be “resilient” or “tolerant” with regard to violations of their advice. Thus, unlike a classical feature, a conflicttolerant feature observes that its advice has been overridden, and takes this fact into account before proceeding to offer advice for subsequent behaviour of the base system. Conflict-tolerant features are composed using a priority order such that whenever a conflict occurs between two features, the base system continues with the advice of the higher priority feature. We guarantee that each feature is “maximally” utilized in that its advice is not taken only when there is a conflict with some higher priority controller. We show how to specify conflict-tolerant features for finite state, timed, and hybrid systems and also provide decision procedures for automated verification of finite state and timed systems. This provides a compositional technique for verifying systems which are composed of conflict-tolerant features.
Our framework for developing feature based systems enables conflictresolution without redesign. The scope for reusing conflict tolerant features is significantly higher thus reducing design and verification effort. | en_US |
dc.language.iso | en_US | en_US |
dc.relation.ispartofseries | G23649 | en_US |
dc.subject | Computer Software - Manitenance and Repair | en_US |
dc.subject | Computer Trouble Shooting | en_US |
dc.subject | Conflict-tolerance | en_US |
dc.subject | Hybrid Systems - Conflict Tolerance | en_US |
dc.subject | Features (Controllers) | en_US |
dc.subject | Continuous Dynamical Systems | en_US |
dc.subject | Conflict-Tolerant Controllers | en_US |
dc.subject | Timed Systems - Conflict Tolerance | en_US |
dc.subject | Conflict-Tolerant Specification | en_US |
dc.subject | Conflict-Tolerant Features | en_US |
dc.subject.classification | Computer Science | en_US |
dc.title | Conflict-Tolerant Features | en_US |
dc.type | Thesis | en_US |
dc.degree.name | PhD | en_US |
dc.degree.level | Doctoral | en_US |
dc.degree.discipline | Faculty of Engineering | en_US |