Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование

Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 37

Описание файла

PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "книги и методические указания". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 37 страницы из PDF

Даже если ничего не будет выявлено, это заостряет внимание на некоторых серьезных вопросах и улучшает понимание предметной области.188Глава 8. Выявление классов анализа8.4.1.1. Процедура анализа существительное/глаголПервый шаг в анализе существительное/глагол – собрать максимально возможный объем относящейся к делу информации. Хорошими источниками информации являются:• модель требований;• модель прецедентов;• глоссарий проекта;• чтолибо еще (архитектура, документыконцепции и т.

д.).После сбора документации проводится ее анализ. Делается это оченьпросто: выделяется (или регистрируется какимлибо иным способом)следующее:• существительные, например рейс;• именные группы, например номер рейса;• глаголы, например размещать;• глагольные группы, например проверить действительность кредитной карточки.Существительные и именные группы могут служить признаком классов или атрибутов классов. Глаголы и глагольные группы – обязанностей классов.Если встретился термин, значение которого осталось непонятным, необходимо незамедлительно проконсультироваться у эксперта в предметной области и добавить этот термин в глоссарий проекта. Составьтесписок существительных, именных групп, глаголов и глагольныхгрупп, используйте глоссарий проекта, чтобы разрешить противоречия с синонимами и омонимами. Результатом этого должен стать список потенциальных классов, атрибутов и обязанностей.После создания такого списка производится предварительное распределение атрибутов и обязанностей по классам.

Сделать это можно, вводя классы в средство моделирования и добавляя в них обязанностив качестве операций. Если были выявлены какиелибо предполагаемыеатрибуты, их также можно предварительно распределить по классам.В ходе этого процесса может возникнуть некоторое представление оботношениях между определенными классами (прецеденты – хорошиеисточники этого), поэтому можно добавить и коекакие потенциальныеассоциации. В результате получается модель классов в первом приближении, которая будет уточняться в ходе дальнейшего анализа.8.4.2.

Выявление классов с помощью CRCанализаОчень хорошим (и забавным) способом привлечения пользователейк процессу выявления классов является применение CRCанализа(CRC – classresponsibilitiescollaborators, классобязанностиучастники).

Этот технический прием использует самый мощный в мире инст1898.4. Выявление классоврумент анализа – клеящуюся записку (стикер)! CRCметод настолькопопулярен, что говорят (может быть, это выдумки), что в какойто момент компания, торгующая стикерами, стала выпускать их уже с разметкой для имени класса, обязанностей и участников.CRC – это техника мозгового штурма, при которой важные моментыпредметной области записываются на стикерах.Начинаем с разметки стикеров, как показано на рис. 8.4.

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

8.4. Разметка стикера8.4.2.1. Процедура CRCанализаЕсли это не совсем простая система, CRCанализ должен всегда использоваться в сочетании с анализом существительное/глагол прецедентов, требований, глоссария и другой относящейся к делу документации. Процедура CRCанализа проста. Ее основная идея – рассортировать данные, поступающие в результате анализа информации. Поэтой причине CRCанализ лучше проводить в два этапа.8.4.2.2.

Этап 1: мозговой штурм – сбор информацииПривлечение заинтересованных сторон – важнейшая составляющаяуспеха CRC.Участники – ОО аналитики, заинтересованные стороны и эксперты.Кроме того, необходим руководитель. Процедура первого этапа сводится к следующему:1. Объясните участникам, что это настоящий мозговой штурм.190Глава 8. Выявление классов анализа1.1.

Все идеи принимаются как хорошие.1.2. Идеи записываются, но не обсуждаются – никаких споров,просто записывайте идеи и двигайтесь дальше. Все будет анализироваться позже.2. Попросите членов команды назвать «сущности» их области деятельности, например покупатель, продукт.2.1. Каждую сущность запишите на клеящуюся записку в качествепредполагаемого класса или атрибута класса.2.2. Приклейте записку на стену или доску.3. Попросите команду сформулировать обязанности этих сущностей,запишите их в ячейке обязанностей записки.4. Работая с командой, попытайтесь установить классы, которые могут работать совместно. Перегруппируйте записки на доске соответственно такой организации классов и нарисуйте линии между ними.

