Проектирование на UML. Сборник задач - Антон Хританков
Шрифт:
Интервал:
Закладка:
г. (*) Приведите по одному примеру разрешенной и неразрешенной траекторий в данном взаимодействии.
3.9. Пользовательский интерфейс мультимедиа проигрывателя PlayerView сообщает ev контроллеру UIPresenter о начале проигрывания элемента списка воспроизведения playEntry. Контроллер: 1) рассылает это сообщение всем своим слушателям собственной операцией raiseEvent; 2) получает от управляющего компонента Engine тип контента по имени name выбранного элемента item события ev вызовом getContentType; 3) по типу контента получает медиапоток вызовами getAudioStream или getVideoStream; 4) переводит интерфейс в состояние проигрывания либо видео, либо аудио вызовом setPlaybackMode и указывает медиапоток операцией setMediaStream; 5) запускает воспроизведение операцией play контроллера.
а. Добавьте в модель возможность параллельной обработки сообщений в raiseEvent так, что операция обработки handleEvent вызывается асинхронно у каждого зарегистрированного слушателя типа IUIListener. Для отображения в модели используйте два анонимных слушателя.
б. Уточните взаимодействие при обработке события запуска проигрывания песни модулем lyricsPlugin, зарегистрированным в качестве слушателя событий UIPresenter. Модуль определяет тип контента элемента, передаваемый в сообщении о запуске. Для аудиоконтента создает запрос о тексте песни, вызывая собственный метод makeRequest. Затем модуль асинхронно вызывает операцию dispatchRequest класса NetController, передавая в параметрах запрос и себя как обработчика ответа. Получив ответ от сервера, NetController передает processResponse его обработчику. Модуль вызывает displayPage у UIPresenter и передает полученную HTML-страницу с текстом песни
3.10. (*) При решении основных задач, морфологический модуль ищет запрашиваемое слово в словаре языка. Таким образом, многие задачи в модуле зависят от реализации функции поиска слова в словаре. См. диаграмму на рис. 8. Для уменьшения объема, который занимает словарь, используется тип данных префиксное дерево2. Каждый узел дерева содержит ассоциативный массив буква – следующий узел. Таким образом, если слово есть в словаре, то в дереве есть путь, начинающийся в корне и проходящий по вершинам, соответствующим буквам слова.
а. Постройте модель кооперации поиска слова в словаре, используя роли класса Dictionary и узла дерева Node. Для моделирования префиксного дерева используйте квалифицированные соединители и булевый атрибут leaf, указывающий на конечный узел слова.
б. Добавьте в модель поведение кооперации. Актор парсер строки StringParser вызывает операцию hasWord класса Dictionary с параметром word типа String. Метод hasWord, реализующий операцию hasWord, получает корневой узел с помощью операции getRoot класса Dictionary. Получив экземпляр класса Node, метод в цикле для каждой следующей буквы слова word вызывает у этого экземпляра операцию getNextLetter с параметром c типа char – текущей буквы слова. Данная операция возвращает дочерний узел дерева. Когда буквы слова word закончились, нужно вернуть актору значение операции isLeaf последнего полученного узла Node.
в. Модифицируйте поведение. Если в какой-то момент вызов getNextLetter прерван по исключению NoSuchLetter, операция hasWord должна вернуть false.
3.11. Вариант использования просмотр каталога SearchCatalog реализован кооперацией GetAllRecords. Основной сценарий варианта использования начинается с получения контроллером приложения AC команды showRecords. AC отображает show в пользовательском интерфейсе UI сообщение «Идет запрос». AC параллельно отправляет источнику данных DataSource запрос readRecords. DataSource передает AC одну запись в параметре действия acceptRecord. Затем AC показывает запись в UI.
а. Укажите, что перед запросом записи, AC запрашивает getListSize количество записей у источника данных. Результат присваивается переменной listSize.
б. Измените модель так, чтобы источник данных передавал контроллеру listSize записей по одной, а контроллер отображал show в UI все полученные записи вместе.
в. Реализуйте альтернативный сценарий, когда источник данных не содержит записей.
г. Перечислите все необходимые соединители в кооперации GetAllRecords, укажите, какие сообщения по ним передаются. Ответ поясните.
д. (*) Какое минимальное количество экземпляров классов необходимо, чтобы выполнить описанное поведение? Ответ поясните.
ГЛАВА 2. МЕТОДЫ И ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
Парадигмы проектирования. Возникновение проектирования программного обеспечения можно связать с появлением языков высокого уровня в 60-х и 70-х годах. Проектирование возникло как дисциплина, целью которой было управление сложностью программных систем и расширение возможностей разработчиков по созданию систем большего размера предсказуемого качества.
В развитии проектирования как дисциплины выделяют несколько этапов, в каждом из которых доминировала одна из парадигм проектирования. В 70-е и 80-е такой была структурная парадигма проектирования. Ее основу составляют нисходящие декомпозиционные методы, итеративно разделяющие систему на функциональные блоки, все более понятные и простые в реализации. Примерами таких методов могут служить метод постепенного уточнения (stepwise refinement) [6], метод структурного анализа и структурного проектирования SSA/SD [6], техника структурного анализа и проектирования SADT3. Среди восходящих методов структурного проектирования следует отметить метод структурного проектирования Джексона [6].
Преимущественные нотации моделей в этой парадигме – это структурная схема, схема потоков данных, диаграмма сущность-связь, диаграммы IDEF.
В 80-е и 90-е преобладающими стали методы объектно-ориентированного проектирования. Основой методов является выделение общего описания групп объектов и использование этого описания в качестве абстрактного типа данных. Различные эвристики выделения общего описания и процедуры создания модели нашли выражение в различных методах анализа и проектирования. В результате объединения Objectory, OMT и OOAD был создан унифицированный процесс разработки RUP и язык моделирования UML. Во многом благодаря обсуждению принципов проектирования на страницах таких журналов как C++ Report были сформулированы эвристики повышения изменяемости и сопровождаемости систем SOLID [7]. Следует также отметить методы проектирования, основанные на выделении и группировке обязанностей RDD и связанные с ними эвристики назначения обязанностей GRASP [8]. А также методы, построенные на прямом использовании модели предметной области для построения программной системы. Позднее они нашли отражение в книге Эванса по предметно-ориентированному проектированию [5].
Сейчас объектно-ориентированные методы применяются для разработки отдельных компонент сложных систем. Методы структурного проектирования нашли применение при разработке систем обработки данных, в проектировании архитектуры систем масштаба предприятия.
Систематизация и количественный подход. Существование разных подходов к проектированию в одних и тех же отраслях ведет к необходимости их сравнения и определения предпочтительного и указания границ применимости. Инициатива по выработке базовых методов и теории программной инженерии SEMAT ставит своей целью каталогизацию методов, выработке их описания на основе нескольких базовых понятий и, таким образом, создания основ накопления данных об использовании методов для их последующего сравнения.
Распространенный подход к накоплению знаний в области проектирования – составление каталога повторно применимых приемов решения часто встречающихся задач проектирования, которое могут быть адаптированы для разных случаев – паттернов проектирования. В конце прошлого века были составлены первые каталоги паттернов. Наиболее известным является набор из двадцати двух паттернов «банды четырех» GoF [3]. В сфере высокоуровневого (архитектурного) проектирования аналогом паттернов выступают архитектурные стили [9], комбинации которых, исходя из требований к системе, составляют первоначальное архитектурное описание.