Enterprise Ontology IN4148TU

Assignment 3: Education Administration
Identification of Business Components

Christiaan ten Berg Thieme Hennis

1149563 1052381

c.p.r.tenberg@student.tudelft.nl t.a.hennis@student.tudelft.nl

1

Index
1. Introduction.........................................................................................................................................................3 2. Case description.................................................................................................................................................4 3. Identification of business components...........................................................................................................6 Discussing the relationship weights..............................................................................................................11 Graphical representations...............................................................................................................................12 Component description...................................................................................................................................13 4. Component diagrams of Business Components..........................................................................................15 Services for component 1................................................................................................................................15 Services for component 2................................................................................................................................15 Services for component 3................................................................................................................................16 Services for component 4................................................................................................................................16 Services for component 5................................................................................................................................16 5. Orchestration of business components.........................................................................................................17 6. Deployment of orchestration..........................................................................................................................22 7. Remarks and conclusions................................................................................................................................23 On the Standard Solution................................................................................................................................23 On the Assignment...........................................................................................................................................23 On the BCI-3D tool...........................................................................................................................................23 Appendix A – Standard Solution......................................................................................................................25

2

1. Introduction
This third and final assignment for the course IN4148 – Enterprise Ontology and Business Components – describes the different steps towards identification and orchestration of business components. The case used for this assignment is the same case as for the first assignment, namely the Education Administration case, described in the following chapter. A standard solution, on which the results in this report are based, is provided in appendix A. In chapter 3 the BCI-3D tool for the identification of the business components is used. All five BCI-3D tables (io, fun, ioio, funfun, iofun) and the 3D-graphical representation of the dependencies between the nodes before and after applying the optimization algorithm are provided. Additionally the weights assigned to the different relationships we have chosen are listed, including some remarks about the advantages of using the weights assigned to the relationships. Finally a list is given with all process steps and information objects assigned to each single component. In the fourth chapter a UML/2.0 component diagram listing all business components, their services and parameters is included, with an explanation about how we identified the single services. The 5th chapter shows a UML/2.0 activity diagram for the orchestration of the business components to an information system. The result is a component diagram including the orchestration and the service calls. Besides, the single process steps executed by the orchestration are provided as an activity diagram. The last part of the assignment is found in chapter 6. The orchestration and the business components on systems are deployed in a UML/2.0 deployment diagram and the result is explained. The last chapter includes some remarks about the modeling tool and other issues we came about during this assignment, which might be interesting input for next year. We would like to thank Dr.Dipl-ing. Antonia Albani for her interesting and informative lectures, and for the BCI 3D modeller tool which really helped us in the identification of the business components. Christiaan ten Berg Thieme Hennis November 2006

3

