Sample - G4

BAHIR DAR UNIVERSITY INSTITUTE OF TECHNOLOGY
SCHOOL OF ELECTRICAL AND COMPUTING ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Architectural documentation
HRMS on Amahara Regional Correctional Center
Submitted To: Instructor Esubalew Group Member: Abreham h/mariam.011/2000 Adissu zeleke.019/2000 Ambaye Tadesse...... 035/2000 Mesfin Anegagerie .. 246/2000 Yared Mekuria .371/2000 Submitted Date: June, 2011
Architectural document on ARCC HRMS
Table of Contents
1. Overview....................................................................................................................................4 1.1 1.2 1.3 1.4 2. 3. 4. Purpose Scope ................................................................................................................................. 4 ..................................................................................................................................... 4
Intended Users .............................................................................................................................. 5 Overview ....................................................................................................................................... 6
References .................................................................................................................................6 Definitions, Acronyms and Abbreviations .............................................................................7
Conceptual Framework ...............................................................................................................8 4.1 4.2 4.2.1 4.3 4.4 4.5 4.6 4.7 Architectural Description in Context ............................................................................................ 8 Architectural Goals and Constraints ............................................................................................. 9 Quality Attributes for the HRMS ............................................................................................. 10 Stakeholders and their Roles ...................................................................................................... 22 Architectural Activities in the Life Cycle ..................................................................................... 22 Interface specification................................................................................................................. 23 Components interaction ............................................................................................................. 25 Uses of Architectural Descriptions .............................................................................................. 25
5.
Architectural Description Practices ............................................................................................ 27 5.1 5.2 5.3 Architecture documentation ...................................................................................................... 27 Identifications of stakeholders and concerns ............................................................................. 27 Architectural views ..................................................................................................................... 29 Module Viewpoint ...................................................................................................................... 30 Deployment view ........................................................................................................................ 34 Process view................................................................................................................................ 36 Use case view .............................................................................................................................. 38
Group 4 Students
Page 2
Architectural document on ARCC HRMS List of figures

Figure 1: conceptual model...................................................................................................10 Figure 2: architectural description in operation of the system24 Figure 3: high level view of system architecture30 Figure 4: Package overview diagram for the HRMS system32 Figure 5: Decomposition of the Domain module package of ARCC HRM system.33 Figure 6: Decomposition of the Organization package of ARCC HRM system..34 Figure 7: deployment view.36 Figure 8: class diagram.38 Figure 9: use case view of the system41
List of tables
Table 1: prioritized Quality Attribute Requirements for the HRMS ........................................................... 10 Table 2: Usability Scenarios ........................................................................................................................ 11 Table 3: Performance Scenarios ................................................................................................................. 13 Table 4: Availability Scenarios..................................................................................................................... 14 Table 5: Security Scenarios ......................................................................................................................... 15 Table 6: Scalability Scenarios ...................................................................................................................... 17 Table 7: Testability Senario ......................................................................................................................... 18 Table 8: Modifiability Scenarios .................................................................................................................. 19 Table 9:Components interaction ................................................................................................................ 25 Table 10: stakeholders and their concerns ................................................................................................. 28
Group 4 Students
Page 3
1. Overview
1.1 Purpose
This document provides a comprehensive architectural overview of the Amahara Correctional center HRM system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
1.2
Scope
This Software Architecture Document provides an architectural overview of the HRM System. It has been generated directly from the HRM Analysis & Design Model implemented in previously. This recommended practice addresses the architectural description of the software that contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. The scope of this recommended practice encompasses those products of system development that capture architectural information. This includes architectural descriptions that are used for the following: 1. Expression of the system and its evolution 2. Communication among the system stakeholders 3. Evaluation and comparison of architectures in a consistent manner 4. Planning, managing, and executing the activities of the system development 5. Expression of the persistent characteristics and supporting principles of a system to guide acceptable change 6. Verification of a system implementations compliance with an architectural description
Group 4 Students
Page 4
1.3
Intended Users
The principal class of users for this recommended practice comprises stakeholders in system development and evolution, including the following: Those that use, own, and acquire the system Users (acquirer) Operator client Those that develop, describe, and document architectures such as architects Those that develop, deliver, and maintain the system Architects Designers Programmers Maintainers Testers Those who oversee and evaluate systems and their development Chief information officers Auditors Independent assessors Quality assurance staff Domain engineers Suppliers Project managers
Group 4 Students
Page 5

