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

Усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области и для которых невозможно найти человека, понимающего эту предметную область в целом, также требует использования традиционных подходов в виду их большей доступности для неспециалистов;

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

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ (UML) – КАК СРЕДСТВО ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОНЫХ СИСТЕМ

• 1. Унифицированный процесс разработки информационных систем

Унифицированный процесс должен быть: управляемый вариантами использования, архитектурно-ориентированный, итеративный и инкрементный.

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

Поскольку варианты использования управляют процессом разработки, то они разрабатываются в паре с архитектурой системы. Таким образом, варианты использования управляют архитектурой, а архитектура оказывает влияние на варианты использования. Причем, и варианты использования, и архитектура развиваются в процессе жизненного цикла.

Унифицированный процесс – ориентирован на архитектуру. Архитектура - это представление всего проекта с выделением ключевых

составляющих и затушевывание деталей. Архитектура вырастает из

требований к результату, в том виде, как их понимает пользователь и другие заинтересованные лица.

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

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

Архитектура и варианты использования разрабатываются параллельно. Архитектор выполняет следующие работы:

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

Архитектура определяется в виде представлений всех моделей системы, объединенных (сконфигурированных) в систему.

Существуют архитектурные представления модели вариантов использования, модели анализа, модели проектирования, модели развертывания.

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

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

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

Задачи, которые образуют итерации, выбираются под воздействием двух факторов:

• В ходе итерации следует работать с группой вариантов использования, которая повышает применимость продукта в ходе дальнейшей разработки.
• В ходе разработки итерации следует заниматься серьезными рисками.

Достоинства управляемого итеративного процесса (в управлении рисками):

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

2. Управляемая итерация снижает риски не поставки продукта заказчику в запланированные сроки.

3. Управляемая итерация ускоряет темпы процесса разработки, так как для разработчиков короткий и точный план предпочтительнее длинного и вечно сдвигающегося (временные риски).

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

• 1. Структура и основные понятия унифицированного языка моделирования (UML)

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

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

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

Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООАП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые, в свою очередь, могут подразделяться на другие более частные представления. Феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех ее особенностей.

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

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей: семантики и нотации.

Семантика языка UML представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

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

Формальное описание самого языка UML основывается на некоторой общей иерархической структуре модельных представлений, имеющей четыре уровня: метаметамодель; метамодель; модель; объекты пользователя.

Уровень метаметамодели образует исходную основу для всех метамодельных представлений. Главное предназначение этого уровня состоит в том, чтобы определить язык для спецификации метамодели. Метаметамодель определяет модель языка UML на самом высоком уровне абстракции и является наиболее компактным ее описанием. С другой стороны, метаметамодель может специфицировать несколько метамоделей, чем достигается потенциальная гибкость включения дополнительных понятий. Примерами понятий этого уровня служат метакласс, метаатрибут, метаоперация.

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

Метамоделъ является экземпляром или конкретизацией метаметамодели. Главная задача этого уровня — определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия языка UML — это понятия уровня метамодели. Примеры таких понятий: класс, атрибут, операция, компонент, ассоциация и многие другие.

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