2. Case description
The HIT (Holland Institute of Technology) is a university of technology in the Netherlands, comprising fifteen schools, in seven faculties, which offer Bachelor and Master programs in a variety of technological areas. One of them is the school for Information Architecture (IA). This school offers a two-year Master Program with the same name. General information about the program can be found on the (public) website of the school. Although most students who do the IA program have either a B.Sc. in Computer Science (CS) or a B.Sc. in Systems Engineering, Policy Analysis and Management (SEPAM) from HIT, also students from other universities, in principle from all over the world, follow the Master program IA. In the school is a department of Educational Administration that deals with all administrative matters concerning the Master Program. The operational activities of this department, for which we will use from now on the shorthand name EdA, are described hereafter. The first thing students have to do if they want to follow the IA Program is to apply for admission. To this end they have to fill out the so-called Program Admission Form, of which a PDF can be downloaded from the website of the school. One has to add photocopies (Xerox) of the Bachelor diploma one possesses, or of a diploma that one considers to be an alternative (e.g. a Master diploma). The applications for admission are collected and processed by the Admission Office of EdA. The rules for admission are as follows: 1) Students with a BSc in CS from HIT or from some other Dutch university or from a European university in the so-called IDEA-league1 are directly admitted. 2) Students with a BSc in SEPAM from HIT or with a BSc in Business Administration from a Dutch university are directly admitted. 3) All other applications are passed through to the Program Director of the IA Program. The Program Director decides on all other individual cases, and in doing so also refines existing admission rules and may conceive new ones. These rules are stored in the so-called Admission Rule Base, which originally only contained the first two rules above. Approved admissions are entered into MASH (MSc Administration System HIT). A confirmation of the approval of an admission is sent to the student by e-mail, as well as by a written letter, which is sent by the public postal mail service. After having been admitted, students have to enroll in the courses they want to follow by means of the WhiteBoard system. The complete program and schedule of the courses can be found on the school’s website. Successful enrolments are confirmed to the students by a corresponding e-mail message. The WhiteBoard system is also used for all kinds of communication between the lecturers of the courses and the students. The scheduling of the courses is also a task of the EdA. Scheduling a course means that one has to find a free lecture time slot and a free lecture hall for a course, such that there are no conflicts of coinciding lectures within the IA program. Put differently, students can always take the courses they want. A lecture time slot consists of two consecutive lecture hours. A lecture hour effectively is 45 minutes, since by tradition it starts with 15 minutes spare time. A weekday has 8 lecture hours, usually identified by the numbers 1 through 8. So, an example of a lecture time slot is “Friday, 5 th and 6th hour”. The course year is divided into four periods of 9 weeks. Lectures are given in the first seven weeks. The eighth week is free for study and in the ninth week are the exams. The availability of the lecturers is not taken into account while scheduling the courses, which means that they are considered to be available. Of course, time conflicts for the lecturers in the schedule are avoided. Exams are scheduled either in the morning (9-12 hrs.) or in the afternoon (14-17 hrs.) of the weekdays in the ninth week of a period. This is also a task of the EdA. Students have to register explicitly for the

4

exams, via MASH. The system produces a list of all registered students for an exam, which is sent to the examinator (who is usually the same professor as the lecturer of the course). After having valuated the answers of the students, the examinator writes the grades on the list and sends it back to the EdA. These data then are processed in MASH. For security reasons, students are not able to inspect their grades online. Instead they can apply to the students’ desk of the EdA and ask for a printout of all their grades. The grades per course are also published on the WhiteBoard system. They can be accessed by the students on the basis of their personal user code and password. If a student has passed all exams of the IA Master Program, he or she is entitled to receive the diploma. In order to get a diploma, one has to fill out the so-called Diploma Application Form, which can be downloaded from the school’s website. These forms have to be handed over or sent to the EdA who passes them to the Examination Board. This board formally decides about the issuing of diplomas. The EdA records these decisions.

5

3.

Identification of business components

In this chapter the BCI-3D tool for the identification of the business components was used. All five BCI-3D tables (io, fun, ioio, funfun, iofun) and the 3D-graphical representation of the dependencies between the nodes before and after applying the optimization algorithm are provided. Also the weights assigned to the different relationships are given. Some remarks about the advantages of using the weights assigned to the relationships have been made as well. Finally a list is given with all process steps and information objects assigned to each single component. IO Admission Approved Admission Exam Registered Exam Student Registered Student Course Enrollment Person Program Exam Period Course Period Admission Rules Course Schedule Exam Schedule
Table 1 - Information Objects

Shortcut A AA E RE S RS C EN P PR EP CP AR CS ES

is part of external component

CPB4 CPB1 CPB4 CPB1 CPB2 CPB5 CPB5 CPB3

6

Function accept program admission produce program admission promise program admission request program admission state program admission accept admission approval produce admission approval promise admission approval request admission approval state admission approval accept course enrollment produce course enrollment promise course enrollment request course enrollment state course enrollment accept exam registration produce exam registration promise exam registration request exam registration state exam registration accept course scheduling produce course scheduling promise course scheduling request course scheduling state course scheduling accept course management produce course management promise course management request course management state course management accept exam scheduling produce exam scheduling promise exam scheduling request exam scheduling state exam scheduling accept exam management produce exam management promise exam management request exam management state exam management
Table 2 - Fun

Shortcut T01/ac T01/ex T01/pm T01/rq T01/st T02/ac T02/ex T02/pm T02/rq T02/st T03/ac T03/ex T03/pm T03/rq T03/st T04/ac T04/ex T04/pm T04/rq T04/st T05/ac T05/ex T05/pm T05/rq T05/st T06/ac T06/ex T06/pm T06/rq T06/st T07/ac T07/ex T07/pm T07/rq T07/st T08/ac T08/ex T08/pm T08/rq T08/st

