Проектирование классов и взаимодействия

Содержание

Слайд 2

Проектирование ПО. Проектирование классов и взаимодействия Проектирование классов и взаимодействия Проектирование

Проектирование ПО. Проектирование классов и взаимодействия

Проектирование классов и взаимодействия

Проектирование классов –

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

Проектирование классов начинается с идентификации классов (и интерфей­сов) и с их распределения по пакетам. Далее, модели взаимодействия определяют особенности классов и в первую очередь операций класса.
Классы должны иметь обязанности выполнять определенные функции. При проектировании классов происходит распределение обязанностей (responsibilities).
Проектирование взаимодействия обеспечивает: проверку существующих классов и дальнейшую их детализацию. В частнос­ти, определяются сигнатуры операций классов.
Результатом этого этапа будут диаграммы классов и диаграммы взаимодействия (последовательности и коммуникации).

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

Слайд 3

Проектирование ПО. Проектирование классов и взаимодействия Распределение обязанностей (responsibilities) Класс, ко­торый

Проектирование ПО. Проектирование классов и взаимодействия

Распределение обязанностей (responsibilities)

Класс, ко­торый имеет соответствующие

данные, должен и выполнять соответствую­щие обязанности.
Если все данные находятся в одном классе, проблема реше­на.
Если данные распределены по нескольким классам, возможны следующие ре­шения:
Поместить обязанности в один класс (часто в класс-представление) и делегировать части работы другим классам, содержащим данные.
Создать класс «третьего лица» (часто класс пакета control — управление или mediator — посредник), назначить ему обязанности и при необходимости заставить его делегировать части работы другим классам.
Использовать существующий класс как класс «третьего лица»
Слайд 4

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

Проектирование ПО. Проектирование классов и взаимодействия

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

Классы

должны обеспечивать поведение, указанное в функциональных требо­ваниях спецификации вариантов использования.
Определение клас­сов включает выделение этих требо­ваний и выбор классов и их совместной работы, необ­ходимых для выполнения этих требований.
Концептуальные классы, которые определяют бизнес-объекты в БД, дол­жны быть выделены заранее. Концептуальные классы станут в проекте классами пакета entity (сущность).
Классы должны строго соответствовать структурному шаблону, выбранному для системы. Для начальных итераций иногда достаточно одного класса на пакет (например, для пакетов control и mediator).
Слайд 5

Проектирование ПО. Проектирование классов и взаимодействия PCMEF+ пред­ставление управление посредник сущность основание + знакомство

Проектирование ПО. Проектирование классов и взаимодействия

PCMEF+

пред­ставление
управление
посредник
сущность
основание
+
знакомство

Слайд 6

Проектирование ПО. Проектирование классов и взаимодействия Определение классов из требований для управления электронной почтой

Проектирование ПО. Проектирование классов и взаимодействия

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

электронной почтой
Слайд 7

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

Проектирование ПО. Проектирование классов и взаимодействия

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

Слайд 8

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

Проектирование ПО. Проектирование классов и взаимодействия

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

Слайд 9

Проектирование ПО. Проектирование классов и взаимодействия Проектирование исходных классов для управления

Проектирование ПО. Проектирование классов и взаимодействия

Проектирование исходных классов для управления электронной

почтой

Модель включает ассоциации между сотрудничающими классами.
Соглас­но PCMEF-структуре все ассоциации являются нисходящими.
Большинство ассоциаций могло бы быть выявлено из сотрудничества, непосредственно ви­димого в таблице. Однако в связи с тем, что таблица не показывает по­шаговую передачу сообщений, некоторые виды сотрудничества (которые есть в таблице), по-видимому, имеющиеся между несоседними пакетами, удалены из PCMEF-структуры.

Слайд 10

Проектирование ПО. Проектирование классов и взаимодействия Константы в интерфейсе Интерфейс —

Проектирование ПО. Проектирование классов и взаимодействия

Константы в интерфейсе

Интерфейс — удобный способ

хранения констант. Элементы данных в интерфейсе, в противоположность UML-интерфейсу, не­явно заданы как public (внешний), static (статический) и final (заключитель­ный). Следовательно, они являются константами.

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

Слайд 11

Проектирование ПО. Проектирование классов и взаимодействия Структурная разработка проекта классов Классы

Проектирование ПО. Проектирование классов и взаимодействия

Структурная разработка проекта классов

Классы (и интерфейсы)

