On E,xplicit Specification of Software Components with DB-Data Enkryta
'?
Daramola, J.O., Bamigbola, O.M.
ABSTRACT
Although Component-based software develofltrlent and component technology
offer exciting and interesting potentialities for the simplification of complex
software models if}.. order to gain increased functionality, reduction in time and
cost of development, the desire to enhance the user's understanding and perception
of
- eemponents' behaviours is still a pressing challenge. Since users do not have access
to the program texts (source codes) of component developers in most cases, it becomes
necessary for the developers to give a detailed specification-of cqmponent functionalities,
behaviour and performance in a way' thai: will enhance their predictability even before
they are deployed. In this, paper~we have adopted the semantics of the CSP-like WRIGHT
in the specification of a visual component tool named ''DB-Data Enkryta" that can be used
to compress and encrypt text stored in
a relational database. WRIGHT is one of the eXisting Arc~itecture DeSt[iption,
Languages (ADL) used in the formal specification of comPonent-based systems,"t<
that enables explicit specification C?f component ancLconnector interfaces. This we
believe is capable of giving an addep insight to prospective users about the behaviour
,Ii
of components and enhancing interoperability among components in
component
':;~f~1: "based systems.
[12] including its usage, capabilities ancJ intera_"
behaviour. This limited specification often leads:'!
Component-based
software engineering affords the mismatches in behavioural interoperability betWi
1.'Il1t~oduction
_opportunity
for independent develo.pment of , components when designing component-ba~_,
i'
components that can be used in the composition of
systems, especially in cases where third par.
-4l~~., ",,': ,
-
---
-sOftWare~ySte~ms. These often include third-party components are involved [12].
'
components [5], [8], [21] which are selected at buildtime and reconfigured for interaction at run-time. One In order to proyide a sound basis for compone
of the major- -€oneerns of component-based interoperabilitv,accurate description, precise semanI'
development is the need to minimize instances of qualities, usage and interaction protocol betw
mismatches and misuse of components especially in components there is a need for a more expli(,
the context of assembled systems [7], [9].
specification, which entails the description of compana
,
interilction protocols and~tbespecification of bo~
There is a general consensus in literature on the need to
extend the level of component specification beyond the functional and extra-functional properties.
\
syntactic level [3], [4], [6], [11], [14], [21]. The In this paper, we have used an approach [1], [2] whf
existing mode of specification that exist in the is based on the WRIGHT formal specification
available standard component models like CORBA, languac in the sp€ci'ficationof a visual com,ponent called
COM and JAVA
"D
are mainly syntactic, which only describes the functional
Data Enkrypta". Thlsis a visual tool ttJat we ha'
properties of components. These forms of specification constructafwhich can be made available as an Acti~
highlightsthe services provided and services component across ActiveX platforms for compressil and
required (CdRBA IDL) by the components, which also encrypting a database file.
represents ac:o~tract between the component and its
prospective
2. MotivationThe motivation for this work is to
clien~s. lihese commercial Interface Definition
enst the precise specification of component
'. '
LangpCiges (IDLS) primarily specify the signature aspect
of software components Jnterfaces i.e. names,
interacU protocols in contrast to what
presently exist
- para'hleters, -and-data-types-of tll~ provided services, commercial Interface Description Languages (IDLs).
~ --'~not provide the necessary support for capturing order to illustrate this, we have used the example
,
the semantic or behavioural aspects of a component oft
ill
f
1. Interface Compressor _Encrypta {
2~ StrirtgCowpress( in string filename, in string filed river);
1t,String Ericrypta'(jn string filename);
Ii'
~1,
"4. }
,.:w
, (.
,
',ij
',,"t
1. Interface Decompress_Decrypta {
2. String Decompress (in string firename);
3. String D~crypta ( in string- fiiename);
4. ,}
'.,
"
j
Figure 2.0 Oveniiew of CORBA IDL specifications for DB-Data
Enkrypta Component.
compression and data encryption component, our example,' the COrrect sequence of invoking the
DBa-Enkrypta. This component is a operation of the DB-Data Enkrypta component is to
composite lponent, which comprises of two
sub-components
The first sub-component is the Compressor
(pta component, which compresses a database
using the filename as input parameter for the
1an compression algorithm [10]. Thereafter, it
pts the compressed file using a data encryption
ndard (DES) method [13]. The second sub-
.
first invoke the compressor method for compression
and then the encryption method for encrypting the
compressed file. We also need to first decrypt,the
encrypted file before we invoke the decompression
method in order to get back the original file.
The configuration of this component is such, thafany
variation from this outlined s~quence of invocation
will lead to system failur~ and yet this could not have
lponent is the Decompressor-Decryptacomponent,
I consists:of m~thods to dec~t encrypted data ,been
to decompress previously compressectrlata~- The discovered in any way from the purely sy-ntaette i,ivalent CORBA IDL definition for the DB- specification given in Figure 2.0. Figure 2.1 shows the
diagram for these transactions.
Data collaboration
,
tYpta component is shown in ~gure 2.0. One common approach tothis kind of problem as-it-is
being-done in t.fle-specif-ietion ofc-Qmmercial
Figure 2.0, It cannbt~ seen In whlch'partlcular components [15],[16],[18],[20] is the use of informal
,~ta user or a prospective client should invoke the documentation, which is attached to a component
:es provided by this component in order to correctly explaining the protocol of its interaction in order'to
ge it. This underscores the need for protocol avoid problems. However, this kind of infornJai
[cation, which will indicatethe particular sequence documentation leaves room for ambiguity and
'. oking the services provided by a component such inconsistency and also lacks adequate basis for
performance synchronization and run-time the
~.
-
Call 0
~our interoperability
can be achieved. Considering
:Coml!res
s
f
:Drcoml!ress
i
+ Compressed filename
filename
"
r,
Decrypted
.. ~-,
'
: Decmta
: E n c!.1::J!$a
'hi,>
'..
----.
Encrypted filename
" c,
1 .,',~ 'i'
I
,.1
",'
Figure 2.1 Collaboration Diagram for DB-Data Enkrypta Component [17]
--l
'
-~
;'
precise description and analysis of the behavioural
context dependencies only.. A software compon can
properties of a component. This makes- necessary,
the need to evolve a more explicit and precise way of
specifying the interoperability requirements of
components in a way that can be verified and proved
be deployed independently and is subject t!1
composition by a third party [5].
The description of a component in WRIGHT h
two parts the. Interface and the Computation. J
-for correctness;~
~-~~
-Interface consists of Ports. A Port:represents a~
interaction
in
which.the
component
may
Although a formal approach has been adopted, which
participate;!
ordinarily may not interest many developers with
The Cqmputation section of a de.scription describe '
relatively, low affinity for mathematical formalisms, we
what the component actually does. Th
~aq4Saytl,at lh-e notations of WRIGHT are quite reI.'
Computation carries out the interactions
tiy.E;!ly mild and not difficult to understand. It became
described by the Ports and shows how they are
ou'. oi<:~I,anguage because of its attribute of
tied togethE
co . j1')giabstraction elements for explicit specification
'to form a coherent whole. Therefore, in WRIGH" the
of B,R 'components and connectors. It also .has
Computation is the full specification upon whic analysisautd,matic support tools for checking for the
ofthe"COmponents properties will be ba
completeness and consistency of specifications by
using the FDR (Failure, Divergence, Refinement) as 3.1.2 Connectors
specification checker.
~
A connector encapsulates the character of
I component interactions. It is the, link
'i~~
i~
In
WRIGHT
connectors
represents an interactIbetween
components
[19].
among a collection of components. The abstracti,'
of connectors as an encapsulation of interacti,
among a collection of components achieves
Introduction To WRIGHT~pecificati°f'
t ,~
WrqGHT is an ArchitectureDescription Language that
is used for the formal definition of software
architectur~ and also provides a basis for the analysis
of the system structure. The notion of WRIGHT as an
architecture rlescription language is based on the
abstract!on of the components in a software system as
independent
---compUtational entities ISJ and the connectors as a
composition patterns among components [1], [t9]. This
makes WRIGHT very suitable for the specification of
independence of a component by structuring
way a component interacts with the rest of .
~~ystem [1]. In,order'words, a connector provid~
in effect a set of requirements that i3 compone~
compdnent--baseEkystems. It~aJso provides a precise
s~'!1af\tfesd~/1at resolves ambiguity and aids in the
det~crtion of inconsistencies. WRIGHT also provides a
extends that applicability of analysis of component
[1]. A connector between components could bea
simple as a procedure call, which indicates a caU,,!
1
"
y
important purposes. First is that it increases
must!meet~ and an information-hidln9 bounda~
that defines wffafexpectation~tl1e component ca~
haveabounts environment. The secb'nd is that
set;~~e'cHri4qes that supports reasoning about system
afld-return-~attern. of- control.
pr6$~~t~i;El~:
The WRIGHT's description of connectors divides
'\;i,.
~j,&.
'~'\J '.:
1
t
I
i.
:t
'i
,
The basic-architect-ur.al abstractions of WRIGHT are
'~omponents, connectors and configuration~. It
provides explicit notations for specifying each of
tbese elements, which makes It;-adequate for.the
sp"Ekification of component-based systems.
COmponent-based systems .are essentiallYa'h
assembly of' independent- cDmpeneflt~ 'and'
conn'ecrors "that have been integrated for
coherent
behaviour in order to achieve a set~of
.." ". "
requirements. We now giVe 11 preview , ofeacfi
Of these elements.
.
specifies
an interaction."'"
"
contractually specified interfaces and explicit
'
how-the
computation
of
a
th~
wUI-co..bfdinate,tlJe components: behaviour to crea'
.'t{'c.
.,.,. ;\,[-;,.;:
into
compone~t is corp posed to form a large
~computation. Like the computation of a component
the'~ Glue 'of 'the" connector represents fi1'e '"full;
behavjqural specification. It is the Glue process tha
A softWare component is a unit of composition
with
"'"
i
the behaviour of a simple participant in thl; interaction.
For example a pipe connector has two!
roles i.e. the sourc~ of data and the Sink ,(tt\~
component that receives data) while a procedun call
'cOlirlectorhasa Caller and Definer. The RoJ
indicates what is expected of any component tha' will
participate in that interaction. A Glue of a' conne~or
describes hoWlhe paliic'ip'ants will wOr\'!
togethE;!r to create an interaction. The connecto
Glue
3.1.1 Component
~~.~. .
i
set of Roles and Glue. Each Role specifle
3.1 rey Elements of WRIGHT
1
n
.
,,'-"
,"
.
'p'"
1\'
-
I"
'~'--!I
I Therefore, a component specifica~lOf,1 is interpreted 3. ~@STOP' - indicates a process that successfully
to mean that if the 'actual COrhpon~Dt:S obey thee' '. terminates.
behaviour indicated by the roles, then the different
!~omputations of the components will be combined
4. ";" ~ also used as sequencing operator..,
jas indicated by the Glue [1], [2].
h
S. P;Q - means P executes successfully, terminates
and then Q executes and terminates.
I
6. b@f@§; (g@§) = b@f@g@§
~.3 Other Elements of WRIGHT Structure
Instances: In WRIGHT, components and 7.
, - An alternative that recognizes the possibility pf two
connectors are defiOE:!d as types which arel:hen
behaviours in its environment. This is calfecr
the deterministic or e~ernal choice e.g. b@P".c:' 'Q
is the process that willb,ehave as the proc~§s~. .' it
first observes event b and will behave as/th~Eroq .~
Q if It first observes the event F. the detet'mtnl-aii'l ;
cholce cepends on wl1at 'the 'environment dc'~
instantiated for various uses. An "instance
therefore is an occurrence of a type of
component or connector.
:
.,£~:~!i!l~r~t,~nJ ,ct'. ~9.J1\~~Hl]1t!9~JS};1 S9!!~ipn
of components! InStance$ rl=,q~irN9 rY1~
connectors. .
a1o":' "\
S;~£>.,:;- A
,
,
Attachment: This defines the topology of the
configuration, by showing which components
participate in which interaction. This is done by
associating the ports of the components with the
roles of the connectors.
.
:.
Styles: This is a set of configurations types that
can be adapted for an entire family pf systems.
Styles can also have constlOints'which
represents predicates that must satisfied' by9;
""',
'" "
'.
"\t1!'I""'.:'~
second alternative is a process that makes
an internal choice about which of two behaviour to
perform. This is called non-deterministic or internal
choice and uses the operator D. The process e
@ P D F @" Q is the Process that will either
04tput
e' and then acts as P or F and then acts
as Q. The proce~ itself decides which to do,
without
co'nsulting the environment.
,
'x: S? P(x)- indicates an external choice between
different P(x)
';
any configuration declared to be a member
of the style.
10. f) x: S ? P(x) - indicates the execution of a!1 of t!'ie
,
different P(x) in some order.
Some
Notations
of
WRIGHT- 4. EpliCit Specification with DB..Data Enkryta
The DB-Data Enkrypta is a composite compoQent
composed of two sub-components, the Compressor and
GHT makes use of a notation that is based on Decomprocessor with two ports each:}:Tne- (QmpressiooCSP. . (Communication Specification Process) is a eAcrypt~oA-5eFViEe-pFoviEleel ,bY'the .'b~- Data Enckrypta
process . mcation Language for specifying entails the compression
of. a datat>ase.,
; file specified bY
its ftlename
using a HUffmanepc:Q:giA1
Specif'rcatton
,~
patterns of
[Huffman].
The
.algorithm
~iour and interaction. The two key features of compressedoutp~~~1i''!iI
GHT behaviour specifications are Events and passed-to the encryption method of the
':esses. Some of the notations used In Compressor
specifying ,ilts, and processes are shown as
. sub-component to encrypt the data-using a DES (Data
follows'[~], [2]:
Encryption Standaro) algorithnrThe- DeCQr;t\pr,~~9.~:,
j
nts: ,., "','
Write - indicates, a signaled event
Decryption service involves the decryption of encrypted
f.
m..';indicates'a
that
'b?x'"
indicates asignalled
process b event
receives
data x
data with the dec;ryption method and then the
. decorT1preSsio1.l.,~f ~~~rypt~a.~ta to getrtbe.,orjgl~al
data. Figure 4.0 showSi'.tne iriternal (White-box) vi~W of
terminates'
component.
b!x.,.- shows that a process b outputs data x, it is the DB-Enkrypta
""
. ~ "" .., "
. successfully.
Ports-are- "
.
. 'Dlr
signaled event ( initiated by the~'process-itself).
'$TOP-,- the process that does nothing.
.C
then P
occurs).
Sequencing
-
b@P (events b occurs and
It is composed!~f two subcomponen~}~~J>J)~"Y~:.l~J
connected to the ports of the contained subcomponents by
external connectors [11]. The direction of the
delegation
delegation cOnJ=1ectors indicates tbaUbe-input--pmts
inl and in2 ports are associated with required
inteFfaces________________________________________________________ 7' ?"
and the output ports out! and out2 are associated with
ipl
~
\\
CQmpressor
Decompressor
in2
Out2
1
!
~
fl~ure 4.0 YV~!tI'-bo:IC view of the DB-Enkrypta component-based system [11J
--
-
.
~~.'
, .the provict~ Interfaces. The Int~ma! sujxomponents' Role com~res~ ,..:: call @ rtnurn @?'tomprl
'
"re connected ,Py, an U nla~eled ~ss~mbly c<?nnector- .1"'1..,'
II @ ,..,.
II
,
~11]. ""
.. '''';",;.f
1,- ,
.-,
. 'iii'.',
.t!.,?'f-. '" .r"
.1:J" FQrmal Specltlcatloll
. ,/<W1th. WRIGHT. \, i,
-.' 'f'ii' 'i,a':,. ,"
-
.v~e r:~'"
.-
~..,~ er.ca R comprl
@ Glue ;If , compressor.return"@
. ",
caller.return
Glue §
\
of DB-Da~ ~nkrypta
"
cqrnponent Cpmpressol(strlng;x: 1..2)
Connector ca1l_decompressor
port Compress:: read?x @ compressaxit' close@ §
Role caller
,
r~11 I!ncrypta -= encryptaaii @ writ~!x @ f) ,I~s~ @ §
~ C~I1tPURtion = ,c~mpress.read?x @
Role decompressor = call @ return @
decompressor \ § .
Glue
= caller.call @
decompressor.call @ Glue
compr~5s;compressazn <!)'
,
encrypta~¥n @ ~ncrypta.writelx @ computation
, decornpressor.return @ caller.retu'
j \ (compress.close (!), encrypta.close @
Glue §
.,; .
~.
= call @ return @ caller £)
\
"'
5.Q Component Specification \:
"--
.1
Comp~l1ent Decq!"p~$sQl(strlng;Clpherx)
The app~ch ~f us!n~ WRIGHT~,~c~ficaJ:~on effed
~ddresses the Isstfe of protocol speclfica.tlon, affol.
Port decrypta == read?Cipherx:@
,
decryptaaOpheocn ' close@ ,§
."
fV
- p~!!.-~ q~fpmpress ~ decompress6l'Jp11e1J" @
f.' .
~J1~ompreS5 f) close @ 6
.
C,empu~ion = decrypta.reaq1clpherx @
d~tY.~~~decrypta-Cipherx"@ j ; I
,
.~
qe<;o-mpress.decompressaz" ~decornpress.writelx
111\
'.
.,
.
.,
'W
:
t'
"
;.." ,\
.
computation \ ( decrypta.close,@ !..
,
decompress. close @-§)
.f
Connector'call_Co~p'~essor
Role caller
't
., Ordef-()f~ oompenent interaction as demonstrate'
Wrlte.x. aUf example, This is an improvement on the e> .
~"1;" .
.,,,
.' -'00
tfle opportunily to clearlY spell out in a formal ~
= 'call @ return @ cailer f) §
standard especially the Interface Definition Langl
(~D~) that is mostly used in the specifi~ti.
cpmmercial compon~nts [15], [16], [20]. .
specifications are essel1tially syntactic, and say I
about the other aspects of a component thai prospective
user will be interested in. A detailed ex ' specification
ShOl~ld therefore include the specifiai' of component at the
_syntactic, semantic, protocol
extra-functional levels.
One of the key advantages of WRIGHT specification'
shown with our example is that it has adeq.
abstraction elemen~ to explicitly specify a
compor at the syntactic, semantic .and protocol
level. '
syntactic aspect deals with the names, &w
parameters,;
.
[i)"""
~'!..!~kL~t""
~".';lJ1 ~'),';,~~{~~'\;~;,l0f.,'r''''''AA''";''''
,'"
.
"..'"
"."
1
..
types
of the provided services, the semantic3spect 8.
eals with the specification of constraints that
:ermines the conditions for components inter;:dion,
17]. The protocol aspect indicates the O'1'd(>r of
!raction 'v:;lle the ~xtra-functional aspect deals with 9.
http://www.cbs.colognet.org/Sepecifiaction.php:
CompOl'ient
Spedfication and Retrieval
petties like the performance and reliability rall'lg of
,
Han, J. [1999]; An approach to software component
specification; In Proceedings of Internal Workshop on
Component-Based Software Engineering; Los Angeles,
U.S.A.
component [23], [24].
10. http://www.crypto.com: Huffman Encoding Algorithms
c,' our future work, we intend to extend our eXf'I. -it 1l.
, :ification to include the extra-functional propert ~,
reliability using the CoRe (Component Reliabillt)
I
ad [14] and performance using a performance
- Jneering approach [22]. This we believe, will further
t user perception of such component and enhance
roperability and minimise component mismatches
greatly improve understanding and perception of
component
'-
Iviour, boost component interoperability in order
,tninimise misuse and mismatches in the composition
.;.
component-based system.
Institute, Pittsburgh.
.
12. Jin, Y., and Han, J. (2004): PEIDL: An Interaction ProtOCOl
Specification Language for Software Components; Center
for Component and Enterprise System, School of
Information -1'echnology, Swinburne University of
Technology; Technical Report: SUTIT-FR2004. 02/SUTCecses"tr002.
13.
'e have shown with our example that explicit
ification of components which includes syntactic,
antic and protocol specification is possible with an
~. .like WRIGHT. This is recommended for
component ~Iopers as it has the tendency to
Ivers, J...qements, P., Garden, D, Nord, R., Schmerl, R. and Silva,
I.O.R. (2004): Documenting component and
connector vi~ws with UML 2.0; Technical Report CMU/ SEI2004-TR-008 ESC-TR-2004-008; Carnegie Mellon
Itrammer, R.G. (1999): Data Encryption Standard (DES); Federal
Information Processing Standard Publications, FIPS PUB 46-3,
U.S.A.
14. McGr. ~gor, J.D., Stafford, J.A., Cho, I. (2003): "Measuring and
Communicating Component Reliability, Sof~wt\re EI 'gineering
Research and Applications (SERA), San Fr~ ''1cisco, CA, USA,
Selected Revised Papers Series: Lec 'ure Notes in Computer
Science, Vol. 3026 Ram.lmoorthy, C.V.; Lee, Roger Y.; Lee,
Kyung Whan (Eds.) 2004, pp. 74-86.
15.
16
.
Microsoft (1 996), The Component Object Model Specification;
Report \ 0.99, Microsoft Standards, Redmond WA.
OMG orbos/~9-04-J7 ,.,non" COPBA Component Model
Volume 1
.
17. OMG: OMG-Unitit:d Modelling Language Report V1.5; Object
Allen, RJ. (1997): A Formal Approach to Software Architecture.
Manageml~nt Group; http//www.omg.org/
Ph.D. Thesis, School of Computer Sdence, Camegie Mellon
University, Pittsburgh.
18. OMG (2000): T')P \.'~
">hi"d Request 8roker: Architecture
and
Speci!
ie.'
:.J. Ot'o1G Standard Collections.
:. Allen, Rand Garlan, D. (1997): A Formal basis for architectural
connection; ACM Transaction on software Engineering and
19. Plasll, F. and Wisnovsky, W. (2002): Behaviour Protocols of
methodology; 6(3); 213-249.
Software Components; IEEE Transaction on software
)
"Borgida A., and Devanbu, P. (1999): Adding more "DL" to IDL:
Towards more knowledgeable component Interoperabillty; 20 In proc.
21st Int'L Conference on Software Engineering (ICSE), Los Angeles,
CA. ,378-387..
.
Engineerin!1 28(11); 1056 -
1076.
Sun Microsyst :!ms: Javabeans 1.0 Specification; http://
www.java,$, '1'1 rC)m/beans
Canal, C. and Pimentol, E., Troya, J.M., Valledllo, A., (2000): 21. Zaremski A.M., W 1'10. . ',1995): Specification Matching of Software
C( I',por,ents; In proc. 3'd ACM SIGSOFT Symposium en the
Extending CORBA Interfaces with Protocols; The Computer
Foundation of Software Engineering. 6-17.
Journal 44(5), 448-462.
.
:Qnkovic, I. Hnich, B., Jonsson, T., and Kiziltan, Z. (2002): 22
Specification, Implementation and Deployment of .
WU,X., McMullan, ['1" Woodside, M. : Component Based
Perform;Jncc
P-edlction;
http//www.csse.monash.edu.au/ "'hws/cgl-b,n/C '3SE
6/ Proceedings/papersfinal/p24 .pdf
Computers; Communications of the ACM, Vol. 45. No. 10. 3540.
,ltan, J. (1998): A Comprehensive Interface Definition Framework
i. for Software Components; In proc. Asia-Padfic Software I~ 23. Zschlaer, S. : Formal 5, ~ecification of Non-Functional properties of
Component-Ba'~d Systems; http//www.comquad.inf.tuEngineering Conference (APSEC), Taipei, Taiwan. 110-117.
dresden.de/nfcO<1/pIPcrs/nfc04_3.pdf
Han, J. and Ker, K.K., (2003): Ensuring Compatible Interactions 24. Zschlaer, S. (2004): To ..prds a semantic Framework for Non-
with Component-based Software System; In proc. AslaPacific software
Engineering conference (APSEC), Chiangmai, Thailand; IEEE
Computer Society. 436-445.
Functional specific< tlOf) of component-based system. In
stainmetz, R., Manth~, A., eds: Proc. lEE Computer society.