7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

Role based Software Process Modelling

Fadila Atil, Djamel Meslati, Nora Bounour & Said Ghoul*

LRI Laboratory, University of Badji Mokhtar, BP 12, Annaba, Ageria
*
Institute of Computer science, university of Philadelphia, Jordan
atil_fadila@[Link]
meslati_djamel@[Link]
nora_bounour@[Link]
sghoul@[Link]

Abstract : Modelling software processes is a difficult and expensive task. It's confirmed by diversity
of software processes modelling approaches which are however, not satisfactory. This paper presents
roles and coordination as valuable abstractions for specifying and modelling methodological aspects
of this processes, by formally defining the policy that lead the process, such as rules which determine
activities and their organization and the component mechanisms, such as tools that realize activities
and operate on objects according to policy.
The purpose of role modelling is to achieve separation of concerns, allowing the designer to consider
different aspects, or the same aspect at different levels of detail.
The originality of our approach is to consider a process as a coordination of an agent system. This
have include profits; among which, the modular distribution of methodologies upon implicated system agents,
the construction and the realization of component methodologies, and the association of version of behaviours to
the same agent.

Key words: Activity, agent, coordination, methodology, role modelling and software process.

Introduction
In the real word, we discern the presence of processes with diverse nature (biological processes, chemical
processes, software processes…etc). We note that every process is a well-ordered series of facts or
phenomena answering to a certain scheme and leading to the determination of result. In fact, this represents
the resolution of problem that the process confronts.
As part of software engineering, a large community defines a software process as a partially ordered set
of activities accomplished during development or evolution of software [6]. This definition implies that each
set of software life cycle activities (and not necessarily every activities) forms a software process. For
against, number of searchers defines a software process as the total set of software engineering activities.
This definition is a particular case of the first because it is interested with a particular software process
(covering all the set of life cycle activities).
Modelling, evaluation, improvement, formalizing description and progress of a software process have
made the object of several research projects. Problem of this domain is that it calls at many technologies
(knowledge representation, data bases, artificial intelligence, simulation…) and methodologies (sequential,
cascade, expert system, prototyping…) of which the majority has not reach the stage of maturity and
stability. This makes the software production a process with difficult approach to understand and with
concepts difficult to unify. It also confirms the diversity of processes modelling approaches which are
however not satisfactory [2, 5].
Rueher define the software process as a sequence of operations required for building up various
information objects (specifications, prototype documentation, test cases, code…) that compose a software
product [11]. The software process can be split into sub-processes, but it is often very hard to find a good
decomposition and to describe the complex way in which they must communicate. Processes are dynamic,
hard to comprehend, and to reason about.
A software process model (SPM) is a descriptive representation of the software process structure, used as a
reasoning support, allowing its understanding and its progress.

199
7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

Analysis of any process get appear two levels: structural level which represent objects on which process's
activities perform, and methodological level describing the policies which lead the process and its component
methods.
SPM = ({Methodologies: Policies, Mechanisms},
{Structures})
In this paper, we propose modelling software processes by a simple and natural way, using object
approach. The problem that we have confronted is due to the fact that this approach doesn’t allow the
modelling of all dynamics and constant change of reality. To solve this problem, we attempt to use the role
and coordination concepts to express how the object changes and to allow the definition of one or more
methodologies controlling the behaviour of the software process.
This approach presents many conceptual advantages with regard to actual works in the domain. In fact, a
software process is regarded as an agent system, which cooperates for realizing the same objective. This
vision is natural and present contribution concerning construction and reuse of software process’s
methodologies. In this approach, it's even possible to associate versions of roles to the same agent.
We present, in section 2, insufficiencies of object approach to express methodological aspects of software
processes, as well as the proposed solutions. In section 3, we detail foundations of our modelling approach.
Finally, a comparison between our work and related works is taken out in section 4 and we terminate with a
conclusion.

1. Insufficiencies of Object Oriented Approach and proposed solutions

The object oriented modelling present many advantages; nevertheless, many deficiencies could be taken up
[9]. To demonstrate the need of new concepts, we present a simple example of a software process, and we
show afterwards limits of actual models.

1.1. Example of a Software Process