1.4 Overview
This architectural document represents the architecture and provides an overview of the overall scheme of things highlighting architecturally significant elements. And our architecture description is for the whole system and major sub parts of our system. The document will also include the contextual description of our system, system stakeholders, roles and concerns, architectural view points and over all benefits obtained from architectural description.
2. References
IEEE 1471-2000.pdf Design Lecture slides http://www.scribd.com/doc/3263270/Human-Resource-Management-Systems-HRMS Documenting software architecture 2nd Edition.paul clements, David garlan and pawl merson. IEEE Std 1471-2000, IEEE Recommended Practice for Architectural
Group 4 Students
Page 6
3. Definitions, Acronyms and Abbreviations

Human resource management system: the system in the intersection between human resource management (HRM) employee staffs and technology which is intended to manage manual operations concerning the employees of the organization. ARCC: Amhara regional correction center
Acquirer: An organization that procures a system, software product, or software service from a supplier. (The acquirer could be a buyer, customer, owner, user, or purchaser.) Architect: The person, team, or organization responsible for systems architecture. Architecting: The activities of defining, documenting, maintaining, improving, and certifying proper implementation of architecture. Architectural description (AD): A collection of products to document architecture. Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Life cycle model: A framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, which spans the life of the system from the definition of its requirements to the termination of its use. System: A collection of components organized to accomplish a specific function or set of functions. System stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. View: A representation of a whole system from the perspective of a related set of concerns.
Group 4 Students
Page 7

Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
4. Conceptual Framework
4.1 Architectural Description in Context
A system inhabits an environment. A systems environment can influence that system. The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems. In our system, HRMS system is dependent with prison management system by which it calculate the required number of military employees based on the number of prisoners from prison management system.
Group 4 Students
Page 8
Figure 1: conceptual model

4.2 Architectural Goals and Constraints
There are some key requirements and system constraints that have a significant bearing on the architecture. They are: 1. The existing Human Management System at Amahara Correctional Center must be accessed to retrieve all necessary information for the all regional center. 2. The HRMS System must ensure complete protection of data from unauthorized access. All remote accesses are subject to user identification and password control. 3. The HRMS System will be implemented as a client-server system. The client portion resides on PCs and the server portion must operate on the ARCC server. 4. All performance and loading requirements, as stipulated in the Vision Document and the Supplementary Specification must be taken into consideration as the architecture is being developed.
Group 4 Students Page 9
4.2.1 Quality Attributes for the HRMS
Table 1: prioritized Quality Attribute Requirements for the HRMS

Quality attribute Performance Statement The system must reply to user within two seconds of the click The system responds for each request initiated by users to navigate from one page to the other page with in 1 second interval Security The system shall authenticate employees, employee manager and information archive using user name and password Integrity Some system components must give some service and data to some other components and work together Interoperability The system must operate with other Systems of the organization previously developed that is prisoners management system Maintainability The component shall be maintained without any effect on other working component The system component must be maintained within a day Reusability Testability The system component shall have modules to be used in another components The information archive test system by inputting the required information and capturing the behavior result with 90% accuracy The system impetrator can test the components by inputting the information and capturing the result A system tester performs a system test on a completed; 85% path coverage is achieved within 1 day Usability The system shall have a support in help file attached with the system The system shall be used by users with five working days of training with less than three errors per hour errors per hour
Group 4 Students
Page 10

Modifiability The system components shall be modifiable independently within a day The system can be modifiable to integrate with the other systems Scalability Portability The system must support for increase number of organization to be double The system shall be operate with window XP and above The system may be portable to other operating systems depending on independent drivers
Usability NRF: The system shall be used by users with five working days of training with less than three errors per hour.
Table 2: Usability Scenarios

Scenario Name: specific scenario for usability Scenario(s): The system shall be used by users with five working days of training with less than three errors per hour. Business Goal(s): Relevant Quality Attributes: Scenario Components How easy it is for the user to accomplish a desired task and the kind of user support provided. Usability Stimulus source: Stimulus Environment: Artifact : Response: Response Measure:
Administrator ,arc hiver or HRM managers
A need to work on the system Normal operating environment System The system provide help system for the user. System understanding takes 2 weeks training
Tactic
We use a mixed support initiative which is support system initiative and support User Initiative to achieve a usability quality attribute. Once the user wants to understand or use the system, the system supports it by providing the user with the ability to issue usabilityGroup 4 Students Page 11

