CC BY
13
YAK 681.32
REQUIREMENTS PARTICLE NETWORKS: AN APPROACH TO FORMAL SOFTWARE FUNCTIONAL REQUIREMENTS MODELLING
Wiwat Vatanawood, Wanchai Rivepiboon
Представлен подход к моделированию функциональных требований программного обеспечения. Предложены алгоритмы, реализующие рассматриваемый подход.
In this paper, an approach to software functional requirements modelling using requirements particle networks is presented. In our approach, a set of requirements particles is defined as an essential tool to construct a visual model of software functional requirements specification during the software analysis phase and the relevant formal specification is systematically generated without the experience of writing formal specification. A number of algorithms are presented to perform these formal specification transformations using predefined templates of formal specification schema of the requirements particles. The usability of the requirements particle networks is investigated by conducting a workshop. The result indicates that an analyst with experience in writing data flow diagram is capable to produce a complete and consistent requirements particle networks.
1. INTRODUCTION
There is still a wide gap between the current practice of software requirements engineering and the research on formal specification and software formal development since a formal specification of software system is difficult to write and understand. A number of active researches are conducted in order to extend the capability of software analyst and designer with the specific CASE tools to capture formal specification, including the relevant specification languages to ease the transformation of formal specification [1], [2] and the reverse engineering tasks - to transform program codes to formal specification [3]. It is practical for software analyst and designer to be able to investigate their software system specification in the early stage of the system development.
The Z notation is used in our research to describe formal specification. Since the Z notation is based upon set theory and mathematical logic, the process of constructing proofs can help us to understand the requirements upon a system and can assist us in identifying any hidden assumptions. Proof at the specification stage can make a significant contribution to the quality of software.
Our research is motivated by the work of Jin and Zhu [4] which the formal specification is automatically generated from requirements definition. Our objective is to extend the data flow diagram notations in some manners to explicitly capture precondition predicates happening in the required software system. The technique of decomposition is exploited to obtain a set of requirements primitives so that a well-defined formal specification template can be assigned. Each requirements primitive is expected to guide the identification of requirements patterns in the future work and the reuse of these patterns is feasible.
This paper is organized as follows. Section 2 describes a number of definitions and Algorithms. Section 3 describes the proposed model of software functional requirements specification and section 4 defines formal specification template for requirements particles. The specification procedure is guided in section 5. Section 6 reports the experiment to investigate the usability of the requirements particle networks. Section 7 concludes the paper and the future work is described in section 8.
2. DEFINITIONS AND ALGORITHMS
In this section, a number of definitions and algorithms are introduced and will be used later. The examples are illustrated at the end of this section.
Definition 1. A specification of software functional requirements SPEC is considered as a collection of rules that the target software system is obliged to follow as to accomplish user's needs. To provide a formal framework of how to write a unambiguous functional specification for software requirements engineer, the software functional requirements specification is formally defined as SPEC = ({RP}, CPS) where {RP} is a set of requirements primitives, and CPS is a connection description for {RP} . RP and CPS are defined in the next paragraph. In our approach, a connection description is defined as a schema in Z.
Definition 2. A requirements primitive RP is an essential action expected to perform a particular set of tasks that is required as part of software functional requirements. In our approach, a requirements primitive is formally denoted by RP = (FS(O), CRP(O)) , where FS(O) represents a set of formal specification defined on each O and CRP( O ) is a connection description for FS( O ).
Definition 3. A requirements particle network is a tuple O = ( V, P, D, ES, EM) . We define V = P u D . P is a set of vertices called requirements particle vertices. D is a set of vertices called data entity vertices. ES is a set of edges on P X P , called status edges. EM is a set of edges on VX V, called message edges. Let p, q e P and d e D , edges are
Status Message Message
written as p ^ q e ES, p ^ q e EM, d ^ q e EM . A requirements particle network is a network of requirements particles and associated data entity. Practically, software functional requirements specification is represented by a set of requirements particle networks.
Definition 4. A requirements particle P is an atomic node that performs a specific task which is required as part of a
requirements primitive RP. A requirements particle is formally defined as a collection of ordered attributes <Name, What, Where, Precond, Out, Ack, Nack>. Let ^ be a requirements particle, p.Name refers to attribute "Name" while the rest of attributes are referred as p. What, p. Where, p.Precond, p.Out, p.Ack, p.Nack, respectively.
The last six attributes are called communication ports. Each requirements particle communicates to outside world via these communication ports. A number of messages are received via "What" and "Where" port while precondition status is obtained via "Precond" port. "Out" port is used by each particle to forward postconditions to the successive particles. Boolean-value status will be transmitted to successive particles as well via "Ack" and "Nack" port.
Definition 5. A data entity D is the representative of data element or a set of data elements. Data entity D is defined as a ordered pair <Name, Type>. Let d be a data entity, d.Name refers to attribute "Name" and d.Type refers to attribute "Type".
Definition 6. A set of formal specification FS( O ) is formally defined as {FST(p, O)|p e P} , where FST(p, O) is a transform function defined in algorithm 1. A well-defined template of formal specification is assigned to match each p.Name. A collection of proposed template of formal specification is shown in fig 8 and figure 9.
Algorithm 1. Transform Function FST(p, O)
1. Select formal specification template that matches p.Name.
2. Substitute all the state variables named "What" with
Message
d.Name where d ^ p .What.
3. Substitute all the state variables named "Where" with
Message
d.Name where d ^ p.Where .
4. Substitute the state variables named "Precond" with the predicates of status edge from q.Ack or q.Nack where
Status
q e P and q ^p.Precond . Algorithm 2. Generating CRP( O )
1. Find p where p, q e P and there exists no such q that
Status
q ^p.Precond .
2. Define CRP(O ) as FST(p, O) a (CRP(OAck)v
v CRP(ONack)) where OAck is the sub network connecting to p.Ack and ONack is the sub network connecting to
p. Nack.
Algorithm 3. Generating CPS
Let rp be a requirements primitive, CPS is defined as
v rp . rp e RP r
Example 1. Let s be target SPEC then
s = ({RP}, CPS) and rp 1, rp2, ..., rpn e{RP} . For
requirements primitive rp ^ , see figure 4, such that rpi = (FS(a), CRP(a)) and let a be a requirements particle network O' then a = (V, P', D', ES, EM) and Pi,P2,P3,P4 e P , dp d3, d4, d5 e D'.
Message Message
Given that dj ^ p\. What, d2 ^ Pj. Where ,
Mess age Message Mess age
Pj. Out ^ P3. What, d4 ^ P2.What, d3 ^ P2. Where ,
Mess age Mess age Message
d2 ^ P^.Where , d5 ^ P^.What, d3 ^ P^Where e EM ,
Status Status
and Pj.Ack ^ P2. Precond, Pj.Nack ^ P3.Precond,
Status
P3.Ack ^P4.Precond e ES .
Then, FS(a) = {FST(p1, a), FST(p2, a), FST(p3, a), FST(pa, a)} and CRP(a) = FST(px, a) a (FST(p4, a) v v(FST(p2, a)a FST(p3, a))). While rPj is defined as rPj| the value of CRP(a) followed by all formal specification in FS(a). From algorithm 3, CPS is defined as rPj v rP2 v ... v rPn and specfication s is finally defined as
s | the value of CPS followed by all formal specification in
{RP}.
3. A MODEL FOR SOFTWARE FUNCTIONAL
REQUIREMENTS SPECIFICATION
In this section, a number of notations are defined to represent requirements particle, data entity and requirements particle networks. Software analyst is provided with a set of requirements particles and data entities to construct software functional requirements specification as desired.
Requirements Particle Notation
Each requirements particle is represented as a circle symbol with 6 communication ports, as shown in figure 1 and figure 2.
"Out" Port
"Ack" Port
Requirement
Particle J "Where"Port
"Nack" Port
"Precond" Port
Figure 1 - Requirements Particle Notation
'Boolean-value status'
'Boolean-value status'
Figure 2 - Sample of Requirements Particle "Retrieve" Data Entity Notation
Each data entity is represented as a rectangle symbol as shown in figure 3.
Data Entity
Video Stock
Figure 3 - Data Entity Notation and Sample of Its Instance
A Sample of Requirements Particle Networks
To illustrate how to represent a requirements particle network, a sample of video shop's requirements defined in [6] is selected and used in our experiment later. The video shop mentioned has video club members who may hire videos. The functional requirements of video shop system concerns with how to register a new member, how to register new video titles, how to search the video title for hiring and how to manage the hiring record for each member.
A requirements particle network for registering a new video title into video stock data entity is illustrated in figure 4.
4. FORMAL SPECIFICATION TEMPLATE FOR REQUIREMENTS PARTICLE
One of our intentions is to propose a minimum number of simple requirements particles. In this paper, five requirements particles are defined as follows: "Store", "Retrieve", "Remove", "InDevice", "OutDevice" particles. A number of well-defined formal specification items, in Z notations, are defined and assigned to each particle, shown in figure 8 and figure 9. For example, The "Store" particle, shown in figure 5 and defined in figure 6, performs a task of storing messages from "What" port into data entity specified by the message from "Where" port. A number of preconditions will be considered whether the "Store" particle is activated or not. The postconditions will be finally transformed and delivered to "Out" port, "Ack" port and "Nack" port.
Store | [What? : What_Type; Where?, Where! : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_type; Precond? : Boolean | Precond? л Where! = Where? и {What?} л Out! = What? л Ack! = What? e Where! л Nack! = What? £ Where!]
Figure 5 - Formal Specification Template for "Store" Particle
Store | [Video Title? : Video Title Type; Video Stock?, Video Stock! : Video Stock Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_type; Precond? : Boolean | Precond? a Video Stock! = Video Stock? u {Video Title?} a Out! = Video Title? a Ack! = Video Title? e Video Stock! a Nack! = Video Title? £ Video Stock!]
Figure 6 - A Sample of Specification for "Store" Video Title into Video Stock
Figure 4 - "Store" Particle Notation
A "Retrieve" particle is required to perform a search of the existing of video title in video stock. If there exists a certain name of video title in video stock, a constant message 'Existing Title' is transmitted to Monitor CRT using "OutDevice" particle. Otherwise, the video title is expected to store into video stock as a new entry using "Store" particle and the constant message 'Register Done' is finally displayed on the Monitor CRT.
Figure 7 - A Sample of Requirements Particle Network for Registering New Video Title
Store | [What? : What_Type; Where?, Where! : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_type; Precond? : Boolean | Precond? a Where! = Where? u {What?} a Out! = What? a Ack! = What? e Where! a Nack! = What? g Where!]
Retrieve | [What? : What_Type; Where? : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_Type; Precond? : Boolean | Precond? a Out! = What? a Ack! = What? e Where? a Nack! = What? g Where?]
Remove | [What? : What_Type; Where?, Where! : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_Type; Precond? : Boolean | Precond? a Where! =
Where? - {What?} a Out! = What? a Ack! = What? g Where! a Nack! = What? e Where!]
InDevice | [What! : What_Type; Where? : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_Type; Precond? : Boolean | Precond? a What! = Where? a Out! = What! a Ack! = !({What!} == 0) a Nack! = ({What!} == 0)]
OutDevice | [What? : What_Type; Where! : Where_Type; Ack! : Boolean; Nack! : Boolean; Out! : Out_Type; Precond? : Boolean | Precond? a Where! = What? a Out! = What? a Ack! = (Where! == What?) a Nack! = ! (Where! == What?)]
Figure 8 - Formal Specification Templates for "Store", "Retrieve", "Remove", "InDevice", "OutDevice"
Precond
'Boolean-value status' 'Boolean-value status'
'Boolean-value status'
'Boolean-value status'
'Boolean-value status '
'Boolean-value status'
Figure 9 - Particle Notations for "Store", "Retrieve", "Remove", "InDevice", "OutDevice"
5. SPECIFICATION PROCEDURE 2. Decompose SPEC in detail to obtain the final SPEC.
3. Draw requirements particle network for each rule in In order to develop a software functional requirements SPEC
specification, the step-by-step procedure is defined as fol- 4. Transform each requirements particle network into for-
lows:
1. Develop SPEC using decision table approach [5].
mal specification of each requirements primitive with a connection description, using algorithm 1 and 2.
5. Compose the final formal specification, using algorithm 3.
A sample of formal specification for "Store" particle
shown in figure 5, is specified in figure 7.
6. EXPERIMENT
In order to verify the usability of the requirements particle networks, we conducted a workshop of developing software functional requirements specification of a small software system. A sample of software requirements for "Video Shop" in [6] is selected. More than 80 attendants with experience in writing data flow diagram are gathered. Five requirements primitives are selected as follows: 1) primitive for registering a new video title in the video stock, 2) primitive for searching video stock for the existing of the video title, 3) primitive for registering a new member, 4) primitive for searching the existing of the member name in the member list, and 5) primitive for keeping the video hiring record of each member.
Average time to accomplish the specification procedure is 50 minutes and more than 90% of the attendants produce the complete requirements particle networks. The final formal specifications are consequently mapped from their requirements particle networks without any major complication.
7. CONCLUSION
We have developed an approach to software functional requirements specification using requirements particle networks. Our approach emphasizes that requirements particle is the atomic task and a well-defined formal specification template is relevantly assigned to each requirements parti-
cle. Moreover, we introduce the explicit definition of preconditions in the requirements particle networks so that software analyst is capable to specify when a particular particle is activated in the consequences of preconditions. A number of requirements particles are proposed to deal with store and retrieve functions in software system.
8. FUTURE WORK
We intend to investigate and define more relevant requirements particles for the another part of software system for business information system. A set of requirements particles to perform calculation is required as well. In addition, the reuse features of several common requirements particle networks will be considered.
REFERENCES
[1] J. J. P. Tsai, T. Weigert, M. Aoyama, A Declarative Approach to Software Requirements Specification Languages, Proceedings of International Computer Languages, 1988, 414-421.
[2] H. M. Jarvinen, R. K. Suonio, DisCo Specification Language: Marriage of Actions and Objects, Proceedings of Conference on 11th International Distributed Computing Systems, 1991, 142-151.
[3] B. H. C. Cheng, G. C. Gannod, Abstraction of Formal Specifications from Program Code, Proceedings of IEEE International Conference on Tools for AI, 1991.
[4] L. Jin, H. Zhu, Automatic Generation of Formal Specification from Requirements Definition, Proceedings of First IEEE Format Engineering Methods, 1997, 243-251.
[5] W. Vatanawood and P. Chongstitvatana, A Genetic Algorithm Approach to Software Components Search using Software Functional Requirements Checklist, Proceedings of 3rd Annual National Symposium on Computational Science and Engineering (ANSCSE), 1999.
[6] R. Barden, S. Stepney, D. Cooper, Z in Practice, (Prentice-Hall, 1994).
УДК 681.32
АНАЛИЗ ХАРАКТЕРИСТИК МНОГОПОТОКОВЫХ СЕТЕЙ
ОБСЛУЖИВАНИЯ
А.А.Алиев, Б.Г.Исмайлов
Рассмотрены модели многопотоковых компьютерных сетей обслуживания. Поставлены задачи минимизации математического ожидания вероятностной функции потерь информации при минимально необходимой производительности сети. Разработаны процедуры анализа характеристик сети и приведены результаты численных экспериментов.
ltistream computer networks of service are considered. The tasks of minimization of expectation of a probability loss function of the information are posed at minimum of necessary productivity of the network. The procedures of the analysis of the characteristics of the network are developed and the results of numerical experiments are indicated.
В современных сетях компьютеры должны обслуживать большое число источников информации. По этой причине им необходимо работать оперативно и выполнять несколь-
ко операций одновременно. Таким требованиям отвечает мультипроцессорная обработка информации. В таких сетях операционная система позволяет добавить дополнительные процессоры, и она позволяет распределять процессы по нескольким компьютерам, управляя выполняемыми ими задачами. Поэтому с целью ее построения в работе дается анализ характеристик многопотоковых сетей.
В рассмотренной многопотоковой сети имеется т очередей и N мест в очереди. Интенсивность потока заявок, количество заявок в группе, время обслуживания заявок заданы. Характеристики такой сети, в частности, вероятность возникновения заявок на обслуживание, вероятность прихода заявок за время цикла, среднее время цикла и т.д. неизвестны. С целью построения сети необ-
