Файл: Основные технологии проектирования информационных систем.pdf

В общем случае рассматриваются 3 классических модели ЖЦ ПО – каскадная (водопадная), итерационная и спиральная, все прочие являются ни чем иным как результатами изменения этих моделей под некоторые практические нужды.

1) Водопадная модель жизненного цикла

Водопадная модель жизненного цикла (англ. waterfall model) была предложена Уинстоном Ройсом в 70 гг. 20 века. В рамках данной модели, предполагается выполнение всех этапов проекта строго заданном порядке, причем этот порядок не допускает изменений. Переход к следующему этапу может быть осуществлен только после завершения работ в рамках текущего этапа. Схематически данная модель представлена на рисунке 1.1.

Рисунок 1.1 – Водопадная модель ЖЦ ПО

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

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

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

Недостатки:

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

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

2) Итерационная модель

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

Рисунок 1.2 – Итерационная модель ЖЦ

Основной недостаток итерационной модели заключается в том, что целостное пониманием возможностей и ограничений разрабатываемого проекта отсутствует долгое время, т.к. любые проблемы приводят к откату, даже если проблемы связаны с ограничениями, заданными в рамках определения требований. Еще один недостаток, которая присуща проектам, реализуемым по данной модели – добросовестность разработчиков, которая является следствием того, что разработчик не может быть уверен в качестве принятых решений, потому что всегда есть возможность «откатиться и сделать лучше» [10].

3) Спиральная модель

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

Рисунок 1.3 – Спиральная модель ЖЦ ПО

Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. Каждая выполняемая итерация позволяет оценить [10]:

• риски превышения сроков и стоимости проекта;
• наличие необходимости выполнения еще одной итерации;
• степень полноты и точности понимания требований к системе;
• целесообразность прекращения проекта.

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

К числу преимуществ спиральной модели можно отнести:

• быстрое получение результата;
• повышение конкурентоспособности;
• изменение требований не вызывает серьезных проблем.

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

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

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

Объектно-ориентированный подход проектирования информационных систем предполагает декомпозицию этой ИС. При этом декомпозиции подвергаются объекты, обладающие определенной структурой данных, именно от этих данных и идет декомпозиция. При объектно-ориентированном подходе выделяют классы объектов, каждый из которых содержит в себе только однородные объекты. Объекты, относящиеся к одному классу, имеют равное множество методов реагирования на внешние сообщения. Таким образом, иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы в виде их взаимодействия, путем обмена сообщениями [7]. Пример алгоритма объектной декомпозиции представлен в приложении 1, а в приложении 2 представлена его развернутая блок-схема.

Объекты ИС, проектируемой путем применения объектно-ориентированного подхода, обладают следующим набором свойств:

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

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

Другое достоинство объектно-ориентированного подхода заключается в возможности упростить накопление типовых проектных решений с тем, с возможностью их использования при разработке новых ИС, которые будут создаваться не с нуля, а из готовых компонент. Объясняется эта особенность тем, что отдельные классы объектов в некоторой мере повторяются при переходе от одной ИС к другой, по этой причине нет смысла создавать новый программный код – для повторяющихся классов уже созданы методы, разработаны и описаны структуры объектов данных [15].

Для лучшего понимания модели объектно-ориентированного подхода к проектированию ИС, представим ее графически на рисунке 2.1.

Рисунок 2.1 – Модель проектирования ИС на основе объектно-ориентированного подхода

Итак, на представленном рисунке мы видим 4 основных этапа проектирования ИС, реализуемых в рамках модели объектно-ориентированного подхода:

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

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

Таким образом, мы может выделить основные преимущества объектно-ориентированного подхода к проектированию ИС, к ним относятся:

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

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

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

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

Рисунок 2.2 – Зависимость эффективности применения функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов

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

2.2 Программные средства реализации объектно-ориентированного подхода

При проектировании информационных систем не маловажное значение имеет среда разработки конечной модели, от ее выбора во многом зависит качество проекта разрабатываемой системы. По этой причине необходим обоснованный выбор инструментальных средств проектирования, которые позволяют реализовать объектно-ориентированный подход. В качестве таких средств выступают CASE-технологии (Computer-Aided Software/System Engineering). Они представляют собой набор инструментов и методов программной инженерии для проектирования программных продуктов. Использование CASE-средств позволяет значительно снизить количество ошибок, увеличить качество программ и обеспечить простоту в их обслуживании. Такой подход зачастую называют CASE-технологией проектирования [8].