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

Введение

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

Существует несколько моделей жизненного цикла программного обеспечения: каскадная, итерационная, спиральная, V-образная и т.д. Однако, каждая из перечисленных моделей содержит этап проектирования системы.

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

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

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

Актуальность темы исследования заключается в необходимости обеспечения качества процесса проектирования программного продукта.

Объектом исследования является процесс проектирования информационных систем.

Предметом исследования является применение объектно-ориентированного подхода к процессу проектирования программного обеспечения.

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

Для достижения поставленной цели необходимо решить ряд задач:

---

1. Рассмотреть процесс создания программных продуктов.
2. Изучить сущность процесса проектирования программного обеспечения.
3. Описать этапы проектирования программного обеспечения.
4. Дать определение объектно-ориентированному подходу к проектированию информационных систем.
5. Проанализировать инструменты автоматизации проектирования информационных систем.
6. Рассмотреть достоинства и недостатки объектно-ориентированного подхода.
7. Проектирование информационных систем
8. Процесс разработки информационных систем

Процесс создания программного обеспечения – это достаточно сложный и нелинейный процесс. Не существует одного четкого подхода к разработке программного обеспечения. Однако были разработаны стандарты, которые регламентируют этот процесс. К таким стандартам относят российский стандарт ГОСТ 34.601 «Стадии создания автоматизированных систем» и зарубежный стандарт ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

Однако не все разработчики строго следуют стандартам разработки программного обеспечения. За годы создания автоматизированных систем были созданы модели жизненного цикла программных продуктов, которые включают стадии разработки программных средств. Рассмотрим существующие модели.

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

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

Рисунок 1. Структура каскадной модели жизненного цикла программного обеспечения.

Требования к проектируемой АИС определяются на стадии анализа и затем документируются в техническом задании, которое является опорным документом при создании АИС. Каждая стадия каскадной модели должна завершаться выпуском полного комплекта проектной документации, которая включает в себя:

---

1. Техническое задание;
2. Эскизный проект;
3. Технический проект;
4. Рабочую программу.

Перечисленный пакет документов является достаточным для продолжения процесса разработки другой командой разработчиков. Критерий качества при использовании каскадной модели жизненного цикла программного обеспечения – точное соответствие спецификациям технического задания на разработку АИС. При этом особое внимание разработчики уделяют достижению оптимального значения технических характеристик разрабатываемой АИС: производительности, объема занимаемой памяти и т.д.

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

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

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

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 2.

Рисунок 2. Итерационная модель жизненного цикла программного обеспечения.

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

Спиральная модель жизненного цикла программного продукта является классическим примером применения эволюционной стратегии разработки программных средств. Модель была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 3.

---

Рисунок 3. Схема спиральной модели жизненного цикла разработки ПО.

Рассмотрим этапы спиральной модели:

1. На этапе планирования осуществляется определение целей, вариантов и ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и распознавание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разработки заказчиком.

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

На дальнейших этапах осуществляется определение проблемных и уточненных требований, при этом может использоваться метод моделирования. Заказчик дает оценку инженерной (конструкторской) работы и осуществляет внесение предложений по модификации текущего релиза АИС (квадрант оценки заказчиком). На следующей фазе осуществляется планирование и анализ рисков, который базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

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

1. Сущность процесса проектирования

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

---

Под проектированием программного продукта понимают итерационный процесс, с помощью которого осуществляется трансляция требований к программному средству в инженерные представления о программном продукте.

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

В начале процесса проектирования системы, она рассматривается в виде чёрного ящика. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика.

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

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

В процессе проектирования создаются следующие компоненты информационных систем:

• Архитектура ПО;
• Устройство компонентов ПО;
• Пользовательские интерфейсы.

Как правило, процесс проектирования программных продуктов делится на два этапа:

• предварительное проектирование;
• детальное проектирование.

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

Рисунок 4. Информационные связи процесса проектирования.

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

• идентификацию подсистем;
• определение основных принципов управления подсистемами;
• взаимодействие подсистем.

К процессу предварительного проектирования относятся следующие типы деятельности:

1. Структурирование системы, в процессе которого система разделяется на ряд подсистем. Подсистемой называют независимый программный компонент. Затем определяют способы взаимодействия подсистем.
2. Моделирование управления, в процессе которого определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули, в процессе которой выделенные подсистемы делятся на модули. Затем происходит определение типов модулей и межмодульных соединений.

---