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

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

2.1. Достоинства и недостатки объектно-ориентированного подхода. Методологии его реализации

Оценим объектно–ориентированный подход в соотношении с не менее известным структурным подходом.

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

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

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно–ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно–ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований [1].

Исследователи отмечают также ряд следующих преимуществ объектно–ориентированного подхода:

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

---

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно–ориентированных языков программирования [2].

К недостаткам объектно–ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно–ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка объектно–ориентированного моделирования UML, и количество CASE–средств, поддерживающих объектно–ориентированный подход, невелико по сравнению с поддерживающими структурный подход. Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения CASE–технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком «для передачи понимания», обеспечивается на сегодняшний день только структурными методами [2].

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

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

---

Кратко преимущества объектно–ориентированного подхода можно охарактеризовать следующим образом:

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

1. адаптации системы к изменению существующих или появлению новых требований;
2. сопровождения системы на разных стадиях жизненного цикла;
3. повторного использования компонентов;
4. объектно–ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться его автономной работы;

• Case–средства, поддерживающие объектно–ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case–средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая кодогенерация (например, экранов или функций обработки данных) возможна лишь в редких случаях [7].

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

Методология OMT (Object Modeling Technique) поддерживает две первые стадии жизненного цикла программных систем. Это не единственная объектно–ориентированная методология разработки программных систем. Она является одной из наиболее продвинутых и популярных объектно–ориентированных методологий. Более того, графический язык (система обозначений для диаграмм) методологии OMT получил достаточно широкое распространение и используется в некоторых других объектно–ориентированных методологиях, а также в большинстве публикаций по объектно–ориентированным методологиям [12].

---

В этом разделе рассмотрим объектно–ориентированные методологии разработки программных систем. Они будут сравниваться с методологией OMT. В последнее время интерес к объектно–ориентированным методологиям разработки программных систем продолжает возрастать: много публикаций в журналах, докладов на конференциях и т.д. Программное обеспечение объектно–ориентированных методологий стало настолько популярным, что все интересные инструментальные и CASE–системы давно исчезли из public domain и распространяются только как коммерческие системы. Наиболее известной такой системой является система Paradigm+, которая поддерживает восемь объектно–ориентированных методологий, и в том числе, методологию OMT [12].

В этом разделе работы будут рассмотрены следующие объектно–ориентированные методологии анализа и разработки программных систем:

• OMT (Object Modeling Technique);
• SA/SD (Structured Analysis/Structured Design);
• JSD (Jackson Structured Development);
• OSA (Object–Oriented System Analysis).

Методология OMT опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+ [12].

Методология SA/SD содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов [9].

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

---

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

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы. Таким образом, мы видим, что у методологий SA/SD и OMT много общего: обе методологии используют похожие конструкции для моделирования и поддерживают три взаимно–ортогональных представления проектируемой системы. Методологии SA/SD и OMT можно рассматривать как два способа использования инструментального средства – OMTTool.

Методология JSD предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80–х годов, особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. На этом этапе решается вопрос «что должно быть сделано»; вопрос «как это должно быть сделано» решается на следующем этапе – этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени [5].

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT. Разработка модели JSD начинается с изучения объектов реального мира. Целью системы является обеспечение требуемой функциональности, но Джексон понимает, что сначала следует убедиться, что эта функциональность согласуется с реальным миром. Модель JSD описывает реальный мир в терминах сущностей (объектов), действий и порядка выполнения действий. Разработка системы по методологии JSD включает следующие шесть фаз:

• разработка действий и объектов;
• разработка структуры объектов;
• разработка исходной модели;
• разработка функций;
• разработка временных ограничений;
• реализация системы [5].

Методология JSD может быть названа объектно–ориентированной с большой натяжкой: в ней почти не рассматривается структура объектов, мало внимания уделяется их атрибутам. Некоторые действия в смысле методологии JSD являются, по существу, зависимостями между объектами в смысле методологии OMT [5].

---