based commands. For example, cancel, undo, aggregate, help and show multiple views support the user in either error correction or more efficient operations. So based on this assumption.
Chosen usability tactics from:

Runtime tactics Design time tactics
Our usability driver is primarily concerned on giving the user feedback as to what the system is doing and by providing the user with the ability to issue usability-based commands, so we choose Runtime tactics
Group 4 Students
Page 12

Performance NRF: The system responds for each request initiated by users to navigate from one page to the other page with in 1 second interval.
Table 3: Performance Scenarios

Scenario Name: specific scenario for performance Scenario(s): The system responds for a page request with in 1 second. Business How long the system takes to respond when an event occurs. Goal(s): Relevant Performance Quality Attributes: Scenario Stimulus Source: user Component Stimulus : Request to navigate from one page to another s Environment: Normal operating environment (runtime) Artifact (If Known): System Response: Request are processed, user navigate form one page to another page Response Measure: provide response to request within 1 second
Tactic
Recourse Demand Increase computational efficiency: By using tested, proven data storage, fetching and manipulation algorithms we will achieve this attribute. Relational database management systems, such as MYSQL will be used to achieve the above given objective. Reduce computational over head: - use proven Resource Arbitration-> scheduling policy: Whenever there is contention for a resource, the
resource must be scheduled. Processors are scheduled, and networks are scheduled. The architect's goal is to understand the characteristics of each resource's use and choose the scheduling strategy that is compatible with it.
Group 4 Students
Page 13
Availability A system user performs the test on complete application that provides an interface for controlling Systems behavior and observing its output at deployment time; this task is completed in four hours.
Table 4: Availability Scenarios

Portion of Scenario Source Stimulus Artifact Environment Response Response measure Possible Values
System user Application completed Complete Application At deployment time System records the faults task of viewing output completed within four hours
Tactic
Chosen availability tactics from:

Fault Detection Fault Recovery Fault Prevention.
Since the availability is core after implementation the change effect must be specific and the change must not affect others so prevent ripple effect is good tactics to do this.
Group 4 Students
Page 14

Security
The system shall authenticate employees, employee manager and information archive using user name and password The system provides different access privilege for each user. The employees personal info will only be accessed by an authorized person.
Table 5: Security Scenarios

Scenario Portion source Stimulus Environment: Artifact Response: Response Measure: Possible Values
User who is unknown with full or limited access Attempt to access services Normal operating environment (runtime) System services, data Authenticate user and block access; Time /effort to Authenticate user and detect new users with probability of success
Scenario Portion Stimulus Stimulus Environment: Artifact Response:
Possible Values
User who is new to the system Attempt to log in to the system Normal operating environment (runtime) System services Authenticate user and detect new users
Group 4 Students
Page 15

Response Measure:
Time /effort to Authenticate user and detect new users with probability of success
Scenario Portion Stimulus Stimulus Environment: Artifact Response: Response Measure:
Possible Values
Unauthorized user Attempt to access someone else personal information Normal operating environment (runtime) Employees personal information Authenticate user and block access Effort to Authenticate user and block access with probability of success
Tactic
Chosen security tactics from:

Resisting attacks Detecting attacks Recovering from attacks
Group 4 Students
Page 16

Scalability
The system shall store an additional of 10,000mb of data in addition to the current data. The HRM of ANRS currently has large mega byte of data. The system that we are now Developing can handle and store additional mega byte of data beside the current data.
Table 6: Scalability Scenarios

Scenario Name: specific scenario for scalability Scenario(s): Business Goal(s): Relevant Quality Attributes: Scenario Components Stimulus Source: Stimulus : User Demand to store additional 10,000 Mb data from the current storage capacity Environment: Artifact: Response: Normal operating environment (runtime) System database Adding extra memory to server, adding extra sever without recompiling the software Response Measure: Cost of the added hardware scalability The system will store an additional 10,000mb of data. The extendibility of the system
Group 4 Students
Page 17

