Understanding and maintaining the source code of industrial-scale software product is hard and time-consuming, and it is getting more difficult when the software implements parallel/concurrent/distributed computations and behaviours. Static source code analysis tools support program comprehension through detecting dependencies and relations among small (like functions and processes) or large (modules and components) software elements. For Erlang, which is a dynamic language, only an approximation of the real dependencies can be calculated statically. However it is possible to improve these analyses by adding application specific information, such as the most frequently used behaviours. In this paper we introduce an extension of the RefactorErl static source code analyser framework for Erlang that adds information about generic server behaviour implementations to the Semantic Program Graph of RefactorErl. In addition we define several views of the generic server based hidden communication.
Tools that support the software development life-cycle (such as code comprehension tools, refactoring tools, visualisation tools, test selection tools, test coverage checkers, etc.) are frequently used by the industry. These tools can reduce the time of bug fixing, code change requests, new feature requests and they also help to decrease the number of faults in the system.
Static analyser tools extract information from the source code without executing the program. Static analysis is not straightforward for sequential programs and it is getting more difficult when we are to analyse complex concurrent or distributed software.
Erlang [
Erlang provides patterns (so called behaviours) for concurrent and distributed application design. There are
several behaviours in the Erlang/OTP [
The rest of this paper is structured as follows: Section 2 introduces the basic communication primitives of Erlang and the generic server behaviour; Section 3 introduces RefactorErl and the Communication Graph; Section 4 presents the Erlang generic server analysis and visualisation; Section 6 shows an example of the resulted model;
2
Originally, Erlang was designed for developing concurrent and distributed software systems with soft real-time characteristics. Erlang supports process creation and communication between processes with built in language constructs.
To start processes one can use the spawn* functions with different options, for message sending the ! operator and for receiving messages the receive construct. Processes can be accessed either with their process identifier (pid ) or can be registered and accessed by the registered name. 2.1
Behaviours
Beside the communication primitives the Erlang OTP comes with a set of design patterns, so called behaviours [
• gen_server – Generic server pattern for client-server applications. • gen_fsm – Generic finite state machine.
• gen_event – Generic event handler.
Besides the standard behaviours we can extend the above list by defining our own behaviours. For this, we have to define the required interface of the callback module and implement the general part of the behaviour. 2.2
Generic server behaviour In this paper we focus only on static analysis of source codes implementing the gen_server behaviour. Let us introduce briefly the main features of the generic server behaviour, the additional features can be handled analogously. In Section 6 the reader can find an example source code.
The interface functions of the gen_server module are: • start*/3,4 – The function starts the server with the provided callback module, arguments and options. The server can be accessed by its pid or, if it is registered, by its name. The visibility of the registered server can be local or global. For setting up the server process it uses the init/1 function from the callback module. • call/3,4 – This function is for synchronous communication. The function sends the given request to the addressed server and waits for the response. The calling process is suspended until the reply arrives. Optionally it can be given a timeout value, that causes the function call to fail if there is no reply within that time. • cast/2 – This function is for asynchronous communication. The function sends the given message to the addressed server asynchronously. • reply/2 – With this function the server can send messages directly to the client. It can be used for delayed answers to the client. 2.2.2
Callback module The callback module can be divided into two parts, the server API and the callback functions. The API functions depend on the purpose of the server: starting and stopping the server, interface functions to hide the communication with the server and forward correctly the requests to the server.
Let us describe only the subset of the callback functions that are the most relevant to our analysis: • init/1 – The function is called when the server is started, it initialises the server process using the input arguments. • terminate/2 – The function is evaluated if the server is stopping, it performs the necessary clean up operations according to the provided reason of stopping and state of the server. • handle_call/3 – The function is called when a synchronous request arrives to the server. The function gets the request data, the client id and the current state of the server. There are three different types of return values: – reply : The return encloses the reply message to the client request, the new server state and an optional timeout value or the hibernate atom. If timeout option is used, a timeout will occur if there is no new request within this time. If the hibernate option is used, the server goes into hibernation until the next request arrives. – noreply : There are situations that require to delay the answer to the client, this option can be used in this case. The return value encloses the new state and an optional timeout value or the hibernate atom. The delayed answer can be returned to client later on with the reply/2 function. – stop : The return value must enclose the reason of stopping, the new state, and an optional reply to the request. If the request is not provided the reply must be handled with the reply/2 function directly.
This return value causes the server to stop, the terminate/2 function is evaluated.
• handle_cast/2 – The function is called when an asynchronous request arrives to the server. The function
gets the request data and the current state of the server. There are two possible returns of this function:
– noreply : The return value encloses the new server state and an optional timeout value or the hibernate
atom.
– stop : This return causes the server to stop. The return value encloses the reason of stopping and the
new state of the server.
• handle_info/2 – The function is called when a message arrives to the server (in other ways than the provided
gen_server interface functions) or a timeout occurs. The server handles the message as asynchronous
communication, the return values are the same as at the handle_cast/2.
RefactorErl [
As the basis of further analysis RefactorErl uses a Semantic Program Graph (SPG ) to represent the Erlang source code in a data structure designed to efficiently store and reuse the calculated lexical, syntactic and semantic information. The tool has an asynchronous semantic analyser framework and provides several built-in analyses: variable scoping, static and dynamic function call, data-flow, module, record, specification analyses. 3.1
Semantic Program Graph schema The SPG can be described as the following hextuple: SP G = (N; AN ; AV ; A; T; E), where: • N is the set of nodes, • AN is the set of attribute names, • AV is the set of possible attribute values, • A : N
AN ! AV is a node labelling partial function, • T is the set of edge labels, • E : N
T
N0 ! N a partial function that describes labelled, ordered edges between the nodes.
The set N corresponds to the three layers of the SPG, it is the union of the lexical, syntactic and semantic nodes:
N = Nlex [ Nsyn [ Nsem
Nsyn = Nfile [ Nform [ Nclause [ Nexpr The set Nsem contains nodes of several different classes, like module, function, variable, pid, behaviour, etc.
Nsem = Nmodule [ Nfunc [ Npid [ Nbehaviour [ ::: In further sections we use the N ode 2 Nx notation which means that N ode is a node of class x. 3.2
Nodes in the SPG We introduce the node classes that are necessary for the generic server analysis: • ROOT: Root node of the SPG • Expr: Syntactic nodes representing expressions. The type attribute of the node describes the type of the given expression, e.g. tuple, list, application, function parameter, etc. • Clause: Syntactic nodes representing the clauses of functions and expressions. • Func: Semantic nodes representing functions. The node describes the arity and the name of the function. • Module: Semantic nodes representing modules. • Behaviour: Semantic nodes of behaviours. Its type attribute describes the represented behaviour (e.g.
gen_server). • Pid: Semantic nodes representing processes. A node can either belong to a behaviour process or it can be an interface function that can be started as a separate process. 3.3
Data-Flow Reaching
To determine the identifiers of processes and the recipient of the messages we use data-flow analysis [
Behaviour nodes in the SPG The behaviour analysis is performed when a file is being added to the database of RefactorErl. It extends the SPG with the behaviour information of modules. Whenever a behaviour attribute form is discovered in the source code, a new semantic node and a new edge with the label beh is inserted between semantic module node and the newly added behaviour node. Formally: M odule b!eh Behaviour 3.5
Process analysis
The process relations are represented in the Semantic Program Graph as described in [
The process discovery analysis examines the function applications which can start new processes, these are erlang:spawn/1,2,3,4 and erlang:spawn_link/1,2,3,4 and other spawn_* function applications. For each discovered process a new semantic Pid node is created in the SPG. The algorithm tries to extract as much information as possible about the started processes, such information are for example the registered names. Messaging primitives such as send/2,3 function applications and receive expressions are examined as well to identify the communication between the processes.
The process analyser identifies gen_server processes and the synchronous and asynchronous requests from clients
to servers [
SPG edges Besides the semantic process identifier nodes several edges are created in the SPG to describe the communication between gen_servers and clients: pid • pid: from the root node of the SPG to the process identifier nodes: ROOT ! P id • eval_in: any expression that performs message passing (via communication primitives or gen_server interface functions) is connected to the process it is evaluated in: Expr eva!l_in P id 1RefactorErl analyses the sources with its asynchronous incremental analyser framework, where each Erlang form is analysed in a separate Erlang process. When we rely our analysis on interfunctional information, such as data-flow, we have to run our analysis after the initial analysis is finished for the whole graph. These kinds of analyses are called post analyses. • sync_call: process identifier nodes that perform gen_server:call/2,3 are connected to the Pid node of the gen_server process: P id sny!c_call P id • async_call: process identifier nodes that perform gen_server:cast/2 are connected to the Pid node of the gen_server process: P id asyn!c_call P id 4
The gen_server analysis extends the behaviour nodes with the gathered information and adds new edges that represent the communication between processes. The analysis uses the information from other analyses like behaviour, process and data-flow analyses.
The analyser first identifies the generic servers and for each server its possible registered name is determined. Next the algorithm examines the communication between processes. The algorithm looks for expressions that could potentially send messages to the gen_server process (using messaging primitives, synchronous or asynchronous message passing) and it determines the possible reply values based on the sent messages. The sent messages and possible replies are stored in the behaviour node. The next step is to insert new edges to the SPG. New edges are inserted between the behaviour node and functions that define, start or stop the server, and to functions that initiate message sending to the server process. 4.1
Semantic Program Graph extension The SPG schema is extended to allow for storing communication information in behaviour nodes and the addition of new edges into the graph.
M essages Npid T erm Nexpr Nclause P(T erm)
1. P id 2 Npid: The semantic process identifier node in the SPG of the message sender process. 2. M essage 2 T erm: The sent message, an Erlang term. 3. Expression 2 Nexpr: The expression node in the SPG that performs the message sending. 4. DestinationClause 2 Nclause: Syntactic node of the function clause that handles the message. 5. Replies 2 P(T erm): A list of Erlang terms that are possible replies to the message from the server side. The message sending could be represented as edges from the process identifier nodes to the handling function clause with the message as the edge label. The reason why we introduced this complex attribute instead of edge labels was that the RefactorErl database has a fixed schema. This means every edge label has to be declared in advance, they cannot be changed dynamically. The advantage of this representation is that there is no need to perform costly queries in the graph, every piece of information is accessible directly from the semantic behaviour node.
The following new edges are introduced to the SPG: • gs_def: Connects the gen_server behaviour semantic node to the init/1 function in its callback module. • gs_call: Connects the gen_server behaviour semantic node to those functions that apply the gen_server:call/2,3 function thus sending a synchronous request to the server process. • gs_cast: Connects the gen_server behaviour semantic node those functions that apply the gen_server:cast/2 function thus sending an asynchronous request to the server process. • gs_start: Points from the gen_server node to those function nodes that could start server process. These functions either call the gen_server:start/3,4 or gen_server:start_link/3,4 functions. • gs_stop: Points from the gen_server node to those function nodes that could stop the server process. These functions call the gen_server:stop/1,3 function.
• gs_pid: Connects the gen_server node to the Pid node, representing the server process. As the first step of the gen_server analysis it performs the process analysis. This step is shown in Algorithm 1, as the analyse_processes() subroutine call. After this we query the gen_servers from the graph by calling the genservers() subroutine and we apply the analysis for each found gen_server.
Algorithm 1 analyse_genservers() 1: analyse_processes() 2: GenServers genservers() 3: for Server 2 GenServers do 4: analyse_genserver(Server) 5: end for The algorithm for the genservers() subroutine is described in Algorithm 2. The subroutine filters and returns the set of behaviour nodes of type gen_server.
Algorithm 2 genservers() 1: GenServers ; 2: for Behaviour 2 Nbehaviour do 3: if is_genserver(Behaviour) then 4: GenServers GenServers [ fBehaviourg 5: end if 6: end for 7: return GenServers The abstract algorithm of extending the SPG with semantic knowledge about a gen_server is shown in
The routine gets a generic server semantic node as argument. As a first step the algorithm determines the possible names for the gen_server and updates the node. The second step is to determine the possible messages addressed to the examined server, the possible replies and update the node with the gathered information. The further steps are to insert edges between the examined gen_server node and its Pid node, init/1 function, and functions that make either synchronous or asynchronous requests, start or stop the server. Algorithm 3 analyse_genserver(GenServer) 1: update_with_name(GenServer) 2: update_with_messages(GenServer) 3: create_gs_pid_edge(GenServer) 4: create_gs_def _edge(GenServer) 5: create_gs_call_edges(GenServer) 6: create_gs_cast_edges(GenServer) 7: create_gs_start_edges(GenServer) 8: create_gs_stop_edges(GenServer)
The gen_server graph The SPG itself contains an overwhelming amount of information, although it can be visualised with RefactorErl it is not the most appropriate form for human readers. To extract information produced by the gen_server analysis one can either generate views on different abstraction levels or query the information directly from the SPG.
In Section 4 we have presented how the SPG is extended with gen_server specific information. The most comprehensible presentation of this information is through visualisation, therefore we defined the gen_server communication graph to present the message passing between server processes and their clients. We can generate the gen_server communication graph on three levels of abstraction, which correspond with the abstraction levels of the language itself (functions, function clauses, expressions): • Compact: Server processes, callback modules and functions sending requests to server processes are displayed, along with the gen_server:handle* functions. Request and message contents are the labels of edges leading to the handle functions from the function initiating them. • Normal: The compact view is extended with the clauses of the functions gen_server:handle*. The edges showing message passing are leading to the function clause handling them. • Detailed: The normal view is extended with the actual expressions performing a request or sending a message, these are the sources of the request edges in the graph. 5.1
Graph definition
Ggs = (Vgs; Egs) Vgs = Vserver [ Vmodule [ Vpid [ Vhandler [ Vclause [ Vexpr
Egs Vgs Vgs LABEL Where Vgs and Egs are the node and edge sets respectively. The set of nodes is composed of the following subsets: • Vserver: nodes of generic servers • Vmodule: nodes representing modules • Vpid: nodes of processes • Vhandler: nodes of gen_server:handle* functions of each server • Vclause: nodes of clauses of the gen_server:handle* functions • Vexpr: expression nodes (that initiate a request)
Egs is the set of labelled edges, where each edge is represented with an ordered triple. The elements of the ordered triple are the head node, the tail node and the label of the edge. The elements of the LABEL set are arbitrary
5.2
Graph building rules The graph building procedure can be described as declarative rules. The graph is built in a way that we match the rules on the SPG and build the corresponding genserver graph nodes and edges. There are several rules that are common for all three graph abstraction levels, and a few rules that are specific for the given abstraction level. General rules 1. gen_server node: If a behaviour node represents a generic server in the SPG, it will be present in the communication graph.
is_genserver(GenServer) ^ callback_module(M odule; GenServer)
GenServer0 2 Vserver ^ GenServer0:label = M odule:name 2. Callback module node: Each gen_server callback module is present in the graph, with the module name as a label.
callback_module(M odule; GenServer)
M odule0 2 Vmodule ^ M odule0:label = M odule:name 3. Callback module edge: From the gen_server node an edge with the label "callback module" leads to the callback module node.
callback_module(M odule; GenServer) (GenServer0; M odule0; "callback module") 2 Egs 4. handle_call/3 message handler: If a server callback module defines a handle_call/3 function, it will be present in the graph.
callback_module(M odule; GenServer) ^ M odule func F unction ^
! F unction:name = handle_call ^ F unction:arity = 3
F unction0 2 Vhandler ^ F unction0:label = M odule:name : F unction:name=F unction:arity ^
(M odule0; F unction0; "synchronous handler") 2 Egs 5. handle_cast/2 message handler: If a server callback module defines a handle_cast/2 function, it will be present in the graph 6. handle_info/2 message handler: If a server callback module defines a handle_info/2 function, it will be present in the graph.
callback_module(M odule; GenServer) ^ M odule func F unction ^
! F unction:name = handle_cast ^ F unction:arity = 2
F unction0 2 Vhandler ^ F unction0:label = M odule:name : F unction:name=F unction:arity ^
(M odule0; F unction0; "asynchronous handler") 2 Egs callback_module(M odule; GenServer) ^ M odule func F unction ^
! F unction:name = handle_inf o ^ F unction:arity = 2
F unction0 2 Vhandler ^ F unction0:label = M odule:name : F unction:name=F unction:arity ^
(M odule0; F unction0; "message handler") 2 Egs 7. Pid nodes: Process identifier nodes in the SPG will be present in the graph if they send a request to the server process.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages P id0 2 Vpid ^ P id0:label = P id:module : P id:f unction=P id:arity
is_genserver(GenServer) ^ M odule 2 Nmodule ^ (P id; M essage; Expression; DestClause; Replies) 2 g:messages ^
M odule:name = P id:module M odule0 2 VmoduleM odule0:label = M odule:name ^ (M odule0; P id0; "pid") 2 Egs 9. Function of clause:
F orm 2 Nform ^ Clause 2 Nclause ^ F unction 2 Nfunc ^
F orm fu!ncl Clause ^ F orm fu!ndef F unction
clause(Clause; F unction) 1. Requests: From every process that is a message source of a gen_server an edge leads to the proper message handling function, with the message as an edge label.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages ^
clause(DestClause; F unction) (P id0; F unction0; M essage) 2 Egs 2. Responses: From the message handling functions an edge leads to the process that originally sent a request.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages ^ clause(DestClause; F unction) ^ Reply 2 Replies (F unction0; P id0; Reply) 2 Egs
1. Function clauses: Each function clause of the message handling functions of the server will be present in the graph.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages ^ clause(DestClause; F unction)
DestClause0 2 Vclause ^
DestClause0:label = text(DestClause) ^ (F unction0; DestClause0; "f unction clause") 2 Egs 2. Requests: From every process that is a message source of a gen_server an edge leads to the proper message handling function clause, with the message as an edge label.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages
(P id0; DestClause0; M essage) 2 Egs 3. Responses: From the message handling function clauses an edge leads to the process that originally sent a request. The edge label is the response itself. Detailed graph rules 1. Function clauses: Each function clause of the message handling functions of the server will be present in the graph.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages ^ clause(DestClause; F unction)
DestClause0 2 Vclause ^
DestClause0:label = text(DestClause) ^ (F unction0; DestClause0; "f unction clause") 2 Egs 2. Message sending expressions: Each expression that is a message source will be a node in the communication graph.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages Expression0 2 Vexpression ^ (P id0; Expression0; "send expression") 2 Egs ^
Expression0:label = text(Expression) 3. Requests: From every expression that is a message source of a gen_server an edge leads to the proper message handling function clause, with the message as an edge label.
is_genserver(GenServer) ^ (P id; M essage; Expression; DestClause; Replies) 2 GenServer:messages
(P id0; Expression0; M essage) 2 Egs
4. Responses: From the message handling function clauses an edge leads to the process that originally sent a
request. The edge label is the response itself.
The introduced analysis technique has been applied to larger open-source project, such as RabbitMQ [
The vital parts of the implemented chat server are introduced in Figure 1. There is a macro definition SrvRef to make it easier to refer the server as it is registered globally. The functions of the server module are divided into three groups: interface function for managing (starting, stopping) the server, interface functions for clients (connecting to the server, sending messages) and the callback functions of the server.
The server can be started with the start/1 function. The argument of the function is the maximum number of simultaneous users. The function starts the server with the given name, callback module and initialising arguments.
Client interface The module provides interface function to the clients to hide specific information of the server. Such information is the name of the server and how to interact with the server process.
The client can connect to the server through evaluating the chatserver:connect/1 providing the nick as an argument. The function performs a synchronous request to connect to the server with the given nick. The client can disconnect from the server by calling the chatserver:disconnect/0. The function performs an asynchronous request that sends the server the quit message.
The texting to other chat clients is performed by the chatserver:send/1 function. The function sends the text and the pid of the sender to the server. Messages can be sent directly to the server with the chatserver:other_message/1 function.
The chatserver:init/1 function is called when the server is started, it performs the initialisation and returns the initial state of the server.
The synchronous requests sent with gen_server:call/2,3 functions are handled with handle_call/3 function defined in the callback module. In our implementation there is a synchronous request when a client initiates connection to the server process. When the request arrives the server checks whether the user limit has been reached. If there is no free space in the chat room, a deny message is replied to the caller. In this case the state remains unchanged. If the chat room is not full the user list is extended with the new member. The reply will be the ok atom, and the state of the server is updated with the new user.
The asynchronous requests sent with gen_server:cast/2 function are handled with the handle_cast/2 function defined in the callback module. In our example implementation there are three different cases. The first clause of the function handles the text broadcasting among the chat users in the chat room. It receives the message and the identifier of the sender. From the identifier the server determines the nick of the user (it is assumed that the sender is connected to the server) and sends the composed message for every member of the chat room. The second clause handles the disconnection request from the users. The server omits the requested user from the list of users and updates its sate. The third case is for stopping the server.
The requests/messages sent in a non standard way to the generic server are handled with the handle_info/2 function definition of the callback module. In our case any unexpected message causes the server to stop. 6.2
The client
The client is composed of two interface function start/1 and send/2 and two auxiliary functions loop/0 and input/1.
The function start/1 initiates the client process by sending a request connect to the server. The client is terminated if a deny message is received. If the connection succeeded it spawns the input reading process and continues executing the loop/0 function.
The send/2 function is an interface function for the server process. With the help of this function the server can send easily messages to clients. %% Macro definition of server reference -define(SrvRef, {global, chatserver}). %% Interface functions start(Max) -> gen_server:start(?SrvRef, chatserver, [Max], []). stop() -> gen_server:cast(?SrvRef, stop). %% Interface functions for clients connect(Nick) -> gen_server:call(?SrvRef, {connect, Nick}). disconnect() -> gen_server:cast(?SrvRef, {quit, self()}). send(Text) -> gen_server:cast(?SrvRef, {text, self(), Text}). other_message(Message) -> chatserver ! Message. %% Callback functions init(Max) -> {ok, #state{users = [], max = Max}}. handle_call({connect, Nick}, {Pid, _}, State = #state{users = Users}) -> if length(Users) >= State#state.max -> {reply, deny, State}; true ->
NewUsers = [#user{nick = Nick, pid = Pid} | Users], {reply, ok, State#state{users = NewUsers}} end. handle_cast({text, From, Text}, State = #state{users = Users}) ->
Nick = get_nick(From, Users), lists:foreach( fun(#user{pid = Pid}) ->
chatclient:send(Pid, Nick ++ ": " ++ Text) end, Users), {noreply, State}; handle_cast({quit, From}, State = #state{users = Users}) ->
NewUsers = omit_user(From, Users), {noreply, State#state{users = NewUsers}}; handle_cast(stop, State) -> {stop, normal, State}. handle_info(_, State) -> {stop, normal, State}. start(Nick) when is_list(Nick)-> case chatserver:connect(Nick) of deny -> io:format("Connection failed~n",[]); ok ->
Loop = self(), spawn(fun() -> input(Loop) end), loop() end. loop() -> receive quit -> chatserver:disconnect(), quit; {send, Text} -> chatserver:send(Text), loop(); {text, Text} -> io:format("~s~n", [Text]), loop() end. send(Pid, Text) -> Pid ! {text, Text}. input(Loop) -> case string:strip(io:get_line('--> '), right, $\n) of "#q" -> Loop ! quit, ok;
S -> Loop ! {send, S}, input(Loop) end. The input process iteratively reads the standard input and forwards the read text or command to the client process. The loop/0 function receives messages continuously and perform actions based on these messages. If the loop receives the quit message the client disconnects from the server and exits looping. If a tuple with the send tag is received a message is sent to the server process. If a tuple with text tag is received, that is a message from the server with text of other chat users, it is printed to the standard output and continues looping. The compact graph in Figure 3 shows the chatserver process, its callback module and the client module, chatclient. The message sending functions and the message handlers are featured as well, with the messages and responses as edges between them.
The normal graph (Figure 4) compared to compact graph contains the individual function clauses of the message handler functions. Each message is displayed as an edge from the sender to the handler clause. The detailed graph in Figure 5 is the extension of the normal graph with the expressions that perform the message sending. 7
Supporting code comprehension by static analysis tool is not unique, several tools exist for different programming
languages [
However the Erlang Verification Tool [
The paper [
Message passing analyses have been developed to build accurate data- [
Percept2 [
Akka [
Under the development and maintenance of a concurrent software the developer has to properly understand the source code. In this paper we have introduced a static analyser tool that detects and visualise the communication among processes implemented using the generic server behaviour and their clients.
We have introduced a static source code analysis and transformation tool, RefactorErl. An extension of its existing process analysis is presented to examine source code that implements a client-server architecture with
We have described the visualisation of the communication between server processes and the clients that use them, in the form of the gen_server Communication Graph. We have evaluated our tool on several open source projects and it was able to produce a useful view of the server.
In a distributed Erlang environment the process replacement is explicit, therefore the developer has to deal with this information as well. Thus as a future work we aim to extend our analysis with distributed node analysis. m o c F m o c