Let a simple software process, which takes place in a little programming environment that includes an editor,
a compiler and a tester. This process consists to edit a file, then to compile it (as soon as the programmer
finishes edition). If compilation doesn’t fail, the object program will be tested using data test. This minimal
programming environment presents a simple model Edit-Compile-Test (figure 1).

Edit Compile

Test

Figure 1. A minimal Programming Environment.

A software process model, ProgramingEnvironment, which models this process, must support three steps as
indicated in figure 2.
Compiler
ReadyToCompile
EndEdit
Edit Edit
Editor FailCompiler
SucessCompiler
FailTest
Test TestWithData

Run
Figure 2. Steps of Programming Environment.
In ProgramingEnvironment, the mechanisms are defined by the set of implicated activities and are
unchangeable.

200
7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

Mechanisms = {ReadyToCompile, Editor, EndEdit, Compiler, FailCompiler, SuccesCompiler, Run,

TestWithData, FailTest}

The policies are defined by dependencies between process's activities. These policies and their control are
taken under one’s responsibility of the user, who must pass on the product from one step to other step. This
often engenders diverse mistakes and exceeding delay.

1.2. Limitations in Modeling Methodological Aspects

To model a software process according to the object approach, the principle is based one’s argument on
invocation of methods by sending messages to objects of a class hierarchy. The series of these methods must
allow the correct and not ambiguous resolution of the given problem [3, 5]. Such series of methods qualified
with sensible and explicit, define a coordination of these methods [5, 7].

If in object oriented programming languages, the semantic analysis allows verification of method
invocation’s validity by an object, nothing allows the verification of methods coordination’s validity of the
same object or of different objects. Nothing allows then to consider an object as a process, and consequently,
to verify its correct exploitation (according to this process). This is due to the total absence of an explicit
formulation of coordination in actual object oriented formalism, which is a serious handicap for software
processes modeling. We attempt to remedy to that by the integration of methodologies in the definition of
objects. We note that actually there are needs in this way as part of formal specifications.

2. Coordination Paradigm
We use a coordination model permitting expression of software processes methodologies. We consider a
software process as a set of agents that cooperate for realizing the same objective. This approach is based on
the set of the following concepts [2, 3, 5]:
1. Activity: An activity corresponds to a simple or compound action, which is executed by a human being
or a machine.
2. Agent: An agent is an active, a reactive or a cognitive entity responsible of the execution of a set of
activities, defining its behaviours.
3. Dependency: A dependency defines a relation between two or some activities. We say that an activity
A1 depend on the activity A2 if the working of A1 require this of A2. Some dependencies come under
intrinsic semantic of activities. They exist independently of any context (global objective to reach). For
example, any "Consumer" activity depends on a "Producer" activity: It must ever check that the
"Producer" activity is accomplished before its results are required by "Consumer" activity. Some other
dependencies between activities come under a global objective to reach. These dependencies must be
dynamically introduced (or separated) to satisfy this goal. A same objective can be reach with different
manners, according to the applicable methodology. The set of dependencies between activities is open,
in view of the infinity of contexts were they evolve and the changeable goals to reach. In our study, we
are interested with two types of dependencies, namely, functional dependencies and organizational
dependencies.

Functional dependencies: These types of dependencies regroup all data flux and control flux dependencies,
well known in procedural languages. They must be verified every time and are explicitly defined by the
relation Function that has a changeable semantic (Figure 3).

Ctr

IA TA
Figure 3. Functional Dependency.

The Function dependency expresses that a set of target activities TA depends on an optional set of initial
activities IA under the optional constraint Ctr. When all activities of IA are executed, activities of TA could
be executed under the constraint Ctr.
Formally, this dependency is defined with: ″ [IA] [Ctr] → TA ″, were Ctr is defined with <condition; value;
sense>. The Condition attribute defines conditions that must be satisfying in order that dependency being
valid. Value attribute defines the data flux required by this dependency. Finally, Sense attribute defines the

201
7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

semantic of dependency, which can be repetition (∗), implication (∧), exclusion (¬), equivalence (∼),

For example, the instantiation dependency {Edit} <∅; ∅; ∋> → E consists of generating an agent E from the
instantiation (∋), etc.