Tactic
The goal of modifiability and scalability is similar which is, to control the time and cost to implement, test, and deploy changes. So we use specific tactics of modifiability to achieve the quality attribute scalability. The scenario indicates that there is may be a problematic dependency chain between modules of the system while modifying the system. We can minimize the ripple by applying tactics for preventing ripple effects such as the use an intermediary tactic to decouple responsibilities in the architecture, the Maintain existing interfaces and the restrict communication paths tactic to prevent modules from bypassing the intermediary.
Testability
NFR: A system tester performs a system test on a completed; 85% path coverage is achieved within 1 day.
Table 7: Testability Senario

Scenario Name: specific scenario for Testability A system tester performs a system test on a completed; 85% path coverage is achieved Scenario(s):
within 5 hours
Business Goal(s): Relevant Quality Attributes: Scenario Components
To Discover faults on the completed system. Testability Stimulus source: Stimulus Environment: Artifact : Response: Response Measure:
system user
Request to analyze the system

deployment time
System Observe the testing result 85% path coverage was achieved
Group 4 Students
Page 18

Tactic
Chosen Testability tactics from:

Providing input & capturing output Internal monitoring
Since our testability driver is primarily concerned with changes during system design, so we choose Providing input & capturing output that is Record/playback refers to both capturing information crossing an interface and using it as input into the test harness. The information crossing an interface during normal operation is saved in some repository and represents output from one component and input to another. Recording this information allows test input for one of the components to be generated and test output for later comparison to be saved.
Modifiability The organization does not have any automation system previously it is obvious that other features such as financial system, store system and others will add to the future after implementation so the system must modifiable based on any change .Also the organization is at regional level the data is increasing g at each time .
Table 8: Modifiability Scenarios

Portion of Scenario Source Stimulus Artifact Environment Response Response Measure Possible Values Developer Wishes to add more component System Design time Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification Not more than 2 elements are affected by the change
Group 4 Students
Page 19
Portion of Scenario Source Stimulus Artifact Environment Response
Possible Values
System developer want to change system functionality, user Wishes to modify the architecture System component that operate the function. During system development time. Locates places in architecture to be modified. Makes modification without affecting other functionality. The cost of changing or adding this functionality doesnt affect elements more than 3 components. The time to change or adding this functionality doesnt take more than 2% system development time.
Response Measure
Portion of Scenario
Possible values
Source Stimulus Artifact Environment Response
System administrator Add feature system After implementation Providing architectural design that allows new features to be added without affecting previous features.
Response measure
In less than one week modification finishing the modification
Group 4 Students
Page 20

Tactic
Chosen Modifiability tactic from:

Localize changes Prevent ripple effects Defer binding time
Since the modification is core after implementation the change effect must be specific and the change must not affect others so prevent ripple effect is good tactics to do this.
Group 4 Students
Page 21

4.3

Stakeholders and their Roles
System manager Employee Archive worker Applicant System designer System testers
Archive worker: Archive worker may perform register, search, save employee information that manage every information of employees. Also generate forms and generate report. System manager: The manager will have the higher privilege or special rights. So that he/she may save employee punishment information, delete an employee from active employees list and extend pension date. Employee: These can be military or civil employee that provide its basic information to be managed by the system. And this may include archive worker and system manager. Applicant: The applicants are users who provide their information to apply for work within the organization. System designer: these are people who develop the software, so that it will effectively solve the problems faced in manual system. System tester: The Tester role is responsible for the core activities of the test effort, which involves conducting the necessary tests considering different test cases.
4.4
Architectural Activities in the Life Cycle
Group 4 Students
Page 22
Figure 2: architectural description in operation of the system

