Проектирование ПО
Тема 7. Проектирование классов и взаимодействия
6/27/19 |
ИГЭУ. Кафедра ПОКС |
Проектирование классов и взаимодействия
Проектирование классов и проектирование взаимодействия на практике происходит параллельно,
поскольку эти процессы тесно связаны.
поведения, заданного в модели вариантов использования при соответствии структурному шаблону, выбранному для
системы.
Проектирование классов начинается с идентификации
классов (и интерфейсов) и с их распределения по пакетам. Далее, модели взаимодействия определяют особенности
классов и в первую очередь операций класса.
Классы должны иметь обязанности выполнять определенные функции. При проектировании классов происходит распределение обязанностей (responsibilities).
Проектирование взаимодействия обеспечивает: проверку существующих классов и дальнейшую их
детализацию. В частности, определяются сигнатуры операций классов.
Результатом этого этапа будут диаграммы классов и
диаграммыПроекти ование ПО. Проектированиевзаимодействиякла ов и взаимодействия(последовательности 2и
коммуникации).
Распределение обязанностей (responsibilities)
Класс, который имеет соответствующие данные, должен
и выполнять соответствующие обязанности.
Если все данные находятся в одном классе, проблема решена.
Если данные распределены по нескольким классам, возможны следующие решения:
•Поместить обязанности в один класс (часто в класс- представление) и делегировать части работы другим классам, содержащим данные.
•Создать класс «третьего лица» (часто класс пакета control
— управление или mediator — посредник), назначить ему
обязанности и при необходимости заставить его делегировать части работы другим классам.
•Использовать существующий класс как класс «третьего
лица» |
3 |
Проектирование ПО. Проектирование классов и взаимодействия |
Определение классов из требований варианта использования
Классы должны обеспечивать поведение, указанное в
функциональных требованиях спецификации вариантов использования.
Определение классов включает выделение этих требо ваний и выбор классов и их совместной работы, необходимых для выполнения этих требований.
Концептуальные классы, которые определяют бизнес- объекты в БД, должны быть выделены заранее. Концептуальные классы станут в проекте классами пакета entity (сущность).
Классы должны строго соответствовать структурному шаблону, выбранному для системы. Для начальных итераций иногда достаточно одного класса на пакет (например, для пакетов control и mediator).
Проектирование ПО. Проектирование классов и взаимодействия |
4 |
PCMEF+
пред
ставление
управлени
е
посредник
сущность
основание
+
знакомство
5
Определение классов из требований для управления электронной почтой
|
|
|
|
Сопутствую |
|
№ |
Определение требования |
Имя класса |
Имя |
щий класс |
|
тр. |
операции |
или |
|||
|
|
||||
R1 |
Система отображает информационное |
PConsole |
displayLogin |
интерфейс |
|
PConsole |
|||||
|
сообщение и запрашивает, чтобы служащий |
|
getUserInput |
CActioner |
|
|
ввел имя и пароль |
CActioner |
login |
FConnection |
|
R2 |
|
||||
Система пытается связать служащего с БД ЕМ FConnection getConnection lAConstants, |
|||||
|
|
FReader |
readEmployee |
FReader |
|
R3 |
После успешной связи приложение |
|
|||
PConsole |
displayMenu |
|
|||
|
отображает список возможных опций меню, |
|
|
|
|
R4 |
которые служащий может запросить |
|
getUserlnput |
CActioner |
|
Если служащий выберет выход из ЕМ-приложе PConsole |
|||||
|
ния, нажав 4, сценарий использования |
|
|
|
|
R5 |
завершается |
CActioner |
exit |
Fconnection |
|
S1 — View Unsent Messages (просмотр |
PConsole |
getUserlnput |
PConsole |
||
|
непосланных сообщений): информация |
|
viewMessages lAConstants, |
||
|
отображается в консольном окне |
|
|
MBroker |
|
|
|
MBroker |
retrieveMessa |
FReader |
|
|
|
|
ges |
|
|
FReader
readMessages readContact
Определение классов из требований
№ |
Определение требования |
|
тр. |
||
|
R6 S2 — Display Text of a Message (отображение текста сообщения): служащий вводит message_id. Текст сообщения отображается
на экране
R7 S3 — Email a Message (передача сообщения по электронной почте): служащий задает message_id сообщение, которое следует передать по электронной почте. Служащий вводит message_id, сообщение отсылается и корректируется БД
R8 S3 — Email a Message: информационное сообщение отображается в консольном окне
после успешной передачи сообщения R9 E1 — Incorrect username or password
(неправильное имя пользователя или неправильный пароль): если в основном потоке актёр вводит неправильное имя или пароль, система выводит сообщение об ошибке. Система разрешает актёру повторно
ввести имя пользователя и пароль, либо
|
|
Сопутствую |
|
Имя класса |
Имя |
щий класс |
|
операции |
или |
||
|
|||
PConsole |
getUserlnput |
интерфейс |
|
PConsole |
|||
|
displayMessag MBroker |
||
|
eText |
|
|
PConsole |
getUserlnput |
PConsole |
|
|
prepareMessa |
CActioner |
|
CActioner |
ge |
MAPI, |
|
|
sendMessage |
lAConstants, |
|
FWriter |
|
FWriter |
|
updateMessag |
|
||
|
|
||
PConsole |
e |
|
|
displayConfir |
|
||
|
mation |
|
|
ref. R1 |
|
PConsole |
|
PConsole |
displayLoginEr ref. R1, |
||
|
ror |
CActioner |
|
Cactioner |
exit |
FConnection |
|
|
|
||
Определение классов из требований
№
тр.
R1
0
R1
1
R1
2
Определение требования
E2 — Incorrect option (неправильная опция): если актёр выберет неправильную опцию, система игнорирует введенное значение и заново показывает список опций. Если будут подряд три неудачных выбора, система прекращает работу с актёром и повторно начинает сценарий использования
(запрашивая имя)
ЕЗ — Too many messages (слишком много сообщений): если в подпотоке S1 число непосланных сообщений превышает заранее установленное число, система отображает сообщение о том, что в БД имеется большее количество сообщений, чем допустимо. Сообщение отображается после того, как актёру показывается установленное число сообщений, и перед тем, как будет заново
показан список меню.
Е4 — Email could not be sent (сообщение электронной почты не может быть послано): если в подпотоке S3 почтовый сервер
возвращает ошибку о том, что сообщение не
Имя класса
PConsole
CActioner ref. R1
ref. R5 PConsole
ref. R7 CActioner
PConsole
Сопутствую Имя щий класс
операции или
интерфейс getUserlnput PConsole
displayMenu
logout FConnection
tooManyMess ages
handleEmailEx ception
displayEmailF PConsole
Проектирование исходных классов для управления электронной почтой
Модель включает ассоциации между сотрудничающими классами.
Согласно PCMEF-структуре все ассоциации являются нисходящими.
Большинство ассоциаций могло бы быть выявлено из сотрудничества, непосредственно видимого в таблице. Однако в связи с тем, что таблица не показывает по шаговую передачу сообщений, некоторые виды сотрудничества (которые есть в таблице), по-видимому, имеющиеся между несоседними пакетами, удалены из PCMEF-структуры.
взаимодействия |
9 |
Константы в интерфейсе
Интерфейс — удобный способ хранения констант. Элементы данных в интерфейсе, в противоположность UML-
интерфейсу, неявно заданы как public (внешний), static (статический) и final (заключительный). Следовательно, они являются константами.
Поскольку интерфейс не имеет экземпляров, среда программы во время выполнения размещает постоянные величины в статической области хранения, находящейся в интерфейсе.
Следовательно, константы могут использоваться для параметризации операций программы, использующих параметры. Параметризация задается во время компиляции, а не во время выполнения.
Когда нужна более сложная параметризация, требующая определения во время выполнения, но, тем не менее, видимая в исходном коде, может использоваться
одноэлементный класс. Одноэлементный класс может |
|
Проект рование ПО. Проектирование классов взаимод йствия |
10 |
инициализировать только один объект. |
|