Лекция Анализ и проектирование программного обеспечения. Анализ по - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Лекция Анализ и проектирование программного обеспечения. Анализ по 1 187.61kb.
Лекция Анализ и проектирование программного обеспечения. Проектирование по 1 166.11kb.
Анализ требований и управление изменениями программных проектов 1 108.74kb.
1. Анализ предметной област 3 596.51kb.
Методологии разработки программного обеспечения 1 31.78kb.
Программный принцип работы компьютера. Программное обеспечение. 1 57.34kb.
Методические указания к выполнению работы 4 Анализ исходных данных 5 1 100.87kb.
Рабочая программа дисциплины: б б 11 Разработка и анализ требований... 1 102.43kb.
Минимизация ошибок и сбоев программного обеспечения 1 62.06kb.
Проектирование Информационных Систем Лектор: Пальмов В. С. V курс. 4 506.3kb.
Продвижение услуг по разработке программного обеспечения (2009) 1 196.58kb.
Поддержка эксплуатации связана с рутинными задачами сопровождения... 1 71.2kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Лекция Анализ и проектирование программного обеспечения. Анализ по - страница №1/1

Лекция 7. Анализ и проектирование программного обеспечения. Анализ ПО


Сначала охарактеризуем в целом технологический процесс анализа и проектирования (один из процессов в рамках RUP). Его цели:

  • преобразование требований в системный проект;

  • создание стабильной (т. е. не подлежащей существенным изменениям) архитектуры системы;

  • адаптация системного проекта к среде реализации.

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

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

Эскизная архитектура включает:


  • Набор ключевых абстракций.

  • Набор классов анализа.

  • Механизмы анализа.

  • Иерархию уровней.

  • Структуру системы.

  • Реализации вариантов использования.

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

Определяются: проектные классы; механизмы проектирования; представление размещения.

Анализ поведения включает:


  • анализ вариантов использования;

  • определение элементов проекта;

  • рецензирование проекта.

Проектирование элементов включает:

  • выявление пакетов и подсистем;

  • проектирование классов;

  • проектирование подсистем.

Проектирование БД включает:

  • выделение устойчивых классов;

  • разработку схемы БД;

  • определение механизмов хранения (таких как ODBC или OODBMS).

Анализ и проектирование отличаются подходом к создаваемой системе. Анализ характеризуется тем, что:

  • в центре внимания – проблема;

  • не придается значения деталям;

  • описывается структура и поведение системы;

  • реализуются функциональные требования в архитектуре системы;

  • модель анализа имеет относительно небольшой размер.

Характеристики проектирования:

  • в центре внимания – решение;

  • придается значение деталям – операциям и атрибутам;

  • учитываются аспекты производительности;

  • модель адаптирована к реализации в коде;

  • реализуются нефункциональные требования;

  • проектная модель значительно больше и подробнее модели анализа.

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

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

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

Обязанности архитектора во время анализа:



  • координация и руководство процессом анализа и проектирования;

  • определение структуры каждого архитектурного представления;

  • осуществление архитектурного анализа.

Обязанности разработчика во время анализа:

  • анализ вариантов использования;

  • определение обязанностей, поведения, свойств классов и связей между классами;

  • анализ одного или нескольких пакетов или подсистем.

Специализированные разработчики (разработчик БД, разработчик элементов реального времени) подключаются при проектировании.

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

Рецензент оценивает решения, принятые в ходе процесса и созданные рабочие продукты (артефакты, т. е. документы, модели и т. д.).

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



  1. архитектурный анализ;

  2. анализ вариантов использования.

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

  1. утверждение общих соглашений моделирования и документирования системы;

  2. предварительное выявление архитектурных механизмов (механизмов анализа);

  3. формирование набора ключевых абстракций предметной области;

  4. формирование начального представления архитектурных уровней.

Соглашения моделирования определяют:

  • используемые диаграммы и элементы модели;

  • правила их применения;

  • соглашения по именованию элементов модели;

  • организацию модели (пакеты).

Соглашения фиксируются в документе «Руководящие указания по проектированию» (Design Guidelines). Пример соглашений:

  1. Имена вариантов использования должны быть короткими глагольными фразами.

  2. Для каждого варианта использования должен быть создан пакет Use-Case Realization, включающий:

        1. п
          о крайней мере, одну реализацию варианта использования, представленную в модели в виде кооперации;

        2. д
          иаграмму “View Of Participating Classes” (VOPC), на которой представлены только те классы, экземпляры которых задействованы в потоках событий реализации данного варианта использования (см. пример);

  3. Имена классов должны быть существительными, соответствующими, по возможности, понятиям предметной области.

  4. Имена классов должны начинаться с заглавной буквы.

  5. Имена атрибутов и операций должны начинаться со строчной буквы.

  6. Составные имена должны быть сплошными, без подчеркиваний, каждое отдельное слово должно начинаться с заглавной буквы.

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

  • Механизмы анализа: обеспечивают взаимодействие классов и компонентов предметной области, без деталей реализации.

  • Проектные механизмы: учитывают некоторые детали среды реализации, без привязки к конкретной среде (например, выбор между РСУБД и ООСУБД).

  • Механизмы реализации: зависят от конкретной технологии, языка программирования, поставщика (Oracle, Microsoft и т.д.).