должны удовлетворить структурным ограничениям, накладываемым структурным шаблоном, выбранным для проекта. Ограниче­ния включают нефункциональные требования (FURPS+), определенные в документе дополнительной спецификации.
Структурные ограничения задают требования к разработке исходного проекта классов.
Разработка проекта на основе структурных требований завершается моди­фикациями и дополнениями к классам, определенным из требований пользо­вателя.
Поэтому процесс может начаться с таблицы, используемой для опре­деления классов, на основании требований сценария использования, и затем таблица должна быть расширена, чтобы включить столбцы, которые пред­ставляют модификации и дополнения.
Слайд 12

Проектирование ПО. Проектирование классов и взаимодействия Структурная разработка проекта классов для управления электронной почтой

Проектирование ПО. Проектирование классов и взаимодействия

Структурная разработка проекта классов для управления

электронной почтой
Слайд 13

Проектирование ПО. Проектирование классов и взаимодействия Уточнение классов

Проектирование ПО. Проектирование классов и взаимодействия

Уточнение классов

Слайд 14

Проектирование ПО. Проектирование классов и взаимодействия Уточнение классов

Проектирование ПО. Проектирование классов и взаимодействия

Уточнение классов

Слайд 15

Проектирование ПО. Проектирование классов и взаимодействия Уточнение классов

Проектирование ПО. Проектирование классов и взаимодействия

Уточнение классов

Слайд 16

Проектирование ПО. Проектирование классов и взаимодействия Классы после структурной проработки Результаты

Проектирование ПО. Проектирование классов и взаимодействия

Классы после структурной проработки

Результаты таблицы 2

приводят к созданию улучшенной модели клас-сов.
К модели до­бавлен пакет entity. Пакеты entity и mediator составляют пакет domain (предмет-ная область) как один из PCMEF-слоёв.
Пакет acquaintance имеет три новых интерфейса, реализован-ные классами в пакете entity. Новые операции, определенные во время структурной проработки, показаны в соответству-ющих классах.
Слайд 17

Проектирование ПО. Проектирование классов и взаимодействия Инициализация классов Результатом структурной проработки

Проектирование ПО. Проектирование классов и взаимодействия

Инициализация классов

Результатом структурной проработки является определение

классов, ответственных за создание новых экземпляров других классов. Другими словами, кто должен послать сообщение методу-конструктору другого класса, чтобы инициализировать новый объект этого класса.
Классы в более высоких слоях могут инициализировать классы в (соседних) более низких слоях, но не наоборот.
Первый объект должен быть инициализирован в начале программы. На­чальная точка компьютерной программы находится в главном методе. Главный метод инициализирует первый объект — это объект класса, который содержит главный метод.
Java требует массив объ­ектов String в качестве аргумента метода main. Пара­метр args содержит аргументы, если таковые вообще имеются, помещаемые в командную строку при запуске программы.
Класс, содержащий метод main, находится в пакете presentation и называется PMain.

Показать, кто создает новые экземпляры других классов можно, рисуя отношения зависимости между классами со стереотипом «instantiate» (инициализация).

Слайд 18

Проектирование ПО. Проектирование классов и взаимодействия Диаграмма инициализации Когда класс А

Проектирование ПО. Проектирование классов и взаимодействия

Диаграмма инициализации

Когда класс А инициализи-рует класс

В, объекту А необходима ссылка на объект В. Если эта ссылка в будущем должна использоваться для передачи сообщений от А до В (как часто и бывает), то должна быть установлена однонаправ-ленная связь ассоциации.
Рисунок изображает диа-грамму инициализации для управления электрон­ной почтой. Связи ассоциации не смодели-рованы.
Слайд 19

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействия Взаимодействие (Interaction) - это

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействия

Взаимодействие (Interaction) - это поведение, которое

со­средоточено на наблюдаемом обмене информацией между объектами, существующими во время взаимодействия

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

Слайд 20

Проектирование ПО. Проектирование классов и взаимодействия Диаграммы последовательности Диаграмма последовательности (sequence)

Проектирование ПО. Проектирование классов и взаимодействия

Диаграммы последовательности

Диаграмма последовательности (sequence) показывает упорядоченный

во времени обмен сообщениями между объектами (partName : ClassName [multiplicity]) в процессе взаимодействия.

Областью вза-имодействия может быть вариант ис-пользова­ния, часть его, ряд вариантов использования, от-дельное требова-ние, действие поль-зователя и т. д.

Слайд 21

Проектирование ПО. Проектирование классов и взаимодействия Структурированные управляющие конструкции Комбинированный фраг­мент

Проектирование ПО. Проектирование классов и взаимодействия

Структурированные управляющие конструкции

Комбинированный фраг­мент (combined fragment)