is part of external component

7

IO-IO Admission Approved Admission Exam Registered Exam Student Registered Student Course Enrollment Person Program Exam Period Course Period Admission Rules Course Schedule Exam Schedule
Table 3 – IO-IO

related-to P, PR

founded-on AR

state-of A E S

C, S

CP EP

8

Fun-Fun accept program admission produce program admission promise program admission request program admission state program admission accept admission approval produce admission approval promise admission approval request admission approval state admission approval accept course enrollment produce course enrollment promise course enrollment request course enrollment state course enrollment accept exam registration produce exam registration promise exam registration request exam registration state exam registration accept course scheduling produce course scheduling promise course scheduling request course scheduling state course scheduling accept course management produce course management promise course management request course management state course management accept exam scheduling produce exam scheduling promise exam scheduling request exam scheduling state exam scheduling accept exam management produce exam management promise exam management request exam management state exam management
Table 4 – Fun-Fun

Normal T01/st T01/ex T01/pm T01/ac T01/pm T02/st T02/ex T02/pm T02/ac T03/st T03/ex T03/pm T03/ac T04/st T04/ex T04/pm T04/ac T05/st T05/ex T05/pm T05/ac T06/ex T06/st T06/ex, T05/rq T06/pm T06/ac T08/ex T07/st T07/ex T07/pm T07/ac T08/st T08/ex, T07/rq T08/pm T08/ac

Optional

Main

T02/rq

9

IO-Fun Admission Approved Admission Exam Registered Exam Student Registered Student Course Enrollment Person Program Exam Period Course Period Admission Rules Course Schedule Exam Schedule
Table 5 – IO-Fun

create use T01/ex T01/rq, T02/rq, T02/pm, T02/ex, T02/st, T02/ac, T01/pm, T01/st, T01/ac T02/ac T04/ex, T07/ex T04/ac T01/ex, T02/ex T04/ac T03/ex, T05/ex T03/ac T01/ex, T02/ex T01/ex, T02/ex T08/ex T06/ex T01/ex T05/ex T05/rq, T06/rq, T06/pm, T06/ex, T06/st, T06/ac, T05/pm, T05/st, T05/ac T07/ex T07/rq, T08/rq, T08/pm, T08/ex, T08/st, T08/ac, T07/pm, T07/st, T07/ac

10

Discussing the relationship weights
The weights we have assigned to the different relationships can be found below in table 6. Adjusting the weights of the relationships enabled us to identify and compose the Business Components easier. We have used a new type of relationship, founded-on, to describe the relationship between the Information Objects 'Admission' and 'Admission Rules'. Sometimes it was a bit hard to "guess" the weights of the various relationship types in the right direction because the BCI 3D tool was somewhat like a blackbox model, you did not exactly know how the different weights would effect the identification process. In the end however we were able to successfully identify 5 components.

Table 6 - Relationship weights

11

Graphical representations

Figure 1 - Graphical representation before optimization

Figure 2 - Graphical representation after optimization

12

Component description
In the list below you can find the different business components we have identified by using the BCI3D tool. For each component the process steps and information objects are given. Component 1: Admitter - Admission - promise program admission - accept admission approval - produce admission approval - state program admission - promise admission approval - state admission approval - request program admission - request admission approval - accept program admission - produce program admission - Approved Admission Component 2: Course Manager - Course Schedule - produce course management - promise course management - state course management - accept course management - promise course scheduling - state course scheduling - request course scheduling - accept course scheduling - request course management - produce course scheduling Component 3: Exam Manager - Exam Schedule - promise exam management - produce exam management - request exam scheduling - state exam management - promise exam scheduling - state exam scheduling - accept exam scheduling - request exam management - accept exam management - produce exam scheduling Component 4: Course Enroll Manager - promise course enrollment - produce course enrollment - state course enrollment - accept course enrollment - request course enrollment

13

- Enrollment Component 5: Exam Registration Manager - produce exam registration - state exam registration - promise exam registration - accept exam registration - request exam registration - Registered Student - Registered Exam Extern Student Data: - Student - Person Programs: - Program Admission Rules: - Admission Rules Extern Course Types: - Exam - Course Time Data: - Exam Period - Course Period

