May
2004 Issue: 32
May
2004 Issue: 32
Journal of Conceptual Modeling
www.inconcept.com/jcm
Awareness Net: An Integrated
Modelling Language
for Knowledge
Sharing Requirements in Collaborative Processes
By
Farhad Daneshgar, Phd
Abstract:
This article introduces a multiple-perspective modelling language for both describing and measuring the knowledge sharing requirements in collaborative business processes. It is a conceptual framework that facilitates representation and analysis of knowledge sharing requirements of the actors in collaborative business processes. The representation and measurement are performed using a set of collaborative semantic concepts, and with the aim of enhancing collaboration and knowledge-sharing within the process. The type of the proposed language is a variation of Petri-net. However, contrary to many available Petri-net-based role interaction models that mainly aid the representation and execution of structured tasks in some way, the proposed language goes one step further to identify the knowledge sharing requirements of the actors who perform these structured tasks within the collaborative business processes. It provides a unified view of the collaborative process integrating the communication, cooperation and coordination (3Cs) perspectives in one hand, and the functional, behavioural and organisational perspectives in another. In defining knowledge sharing requirements special attention is given to the concepts focus and nimbus as units of identification for these requirements.
Keywords: Awareness; Collaboration, Knowledge Sharing; Groupware; Knowledge Representation
1. Introductions and Background:
The proposed framework is rooted in the Actor Network Theory (ANT) according which, entities (or, the collaborative semantic concepts) take their form and acquire their attributes as a result of their relation with other entities (within the collaborative processes) [18, p.3]. As a result, the knowledge sharing in this article refers specifically to a special kind of contextual knowledge about the collaborative process; that is, who is doing what, how they do it, and what artefacts they use to do it. In defining the knowledge sharing requirements the view taken in this article is an extension of the interactionist’s view in the field of social psychology. According to this approach, objects in a given medium manipulate each others’ understanding and awareness via focus and nimbus, which are subspaces within which an object chooses to direct either its presence (nimbus) or its attention (focus) [11]. The more an object is within one’s focus, the more one is of that object; and the more an object is within one’s nimbus, the more aware it is of the person. Such definitions are used in this article for defining awareness levels of the actors in collaborative business processes. Such level is a combination of nimbi and foci exposed/possessed by the actors. In other words, the level of awareness that actor A has of object B is some function of A's foci and B's nimbi.
In order to operationalise the above concept of awareness and knowledge sharing capabilities in collaborative business processes, a process awareness framework was initially developed by the author followed by a groupware for maintaining actors’ levels of process awareness at required levels [5]. This article extends this previous work by applying the primitives used in the existing awareness framework in order to introduce a new modelling language called the awareness net that can be used for identifying knowledge sharing requirements of the actors in collaborative business processes.
2. The Objectives of the Awareness Net:
The awareness net is a representation of a collaborative business process and consists of a collection of collaborative semantic concepts and their relationships for the purpose of defining and measuring the awareness requirements of the actors involved in collaborative processes. In setting objectives for the proposed modelling language it was noted that one distinguishing factor that separates process models from other types of models in computer science is that humans rather than machines must enact many of the phenomena modelled. As a result, a good collaborative process model must not focus solely on the actors’ behaviour at the interface or the flow and transformation of data within the system but also focus on the communication, cooperation and coordination (3Cs) among the actors. This is regardless of whether a computer is involved in the transaction or not. Many collaborative process models have already been developed that provide a common representation format that facilitate human understanding and communication, and at the same time support and automate collaborative process management ([1], [2], [3] and [4]) with each following different objectives.
In the following paragraphs some of the objectives and unique attributes of the proposed language are discussed:
3. Introducing the Awareness Net:
A list of collaborative semantic concepts used in the awareness net is described in Section 3.1. Section 3.2 provides an in-depth analysis of awareness requirements and awareness levels. This is followed by a methodology in Section 3.3 by which the knowledge sharing requirements of the actors can be identified. To simplify the explanation of the concepts, a real-life example of awareness net is shown in Figure 1 that represents the insurance claim process within the Australian Health Insurance Sector (AHIS) involving multiple collaborating roles [20]. According to this awareness net Patients receive treatments from Medical Practitioners, pay a fee and can claim it from a Health Insurance Fund. This example will be used throughout the article.
Following is a list of the semantic concepts used in the awareness net. Each concept has a set of attributes and performs certain functions. These attributes and functions are related to one or more aspects of the 3Cs.
ACTORS:
These are human agents that enact a set of tasks by assuming one or more roles within the process. In the awareness net there is no graphical representation for the ‘actors’; instead, they are represented indirectly by the relevant role(s) that they play within the process.
ROLE:
A set of norms expressed in terms of obligations, privileges, and rights enabling actors to perform certain tasks within the process. In Figure 1 filled circles represent roles. These roles include ‘Health Insurance Fund’, ‘Patient’ and ‘Medical Provider’.
STRUCTURED TASK (or task for short):
An object made of a sequence of actions or execution steps that can be planned from the known dependencies in order to achieve a specific process goal. In Figure 1 labelled unfilled circles represent tasks. For example, tasks performed by the role ‘Health Insurance Fund’ include ‘process claim’ and ‘supply claim payments’;
ACTION:
A sequence of goal-directed microscopic execution steps that utilise certain resources and/or artefacts for their execution. There is no graphical representation for the actors however they are represented within the process script as embedded attributes of the task object.
COLLABORATIVE TASK:
Is composed of two or more tasks that have a common goal, and (must) share a task artefact. A collaborative task is always associated with a unique task artefact, and two or more simple tasks. They are graphically represented by a subset of the awareness net consisting of a pair of related tasks and the common task artefact. In Figure 1 the sub-graph consisting of the objects ‘Lodge Claim’, ‘Claim Form’ and ‘Supply Claim Payment’ represents a collaborative task.
ROLE ARTIFACT:
This object carries knowledge/resources about how to perform the actions within a task. The role artefacts are personal and are either possessed by the actors, or they know how to obtain them when required. For this reason it is assumed in this article that role artefacts can be stored either within the actor's mind in a way that others cannot formally access and use this knowledge, or is stored explicitly in personal knowledge bases in a way that can only be fully understood by anybody who has access to it. Within the awareness net the arcs that connect a role vertex to its task vertices are graphical representations of the role artefacts. In Figure 1 the ‘Treatment Knowledge’ is a role artefact for the role ‘Medical Provider’.
TASK ARTIFACT:
This object carries knowledge about how various actions associated with a collaborative task are executed. Contrary to the role artefacts where they may or may not exist explicitly within the organised knowledge bases, it is assumed here that task artefacts are always kept within the organised knowledge bases in order to be accessible and be shared by multiple actors when performing collaborative tasks. Arcs that connect a pair of task vertices together graphically represent task artefacts. In Figure 1 the ‘Patient Record’ is a task artefacts that is shared by both the Medical Provider and the Patient in order to collaborate in ‘treatment’.
COLLABORATIVE BUSINESS PROCESS (or, Process, for short):
Is a set of roles, role artefacts, tasks and task artefacts that are linked together to achieve certain process goals. A process is represented by a connected awareness net. It is formed when at least one collaborative task exists within that process. A collaborative task is created when some of its actions compete with each other in using certain process resources used by other tasks within the process at the same time; hence the concept of task dependency and collaboration.
AWARENESS:
Is knowledge about the objects that lead an actor to an understanding of various aspects of the collaborative process. It is defined by, and measured in terms of, the collaborative semantic concepts used in the awareness net, that is, roles, role artefacts, tasks and task artefacts. See 3.2 for graphical representations of various levels of awareness.
ACTUAL AWARENESS:
Represents the focus of the actor with regards to the collaborative process. Actual awareness is represented by an integer number, ranging from zero to four, representing various levels of awareness (see 3.2). Actual awareness is an attribute of the role object.
REQUIRED AWARENESS:
Represents the nimbus of the tasks. Required awareness is awareness that is attached to a task and is a property of the task object. It represents the awareness level that is expected from the actor who performs that task. It is also represented by an integer ranging from zero to four. When the require level of awareness of a task is higher than the actual level of awareness of a role, there is an ‘awareness gap’ meaning that the role is lacking the appropriate knowledge sharing capabilities and therefore may not performing the task successfully.
3.2 Definition of Awareness and Awareness Levels:
In order to operationalise the concept of awareness levels within the context of collaborative business processes, a process awareness framework was initially developed by the author followed by development of a groupware for maintaining awareness levels of the actors at required levels [5]. This awareness framework has already been applied to many real life situations and some interesting collaboration patterns were identified (see [20] for the latest application). The framework has also been applied to the ERP processes [6] & [7] as well as the community of Knowledge Management [8] and [9]. The role of the framework in identifying knowledge sharing requirements of actors in virtual communities has been identified through its capability of providing contextual knowledge in virtual communities [10] as well as being used as a design directive for implementation of groupware systems [17]. This article combines and extends all of this previous work by the writer with the aim of introducing a combined multiple-perspective modelling language for the collaborative business processes.
In the following paragraphs various levels of awareness are discussed in their original form using a simplified awareness net shown in Figure 2. In the next Section these levels are used to describe the proposed modelling language.
Figure 2: An awareness net with four roles and 14 tasks
Level-0 Awareness (Failed Level): An actor is at level-0 if s/he possesses contextual knowledge about the objects that lead the actor to an understanding of the tasks that the actor performs within the collaborative process. According to the Figure 1, level-0 awareness for the role X is a sub-graph that contains the following set of objects:
A0 ('X') = {(X, 1), 1, (X, 2), 2, (X, 3), 3, (X, 4), 4}
Therefore, awareness level-0 for the role ‘X’, shown by A0 (‘X’), is the sum of
the four
role
artefacts
shown by the lines (X,1), (X,2), (X,3) and (X,4), and four
task
vertices 1, 2, 3 and 4. Level-0 awareness does not provide the actors with
adequate awareness to get them involved in any kind of knowledge-sharing
transactions with others. The reason is that it does not include objects beyond
the actor’s perception of his/her own personal ‘tasks’ within the process.
Level-1 Awareness (Direct Cooperation and Communication): Level-0 awareness is a pre-requisite for this level. An actor that reaches level-1 awareness will possess level-0 awareness, plus knowledge about all the objects that leads the actor to awareness about some of the actors within the process. These are actors with whom the actor has a direct task dependency. In Figure 2, level-1 awareness for the actor V is the path that links vertex ‘V’ to all other related role vertices. In this example role ‘V’ happens to have task dependency with one other role, that is, role ‘X’. In this particular case, there are two alternatives/paths for the V’s level-1 awareness because there are two separate relationships between V and X. The mathematical set presentations for these alternatives are:
Alternative_2_A1 (‘V’) = {A0 (‘V’), (d, 2), 2, (2, X), X}
Level-2 Awareness (Extended Cooperation): An actor at level-2 awareness will have knowledge about the objects that lead the actor towards an understanding of all (other) roles within the process. Level-2 awareness for the role ‘V’ is its level-1 awareness, plus the path that links V to all other role vertices within the process. There are many alternatives for the V’s level-2. The mathematical set representation for one of these alternatives follow:
Alternative_1_A2 ('V') = {A1 ('V'), (X,4) , 4 , (4 , 5), 5 , (5, Y), Y, (Y , 6), 6 , (6 , b), b , (b , T), T}
Level-3 Awareness (Extended Communication): An actor at level-3 awareness has the knowledge about the objects that lead that actor towards an understanding of all the interactions that occur between any pair of roles within the process. Attaining level-3 awareness enables an actor to initiate level-3 context-sharing transactions within the VC. The mathematical representation of this level for the alternative 1 of the level-2 awareness for the role V is:
A3 (‘V’) = {alternative_1_A2 (‘V’), (4 ,6), (7 , 2)}
Notice that (4, 6) and (7, 2) are the only two other task artefacts that were not included in the alternative_1_A2(‘V’).
Level-4 Awareness (Coordination): An actor at level-4 awareness has a specialised knowledge about the objects that lead that actor to an understanding of how all the objects within the VC as well as their relationships. Graphically, this level can be represented by the whole of the awareness net. At this level the actor has adequate contextual knowledge about who does what, how, with whom, etc. In other words, this level provides awareness about how people within the VC perform their tasks (that is, the sum of all the actors’ level-0 awareness), who directly collaborates with whom and how (sum of all the level-1 awareness), and who directly or indirectly collaborates with whom and how (sum of all the level-2 awareness), and finally, how other actors collaborate with one another (sum of all the level-3 awareness). The mathematical representation of this level can be shown by the following sets of equations:
A4 (X) = A4 (Y) = A4 (T) = A4 (V)
A4(X) = {A3(X), {V, e}, {V, f}, e, f, {T, c}, {T, a}, c, a, {Y, 8}, 8}
A4(Y) = {A3 (Y), {V, e}, e, {V, f}, f, {X, 3}, 3, {T, c}, c, {T, a}, a}
A4(T) = {A3 (T), {V, e}, {V, f}, e, f, {Y, 8}, 8, {X, 3}, 3}
A4 (V) = {A3 (V), {X,3}, 3, {T, c}, c, {T, a}, a, {Y, 8}, 8, {X, 3}, 3}
In short, the level-4 awareness is the sum of all the role’s level-3 awareness, plus the sum of all the other roles’ tasks and corresponding role artefacts that obviously were not included in the role’s level-3 awareness. Awareness at this level is highest within the context of the collaborative business process, as the actor will know not only how everybody interacts with others, but also how each role performs its own very personal and non-collaborative task(s).
3.3 A Modelling Language for Collaborative Business Processes
Many forms of information must be integrated to adequately describe a collaborative business process. Generally speaking, process-modelling language can represent and reason about various aspects of collaborative processes. These languages can be evaluated by the extent to which they provide constructs useful for representing and reasoning about the various aspects of a collaborative process. The proposed awareness net represents three perspectives in order to identify awareness requirements of the actors in collaborative business processes. These perspectives are functional, behavioural and organisational perspectives [15]; and the requirements are communicational, co-operational and coordination requirements.
It is believed in this article that when combined, these perspectives will produce an integrated, consistent, and complete model of the collaborative business processes. The definitions for these perspectives are:
1. Functional Perspective: This represents what process elements are being performed, and what flows of informational entities (e.g., data, artefacts, products), are relevant to these process elements. As demonstrated before, the awareness net clearly specifies what task objects are performed, what artefact objects are used and what features (eg, attributes, methods, constraints, flow, etc.) these elements/objects have.
2. Behavioural Perspective: represents when process elements are performed (e.g., sequencing), as well as aspects of how they are performed through feedback loops, iteration, complex decision-making conditions, entry and exit criteria, and so forth. While providing information about this perspective was not the main thrust of the awareness net, it is however capable of encapsulating the above behavioural variables within various features of the process elements. Alternatively, the awareness net can easily be transformed into an interaction sequence diagram, or a collaboration diagram [19], both demonstrating behavioural aspects of the collaborative semantic concepts within the process. Due to limited space no attempt was made in this article to demonstrate the latter potential for the awareness net.
3. Organizational Perspective: represents where and by whom in the organization process elements are performed, the physical communication mechanisms used for transfer of entities, and the physical media and locations used for storing entities. Again, the strong role-relationship attribute of the awareness net, coupled with its object-orientation nature, is potentially capable of providing information regarding this aspect of the collaborative process.
The following paragraphs demonstrate additional capabilities of the awareness net in representing the above perspectives.
Awareness net, like many other petri nets, depicts role interactions. Generally, the role interaction nets are designed to aid the representation and execution of structured tasks (as defined in 3.1). Historically, role interaction nets represent roles, dependencies, and process elements. The awareness net goes one step further; it highlights the 3C (communication, collaboration and coordination) requirements of the actors in collaborative business processes.
Awareness net also introduces a new and de facto notion of team. This de facto notion is built on dependencies among roles on the basis of the collaborative tasks that the actors perform, as well as the task artefacts that they share for their collaboration. This is different from the common notion of team, which is based on the reporting relationships. With awareness net a process plan can be designed as a decomposition of tasks, roles, task artefacts and role artefacts. A project plan, on the other hand, is established when roles are assigned to actors. One actor may hold many roles and a type of role may be assigned to several actors. Awareness net can then be used as a method of coordinating the flow of artefacts among collaborating roles and as a method of tracking progress by the completion of interactions among roles. This formalism can be used for coordinating activities in process-driven environments. Equipped with a rule-based awareness model/levels, the awareness net also provides communication and collaboration support as discussed in 3.2.
3.4 A Methodology for Identifying the Awareness Requirements:
Step One: Construct an awareness net to represent the collaborative process.
Step Two: determine the actual levels of awareness for each actor. Several methods can be used in order to determine these actual levels. One method is to use software developed by the writer and is called "Aware-Ware Template" or AWT [5]. Actors interact with this software and express their awareness (Yes/No) with regards to the objects that exist on the awareness net. The algorithm of this software is capable of parsing the awareness net, which has already been mapped into a database, in order to identify various objects that make up various awareness levels for each actor, based on their responses. Another method for determining the actual level of awareness in smaller processes is the 'interview' method. Both of these methods have already been used and significant results were produced.
Step three: define a required level of awareness for each task that an actor performs within the process. It is assumed in this article that such level of awareness is directly related to both the nature of the task as well as to the organizational culture. Although no attempt is made in this article to tackle these issues, these required awareness levels are treated as parameters to the model and therefore are determined externally. Again, the AWT software can be used to identify objects that constitute various levels of awareness that is required from the actors within the community. In the absence of the AWT software, this can be done either by interviewing the actors, or by manually tracing the awareness net and recording the objects (that is, nodes and vertices) that constitute various levels of awareness for each actor.
Step Four: for each actor, if the highest value of his/her required level of awareness is higher than the actual level of the actor’s awareness, that is, if there is an awareness gap, then there is potential for enhancing collaboration. This can be done by exposing the actor to the relevant objects that constitute the awareness gap. Alternatively, another actor can be assigned to this role that possesses higher actual level of awareness.
4. Some Issues in Awareness Net
In this section the three common process modelling issues are addressed. These issues have initially been raised by Curtis et al [15] and are frequently addressed in process modelling literature. These are formality, granularity, and scriptiveness/fitness.
Formality: Due to its role-interaction nature, the awareness net is based on precise definitions of the language elements and their relationships. Tasks, for example, are of the type structured in a sense that their actions as well as the resources used by these actions can be determined and/or planned beforehand. Any level of ambiguity or imprecision that may be introduced by mathematical formalism will adversely affect the quality of this language and therefore is avoided. For this reason the level of mathematical formality used to describe tasks need to clearly identify actions and resources used, but do not need to be high enough to make the awareness net enactable on a computer, as this has not been the main objective of the awareness net (see Section 2 for the objectives of the awareness net). Also, the multi-perspective nature of the awareness net imposes further requirements to the level of mathematical formality used to describe it. Generally speaking, process elements need to be formalised to a degree that flow of information, their timing, and various simultaneous links among them are not disregarded by such formalism. For these reasons the author recommends a standard object-oriented modelling formalism such as UML, and higher level of formality is discouraged if the multiple perspective nature of the awareness net is to be maintained.
Granularity: This involves the size of the process elements represented in the model. Greater granularity ensures process precision, that is, the degree to which a defined process specifies all the process steps needed to produce accurate results. In the case of awareness net granularity will depend on the purpose of the model, as well as the attributes of the actors that execute the process. As long as the process task structure is concerned, an action in the awareness net is the smallest unit of mathematical and/or descriptive representation, whereas task is the smallest unit of graphical representation. This means that those actors who are directly involved in the business of executing the process in its utmost detail would be interested in accessing the process description that carries knowledge about the individual actions and resources they utilise, whereas a graphical representation would satisfy needs of other actors who may not have such needs.
In practice it is possible that descriptions for tasks, actions, roles and artefacts may be too large-grained for some actors; that is, having higher level of abstraction. This will provide insufficient details for guiding those actors that actually execute the process. In situations like these actors are expected to have sufficient knowledge to translate these imprecise and perhaps unstructured scripts into actions by filling in detailed process steps that are appropriate to current situation. This also means that if these actors already know many relevant potential scripts, a large-grained process model may be desirable in order to allow these actors to tailor the final detailed process script enacted. This kind of flexibility may be especially desirable when there are complicated decision rules for selecting and integrating the processes to be performed.
Scriptiveness and Fitness: As a modelling language, the awareness net possesses attributes that make it both a prescriptive model (to lesser degree), and a descriptive model (to a higher degree). When developing the proposed modelling language, the only prescription in the mind of the writer of this article was certain relational rules for the awareness net’s semantic concepts that generally apply to all collaborative processes. Some of these relational rules include:
1. At any given time a role cannot be played by more than one actor, but an actor can play multiple roles.
2. For execution of a task a role artefact is needed. There is no task that can be executed without having a need for some kind of explicit/implicit knowledge/resources.
3. Similarly, execution of a collaborative task would require sharing of a common task artefact.
Considering above rules as prescription, then the awareness net would be a prescriptive language; whereas considering them as common sense, then the awareness net would be a descriptive language. As a prescriptive model the awareness net needs to be analysed for its fitness. Fitness is defined here as the degree to which the actors can faithfully follow the process steps it specifies [16].
5. Concluding Remarks and Future Work
The work on modelling of collaborative business processes is fairly young. This article introduced a new modelling language for collaborative processes that provides an integrated view of multiple perspectives in two dimensions: the traditional functional, behavioural and organizational perspectives, as well as the traditional groupware-oriented 3Cs perspectives.
The awareness net also facilitates human understanding and communication that the group needs in order to be able to share a common representation format. It can also be used to enhance collaboration among actors. Work is in progress for using the awareness net as a medium for analysis and design of groupware systems that specifically support collaborative process awareness.
In conclusion it must be noted that despite the strength of the awareness net in achieving its objectives, technology transfer experience suggests that this process model may not be sufficiently effective in an organization where a basic description of its process has not been established yet.
REFERENCES
7. Daneshgar F, Book chapter in ERP & Data Warehousing in Organizations: Issues and Challenges, title ”Context Management of ERP Processes in Virtual Communities" by Gerald Grant, Carleton University, Canada, IRM Press, 2003.
8. Daneshgar F, “Maintaining Collaborative Process Awareness as a Mechanism for Knowledge Sharing”, 2nd European Conference in Knowledge Management, Bled, Slovenia, November 2001. LOVENIA
9. Daneshgar F, Amaravati C, "Sharing Contextual Knowledge in Today's Workplace Environments", Electronic Journal of Knowledge Management Issue 2, vol 2, 2004.
10. Daneshgar F, Ray P, Rahbi F, Molli H S, Molli P and Godart C; "Knowledge Sharing Infrastructures for Teams within Virtual Communities", in e-Collaborations and Virtual Organizations, edited by Dr. Michelle Fong, IGP/Infosci/IRM Press, Hershey, PA, USA, 2004.
11. Benford S., L. E. Fahlen, "A Spatial Model of Interaction in Large Virtual Environments", Proceedings of Third ECSCW, Milano, Italy, 1993.
12. Iivari J and Linger H, “Knowledge Work as Collaborative Work: A Situated Activity Theory View”, Proceedings of 32nd Hawaii International Conference on System Sciences, Hawaii, USA, 1999.
13. Sumi Y and Mase K, “Supporting the Awareness of Shared Interests and Experiences in Communities”, International Journal of Human-Computer Studies, Vol. 56 (2002), pp. 127-146.
14. Cohen D, Jacovi M, Maarek Y S, Soroka V, “Livemaps for Collection Awareness”, International Journal of Human-Computer Studies, Vol. 56 (2002), pp.7-23.
15. Curtis B, Kellner M I, & Over J, “Process Modeling”, Communication of the ACM, Vol. 33, No. 9, September 1992.
16. Humphrey W S, and Feiler, P H, “Software process development and enactment: Concepts and Definitions”, Technical Report SEI-92-TR-4, Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
17. Daneshgar F, Book Chapter in Innovations of Knowledge Management, Editted by Bonnie Montano, title: “Awareness Matters in Virtual Communities: An Awareness Ontology”, Idea Group Inc. Hershey, PA, USA, 2004.
18. Law J, J Hassard (Eds.), Actor Network Theory and After, Malden, MA: Blackwell, Selection chapters: “After ANT: complexity, naming and topology” by Law and “On Recalling ANT” by Bruno Latour)
19. Bennett
S, S McRobb & R Farmer, “Object-Oriented Systems Analysis and Design using UML”,
McGraw Hill, Berkshire, 2002, pp. 234-248.
20. Daneshgar F, K Mawson-Lee, "Enhancing collaboration in the Australian Health Insurance Sector", Proceedings of KMAC'2003, Aston University, UK, July 2003.
________________________________________________________________________
Farhad Daneshgar, Phd
Senior Lecturer
School of Information Systems, Technology and Management University of New South
Wales Sydney, Australia,
Address:
F.Daneshgar
SISTM
UNSW SYDNEY 2052 AUSTRALIA
Email: f.daneshgar@unsw.edu.au
Phone: +61 (2) 9385 4241
Fax: +61 (2) 9662 4061
Web Page (click on Academic Staff, Farhad Daneshgar):
http://www.sistm.unsw.edu.au/
__________________________________________
© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement. ISSN: 1533-3825