حمایت از تیم های کوچک در ساخت مدل حوزه نرم افزار همکاری

Building application domain models is a time-consuming activity in software engineering. In small teams, it is an activity that involves almost all participants, including developers and domain experts. In our approach, we support the knowledge engineering activity by reusing tagging done by team participants when they search information on the Web about the application’s domain. Team participants collaborate implicitly when they do tagging because their individually created tags are collected and form a folksonomy. This folksonomy reflects their knowledge about the domain and it is the base for eliciting domain model elements in the knowledge acquisition and conceptualization tasks in a consensual way. Experiments provide evidence that our approach helps team participants to build richer domain models than if they do not use our software tool. The tool allows the reuse of simple annotations as long as users learn about the application’s domain.

Domain modeling is an activity present in a great number of software development (SD) projects. It is essentially a cooperative activity and hence an interesting field of experimentation for computer supported cooperative work (CSCW). It is often the case that developers do not know deeply the domain of the application. In order to learn, elicit knowledge to be represented, build a conceptual vision of such knowledge and, finally, formalize and represent it in a machine-readable format, developers use several sources of information, including the experts of the domain. For instance, a SD team developing a domain model for a tourism website has to interview people working in this business and its potential users, search for information in tourist guides, travel agencies and tourist offices learning which elements are relevant for designing the system’s use cases and how such elements are related to each other. This is a long process since knowledge is learned in an incremental way and people should commit to a certain view of the domain. Different people have different views of the same piece of the domain being modeled and resulting conflicts must be managed. Consequently, there is a great difference from versions of the domain model built in the initial phases to the ones at the end of the project. In a SD process, application domain models may take different forms such as entity-relationship models, conceptual-level schemas, object-oriented data models (OODM) and ontologies, the latter being adopted as reference in this work. We adopted ontologies because they are built consensually and reaching such a consensus demands cooperation as stated by Gruber (1993): “an ontology is a formal, explicit specification of a shared conceptualization”. Guarino and Giaretta (1995) consider an ontology in the artificial intelligence (AI) sense as “a logical theory which gives an explicit, partial account of a conceptualization”. Ontologies can be represented taking AI-based approaches (e.g. frames), logics, among others. In this work, we assume ontologies are represented with Description Logics (Baader, McGuinness, Nardi, & Patel-Schneider, 2003). In this logic, the representational primitives are concepts (classes of objects), roles (binaries relations between concepts), and individuals (instances of classes). According to (Borgida & Brachman, 2003), all of the above mentioned kinds of application domain models are comparable since they rely on an object-centered view of the world including notions like individual objects, which have relationships to each other, and which are grouped into classes. Even notational languages used to represent OODM and ontologies can be the same, such as the UML (Unified Modeling Language), the similarity among different kinds of domain models was also noted by Studer, Benjamins, and Fensel (1998) when they present the communalities of Software Engineering and Knowledge Engineering. Nowadays, there is an intense research in emergence of knowledge from social applications like BibSonomy,1 Semantic-MediaWiki,2 and Richards (2009) proposing new methods and techniques to acquire knowledge. In this work, we apply one of these techniques in small SD teams to support knowledge engineering activity by acquiring knowledge from folksonomies. In social applications, a personomy is produced by user tagging activity in any social tagging system and it is formed by all tags of the user represented in a plain structure. The collection of personomies constitutes a folksonomy (Jaschke, Hotho, Schmitz, Ganter, & Stumme, 2008). The folksonomy is dynamic as long as users learn new things and review their personomies, including and excluding their tags. Users can annotate resources with different tags depending on their social or cultural backgrounds, expertise and perception of the world (Begelman et al., 2006, Golder and Huberman, 2005, Peterson, 2006 and Wu et al., 2006) and thus it is an important source of information. Typically, small teams in SD have fewer than 10 members, and wasteful activities can be detrimental or even lead the development effort to failure. Pollice, Augustine, Lowe, and Madhur (2004) describe a SD project in which members of the development team began by identifying artifacts they felt were absolutely required, including the vision statement, risk list, development case, use cases, test cases, project plan, glossary, and architecture. As the development effort progressed, the team created many of these essential artifacts informally. For example, a test plan might be simply a sticky note attached to the wall. As the team members stated, it was “good enough” for the team’s needs. By creating many of their artifacts according to this principle, they avoided waste time and attention on documentation that was not necessary for delivering a stable and well-tested product. Application domain modeling in small teams of SD is an activity that involves practically all participants. Such activity is one among several they develop day-to-day and it could be just partially supported by computers because there are a considerable amount of face-to-face discussions in order to build a shared conceptual view. Thus, the problem is how to help developers to build such models in a cooperative way during the project. The cooperative modelling includes (i) coping with frequent modifications on the information sources and their influence in the current version of the domain model, (ii) reaching consensus on the knowledge representation structure, and (iii) tracing modeling decisions. The general goal of our work is to support different types of activities in SD for small teams using a multiagent system (MAS). The focus of this article is specifically on the domain modeling activity. We show evidences that a folksonomy built from personomies can help a small team to build better ontologies than if they work without remembering simple annotations made when they visit web pages about an application domain. The folksonomy results from implicit collaboration given that users tag resources individually. This paper presents a review of the literature on CSCW for domain modeling, the fundamentals on ontology development, ontology learning, ontology evolution and multiagent systems, the proposed multiagent architecture highlighting the domain modeling activity, the experiments in order to evaluate the level of support offered to the users, analysis of the results, and finally, a conclusion.