class Edit. The dependency <∅; ∅; ¬> → {NormalEdit, PascalSyntax, PrologSyntax} express exclusivity
between tree type of editors: A normal editor, and two syntactic editors, one for Pascal and one for Prolog.
Organizational dependencies: These dependencies allow an organization of activities during time (with
Synchronous and Alternation dependencies) as well as their hierarchical organization (with Aggregation
dependency). We note that organizational dependencies allow the modelling of behaviours of agent's
software processes.
• Synchronous: This dependency allows ordering activities in time. It’s expressed with: Syn a1, a2, ..., an
Endsyn. For example, the dependency Syn init, ReadyToCompile Endsyn expresses that the activity
ReadyToCompile can’t be executed only after the activity Init. Activities none implicated in a Syn
dependency may be executed in any order.
• Alternation: It’s a dependency, which allows establishing a nil order between a set of activities. These
activities are then alternated, and could constitute a varying activity. By nil order, we imply that only one
of concerned activities can be executed. This activity will be determined dynamically according to
explicit or deduced contextual knowledge. It’s defined with: Alt a1, a2, ..., an Endalt. Only one activity ai
(i=1,n) must be executed and all the others will be ignored. For example, Alt Edit1, Edit2 Endalt
expresses that only one activity between the two exclusive activities can be executed at a fixed time.
• Aggregation: It allows constructing a complex activity with hierarchical composition (designed by an

indicate the resulting activity. Such dependency will be expressed with: ″ {IA1,IA2,...,IAn} <∅;∅;U> →
identifier) of different agent’s activities. If the composition is designed with an identifier, this last will

TA ″, were TA is the identifier of the resulting activity. None designed composition don't construct a
complex activity.

3. Role Modelling
We consider real word concepts to consist of several mutually cooperating and interacting entities, not stand-
alone entities existing independently of other entities in the same domain of interest. The design approach
presented here is related to the ideas of considering objects as “playing” different roles in different contexts
[1, 4, 10].
Agent of a software process cooperates with each other to accomplish a global goal. So, they are related
to each other in different way: Serving, using, and communicating with each other. From the way in which
they treat one another, agents have different perspectives of each other. These perspectives define the role
that an agent may play towards another. A role is formed as a set of behaviours of the agent. Different roles
exist for different purpose, and the roles played by an agent may change over time.
The role is a powerful modelling concept. It gives restricted, possibly complementary perspectives on a
complex and compound agent and allow dynamicity of such perspectives. An agent has several roles that
have been chosen in order to accomplish the objective of the modelling. The roles may change and they may
exist simultaneously.
The concept of role is intuitive and important to achieve a simple and natural modelling of process activities,
and to aid comprehension.
The mission of role modelling is to reduce complexity when doing "large-scale" design; i.e. complexity due
to the size of the design task. This is done by supporting separation of concerns and reusable design [1].
In our approach, agent’s activities can exist in many versions and can be organized during time in many
different manners. Each acceptable organization of activities defines agent behaviour (a methodology of its
working). In this way, behaviour presents the associated agent as a states machine [8] or simply as a process.
The agent’s behaviour according to a determined objective defines its role and the role is then a sensible
series of activities.
In order to illustrate the use of this concept for modelling software processes, we retain the same example of
the figure 1. Behaviours present in the software process Edit are defined by the set of activities {Init, Editor,
ReadyToCompile, EndEdit}. Edit correspond then to an agent that can be obtained by generating an instance
from a class Edit. We can assign to this agent two distinct roles, schematically defined by the figure 4,
allowing going buck or no to the edition step from the compilation step.

202
7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

NormalEdit1

Editor.1 ReadyToCompile

Init.1 EndEdit

NormalEdit2
Editor.1 ReadyToCompile

Init.1 EndEdit

Figure 4. Two roles NormalEdit1 and NormalEdit2 of Edit agent.

4. Agent Modelling
A software process corresponds in our approach to an agent that can be simple or complex, i.e., compound of
a set of agents which cooperate in order to achieve the same objective. The modelling of such agent is
essentially based on the definition of the set of composing agents, of dependencies between its activities and
of roles that it offers (Figure 5).

Agent <Agent Name>;

Interface <Interface description: Identification of roles>
Agents <Definition of the set of composing agents>
Functional Dependencies
<Definition of functional dependencies>
Organizational Dependencies
<Definition of the set of roles>
End <Agent Name>
Figure 5. Definition of a formal agent.

