Разработка подсистемы документооборота в системе управления проектами сервисной компании
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
Рисунок 4 - Декомпозиция второго уровня
.2.2 Инфологическая модель предметной области
Диаграмма сущность-связь (ER) предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношения между ними. Фактически с помощью ER-диаграмм осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы взаимодействия, включая идентификацию объекта важной для предметной области (сущности), свойства этих объектов (атрибуты) и отношения с другими объектами (связи).
Рисунок 5 - Инфологическая модель предметной области Взаимодействие бизнес-объектов
Рисунок 6 - Инфологическая модель предметной области Взаимодействие бизнес-объектов
Рисунок 7 - Инфологическая модель предметной области Взаимодействие бизнес-объектов
.2.3 Даталогическая модель предметной области
В отличие от инфологической модели, которая осуществляет проектирование на логическом уровне, даталогическая модель позволяет рассматривать модель на физическом уровне. В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД. Под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов. Даталогическая модель представлена в приложении А.
документооборот логистический автоматизация закупка
2.2.4 Диаграмма вариантов использования
Для того чтобы более точно понять, как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Варианты использования предназначены в первую очередь для определения функциональных требований к системе и управляют всем процессом разработки. Все основные виды деятельности, такие как анализ, проектирование, тестирование выполняются на основе вариантов использования. Во время анализа и проектирования варианты использования позволяют понять как результаты, которые хочет получить пользователь, влияют на архитектуру системы и как должны себя вести компоненты системы, для того чтобы реализовать нужную для пользователя функциональность.
В процессе тестирования, описанные ранее варианты использования позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что пользователи ждут от системы?" задавать вопрос "что система должна сделать для конкретного пользователя?". Такой подход позволяет искать функции, которые нужны многим пользователям, и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.
В центре диаграммы установим актера - пользователя, взаимодействующего с шестью вариантами использования - шестью формами разработанной программы. UseCase-ы Выбор формы проектов, Выбор формы договоров, Выбор формы ведения ДС, Просмотр информации о формах, Выбор формы закупочные спецификации и Выбор формы ведения единиц измерения связываются с другими вариантами использования, которые представляют более детальную картину работы всей программы в целом.
Данная диаграмма построена в среде IBM Rational Rose Enterprise Edition v7.0.0, которая предназначена для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющих моделировать, как компоненты программного обеспечения, так и бизнес-процессы. Диаграмма вариантов использования приведена на рис. 8.
Рисунок 8 - Диаграмма вариантов использования
.2.5 Диаграмма классов
Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы.
На диаграмме классов (рис. 9) представлены девять классов. Запуск программы начинается с класса LaunchForm.cs, где отображается логотип фирмы-разработчика. Далее управление передается в класс менеджера форм ManagerForm, откуда можно запустить настройки (класс SettingsForm) и сами формы. В большинстве классов используются такие поля, как connector и description, соответственно служащие для загрузки данных в формы из базы данных и описания выбранной формы. Представленные методы или функции преимущественно используются для добавления, удаления, обновления и загрузки данных.
Рисунок 9 - Диаграмма классов
.2.6 Диаграмма состояний
Рассмотрим диаграмму состояний. Семантика понятия