Примеры механизмов анализа:

  • Устойчивость (persistency): элементы модели, которые должны сохранять свое состояние в течение длительного времени должны быть определены как устойчивые (для каждого устойчивого элемента определяются его размер и количество хранимых объектов, сроки хранения, механизмы и частотные характеристики доступа).

  • Интерфейс с унаследованными системами (legacy interface) – к этому механизму относят все элементы модели, ответственные за интерфейс с унаследованной системой.

  • Безопасность (уровни, правила, привилегии) – элементы, обеспечивающие контроль доступа к системе.

  • Распределение – элементы, которые должны быть распределены по узлам сети.

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

Рисуется диаграмма классов Key Abstractions, на которую помещаются все ключевые абстракции. Пример диаграммы ключевых абстракций приведен на предыдущей странице.



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

  • прикладной, содержащий набор компонентов, реализующих основную функциональность системы;

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

  • промежуточный (middleware), куда входят платформо-независимые сервисы;

  • системный, содержащий компоненты вычислительной и сетевой инфраструктуры.

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

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

  • Модель-представление-управление (Model-view-controller, M-V-C) – разделение приложения на три части: данные и бизнес-правила; пользовательское представление; обработку данных.

  • Каналы и фильтры (Pipes and filters) – шаблон архитектуры системы для потоковой обработки данных.

Архитектурный образец «Layers»:

Прикладной уровень (Application subsystems) – реализация функциональности вариантов использования.

Бизнес-уровень (Business-specific) – набор компонентов, специфичных для конкретной предметной области.

Уровень промежуточного ПО (Middleware) – платформо-независимые сервисы (GUI, ORB, …)

Уровень базового ПО (System software) – обеспечение вычислительной и сетевой инфраструктуры (ОС, сетевые протоколы и др.).

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


О
бразец «Каналы и фильтры» разбивает большую сложную задачу по обработке данных на упорядоченную совокупность небольших независимых этапов обработки (каждый такой этап – «фильтр»), соединенных «каналами» – потоками данных. При этом для некоторых задач удается добиться эффективного решения за счет конвейера.
Образец «Model-view-controller» родом из языка Smalltalk. Проблема, которую он решает, формулируется так: Изменения во внешнем представлении достаточно вероятны, одна и та же информация представляется по-разному в нескольких местах, система должна быстро реагировать на изменения данных.

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

Рис. Один из вариантов организации взаимодействия, предписываемый образцом MVC.

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

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

Анализ вариантов использования выполняется разработчиками и включает в себя:


  • идентификацию классов, участвующих в реализации потоков событий, (так называемых, классов анализа);

  • определение обязанностей классов, их атрибутов и ассоциаций;

  • унификацию классов анализа;

  • квалификацию механизмов анализа.

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

Шаги анализа вариантов использования:



  1. Уточнение и дополнение описаний вариантов использования.

  2. Для каждой реализации варианта использования:

    1. Выявление классов, участвующих в реализации потоков событий варианта использования.

    2. Распределение поведения, реализуемого вариантом использования, между классами (обязанности классов).

  3. Для каждого выявленного класса анализа:

    1. Определение обязанностей класса.

    2. Определение атрибутов и ассоциаций.

    3. Квалификация механизмов анализа.

  4. Унификация классов анализа.

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

  • граничные классы, являющиеся посредниками при взаимодействии с внешними объектами;

  • управляющие классы, обеспечивающие координацию поведения объектов в системе;

  • классы-сущности, представляющие собой ключевые абстракции разрабатываемой системы.

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

  • пользовательский интерфейс (обмен информацией с пользователем, без деталей UI – кнопок, списков, окон);

  • системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

П
равило выявления управляющих классов: для каждого варианта использования создается ответственный за его реализацию класс управления.

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

Все созданные при анализе данного варианта использования классы анализа помещаются на диаграмму VOPC (View Of Participating Classes). Пример см. на стр. 3.


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

  • Знание:

    • наличие информации о данных или вычисляемых величинах;

    • наличие информации о связанных объектах.

  • Действие:

    • выполнение некоторых действий самим объектом (прием и обработка входящих сообщений);

    • инициация действий других объектов (отправка исходящих сообщений);

    • к
      оординация действий других объектов (посредничество).

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

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

При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов: Information Expert, Creator, Low Coupling, High Cohesion и др.


