Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/30—Monitoring
  • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
  • G06F11/3447—Performance evaluation by modeling
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/30—Monitoring
  • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
  • G06F11/3457—Performance evaluation by simulation

Definitions

• the invention lies in the field of performance analysis by simulation of a system, such as for example a telecommunication system comprising a plurality of distributed hardware and software components and cooperating to provide a service to one or more users .
• the invention more specifically relates to a method for generating a performance model from a functional model of such a system.
• the performance study allows to know in a precise way the distribution of the resources of the system and thus to identify possible bottlenecks.
• a second objective is economic. It is a question of determining the optimal configurations of the resources, in order to maximize their efficiency and thus avoid the purchase of additional equipment.
• the dimensioning of the resources consists in determining the quantitative parameters necessary for the desired quality of service such as for example the size of the buffers, the number of servers, the distribution of the treatment entities on the different machines, etc.
• a performance study is carried out either on a model or on the real system by measurements.
• the transient behavior When it is on a model, one can generally observe two types of behavior of the studied system, the transient behavior and the stationary behavior. The first is for short periods and the second for long periods.
• the most sought-after approaches include mathematical techniques, discrete simulation, and graph-based analysis.
• Notations for expressing models are often of the following types: - queuing systems,
• Queuing systems remain one of the most powerful mathematical formalisms for quantitatively analyzing a very wide variety of systems.
• a computer system can be considered, in a very abstract way, as a set of hardware and software resources
• the formalism of the Petri nets is based on a graphical representation which makes it possible to understand the behavior of the system. This formalism is particularly suitable for systems whose behavior is strongly characterized by aspects of competition, synchronization, communication and cooperation.
• the system can be analyzed qualitatively (absence of interlocking, operating safety, etc.).
• a major handicap in the petri dish is the explosion of the number of states to consider when the complexity of the system increases.
• the analytic approach generally consists in expressing the behavior of the system in the form of an exact mathematical model resulting in closed formulas.
• the behavior of the system is then reduced to a set of variables linked together by equations.
• the main advantage of this analytical approach lies in the fact that it does not require a sophisticated support tool during the modeling and problem solving phases, which is particularly suitable for the upstream phases of application design. With this approach, it suffices to apply the formula to determine the quantities sought and especially to know the relative influence of the different parameters.
• This approach which currently requires strong assumptions (independence of events, server conservability, etc.), proves feasible for systems with a relatively simple functional architecture such as, for example, the study of switching systems of networks of networks. transport.
• the real-test approach consists, by means of an observation infrastructure (probes), to measure directly on the real system.
• the observation is generally done either at the software level or at the operating system level, or at both levels at the same time.
• This approach has the advantage of obtaining real results, in particular for the limit processing capacity of the system (scaling up).
• Measuring performance on a real system requires having a complete implementation of the system to be tested (hardware and software), therefore the study can be conducted only after the event, and may involve purchases of expensive equipment.
• the realization of a probe to inspect the system is a difficult task because the instrumentation must not significantly disturb what is measured. In particular, the distribution of the machines requires a satisfactory synchronization of clocks.
• any software or hardware modification entails additional implementation costs in terms of interoperability and portability, reconfiguration, and adjustments.
• the test programs must be developed and tested themselves and are strongly linked to the actual code of the application, which is even more restrictive than the development and development processes. putting into operation of an application are short. It is therefore often necessary to develop the application and the test programs in parallel, which leads to strong synchronization constraints at the level of the development organization.
• the actual tests suffer from a limitation that comes from the fact that only simple configurations can be considered. For example, the processing capacity is evaluated by testing the behavior of the system when service requests arrive simultaneously. On the other hand, to know the evolution of the response time
• the simulation approach seems by far the most used for evaluating the performance of all kinds of systems and involves modeling the behavior of the system, most often using a queuing system or a Petri net, then experimenting the model by varying a set of parameters corresponding to the different configurations of the system.
• the parameters can be processor speed, network transmission rate, process scheduling policy, number and topology of machines, rate and rate of arrival queries, etc.
• the simulation is easier to understand, and more powerful than the analytical method.
• the formulation of the model to be simulated is not expressed in the form of equations but of programs, which makes it possible to construct a model as close as possible to the real system studied. It is much less expensive in hardware and software than the test approach because it exploits a model (an abstraction, a virtual representation) instead of a real system. This approach provides a powerful tool for predicting performance from the design of the system to be studied to completion.
• the execution time of a simulation is not related to the actual processing times of the application.
• the simulation approach allows for a more large number of scenarios by simply varying the parameters of the model.
• the development of a model often makes it possible to state conjectures about the system in question and to have a better understanding of some of the answers to the problem of performance.
• the simulations will confirm or refute these conjectures.
• Other elements, such as the distribution of end-to-end response time or loss rate, are most often very difficult to quantify and only the simulation makes it possible to highlight them.
• the simulation approach takes place in four phases: • the development of the system's behavior model: it starts with the selection of the entities of the system (a software component, a process, etc.) that it is wise to model, in relation to the specific objectives of the performance study. The elaboration continues with the description of the functioning of these entities, as well as their interactions.
• the entities are chosen according to the desired fineness of the results of the simulation, but also according to the initial data that can be provided. Parameters are significant features of system elements (eg, unit processing time of an entity on a processor, number of servers, etc.), which are likely to influence the simulation results.
• the models are generally represented either by queuing systems (QNAP, SIMSCRIPT, SES / orkbench), or by PLCs (OPNET), or by Petri nets.
• this data corresponds in particular to the processing times of the programs on the processors and to the transmission delays if routing through networks take place. They are measured by unit tests.
• simulations and the collection of statistical results the behavior of the system is observed by running the model using a simulator and varying its parameters; the results of each simulation are analyzed and performance results are deduced for the selected configurations.
• validation of the simulation model the confidence that can be granted to the results of simulations requires validation of the model. It consists in carrying out some carefully selected representative real tests and in comparing these real results with those obtained by simulation.
• the simulation approach is a good compromise between the cost of implementation and the value of the results.
• it allows to study the behavior of a system or an application under a large variety of configurations. This without having all the infrastructure system target (hardware and software) and, for applications, without doing the full development.
• it is ideal for comparing different technologies or products, as well as for sizing and optimizing the system being developed.
• Timed SDL [F. Bause and P. Buchholz, "Qualitative and Quantitative Analysis of Timed SDL Specifications," in N. Gerner, HG Hegering, J. Savolvod, (Eds.) Springer-Verlag, 1993] implements a form of timed transition systems, constructed at from an SDL specification in which at each transition, an exponential duration is attached. It does not include notions of resources or burden. From an intermediate representation in the form of an automaton, the tool performs qualitative and quantitative analyzes using Markovian type algorithms.
• the 15 blocks run in a multitasking mode. Channel delays and reliability characteristics can be added.
• the model runs on a virtual machine that is derived from the SDL model.
• the systems can be simulated or run on existing hardware emulators (Intel ® , Motorola ® and Siemens ® ). They are stimulated by traffic generators and are interconnected by transmission links
• DO-IT Toolbox [A. Mitschele-Thiel and B. MUlier-Clostermann, "Performance Engineering of SDIJMSC Systems,” Journal on Computer Networks and ISDN Systems, Elsevier, 1998] performs performance evaluation of specified systems in MSC and SDL. Its originality is to start from MSCs that are available very early in the life cycle, adding load annotations and specifying the resources available for specific executions of the system. It provides a simple performance evaluation technique for the analysis of bottlenecks and optimization of implementations, based on deterministic time of service assumptions.
• EaSy-Sim [C. Schaffer and R. Raschhofer, A. Simma, "EaSy-Sim A Tool Environment for the Design of Comnplex, Real-Time Systems", Proceeding International Conference on Computer Aided Systems Technologies, Innsbruck, Springer-Verlag, 1995] is a coupling between the GEODE environment for SDL and the SES / Workbench simulator.
• the SDL environment is used for functional verification and validation, while SES / Workbench models the non-functional part to evaluate performance.
• the coupling is implemented by message exchanges between the executable code of the application obtained by GEODE and the SES / Workbench simulator.
• This tool can be applied to an MSC specification in which response time requirements are added for real-time systems [C.
• EDT Erystron Transfer Tool
• M. Hendaz "5 Dynamic Annotation for Performance Evaluation of Specified Systems in Estelle", doctoral thesis at Paris 6 University, 1996.
• the translator transforms an Estelle model into an intermediate model, annotated with
• the simulator / debugger (Edb) based on the semantic model defined in the Estelle standard, contains a set of special functions allowing
• LQN LayerQN
• SPEED Software Performance Engineering Early Design
• CU Smith and LG Williamns, "Performance Engineering Evaluation of ObjectOriented Systems with SPE-ED,” Computer Performnance Evaluation Modeling Techniques and Tools, no. 1245, Springer-Verlag, Berlin, 1997] is a tool for evaluating architecture and alternative solutions for the design of object systems.
• the functional specification of the system is in the form of sequence diagrams representing traces of executions
• the tool transforms the specification model into a performance model represented by a queuing system.
• a combination of analysis and simulation can identify potential performance issues, such as bottlenecks.
• TLC Race-Based Load Characterization
• LQN layered performance model
• the traces - Message Sequence Charts - are obtained by simulation of an SDL model, but must be annotated in order to explain the causal dependencies that exist between the different actions performed. By an analysis of the detailed events of the simulation, the annotations of the traces are produced according to an incremental marking principle, which is similar to the blood staining technique used in radiography, the angiogram.
• communication schemes conventional in software systems, are identified, in practice, each message is assigned a type, which can be "RPC" (remote procedure call), "Forward” (RPC propagated to a third party), "Reply” (response to a RPC), or " Async "(asynchronous transmission of a message).
• RPC remote procedure call
• RPC forward
• Reply response to a RPC
• Async Async
• the Markov hypotheses are omnipresent. They can possibly be checked on simple systems. However, they generally do not apply in the case of complex systems in which many interactions take place. To make Markov's hypothesis then returns to consider a rather rough approximation of the real system, for want of a better one.
• most approaches introduce temporal annotations within the functional model. The resulting performance model generally has far too much functional detail, which is irrelevant from the point of view of performance, which undermines the effectiveness of simulation programs.
• the latest TLC approach is appealing in that it considers a finite set of scenarios, rather than a complete description of the system.
• the targeted LQN model introduces high-level concepts which, in order to promote the human understanding of the system, are both rigid and artificial performance analysis, and restrictive in terms of expressiveness.
• the TLC approach seeks to automate the identification of the causal links between the different events of a scenario, which seems very delicate in the general case.
• the reaction of a system to a stimulus is often conditioned not only by this stimulus but also by the internal state of the process; however, the TLC approach focuses on identifying trigger factors of the external stimulus type (messages).
• the object of the invention is to overcome the shortcomings of the systems of the prior art described above by means of a method adapted to service platforms, the main result of which is the automatic production of a performance model. , from a functional model of the studied system.
• the generated performance model is dedicated to the software simulators of the market based on the queuing systems.
• the functional model is expressed in the form of sequence diagrams with temporal data. Sequence diagrams can be derived from dynamic and complete modeling of the SDL or UML system.
• the method according to the invention comprises the following steps: - Distributing the representative requests of the system into a finite number of groups and identifying, for each group of requests, the corresponding execution flow, the distribution of said requests being determined by the service invoked and by the characteristics of the customer's own behavior, and the execution flow for each group of requests corresponds to the sequence of executions of software entities, in sequence and / or in parallel, induced by a request of the group.
• the performance model derived from the intermediate model developed is dedicated to pre-existing software simulators using queuing network techniques.
• the distribution of the system's requests into a finite number of groups of requests is determined by the service being invoked (its nature), and by the characteristics of the customer's own behavior which influence the way in which it is realized. the service invoked.
• the execution flow for each group of requests is determined by the sequence of executions of software entities, in sequence and / or in parallel, induced by a request of the group.
• the topology of the queuing model derived from the transformation is entirely determined by the execution streams corresponding to the groups of requests.
• the derivation of a performance model dedicated to a pre-existing simulator based on queuing network techniques can be automated by adapting the proposed matching rules.
• the phase formalism is realized by means of an extension of the MSC (Message Sequence Charts) formalism, and the formalization of the graph of the phases and execution flows of a service using HMSC (High Level Message Sequence Charts) formalism is represented as a tree with:
• the formalization tree may further comprise:
• At least one node followed by several arcs oriented in parallel at least one node followed by several oriented arcs according to the choice of the next phase depending either on a condition external to the system (linked for example to a characteristic of the client) or an internal condition related to the current state of the system.
• the intermediate model developed comprises the formalized execution flows, associated with temporal data characterizing the behavior of software entities and their interactions, at least one specification of the resources describing the physical materials, and at least one environment specification representing user behavior.
• FIG. 2 schematically illustrates an intermediate model defined by the method according to the invention
• FIG. 3 schematically illustrates the association of the different elements of the intermediate model and the primitives of the SES / Workbench simulator based on queuing systems
• FIGS. 4a to 4h schematically illustrate the rules of correspondence between the annotated events characterizing the behavior of software entities and primitives of the SES simulator
• FIG. 5 schematically illustrates an SES sub-model derived from a formalized execution stream by applying matching rules illustrated in FIGS. 4a to 4h
• FIG. 6 represents an SES sub-model of the overall system architecture obtained by applying matching rules illustrated in FIG. 3
• FIG. 7 schematically illustrates the phase tree representing the different steps for the realization of an audio-conference service according to the process of the invention
• FIGS. 8 to 10 represent the execution flows extracted from the phase tree for the audio-conference service
• FIGS. 11 to 20 show diagrams of the phases of the behavior of the service provided
• FIG. 21 shows the resource declaration, execution flows, and sub-model of the global architecture of an audio conferencing platform in the SES model
• FIGS. 23 to 25 represent the SES sub-models derived from the various formalized execution streams by applying matching rules illustrated in FIGS. 4a to 4h.
• the method according to the invention uses queuing systems. This choice is linked to the fact that most of the most advanced performance simulators on the market use the queue network model for the most part. These workshops show a notorious maturity, both in terms of the wealth of features, quality of analysis and robustness. Recall that a model of a queuing system focuses on the aspects that have an effect directly or indirectly on the consumption of the resources of the system (processors and memories of the machines, bandwidth of the transport networks).
• the method according to the invention makes it possible to model essentially:
• a distributed software system typically consists of a set of software entities
• Clients are queries sent by users invoking services provided by the system.
• the topology of the queued system it is determined entirely by the execution traces. Indeed the arrival of a request in the system causes the execution of actions on the servers. These actions can evolve simultaneously (in parallel) or synchronize in sequence. Each execution trace is thus represented by a server tree.
• the overall topology of the queuing network is such that all traces of execution are covered. Before modeling the model, it still needs to be completed with an environment model and a resource model. The first characterizes user behavior, in terms of throughput and statistical distribution of inter-arrival times.
• the second specifies the duration of execution of each entity when the machine is entirely dedicated to it (unit tests), the transmission delays characterizing the capacity of the networks and the scheduling policy of the competing treatments.
• This data can be integrated into the functional model of the system. Simulation involves injecting a very large number of queries into the model. One optimizes the use of the resources of the system by seeking a good configuration (or parameterization) of the various elements of the model. The quality of the overall configuration is evaluated in student by simulation its impact on the load of the servers, on the occupancy rate of the buffers, and on quantities characterizing the quality of service: the response times of a particular component or the system (from end to end), the maximum processing capacity (volumetry), etc.
• the approach proposed by the invention is applicable to systems whose behavior can be reasonably summarized by a limited set of execution scenarios. Ideally, the chosen scenarios will evolve independently of each other. Nevertheless, systems involving dependencies between scenarios are acceptable (in the event of interaction between two clients for example), as long as these dependencies remain clearly expressible by the designer. In this sense, the service platforms constitute a concrete field of application for the implementation of the invention. Indeed, the use of this type of platform can often be characterized by a reasonable number of scenarios, which correspond to the different cases of use of the platform (in other words, to the processing of the different requests issued by the users when invoking services), and which weakly depend on each other.
• the true starting point for the Generation of a queued performance model consists in distributing the requests representative of the system in a finite number of groups of requests and in identifying (step 2), for each group of requests, the corresponding execution flow.
• This makes it possible to determine the overall topology of the queued system so that all the execution traces induced by representative queries are reflected therein.
• Representative queries are those whose transmission frequency in the system is significant.
• the distribution of these requests is determined on the one hand by the service invoked; and on the other hand, by the characteristics of the customer's own behavior that influence the way in which the service is performed (see the example of Audio Conferencing).
• the execution flow for each group of requests it corresponds to the sequence of executions of software entities, in sequence and / or in parallel, induced by a request of the group.
• each service of the system is represented in the form of a tree with the following characteristics: the nodes of the tree represent the phases constituting the service.
• a particular node, the initial node, is the phase that initiates the service; an oriented bow leading from a knot to a other represents the sequential sequence of two phases
• FIGS. 8 to 10 illustrate the execution flows extracted from the phase tree (FIG. 7) in the example of the audio-conference service. Formalization of execution flows
• Step 4 of the method (FIG. 1) consists in formalizing the execution flows using a notation that makes it possible to highlight the interactions between the different software entities involved in the execution flows and the information characterizing the execution. consumption of system resources.
• this formalization is based on the Message Sequence Charts
• MSC is optimal if the chart is produced as a system run trace.
• an executable specification of the system can be produced in SDL, which happens to be a formalism closely related to MSCs in terms of semantics.
• SDL tools are able to produce simulation traces in the MSC format. These same tools also offer the possibility of manually editing such diagrams, and it is thus possible to proceed without using the simulation of an SDL model.
• the events that appear on an MSC chart focus on functional aspects: sending or receiving messages, actions, arming, or timing out, and so on. In reality, this level of information is irrelevant or insufficient for a performance model: for example, the name of the messages does not matter.
• chaining conditions which specify to what extent the execution of a stream can continue.
• a chaining condition is either waiting for the expiration of a delay or the validity of a Boolean expression. It can be seen as a door blocking the pursuit of execution, and the components of the condition as the keys that must be collected to cross that door. These keys must be defined by the designer and serve to indicate the realization of certain facts which then contribute to the validation of the chaining condition. These keys will typically be represented by Boolean flags such as for example_connected_user. nb_max_tentatives_atteint, etc.
• Step 6 of the method is to define an intermediate model to allow the automatic transition to a performance model.
• this model is composed of the formalized execution flows (10) characterizing the behavior of software entities and their interactions, a resource specification (12) describing the physical materials, and a environment specification 14 representing user behavior.
• the resource model contains the following declarations: - machines, buffer size and simultaneous processing scheduling policy of these machines; transport networks and their topologies for connecting machines; software entities (single-threaded programs), and their distribution over resources;
• Step 8 of the process ( Figure 1) consists in defining rules of correspondence between the elements of the intermediate model and the primitives of a general-purpose simulator based on queuing systems. The transformation becomes automatic when these matching rules are applied. The latter apply - as well to all simulators in this category: all are based on the same basic concepts, only the mode of representation of these concepts differs. The consistency of the transformation is based on semantic rules
• Figure 3 schematically illustrates the rules of correspondence between the intermediate model and SES / Workbench "nodes".
• R ⁇ machine_l, ..., machine_m ⁇
• F ⁇ flowFormExec_l, ..., flowExecFormalized_n ⁇ all the machines of the system declared in the resource model and the set of formalized execution flows system services:
• the environment model 14 is associated with a "source” node 20, possibly followed by a “submodel” node 22.
• the latter is useful in more complex cases, for example in the case of requests structured in sessions or several levels ;
• the resource model 12 containing the declaration of the set R of m machines is associated with a set of m nodes "service” denoted by a logical name (server_j for example), for all j;
• the primitive "EXEC (t)” is associated with a sequence of two nodes: a "user” node, followed by a “service reference_to” node.
• the user node is used to specify the value of t corresponding to the code execution time, while the service reference node refers to the service node declared in the module corresponding to the machine hosting the process that performs the EXEC (t) rupe
• the primitive "DELAY (t)" is associated with a node “delay” ( Figure 4d) and the value of t is the parameter of the node.
• the chaining condition “EXPECT” is associated with a "block” node, where it is expressed by a Boolean expression c given as a parameter of the node (FIG. 4e).
• the sequential sequence of events is represented by an arc between the nodes ( Figure 4f).
• the choice of a sequence of events among N possible sequences is represented by N arcs starting from the node where the choice takes place.
• the conditions determining a choice are specified in the corresponding arc ( Figure 4g).
• FIG. 4h illustrates the separation of the stream into N parallel branches.
• FIG. 5 illustrates the sequence corresponding to the submodel of a formalized execution stream completed by an "enter” node and by a “return” node which respectively represent the input and the output of the submodel.
• Figure 6 illustrates the overall architecture of the system, which brings together the runtime submodels and the environment sub-model.
• Example of application Audio-conference platform Informal presentation of the audio-conference service.
• the Audio-conference service allows a specific number of users, with prior agreement, each on their own side and at an agreed date and time, to dial a number to establish a communication to a conference bridge .
• the reservation of a conference bridge previously made by one of the participants, which specified the date, time, duration and number of participants.
• the realization of the conferencing session service offered by the Audio-conferencing platform depends on the role (nature) of the client invoking it:
• This classification makes it possible to identify the different types of requests.
• one type of query may interact with another. For example, the processing of the request of a simple participant in an audio-conference session is suspended until the arrival of the organizer of this session.
• a special role is assigned to the Conference Organizer.
• the 'Conference can not begin before the arrival of the Organizer, that is to say that the participants can not be connected to the conference bridge as one organizer is absent.
• the conference is closed after the hang-up of the Organizer, and participants still in line will then be disconnected from the conference deck.
• the subscription which consists mainly of the reservation of an access number to the conference bridge, takes place through the service provider.
• the data is consequently retrieved from the database.
• a participant dials the access number to the programmed conference (NAS service access number). This number is composed of a service-specific OZABPQ prefix, while the MCDU suffix is
• the service translates the service access number to the real conference bridge access number (NAC).
• NAC real conference bridge access number
• the service rejects the call with a saturation message.
• SDF Service Data Function
• the data modifiable by the call processing are in a database accessible in read and write by call processing scripts, this database must provide greater access performance. This last type of data is represented here by the maximum number of participants, and by the state of the resource.
• the first step is to identify the elementary phases and their organization into a phase tree.
• Figure 7 illustrates the global phase tree which describes the sequence of the different phases by specifying the internal or external alternatives. External conditions are recognized by the fact that the resulting arches carry statistical percentages.
• an external alternative identifies whether the user is the organizer (P2) or a simple participant (P4). If the user is a participant, an internal alternative ⁇ nbParticipants ⁇ MAXl ⁇ , whose option depends on the execution of other scenarios, identifies whether the maximum number of participants is reached or not. If this number is reached, a phase for sending a saturation message is initiated (P6). If this maximum number is not reached (P5), a second internal alternative ⁇ organizerPresent ⁇ makes it possible to identify if the organizer is already present. If it is already present, the participant is connected to the bridge (P. 7, with prior in a greeting). If the organizer is absent, a waiting message is sent to the participant (phase P8).
• an external condition ⁇ participantPatient ⁇ makes it possible to distinguish the case where the participant is waiting for the arrival of the organizer (phase P10) and enters the conference (phase P7) at the arrival of the Organizer, of the case where the participant is rather of the "impatient" type, that is to say he hangs up after the announcement of delay broadcast in phase P9.
• the number of participants is reduced by one.
• the queries in the example are divided into three groups: queries sent by an organizer; requests sent by a single patient participant; and queries sent by a simple impatient participant. From the global phase tree, the three corresponding execution streams are then extracted by keeping only one branch of each external alternative: execution flow induced by the arrival of the organizer (FIG. 8) ; flow of execution induced by the arrival of a single patient participant ( Figure 9); flow of execution induced by the arrival of a simple impatient participant ( Figure 10).
• the second step of the process consists in identifying the keys and doors that influence the behavior of a use case from the behavior of one or more other use cases.
• a key related to the presence of the organizer is identified.
• the P3 phase, performed at the arrival of the organizer, includes the PUBLISH task (organizerPresent).
• nbParticipants is increased by 1 when connecting a user (non-organizer), unless it is already worth its maximum allowed value (MAXI). This test is represented by an internal alternative in the phase tree.
• FIGS 11 to 20 show diagrams of formalization of the phases of service behavior, the MSCs associated with different phases of service behavior will be given with a simplified view of the signal names. Similarly, not all exchanges are indicated so as not to burden the schemes.
• the instances considered in these MSCs are: - the Service Data Function (SDF), the Service Control Function (SCF), the SRF (Service Resource Function or Platform) voice) and USERs.
• SDF Service Data Function
• SCF Service Control Function
• SRF Service Resource Function or Platform
• the signal exchanges correspond to: the interrogations of the database: • calling (callingNumber) queries the base on the calling number (P2, P4); • caller type is the answer of the base, it can take the values ORGANIZER (if the caller is the organizer) or PARTICIPANT (if the caller is not the organizer).
• Voice message exchange via the voice platform send_message to the voice platform, msg_info to the user (P6, P7, P9).
• FIG. 11 shows the formalization of the invocation phase of the service.
• Figure 12 represents the formalization of the "Organizer Identification” phase.
• Figure 13 represents the formalization of the "IdentificationParticipant” phase.
• Figure 14 represents the formalization of the "OpeningConferenceOpening" phase.
• Figure 15 represents the formalization of the phase "ConnexionParticipant”.
• FIG. 16 represents the formalization of the "DisconnectionSuiteASaturation" phase.
• Figure 17 shows the formalization of the phase "EntreeDansLaConference”.
• Figure 18 represents the formalization of the "AdvertRetardOrganizer" phase.
• FIG. 19 represents the formalization of the "WaitingOrganizer” phase.
• FIG. 20 represents the formalization of the "AbandonWaiting” phase.
• Figure 21 shows the general view of the intermediate model (in SES / Workbench). It contains: the statement of resources, the three streams of executions and the sub-model of the global architecture of the udio-conference platform.
• the SDF, SCF, and SRF processes each run on one machine.
• FIG. 22 An internal view of the overall architecture of the platform is shown in Figure 22.
• the initSession node initiates the creation of the maximum number of concurrent sessions allowed by the platform.
• the callSessionCode generates calls for each open session and the node interAppOrdre models the length of time between consecutive calls in a session and the rank of the organizer.
• each end of session represented by the closingSession node, triggers the creation of a new session represented by the creationSession node.
• Figures 23, 24, and 25 respectively show the three sub-models resulting from the transformation of the execution flows of
• the organizer a patient participant, and an impatient participant.

Landscapes

• Engineering & Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Bioinformatics & Computational Biology (AREA)
• Evolutionary Biology (AREA)
• Computer Hardware Design (AREA)
• Life Sciences & Earth Sciences (AREA)
• Quality & Reliability (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Bioinformatics & Cheminformatics (AREA)
• Debugging And Monitoring (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=28686286

Family Applications (1)

Country Status (5)

Families Citing this family (23)

Family Cites Families (3)

• 2002
  • 2002-04-23 FR FR0205063A patent/FR2838844B1/fr not_active Expired - Fee Related
• 2003
  • 2003-04-18 WO PCT/FR2003/001251 patent/WO2003092245A2/fr not_active Ceased
  • 2003-04-18 EP EP03747148A patent/EP1497732A2/de not_active Withdrawn
  • 2003-04-18 AU AU2003249151A patent/AU2003249151A1/en not_active Abandoned
  • 2003-04-18 US US10/511,033 patent/US7536292B2/en not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events