3.3 Вибір web-сервера
Apache Tomcat (у старих версіях - Catalina) - програма-контейнер сервлетів, написана на мові Java і реалізовує специфікацію сервлетів, специфікацію Java Server Pages (JSP) та Java Server Faces (JSF), які є стандартами для розробки веб-програм на мові Java. Tomcat дозволяє запускати веб-додатки, містить ряд програм для само-конфігурації. Tomcat використовується в якості самостійного веб-сервера, в якості сервера контенту в поєднанні з веб-сервером Apache HTTP Server, а також як контейнер сервлетів в сервері програм JBoss.
3.4 Вибір IDE
Eclipse - в першу чергу повноцінна Java IDE, націлена на групову розробку, має засоби роботи з системами контролю версій (підтримка CVS входить у поставку Eclipse, активно розвиваються кілька варіантів SVN модулів, існує підтримка VSS та інших). З огляду на безкоштовність, у багатьох організаціях Eclipse - корпоративний стандарт для розробки програмного забезпечення.
Друге призначення Eclipse - служити платформою для розробки нових розширень (чим і завоював популярність - будь-який розробник може розширити Eclipse своїми модулями). Такими стали C / C + + Development Tools (CDT), розроблювані інженерами QNX разом із IBM, COBOL, FORTRAN, PHP кошти від різних розробників. Безліч розширень доповнює Eclipse менеджерами для роботи з базами даних, серверами додатків і ін.
Eclipse написана на Java, тому є платформо-незалежним продуктом, за винятком бібліотеки SWT, яка розробляється для всіх поширених платформ. Бібліотека SWT використовується замість стандартної для Java бібліотеки Swing. Вона повністю залежить від нижче перерахованої платформи (операційної системи), що забезпечує швидкість і натуральний зовнішній вигляд для користувача інтерфейсу, але іноді викликає проблеми сумісності та стійкості програм на різних платформах.
4.Опис програмної системи
4.1 Підсистема реєстрації
Підсистема реєстрації потрібна для того, щоб у систему можна було додавати користувачів. На даному етапі розробки системи, користувача можна зареєструвати двома способами:
а) реєстрація користувачем;
б) реєстрація системним адміністратором.
При першому варіанті реєстрації користувач заходить на форму реєстрації за посиланням, вводить свої особисті дані та дані для майбутньої авторизації. Після цього йому присвоюється роль користувача і він може приступати до користування системою.
У другому випадку, системний адміністратор самостійно вводить дані користувача, задає йому роль у системі(на даному етапі присутні лише дві ролі – юзер та адміністратор, причому один користувач може об’єднувати у собі обидві ці ролі). Після додавання всієї інформації про користувача та успішної реєстрації користувач, після авторизації, може приступати до роботи у системі.
Програмний код реєстрації користувача приведено нижче:
String name = (String) req.getParameter("name");
UserManagerImpl um = new UserManagerImpl();
User user = um.load(name);
if (user == null) {
req.getSession().setAttribute("show_pass_error", "");
user = new User();
user.setName(name);
Date d = new Date();
boolean er = false;
List errors_date = new ArrayList();
user.setBirth(d);
user.setEmail(req.getParameter("eMail"));
user.setFirstName(req.getParameter("firstName"));
user.setLastName(req.getParameter("lastName"));
user.setPassword(req.getParameter("password"));
try {
StringTokenizer st = new StringTokenizer(req
.getParameter("birthDay"), "-");
d.setDate(Integer.parseInt(st.nextToken()));
d.setMonth(Integer.parseInt(st.nextToken()) - 1);
d.setYear(Integer.parseInt(st.nextToken()) - 1900);
} catch (Exception e) {
errors_date.add("error in date");
er = true;
}
if (!er) {
UserValidator valid = new UserValidator();
List errors = valid.vilidateFields(user);
if (errors.size() > 0) {
System.out.println("have errors");
req.getSession().setAttribute("errors", errors);
resp.sendRedirect("regestry.jsp");
} else {
RoleManagerImpl rm = new RoleManagerImpl();
Role role = rm.getRole("user");
user.addRole(role);
um.create(user);
role = (Role) req.getSession().getAttribute("role");
if (role != null) {
try {
if (role.getRole().equals("admin")) {
resp.sendRedirect("getallusers.jsp");
} else { resp.sendRedirect("registergood.jsp");
}
} catch (Exception e) { resp.sendRedirect("registergood.jsp");
}
} else {
resp.sendRedirect("registergood.jsp");
}
}
} else {
user.setBirth(null);
req.getSession().setAttribute("erruser", user);
req.getSession().setAttribute("errors", errors_date);
resp.sendRedirect("regestry.jsp");
}
} else {
String error = "Error, same login has exist already";
req.getSession().setAttribute("show_pass_error", error);
resp.sendRedirect("regestry.jsp"); }
Адміністратор та користувач, під час реєстрації повинні ввести вісі дані коректно, тому варіація та зберігання даних про користувача однакове. Приведений вище код буде виконаний при будь-якому з видів реєстрації.
4.2 Підсистема додавання електронного документу
В основу концепцій роботи підсистеми документообігу покладено принцип, який можна описати наступними кроками:
а) користувач завантажує за допомогою форми на сервер деякий документ;
б) документ зберігається на жорсткому диску сервера;
в) документ реєструється у реєстрі документів, що було завантажено;
г) користувачу, що завантажив документ надаються права на редагування документу;
д) користувачу, що завантажив документ надаються права на надання прав доступу до цього документу.
Завдяки тому, що данні про електронний документ зберігаються у БД, а сам документ на жорсткому диску, дана система виграє час на пошуку документів(оскільки БД не засмічується великими за обсягами документами), і водночас виграє час на доступі до файлів, за рахунок майже прямих посилань(детальніше це описано в описі підсистеми ведення статистики редагування документів).
Програмний код завантаження документу має вигляд:
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
DiskFileItemFactory fileItemFactory = new DiskFileItemFactory();
fileItemFactory.setSizeThreshold(1 * 1024); // 1 KB
fileItemFactory.setRepository(tmpDir);
ServletFileUpload uploadHandler = new ServletFileUpload(fileItemFactory);
try {
List items = uploadHandler.parseRequest(request);
Iterator itr = items.iterator();
User user = (User)request.getSession().getAttribute("user");
request.getSession().setAttribute("user", user);
DocumentManagerImpl documentManagerImpl = new DocumentManagerImpl();
while (itr.hasNext()) {
FileItem item = (FileItem) itr.next();
if (!item.isFormField()) {
File file = new File(destinationDir, item.getName());
item.write(file);
Document document = new Document();
document.setName(item.getName());
document.setPath(DESTINATION_DIR_PATH+"//"+item.getName());
Set<User> userSet = new HashSet<User>();
userSet.add(user);
document.setUser(userSet);
documentManagerImpl.create(document);
}
}
response.sendRedirect("index.jsp");
} catch (FileUploadException ex) {
log("Error encountered while parsing the request", ex);
} catch (Exception ex) {
log("Error encountered while uploading file", ex);
}}
Менеджер роботи з документами DocumentManagerImpl під час додавання до системи документу присвоює йому версію номер один, та задає ім’я влсника.
4.3 Підсистема статистки редагування документів
Підсистема статистики редагування документів діє наступним чином: коли користувач хоче відредагувати файл, він заходить на форму відображення документів, що він може корегувати. Після цього він може скачати документ та відредагувати його. Відредагувавши документ, його знову завантажують у систему, за допомогою форми, після чого файл помічається, як остання версія.
Останні 10 версій документу зберігаються на жорсткому диску. В любий момент часу користувач має можливість отримати доступ до них. Завдяки такому методу зберігання даних, користувач завжди може перевірити, як саме редагувався документ.
Принцип зберігання даних було взято з принципу роботи Subversion – централізованої системи зберігання версій даних. Проте, оскільки повністю реалізація даного принципу є дуже складною та об’ємною частиною, повністю вона не реалізована. У майбутньому планується розробка системи Subversion, спеціально для даної системи.
4.4 Підсистема надання прав на редагування документів
Підсистема надання прав на редагування документів діє по наступному принципу:
Той, хто вперше створив документ являється його власником, та має повні права на редагування та видалення. У випадку, коли необхідно, щоб хтось інший міг також редагувати цей документ, власник, переходячи на спеціальну форму, додає цю людину у список власників. Після цього, людина, яка отримала права на редагуваня, має такі самі права, як і власник.
Такий підхід у електронному документообігу дуже важливий, оскільки він виключає доступ до файлів тих людей, які не мають на це повноважень. Тим самим підтримується конфіденційність.
Програмний код сервлету редагування прав користувачів приведено нижче:
public class EditDocumentRool extends HttpServlet {
@SuppressWarnings("unchecked")
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
String name = req.getParameter("name");
DocumentManagerImpl documentManagerImpl = new DocumentManagerImpl();
Document document = documentManagerImpl.load(name);
if(document == null){
document = new Document();
}
if(document.getUser() == null){
document.setUser(new HashSet<User>());
}
UserManagerImpl userManager = new UserManagerImpl();
List<User> users = userManager.getAll();
for(int i = 0; i < users.size()-1; i++){
for(int j = i+1; j < users.size(); j++){
if(users.get(i).getName().equals(users.get(j).getName())){
users.remove(j);
j--;
}}}
for(int i = 0 ; i < users.size(); i++){
Iterator iter = document.getUser().iterator();
while(iter.hasNext()){
if(users.get(i).getName().equals(((User)iter.next()).getName())){
users.remove(i);
i--;
break;
}}}
users.removeAll(document.getUser());
req.getSession().setAttribute("users", users);
req.getSession().setAttribute("document", document);
resp.sendRedirect("editDocumentUsers.jsp");
}
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
String[] users = req.getParameterValues("names");
Document document = (Document) req.getSession()
.getAttribute("document");
boolean result = (new DocumentManagerImpl()).addUsersToDocument(
document, users);
if (result) {
resp.sendRedirect("myDocumentsListVisualisation");
} else {
doGet(req, resp);
}}}
На даному етапі розробки, під час надання прав доступу іншому користувачу, власник документу бачить всіх користувачів системи у вигляді списку. Такий підхід дає можливість надавати права користування файлом напряму людині, а не деякій групі людей. Це робить систему більш гнучкою та безпечною. Наприклад, якщо документ відноситься до відділу розробки, то до нього потрібен доступ певної особи з відділу контролю якості. При такому підході, доступ надається саме цій особі, а не усьому відділу контролю якості. Це зменшує ризик витоку інформації, а також покращує контроль за документами, оскільки до них мають доступ лише конкретні люди, список яких можна отримати в любий момент часу.
В майбутньому планується розширення системи в напрямку юзабіліті інтерфейсу, а саме, створення додаткових груп користувачів. Проте групи користувачів будуть потрібні лише для більш сприйнятливого відображення списків користувачів. Надання прав користування все рівно буде надаватися окремо для кожної людини. Після створення таких груп, окрім покращення юзабіліті, ця система отримає нову, перспективну форму, при якій однією системою зможе користуватися не одне підприємство, а декілька, при цьому, використовуючи апаратні можливості тільки одного сервера. Це зекономить гроші на закупівлю та обслуговування обладнання, а також, на заробітну плату обслуговуючому персоналу.