www.ijecs.in
International Journal Of Engineering And Computer Science ISSN:2319-7242
Volume 4 Issue 2 February 2015, Page No. 10416-10423
Specification of Software Components
Manjeet kaur 1, Harmanjot Kaur2,Kanchan Kumari3,Harpinder Kaur4
1
Guru nanak dev university, Dept of Computer Science and Engineering
chheharta Road, Amritsar
manjeetbhullar64@gmail.com
2
Guru nanak dev university, Dept of Computer Science and Engineering,
chheharta Road, Amritsar
harmank34@gmail.com
3
Guru nanak dev university, Dept of Computer Science and Engineering,
chheharta Road, Amritsar
kanchanattri0001@gmail.com
4
Guru nanak dev university, Dept of Computer Science and Engineering,
chheharta Road, Amritsar
harpinderkaurkhehra@gmail.com
ABSTRACT
Specification of software components gives a brief definition of various operations that can be performed by a component.
Specification of software components is needed for various purposes for example to know all the context dependencies and for
knowing its internal structure. There are various levels at which specification of software components can be done. This paper
first defines specification of software components , then it discusses various levels at which it is done. An approach is presented
with an example to specify components .Then a review of various methods used by researchers is described.
Keywords
INTRODUCTION
Modern software systems are growing ever more
complex..This complexity leads to increased time to market
or to larger numbers of errors introduced into the software.
It has, therefore, become necessary to counter the increase in
complexity and provide development techniques that can
help cope with complexity.
Component-based software engineering (CBSE) [1] is
viewed as one such technique. It helps deal
Component-based software engineering (CBSE) [1] is
viewed as one such technique. It helps deal with complexity
by following a divide-and-conquer approach, modularising
large software systems into smaller, reusable units—called
(software) components. CBSE is supposed to be particularly
effective in the context of so-called component markets,
where components are developed by independent third-party
developers and bought by application builders to be
composed into complete applications. If components are to
be traded on component markets, they must be accompanied
by a precise description of all of their relevant properties.
Such a description must be expressed by component
developers without knowledge of the context in which their
components will be used.
On the other hand, it must be understandable by application
builders and it must be
possible for them to compose specifications of different
components and reason about properties of the final system.
For example, application builders need to know whether an
application built from a certain set of components and
deployed on a system with a certain amount of available
resources will meet required performance goals, how much
memory or network bandwidth will be consumed, or
whether data quality will be up to required standards.
Ideally, such reasoning would be supported by development
tools. This means that we require formal means of
specification.
In component-based software engineering research,much
effort has gone into developing specification techniques for
software components. There exist many software
component specification techniques, from Interface
Description Language (IDL), to design-by-contract based, to
formal methods. However, much of the focus of the research
literature is aimed at component specification for the
development of components, not their use. The current best
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10416
practices for component specification ignore information
that is vital in determining if an available, ready to use
component contains precisely the functional and extrafunctional properties required and if that component can be
used in the target environment
software development, aiming at breaking monolithic blocks
into interoperable components, decreasing the complexity of
the development as well its costs, through the use of
components that, in principle, ought to be adequate for other
applications .
Detailed study
One of the most promising solutions today for reducing the
cost and development time in order to build a software is the
component-based software development approach. This
approach is based on the idea that software systems can be
developed by selecting appropriate off-the-shelf components
and then assembling them with a well-defined software
According to Szyperski [1], a software component is “a unit
of composition withcontractually specified interfaces and
explicit
context
dependencies
only.
A
software
componentcan be independently deployed and is subject to
third-party composition”.
architecture. This new software development approach is
very different from the traditional approach in which
software systems can only be implemented from scratch.
These commercial off-the-shelf (COTS) components can be
developed by different developers using different languages
The contractually specified interfaces are important in order
to form a common layer between the client (i.e. a person
who needs a component) and the component developer.
The explicit contextdependencies refer to what the
deployment
and different platforms.
environment
must
provide
so
that
the
components can function properly.
This can be shown in Figure 1, where COTS components
can be checked out from a componentrepository, and
Still, for a component to be independently deployable, it
needs to be well separated from its environment and other
components.
assembled into a target software system.
Finally, for a component to be composed with other
component by a third-party it must be sufficiently selfcontained, i.e. the function that the component performs
must be fully performed within itself.
Why there is a need to specify a component ?
Thespecification of a component is the specification of its
interface.
The Specification of an Interface : This must consist
solely of:
Figure 1:- Component-based software Development[2]

