Моделирование и проектирование программного обеспечения Лекция 6. Объектно-ориентированный анализ
advertisement
Моделирование и проектирование программного обеспечения Лекция 6. Объектно-ориентированный анализ Процесс разработки ПО • Выявление и описание требований – сбор данных о том, что должна делать система; • Планирование проекта разработки – оценка трудоемкости, составление календарного планы, планирование качества, управление рисками; • Выявление вариантов использование – моделирование вариантов использования • Анализ – уточнение и структурирование требований – моделирование хода анализ; • Проектирование – реализация требований в архитектуре системы – моделирование хода проектирование; • Реализация (кодирование) – построение программного обеспечения; • Тестирование – проверяется, отвечает ли реализация предъявляемым требованиям; • Внедрение – передача ПО заказчику и организация его практического применения. Объектно-ориентированный анализ • На этапе анализа моделируется, что должна делать система. • На этапе проектирования моделируется, как это поведение может быть реализовано. • Основной целью анализа является построение логической модели системы, отражающей что должна предоставлять система для удовлетворения требований пользователя. • Основной целью проектирования является определение в полном объеме того, как будет реализовываться эта функциональность. • Проектная модель базируется на модели анализа и может считаться просто ее улучшенной и уточненной версией. Предметная область • Предметная область – это область реального мира, в которой возникает необходимость в программной системе (и, следовательно, в деятельности по разработке программного обеспечения). – Обычно это определенная область деловой активности, например сетевая торговля или управление взаимоотношениями с клиентами. – Однако важно отметить, что предметная область может являться физическим оборудованием, для работы которого необходимо программное обеспечение. • Разработка коммерческого программного обеспечения служит некоторой прикладной цели – Например, • автоматизация существующего бизнес-процесса • разработка нового устройства, имеющего существенную программную составляющую. Область решения (Компьютерное пространство) • Область решения – это множество библиотек утилитных классов и многократно используемых компонентов, таких как Time, Date, String, коллекции и т. д. • Здесь находится: – промежуточное программное обеспечение (middleware), такое как коммуникационное ПО, – базы данных (и реляционные, и объектные) и – компонентные инфраструктуры, например .NET, CORBA или Enterprise JavaBeans, – а также средства для построения GUI. • Эта область предоставляет технические инструментальные средства для реализации системы. Работы по моделированию на этапе анализа • В модели анализа основное внимание уделяется пониманию проблемы: – выявлению объектов предметной области (ПрО) – выявлению взаимосвязей между ними; – выявлению взаимодействия между ними. • Основные виды работ: – Статическое моделирование • выявление классов; • разделение классов по категориям (структуризация классов) – Динамическое моделирование: • Моделирование динамического взаимодействия между объектами независимого от состояния • Моделирование взаимодействия между объектами зависимого от состояния - на основе машины конечных состояний (конечных автоматов). Исходные данные для анализа • Бизнес-модель – в распоряжении разработчиков модели может быть (а может и не быть) бизнес-модель моделируемой системы. – Если она уже есть, это превосходный источник требований. • Общие требования к ПО - Спецификация требований к ПО (включает функциональные и не функциональные требования) • Диаграммы и спецификации вариантов использования (прецедентов). Модель анализа (МА) • Все системы разные, поэтому сложно найти универсальный подход к созданию моделей анализа. • Модель анализа системы среднего размера и сложности включает от 50 до 100 классов анализа. • При создании МА важно ограничиться лишь теми классами, которые являются частью словаря предметной области. – часто имеется желание поместить в модель анализа и проектные классы (такие как классы, используемые для установления соединений или доступа к базе данных), но этого необходимо избегать (если только предметная область не касается связи или баз данных)! • МА должна быть кратким, простым описанием структуры и поведения системы. • Все решения по реализации должны приниматься при проектировании и реализации ПС. Способы создания хорошей МА 1. МА всегда создается на языке предметной области заказчика. – Абстракции аналитической модели должны формировать часть словаря бизнес-сферы. 2. Необходимо сосредоточиться на отображении основной картины. – Не надо углубляться в детали того, как будет работать система. – Для этого отводится достаточно времени при проектировании. 3. Необходимо четко различать – проблемную область (проблемное пространство) и – область решения (компьютерное пространство). 4. Основное внимание всегда должно быть направлено на абстракции предметной области. – Например, при моделировании системы электронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). – Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения. 5. Всегда необходимо стремиться минимизировать связанность (coupling). – Каждая ассоциация между классами увеличивает их связанность. 6. Наследование между классами следует применять только в том случае, если присутствует естественная и очевидная иерархия абстракций, – При анализе иерархия не должна применяться для повторного использования кода. – Наследование – самая сильная форма связанности классов. 7. Модель должна быть полезна для всех заинтересованных сторон. – Не надо создавать модель анализа, которая не понятна пользователям, проектировщикам или разработчиками. – Основные способы достижения этого: • сделать модель анализа и процесс моделирования максимально открытыми, • по возможности привлечь в их выполнение все заинтересованные стороны, • проводить частые и открытые обсуждения. 8. И, прежде всего, модель должна быть простой! • Это легче сказать, чем сделать, но из опыта специалистов известно, что внутри любой сложной модели анализа можно найти простую. • Один из способов упрощения – рассматривать вопрос в общем, не погружаясь в частности. • Класс анализа описывается на достаточно высоком уровне абстракции. • Здесь нет полного набора атрибутов, а набор операций – это фактически только эскиз, отражающий ключевые сервисы, предлагаемые классом. – Все операции и атрибуты класса должны быть полностью описаны на этапе проектирования. • С помощью классов анализа делается попытка описать, что должна делать будущая программная системы без рассмотрения его возможной реализации. – В проектных классах будет необходимо точно определить, как каждый класс будет осуществлять свои обязанности. Понятие классов анализа • Классы анализа моделируют важные аспекты предметной области. – Например: «банкомат», «клиент», «покупатель» или «продукт». • Классы анализа – это классы, которые: – представляют четкую абстракцию предметной области (problem domain); – должны проецироваться на реальные бизнеспонятия – быть поименованы в соответствии с используемыми в ПО именами этих понятий. • Классы анализа должны четко и однозначно связываться с реальными прикладными понятиями. – Самое важное свойство класса анализа – он должен четко и однозначно проецироваться в некоторое реальное прикладное понятие, например покупатель, продукт или счет. • Это предполагает четкость и однозначность самих бизнес-понятий, что случается редко. • Задача ОО аналитика – попытаться прояснить беспорядочные или несоответствующие прикладные понятия и превратить их в то, что может стать основой для класса анализа. • В это состоит сложность ОО анализа. Связь между классами анализа и проектирования • Для перехода от класса анализа к классу проектирование: – уточняется и полностью описывается набор атрибутов, включая: имя, тип, видимость и (необязательно) применяемое по умолчанию значение; – уточнить набор операций и полностью описать их, включая имя, список параметров и возвращаемый тип. Первый шаг построения ПО • Первый шаг в построении ОО программного обеспечения – прояснить предметную область. • Если она содержит четко определенные бизнеспонятия и имеет простую функциональную структуру, то достаточно просто разработать программное решение. • Большая часть этой работы осуществляется при определении требований в деятельностях по – выявлению требований и – созданию модели вариантов использования и – созданию глоссария проекта. • Однако намного большая ясность вносится при построении классов анализа и реализации вариантов использования. • Важно, чтобы все классы модели анализа являлись классами анализа, а не классами, вытекающими из проектных соображений (области решения – компьютерного пространства). • При детальном проектировании классы анализа могут быть преобразованы в один или более проектных классов. Важность правильное выявление классов анализа • Очень важным для ОО анализа и проектирования является правильное выявление классов анализа. • Если при анализе классы определены неверно, то и весь процесс разработки программного обеспечения, основывающийся на работах по определению требований и анализа, окажется под угрозой. • В связи с этим критически важно уделить анализу достаточное количество времени, чтобы быть уверенными в правильности определения классов анализа. • Время выделенное для определения классов анализа позволит сэкономит время на выполнение последующих работ (проектирование, реализация). Содержание классов анализа • Классы анализа должны представлять «высокоуровневый» набор атрибутов. • Они указывают атрибуты, которые, возможно, будут присутствовать в проектных классах. – Можно сказать, что классы анализа включают предполагаемые атрибуты проектных классов. • В классах анализа содержатся только ключевые атрибуты и обязанности, определенные на очень высоком уровне абстракции. Операции класса анализа • Операции классов анализа определяют на высоком уровне абстракции, ключевые сервисы, которые должен предлагать класс. • Классы анализа определяют обязанности объектов: – обязанность знать что-то (обязанность за знание); – обязанность вести себя как-то (обязанность за поведение). • При выполнении проектирования операции классов анализа станут реальными операциями. – Однако одна операция уровня анализа очень часто разбивается на несколько операций уровня проекта. UML представление класса анализа • Для изображения класса анализа обычно используется упрощенный UML синтаксис. • Конечно, всегда можно добавить любые необходимые, дополнения, чтобы сделать модель более понятной. • Однако базовый синтаксис класса анализа всегда должен избегать деталей реализации. Минимальная форма класса анализа • Имя – обязательно. • Атрибуты – имена атрибутов являются обязательными, хотя на данном этапе могут моделироваться только важные предполагаемые атрибуты. – Типы атрибутов считаются необязательными. • Операции – в анализе операции могут быть всего лишь очень приблизительными формулировками обязанностей класса. – Параметры и возвращаемые типы операций приводятся только в том случае, если они важны для понимания модели. • Видимость – обычно не указывается. • Стереотипы – могут указываться, если это приводит к улучшению модели. Отличительные признаки хорошего класса анализа 1. его имя отражает его назначение; 2. он является четкой абстракцией, моделирующей один конкретный элемент предметной области; 3. он понятно связывается с конкретными возможностями предметной области; 4. имеет небольшой четко определенный набор обязанностей: 1. обладает высокой сцепленностью (cohesion); 2. имеет низкая связанность с другими классами (coupling). Имя класса анализа должно отражать его назначение • При анализе делается попытка точно и лаконично смоделировать один аспект предметной области с точки зрения создаваемой системы. – Например, при моделировании клиента банковской системы необходимо записать его имя, адрес и т. д. – При этом вряд ли представляет интерес информация о том, предпочитает ли он сидеть в самолете у окна или в проходе. • Необходимо сосредоточиться на важных с точки зрения строящейся системы аспектах реальных сущностей. Обязанности класса анализа • Обязанности описывают связный набор операций. – Обязанность – это контракт или обязательство класса по отношению к его клиентам. • По существу, обязанность – это сервис, который класс предлагает другим классам. • Очень важно, чтобы классы анализа имели связный набор обязанностей, абсолютно соответствующих назначению класса (которое выражено в его имени) и реальной «сущности», моделируемой классом. • Важно правильно распределить обязанности между классами анализа, чтобы обеспечить максимальную сцепленность внутри каждого класса. Минимальная связанность • Хорошие классы обладают минимальной связанностью (coupling) с другими классами. • Связанность измеряется количеством классов, с которыми данный класс имеет отношения. • Равномерное распределение обязанностей между классами обеспечит в результате низкую связанность. • Размещение управления или множества обязанностей в одном классе приводит к повышению связанности этого класса. Выявление классов Выявление классов и их ответственностей • На этапах ООА и ООПр не делаются попытки выявить классы напрямую. • Существует несколько концептуальных шагов для получения классов для «Диаграммы классов». 1. Выявление сущностей ПрП, которые являются кандидатами для разделения рассматриваемого предмета обсуждения. 2. Отсеивание кандидатов, которые являются избыточными или не релевантными (не относящимися) решаемой проблеме. 3. Выявление внутренних свойств сущностей ПрП, релевантных решаемой проблеме. 4. Абстрагирование свойств сущностей в ответственности объектов. 5. Выявление классов для организации наборов объектов. • Типичными причинами отсеивания сущностей-кандидатов являются: 1. Они не имеют присущих им свойств, относящихся к рассматриваемой проблеме (шаг 3). 2. Имеются другие сущности, свойства которых являются более подходящими для решаемой проблемы (шаг 3 и 4). • • • Главным здесь является то, что данный список представляет набор концептуальных средств для перехода от проблемного пространства потребителя к Диаграмме Классов. Пока такая последовательность шагов будет выполняться, все будет работать так как надо. Имеются два наиболее популярных подхода, для выполнения начального отбора таких классов для ДК, которые хорошо соответствуют данной последовательности шагов. Практические методы выявления классов 1. анализ «существительное/глагол». 2. CRC-анализа. 3. объектный блиц. 1. Выявление классов с помощью анализа «существительное/глагол» • Собираются различные текстовые документы • В документах стараются выделить существительные и глагол. • Существительные и именные группы указывают на классы или атрибуты. • Глаголы и глагольные группы служат признаком обязанностей или операций классов. Выявление классов с помощью анализа «существительное/глагол» (2) • Анализ существительное/глагол успешно применяется в течение многих лет, поскольку основывается на прямом анализе языка предметной области. • Необходимо помнить о синонимах и омонимах, поскольку они могут стать причиной появления ложных классов. Выявление классов с помощью анализа «существительное/глагол» (3) • Надо быть очень осторожными, когда предметная область недостаточно понятна и определена. • В этом случае необходимо попытаться собрать максимум информации об этой области у максимально возможного числа людей, изучить аналогичные предметные области за пределами вашей организации. Выявление классов с помощью анализа «существительное/глагол» (4) • Наверное, самый сложный аспект анализа существительное/глагол – выявление «скрытых» классов. • Это классы, которые свойственны предметной области, но могут никогда не упоминаться явно. – Например, в системе резервирования для компании, занимающейся организацией отдыха, заинтересованные стороны будут говорить о резервировании, бронировании и т. д., но более важная абстракция, Order (Заказ), может вообще не упоминаться открыто, если ее нет в существующих бизнес-системах. Порядок выполнения анализа «существительное/глагол» • Первый шаг – сбор максимально возможный объем относящейся к делу информации. • Второй этап - анализ собранной информации. 1. Сбор документов • Хорошими источниками информации являются: – модель требований; – модель прецедентов; – глоссарий проекта; – различные документы, концепции и т. д. 2. Анализ собранной информации • Выделяются (каким-то способом: вручную, гистограммы встречаемости) следующее: – существительные, например: «рейс»; – именные группы, например: «номер рейса»; – глаголы, например: «разместить»; – глагольные группы, например: «проверить действительность кредитной карточки». Анализа собранной информации • Существительные и именные группы могут служить признаком классов или атрибутов классов. • Глаголы и глагольные группы – обязанностей классов. • Если встретился термин, значение которого осталось непонятным, необходимо проконсультироваться у эксперта в предметной области и добавить этот термин в глоссарий проекта. Составление списка существительных • Составляется списки – список существительных и именных групп, – список глаголов и глагольных групп, • Для разрешения противоречия с синонимами и омонимами используйте глоссарий проекта. – В результате получается список потенциальных классов, атрибутов и операций. • Выполнение предварительного распределения атрибутов и обязанностей по классам. – Сделать это можно, задавая классы и добавляя в них обязанности в качестве операций. • Если были выявлены какие-либо предполагаемые атрибуты, их также можно предварительно распределить по классам. Процедура анализа существительное/глагол • В ходе этого процесса может возникнуть некоторое представление об отношениях между определенными классами (хорошим источником этого являются варианты использования), поэтому можно добавить и некоторые потенциальные ассоциации. • В результате получается модель классов в первом приближении, которая будет уточняться в ходе дальнейшего анализа. 2. Выявление классов с помощью CRC-анализа • Очень хорошим способом привлечения пользователей к процессу выявления классов является применение CRC-анализа • CRC – class-responsibilities-collaborators, классобязанности-участники. • Этот технический прием использует клеящуюся записку (стикер)! • CRC – это техника мозгового штурма, при которой важные моменты предметной области записываются на стикерах. • Использование CRC является одним из первых методов ООА/ООПр, который был разработан в конце 70-х годов. • Они являются вариантом карточек Таблица/Атрибут, которые использовались для определения схем РБД в середине 70-х годов. • Они стали устаревать, когда в начале 80-х годов были разработаны современные системы обозначений для ООА/ООПр. • CRC карточки опять начали активно использоваться при появлении гибких процессов разработки ОО программ в конце 80-х годов. Разметки карточек (стикеров) • Записка делится на три ячейки. – В верхней записывается имя предполагаемого класса, в левой – обязанности, в правой – участники. – Участники – это другие классы, которые могут взаимодействовать с этим классом для реализации функциональности системы. – Ячейка с участниками обеспечивает возможность записи отношений между классами. • Другой способ показать отношения (который мы считаем предпочтительным) – приклеить записки на доску и провести линии между взаимодействующими классами. Порядок выполнения CRC-анализа • CRC анализ выполняется в два этапа – Этап 1: мозговой штурм – сбор информации – Этап 2: анализ информации Этап 1: мозговой штурм – сбор информации • Важнейшей составляющей успеха CRC является привлечение к его проведению всех заинтересованных сторон. • Участники – – специалисты по ОО анализу; – заинтересованные стороны и эксперты. • Кроме того, необходим руководитель – модератор обсуждения. Процедура первого этапа 1. Участникам поясняется, что это настоящий мозговой штурм. 1.1. Все идеи принимаются как хорошие. 1.2. Идеи записываются, но не обсуждаются – никаких споров, просто записывайте идеи и двигайтесь дальше. Все будет анализироваться позже. 2. Участников просят назвать «сущности» их области деятельности, например покупатель, продукт. 2.1. Каждую сущность записывется на клеящуюся записку в качестве предполагаемого класса или атрибута класса. 2.2. Записки приклеиваются на стену или доску. Процедура первого этапа (2) 3. Участников просят сформулировать обязанности предложенных сущностей, которые записываются в разделе «Обязанности» записки. 4. Работая с командой, нужно попытаться установить классы, которые могут работать совместно: – записки на доске перегруппируются в соответствии с предлагаемой организацией классов; – между записками рисуются линии взаимосвязи между классами; • либо эти связи записываются в раздел «Участники» записки. Этап 2: анализ информации • Участники – специалисты по ОО анализу и эксперты ПрО. • Определенные клеящиеся записки будут представлять ключевые бизнес-понятия и, непременно, должны стать классами. • Другие записки могут стать классами или атрибутами. • Если по логике кажется, что записка является частью другой записки, то это верный признак того, что она представляет атрибут. • Кроме того, если записка не кажется особенно важной или не отличается интересным поведением, стоит рассмотреть возможность сделать ее атрибутом другого класса. • Если по поводу записки есть какие-то сомнения, просто сделайте ее классом. • Важно сделать лучшее приближение, а затем довести этот процесс до логического конца. • Всегда можно уточнить модель позже. 3. Объектный блиц (быстрая процедура выявления объектов) • Это наиболее общая форма начального формирования Диаграммы Классов при командной разработке. • Он основан на методе достижения консенсуса, который был разработан для поддержки систематического процесса улучшения (например, Общее Управление Качеством использует варианты такого метода). • Обычно объектный блиц выполняется командой, собранной в одной комнате. Быстрая процедура выявления объектов (объектный блиц) • Обычно объектный блиц выполняется командой, собранной в одной комнате. • Он включает следующие основные шаги: 1. 2. 3. 4. Сбор сущностей-кандидатов без предубеждения. Начальное отсеивание Составление определений Выполнение очистки • Имеются небольшие вариации, но все они включают такие основные шаги. 1. Сбор сущностей-кандидатов без предубеждения • Участники разработки предлагают имена сущностей в режиме свободного потока сознания. • Они просто записываются (например, в виде списка на одной стороне доски) без обсуждения или предубеждения. • На это тратится от 5 до 10 минут прежде чем закончатся предложения от участников. 2. Начальное отсеивание • Каждый кандидат поочередно рассматривается. • Тот кто изначально предложил его делает короткое (13 предложения) пояснение того, что он имел в виду. • Команда кратко обсуждает данную сущность (обычно ограничивается модератором в 1-2 минуты), чтобы определить является ли данный кандидат настолько полезным, как описывается. • Если есть полное согласие (консенсус), что он не является жизнеспособный (релевантным решаемой проблеме), то он отвергается. • Если нет полного согласия отклонить данного кандидата, то он остается кандидатом путем записи его имени на обоих сторонах карточки (карточка, 8 * 13 см.) 3. Составление определений • Для каждого оставшегося кандидата составляется определение. • Обычно лучше передать карточки с этими кандидатами членам команды, которые должны составить для них предварительное определение, которое будет уточняться на дальнейших шагах. – Эти определения должны состоять из 1-3 предложения, которые описывают, что собой представляет данная сущность, без подробностей о том, что она знает и делает. • Лучше всего это должен делать не тот сотрудник, который предложил данную сущность. Т.к. это немедленно покажет новый взгляд на то, что собой данная сущность представляет 4. Выполнение очистки • Каждый кандидат рассматривается поочередно. • Команда оценивает определение и корректирует его до тех пор пока не будет достигнут консенсус. • Целью данной работы является получить общее понимание того, что собой представляет данная сущность и как она связана с решаемой проблемой. • Здесь кандидаты могут быть отвергнуты, если уточнение показало, что они не релевантны решаемой проблеме. • На обсуждение каждого кандидата может затрачиваться по 1-5 минут. • В результате остаются карточки с начальным набором классов для Диаграммы Классов. • Как видно из сделанного описания, объектный Блиц более сфокусирован на классы. • Это связано с тем, что выявление сущностей и их обобщение до классов фактически подсознательно объединяется. • Тем не менее переход от сущностей ПО к классам очень тесно связан с данным процессом. • В результате предыдущих действий получился предварительный отбор классов. • При переходе к выявлению взаимосвязей и сотрудничества между объектами несомненно детали классов будут меняться. • Для того, чтобы избежать «паралича анализа» ограничивается время на разные шаги блица. • Однако требуется иметь каркас для совместной работы, который крепко связан со структурой ПрО. • Достижение консенсуса понимания ПрО является настолько же важным, как и выявление классов и ответственностей. • Объектный блиц активно используем метод достижений консенсуса, чтобы создать такое важное общее понимание. – В частности, он гарантирует, что вся команда понимает ПрО одинаково. • Т.к. диаграмма классов является скелетом (каркасом) на который будет навешиваться разрабатываемое решение, то очень важно, чтобы разрабатывающая его команда имела согласованное понимание семантики данного скелета. • Определения объектов и их ответственностей должны быть достаточно краткими, т.к. документирование ПрО является здесь не самым важным. • Фактически они являются простыми средствами обозначения для более глубокого понимания проблемного пространства. • Такое глубокое понимание получается из участия в дискуссиях, которые создают такие краткие описания. • Для достижения такого понимания необходимо реально участвовать в объектном блице, а не просто читать результаты кого-то, кто в нем участвовал. Лидер команды • Т.к. объектный блиц в основном фокусируется на достижении консенсуса членов команды, то большинство шагов включает командные дискуссии. • Такие дискуссии могут легко заводить в тупик, поэтому для выполнения объектного блица должны соблюдаться некоторые условия: – Должен быть сильный лидер, который может ограничить обсуждение и прекратить разговоры не по делу. – Должны быть способы разрешения тупиковых ситуаций. Задачи лидера команды • Прежде всего, лидер должен заставить команду работать серьезно (по взрослому). • Целью работы является консенсус о том, что является «истиным», с чем все должны жить, а не сведение счетов о том, кто прав, а кто не прав. • Лидер команды должен вмешиваться в личные разборки членов команды, если они возникают. Разрешение тупиковых ситуаций • При проведении дискуссий должны существовать некоторые способы разрешения тупиковых ситуаций, когда консенсус не может быть достигнут. • В конечном счете все связано с потребителем, т.к. ДК предназначена для абстрагирования Проблемного Пространства потребителей. • Поэтому решающее мнение об определении классов и их ответственностей всегда имеет эксперт ПрО. • В идеале желательно, чтобы эксперт ПрО участвовал в Объектном Блице и действовал как третейский судья. • Если эксперта по ПрО нет при обсуждении, то должен быть способ фиксации не решенных проблем, чтобы позже можно было получить отзыв от эксперта по ПрО. Применение вариантов использования • Если имеются ВИ для задания требований к ПрО, то 1 и 4 шаги могут быть изменены, чтобы облегчить работу. • На первом шаге: команда поочередно рассматривает небольшую группу взаимосвязанных ВИ и применяет тот же самый метод «свободного потока сознания» для выявления объектов, которые подходят для реализации набора ВИ. – Члены команды могут фактически называть объекты по мере анализа ими Вариантов Использования. Применение вариантов использования (2) • На четвертом шаге: команда просто использует ВИ в качестве руководства для выявления ответственностей. • Когда данный шаг блица будет выполнен, то можно будет «пройти» по шагам вариантов использования и задать, по крайней мере, одну ответственность объекта, которая участвует в данном шаге ВИ. • Пошаговая обработка не должна создавать проблем, когда разные группы вариантов использования анализируются последовательно. • Базовые сущности, которые абстрагируются, будут оставаться одними и теми же для последующих ВИ. • Если они не релевантны для последующих ВИ, то они для них могут и не рассматриваться. • Если они релевантны для них, то тогда имеется больше причин их абстрагировать. Создание модели анализа в первом приближении • Для создания модель анализа в первом приближении, необходимо в инструментальном средстве моделирования объединить в одну UML-модель результаты анализа. Процесс объединения классов 1. Сравниваются все источники классов. 2. Классы анализа, атрибуты и обязанности, полученные из разных источников, объединяются и вводятся в инструментальное средство моделирования. 1.С помощью глоссария проекта выявляются синонимы и омонимы. 2.Находятся различия в результатах трех методов. Отличия указывают на неопределенности или моменты, требующие более тщательной проработки. Обработайте эти различия сейчас или оставьте это на будущее. 3. Участники представляют отношения между классами. 4. Корректируются имена классов, атрибутов и обязанностей согласно какому-либо стандартному соглашению о присваивании имен, принятому в компании, или в соответствии с простыми соглашениями. • Результатом этой деятельности является набор классов анализа, в котором у каждого класса может быть несколько ключевых атрибутов и должно быть от трех до пяти обязанностей. • Это модель анализа в первом приближении. Процесс выявление ответственностей Процесс выявление ответственностей • Выявление ответственностей очень сходно с выявлением классов, только уменьшен масштаб абстрагирования • Можно пытаться достигать такого же вида командного консенсуса, как и при Объектном Блице, за исключением того, что каждый раз рассматривается только один класс. • Однако это м.б. немного излишним. • Команда уже достигла консенсуса о том, что из себя представляет рассматриваемая сущность, и это предоставляет достаточно крепкую основу для выделения свойств. • Компромиссным подходом м.б. метод аналогичный методу «Объектного блица», но выполняемый несколько более неформальным способом. 1. Для получения предварительных кандидатов для атрибутов и операций, требуемых для решения рассматриваемой проблемы, используется такой же способ «свободного потока сознания», как и в «объектном блице». 2. Предложенные ответственности рассматриваются поочередно, аналогично тому, как это делалось с кандидатами-сущностями в Объектном Блице. – Для контроля корректности определяется, что каждая ответственность за поведение должно знать, и гарантируется, что данное знание имеется в формируемом списке. 3. Создается очень грубая диаграмму последовательности (Sequence diagram) или диаграмм сотрудничества (Communication diagram). • Это только разовые диаграммы, которые просто могут помочь предоставить приблизительный контекст для совместной работы (collaboration). • В основном они описываются просто прямоугольниками, соответствующими каждому классу, которые связываются стрелками для того, чтобы показать непосредственные взаимодействия. • Не требуется пытаться выявить конкретные сообщения. • Просто используйте стрелки между объектами, в виде общего определения ожидаемого сотрудничества, на основе общих знаний содержаний объектов 4. Проход по диаграмме сотрудничества. • Это лучше всего работает с вариантами использования для подситемЮ но может быть выполнено и с просто внешними стимулирующими событиями. • Команда отслеживает путь по диаграмме сотрудничества. И по мере этого решает, какие ответственности из списка к какому объекту будут отнесены. • Эти ответственности и взаимодействия записываются на обратной стороне карточки (8*13 см.), которая была создана на этапе «Объектного блица». 4. Создаются формальные описания атрибутов и ответственностей (операций). Выявление классов путем применения стереотипов • Идея этого метода состоит в том, что в ходе анализа рассматриваются три разных типа классов анализа. • Этот метод позволяет сосредоточить анализ на конкретных аспектах системы. • Мы считаем необязательным использование этого метода. • Его можно применять как дополнение к основным методам анализа: существительное/глагол и CRC-карточки. • Согласно RUP считается полезным поискать классы, которые можно обозначить стереотипами – «boundary» (граница), – «control» (управление) и – «entity» (сущность). • Стереотипами, приведенными в табл., могут быть обозначены три типа классов анализа. • В следующих трех разделах рассматриваются способы выявления каждого из этих типов классов анализа. Выявление классов типа «boundary» • Классы типа «boundary» существуют на границе системы и общаются с внешними актерами. • Такие классы можно обнаружить, рассмотрев контекст системы (границы системы) и выяснив, какие классы являются посредниками между контекстом системы и его окружением. • Согласно UP существует три типа «boundary» (граничных) классов: 1. Классы пользовательского интерфейса – классы, связывающие систему и людей. 2. Классы системного интерфейса – классы, связывающие систему с другими системами. 3. Классы аппаратного интерфейса – классы, связывающие систему с внешними устройствами, например датчиками. Выявление классов типа «boundary» • Каждая связь между актером и прецедентом в модели должна быть представлена некоторым объектом системы. • Эти объекты – экземпляры граничных классов. • Выяснив, кого или что представляет актер, можно определить тип граничного класса. • Таблица – – – – Актер Представляет человека Представляет систему Представляет устройство Указывает на Класс пользовательского интерфейса (GUI) Класс системного интерфейса Класс аппаратного интерфейса • Если граничный класс обслуживает более одного актера, эти актеры должны быть одного типа (представлять человека, систему или устройство). • Если граничный класс обслуживает актеров разных типов, это свидетельствует о плохом проектировании! • Поскольку речь идет о этапе анализа, важно удерживать эти классы на соответствующем уровне абстракции. – Например, при моделировании граничного класса, представляющего GUI, необходимо смоделировать только главное окно. • Детализация всех графических элементов, составляющих окно, должна быть перенесена в фазу проектирования. • Или можно ввести пустой класс, представляющий весь пользовательский интерфейс. • Аналогично и с классами системного и аппаратного интерфейсов. • Главное – зафиксировать факт существования классапосредника между системой и чем-то еще, но не конкретные детали этого класса. • Детали будут рассматриваться позже, при проектировании. – Например, если создается система электронной коммерции, нуждающаяся во взаимодействии с системой Inventory (инвентаризация), то интерфейс для связи с этой системой можно представить классом InventoryInterface, помеченным стереотипом «boundary». • Такой детализации достаточно для модели анализа. Выявление классов типа «control» • Эти классы являются управляющими – их экземпляры координируют поведение системы, соответствующее одному или более прецедентам. • Управляющие классы выявляются при рассмотрении поведения системы, описанного прецедентами, и выработке решения о том, как это поведение должно быть разделено между классами анализа. • Простое поведение часто можно распределить между граничными классами или классамисущностями. • Но более сложное поведение, такое как обработка заказов, лучше обозначить, добавив соответствующий управляющий класс, например OrderManager (менеджер заказов). • Некоторые разработчики моделей (включая и нас!) часто обозначают управляющий класс, дополняя его имя словами Manager или Controller. Выявление классов типа «control» • Главное при работе с управляющими классами – они должны естественным образом проистекать из самой предметной области. • Некоторые разработчики моделей искусственно вводят управляющие классы для каждого прецедента, чтобы управлять или выполнять этот прецедент. • Это опасный подход, в результате которого получается модель, больше похожая на прямую функциональную декомпозицию, чем на настоящую ОО аналитическую модель. • По сути, это одна из причин, по которой мы считаем использование стереотипов необязательным. • Они могут сбить с толку начинающих разработчиков моделей! • В реальности контроллеры, вытекающие непосредственно из предметной области (а не появляющиеся как побочный продукт определенной техники анализа), обычно охватывают несколько вариантов использования (прецедентов). • Удачным примером контроллера является класс Registrar (регистратор). • Он задействован во многих прецедентах, описывающих систему регистрации курса. • Аналогично одному прецеденту может требоваться участие нескольких управляющих классов. • Если управляющий класс обладает очень сложным поведением, это говорит о том, что, вероятно, его можно разбить на два или более простых контроллера, реализующих связную часть этого поведения. • Каждый из получившихся простых классов должен по-прежнему представлять что-то, что реально имеет место в предметной области. • Например, при проектировании системы регистрации курса сначала может быть введен управляющий класс CourseRegistrationController (контроллер регистрации курса), координирующий весь процесс. • Но поведение такого класса очень сложное, поэтому его можно разбить на ряд взаимодействующих классов, каждый из которых будет отвечать за один-два аспекта этого поведения. • Класс можно было бы разложить на классы Registrar, CourseManager (менеджер курсов) и PersonnelManager (менеджер персонала). • Обратите внимание, что каждый из этих классов представляет реальную сущность предметной области. • Хороший способ проанализировать управляющие классы – представить себя в роли такого класса. Выявление классов типа «entity» • Эти классы моделируют информацию о чемто и обычно имеют очень простое поведение, состоящее практически только в получении и задании значений. • Классы, представляющие постоянную информацию, например адреса (класс Address) и людей (класс Person), являются классамисущностями. • Классы-сущности: – – – – пересекают несколько прецедентов; с ними оперируют управляющие классы; предоставляют и принимают информацию от граничных классов; представляют ключевые сущности, которыми управляет система (например, Customer); – часто являются постоянными (persistent). • Классы-сущности выражают логическую структуру данных системы. • Если есть модель данных, классы-сущности тесно связаны с сущностями или таблицами этой модели.
