Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Преимущества и недостатки объектно-ориентированного подхода).pdf

Рисунок 5. Диаграмма компонентов для проектируемой системы

Таким образом, на этой диаграмме можно наблюдать зависимость между различными программными компонентами, что облегчает понимание архитектуры сложной системы при проектировании.

Диаграммы классов создаются при логическом моделировании ПС и служат для следующих целей:

• Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
• Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС.
• Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
• Для моделирования логики программных компонент.
• Для моделирования логики обработки данных.

ARIS UML Designer является инструментом, который позволяет бизнес- и IТ-специалистам использовать общий язык моделирования Unified Modeling Language (UML), чтобы скоординировать процесс моделирования бизнес-процессов на всех его этапах.

Многие программные проекты выходят за рамки бюджета или терпят неудачу из-за отсутствия согласованности между отделами менеджмента и IT. ARIS UML Designer является инструментом, который позволяет бизнес- и IТ-специалистам использовать общий язык моделирования Unified Modeling Language (UML), чтобы скоординировать процесс моделирования бизнес-процессов на всех его этапах. 

Преимущества ARIS UML Designer: 

• Интеграция бизнес-процессов и UML в проектах по разработке программного обеспечения
• Разработка эффективного программного обеспечения — быстрее и в рамках бюджета
• Последовательный, всеобъемлющий, бизнес-ориентированный процесс разработки ПО
• Работа над проектами, которые охватывают группы сотрудников, работающих удаленно
• Поддержка всех UML-диаграмм

Основные возможности ARIS UML Designer:

• Один язык для бизнес- и IT-специалистов. UML является всеобъемлющим стандартом моделирования для описания прикладных систем. Он используется для статического и динамического моделирования процессов, таких как архитектура и внутренние потоки организации. UML поддерживает диаграммы и графические символы, а также формат обмена XMI. С помощью XMI информация о модели может быть передана между различными инструментами моделирования и средами разработки. ARIS UML Designer использует язык UML, чтобы объединить работу менеджеров и разработчиков программного обеспечения.
• Обеспечение высокого качества моделирования. ARIS UML Designer обеспечивает высокое качество моделирования в двух направлениях. Во-первых, решение позволяет создавать UML-диаграммы, используя удобные диалоговые окна. Это гарантирует высокую степень согласованности даже на начальных стадиях создания модели. Кроме того, пользователи могут автоматически создавать новые модели из существующих с помощью семантических преобразований. Во-вторых, встроенная функция online проверки соответствия определяет синтаксические и структурные ошибки моделирования
• Централизованный репозиторий ARIS. Так как ARIS UML Designer использует тот же репозиторий, что и остальные платформы ARIS, сотрудники, специализирующиеся на UML-моделировании, могут получить доступ к необходимым данным напрямую
• Масштабируемый web-инструмент. ARIS UML Designer идеально подходит для программных проектов, охватывающих сотрудников из разных стран. Все процессы моделирования и UML-контент доступны через web-браузер. Решение также предлагает поддержку множества языков, возможности разработки отчетов и web-публикаций для упрощения создания и распространения документов

Для проектирования UML диаграмм приложения использовалось CASE-средство (от Computer Aided Software/System Engineering) Jude Community. Case–средства позволяют моделировать бизнес процессы, компоненты программного обеспечения, структуру и деятельность организаций. Использование CASE-средств оптимизирует эффективность проектирования, снижает вероятность расходы и вероятности ошибок.

Jude Community – мощное средство для проектирования программных комплексов любой сложности. С его помощью можно провести весь цикл разработки программы – от идеи до генерации кода. Серьезным преимуществом данной программы является ее свободное распространение.

Преимущества от использования:

• унифицированное средство общения между разработчиками;
• ускорение разработки;
• увеличение продуктивности.

Поскольку проектируемый АРМ будет состоять из программного приложения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производится специализированным case-средством с возможностью генерации исходного кода – ER Win.

Результаты применения объектно-ориентированного подхода

Диаграмма вариантов использования (Use case diagram) позволяет сделать анализ бизнес-процессов, отображая приложение в статическом состоянии. В диаграмме описываются только функции, выполняемые актерами. Актером является пользователь, выполняющий определенную роль в системе.

Рисунок 6. Диаграмма вариантов использования

Диаграмма взаимодействия - это диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются. Этот термин применяется к видам диаграмм с акцентом на взаимодействии объектов (диаграммах кооперации, последовательности и деятельности).

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams).

По результатам проведенного анализа бизнес-процессов можно составить диаграмму последовательности, основанную на обмене информацией между объектами. На рисунке 7 показан данный вид диаграммы для наиболее значимого прецедента.

Рисунок 7. Диаграмма последовательности: составление заявки на ЗИП

Диаграммы сотрудничества в большей степени заостряют внимание на связях между объектами, чем диаграммы последовательности событий. В принципе, на данной диаграмме представлена такая же информация, как и на диаграмме последовательности, но по-другому. Из нее легче понять связи между объектами, но труднее - последовательность событий. На рисунке 8 показан данный вид диаграммы.