Образец Information Expert. Проблема: Нужно определить наиболее общий принцип распределения обязанностей между классами. Решение: Следует назначить обязанность информационному эксперту – классу, у которого имеется информация, требуемая для выполнения обязанности. Пример:

При выполнении подчиненного потока событий "Обновить график" варианта использования "Зарегистрироваться на курсы" студент-пользователь должен получить доступ к своему графику прежде, чем изменить его. Согласно образцу "Information Expert", нужно определить, объект какого класса содержит информацию, необходимую для доступа к графику. На эту роль информационного эксперта, очевидно, претендует объект класса-сущности Student, поскольку график принадлежит именно ему. Поэтому сообщение 3 "get schedule(forSemester)" должно быть направлено от контроллера объекту класса Student. После того, как студент получит график и внесет в него необходимые изменения, они должны быть зафиксированы в объекте Schedule. В данном случае уже сам объекте Schedule будет играть роль информационного эксперта, поскольку он непосредственно доступен контроллеру, и сообщение 10 "update with new selections" будет направлено именно ему.

Следствия:

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

В некоторых ситуациях применение образца Information Expert нежелательно.

Образец "Creator". Проблема: Нужно определить, кто должен отвечать за создание нового экземпляра некоторого класса. Создание новых объектов в объектно-ориентированной системе является одним из стандартных видов деятельности. Следовательно, при назначении обязанностей, связанных с созданием объектов, полезно руководствоваться некоторым основным принципом. Решение: Следует назначить классу В обязанность создавать экземпляры класса А, если выполняется одно из следующих условий:

• класс В агрегирует, содержит или активно использует объекты класса А;

• класс В обладает данными инициализации, которые будут передаваться объектам класса А при их создании (т.е. класс В является информационным экспертом).

Класс В при этом определяется как создатель (creator) объектов класса А.

Если несколько классов удовлетворяют этим условиям, то предпочтительнее использовать в качестве создателя класс, агрегирующий или содержащий класс А.

П
ример:
При выполнении подчиненного потока событий "Создать график" варианта использования "Зарегистрироваться на курсы" необходимо решить, кто должен отвечать за создание нового графика в системе. На рис. показаны два возможных варианта решения этой задачи.

Согласно образцу "Creator", оба решения подходят, так как с одной стороны объект-контроллер обладает данными, необходимыми для инициализации, с другой стороны объект Student агрегирует объекты Schedule.



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

В некоторых случаях в качестве создателя выбирается класс, который содержит данные инициализации, передаваемые объекту во время его создания. На самом деле это пример использования образца Information Expert.



Образец "Low Coupling" (низкая связанность). Проблема: Нужно распределить обязанности между классами таким образом, чтобы снизить взаимное влияние изменений в них и повысить возможность повторного использования. Решение: Следует распределить обязанности таким образом, чтобы обеспечить низкую связанность. Связанность (coupling) – это мера, определяющая, насколько жестко один элемент связан с другими элементами, или каким количеством данных о других элементах он обладает. Элемент с низкой связанностью зависит от небольшого числа других элементов. Класс с высокой связанностью зависит множества других классов. Наличие таких классов нежелательно, поскольку оно приводит к возникновению следующих проблем:

  • Изменения в связанных классах приводят к локальным изменениям в данном классе.

  • Затрудняется понимание каждого класса в отдельности.

  • Усложняется повторное использование, поскольку для этого требуется дополнительный анализ классов, с которыми связан данный класс.

Пример: Рассмотрим подчиненный поток событий "Создать график" варианта использования "Зарегистрироваться на курсы" (предыдущий рисунок). Согласно образцу "Low Coupling", наилучшим решением является вариант справа, поскольку при этом у класса RegistrationController будет на одну связь меньше (т.е., будет обеспечена более низкая связанность).

Следствия: Образец Low Coupling поддерживает независимость классов, что, в свою очередь, повышает возможности повторного использования. Его нельзя рассматривать изолированно от других образцов, таких как Information Expert и High Cohesion. Он также обеспечивает выполнение одного из основных принципов проектирования, применяемых при распределении обязанностей.

Образец "High Cohesion" (высокая функциональная прочность или сильное зацепление обязанностей). Проблема: Нужно распределить обязанности между классами таким образом, чтобы каждый класс не выполнял много разнородных функций или несвязанных между собой обязанностей. Такие классы создавать нежелательно, поскольку они приводят к возникновению таких же проблем, как у классов с сильной связанностью. Решение: Следует распределить обязанности таким образом, чтобы обеспечить высокую функциональную прочность. В терминах объектно-ориентированного проектирования функциональная прочность (cohesion) – это мера взаимосвязи и непротиворечивости обязанностей класса. Считается, что элемент обладает высокой прочностью, если его обязанности тесно связаны между собой, и он не выполняет излишнего объема работы. В роли таких элементов могут выступать классы, подсистемы, модули и т.д.

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