A precise definition of the component's operations.

All context dependencies.
Need for component specifications:
What is a component ?

For users,
Until a few years ago, the development of most real
The specification provides a definition of its interface, viz.
software products were based on monolithic blocks, formed
its operations and context dependencies.
by a considerable number of related parts, where these
Since it is only the interface that is visible to users, its
relations
specification must be precise and complete.
were
mostly
implicit.
Component-Based
Development (CBD) appeared as a new perspective for

For developers,
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10417

The specification of a component also provides an abstract
definition of its internal structure.
and


Levels of a component specification:

Syntax:
includes
Object Oriented specifications
specifications
on
the
Procedural specifications
Some differences may appear between
different component technologies

programming language level.
Ex:
A
component

Semantic: functional contracts
implements a set of

Non-functional: deals with quality of service.
classes,
each
implementing a set of
SYNTATIC
LEVEL
OF
A
interfaces (COM)
COMPONENT

SPECIFICATION:
•
Ex: A component is
At Syntatic level ,a component provides the
itself
a
implementation of a set of named interfaces, or
implementing
types, each interface being a set of named
interface
class,
a
operations.
•
UML Metamodel of the concepts used in specific
Uses of Syntactic Specification:
specification of software component.
 The primary uses of syntactic specifications are:
–
Type checking (static of dynamic) of
client code.
–
Base
for
interoperability
between
independently developed components and
applications.
 Interoperability may be achieved in different ways:
–
Binary
format
for
interfaces
–
IDL
to
programming
language mapings
 An important aspect of interface specifications is
Figure 2:UML metamodel of the concepts used in
how they relate to substitution and evolution of
syntactic specification of software components(Fig 2.1 from
components.
[3]).
DESCRIPTION OF MODEL:

implemented

Forms of syntactic specification :
This model allows an interface to be
by
several
•
different
All component models use syntactic specification
of interfaces:
components, and an operation to be part of
–
Programming language
several different interfaces.
–
IDL
The
model
presents
a
generic
relationships
between
representation of:

The
•
Examples
–
components,
interfaces,
and
(COM)
–
operations

Through this model one can distinguish
Microsoft’s Component Object Model
Common
Object
Request
Broker
Architecture (CORBA)
–
JavaBeans
between:
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10418
SEMANTIC
LEVEL
OF
provided the operation’s pre-conditions were true
when it was invoked.
COMPONENT
SPECIFICATION:
•
Semantic level of component specification consists of
functional contracts. According to Meyer, a contract [4]is a
collection of assertions that describe precisely what each
feature of the component does and does not do.
Contracts for software: It can be explained by taking
following
example
•
Example: add node to tree
An Invariant: An Invariant is
•
A predicate over the interface’s state model that
will always hold
•
A set of invariants may be associated with an
interface.
More formal description of contract, as part of the
routine’s text:
put_child(new:NODE) is
… Add new to the children of current node
require
new/ =Void
do
…Insertion Algorithm…
ensure
new.parent=Current;
child_count=old child_count+1
end - - put_child
Is a predicate over both input and output
parameters as well as the state just before the
invocation and just after
 Metamodel of the concepts used in
specification of software components
semantic
Figure 3:Describing formal description of contract for
software [4]
In this figure , a simple contract is written for software so as
to add a node to tree. In this figure , new node is added to
the children of current node.
Contracts for components: It consists of following:
•
Pre-conditions
•
Post-conditions
•
Invariant
Figure 4: metamodel of the concepts used in
semantic specification of software components (Fig
2.2 from [3]).
A Pre-condition: A Pre-condition is
•
•
Is an assertion that the component assumes to be
fulfilled before an operation is invoked.
Will in general be a predicate over the operation’s
input parameters and this state
A Post-condition : A Post-condition is
•
Uses of Semantic Specification:
•
•
Tool support for component developers
Tool support for developers of component-based
applications
Non-functional Level Of Specification: Non-functional
level of specification is concerned with:
An assertion that the component guarantees will
hold just after an operation has been invoked,
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10419
•
Non-functional (extra-functional)
properties
(associated more with component implementations
rather than interfaces)
• Examples:Reusability,
Configurability,
Distributeability,
Availability,Confidentiality,Integrity,Maintainabilit
y,Reliability,Security,Affordability,Accessibility,A
dnistrability,
Understandability,
Generality,
Operability,Simplicity, Mobility, Nomadicity,
Hardware independence, Software independence,
Accuracy.
• Why it is needed:
 Selection
between
semantic
equivalent
components
 Negotiation possibilities
• It is a specification techniquebased on credentials
must include:
 a set of registered attributes
 notations for specifying their value and credibility
The key assertions in the design by contract technique
are of three types:
1. Invariants
2. Preconditions
3. Postconditions
1.
2.
3.
An invariant is a constraint attached to type that
must be held true for all instances of the type
whenever an operation is not being performed on
the instance. It is possible to attach invariants to an
interface to specify properties of the component
objectsthat implement the interface. For example,
an invariant might state that the value of some
attribute is always greater than zero.
A precondition expresses requirements that any
call of the operation must satisfy if it is to be
correct.
A postcondition expresses properties that are
ensured in return by the execution of the call.
 provisions for addingnew attributes. A technique
could specify some attributes as required andothers
as optional.
Course Registration System Example For Explaning
Design by Contract Approach:
•
Here we use as an example a course registration system
for a college. With this system, a student may register for
classes. Once given access, the student may select a term
and then build a personal class schedule from among the
classes offered that term. A student may add and delete
classes from the schedule. The system passes the
information about the student's schedule to the tuition billing
system. An instructor may use the registration system to
print a listing of the 5 students in his or her class. The
administrator may maintain student and instructor lists and
course information.
Metamodel of the concepts used in extrafunctional specification of software components.
After analyzing the requirements, we specify the domain
model and the use case model. Then, we refine the domain
model into a business type model. From the business type
model, we get the interface responsibility diagram
represented by the UML class diagram shown in Figure 6.
Figure 5:metamodel of the concepts used in -functional level
of specification of software components (Fig 2.7 from [3])
AN
APPROACH
TO
SPECIFICATION
OF
SOFTWARE COMPONENTS WITH THE HELP OF
AN EXAMPLE:
In this example, we identify Person, Course, and Term as
the core types. The corresponding interfaces are thus
IPersonMgt, ITermMgt, and ICourseMgt, as shown in
Figure 6. We assign types Person, Student, Instructor,
Student_Schedule, and Instructor_Schedule to the
IPersonMgt interface, assign types Term and Section to the
ITermMgt inteface, and assign type Course to the
ICoureMgt inteface.
Figure 6: Interface Responsibility Diagram for Course
Registration System[5]
Design by Contract: Design by contract is a design
approach developed by Meyer. It is used to provide precise
specifications for the functionality of components and to
enhance their reliability.
According to Meyer, a contractis a collection of assertions
that describe precisely what each feature of the component
does and does not do.[3].
We use the interface IPersonMgt to illustrate the use of the
design by contract approach. The
interface information model for IPersonMgt (shown in
Figure 7) needs to contain types for
Person, Instructor, Student, StudentSchedule and
InstructorSchedule.
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10420
Because types Term, Section and Course provide important
information for StudentSchedule and InstrutorSchedule, they
should also be included in this
interface information model. Type Term also should be
included in the interface information
model for ITermMgt and type Course for ICourseMgt. The
interface models we build will
be independent, but they will require some communication.
Figure 7: Interface Information Model for the IPersonMgt
Interface[5]
Consider the makeStudentSchedule operation of the
IPersonMgt interface as an
example design contract. This operation creates a new
student schedule and adds a single course section to it.
We use the Object Constraint Language (OCL) to write the
precondition and postcondition
constraints. In the precondition, we require the student and
section information provided as
arguments to be valid. In the postcondition, we ensure that
an appropriate result is achieved. On a successful execution
of the operation, we ensure that the new student schedule
has a unique schedule reference and that the schedule
created is for the correct student and includes the desired
course section. The information returned about the new
schedule matches the information retained in the system
Below is the full operation specification written in OCL.
Note that the specification we provide for this operation says
only what must be achieved in terms of an abstract model of
the component object’s state. It does not say how the effect
of the operation is to be achieved. The designers and
implementers of the component are free to implement it in
any convenient manner.
The various implementations can thus potentially replace
each other.
IPersonMgt::makeStudentSchedule(insectioninfo:sectionDet
ails,in studentinfo:studentDetails,
out schedule:scheduleDetails):Boolean
Pre:
----------------section and student information are valid
Course ->exists(c|c.id = sectioninfo.courseId) and
Term->exists(t|t.termNo = sectioninfo.termNo) and
Section -> exists (se|se.sectionNo = sectioninfo.sectionNo)
and
Person->exists(z|id = studentinfo.studentID) and
Student ->exists(y|id = studentinfo.studentID)
Post:
Result implies
StudentSchedule@pre->forall(x|x.scheduleRef
<>
schedule.scheduleRef)
and
let s = ( StudentSchedule – StudentSchedule@pre)>asSequence->first in
s.schedule.scheduleRef = schedule.scheduleRef and
s.schedule.id = schedule.id and
schedule.id = studentInfo.studentID and
s.schedule.section = schedule.section and
schedule.section = sectioninfo.section
RELATED WORK:
Software Component Specification Using Role-Based
Modeling Language:(Kim.D.K et al. ,2002) have
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10421
developed an approach for component specification with a
Role-Based Modeling approach.Component-based software
development processes currently lack adequate notations for
the specification of components and tool support for the
reusability of componentSpecifications. Although the UML
has established itself as a widely accepted standard for
specifying analysis and design models, and has powerful
tool support, it is not adequateto support multiple viewpoints
in
component-based
software
development.Here,an
approach is to specify components using the RBML, a metaRole Based Modeling Language. The RBML is a
specialization of the UML. Role models described using the
RBML are property-oriented characterizations of a family of
UML models. Role models are composed of metaRoles that
describe sets of properties. Using the RBML to specify
components facilitates the development of tools for
automating the process of reusing components in the
software development process. In this ,the overview of the
RBML and outlined the approach to define Role Models as a
specialization of the UML is provided. It is demonstrated
how Role Models can be used to capture static properties of
components and illustrated theapproach using the CICO
example. Currently we are developing techniques to
describe behavioral properties using IRMs and meta-model
level constraints.
Software Component Specification:A Study in
Perspective of Component Selection and Reuse:(Michael
CJ et al,2006)has discussed thatthere are many software
component
specification
techniques,
from
InterfaceDescription Language (IDL), to design-by-contract
based, to formal methods. However, much of the focus of
the research literature is aimed at component specification
forthe development of components, not their use. The
current best practices for component specification ignore
information that is vital in determining if an available, ready
touse component contains precisely the functional and
extrafunctional properties required and if that component
can be used in the target environment. These specification
techniquesdo not sufficiently support selection and reuse of
software components. This paper evaluates some of the
current component specification techniques with respect to
the needs of component selection and reuse. From this
evaluation, some recommendationsmade as to advancing the
development of component specifications to include the
purposes of component selection and reuse. This paper
presented the issues that mustbe addressed as we look to
develop complete software specifications that both enable
automated selection of software components and facilitate
the
reuse
of
those
selected
components.Some
recommendations have been made that may ease the
advancement of development of component specifications.
Certain aspects of research in the area of formal method
specification and analysis could positively affect the
development
of component specifications.If such techniques were made
more accessible via tools that capture and present
information in a more human-understandable way
to commercial component designers and developers.
successful in organizations, the software developers must
give close attention to the design of components as
independent abstractions with well-specified behaviors.
Without well-specified behaviors the possibility to distribute
and acquire software components will be limited.In this
paper, 20 approaches to software component specification
were studied,focusing on problem area, formality, usage of
specification and identification of requirements.The major
part of research concerning software component
specifications is aimed at finding solutions regarding
assembly and composition.In this paper focused on believe
that there is a missing approach to specifysoftware
components.In
20 existing approaches to software
component specificationsthat the main focus in the software
engineering community is towards the ‘datalogical’side.But
the researchers of this paper believe that focus should be
towards the ‘infological’ problems. The researchers believe
that we need an approach focused towards acquisition; we
need to acquire components before we can assemble them
into software systems. We also show that the larger share of
studied approaches have a descriptive view regarding the
capturing of requirements. With descriptive we mean that
they only show how to describe existing known
requirements, they do not aid the process of exploring
requirements. The researches of this paper have given an
approach has emphasisized
on the capturing of
requirements.
CONCLUSIONS
Commerce in off the shelf software components is
gradually becoming a reality. What is now keeping
widespread adoption from occuring overnight is ,first, not
knowing the quality of components and ,second, not
knowing how systems will tolerate them.
If these problems can be overcomed, then developers will be
better able to determine the opportunity costs of selecting
one component over another or over creating custom
software. The design by contract approach described in this
paper can help developers decide whether a component is
right for their system. By using this, developers can get the
precise specification of software components and which
helps in increased functionality of components.
REFRENCES:
1. Szyperski, C.: Component Software: Beyond ObjectOriented Programming, 2nd edn.
Component
Software
Series.Addison-Wesley,Reading
(2002)
2. Xia Cai, Michael R. Lyu, Kam-Fai Wong Roy Ko,
“Component-Based Software Engineering: Technologies,
The
Missing
Approach
for
Component
Specification:(Christiansson B. et al,2007) has defined
thatfor component-based software development, to be
Development
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Frameworks,
and
Quality
Assurance
Page 10422
Schemes”,The
Chinese
University
of
Hong
Kong
Productivity Council,1999
3.Ivica Crnkovic, Magnus Larsson (Eds.): Building
reliable component-basedsystem
4. B. Meyer “Applying Design by Contract,”, IEEE
Computer, pp. 40-51, October 1992.
5.Yi Liu and H. Conrad Cunningham “Software Component
Specification Using Design by Contract”, -The SouthEast
SoftwareEngineering Conference, Huntsville, Alabama,
April, 2002.
6. Kim D. K., Ghosh S. France R. B. & Song E.,”Software
Component Specification Using Role-Based Modeling
Language”,The 8th IEEE InternationalConference on
Engineering of Complex Computer Systems(ICECCS 2002)
7. Michael CJ, Geisterfer, Ghosh S.”Software Component
Specification:A Study in Perspective of Component
Selection and Reuse”,Proceedings of the Fifth International
Conference on Commercial-off-the-Shelf (COTS)-Based
Software Systems (ICCBSS 2006)
8. Christiansson B. and Christiansson T.,“The Missing
Approach for Component Specification” - Information
Technology Department Karlstad University Sweden,April
2007.
Manjeet kaur, IJECS Volume 4 Issue 2 February, 2015 Page No.10416-10423
Page 10423