14

4. Component diagrams of Business Components
Below several diagrams of the business components will follow, including their services and parameters, with an explanation about how we identified the single services.

Services for component 1
In component 1, admitter, there are only two provided services, because the component is fully independent of other components.

Promise Program Admission

ProvideApprovedAdmission (Approved Admission )

Component 1 Admitter
ProvideAdmission (Admission )

Figure 3 - Component 1 "Admitter"

Services for component 2
In component 2, course manager, there also is only one provided service, which is the service of managing courses.

Promise Course Scheduling

Component 2 Course Manager
ProvideCourseSchedule (Course Schedule)

Figure 4 - Component 2 "Course Manager"

15

Services for component 3
Component 3 provides the service of managing exams.

Promise ExamScheduling

Component 3 Exam Manager

ProvideExamSchedule (Exam Schedule)

Figure 5 - Component 3 "Exam Manager"

Services for component 4
The fourth component provides the enrollment service.

Promise CourseEnrollment

Component 4 Course Enroll Manager

ProvideEnrollment (Enrollment)

Figure 6 - Component 6 "Course Enroll Manager"

Services for component 5
The fifth component, the exam registration manager, again provides two services, which are Registered Student and Registered Exam. We have defined it in this way, because the transaction of registering for an exam results in two result types, as defined in the State Model of the standard solution.

Promise ExamRegistration

Component 5 Exam Registration Manager

ProvideRegisteredStudent (Registered Student)

ProvideRegisteredExam (Registered Exam )

Figure 7 - Component 5 "Exam Registration Manager"

16

5. Orchestration of business components
This 5th chapter describes the orchestration of the business components to an information system. The result is a component diagram including the orchestration and the service calls. Also, the single process steps executed by the orchestration are provided as an activity diagram. To ensure the readability of our diagram we have split the activity diagram up into five parts. This is possible because the components are fully independent of each other. However one should read the presented diagrams hereafter as if they are one.

No decision by the Program Director needed

PromiseProgram Admission call received

Call internal ProgramAdmissio n

ProcessResults call received Decision by the Program Director needed

Call ProduceAdmission Approval

ProcessResults call received

ProcessResult

PromiseProgramAdmission ProvideApprovedAdmission (Approved Admission)

Component 1 Admitter
ProvideAdmission (Admission)

Figure 8 – Admitter Orchestration

17

PromiseCourse Scheduling call received

Call internal CourseScheduling

ProcessResults call received

ProcessResult

PromiseCourseScheduling

Component 2 Course Manager
ProvideCourseSchedule (Course Schedule)
Figure 9 – Course Manager Orchestration

18

PromiseExam Scheduling call received

Call internal ExamScheduling

ProcessResults call received

ProcessResult

PromiseExamScheduling

Component 3 Exam Manager

ProvideExamSchedule (Exam Schedule)

Figure 10 – Exam Manager Orchestration

19

PromiseCourse Enrollment call received

Call internal CourseEnrollment

ProcessResults call received

ProcessResult

PromiseCourseEnrollment

Component 4 Course Enroll Manager

ProvideEnrollment (Enrollment)

Figure 11 – Course Enroll Manager Orchestration

20

PromiseExamR egistration call received

Call internal ExamRegistration

ProcessResults call received

ProcessResult

PromiseExamRegistration

Component 5 Exam Registration Manager

ProvideRegisteredStudent (Registered Student)

ProvideRegisteredExam (Registered Exam)
Figure 12 – Exam Registration Manager Orchestration

21

6. Deployment of orchestration
The orchestration and the business components on systems are deployed in a UML/2.0 deployment diagram, which is shown below.
ProvideRegisteredExam ProvideRegisteredStudent (Registered Exam ) (Registered Student ) ProvideEnrollment (Enrollment) ProvideAdmission (Admission)

EdA Front-end
Admission Course Enroll Management Exam Registration Management

ProcessResult Promise Program Admission Component 1 Admitter

ProvideApproved Admission (Approved Admission ) ProvideAdmission (Admission )

ProcessResult Promise Course Enrollment Component 4 Course Enroll Manager ProvideEnrollment (Enrollment)

ProcessResult Promise Exam Registration Component 5 Exam Registration Manager

