International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016), pp. 149-162
http://dx.doi.org/10.14257/ijseia.2016.10.9.13
Component Based Software Engineering in Student
Management System Domain:
A Development for Reuse Approach
Olubukola D. Adekola*, Sunday. A. Idowu and Adewale O. Adebayo.
Computer Science Department, School of Computing and Engineering
Sciences, Babcock University, Ilishan Remo, Ogun State, Nigeria
*
Corresponding Author: [email protected]
Abstract
Component-Based Software Engineering (CBSE) research is an important emerging
area of Software Engineering (SE) that supports and enhances evolution of reusable
components useful for creation of software solutions. CBSE has assumptions that
components exist in repositories, but this is usually not the case. That is, components
are in want. The aim of this work is to design and build generic software components
for student management system domain using object oriented methods. Analysis of
major school management system functions, data and behaviours was done. Also,
pattern-based domain engineering was conducted so as to identify structure points.
This led to factoring out generically reusable components. Student management system
components were created for implementation using a general-purpose distributed
Component-Based Software Development technology model. Consequently, a
framework for implementing student management system and related systems was
provided. This would contribute to the body of the emerging CBSE practices.
Keywords: Software Engineering, Component-Based Software Engineering, Reuse,
Candidate Component
1. Introduction
Software Engineering is the application of systematic, disciplined, quantifiable
approaches to the development, operation and maintenance of software. ComponentBased Software Engineering (CBSE) research is a branch of software engineering that
has to do with developing theories, processes, technologies and tools supporting and
enhancing evolution of reusable components that are useful for creation of software
solutions [1]. Traditional software development process proceeds gradually from
requirement gathering and specification to system delivery but CBSE majorly involves
two separate development processes, component development and system development
[2]. Component development is the process of creating components that can be used
and reused in many applications. System development with components is concerned
with assembling components into applications that meet the system requirements [3].
Building software out of components enables a construction-like approach to software
development. Component based development (CBD) models had been enormously
promoted by the development of Object Orientated Programming (OOP) methods [4].
A component is an independently deliverable piece of functionality providing access
to its services through interfaces [5]. A software component could also be described as
a unit of composition with contractually specified interfaces and explicit context
dependencies only [6]. A software component can be deployed independently and is
subject to composition by third parties.
*
Corresponding Author
*Corresponding Author: [email protected]
ISSN: 1738-9984 IJSEIA
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
CBSE promises massive and generic reuse leading to quick time-to-market, reduced
cost and improved quality. Components are viewed as part of the starting platform for
service-orientation. The main goal of building software component is reusability and
developers build components with nothing more important in mind than a type that
many different programs can reuse rather than developing from scratch each time. It
takes significant effort and awareness to write a software component that is effectively
reusable. These components must be fully documented, thoroughly tested, and
designed with awareness that it will be put to unforeseen uses [7].
The growth in software reuse has been gradual and arithmetic from the time of
structured programming concept to object oriented methods. This includes the reuse of
existing functions or code library, objects and classes which have been helpful in
building software. Component Based Development (CBD) approach promises reuse at
granularity level higher than functions or classes.
2. Problem Statement
In employing CBD, existing components are searched out and then assembled and
adapted to form a proposed system. Components can be assembled and reused to build
a software system only if they exist and are available. More attention is called for in
providing such components across many problem domains as it already exists in the
hardware industries. It is preferred to reuse processes or common artefacts than to build
from scratch. Student management system domain is a globally applicable area to
consider identifying generic components, designing the components, and making it
available for development needs.
3. Aim and Objectives
This work therefore proposes to design generic software components for student
management system domain in order to improve CBSE practices and make it more
applicable to institutional needs. The objectives are to analyse the chosen domain and
to identify specific components that are generic and can be designed for reuse, design
the components and make them available for reuse purposes.
4. Methodology
These studies embody systematic literature review, case studies and surveys with
face-to-face interaction with related system developers. The relevant
documents/publications obtained were qualitatively analyzed for convergence, and
relevant details were extracted, using inductive approach.
Further methodologies employed include analyzing major school management
system functions, data and behaviours, and conducting a pattern-based domain
engineering to identify structure points and repeating patterns. Then the generic
structure points identified within the chosen application domain were used to design
reusable components by applying a general-purpose distributed Component-Based
Software Development technology model. The results of this research are presented in
the later sections. No difficulty of being an ethical researcher was encountered.
5. Related Work
[8] first promulgated the idea of CBSD at the NATO (North Atlantic Treaty
Organization) conference on software engineering in Garmisch, Germany in his paper
titled - Mass Produced Software Components. He stated that software should be
componentized, that is, built from pre-developed software components. The intent of
the conference was to tackle prevalent software crisis.
150
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
A notably potent instrument in software development is reuse. Rather than “reinventing the wheel”, everyone wants to reuse what is working. Reusability started
from the days of making use of already written algorithms and libraries, among others.
Component-based development poses that reuse could get better. There are existing
industrial component technology models. Examples are COM (Component Object
Model) from Microsoft, EJB (Enterprise Java Bean) from Sun, and CORBA
Component Model (CCM) from OMG – Object Management Group.
5.1. Simple CBSD Process Model
Figure 1 depicts simple flowchart for component based software engineering
development process.
Requirement Analysis
and identification for
system to be built
Search/prepare
components to match
requirements
Matching
Components
found
Yes
Architectural Design
Modify requirements and
check if components can
be modified
No
Build system by
composing
components
Figure 1. Simple CBSD process (Source: [9])
5.2. Impact of CBSD on Software Development
CBSD aims to diminish software crisis. In general, the benefits of CBSD include:
-
To promote reusability
To ease maintenance tasks
To promote development flexibility
Composing trusted components will directly inform the quality of the new
design
Reduction in development time which is also proportional to reduction in
development cost
Debugging is localized in that most errors are narrowed to component
integration
The level of risk is reduced while success rate is increased [10].
Just as realtors often say that the three most important factors affecting the price of
real estate are “location, location, and location”, people in the software community
often say that the three most important factors affecting the future of software
development are “reuse, reuse, and reuse” [11].
Copyright ⓒ 2016 SERSC
151
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
5.3. Reusability Tools
A reusable component can be seen as a box, which contains the component’s code
and documentation [12]. Some identified reusability modes are as follows:
(a) White box reuse permits change to be made to the inside of the box and its
interface. The internal structure of a white box can be shared with another box
through popular techniques like inheritance. Re-test is required when
modification is done.
(b) Black box reuse makes the interface only (not the implementation of the
component) available to the component user. The interface contains public
methods, user documentation, requirements and restrictions of the component
(c) Glass box reuse makes both the inside and the outside of the box to be seen but
like looking through a transparent glass, the inside cannot be touched. The gain
here is that system re-user can understand the box and its use much better.
5.4. Some Closely Related work
The literatures summarised here are published works of reputable scholars and
researchers in component based software engineering in various problem domains.
This summary briefly described their works, purposes and methods:
(a) Orca: A component model and Repository [13]
Orca project was distinguished by explicit adoption of component-based approach
from start and also acknowledged the relevance of component market. In terms of
development tool Orca traded-off portability for ease of use. Orca presented a model
and Repository for building robotic wares.
(b) Enhanced Software Development for Reuse Process Model in Component Based
Software Engineering [14]
The goal was to refine reuse model that can promote CBSE. The researcher
developed enhanced software development process for reuse and gave the future
prospect of CBSE
(c) A Component-Based Framework for Software Reusability [15]
A framework for software reusability was presented showing how to use
componentizing approach to facilitate rapid software development.
6. Outcomes
The major parts of the chosen domain where componentization is to be applied in
student management system include:
(a) Admission
(b) Registration
(c) Result Management
(a) Admission
The primary actors regarding admission are Candidate and Administrator. Figure 2
depicts the use cases for Candidate and school Administrator.
152
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
School Admission System
Apply for Admission
Candidate
Process Application
Schedule Exam
Admin/Registrar
Sit for Exam
Process result
Figure 2. Use Case for Admission System
(b) Registration
Actors in registration include Student, Faculty Officer (F.O), Bursar, Medical
Officer (M.O), and Hall Administrator (H.A).
Figure 3 depicts the use cases for Registration actors.
Registration Process
Register Courses
Pay Tuition
Student
Register for
medicals
Allocate
accommodation
F.O
Bursar
M.O
H.A
Figure 3. Use Case Diagram for Registration Process
Copyright ⓒ 2016 SERSC
153
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
(c) Result Management
Actors in result management are Faculty Officer, Lecturer, Head of Department
(HoD), Dean, and Student. The corresponding Use Cases are presented in Figure 4.
Result Management
Key in result
Lecturer
Verify result
Dean
Approve result
HoD
Forward result
Senate
Vote result
Request for
transcript
Student
Figure 4. Use Case Diagram for Result Management
6.1. Fully Dressed Text based Use Case for the School Registration System
Text based used case is paramount to analysis and design of successful enterprise
solution. Test-based use case might be casual and fully dressed version [16]. The fully
dressed used here exhaustively presented detailed interaction in order to avoid missing
requirements.
154
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
Use Case 1: Login to the System
Primary Actor : Student
Scope: School Registration System
Level: User goal
Stakeholders and Interests:
Student- to gain access into the system
Registry – expects a bonafide student to gain
access to the system
Precondition: Account already exist or created for student
Guarantee: student management system(SMS) logs in a valid
student
Main Success Scenario:
(1) Student enters username and password into SMS
(2) SMS validates username and password
(3) SMS re-directs student into the system
Extension:
1a. Student does not have username and password
1a1. SMS prompts student to get a username
and password
2a. Wrong username / password entered
2a1. SMS denies access and request for
correct username and password
Use Case 2: Browse Course List
Primary Actor : Student
Scope: School Registration System
Level: User goal
Stakeholders and Interests:
Student- wants to see a list of courses available
to be taken
Precondition: All courses pre-loaded
Guarantee: courses are available online
Main Success Scenario:
(1) Students select department and semester
(2) Student scroll through course list up and
down
(3) SMS display course listing based on level
and department
Extension:
1a. Course not on the list of displayed or available
courses
1a1. Administrator adds the omitted courses
Use Case 3: Add Course
Primary Actor : Student
Scope: School Registration System
Level: User goal
Stakeholders and Interests:
Students- add course to be taken for the semester
Course Advisor – ensures the right courses and
the right unit is taken
Precondition: None
Guarantee: None
Rule: Total credit unit not exceeded
Main Success Scenario:
(1) Browse Course List
(2) Select applicable courses
(3) Add selected course to student course item list
Extension:
2a. Course not added because total unit exceeded
2a1. Remove (Delete) Course
Use Case 5: Pay tuition fees
Primary Actor : Student
Secondary Actor : Bursar
Scope: School Registration System
Level: Summary
Stakeholders and Interests:
Bursar –wants to ensure student does not owe
institution
Institution – wants to be sure no student owes
Precondition: Admitted/bonafide student
Guarantee: payment successfully approved
Main Success Scenario:
(1) Students pay fee to school account
(2) Bursar converts bank slip to school fees receipt
(3) Bursar acknowledges and approves payment
(4) SMS grants student permission to register
Use Case 4: Remove Course
Primary Actor : Student
Scope: School Registration System
Level: User goal
Stakeholders and Interests:
Student- remove added course from the
selected
Precondition: At least one course exist in the
course list
Guarantee: course is successfully removed
Main Success Scenario:
(1) Students view selected courses
(2) Students select course to remove
(3) SMS removes course successfully
(4) SMS updates and display list
Copyright ⓒ 2016 SERSC
Use Case 6: Approve Registration
Primary Actor : School officer, Head of
Department(HoD)
Scope: School Registration System
Level: Summary
Stakeholders and Interests:
Course Advisor – wants to ensure students
register correctly
Precondition: Add course
Guarantee: Registration successfully approved
Main Success Scenario:
(1) School officer views student registration
detail for correctness
(2) School officer approves student registration
(3) SMS sends approval and notification email
message to student
155
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
Extension:
1a. Student pays insufficient fee
1a1. Bursar acknowledge and disapprove and
advise students to pay up outstanding balance
Extension:
2a. Open issues – Any reason for rejection of
approval
6.2. Object Generalization
Generalization is arranging these objects into inheritance hierarchy. Figures 5 and 6
depict object generalization showing class inheritance and generalization for account
object, respectively.
Person
Student
System Administrator
Admin Officer
Register
Bursar
School officer
Figure 5. Object Generalization Showing Class Inheritance
Account
Student Account
School Account
Figure 6. Generalization for Account Object
6.3. Modelling Class Relationships for Registration
Figure 7 shows object relationship and their multiplicity. Some objects are
independent while some are in composition relationship to other objects. Composition
is an object-oriented concept in which new objects emanate from existing objects [17].
The black diamond represents composition. Asterisk (*) symbol is for multiplicity
(many instances).
156
Copyright ⓒ 2016 SERSC
HoD
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
Course
Facade
Course
CourseUI
*
1
1
*
Semester
Department
Mailer
1
1
Registration
1
1
1
1
Account
…
1
1
Person
…
Figure 7. Class Relationship and their Multiplicity (Ellipse Sign is for
Hidden Details)
6.4. Sequence Diagram
Sequence diagrams emphasize the sequence of the messages instead of the
relationships between the objects [17]. Objects or roles of the system are lined up in a
row. A dashed line, called lifeline, which flows from each object downward, defines
the time axis. The arrows between the lifelines represent messages being sent between
the objects. The following sections, Sections 6.4.1 to 6.4.3, present certain illustrations
of some sequence diagrams involved in the design.
6.4.1. Sequence Diagram for Login to the System: The student enters a login name
and password, and clicks the submit button on the login page. The browser sends an
HTTP GET request to the Web server. The servlet controller receives the client request
and delegates responsibility to the UserManagerFacade enterprise bean to invoke
isValidUser() method which validates entry:
Copyright ⓒ 2016 SERSC
157
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
SSequence Diagram: Login
e
q
u
LoginPage
e
Student
n
c
Enter user name &
e
password
ServletContr
oller
Password
UserManage
rFacade
model
Receives user input
Delegate duty
to userManager
D
i
a
g
r
a
m
:
L
o
g
i
n
Validate
input
Password checked for validity and user granted
access
Figure 8. Sequence Diagram for Student Login to the System
6.4.2. Sequence Diagram for Add Course: Figure 9 shows the flow of what happens
at Add Course use case as the operation is carried out by student. The course façade is
the duty of the Enterprise Java Beans (EJB) component helping out in the interaction.
S
Sequence Diagram:
e
q
u
e
n
Student
c
e
D
i
a
g
r
a
m
:
Add course
Browse Course
Course
facade
Course UI
Course
Request Course list
Display course list
Select course
Add course
Add course
A
d
d
C
o
u
r
s
e
Course added
Figure 9. Sequence Diagram for Add Course
6.4.3. Sequence Diagram for Pay Tuition: Figure 10 illustrates the process of paying
tuition and the system’s expected behaviour. Various delegations of duties are shown:
158
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
SSequence Diagram: Pay Tuition
e
q
u
e
Payment UI
n
Student
c
e
D
i
a
g
r
a
m
:
Payment
facade
Account
Course
Facade
Make payment
Make payment
Post debit credit
Payment done
Payment done
Open registration
P
a
y
Registration opened
Registration opened
T
u
i
t
i
o
Send notification
Figure 10. Sequence Diagram for Tuition
6.5. Structural Illustration of Packages and Generic Components
Components in actual sense are physical manifestation of software. Components are
easy to implement using object orientation paradigm. There should be low coupling
between components; else basic design patterns would be compromised. In addition,
design patterns make components pluggable and replaceable by other components with
minimal effort.
Figure 11 presents a model of how components are factored out from design.
Payment Package
Course
Registration
Package
Alert
Pack
age
User manager Package
Related classes
Related Classes
Related Classes
(1)PaymentUI
(2)PaymentFacade
(3) Account
(1)RegisterUI
(2)RegisterFacade
(3)Registration
(4) BrowseCourse
(5)CourseUI
Related
Class
es
(1)Mailer
Copyright ⓒ 2016 SERSC
(1)userManagerUI
(2)userManagerFacade
(3)user
159
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
(6)courseFacade
(7)removeCourse
(8)addcourse
Factoring out Generic components
<<file>>
paymentEJB.jar
<<file>>
RegistrationEJB.jar
<<file>>
AlertEJB.jar
<<file>>
UserManagerEJB.jar
Figure 11. A Model of How Components are Factored out from Design
7. Conclusion and Future Remark
Object-oriented paradigm was employed in the domain design. Essential packages
were organized and redundancy eliminated. This led to identifying and factoring out of
essential and generic components which are candidates for domain reuse (and beyond).
Examples are: Payment, Registration, Alert and User Manager. A substantial benefit of
componentization beyond building libraries or Application Programming Interface
(API) is that it is expected to speed up development process and reduce failure. While
reusing libraries or API gives the developer more work to do either at the business
logic level or at the enterprise information system level, a component is designed to be
self-contained, offering an end-to-end service to the user. For example, an EJB
component for user manager is expected to handle various kinds of login, send request
for validation and feedback.
Over and above, if there are vast numbers of reusable components easily accessible
in a common repository, software development endeavour would be a more attractive
task. Given more attention, component based development will be one of the potent
and promising approaches to confront unremitting software crisis.
CBSE is looking to a future where software development will be similar to the
common practices of using pre-fabricated components in designing and implementing
new engineering products such as plugging Random Access Memory (RAM) chips,
drives, input devices, and so on together to couple a system. CBSE is looking beyond
object oriented paradigm. Reuse of individual classes will not produce remarkable
productivity leaps because the granularity is small in comparison with large-grained
granularity of components.
References
[1]
[2]
[3]
[4]
[5]
160
Ivica C. & Magnus L., Component-Based Software Engineering - New Paradigm of Software
Development, Västerås, Sweden [email protected]., (2001).
Ivica C., Stig L. and Michel C., “Component-based Development Process and Component
Lifecycle”,
Journal
of
Computing
and
Information
Technology
CIT
13,
http://www.es.mdh.se/pdf_publications/1014.pdf, vol. 4, (2005), pp. 321-327.
Mikael Å., “Reusability of Software Components in the Vehicular Domain; Doctoral Dissertation,
Department of Computer Science and Electronics, Mälardalen University, Västerås, Sweden:
Mälardalen University, (2008).
Gregory
A.
B.,
“Component-based
Software
Development”,
Retrieved
from:
http://www.sei.cmu.edu/str/descriptions/cbsd.html. (2006).
Brown A. W., “Large-Scale, Component-Based Development”, Upper Saddle River, NJ, USA:
Prentice-Hall, (2000).
Copyright ⓒ 2016 SERSC
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
Clemens S., “Component Software: Beyond Object-Oriented Programming”, 2nd ed. Boston:
Addison-Wesley Professional, (2003).
Ravinder K. and Karambir S., “A Literature Survey on black box testing in component based
software engineering”, International Journal of Advanced Research in Computer Science and
Software Engineering, Available online at: www.ijarcsse.com, vol. 2, Issue 3, (2012), pp. 420-423.
Douglas M., “Mass produced software components”, Software Engineering: Report of a conference
sponsored by the NATO Science Committee, Garmisch, Germany, (1968) Oct. 7-11, Scientific
Affairs Division, NATO, (1969), p. 79.
Lahon M. and Sharma U., “Component Based Software Engineering – At a Glance”, International
Journal of Advanced Research in Computer Science and Software Engineering, vol. 4, Issue 9,
(2014), pp. 605- 609.
Sampath K., Viswanadha S. and Vinaya A. (2013), “Strategies for Designing and Building Reusable
Software Components, International Journal of Computer Science and Information Technologies
(IJCSIT)”, vol. 4, no. 5, (2013), pp. 655-659.
Dietel P. and Deitel H., “JAVA How To Program”, Eight Int’l Edition, Edinburgh Gate, England,
Pearson Education Ltd., (2012).
Nasib S. G. and Grover P. S., “Necessary Guidelines for deriving Component Based Metrics”, In
ACM SIGPLAN SEN, vol. 28, no. 6, (2003), p. 30.
Alex B., Tobias K., Alexi M., Stefan W. and Anders O., “Orca: A component model and
Repository”, Retrieved from http://orca-robotics.sourceforge.net., (2007).
Virendra K and Shabina G, “Enhanced Software Development for Reuse Process Model in
Component Based Software Engineering (CBSE)”, IJCST, vol. 3, Issue 1, (2012), pp. 142 -144.
Adnan K., Khalid K., Muhammad A. and Khan M. N. A. (2014), “A Component-Based Framework
for Software Reusability”, International Journal of Software Engineering and Its Applications,
Retrieved from http://dx.doi.org/10.14257/ijseia.2014.8.10.02, vol. 8, no. 10, pp. 13-24.
Alistair C., “Writing Effective Use Cases”, Michigan: Addison-Wesley, (2001).
M. Fowler, “UML Distilled”, A brief Guide to the Standard Object Modeling Language, Forewords
by Cris Kobryn, Grandy Boosh, Ivar Jacobson and Jim Rumbaugh. Addison Wesley. (2003).
Copyright ⓒ 2016 SERSC
161
International Journal of Software Engineering and Its Applications
Vol. 10, No. 9 (2016)
162
Copyright ⓒ 2016 SERSC