Hour Registration System
Obligatory exercise 2 in INF5120 by Group 19
- Fredrik Danielsen
- Trond Andresen
- Kristian Syversen
- Berge Stillingen
1. BUSINESS MODEL ..............................................................................................................................................................2
1.1 ASSUMPTIONS AND LIMITATIONS .......................................................................................................................................2
1.2 SCOPE AND STAKEHOLDERS ............................................................................................................................................2
1.3 CONTEXT DIAGRAM ...........................................................................................................................................................4
1.4 GOAL MODEL .....................................................................................................................................................................5
1.5 BUSINESS RESOURCE MODEL ..........................................................................................................................................6
1.6 BUSINESS PROCESS & ROLE MODEL ...............................................................................................................................7
2. REQUIREMENTS MODEL.................................................................................................................................................9
2.1 SYSTEM BOUNDARY ..........................................................................................................................................................9
2.2 SUBSYSTEM GROUPING MODEL .....................................................................................................................................11
2.3 REFERENCE ARCHITECTURE ANALYSIS MODEL.............................................................................................................13
2.4 UC SCENARIO MODEL ....................................................................................................................................................13
3. ARCHITECTURE MODEL...............................................................................................................................................16
3.1 INTERFACE & INTERACTION SPECIFICATION...................................................................................................................16
3.2 COMPONENT STRUCTURE ...............................................................................................................................................17
3.3 INTERNAL DESIGN ............................................................................................................................................................19
4. PLATFORM SPECIFIC MODEL .....................................................................................................................................22
4.1 COMPONENT IMPLEMENTATION MODEL .........................................................................................................................22
4.2 DEPLOYMENT MODEL .....................................................................................................................................................23
4.2 DEPLOYMENT MODEL .....................................................................................................................................................23
5. REFLECTIONS...................................................................................................................................................................24
6. REFERENCES ....................................................................................................................................................................24
1
1. Business Model
1.1 Assumptions and limitations
The Hour Registration System (HRS) should be build as generic solution that can be used by businesses that are “project
driven”. When a contract with a customer has been signed, a project should be defined and created in the system. We assume
that the system is build to obtain better control of such customer related projects, where hours spent on projects determine
how customers should be invoiced. The goal of implementing the system is to have better control of the wage costs and
project incomes, and monitor other resources spent on each project. The system is build primarily to be used by the company
that develops it. The company will however consider selling the system to other external businesses. Company managers are
the ones that fund the development of this system.
Most important limitations and the aspects of an hour registration system not to be reflected in our business specifications:
- Other competitors on the market that sell hour registration systems.
- Government stakeholders (e.g. legal and tax interests).
- The ones that develop the system (programmers, system architects etc).
- Internal projects that are not customer related
- What kind of services or products offered, related to a customer project.
1.2 Scope and Stakeholders
We assume here that the company managers also are the company owners and the decision makers. In co-operation with
sales, they are also the ones that make the decision of which projects the company should carry out. Sales department is also
responsible for marketing and getting new project customers.
Project managers are the ones that merely create a project in the system and allocate the employees that should participate.
Once the project has been initiated by the company managers, the project manager is in charge of the project. The company
managers will from then on only monitor the project process.
Project manager will assign tasks to the participants that are relevant to a project. As hours are being registered on a project,
the project manager will invoice the customer at the end of the project.
2
Figure 1 : Scope and stakeholders
3
1.3 Context diagram
The following activity graph shows a high level description of the business process concerning the hour registration system:
Figure 2 : Context diagram
4
1.4 Goal model
The main goal is to keep track of the resources that are used on customer related projects. We have also showed the most
important sub goals in this hierarchy. Potentially there could be more goals defined here.
Figure 3 : Goal model
5
1.5 Business Resource Model
These are the main things and concept relevant to the Hour registration system in a business point of view. We have tried to
model the concepts necessary in relation to our limitations given in chapter 1.1.
Figure 4 : Business Resource Model
6
1.6 Business Process & Role Model
The following model is decomposition of the "Execute project" activity from the Context diagram (section 1.3) given earlier.
At level 2 (next page), we have chosen to decompose the process "Perform task and report", that is most relevant to the use of
the hour registration system.
Figure 5 : 1.6 Business Process & Role Model
7
Figure 6 : Business Process & Role Model Level 1
8
2. Requirements Model
2.1 System Boundary
To give a glance at the system boundary we have included a high level system boundary, as well as a detailed system
boundary (next page). The first is shown to give an exclusive picture of the actors and an overview of their roles in relation to
the system.
Figure 7 : High level system boundary
9
Figure 8 : Detailed system boundary
10
2.2 Subsystem Grouping Model
We assume that about the employees are taken from an already existing system used by the company, hence the resource
service "EmployeeInfo". This system is normally used by Human Resources and/or Accounting already.
This model shows the grouping of the adjacent use cases in the Detailed System Boundary Model.
Notice that the use cases "Register Data" and "Extract Data" has been split into four use cases in the SystemDataService
group, and these use cases use the resource services ProjectInfo and EmployeeInfo.
Figure 9 : Subsystem Grouping Model
11
USE CASE DESCRIPTIONS:
We have chosen to show you 2 use case descriptions: “01.Create Project” and “05.Register Hours”.
Use Case 01
Priority
Goal
Actors
Pre-conditions
Post-conditions
Façade
Quality
requirements
Scenario
Description
Create project
1
Create and store new project in system.
Project manager
Contract with customer signed.
Project data added successfully to the system.
Enable hour registration for this project.
Use Case 05
Priority
Goal
Actors
Pre-conditions
Post-conditions
Register Hours
1
Register work period in system.
Project participant
- Work done on project according to given assignment.
- Hours registered are within time budget.
- System correctly updated according to registered work period
Hours calculated for given work period can be invoiced.
Façade
Quality
requirements
Scenario
Description
New project requires system to be updated.
Step
Action
1
Get project data from company managers
2
Login
3
Add project data
3.1 Use case 2: Allocate employees
3.2 Use case 3: Assign task
3.3 Use case 4: Create time budget.
5
Update system
6
Logout
Work done on a customer related project.
Step
Action
1
Login
2
Lookup relevant project (System authorizes project participant)
3
Lookup or register task
4
Register start time and stop time on work period
5
Logout
12
2.3 Reference Architecture Analysis Model
This is a direct mapping to the Subsystem grouping model. The "Info" components represent two separate persistence
systems, i.e. database management systems.
Figure 10 : Reference Architecture Model
2.4 UC Scenario Model
We have chosen to strictly limit our specifications here and will document only one use case: "01. Create project".
GOALS:
Create a customer related project in the system, enabling project participants to register hours they will be working on this
project.
ACTORS/ROLES:
The responsibility is assigned to the role of the project manager which could be any employee with given rights to create a
project in the system.
13
NON-FUNCTIONAL REQUIREMENTS:
Security and Reliability should be considered an important non-functional requirement as sensitive data may be given in the
contract with the customer. Naturally, info given in the contract will be input to the system, so preventing unauthorized
access to the system should have high priority.
Figure 11 : Create project detailing
DESCRIPTION OF SCENARIOS (FORMAL):
After the initiation of a project the assigned project manager will create a project in the system. Various other use cases
include this use case as shown in the model above. Some of them can be considered optional as a project manager isn’t
obligated to allocate employees (02), assign tasks (03) and (04) create time budget at the same time. The last use case shown
in this context (13) is a general business service use case related to the Create project use case.
14
Figure 12 : Use case scenarios
15
3. Architecture model
3.1 Interface & Interaction Specification
This can be viewed as an expansion of Reference Architecture Model, where appropriate interfaces are added.
The model shows the mapping of the different groups in the Subsystem Grouping to System Components.
Figure 13 : Interface & Interaction Specification
A very simple example showing how components can communicate, when a project manager uses the system.
Figure 14 : Component collaboration: Register project Use case
16
3.2 Component structure
This model shows how the data from the ProjectParticipantEditor user interface uses the ProjectParticipantEdiorService to
handle the input.
Figure 15 : Component structure Project Participant Editor
This model shows the different components in the SystemDataService component in The Interface & Interaction Model.
17
Figure 16 : Component structure System Data Service
18
3.3 Internal design
Our "BCE analysis" shows the different interfaces and controllers in the ProjectParticpantEditor Component Structure.
The LoginManager is responsible for feeding the ProjectController and WorkController with information about the logged in
user. The ProjectController and WorkController then use the login information handle project and work information for the
user in the current session.
Employee login system is lists with user information such as status and usernames and passwords.
ProjectData and WorkData are persistent objects with information about the project participation, assignment, tasks and
reports for the different users.
Figure 17 : BCE analysis
19
"Class mapping ProjectParticipantEditor" maps the Interfaces to classes in ProjectParticpantEditor BCE analyses.
AssignmentViewDialog contain a WorkCalendarDialog that is shown when dialog is opened.
Users can select an assignment and view their different task in this assignment in the TaskViewDialog. Users can also open
and view the project they'
re currently participating in by opening the ProjectViewDialog from the AssignmentViewDialog.
And they can select an assignment and write a report on it by opening the AssignementReportDialog.
The ProjectViewDialog shows the different projects a user participates in. Users can select a project and view their
assignments in the project with the AssignmentViewDialog. Users can also register their work hours for the different projects
in the RegisterHourDialog which is opened from the ProjectViewDialog.
Figure 18 : Class mapping ProjectParticipantEditor
20
"Class Design ProjectParticipantEditor" shows the different interfaces and controllers in the ProjectParticpantEditor
Component Structure.
Figure 19 : Class Design ProjectParticipantEditor
21
4. Platform Specific Model
4.1 Component Implementation Model
Using the J2EE UML profile, we will implement the hour registration system with JSP pages, EJB session beans and EJB
entity beans. The Platform specific model reflects only the classes that relates to the actual registration of hours (work
periods). Showing the "complete" PSM would result in a huge model.
Additionally, we have chosen not to show the potential public methods and/or private variables.
Figure 20 : Component Implementation Model
22
4.2 Deployment Model
The Hour registration system is deployed as a classic 3-layered application. Only web clients can access the system. A user
interface for an administrator may be an exception to this, but it is not given in this context.
Figure 21 : HRS Deployment Model
23
5. Reflections
As we have worked our way all the way from Business Model to Platform Specific Model, we feel that changes should be
made to the models created in the early stages of this obligatory exercise. Specifications given the Business Model and the
Requirements Model might not have been reflected in the Architecture Model and the Platform Specific Model.
However the Comet Methodology is based on iterative development, so we have decided not to "go back" and make changes
to the earlier models. This document should be considered an Iteration 1 product, although it has cost us many hours of work.
We have used to Enterprise Architect v 4.00 (Trial version) to model.
6. References
- COMET Methodology Handbook
- INF5120 Lecture Notes
24