состоит из ключевого слова и одного или несколь-ких вложенных фраг-ментов:
ref – ссылка на другое взаи­модействие;
loop – цикл;
alt – условный фраг-мент;
opt – условный фраг-мент с одним вложен-ным фрагментом;
par – параллельно вы-полняющиеся фраг-менты.
Слайд 22

Проектирование ПО. Проектирование классов и взаимодействия Диаграммы последовательности

Проектирование ПО. Проектирование классов и взаимодействия

Диаграммы последовательности

Слайд 23

Проектирование ПО. Проектирование классов и взаимодействия Диаграммы коммуникации Диаграммы коммуникации (сommunication)

Проектирование ПО. Проектирование классов и взаимодействия

Диаграммы коммуникации

Диаграммы коммуникации (сommunication) могут быть

более полезны для анализа сообщений от(к) конкретного(му) объекта(у). Они могут быть более удобны при изображении исходного проекта взаимодействий и выполнения «итеративного» моделиро­вания.
Слайд 24

Проектирование ПО. Проектирование классов и взаимодействия Диаграмма обзора взаимодействия (interaction overview

Проектирование ПО. Проектирование классов и взаимодействия

Диаграмма обзора взаимодействия (interaction overview diagram)

является

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

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

Слайд 25

Проектирование ПО. Проектирование классов и взаимодействия Диаграмма синхронизации (timing diagram)

Проектирование ПО. Проектирование классов и взаимодействия

Диаграмма синхронизации (timing diagram)

Слайд 26

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействия для управления электронной почтой

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействия для управления электронной почтой

«удачный путь»

взаимодействия:
регистрационное имя (login);
выход (exit);
просмотр непосланных сообщений (view unsent messages);
отображение текста сообщения (display message text);
передача сообщения по электронной почте (email message);
«неудачный путь» взаимодействия:
неправильное имя пользователя или неправильный пароль (incorrect username or password);
неправильная опция (incorrect option);
слишком много сообщений (too many messages);
сообщение не может быть послано по электронной почте (email could not be sent).
Слайд 27

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Регистрационное имя»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Регистрационное имя»

Слайд 28

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Выход» (Exit)

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Выход» (Exit)

Слайд 29

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Просмотр сообщений»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Просмотр сообщений»

Слайд 30

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Отображение текста»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Отображение текста»

Слайд 31

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Отсылка сообщения»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Отсылка сообщения»

Слайд 32

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Неправильное имя пользователя или пароль»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Неправильное имя пользователя или пароль»

Слайд 33

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Неправильная опция»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Неправильная опция»

Слайд 34

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Слишком много сообщений»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Слишком много сообщений»

Слайд 35

Проектирование ПО. Проектирование классов и взаимодействия Взаимодействие «Сообщение не может быть послано по электронной почте»

Проектирование ПО. Проектирование классов и взаимодействия

Взаимодействие «Сообщение не может быть послано

по электронной почте»
Слайд 36

Проектирование ПО. Проектирование классов и взаимодействия Резюме Проектирование классов и проектирование

Проектирование ПО. Проектирование классов и взаимодействия

Резюме

Проектирование классов и проектирование взаимодействия должны

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

Похожие презентации

Петербург театральный, музыкальный и мир кино Вторая половина XIX века
Vorbereitung für die Kontrollarbeit
Презентация на тему "Соотношение ключевых компетенций с общеучебными умениями и навыками" - скачать презентации по Педагогик
Особенности обмена АК
С активной и трансформаторомt
Р.Р. Васнецов Богатыри
Цикл статей Зигмунда Фрейда «Мойсей і монотеїзм»
Научный стиль
Заболеваемость населения
Сечения
Правила оформления чертежей
Презентация на тему "Модель современного учителя: проблемы, поиски, решения" - скачать презентации по Педагогике
Общие сведения о системах автоматики, телемеханики, связи, вычислительной и космической технике
Новости в Молдове
Ходовая часть автомобилей
Нуклеиновые кислоты: виды, принципы строения, биологическая роль
Увеличение производительности погружения железобетонных свай дизельными молотами
Халықаралық сауда тәжірибесіндегі халықаралық есепайырысулар және сақтандыру
Алгоритмы планирования
Презентация Правовые основы государственной службы в РФ
Lucid Disassembly SSD SOP 1202
Понятие об имени прилагательном - презентация для начальной школы
Проездные документы и посадка пассажиров
Механика грунтов. Свойства и характеристики грунтов. (Лекция 2)
Базалыќ жартылай ґткізгішті ќўралдар. Шала ґткізгіш диодтар (ШҐД)
Создание 3D модели гайки накидной
Наурыз мейрамы
«Гармония». Адаптивная физическая культура
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть