Предусловие: документ загружен на сервер.
7. Вариантиспользования:получение списка документов.
Актеры: пользователь, администратор.
Краткое описание: система отображает списковдокументов, на которые имеет разрешения пользователь.
Полное описание: функция отображает все документы, накоторые имеет разрешения пользователь, в том числе и документы, ожидающиерецензии. Также все пользователи могут увидеть состояние процессов, привязанныхк документам.
Предусловие: пользователь должен бытьавторизован.
8. Вариантиспользования:прекращение процесса.
Актеры: администратор.
Краткое описание: администратор останавливает процессутверждения, связанный с документом.
Полное описание: администратор может остановитьпроцесс утверждения документа на любой стадии, удалив процесс из системы.
Предусловие: процесс, связанный с документом,находится в состоянии выполнения.
9. Вариантиспользования:получение списка процессов.
Актеры: администратор.
Краткое описание: администратор получает список всехпроцессов.
Полное описание: администратор может просматриватьсписок всех процессов утверждения, запущенных когда-либо в системе, а такжевидеть их статусы и прочую информацию о процессах.
10. Вариантиспользования:добавление пользователей.
Актеры: администратор.
Краткое описание: администратор добавляетпользователей в систему.
Полное описание: администратор системы имеетвозможность добавлять в систему пользователей. При этом учетные записипользователей должны быть существовать в списке пользователей службы ActiveDirectory.
Предусловие: пользователи с указанными именамисуществуют в Active Directory.
Постусловие: пользователи добавлены в систему.
11. Вариантиспользования:удаление пользователей.
Актеры: администратор.
Краткое описание: администратор удаляет пользователейиз системы.
Полное описание: администратор системы имеетвозможность удалять из системы пользователей. При этом учетные записипользователей из списка пользователей службы Active Directory не удаляются.
Постусловие: пользователи удалены из системы.
12. Вариантиспользования:назначение разрешений.
Актеры: администратор.
Краткое описание: администратор назначает правапользователям.
Полное описание: администратор системы можетопределить полномочия пользователя, варьирующиеся от ограниченного чтения доправ администратора системы. Права назначаются каждому пользователю системы,при этом права пользователя в системе не влияют на права пользователя в домене.
В приложении 4 и 5 приведеныдиаграммы деятельности, отражающие процессы согласования учебных планов(приложении 4) и графиков учебных процессов (приложение 5). Как видно изприведенных диаграмм, процесс утверждения подразумевает последовательный сборрецензий у пользователей. В случае отклонения документа кем-либо изпользователей процесс утверждения завершается.
1.11 Модель классовпредметной области
Модель классовпредметной области описывает статическую структуру системы: объекты и отношениямежду ними, атрибуты и операции для каждого класса объектов. Модель классов(приложение 6), представленная в виде концептуальной диаграммы классов,описывает основные сущности предметной области.
Рассмотримподробнее сущности:
1. «Пользователь» –лицо, которое имеет доступ к системе:
· «Логин» - логинпользователя;
· «Пароль» - парольпользователя на доступ к системе;
· «Роль в системе»- группа безопасности, к которой пользователь относится в системе;
2. «Процесссогласования» - процесс утверждения документа, который инициируетсяпользователем:
· «Дата начала» -дата создания процесса;
· «Дата изменения»- дата последний изменений, внесенных в процесс;
3. «Статус процесса»- статус процесса;
4. «Рецензия икомментарий» - рецензия и комментарий, оставляемые пользователем документу;
5. «Документ» -файл, требующий согласования:
· «Название» -название документа, данное ему при загрузке в репозитарий;
· «Дата создания» -дата загрузки документа в репозитарий;
· «Номер текущейверсии» - номер версия документа, которая отображается в качестве него самого;
6. «Версиядокумента» - предыдущие версии документа, хранящиеся в репозитарии;
· «Примечание» -примечание, вводимое пользователем при создании новой версии документа;
· «Дата создания» -дата создания версии;
· «Дата изменения»- дата внесения последних изменений в текущую версию документа;
· «Номер версии» -номер версии документа, присваиваемый версии при сохранении в репозитарий.
В представленноймодели хорошие видны количественные отношения, например, объект «Процесссогласования» может содержать только одну запись об объекте «Статус процесса»,но сколь угодно записей об объекте «Документ».
1.12 Требования ктехническому и программному обеспечению
1.12.1 Требования ктехническому обеспечению
В качестве основного сервера и сервера БДдолжны использоваться компьютеры с характеристиками не ниже следующих:
· процессор Intel или AMD – 2000 МГц;
· объём оперативнойпамяти – 1024 Мб;
· объём свободногоместа на HDD - 1 Гб;
· доступ клокальной сети.
В качествеавтоматизированного рабочего места персонала, должно использоваться техническоеобеспечение с характеристиками не ниже следующих:
· процессор Intel или AMD с тактовой частотой 500 МГц;
· объём оперативнойпамяти – 128 Мб;
· объём свободногоместа на HDD – 10 Мб;
· доступ к локальнойсети.
Для обеспечениябесперебойной, производительной и надежной работы системы, требования кминимальному уровню технических средств должны удовлетворять вышеприведеннымусловиям.
1.12.2 Требования кпрограммному обеспечению
Требования к программному обеспечениюна сервере следующие:
· операционнаясистема MS Windows 2003 Server;
· СУБД MS SQL Server 2005;
· InternetInformation Services 6.0 или выше;
· MOSS2007;
· поддержка ASP .Net.
Требования кпрограммному обеспечению на клиенте:
· операционнаясистема: семейство MS Windows 98/2000/XP/Vista.
· браузер,поддерживаемый операционной системой (Internet Explorer 6.x и выше, Firefox 2.xи выше, Opera 7 и выше, Safari 1.x и выше, Camino 1.x и выше).
Корректная работысистемы может быть обеспечена только при соблюдении всех требований кпрограммному обеспечению.
1.13 Требования кинтерфейсам информационной системы
Разрабатываемый интерфейс должен отвечатьобщепринятым нормам и правилам проектирования пользовательских интерфейсов:
· выдержанная в спокойныхтонах цветовая гамма;
· простой иочевидный порядок выполнение действий;
· удобнаянавигация;
· эргономичноерасположение полей ввода и элементов управления.
Интерфейсы системы должны обеспечивать выполнениеследующих операций:
· рецензирование икомментирование – должен осуществляться ввод пользователем рецензии икомментария к документу;
· отображениесписка процессов – должно осуществляться отображение списка процессов,запущенных в системе;
· отображениесписка пользователей – должно осуществляться отображение списка пользователей,зарегистрированных в системе;
· редактированиепроцессов – редактирование должно обеспечить удаление и остановку процессов;
· редактированиеразрешений пользователей – редактирование должно обеспечить назначение пользователямправ;
· загрузкадокумента – окно загрузки документа и оставления комментария к версиидокумента;
· поиск в системе –должно позволять задание критерия поиска и области произведения поиска.
Логика выполнения перечисленных операций должна бытьинтуитивно понятна и проста для пользователей системы.
Рассмотрим модельнадежности архитектуры системы. Система состоит из следующих компонентов:клиентских машин, Web-сервера и сервера БД. В качестве еще одного компонентабудем рассматривать локальную сеть.
Для прогнозанадежности программного комплекса может быть использована Марковская модель.Надежность всего программного комплекса определяется как функция надежности еесоставных частей. Подобная оценка значительно облегчается, если программастроится по модульному принципу.