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

В завершении этапа рабочего проектирования разрабатываемого программного продукта осуществляется разработка комплекта документов, в которых отражены взаимоувязанные согласованные проектные решения по системе в целом и по всем видам обеспечения достаточные для создания и функционирования ИС.

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

Процесс рабочего проектирования включает следующие этапы:

1. Разработку рабочей документации на систему и ее части.
2. Разработку или адаптацию программ.
3. Разработку программ и программных средств системы.
4. Выбор, адаптацию и привязку приобретаемых программных средств.
5. Разработку программной документации.

В результате разработки рабочего проекта системы получается комплект документов, в состав которого входят:

• ведомость держателей подлинников;
• ведомость эксплуатационных документов;
• спецификация оборудования;
• ведомость машинных носителей информации;
• технологическая инструкция;
• руководство пользователя;
• инструкция по формированию и ведению базы данных (набора данных);
• инструкция по эксплуатации комплекса технических средств (КТС);
• чертеж установки технических средств;
• описание технологического процесса обработки данных (включая телеобработку);
• общее описание системы;
• программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем);
• формуляр;
• паспорт.

3. Применение объектно-ориентированного подхода к проектированию программных продуктов

3.1 Сущность объектно-ориентированного подхода

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

---

В объектно-ориентированном подходе к проектированию предметная область представляется в виде объектов, для которых дается описание связей. Для моделирования системы в объектно-ориентированном подходе используются язык UML.

UML (Unified Modeling Language) — это язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

Объектно-ориентированный поход к проектированию информационных систем включает следующие модели:

• Диаграмма классов;
• Диаграмма компонентов;
• Диаграмма композитной/составной структуры;
• Диаграмма развёртывания;
• Диаграмма объектов;
• Диаграмма пакетов;
• Диаграмма деятельности;
• Диаграмма автомата;
• Диаграмма сценариев использования;
• Диаграмма последовательности.

Дадим описание каждой модели. Диаграмма классов является статической структурной диаграммой, которая описывает структуру системы, позволяет демонстрировать классы системы, их атрибуты, методы и зависимости между классами. Создание диаграммы классов может осуществляться с разных точек зрения, которые завися от целей их применения. С концептуальной точки зрения диаграмма классов позволяет описать модель предметной области в виде классов прикладных объектов. С точки зрения спецификации диаграмму классов применяют в процессе проектирования информационных систем. С точки зрения реализации диаграмма классов включает классы, которые используются непосредственно в программном коде. Пример диаграммы классов представлен на рисунке 13.

Рисунок 13. Пример диаграммы классов.

Диаграмма компонентов является статической структурной диаграммой, которая представляет разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. Компонентами на такой диаграмме могут быть файлы, библиотеки, модули, исполняемые файлы, пакеты и т.п. Пример диаграммы компонентов представлен на рисунке 14.

---

Рисунок 14. Пример диаграммы компонентов.

Диаграмма композитной — это статическая структурная диаграмма, демонстрирующая внутреннюю структуру классов и их взаимодействие. Одним из видов таких диаграмм являются диаграммы кооперации, представляющие роли и взаимодействие классов в рамках кооперации. Пример диаграммы кооперации представлен на рисунке 15.

Рисунок 15. Пример диаграммы кооперации.

Диаграмма развёртывания применяется в процессе моделирования работающих узлов и артефактов. Пример диаграммы развертывания представлен на рисунке 16.

Рисунок 16. Пример диаграммы развертывания.

Диаграмма объектов представляет собой полный или частичный снимок моделируемой системы в конкретный момент времени. На этой диаграмме отображены экземпляры классов и указаны текущие значения их атрибутов и связей между объектами. Пример диаграммы объектов представлен на рисунке 17.

Рисунок 17. Пример диаграммы объектов.

Диаграмма пакетов дает представление о пакетах и отношениях между ними. Диаграммы пакетов применяются для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы. Пример диаграммы пакетов представлен на рисунке 18.

Рисунок 18. Пример диаграммы пакетов.

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

Рисунок 19. Пример диаграммы деятельности.

Диаграммы состояний представляют собой описание объекта с простыми состояниями, переходами и композитными состояниями. Пример диаграммы состояний представлен на рисунке 20.

Рисунок 20. Пример диаграммы состояний.

Диаграмма вариантов использования показывает отношения, существующие между актёрами и вариантами использования. Основной задачей диаграммы вариантов использования является предоставление возможности заказчику, конечному пользователю и разработчику согласовывать функциональность и поведение системы. Пример диаграммы вариантов использования представлен на рисунке 21.

---

Рисунок 21. Пример диаграммы вариантов использования.

Диаграмма последовательности представляет собой диаграмму, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Пример диаграммы последовательности действий представлен на рисунке 22.

Рисунок 22. Диаграмма последовательности.

3.2 Программные продукты, применяемые при объектно-ориентированном подходе

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

1. Проектирование системы. Инструмент должен давать достаточный функционал для возможности документирования требований к системе. Также в нем должен присутствовать функционал для создания зависимости между объектами разных типов, возможность отслеживать изменения.
2. Экспорт. Программный продукт должен обладать функцией экспорта артефактов, которые в нём были созданы. Для экспорта должны быть доступны разные форматы.
3. Удобный интерфейс. Программное средство должно быть удобным, интуитивно понятным, с простым интерфейсом для часто используемых функций.
4. Автоматизация рутинных операций. Используемый инструмент должен позволять осуществлять генерацию программного кода, тест-кейсов, объектного дизайна и т.д.

Рассмотрим и проанализируем следующие программные продукты согласно выделенным критериям:

1. Case Complete – это инструмент, предназначенный для записи требований, создания сценариев использования объектов и связей между ними. Инструмент обладает удобным интерфейсом, функцией экспорта. Но он содержит один серьёзный минус: в нем присутствует тограниченный набор диаграмм. Инструмент отвечает 2 выделенным критериям из 4.
2. Artiso Visual Case – инструмент обладает неудобным интерфейсом, однако поддерживает все виды диаграмм и обладает функциями экспорта. Инструмент отвечает 3 критериям из 4.
3. Инструмент Magic Draw обладает широким функционалом для UML, однако, в нем отсутствуют связи между разными объектами. Инструмент отвечает 3 критериям из 4.
4. Sparx Enterprise Architect отвечает практически всем выдвинутым критериям, однако его слабым местом является интерфейс. Ряд наиболее часто используемых функций отсутствуют на панели инструментов. Инструмент отвечает 3 критериям из 4.
5. Sybase PowerDesigner обладает простым и понятным интерфейсом, а также множеством полезных функций, которые не попали в список критериев (например, оценка изменения, проверка модели и т.д.). Инструмент отвечает 4 критериям из 4.
6. Анализ объектно-ориентированного подхода

---

Объектно-ориентированный подход и, в частности, язык UML являются достаточно распространёнными и используемыми. Однако, они обладают следующими недостатками:

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

Несмотря на перечисленные недостатки, объектно-ориентированный подход обладает достоинствами, с которыми связано его широкое использование. Рассмотрим эти преимущества:

• Поскольку язык UML является объектно-ориентированным, используемые в нем методы описания результатов анализа и проектирования являются семантически близкими к методами программирования на современных объектно-ориентированных языках;
• Язык UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
• UML получил широкое распространение и динамично развивается.

---