Рисунок 8. Диаграмма сотрудничества

Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции, причем предоставляют для этого больше возможностей, чем "классическая" блок-схема. Диаграммы деятельности описывают переход от одной деятельности к другой, в отличие от диаграмм взаимодействия, где акцент делается на переходах потока управления от объекта к объекту. На рисунке 9 показан данный вид диаграммы.

Рисунок 9. Диаграмма активности

Проектирование базы данных

Проектирование базы данных реализовано при помощи CASE-средства ErWin версии 7.3. С его помощью сначала строится логическая модель базы данных, соответствующая структуре бизнес-процесса, который построен другим CASE-средством JUDE COMMUNITY. Логическая модель показана на рис.10.

Рисунок 10. Логическая модель

Логическая модель представляет реляционную базу данных в 3-й нормальной форме, так как она соответствует требованиям 2-й нормальной формы (все ключи простые) и все неключевые атрибуты каждой сущности зависят только от ключа этой сущности.

В сущности «Группа» от ключа «идентификационный_номер_группы» зависят атрибуты: «название», «доплнительная_информация», «идентификатор_для_авторизации», «пароль_для_авторазации», «роль_в_системе». В сущности «Резерв» от ключа «id_резерва» зависят атрибуты: «какая_группа_эксплуатирует», «количество_системных_блоков», «количество_мониторов», «количество_матричных_принтеров», «количество_лазерных_принтеров», «количество_клавиатур», «количество_мышей», «количество_хабов», «количество_сетевых_карт», «количество_патчкордов», «количество_ИБП». В сущности «Заказ» от ключа «идентификационный_номер_заказа» зависят атрибуты: «какой_ЗИП_входит», «какая_группа_заказывает», «количество», «дата_поступления_заявки», «дата_закрытия_заявки», «дополнителная_информация». В сущности «ЗИП» от ключа «идентификационный_номер_ЗИП» зависят атрибуты: «наименование», «код», «наименование_единиц_исчисления», «количество». В сущности «Техника» от ключа «id_техники» зависят атрибуты: «какая_группа_эксплуатирует», «тип_устройства», «модель», «серийный_номер», «инвентарный_номер»,» балансовая_принадлежность». В сущности «Ремонт» от ключа «id_ремонта» зависят атрибуты: «какая_техника_отправлена»,«группа_эксплуатирующая_отправленную_технику», «неисправность», «дата_отправки_с_площадки», «дата_поступления_на_площадку», «дата_отправки_в_ремонт», «дата_получения_из_ремонта», «результат_ремонта», «эксплуатация».

Отношения между сущностями «Группа» и «Резерв», «Группа» и «Заказ», «Группа» и «Техника», «Техника» и «Ремонт», «ЗИП» и «Заказ» представляют собой связи один ко многим.

Физическая модель базы создается по логической модели при помощи того же ErWin. Так как физическая модель зависит от используемой СУБД, то СУБД указывается перед построением.

Физическая модель базы данных, для разрабатываемого АРМа, спроектированная под MS SQL Server 10.5 (2008), показана на рис.11.

Рисунок 11. Физическая модель

Физическая модель представляет реляционную базу данных в 4-й нормальной форме, так как она соответствует требованиям 3-й нормальной формы и в ней отсутствуют многозначные связи, или связи многие ко многим.

По физической модели автоматически построена схема данных для MS SQL Server. Схема показана на рис.12.

Рисунок 12. Схема данных

Проверка показала, что заданная схема отношений удовлетворяет свойству соединения без потерь, исключает избыточное дублирование, исключает потенциальную противоречивость данных и обладает свойством сохранения функциональных зависимостей.

Заключение

В работе рассмотрены основные понятия, касающиеся применения объектно-ориентированного подхода к проектированию информационных систем. В ходе работы была предложена методика проектирования и описания бизнес-процесса предприятия и выполнено проектирование автоматизированного рабочего места инженера по снабжению

Разработанный АРМ позволяет существенно упростить документооборот отдела, оперативно отслеживать наличие: резерва на площадках, потребность в расходных материалах; создавать заявки на ремонт техники, отслеживать его ход и просматривать историю.

Список использованной литературы

• • 1. Варфоломеева Е.В. Информационные системы в экономике: Учебное пособие / Е.В. Варфоломеева, Т.В. Воропаева и др.; Под ред. Д.В. Чистова - М.: НИЦ ИНФРА-М, 2015. - 234 с.
    2. Вдовенко Л.А. Информационная система предприятия: Учебное пособие/Вдовенко Л. А. - 2 изд., перераб. и доп. - М.: Вузовский учебник, НИЦ ИНФРА-М, 2015. - 304 с.
    3. Гвоздева В.А. Базовые и прикладные информационные технологии: Учебник / Гвоздева В. А. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2015. - 384 с.