Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 115
Текст из файла (страница 115)
Специальные средства помогут вам понять поток управления и структуры данных программы. Комментарии, описательные имена переменных, функций и методов еще более углубят ваше понимание системы. ° Структура базы данных. Если приложение работает с базой данных, вы можете многое узнать из этой базы. База данных описывает структуру данных и задает ограничения на них, причем точным и явным образом. ° Данные. Если доступны данные, вы можете определить большую часть их структуры. Хорошо написанная программа и дисциплинированные пользователи обычно дают более качественные данные, нежели предписывает структура данных. В больших системах можно воспользоваться небольшим м зак 699 Таблица 23.1 демонстрирует, что инженерный анализ противоположен по смыслу нормальной разработке ((огтчагг1 епй1пеег1пя): вы начинаете с существующего приложения и пытаетесь вернуться к требованиям, по которым оно строилось.
482 Глава 23 ° Унаследованные системы объемом данных, чтобы получить предварительные заключения, а затем проверить этн заключения на дополнительных данных. Проверка безусловно не может доказать правильность заключений, но чем больше данных вы проверите, тем более вероятной будет правильность заключений. ° Формы и отчеты.
Осмысленные заголовки и формат проясняют структуру данных и логику их обработки. Определения форм и отчетов особенно полезны, если доступна их связь с переменными. Эмпирический подход состоит во вводе известных, но необычных значений переменных для определения связей между формами и переменными. ° Документация. Задачи отличаются друг от друга качеством, количеством и характером документации. Документация создает контекст инженерного анализа. Особенно полезно иметь руководство пользователя.
Может иметься и словарь данных (список важных сущностей в программе с их определениями). Относитесь к документации с осторожностью, потому что она может оказаться устаревшей и несогласованной с самим приложением. ° Понимание приложения. Если вгя хорошо понимаете приложение, вы сможете лучше разработать интерфейсы. Может быть, вам удастся связаться с экспертами по данному приложению, которые ответят на ваши вопросы и приведут обоснования своих решений. Вы можете еще более укрепить свою модель, воспользовавшись сведениями из родственных приложений.
° Тестовые ситуации. Тестовые ситуации позволяют проверить нормальный поток управления и необычные ситуации. Иногда они дают важные сведения. 23.1.3. Выходные данные инженерного анализа Инженерный анализ дает несколько видов полезных выходных данных. ° Модели. Модель отражает область применения и назначение приложения. Она является отправной точкой для понимания исходной программы и построения любых новых программ. ° Отображения. Вы можете связать атрибуты модели с переменными. С меньшей точностью вы можете связать программный код с моделями состояний и взаимодействий. ° Журналы. Аналитики должны записывать свои наблюдения и нерешенные вопросы. Журнал отражает принимаемые решения и их обоснование.
23.2. Построение модели классов Всегда начинайте с построения модели классов приложения. Это даст вам возможность понять классы и отношения между ними. Мы рекомендуем строить модель классов в три этапа, которые мы называем восстановлением реализации, восстановлением проекта и восстановлением анализа. 23.2. Построение модели классов 483 23.2.1. Восстановление реализации Прежде всего постарайтесь быстро изучить приложение и создайте начальную модель классов.
Если программа написана на объектно-ориентированном языке, вы можете восстановить классы и обобщения непосредственно. В противном случае вам придется изучать структуры данных и операции и определять классы вручную. Система может быть спроектирована не очень удачно, поэтому результат может оказаться неудовлетворительным. Старайтесь не делать никаких дальнейших предположений, ограничьтесь только определением классов. Полезно иметь начальную модель, описывающую реализацию системы.
23.2.2. Восстановление проекта Теперь нужно протестировать приложение таким образом, чтобы восстановить ассоциации. Обычно ассоциация реализуется как атрибут-указатель. Кратность ассоциации в прямом направлении обычно бывает очевидна. Кратность в противоположном направлении обычно не декларируется, и вам придется определить ее из общих соображений или путем изучения кода. Во многих системах для реализации ассоциации с кратностью «много» используются совокупности указателей. В этом случае изначальная модель будет указывать на класс совокупности, а не на класс элементов. Вы должны перенести ассоциацию в класс элементов и соответствующим образом скорректировать кратность. Классы совокупностей — это механизмы реализации, которые не должны присутствовать в большинстве аналитических и проектных моделей.
Вы можете указать эти классы как рекомендуемую реализацию для ассоциаций в направлении с кратностью «много». Иногда при помощи указателей ассоциации реализуются в обоих направлениях. В этом случае необходимо идентифицировать парные указатели и объединять их в одну ассоциацию. Необходимо проверить все классы, в которых имеются парные указатели друг на друга. Если вы работаете с программным средством, оно создаст по одной ассоциации на каждый указатель. Вы должны удалить одну из ассоциаций и перенести соответствующую информацию на вторую ассоциацию. Нижнее ограничение на кратность обычно имеет значение О или 1.
Значение О соответствует ситуации, когда целевой объект инициализируется где-то в исходном коде, но момент проведения инициализации неочевиден. Значение 1 означает, что целевой объект инициализируется в момент создания объекта, например, в конструкторе или блоке инициализации. 23.2.3. Восстановление анализа На последнем этапе вы должны интерпретировать модель, уточнить ее и сделать более абстрактной. Удалите все оставшиеся артефакты реализации, устраните ошибки. Избавьтесь от избыточной информации или пометьте ее как избыточную.
Это подходящий момент для пересмотра модели. Является ли она удобочитаемой и согласованной? Согласуйте результаты инженерного анализа с моделями других приложений и с документацией. Покажите свою модель экспертам по приложению и учтите их рекомендации. 484 Глава 23 ° Унаследованные системы Если исходный код не был объектно-ориентированным, вам придется выводить обобщения исходя из подобия и различий структуры и поведения. Для выделения агрегаций и композиций требуется понимание приложения и внимательное изучение кода.
Например, одинаковое время существования объектов может указывать на их участие в композиции. Понимание приложения и кода требуется также для определения квалификаторов и классов ассоциации. Вы можете добавить в модель пакеты, при помощи которых организуются классы, ассоциации и обобщения. Классы из нескольких файлов можно объединить в один пакет или, наоборот, разбить большой файл кода по нескольким пакетам. 23.3. Построение модели взаимодействия Назначение каждого метода обычно бывает достаточно очевидным, а то, каким образом объекты взаимодействуют друг с другом для решения стоящих перед системой задач, обычно бывает достаточно сложно понять просто исходя из кода.
Проблема в присущей коду редуцированности: он описывает работу каждой отдельной составляющей. Система же имеет смысл только как целое: взаимодействия объектов друг с другом придают ей этот смысл. Расширить ваше понимание системы поможет модель взаимодействия. Чтобы добавить методы в модель классов, вы можете воспользоваться разделением на слои.
В данном случае слой (з11се) — это подмножество программы, сохраняющее определенную проекцию ее поведения ~%е)зег-841. Для разделения на слои нужно выбрать некоторый исходный код, подлежащий сохранению. Затем нужно пометить все операторы, используемые этим кодом. Таким образом, вы получите проекцию фрагмента поведения исходной программы.
Разделение на слои позволяет преобразовать процедурный код в объектно-ориентированное представление. Для программистов, как отмечает 1'йГе)зег-84], мышление в терминах слоев довольно естественно. Удобство работы с ними обусловливается следующими факторами: 1) их можно идентифицировать автоматически; 2) слои получаются меньше, чем исходная программа; 3) они выполняются независимо друг от друга; 4) каждый слой в точности воспроизводит проекцию поведения исхолной программы 1'1Уе1зег-841.
Для представления полученного таким образом метода можно использовать диаграмму деятельности. Она поможет вам понять последовательность обработки и поток данных между различными объектами. После этого вы сможете сконструировать диаграммы последовательности из диаграмм деятельности, чтобы упростить дальнейшую работу. 23.4. Построение модели состояний Если вы занимаетесь анализом пользовательского интерфейса, модель состояний может быть довольно полезна.
В остальных случаях модели состояний не имеют особого значения. 23.5, Рекомендации по проведению инженерного анализа 485 Если вам нужно построить модель состояний, действуйте следующим образом. На входе у вас имеются диаграммы последовательности, полученные после построения модели взаимодействий. Вы должны объединить диаграммы последовательности одного класса, упорядочив события и добавив условия и циклы (см.
главу 13). Изучение кода и проведение динамического тестирования позволит вам дополнить диаграммы последовательности. Полезно найти все возможные состояния каждого класса„для которого нужно сформулировать модель состояний. Инициация и завершение соответствуют конструкторам и деструкторам объектов. 23.5. Рекомендации по проведению инженерного анализа В этом разделе мы собрали несколько важных подсказок, которые следует иметь в виду в процессе выполнения инженерного анализа и построения моделей классов, взаимодействия и состояний.
° Отделяйте предположения от фактов. Инженерный анализ выдает множество гипотез. Вы должны достичь полного понимания приложения прежде, чем сможете сделать твердые заключения. По мере проведения анализа вам придется возвращаться к предыдущим решениям, проверять и изменять их. ° Приспосабливайтесь. Процесс инженерного анализа должен соответствовать задаче. Сами задачи и доступные данные очень сильно отличаются в разных случаях. Для инженерного анализа вам понадобятся мозги— это все равно, что решать большую головоломку. ° Будьте готовы к различным интерпретациям. При инженерном анализе ответ может быть не единственным. Альтернативные интерпретации дают разные модели.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