4.5 Interface specification
Personnel management Module: This module deals with the management of the employee information such as the personal details name, qualification, skill, experience, login id, password, etc., Importance of modules in any software development side is we can easily understand what the system we are developing and what its main uses are. At the time of project we may create many modules and finally we combine them to form a system person, so that it can be easily added to the database with any duplication of the data.
Security management Module Access is based on the ARCC organizational hierarchy, which defines operator access to employees in the same home department. In addition, operators will have access to departmental employees in subordinate departments as defined by the organizations hierarchy. Access is either allowed or denied based upon the security clearances for the operator. When an employee record is requested, the system will verify that the operators home department matches either the requested employees home department or that a hierarchical relationship exists. If neither of these conditions exists and the requested employees home department has not been specifically included in the operators security, access will be denied.
HR Report Module This module concerned on generating different reports such as pension alert report, monthly report, quarter of a year report, and the like
Training management Module This module deals with the training of the employee based on his experience and attendance monitoring. Also the information of the projects that need to be trained for the employees based on their experience and skills and the like. Organization management Module This module deals with the management of the employee information such as the hiring of the eligible candidate, payments criteria, his personal information maintenance etc.
Leave management Module This module is specified for the purpose of the report generation for the HR on desired requests.
Project Management Module


This module deals with the management of the projects related with the employee likeprojects that were past dealt, current projects in his account etc
4.6
Components interaction
Table 9:Components interaction

From Security management Personnel management Personnel management To Personnel management Leave management Training management Provides security Calculate annual leave Training Requires User name and password experience Year of experience
Organization management Personnel management
Recruitment mant HR Report
Work position Report generation
Vacancy notice criteria Status of the employs
Personnel management
Organization management
Salary increment, award employees Generates payroll
Job grade, position or salary scale Annual leave setting of the employees
HR report generation
Leave management
4.7
Uses of Architectural Descriptions
Architectural descriptions are applicable to a variety of uses for different set of stakeholders, throughout the life cycle. These uses include: Analysis of alternative architectures Business planning for transition from legacy architecture to a new architecture
Group 4 Students
Page 25

Communications among organizations involved in the development, production, fielding, operation, and maintenance of a system Communications between acquirers and developers as a part of contract negotiations Criteria for certifying conformance of implementations to the architecture Development and maintenance documentation, including material for reuse repositories and training materials Input to subsequent system design and development activities Input to system generation and analysis tools Operational and infrastructure support; configuration management and repair; redesign and maintenance of systems, subsystems, and components Planning and budget support Preparation of acquisition documents (e.g., requests for proposal and statements of work) Review, analysis, and evaluation of the system across the life cycle Specification for a group of systems sharing a common set of features, (e.g., product lines)
Group 4 Students
Page 26
5. Architectural Description Practices

This section specifies practices for architectural description that enables the uses or architectural description as described in part four. These Conforming architectural descriptions include the following elements: Architecture description identification and overview information Identification of the system stakeholders and their concerns judged to be relevant to the architecture Specifications of each viewpoint that has been selected to organize the representation of the architecture One or more architectural views A record of all known inconsistencies among the architectural descriptions required constituents
A rationale for selection of the architecture

5.1 Architecture documentation
We use architecture description (AD) to introduce the architecture and provide an overview of the overall scheme of things highlighting architecturally significant elements. And our architecture description is for the whole system.
5.2
Identifications of stakeholders and concerns
This section discusses the stakes and concerns of the various stakeholders. Some of the concerns, namely those that in our view are not self-explanatory, are explained in detail. Different stakeholders think in different terms when they are confronted with the subject 'software architecture'. The reason for this is that every group of stakeholders has certain concerns in the system. These concerns, or a subgroup of them, have something in common: the 'stake' of this stakeholder. We identify the following possible stakes:
Group 4 Students
Page 27
Table 10: stakeholders and their concerns

