Pub Date : 1998-04-01DOI: 10.1002/(SICI)1096-9942(1998)4:2<117::AID-TAPO6>3.3.CO;2-I
R. Godin, H. Mili, G. Mineau, R. Missaoui, A. Arfi, Thuy-Tien Chau
Building and maintaining the class hierarchy has been recognized as an important but one of the most difficult activities of object-oriented design. Concept (or Galois) lattices and related structures are presented as a framework for dealing with the design and maintenance of class hierarchies. Because the design of class hierarchies is inherently an iterative and incremental process, we designed incremental algorithms that update existing Galois lattices as the result of adding, removing, or modifying class specifications. A prototype tool incorporating this and other algorithms has been developed as part of the IGLOO project, which is a large object-oriented software engineering joint research project involving academic and industrial partners. The tool can generate either the concept lattice or several variant structures incrementally by incorporating new classes one by one. The resulting hierarchies can be interactively explored and refined using a graphical browser. In addition, several metrics are computed to help evaluating the quality of the hierarchies. Experiments are presented to better assess the applicability of the approach.
{"title":"Design of Class Hierarchies Based on Concept (Galois) Lattices","authors":"R. Godin, H. Mili, G. Mineau, R. Missaoui, A. Arfi, Thuy-Tien Chau","doi":"10.1002/(SICI)1096-9942(1998)4:2<117::AID-TAPO6>3.3.CO;2-I","DOIUrl":"https://doi.org/10.1002/(SICI)1096-9942(1998)4:2<117::AID-TAPO6>3.3.CO;2-I","url":null,"abstract":"Building and maintaining the class hierarchy has been recognized as an important but one of the most difficult activities of object-oriented design. Concept (or Galois) lattices and related structures are presented as a framework for dealing with the design and maintenance of class hierarchies. Because the design of class hierarchies is inherently an iterative and incremental process, we designed incremental algorithms that update existing Galois lattices as the result of adding, removing, or modifying class specifications. A prototype tool incorporating this and other algorithms has been developed as part of the IGLOO project, which is a large object-oriented software engineering joint research project involving academic and industrial partners. The tool can generate either the concept lattice or several variant structures incrementally by incorporating new classes one by one. The resulting hierarchies can be interactively explored and refined using a graphical browser. In addition, several metrics are computed to help evaluating the quality of the hierarchies. Experiments are presented to better assess the applicability of the approach.","PeriodicalId":293061,"journal":{"name":"Theory Pract. Object Syst.","volume":"53 98 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123847002","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-01DOI: 10.1002/(SICI)1096-9942(1998)4:2<107::AID-TAPO5>3.0.CO;2-Q
Aleta Ricciardi, Michael Ogg, Fabio Previato
The goal of the Nile project is to develop an inexpensive, scalable, fault-tolerant, widely distributed job processing environment. On the systems side, Nile must manage and provide transparent access to hundreds of commodity processors spread across the United States, and a distributed database that will exceed 100 terabytes. These are scales not commonly encountered by projects concerned with fault tolerance. On the software engineering side, Nile must be easily maintained, outlive its development phase, and be able to incorporate, or even migrate to, new software components; these requirements led us to the CORBA standard. CORBA does not yet include a fault tolerance speciication, and only a small number of experimental Object Request Brokers support object fault tolerance through replication. Our experiences over two years of building Nile have taught us a great deal that may be of use to designers of ORBs that will support object replication and fault tolerance. c The Nile collaboration is building a self-managing, highly-available job processing environment, able to provide transparent access to hundreds of heterogeneous commodity processors and a very large distributed database. The rst deployed system, and the genesis of the Nile project, will be for the CLEO high energy physics (HEP) experiment 6] where the computing resources are spread across the United States at 24 collaborating institutions, and the distributed data base exceeds 100 terabytes. Because it is managing and providing transparent access to distributed resources,. Nile can be considered a distributed operating system for a global virtual computer composed of a multitude of resources spread over a large geographic area. Consequently , while originally developed to address CLEO's computing needs, Nile is not speciic to CLEO, and could equally well be used for any large-scale processing. Nile's modular object structure means that any special purpose algorithms, such as scheduling, can easily be dropped in. Nile is currently being tested by other HEP collaborations and in other target application domains. Nile must outlive its development phase, be able to adapt to and scale with changes in computing needs, be easily maintained, and be able to incorporate new software components as they become available. These concerns led us to the CORBA standard. 1 Pragmatic issues such as cost, scalability, and institutional autonomy led us to a widely distributed global architecture, hierarchically composed of tens of geographically proximate sites. Each site implements the fault-tolerant aspects required of Nile, but inter-site coordination is loosely-coupled. Unfortunately, …
{"title":"Experience with Distributed Replicated Objects: The Nile Project","authors":"Aleta Ricciardi, Michael Ogg, Fabio Previato","doi":"10.1002/(SICI)1096-9942(1998)4:2<107::AID-TAPO5>3.0.CO;2-Q","DOIUrl":"https://doi.org/10.1002/(SICI)1096-9942(1998)4:2<107::AID-TAPO5>3.0.CO;2-Q","url":null,"abstract":"The goal of the Nile project is to develop an inexpensive, scalable, fault-tolerant, widely distributed job processing environment. On the systems side, Nile must manage and provide transparent access to hundreds of commodity processors spread across the United States, and a distributed database that will exceed 100 terabytes. These are scales not commonly encountered by projects concerned with fault tolerance. On the software engineering side, Nile must be easily maintained, outlive its development phase, and be able to incorporate, or even migrate to, new software components; these requirements led us to the CORBA standard. CORBA does not yet include a fault tolerance speciication, and only a small number of experimental Object Request Brokers support object fault tolerance through replication. Our experiences over two years of building Nile have taught us a great deal that may be of use to designers of ORBs that will support object replication and fault tolerance. c The Nile collaboration is building a self-managing, highly-available job processing environment, able to provide transparent access to hundreds of heterogeneous commodity processors and a very large distributed database. The rst deployed system, and the genesis of the Nile project, will be for the CLEO high energy physics (HEP) experiment 6] where the computing resources are spread across the United States at 24 collaborating institutions, and the distributed data base exceeds 100 terabytes. Because it is managing and providing transparent access to distributed resources,. Nile can be considered a distributed operating system for a global virtual computer composed of a multitude of resources spread over a large geographic area. Consequently , while originally developed to address CLEO's computing needs, Nile is not speciic to CLEO, and could equally well be used for any large-scale processing. Nile's modular object structure means that any special purpose algorithms, such as scheduling, can easily be dropped in. Nile is currently being tested by other HEP collaborations and in other target application domains. Nile must outlive its development phase, be able to adapt to and scale with changes in computing needs, be easily maintained, and be able to incorporate new software components as they become available. These concerns led us to the CORBA standard. 1 Pragmatic issues such as cost, scalability, and institutional autonomy led us to a widely distributed global architecture, hierarchically composed of tens of geographically proximate sites. Each site implements the fault-tolerant aspects required of Nile, but inter-site coordination is loosely-coupled. Unfortunately, …","PeriodicalId":293061,"journal":{"name":"Theory Pract. Object Syst.","volume":"125 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121027743","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-01DOI: 10.1002/(SICI)1096-9942(1998)4:2<81::AID-TAPO3>3.3.CO;2-M
L. Moser, P. Melliar-Smith, P. Narasimhan
{"title":"Consistent Object Replication in the external System","authors":"L. Moser, P. Melliar-Smith, P. Narasimhan","doi":"10.1002/(SICI)1096-9942(1998)4:2<81::AID-TAPO3>3.3.CO;2-M","DOIUrl":"https://doi.org/10.1002/(SICI)1096-9942(1998)4:2<81::AID-TAPO3>3.3.CO;2-M","url":null,"abstract":"","PeriodicalId":293061,"journal":{"name":"Theory Pract. Object Syst.","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124535430","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The Implementation of a CORBA Object Group Service","authors":"P. Felber, R. Guerraoui, A. Schiper","doi":"10.1002/(SICI)1096-9942(1998)4:2<93::AID-TAPO4>3.3.CO;2-E","DOIUrl":"https://doi.org/10.1002/(SICI)1096-9942(1998)4:2<93::AID-TAPO4>3.3.CO;2-E","url":null,"abstract":"Reference LSR-ARTICLE-1998-002doi:10.1002/(SICI)1096-9942(1998)4:2 3.0.CO;2-8 Record created on 2005-05-20, modified on 2017-05-12","PeriodicalId":293061,"journal":{"name":"Theory Pract. Object Syst.","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126681361","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-09-01DOI: 10.1002/(SICI)1096-9942(1997)3:3<213::AID-TAPO3>3.3.CO;2-V
W. Emmerich, J. Arlow, J. Madec, Mark Phoenix
Software engineering environments (SEE) support the construction and maintenance of large-scale software systems. They integrate tools for the production and maintenance of documents such as requirements definitions, architecture definitions or user manuals. Very few SEE tools meet all the developers' requirements. Some requirements that are important in practice have not been appropriately addressed. These are inter-document consistency handling, version and configuration management and cooperative work. We claim that the reason for current tools not meeting these requirements is the fact that the required database support for maintaining documents is only now becoming available. The British Airways SEE meets these new requirements. Its tools were constructed using the O2 object database management system, which has been extended to become a database management system for software engineering. We discuss the experiences we made during tool construction for this SEE.
{"title":"Tool Construction for the British Airways SEE with the O2 ODBMS","authors":"W. Emmerich, J. Arlow, J. Madec, Mark Phoenix","doi":"10.1002/(SICI)1096-9942(1997)3:3<213::AID-TAPO3>3.3.CO;2-V","DOIUrl":"https://doi.org/10.1002/(SICI)1096-9942(1997)3:3<213::AID-TAPO3>3.3.CO;2-V","url":null,"abstract":"Software engineering environments (SEE) support the construction and maintenance of large-scale software systems. They integrate tools for the production and maintenance of documents such as requirements definitions, architecture definitions or user manuals. Very few SEE tools meet all the developers' requirements. Some requirements that are important in practice have not been appropriately addressed. These are inter-document consistency handling, version and configuration management and cooperative work. We claim that the reason for current tools not meeting these requirements is the fact that the required database support for maintaining documents is only now becoming available. The British Airways SEE meets these new requirements. Its tools were constructed using the O2 object database management system, which has been extended to become a database management system for software engineering. We discuss the experiences we made during tool construction for this SEE.","PeriodicalId":293061,"journal":{"name":"Theory Pract. Object Syst.","volume":"52 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121039414","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}