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

IDE (англ. «Integrated development environment»; интегрированная среда разработки [16]) — комплекс программных средств, используемый для разработки информационных систем. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированном подходе к разработке.

CASE-технология (англ. «computer-aided software engineering») — это методология проектирования информационных систем, набор методов, нотаций и инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей [17].

CASE-средства — это набор инструментов по реализации CASE-технологии. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять, как программные средства для поддержки процессов жизненного цикла ИС.

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

Ниже перечислены функции CASE.

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

Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории [17].

Автопроверка — автоматическое обеспечение качества и тестирование моделей на наличие ошибок, полноту и непротиворечивость;

Прямое проектирование — это возможность генерации кода по спецификациям (диаграммам) UML на конкретном языке программирования. При этом порядок использования разработчиками CASE-средства следующий [18][19]:

1. создается логическая модель системы;
2. выбирается конкретный язык программирования (или СУБД) для построения физической модели, после чего CASE-средство автоматически создает физическую модель системы;
3. дорабатывается физическая модель;
4. выполняется автоматическая генерация текста программы или структуры базы данных на диске

Обратное проектирование — это создание UML-диаграмм перевод с языка программирования на язык. В этом случае порядок использования CASE-средства обратный – от текста программы или базы данных на диске к логической модели.

Целесообразность обратного проектирования определяется следующими предпосылками:

1. требуется осуществить поиск ошибок, чтобы убедиться в адекватности дизайна;
2. применение подхода RST (Reverse Semantic Traceability, обратная семантическая трассировка), когда осуществив после первого перевода с UML на язык программирования обратный перевод, и сравнив исходные и восстановленные UML-модели, можно убедиться в том, что дизайн системы соответствует модели, ошибок не обнаруживается и никакая информация не была утрачена в результате перевода;
3. если уходят «старые» разработчики или просто отсутствует документация и стоит задача модификации существующей системы, код которой плохо документирован, и требуется понять назначение системы и ее частей, функционал, предоставляемый ею, и т. д.;
4. появляются новые, более перспективные языки программирования и СУБД;

Реинжиниринг — это анализ существующего кода и его модификация после проведения обратного проектирования.

RTE (англ. «round-trip engineering», круговая/двусторонняя разработка) — это возможность CASE-средств синхронизировать два или более связанных с ними программных артефактов, таких как, исходный код, модели, файлы конфигурации и даже документации [20] [21]. Потребность в использовании RTE возникает, когда одна и та же информация присутствует в нескольких артефактах, из-за чего может возникнуть несогласованность, если не все артефакты постоянно обновляются, чтобы отразить данное изменение. Например, некоторая часть информации была добавлена/изменена только в одном артефакте, и в результате она утратилась/стала несовместимой с другими артефактами [22].

RTE часто ошибочно определяется как простая поддержка как прямого, так и обратного проектирования.

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

Еще одна характеристика RTE — это автоматическое обновление артефактов в ответ на автоматически обнаруженные несоответствия [20]. В этом смысле это отличается от прямого и обратного проектирования, имея возможность обновления как вручную (традиционно), так и автоматически (посредством автоматической генерации или анализа артефактов). Автоматическое обновление может быть по требованию или мгновенным (все связанные артефакты немедленно обновляются после каждого изменения, внесенного в один из них). В RTE по требованию авторы артефактов могут одновременно развивать артефакты (даже в распределенной настройке) и в какой-то момент выбрать выполнить сопоставление для выявления несоответствий и выбрать распространение некоторых из них и согласование потенциальных конфликтов [22].

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

Синхронизация между моделями UML и соответствующим исходным кодом — это наиболее распространенная форма применения RTE. Многие проприетарные CASE-средства поддерживают эту форму RTE (детальный анализ приведён далее во 2-ой главе настоящей работы). Обычно диаграммы классов UML поддерживаются CASE-средствами с RTE в некоторой степени; однако некоторые концепции UML, такие как ассоциации и сдерживание, не имеют прямых представлений во многих языках программирования, что ограничивает удобство использования созданного кода и точность анализа кода (например, сдерживание трудно распознать в коде) [22].

Общая проблема в утилитах с поддержкой RTE заключается в том, что модель, полученная в результате обратного проектирования, не совпадает с исходной, если только утилитам не помогают трудоемкие аннотации. Поведенческие части UML налагают еще больше проблем для RTE [21].

Более гибкая форма RTE реализуется в контексте интерфейсов прикладного программирования (API), в соответствии с которыми модель, описывающая использование API-интерфейса инфраструктуры, синхронизируется с кодом этого приложения [20].

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

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

Типичными CASE-инструментами являются инструменты управления конфигурацией, моделирования данных, анализа и проектирования, преобразования моделей, редактирования программного кода, рефакторинга кода, генераторы кода и инструменты для построения UML-диаграмм.

OMG (сокр. от англ. «Object Management Group») — некоммерческое объединение, занимающееся разработкой и продвижением объектно-ориентированных технологий и стандартов для создания платформо-независимых приложений на уровне предприятия [23].

MDE (англ. «model-driven engineering» - разработка, управляемая моделями) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты [24].

Метамодель — это модель, описывающая другую модель и транзитивное отношение между двумя моделями. Метамодель описывает понятия, используемые в модели, и фиксирует информацию в виде метаданных, которые могут быть обработаны инструментами. Модель всегда ссылается на единственную метамодель. Типичные метамодели, рекомендуемые OMG это: UML, SysML, SPEM или CWM.

MDA (англ. «Model Driven Architecture», Архитектура, управляемая моделью) — создаваемая консорциумом OMG разновидность концепции «Разработка, управляемая моделями»: модельно-ориентированного подхода к разработке программного обеспечения. Является наиболее известной MDE-инициативой, суть которого состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов её трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.). Название концепции не совсем удачно, так как она определяет вовсе не архитектуру а именно метод разработки программного обеспечения [25].

MOF (англ. «Meta-Object Facility», мета-объектное средство) — это стандарт OMG для MDE, возникший из UML в качестве архитектуры метамоделирования для определения самого UML. MOF призван служить мостом между разными метамоделями, поскольку представляет собой мощную основу для их описания. Являясь частью концепции MDA [25], технология моделирования MOF определяет создание метамодели.

CORBA (англ. «Common Object Request Broker Architecture», типовая архитектура опосредованных запросов к объектам) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология [26].

XMI (англ. «XML Metadata Interchange») — стандарт OMG для обмена метаданными с помощью языка XML. Наиболее часто XMI применяется как формат обмена UML-моделями, поскольку это позволяет импортировать UML-модель из одного инструмента UML-моделирования в другой — из-за различий в определении синтаксиса и семантики элементов языка [27].

Выводы.

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

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

2. Особенности подхода и CASE-средства для проектирования

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

ArgoUML - средство UML моделирования с открытым исходным кодом.

ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше. Поддерживает девять видов диаграмм UML (диаграммы классов, состояний, кооперации, последовательности, деятельности, прецедентов, объектов, компонентов, развёртывания) [28][29].

• Лицензия: EPL;
• Языки генерации кода: C ++, C #, Java, PHP, Ruby;
• Обратное проектирование: Java (другие языки с плагинами);
• Платформы: кросс-платформенное (Java);
• Другие особенности: поддержка MDA, спецификации UML 1.4, а также XMI 1.2; поддержка OCL для классов, автоматическая верификация модели UML (design critics); расширенное редактирование диаграммы и масштабирование; доступно на 10 языках.