В качестве альтернативы впишите имена участников в соответствующую ячейку записки.8.4.2.3. Этап 2: анализ информацииВажные бизнеспонятия обычно становятся классами.Участники – ОО аналитики и эксперты. Как определить, какие изклеящихся записок должны стать классами, а какие – атрибутами?Вернемся к разделу 8.3.2: классы анализа должны представлять четкую абстракцию предметной области. Определенные клеящиеся записки будут представлять ключевые бизнеспонятия и, непременно,должны стать классами. Другие записки могут стать классами или атрибутами. Если по логике кажется, что записка является частью другой записки, то это верный признак того, что она представляет атрибут. Кроме того, если записка не кажется особенно важной или не отличается интересным поведением, стоит рассмотреть возможностьсделать ее атрибутом другого класса.Если по поводу записки есть какието сомнения, просто сделайте ееклассом.

Важно сделать лучшее приближение, а затем довести этотпроцесс до логического конца. Всегда можно уточнить модель позже.8.4.3. Выявление классов путем применениястереотипов RUPИз RUP был заимствован метод стереотипов. Идея этого метода состоит в том, что в ходе анализа рассматриваются три разных типа классаанализа. Этот метод позволяет сосредоточить анализ на конкретныхаспектах системы. Мы считаем необязательным использование этогометода. Его можно применять как дополнение к основным методаманализа: существительное/глагол и CRCкарточки.1918.4.

Выявление классовСогласно RUP считается полезным поискать классы, которые можно обозначить стереотипами «boundary» (граница), «control» (управление)и «entity» (сущность).Стереотипами, приведенными в табл. 8.1, могут быть обозначены тритипа классов анализа.В следующих трех разделах рассматриваются способы выявления каждого из этих типов классов анализа.Таблица 8.1Стереотип ПиктограммаСемантика«boundary»Класс, который является посредником во взаимодействии между системой и ее окружением.«control»Класс, инкапсулирующий характерное для прецедента поведение.«entity»Класс, используемый для моделирования постоянной информации о чемто.8.4.3.1.

Выявление классов типа «boundary»Классы типа «boundary» существуют на границе системы и общаютсяс внешними актерами.Такие классы можно обнаружить, рассмотрев контекст системы (границы системы) и выяснив, какие классы являются посредниками между контекстом системы и его окружением. Согласно RUP существуеттри типа «boundary» (граничных) классов:1. Классы пользовательского интерфейса – классы, связывающие систему и людей.2. Классы системного интерфейса – классы, связывающие системус другими системами.3.

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

Если граничный класс обслуживает актеров разных типов,это свидетельствует о плохом проектировании!192Глава 8. Выявление классов анализаТаблица 8.2АктерУказывает наПредставляет человекаКласс пользовательского интерфейса (GUI)Представляет системуКласс системного интерфейсаПредставляет устройствоКласс аппаратного интерфейсаПоскольку речь идет о фазе анализа, важно удерживать эти классы насоответствующем уровне абстракции.

Например, при моделированииграничного класса, представляющего GUI, необходимо смоделироватьтолько главное окно. Детализация всех графических элементов, составляющих окно, должна быть перенесена в фазу проектирования.Или можно ввести пустой класс, представляющий весь пользовательский интерфейс.Аналогично и с классами системного и аппаратного интерфейсов.Главное – зафиксировать факт существования классапосредника между системой и чемто еще, но не конкретные детали этого класса. Детали будут рассматриваться позже, при проектировании.Например, если создается система электронной коммерции, нуждающаяся во взаимодействии с системой Inventory (инвентаризация), тоинтерфейс для связи с этой системой можно представить классомInventoryInterface, помеченным стереотипом «boundary». Такой детализации достаточно для аналитической модели.8.4.3.2.

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

Свежие статьи
Популярно сейчас