Пример: Используем тот же пример, что и для предыдущего образца. Согласно образцу "High Cohesion", наилучшим решением также является вариант справа, поскольку при этом класс RegistrationController делегирует обязанность создания нового объекта класса Schedule классу Student, и у самого класса RegistrationController будет на одну обязанность меньше (т.е., его прочность будет выше). Обязанность, отданная Student, относится к тому же роду, что и другие его обязанности, так как касается порождения объектов – частей.

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

Следует обратить внимание, что обязанностью экземпляров классов является не только прием и обработка сообщений, но и их отправка другим объектам. То есть объект обязан знать о других объектах, которым он должен будет посылать сообщения. Распределить обязанности такого рода позволяют образцы Сценарий транзакции и Модель предметной области. Они введены Мартином Фаулером в книге «Архитектура корпоративных программных приложений».



Образец «Сценарий транзакции»

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

Э
скиз:


Назначение: Главное достоинство: простота, естественность, производительность. Подходит для небольших приложений. Недостаток: при усложнении бизнес-логики дублируется большое количество кода – снижается гибкость и сопровождаемость. В таких случаях нужно применять образец «Модель предметной области».

П
ример взаимодействия согласно образцу «Сценарий транзакции»:


Объект-контроллер ведет транзакцию (сохранение расписания) по сценарию от начала до конца.

Образец «Модель предметной области»

Аннотация: Обязанности по обработке запросов распределены по сети объектов-сущностей. В приложении создается слой объектов, описывающих структурные и поведенческие аспекты предметной области. Поведение сочетается с данными и реализуется в сущностях. Управляющие объекты довольствуются ролью посредников между граничными объектами и сущностями.

Э
скиз:

Назначение: Подходит для приложений с запутанной бизнес-логикой. Недостаток: создание модели предметной области более трудоемко, чем реализация сценария транзакции. В простых случаях нужно применять сценарий транзакции.

П
ример:
в системе регистрации на курсы бизнес-логика распределена между классами-сущностями

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

Е
сли бы применялся сценарий транзакции, взаимодействие выглядело бы так:

В этом варианте всю транзакцию ведет объект-контроллер.

Набор обязанностей классов, полученный в результате их распределения, должен быть проанализирован на предмет выявления и устранения следующих проблем:

• дублирования одинаковых обязанностей в различных классах;

• противоречивых обязанностей в рамках класса;

• классов с одной обязанностью или вообще без обязанностей;

• классов, взаимодействующих с большим количеством других классов.

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

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

На втором этапе, исходя из знаний о предметной области, создаются связи между классами-сущностями (ассоциации, агрегации, обобщения).

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

Квалификация механизмов анализа состоит в том, что:


  • Составляется список всех механизмов анализа.

  • Классы анализа ставятся в соответствие механизмам анализа.

  • Определяются характеристики механизмов анализа.

Механизмы анализа играют следующие роли:

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

  • Представляют собой набор типовых решений, или образцов (patterns), принятых в качестве стандарта данного проекта.

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

Т
ак, имея дело с устойчивыми классами, достаточно указать для них механизм «persistencу», не задумываясь как именно будет реализовано сохранение их экземпляров в базе данных. Пример:

В описания классов, сопоставленных с архитектурными механизмами, добавляются дополнительные характеристики, например:

Характеристики класса Schedule:


  • Объем: до 2000 графиков.

  • Частота доступа:

  • Создание: 500 в день.

  • Чтение: 2,000 обращений в час.

  • Обновление: 1,000 в день.

  • Удаление: 50 в день.

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

  • имя и описание каждого класса анализа должно отражать сущность его роли в системе;

  • классы с одинаковым поведением, или представляющие одно и то же явление, должны объединяться;

  • классы-сущности с одинаковыми атрибутами должны объединяться (даже если их поведение отличается).

По результатам унификации классов должны быть модифицированы описания вариантов использования.

По окончании модель анализа должна быть подвергнута проверке:



  1. Все ли классы обоснованы надлежащим образом?

  2. Отражает ли имя каждого класса его роль?

  3. Представляет ли класс единственную, четко определенную абстракцию?

  4. Являются ли все атрибуты и обязанности класса функционально связанными?

  5. Отражают ли классы всю функциональность вариантов использованию, заключенную в основных, подчиненных и альтернативных потоках событий?

  6. Однозначно ли распределено поведение по классам?

Упоминаемые в лекции образцы подробно описаны в книгах [3] и [4].

Литература к лекции 7


  1. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 12-13.

  2. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.

  3. Ларман Крэг. Применение UML 2.0 и шаблонов проектирования. 3-е изд. Пер. с англ. – М.: Вильямс, 2007.

  4. Фаулер М. Архитектура корпоративных программных приложений. – М.: Вильямс, 2007.

  5. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.