component based software engineering in student management ... · component-based software...

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

*Corresponding Author: [email protected] ISSN: 1738-9984 IJSEIA

Copyright ⓒ 2016 SERSC

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. Component-

Based 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

mailto:[email protected]


Vol. 10, No. 9 (2016)

150 Copyright ⓒ 2016 SERSC

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.

http://en.wikipedia.org/wiki/Service-orientation

http://en.wikipedia.org/wiki/Reusability


Vol. 10, No. 9 (2016)

Copyright ⓒ 2016 SERSC 151

A notably potent instrument in software development is reuse. Rather than “re-

inventing 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.

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].

Requirement Analysis

and identification for

system to be built

Modify requirements and

check if components can

be modified

Architectural Design

Build system by

composing

components

Search/prepare

components to match

requirements

Matching

Components

found

Yes

No


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.


Vol. 10, No. 9 (2016)


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.

Figure 3. Use Case Diagram for Registration Process

Admin/Registrar

Apply for Admission

Sit for Exam

Candidate Process Application

Schedule Exam

Process result

School Admission System

Student Pay Tuition

Register Courses

Register for

medicals

Allocate

accommodation

M.O

Bursar

F.O

H.A

Registration Process


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.

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.

Lecturer

Senate

Key in result

Dean

Result Management

Verify result

HoD Forward result

Approve result

Vote result

Student

Request for

transcript


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



Level: User goal


Student- wants to see a list of courses available

to be taken

Precondition: All courses pre-loaded

Guarantee: courses are available online


(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


Level: User goal


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


(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 4: Remove Course Primary Actor : Student


Level: User goal


Student- remove added course from the

selected

Precondition: At least one course exist in the

course list

Guarantee: course is successfully removed


(1) Students view selected courses

(2) Students select course to remove

(3) SMS removes course successfully

(4) SMS updates and display list

Use Case 5: Pay tuition fees


Secondary Actor : Bursar


Level: Summary


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


(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 6: Approve Registration

Primary Actor : School officer, Head of

Department(HoD)


Level: Summary


Course Advisor – wants to ensure students

register correctly

Precondition: Add course

Guarantee: Registration successfully approved


(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


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.

Figure 5. Object Generalization Showing Class Inheritance

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).

Admin Officer School officer

Person

Student

System Administrator

Register Bursar HoD

Student Account School Account

Account


Vol. 10, No. 9 (2016)


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:

…

Account

Registration

* 1

1

*

1 1 1 1

1

…

Mailer

Person

1

1

Department Semester

Course

Facade CourseUI

Course

1

* 1

*


Vol. 10, No. 9 (2016)


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.

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:

Student

LoginPage ServletContr

oller

S

e

q

u

e

n

c

e

D

i

a

g

r

a

m

:

L

o

g

i

n

Enter user name &

password Receives user input

Password checked for validity and user granted

access

UserManage

rFacade

Password

model

Delegate duty

to userManager Validate

input

Sequence Diagram: Login

Student

Browse Course Course UI

S

e

q

u

e

n

c

e

D

i

a

g

r

a

m

:

A

d

d

C

o

u

r

s

e

Request Course list

Display course list

Select course

Add course

Course

facade

Course

Add course

Course added

Sequence Diagram: Add course


Vol. 10, No. 9 (2016)


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

Class

es

Related Classes

(1)PaymentUI (1)RegisterUI (1)Mailer (1)userManagerUI

(2)PaymentFacade (2)RegisterFacade (2)userManagerFacade

(3) Account (3)Registration (3)user

(4) BrowseCourse

(5)CourseUI

Student

Payment UI Payment

facade

S

e

q

u

e

n

c

e

D

i

a

g

r

a

m

:

P

a

y

T

u

i

t

i

o

Make payment

Make payment

Payment done

Account Course

Facade

Open registration

Registration opened

Post debit credit

Payment done

Registration opened

Send notification

Sequence Diagram: Pay Tuition


Vol. 10, No. 9 (2016)


(6)courseFacade

(7)removeCourse

(8)addcourse

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] Ivica C. & Magnus L., Component-Based Software Engineering - New Paradigm of Software

Development, Västerås, Sweden [email protected]., (2001).

[2] 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.

[3] 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).

[4] Gregory A. B., “Component-based Software Development”, Retrieved from:

http://www.sei.cmu.edu/str/descriptions/cbsd.html. (2006).

[5] Brown A. W., “Large-Scale, Component-Based Development”, Upper Saddle River, NJ, USA:

Prentice-Hall, (2000).

Factoring out Generic components

<<file>>

paymentEJB.jar <<file>>

RegistrationEJB.jar

<<file>>

UserManagerEJB.jar

<<file>>

AlertEJB.jar

mailto:[email protected]

http://www.es.mdh.se/pdf_publications/1014.pdf


Vol. 10, No. 9 (2016)


[6] Clemens S., “Component Software: Beyond Object-Oriented Programming”, 2nd ed. Boston:

Addison-Wesley Professional, (2003).

[7] 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.

[8] 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.

[9] 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.

[10] 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.

[11] Dietel P. and Deitel H., “JAVA How To Program”, Eight Int’l Edition, Edinburgh Gate, England,

Pearson Education Ltd., (2012).

[12] 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.

[13] 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).

[14] 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.

[15] 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.

[16] Alistair C., “Writing Effective Use Cases”, Michigan: Addison-Wesley, (2001).

[17] 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).

http://www.ijarcsse.com/

http://orca-robotics.sourceforge.net/

http://dx.doi.org/10.14257/ijseia.2014.8.10.02


Vol. 10, No. 9 (2016)


component based software engineering in student management ... · component-based software...

Documents