Конспект лекций, страница 13

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

Образец представляет собой4типичное решение некоторой проблемы в заданном контексте. Каркас являетсяархитектурным образцом, определяющим шаблон для приложений в конкретной области.Примеры архитектурных образцов: Уровни (Layers) – способ декомпозиции приложения на набор слоев, соответствующихразличным уровням абстракции. Модель-представление-управление (Model-view-controller, M-V-C) – разделениеприложения на три части: данные и бизнес-правила; пользовательское представление;обработку данных. Каналы и фильтры (Pipes and filters)– шаблон архитектуры системы дляпотоковой обработки данных.Layers:Прикладной уровень – реализацияфункциональностивариантовиспользования.Бизнес-уровень – набор компонентов,специфичныхдляконкретнойпредметной области.Middleware – платформо-независимыесервисы (GUI, ORB, …)Systemsoftware–ПОдлявычислительнойисетевойинфраструктуры(ОС,сетевыепротоколы и др.)Образец «Каналы и фильтры»решает следующую проблему: Нужнообеспечитьпреобразованиенепрерывных потоков данных.

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

Проблема: Изменения вовнешнем представлении достаточно вероятны, одна и та же информацияпредставляется по-разному в нескольких местах, система должна быстро реагироватьна изменения данных. Решение: выделить набор компонентов 3-х типов: компонентовхранения данных, компонентов представления для пользователей, и компонентовобработки (воспринимающих команды, преобразующих данные и обновляющихпредставления):5ClientControllerModelViewсобытиеизменить данныеоповеститьобновлениеполучить данныеотобразитьобновлениеполучить данныеРис. Один из вариантов организации взаимодействия, предписываемый образцомMVC.Надо заметить, что при указанном взаимодействии объекты модели отвечают нетолько за хранение данных как таковое, но и за оповещение всех подписчиков обизменениях данных.

Такая дополнительная нагрузка неоднозначно оценивается разнымиэкспертами, например, Мартин Фаулер считает это решение неудачным и предлагаетдругое, в котором оповещение возлагается на объекты управления::Управление:Представление:Пользователь:МодельВ такой схеме достигается независимость модели от представления,обеспечивающая больше возможностей для повторного использования.Анализ вариантов использования выполняется проектировщиками и включает в себя: идентификацию классов, участвующих в реализации потоков событий, (такназываемых, классов анализа); определение обязанностей классов, их атрибутов и ассоциаций; унификацию классов анализа; квалификацию механизмов анализа.6Анализ вариантов использования является итерационным процессом – делится нанесколько итераций в ходе которых работа ведется над одни или несколькими (но невсеми сразу) вариантами использования.

Как правило, распределение вариантовиспользованияпоитерациямосуществляетсянаосновеихприоритета(высокоприоритетные раньше, низкоприоритетные позже).Шаги анализа вариантов использования:1. Уточнение и дополнение описаний вариантов использования.2. Для каждой реализации варианта использования:a. Выявление классов, участвующих в реализации потоков событий вариантаиспользования.b.

Распределение поведения, реализуемого вариантом использования, междуклассами (обязанности классов).3. Для каждого выявленного класса анализа:a. Определение обязанностей класса.b. Определение атрибутов и ассоциаций.c. Квалификация механизмов анализа.4. Унификация классов анализа.Классы анализа отражают функциональные требования к системе и моделируютобъекты предметной области. Совокупность классов анализа представляет собойначальную концептуальную модель системы. Эта модель проста и позволяетсосредоточиться на реализации функциональных требований, не отвлекаясь на деталиреализации, обеспечение эффективности и надежности. Для решения этих вопросовготовая модель анализа трансформируется в проектную модель в ходе проектирования.В потоках событий варианта использования выявляются классы трех типов: граничные классы, являющиеся посредниками при взаимодействии с внешнимиобъектами; классы-сущности, представляющие собой основные абстракции (понятия)разрабатываемой системы; управляющие классы, обеспечивающие координацию поведения объектов в системе.Правило выделения граничных классов: для каждой связи между действующимлицом и вариантом использования создается граничный класс, отвечающий за данноевзаимодействие.

Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей UI –кнопок, списков, окон);7системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталейих реализации).StudentRegister for CoursesCourse Catalog<<boundary>>RegisterForCoursesForm<<boundary>>CourseCatalogSystemСпособы выделения классов-сущностей: Перевод бизнес-сущностей из бизнес-модели в классы-сущности. Анализ глоссария (некоторые термины являются именами искомых классовсущностей). Анализ описаний вариантов использования.Правило выделения управляющих классов: для каждого варианта использованиясоздается ответственный за его реализацию класс управления.StudentRegister for CoursesCourse Catalog<<control>>RegistrationControllerВсе созданные при анализе данного варианта использования классы анализапомещаются на диаграмму VOPC (View Of Participating Classes).Распределение поведения, реализуемого вариантом использования, между классамиреализуется с помощью диаграмм взаимодействия (диаграмм последовательности икооперативных диаграмм).

Виды обязанностей классов: Знание:o наличие информации о данных или вычисляемых величинах;o наличие информации о связанных объектах. Действие:o выполнение некоторых действий самим объектом;o инициация действий других объектов;8o координация действий других объектов.Sequence DiagramsUse CaseCollaboration DiagramsUse-Case RealizationВ процессе анализа конкретного варианта использования в первую очередь строитсядиаграмма последовательности, описывающая основной поток событий и егоподчиненные потоки. Для каждого альтернативного потока событий строится отдельнаядиаграмма последовательности.Обязанности каждого класса определяются, исходя из сообщений на диаграммахвзаимодействия, и документируются в классах в виде «операций анализа».

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