ProvideRegisteredStudent (Registered Student) ProvideRegisteredExam (Registered Exam)

ProvideCourseSchedule (Course Schedule )

ProvideExamSchedule (Exam Schedule)

EdA Back-end

Course Management

Exam Management

ProcessResult Promise Course Scheduling Component 2 Course Manager ProvideCourse Schedule (Course Schedule)

ProcessResult Promise Exam Scheduling Component 3 Exam Manager

ProvideExam Schedule (Exam Schedule)

Figure 8 - Deployment of orchestration

In this case we are dealing with 5 separate and autonomous components and related services. These can be divided into ones that have an external function, the Front-end services of EdA, and ones that are internal, EdA Back-end. We assumed that the Back-end services are in some way needed by the Front-end part of EdA, which can be seen in the middle. Furthermore, according to our analysis, the components do not need any external information, and can deliver their services without. Therefore just the services are described, which can be seen on top.

22

7. Remarks and conclusions
The last chapter includes some remarks about the modeling tool and other issues we came about during this assignment, which might be interesting input for next year.

On the Standard Solution
The results of this assignment are based on a standard solution of the Educational Administration case provided by Prof.Dr.Ir. Jan L.G. Dietz. While studying this standard solution we found some errors and inconsistencies. These errors and inconsistencies did not prevent us from making the assignment properly but did cause some confusion and made us assume some aspects. Below we describe some issues in the standard solution that might need further attention:  The Object Fact Diagram (OFD) and Object Property List (OPL) (which, by the way is contradictory called Object Property Table) together form the State Model (SM) and are completely based on the Action Model. When we made the first and second assignment we have paid much attention on the consistency between the different aspect models and at sometimes it was very hard to ensure this. We were therefore highly surprised that we couldn’t find any of the properties listed in the OPL in the AM. We did not understand why the distinction between Student and Admission was made. Now a Person would only become a student when he registers for an exam or enrolls for a course. Isn’t someone who has been admitted for a particular program a Student as well? On page 180 of the book Enterprise Ontology of Prof.Dr.Ir. Jan L.G. Dietz it is stated that the Information Use Table (IUT) specifies, for every object class, fact type, and result type from the SM, in which steps of the PM its instances are used. In the standard solution (as well as in the example library case in the book) the result types weren’t specified. This could also mean a typographical error in the book was made. The Admission Rules bank CPB3 has not been described in the Bank Contents Table (BCT)

On the Assignment
While making this assignment we sometimes needed documentation on how to solve certain problems and address certain situations. However we found that the documentation on the Business Components Identification Process was very little and brief. Below are some of the questions we asked ourselves and problems we ran into:   How does one describe self-initiation links in the funfun table? The solution on the SSND case presented in the sheets provided by Dr.Dipl-ing. Antonia Albani and in the paper ‘The Benefit of Enterprise Ontology in Identifying Business Components’ by Dr.Dipl-ing. Antonia Albani and Prof.Dr.Ir. Jan L.G. Dietz differs from each other (for example the iofun table). This caused some confusion. In the paper ‘The Benefit of Enterprise Ontology in Identifying Business Components’ by Dr.Dipl-ing. Antonia Albani and Prof.Dr.Ir. Jan L.G. Dietz it is stated that object classes, which are provided by external information systems – that concern the data, which is provided by the external production banks – are traded in a special way in the BCI-3D method. We found the term ‘traded in a special way’ highly ambiguous and we had to make some further assumptions in the identification process, especially regarding the identification of external Information Objects.

On the BCI-3D tool
The BCI-3D tool enabled us to identify and compose the Business Components easier. However at sometimes it was a bit hard to "guess" the weights of the various relationship types in the right

23

direction because the BCI 3D tool was somewhat like a blackbox model, you did not exactly know how the different weights would effect the identification process beforehand. Also we already had an idea which components would had to be identified. So the identification process with the BCI-3D tool became more or less a verification process of your own view on the problem. We would have appreciated it more if the BCI-3D tool provided the solution by it self with as less intervention of the user as possible.

24

Appendix A – Standard Solution
The standard solution, provided by Prof. Dr. Ir. Jan L.G. Dietz, can be read on the following pages.

25

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.