Stake/interest Stakeholder Concerns Effectiveness Schedule estimation Budgeting(low costs, keeping people employed) Feasibility and risk assessment Progress tracking Usage Users/ HRMS staffs Non functional requirements (performance, reliability, security, availability) Providing future requirements Development Architect Requirement traceability Completeness and consistency of architecture Defining the system in relation to the environment Development Developer Sufficient detail for design Reference for selecting/assembling components Maintain compatibility with the existing prison management system Support/ customization Maintainer Maintaining compatibility with existing prison system Guidance on software modification Guidance on evolution of architecture Maintaining non functional requirements (performance, reliability, availability, security)
Profit
Amhara correctional center organization/ our customers
Group 4 Students
Page 28
5.3
Architectural views
Security management
6.
Personnel management
Module
Module
HR Report Module
ARCC HRMS DB
Requirement management
Module
Leave management
Module
Training management
Module
Module
Figure 3: high level view of system architecture
Module Viewpoint
Concerns This architectural viewpoint is concerned with how the functionality is mapped to the units of implementation. It visualizes the static view of the systems architecture by showing the elements that comprise the system and their relationships. Stakeholder Roles This viewpoint is important to architects and developers working on or with the system. Elements and Relations The elements are units of implementation including: Class: A class describing the properties of the objects that exist at Runtime. Package: A logical division of classes in the system. This can refer to packages as we find them in Java or just give a logical division between the classes of the system. Interface: A classification of the interface of the element that realizes it. It can refer to the interfaces found in e.g. Java or just a Description of an interface that a class can conform to the relations describe constraints on the runtime relationships between elements Association: Shows that there is a hard or weak aggregation relationship between the elements and can be used between classes. Generalization: Shows that there is a generalization relation between the elements and can be used between two classes or two interfaces. Realization: Shows that one element realizes the other and can be used from a class to the interface it implements. Dependency: Shows that there is a dependency between the elements and can be used between all the elements.
Group 4 Students
Page 30
The module view of the HRMS system can be described using the class diagrams of UML, which can contain all the above mentioned elements and relations. The module view of the HRMS system can be described using the class diagrams of UML, which can contain all the above mentioned elements and relations.
Figure 4:Package overview diagram for the HRMS system
Group 4 Students
Page 31
Dependencies among packages are also shown; these dependencies arise because of relationship among classes in different packages. As an example, consider the association between figures 4 there is an association from classes in organization to the Customer class of the position package. This relationship gives rise to a dependency from the organization to position package as shown in figure 3.
Domain Module
Organization Mant
Personal Mant
Organization Mant
Organization Mant
Training Mant
Leave Mant
HR Report Generation
Security Mant
Group 4 Students
Page 32
Figure 5: Decomposition of the Domain module package of ARCC HRM system

Job Authorization Service
Organization
Position Job
Address Name Phone No
Position Organization
Job
Job Authorization Service
Authorized By
*
Position Requirement Establishes position-for
1
Position Benefit Expiry Date number Position: Customer Experience
1
number
Figure 6: Decomposition of the Organization package of ARCC HRM system
Group 4 Students
Page 33
Deployment view
Concerns: This architectural viewpoint is concerned with how the software elements of the system are mapped to platform elements in the environment of the system. We are interested in what the software elements require (e.g., processing power, memory availability, speed of computation) and what the hardware elements provide. Stakeholder Roles: This viewpoint is important to a number of stakeholders: Maintainers needing to deploy and maintain the system, to users/customers who need to know how functionality is mapped to hardware, to developers who need to implement the system, and to architects. Elements and Relations: The deployment is a typical 3-tier deployment in which presentation is run on a client, domain code is run on a J2EE application server, and data is stored on a database server. Environmental elements (shown as UML nodes) The Barcode Scanner is the device used for inputting sold items into the system. It is read via An RS232 connection to the ARCC HRMS Terminals The Terminal is the main point of interaction for the users of the ARCC HRM system The Application Server is a machine dedicated for serving all Terminals on an application level A Database Server provides secondary storage Software elements (Shown as UML components)
Group 4 Students
Page 34

The ARCC HRMS executable component runs the client part of the ARCC HRMS system including presentation and handling of external devices (viz., the Barcode Scanner). JBoss is an application server which is used for running the domain-related functionality of the system. It uses the Database Server via JDBC
ARCCs HRMS deployment view

HRM manager Arc hiver Administrator Back Up
Work station computer
: Terminal : ARCC HRMS
RS 232 RS 232
Configuration
: Application Server : Main server : Barcode scanner
Printer
JDBC
Group 4 Students : Database Server : Mysql2005 Page 35
Architectural document on ARCC HRMS Figure 7: deployment view

Process view
Process view of the architecture describes the tasks (processes and threads) involved in the system's execution, their interactions and configurations. Also describes the allocation of objects and classes to tasks.
To provide a basis for understanding the process organization of the system, an architectural view called the process view is used in the Analysis & Design discipline. There is only one process view of the system, which illustrates the process decomposition of the system, including the mapping of classes and subsystems on to processes and threads. With UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view i.e. class diagrams, we show class diagram of our system below:
Group 4 Students
Page 36
Figure 8: class diagram

