Case средства объектно ориентированного программирования

1.5 Методология case-средств объектно-ориентированного проектирования

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

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

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

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

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

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

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

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

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

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

Очевидно, что в конкретном проекте декомпозировать сложную систему одновременно двумя способами невозможно. Можно начать декомпозицию каким-либо одним способом, а затем, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения. Теперь перейдем к рассмотрению взаимосвязи между структурным и объектно-ориентированным подходами. Основой взаимосвязи является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных подходов является использование структурного анализа как основы для объектно-ориентированного проектирования. Такой подход целесообразен ввиду широкого распространения CASE-Объектно-ориентированный подход средств, поддерживающих структурный анализ. Его можно считать слишком прагматическим, но в некоторых ситуациях иной подход невозможен. При этом структурный анализ следует прекращать, как только диаграммы потоков данных начнут отражать не только деятельность организации (предметную область), а и систему ПО.

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

Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут некоторым образом соответствовать сущностям (в качестве упражнения можно предложить детально проанализировать все сходства и различия диаграмм «сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней стадии разработки системы — стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализация данных) расходятся. Таким образом, единственно возможным средством преодоления данного разрыва является построение отображения между объектно-ориентированной и реляционной технологиями, которое в основном сводится к отображению между диаграммами классов и реляционной моделью. Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между структурным CASE-средством Silverrun и объектно-ориентированным CASE-средством Rational Rose, разработанный российской компанией «Аргуссофт» .Этот мост создает диаграммы классов Rational Rose на основе RDM-модели (Relational Data Model — реляционная модель данных) Silverrun и наоборот. Аналогичные интерфейсы существуют также между CASE-средствами ERwin (с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).

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

Источник

Объектно-ориентированные case — средства и их характеристика.

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

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

В настоящее время для объектно-ориентированного модели­рования проблемной области широко используется унифициро­ванный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) и фактически является стандартом по объектно-ориентированным технологиям.

Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы:

1. диаграмму прецедентов использования (Use—casediagram), которая отображает функциональность ЭИС в виде совокупнос­ти выполняющихся последовательностей транзакций;
2. диаграмму классов объектов (Classdiagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
3. диаграммы состояний (Statechartdiagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4. диаграммы взаимодействия объектов (Interactiondiagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5. диаграммы деятельностей (Activitydiagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);
6. диаграммы пакетов (Packagediagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);
7. диаграмму компонентов (Componentdiagram), которая отображает физические модули программного кода;
8. диаграмму размещения (Deploymentdiagram), которая отображает распределение объектов по узлам вычислительной сети.

Case системы различных классов: tools, toolkit, workbenсh. Краткая характеристика инструментов.

Классификация по категориям основывается на определении уровня интегрированности функций в CASE-пакетах и ​​разделяет их на вспомогательные программы (tools), пакеты разработчика (toolkit) и инструментальные средства (workbench).

Категория tools включает вспомогательные пакеты, которые решают несложные автономные задачи.

Категория toolkit характеризует интегрированные средства поддержки одного из классов программных задач, ориентирована на поддержку одного этапа ЖЦ, использует репозиторий для хранения проектной информации.

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

Представлены отдельные инструменты, которые могут применяться на отдельных этапах жизненного цикла ИС.

IDEF, POWER DESIGNER – инструменты среднего охвата.

Охватывают следующие стадии:

1. Предпроектное обследование;
2. Техническое проектирование;
3. Часть рабочего проектирования.

Инструменты данного класса выполняют неполную генерацию.

WORKBENCH: все стадии цикла жизни.

Полностью охватывает весь жизненный цикл ИС, т.е. выполняет полную генерацию программного приложения (NLS, DESIGNER 2000)

Источник