Lecture06 (Лекции по Технологии программирования. Компонентный подход), страница 3
Описание файла
Файл "Lecture06" внутри архива находится в папке "Лекции по Технологии программирования. Компонентный подход". PDF-файл из архива "Лекции по Технологии программирования. Компонентный подход", который расположен в категории "". Всё это находится в предмете "основы программной инженерии" из 6 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 3 страницы из PDF
Это так называемый метод анализа архитектурыПО (Software Architecture Analysis Method, SAAM) [1,4]. Основные его шаги следующие.1. Определить набор сценариев действий пользователей или внешних систем, использующихнекоторые возможности, которые могут уже планироваться для реализации в системе илибыть новыми. Сценарии должны быть значимы для конкретных заинтересованных лиц,будь то пользователь, разработчик, ответственный за сопровождение, представительконтролирующей организации и пр.
Чем полнее набор сценариев, тем выше будет качествоанализа. Можно также оценить частоту появления и важность сценариев, возможный ущербот невозможности их выполнить.2. Определить архитектуру (или несколько сравниваемых архитектур).
Это должно бытьсделано в форме, понятной всем участникам оценки.3. Классифицировать сценарии. Для каждого сценария из набора должно быть определено,поддерживается ли он уже данной архитектурой или для его поддержки нужно вносить внее изменения. Сценарий может поддерживаться, т.е.
его выполнение не потребуетвнесения изменений ни в один из компонентов, или же не поддерживаться, если еговыполнение требует изменений в описании поведения одного или нескольких компонентовили изменений в их интерфейсах. Поддержка сценария означает, что лицо,заинтересованное в его выполнении, оценивает степень поддержки как достаточную, анеобходимые при этом действия — как достаточно удобные.4. Оценить сценарии. Определить, какие из сценариев полностью поддерживаютсярассматриваемыми архитектурами. Для каждого неподдерживаемого сценария надоопределить необходимые изменения в архитектуре — внесение новых компонентов,изменения в существующих, изменения связей и способов взаимодействия.
Если естьвозможность, стоит оценить трудоемкость внесения таких изменений.5. Выявить взаимодействие сценариев. Определить какие компоненты требуется изменять длянеподдерживаемых сценариев; если требуется изменять один компонент для поддержкинескольких сценариев — такие сценарии называют взаимодействующими. Нужно оценитьсмысловые связи между взаимодействующими сценариями.Малая связанность по смыслу между взаимодействующими сценариями означает, чтокомпоненты, в которых они взаимодействуют, выполняют слабо связанные между собойзадачи и их стоит декомпозировать.Компоненты, в которых взаимодействуют много (> 2-х) сценариев, также являютсявозможными проблемными местами.6.
Оценить архитектуру в целом (или сравнить несколько заданных архитектур). Для этогонадо использовать оценки важности сценариев и степень их поддержки архитектурой.Рассмотрим сравнительный анализ двух архитектур на примере индексатора — программы дляпостроения индекса некоторого текста, т.е. упорядоченного по алфавиту списка его слов безповторений.Рассмотрим сравнительныйанализ двух архитектур напримере программыпостроения индекса —упорядоченного по алфавитусписка слов некотороготекста без повторений.алфавиту, анализ, архитектур,без, двух, индекса, на,некоторого, по, повторений,построения, примере,программы, Рассмотрим, слов,списка, сравнительный, текста,упорядоченногоРисунок 28.
Пример работы индексатора текста.1. Выделим следующие сценарии работы или модификации программы.a. Надо сделать так, чтобы индексатор мог работать в инкрементальном режиме, читая навходе одну фразу за другой и пополняя получаемый в процессе работы индекс.b. Надо сделать так, чтобы индексатор мог игнорировать предлоги, союзы, местоимения,междометия, частицы и другие служебные слова.c. Надо сделать так, чтобы индексатор мог обрабатывать тексты, подаваемые ему на входв виде архивов.d. Надо сделать так, чтобы в индексе оставались только слова в основной грамматическойформе — существительные в единственном числе и именительном падеже, глаголы внеопределенной форме и пр.2.
Определим две возможных архитектуры индексатора для сравнительного анализа.a. В качестве первой архитектуры рассмотрим разбиение индексатора на два компонента.Один компонент принимает на свой вход входной текст, полностью прочитывает его ивыдает на выходе список слов, из которых он состоит. Второй компонент принимает навход список слов, а на выходе выдает его упорядоченный вариант без повторений.
Этотвариант архитектуры построен в стиле «каналы и фильтры» (см. следующую лекцию).ВходнойтекстВыделениесловСписоксловУпорядочениесписка словИндексРисунок 29. Архитектура индексатора в стиле каналов и фильтров.b. Другой вариант архитектуры индексатора устроен следующим образом. Имеетсявнутренняя структура данных, хранящая подготовленный на настоящий момент вариантиндекса. Он представляет собой упорядоченный список без повторений всех слов,прочитанных до настоящего момента. Кроме того, имеются две переменные — строка,хранящая последнее (быть может, не до конца) прочитанное слово, и ссылка на то словов подготовленном списке, которое лексикографически следует за последним словом(соответственно, предшествующее этому слово в списке лексикографическипредшествует последнему прочитанному слову).В дополнение к этим данным имеются следующие компоненты.i. Первый читает очередной символ на входе и передает его на обработку одному изостальных.Если это разделитель слов (пробел, табуляция, перевод строки), управлениеполучает второй компонент.Если это буква — третий.Если входной текст кончается — четвертый.ii.
Второй компонент закачивает ввод последнего слова — оно помещается в списокперед тем местом, на которое указывает ссылка; после чего последнее словостановится пустым, а ссылка начинает указывать на первое слово в списке.iii. Третий компонент добавляет прочитанную букву в конец последнего слова, послечего, быть может, перемещает ссылку на следующее за полученным слово всписке.iv. Четвертый компонент выдает полученный индекс на выход.Эта архитектура построена в стиле «репозиторий» (см. следующую лекцию).Обработкаразделителей словВходнойтекстЧтениеочередногосимволаОбработка буквТекущий индексОбработка концатекстаРисунок 30.
Архитектура индексатора в стиле репозитория.3. Определим поддерживаемые сценарии из выделенного набора.a. Сценарий a.Этот сценарий прямо поддерживается второй архитектурой.Чтобы поддержать его в первой, необходимо внести изменения в оба компонента так,чтобы первый компонент мог бы пополнять промежуточный список, читая входнойтекст фраза за фразой, а второй — аналогичным способом пополнять результирующийупорядоченный список, вставляя туда поступающие ему на вход слова.b. Сценарий b.Обе архитектуры не поддерживают этот сценарий.Для его поддержки в первой архитектуре необходимо изменить первый компонент или,лучше, вставить после него дополнительный фильтр, отбрасывающий вспомогательныечасти речи.Для поддержки этого сценария второй архитектурой нужно ввести дополнительныйкомпонент, который перехватывает буквы, выдаваемые модулем их обработки(соответственно, этот модуль больше не должен перемещать указатель по итоговомусписку) и сигналы о конце слова от первого компонента, после чего он долженотсеивать служебные слова.c.
Сценарий c.Этот сценарий также требует изменений в обеих архитектурах.Однако в обоих случаях эти изменения одинаковы — достаточно добавитьдополнительный компонент, декодирующий архивы, если они подаются на вход.d. Сценарий d.Этот сценарий также не поддерживается обеими архитектурами.Требуемые им изменения аналогичны требованиям второго сценария, только в этомслучае дополнительный компонент-фильтр должен еще и преобразовывать слова в ихосновную форму и только после этого пытаться добавить результат к итоговомуиндексу.Таким образом, требуется, как и во втором случае, изменить или добавить одинкомпонент в первой архитектуре и изменить один и добавить новый во второй.4. Мы уже выполнили оценку сценариев на предыдущем шаге.
Итоги этой оценки приведеныв Таблице 6.5. Мы видели, что при использовании первого варианта архитектуры только для поддержкипервого сценария пришлось бы вносить изменения в ее компоненты. В остальных случаяхдостаточно было добавить новый компонент, что несколько проще.При использовании второго варианта нам в двух разных сценариях, помимо добавлениянового компонента, потребовалось изменить компонент, обрабатывающий буквы.АрхитектураКаналы и фильтрыРепозиторийСценарий a-++++Сценарий b++*++-+*Сценарий c++*++++*Сценарий d++*++-+*Таблица 6.