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

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

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

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

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

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

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

---

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

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

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

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

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

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

---

2.2. Методологии, применяемые в процессе реализации объектно–ориентированного подхода

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

Методология 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].

Методология OSA обеспечивает объектно–ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

Методологии объектно–ориентированного анализа нередко критикуются за то, что они являются больше реализационно–ориентированными, чем проблемно–ориентированными, обеспечивая больше предварительную разработку, чем анализ требований к системе. Действительно, все рассмотренные методологии (такие, как OMT, SA/SD, JSD) поддерживают прежде всего предварительную разработку программных систем, а не анализ требований к ним. Это следует из таблиц 1 и 2, в которых рассмотрены возможности различных методологий, поддерживающие процесс анализа (таблица 1) и процесс разработки (таблица 2) [12].

Таблица 1

Аналитические возможности сравниваемых методологий объектно–ориентированного анализа

Возможность	OSA	OMT	SA/SD	JSD
Объекты: должны иметь индивидуальное и независимое состояние и поведение	+	+	+	+
Классы объектов: должны определять свойства своих членов и должны иметь место в памяти	+	+	+	+
Множества связей: множества соединений объектов	+	+	+	+
Реляционные классы объектов: рассматривают связи как объекты	+	+	–	+
Полностью интегрированные подмодели: допускают произвольную интеграцию подмоделей анализа; знак «–» в таблице означает, что подмодели, представленные, например, блок–схемами, не могут комбинироваться с другими видами подмоделей (например, моделями поведения)	+	–	–	+
Агрегация: часто используемый механизм абстракции, который представляет взаимосвязи между системами и их частями	+	+	+	+
Обобщение/наследование: механизм абстракции: если A есть специализация B, то свойства A подразумевают свойства B	+	+	–	+
Полномасштабные ограничения мощности связей: допускают мощности связей, являющихся произвольными множествами неотрицательных целых чисел (не только 1–1, 1–M, M–1, M–M)	+	–	–	–
Синонимы и омонимы: допускают несколько имен для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей	+	–	–	–
Полная система триггеров: допускаются только условия, только события, или комбинации условий и событий	+	+	–	–
Действия: описывают поведение, которое завершается	+	+	+	+
Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться	+	+	–	–
Межобъектный параллелизм: более одного объекта могут быть активными одновременно	+	+	+	+
Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов	+	+	–	–
Исключения: допускается обнаружение и обработка условий ошибок	+	–	–	–
Временные ограничения: обеспечивают средства ограничения времени на какое–либо действие	+	–	+	+
Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем	+	–	–	–
Метамодель: определяет правильный экземпляр модели	+	–	–	–
Родовой класс: параметризация классов – механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка	–	–	–	–
Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события	+	+	+	–
Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям	+	–	–	–
Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами	+	–	–	–
Непрерывные взаимодействия: допускает непрерывный поток информации	+	–	–	–
Взаимодействия по бродкастингу: разрешает иметь много приемников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий	+	–	–	–
Общее число аналитических возможностей	29	13	8	9

---