Use case view
Login and signup: The system will register an employee that is whether military or civil with his/her dependants. Generate pension date: The system calculates pension date of an employee based on his/her birth date. Delete employee: The system discharges or remove employees information from the currently active employee list. Employee punishment: The system will save the employee punishment information to its history data. Delete employee on leave by willingness: the system will delete an employee when he/she leaves the company by his/her willingness. Save employee information: The system allow the user to save all or some of employees personnel information such as profile information or historical data or medical information or employees current academic status or employee job grade to the system. Extend pension date: The system will extend an employee pension date if an employees work position cannot be covered by another new employee. Search employee information: The system will display the employee personal information based on search criteria so that the user views the employee information that she/he wants. Generate a report: The system generates reports based on what the user wants that shows numbers of employees in each woreda/zone, the
Group 4 Students
Page 38

number of employees who are civilian and military, the number of employees based on their level of position and others. Alert an employee: The system will alert how many days left for an employees contract renewal date or how many days are passed without renewing his/her contract. And produce alert when an employees pension date is arrived. Update employee: The system will allow user to update the employees personal profile (like work Position, salary, pension end date)and historical information like (transfer Case, salary increment, disciplinary case, discharged date) Calculate information: The system will calculate the number of military human resource, an employees annual leave days and the organizations salary increment scale. Award employee: The system will add award information to an employee profile when he/she is awarded based on the organization rule/policy who works for three years and who performs special work. Generate form: The system will generate a form for vacancy announcement and a form to be used by social insurance to get retirement identification number.
Group 4 Students
Page 39
Figure 9: use case view of the system
Group 4 Students
Page 40

Sample - G4

Uploaded by

Copyright:

Available Formats

Sample - G4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample - G4

Uploaded by

Copyright:

Available Formats

BAHIR DAR UNIVERSITY INSTITUTE OF TECHNOLOGY

Architectural document on ARCC HRMS

Intended Users .............................................................................................................................. 5 Overview ....................................................................................................................................... 6

References .................................................................................................................................6 Definitions, Acronyms and Abbreviations .............................................................................7

Architectural document on ARCC HRMS List of figures

Architectural document on ARCC HRMS

Architectural document on ARCC HRMS

Architectural document on ARCC HRMS

Architectural document on ARCC HRMS

3. Definitions, Acronyms and Abbreviations

Architectural document on ARCC HRMS

Architectural document on ARCC HRMS

Figure 1: conceptual model

Architectural document on ARCC HRMS

4.2.1 Quality Attributes for the HRMS

Table 1: prioritized Quality Attribute Requirements for the HRMS

Architectural document on ARCC HRMS

Table 2: Usability Scenarios

Administrator ,arc hiver or HRM managers

Architectural document on ARCC HRMS

Chosen usability tactics from:

Architectural document on ARCC HRMS

Table 3: Performance Scenarios

Architectural document on ARCC HRMS

Table 4: Availability Scenarios

Chosen availability tactics from:

Architectural document on ARCC HRMS

Table 5: Security Scenarios

Scenario Portion Stimulus Stimulus Environment: Artifact Response:

Architectural document on ARCC HRMS

Scenario Portion Stimulus Stimulus Environment: Artifact Response: Response Measure:

Chosen security tactics from:

Architectural document on ARCC HRMS

Table 6: Scalability Scenarios

Architectural document on ARCC HRMS

Table 7: Testability Senario

Business Goal(s): Relevant Quality Attributes: Scenario Components

Request to analyze the system

Architectural document on ARCC HRMS

Chosen Testability tactics from:

Table 8: Modifiability Scenarios

Architectural document on ARCC HRMS

Portion of Scenario Source Stimulus Artifact Environment Response

Source Stimulus Artifact Environment Response

In less than one week modification finishing the modification

Architectural document on ARCC HRMS

Chosen Modifiability tactic from:

Architectural document on ARCC HRMS

Stakeholders and their Roles

Architectural Activities in the Life Cycle

Architectural document on ARCC HRMS

Figure 2: architectural description in operation of the system

Architectural document on ARCC HRMS

Project Management Module

Architectural document on ARCC HRMS

Table 9:Components interaction

Organization management Personnel management

Recruitment mant HR Report

Work position Report generation