Team 2 got better results in RD and PR than team 1, showing that KACSA provides good support for creating properties (Table 1). Indeed, team 2 followed approximately 82% of suggestions made by KACSA (Table 3) while only 26.5% of team 1’s modifications were originated from the tag list. This shows that previous tagging was not very important to team 1. Team 1 discussed more than team 2 (in 100% of modifications) and had to rely on previous knowledge about the tourism domain (about 70% of modifications) and, in consequence, on previous elements added to the ontology. Thus the lack of an integrated tool in the daily activities of team 1 demanded an extra effort in remembering and discussing modifications. If the domain is not very usual to the team participants, it may result in a lot of re-work. Team 1 performed better than team 2 in quantitative terms as Table 2 shows. One of the reasons pointed out by team 2 is the lack of usability in the dialog with the PA (that shows the KACSA’s suggestions and questions). All over the experiment team 2 was guided by this dialog as we can infer from values of Table 2. While KACSA allowed team 2 to produce a richer ontology than team 1, the PA’s interface was a barrier to the performance in this time limited experiment. As team 1 was not guided by a dialog, they used their previous knowledge to create concepts and instances that, in its turn, inspired them to create new concepts and instances (Table 3, previous knowledge and previous element). In a long term experiment, previous knowledge may reach a saturation point. 6.1. Contribution of the proposed approach Integrating tagging in the daily tasks provides support to users in building satisfactory domain models. An interesting point is that even though tagging is done individually, the obtained folksonomy can be considered the result of an implicit collaboration. Thus, the developed ontology is the result of implicit and explicit collaboration. The latter occurs more effectively at the conceptualization task. Improvements on the PA dialog would allow a better estimative of how much knowledge tagging could supply for building ontologies. We could observe that tagging helps to remember important elements of domain, and that face-to-face discussion is a very important mechanism (there was no tag transformed in an ontology element without discussion in team 1). Thus, more support should be provided on the conceptualization task by, for example, the development of a voting mechanism. Keeping trace of decisions by saving the arguments for refusing or accepting a modification would reduce re-work in subsequent enrichments of the ontology. In the context of small teams working in the same physical space, users usually prefer to communicate in a face to face mode. Annotations done on an artifact are more important as a register of decisions than as a coordination mechanism. Thus, our approach is based fundamentally on integrating knowledge engineering in small team participants’ work processes and supporting them in making modeling choices. In our approach, domain experts and developers collaborate in a different way as they do not enter information directly on a specific environment. Instead, they tag Web pages that are used to build a folksonomy that, in its turn, is used to elaborate the ontology. Doing so, domain experts and developers provide information about the domain while researching for the project they are developing. As folksonomies are relatively new, most ontology learning and evolution approaches do not consider folksonomies as an information source for ontology learning and ontology evolution. In this work, this is exactly the case, as we focus on change capturing from data-driven implicit requirements. Our approach for ontology evolution starts with an existing ontology and supports the acquisition of new knowledge from folksonomies when users change their tags as long as their vocabularies change.