A formal agent define a generic software processes model, offering some alternatives, from which, we can
generate specifics software processes (Real agents). The generation is done according to an appropriate
behavior, and allows then the solving of a particular problem.
Owing to such model, we can define a formal agent that can be independent of any problem (Figure 6), and
from which, we can generate a real agent as an instance that can take part in development of specific software
processes.

Agent Edit;
Interface NormalEdit1, NormalEdit2;

{File, Boolean} <∅; ∅; ∋> → {F, EndEdit}

Agents

Functional Dependencies
<∅ ;∅ ;¬>→ {NormalEdit, PascalSyntax, PrologSyntax}
....

Organizational Dependencies
NormalEdit1 = ...; // Description of the first role
NormalEdit2 = ...; // Description of the second role
End Edit
Figure 6. Specification of the formal agent Edit.

203
7th ISPS’ Algiers May 2005 - Role based Software Process Modelling

For example, we can generate from this formal agent Edit two software processes, Editor1 and Editor2
respectively according to the roles NormalEdit1 and NormalEdit2. (Figure 4)
Therefore, according to need, we can define or modify different methodologies (behaviors). The instance's
methodology, generated from an agent, imposes to this last a controlled behavior that can be automated. This
vision offers a considerable benefit for software processes modeling.
We note that benefit of our approach is in the construction of methodologies of software processes that is
done with a modular manner by reusing composing agent's methodologies.

5. Related Work
In the IA approach, the rule concerns an activity and its interface with others, which make the dependencies
between activities implicit and informal. Against, in our approach, a rule of dependency relates two sets of
activities according to a coordination constraint, that make the methodology more explicit, more formal and
especially well structured (set, behaviour, agent). This approach has the possibility of formal verification of
methodologies and reasoning which it’s the support.
In the IA approach, the inference’s motor constructs the different possible alternatives when with the model
proposed, the alternatives to consider may be imposed by an explicit selection mechanism (description of
behaviour). In this context, IA approach is purely analogue to an inference’s motor with fixed strategy, when
in our approach; it can correspond to a motor with a programmable strategy (behaviour of agent).

6. Conclusion
In this paper, we have presented a modelling approach of software processes based on integration of
object oriented paradigm and coordination paradigm. The notion of coordination concept has allowed
expressing the methodological aspect, by formally defining the policy that lead it (rules determining the
activities and their organization,), and composing mechanisms (tools realizing activities and operating
according to this policy). We have proved that the construction of complex methodologies can be done with
modular manner by reusing the composing methodologies.

References
[1] Andersen E.P., Reenskaug T., “System Design by Composing Structures of interacting Objects”, In Ole
Lehrmann Madsen editor, Proceedings of the 6th European Conference on Object-Oriented
Programming.
[2] Atil F., Ghoul S., Meslati D., Bounour N., “Modeling Software process using roles”, 17th International
Conference on software & systems engineering and their applications (ICSSEA) Paris, 2004.
[3] Atil F., Ghoul S., “Object based software process modeling”, 1st UK Colloquium on object Technology
& System Re-engineering (COTSR), Demontfort University, Leicester, 1998.
[4] Blondo L., “Designing and Programming with Personality”, Master's thesis, University of Northeastern,
1998.
[5] Ghoul S., “Methodological and structural aspects in software processes models”, PhD dissertation,
University of Annaba, 1995.
[6] Kellner M.I., Hansen G.A., “Software Process Modeling: A case study”, Proc. of 22nd Annual Hawaii
Int. Conf. On System. Sciences, PP.175-188, 1989.
[7] Malone T.W., Rowston K., “The interdisciplinary study of coordination”, ACM Computer Surveys, Vol.
26, No. 1, PP. 87-120, 1994.
[8] McGregor J.D., Dyer D.M., “Inheritance and state machines”, ACM/SIGSOFT, PP. 61 - 69, 18 April
93.
[9] Meslati D., Ghoul S., “Semantic classification: A genetic approach to classification in object-oriented
models”, Journal of Object-Oriented Programming, January 1997.
[10] Pernici B., “Object with Roles”, Proc. of conference on office Information Systems (COIS),
Cambridge, Massachusetts, 1990.
[11] Rueher M., Michel C., “Using objects evolution for software processes representation”, Proc. of 22nd
Annual Hawaii Int. Conf. On System. Sciences, vol. 11, 1990.

204