В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 25
Текст из файла (страница 25)
Заметим, однако, что ошибки в ПО чаще всегоносят неслучайный характер. Они повторяемы, в отличие от аппаратного обеспечения, где ошибкисвязаны часто со случайными изменениями характеристик среды и могут быть преодоленыпростым дублированием компонентов без изменения их внутренней реализации. Поэтому притаком обеспечении надежности надо использовать достаточно сильно отличающиеся способырешения одной и той же задачи в разных компонентах.Другим примером противоречивых требований служат характеристики удобстваиспользования и защищенности.
Чем сильнее защищена система, тем больше проверок, процедуридентификации и пр. нужно проходить пользователям. Соответственно, тем менее удобна для нихработа с такой системой. При разработке реальных систем приходится искать некоторыйразумный компромисс, чтобы сделать систему достаточно защищенной и способной поставитьощутимую преграду для несанкционированного доступа к ее данным и, в то же время, неотпугнуть пользователей сложностью работы с ней.Список стандартов, регламентирующих описание архитектуры, которое является основнойсоставляющей проектной документации на ПО, выглядит так.• IEEE 1016-1998 Recommended Practice for Software Design Descriptions [2](рекомендуемые методы описаний проектных решений для ПО).• IEEE 1471-2000 Recommended Practice for Architectural Description of Software-IntensiveSystems [3] (рекомендуемые методы описания архитектуры программных систем).Основное содержание этого стандарта сводится к определению набора понятий, связанныхс архитектурой программной системы.Это, прежде всего, само понятие архитектуры как набора основополагающих принциповорганизации системы, воплощенных в наборе ее компонентов, связях их друг с другом имежду ними и окружением системы, а также принципов проектирования и развитиясистемы.Это определение, в отличие от данного в начале этой лекции, делает акцент не на наборе78структур в основе архитектуры, а на принципах ее построения.Стандарт IEEE 1471 определяет также представление архитектуры (architecturaldescription) как согласованный набор документов, описывающий архитектуру с точкизрения определенной группы заинтересованных лиц с помощью набора моделей.Архитектура может иметь несколько представлений, отражающих интересы различныхгрупп заинтересованных лиц.Стандарт рекомендует для каждого представления фиксировать отраженные в нем взглядыи интересы, роли лиц, которые заинтересованы в таком взгляде на систему, причины,обуславливающие необходимость такого рассмотрения системы, несоответствия междуэлементами одного представления или между различными представлениями, а такжеразличную служебную информацию об источниках информации, датах созданиядокументов и пр.Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы длярешения таких задач, как следующие.o Анализ альтернативных проектов системы.o Планирование перепроектирования системы, внесения изменений в ее организацию.o Общение по поводу системы между различными организациями, вовлеченными в ееразработку, эксплуатацию, сопровождение, приобретающими систему илипродающими ее.o Выработка критериев приемки системы при ее сдаче в эксплуатацию.o Разработка документации по ее использованию и сопровождению, включая обучающиеи маркетинговые материалы.o Проектирование и разработка отдельных элементов системы.o Сопровождение, эксплуатация, управление конфигурациями и внесение изменений ипоправок.o Планирование бюджета и использования других ресурсов в проектах, связанных сразработкой, сопровождением или эксплуатацией системы.o Проведение обзоров, анализ и оценка качества системы.Разработка и оценка архитектуры на основе сценариевПри проектировании архитектуры системы на основе требований, зафиксированных в видевариантов использования, первые возможные шаги состоят в следующем.1.
Выделение компонентовa. Выбирается набор «основных» сценариев использования — наиболее существенных ивыполняемых чаще других.b. Исходя из опыта проектировщиков, выбранного архитектурного стиля (см. следующуюлекцию) и требований к переносимости и удобству сопровождения системыопределяются компоненты, отвечающие за определенные действия в рамках этихсценариев, т.е. за решение определенных подзадач.c. Каждый сценарий использования системы представляется в виде последовательностиобмена сообщениями между полученными компонентами.d.
При возникновении дополнительных хорошо выделенных подзадач добавляются новыекомпоненты, и сценарии уточняются.2. Определение интерфейсов компонентовa. Для каждого компонента в результате выделяется его интерфейс — набор сообщений,которые он принимает от других компонентов и посылает им.b. Рассматриваются «неосновные» сценарии, которые так же разбиваются напоследовательности обмена сообщениями с использованием, по возможности, ужеопределенных интерфейсов.c. Если интерфейсы недостаточны, они расширяются.79d.
Если интерфейс компонента слишком велик, или компонент отвечает за слишкоммногое, он разбивается на более мелкие.3. Уточнение набора компонентовa. Там, где это необходимо в силу требований эффективности или удобствасопровождения, несколько компонентов могут быть объединены в один.b. Там, где это необходимо для удобства сопровождения или надежности, один компонентможет быть разделен на несколько.4. Достижение нужных свойств.Все это делается до тех пор, пока не выполнятся следующие условия:a. Все сценарии использования реализуются в виде последовательностей обменасообщениями между компонентами в рамках их интерфейсов.b.
Набор компонентов достаточен для обеспечения всей нужной функциональности,удобен для сопровождения или портирования на другие платформы и не вызываетзаметных проблем производительности.c. Каждый компонент имеет небольшой и четко очерченный круг решаемых задач истрого определенный, сбалансированный по размеру интерфейс.На основе возможных сценариев использования или модификации системы возможен такжеанализ характеристик архитектуры и оценка ее пригодности для поставленных задач илисравнительный анализ нескольких архитектур. Это так называемый метод анализа архитектурыПО (Software Architecture Analysis Method, SAAM) [1,4].
Основные его шаги следующие.1. Определить набор сценариев действий пользователей или внешних систем, использующихнекоторые возможности, которые могут уже планироваться для реализации в системе илибыть новыми. Сценарии должны быть значимы для конкретных заинтересованных лиц,будь то пользователь, разработчик, ответственный за сопровождение, представительконтролирующей организации и пр. Чем полнее набор сценариев, тем выше будет качествоанализа. Можно также оценить частоту появления и важность сценариев, возможный ущербот невозможности их выполнить.2. Определить архитектуру (или несколько сравниваемых архитектур).
Это должно бытьсделано в форме, понятной всем участникам оценки.3. Классифицировать сценарии. Для каждого сценария из набора должно быть определено,поддерживается ли он уже данной архитектурой или для его поддержки нужно вносить внее изменения. Сценарий может поддерживаться, т.е. его выполнение не потребуетвнесения изменений ни в один из компонентов, или же не поддерживаться, если еговыполнение требует изменений в описании поведения одного или нескольких компонентовили изменений в их интерфейсах. Поддержка сценария означает, что лицо,заинтересованное в его выполнении, оценивает степень поддержки как достаточную, анеобходимые при этом действия — как достаточно удобные.4.
Оценить сценарии. Определить, какие из сценариев полностью поддерживаютсярассматриваемыми архитектурами. Для каждого неподдерживаемого сценария надоопределить необходимые изменения в архитектуре — внесение новых компонентов,изменения в существующих, изменения связей и способов взаимодействия. Если естьвозможность, стоит оценить трудоемкость внесения таких изменений.5. Выявить взаимодействие сценариев. Определить какие компоненты требуется изменять длянеподдерживаемых сценариев; если требуется изменять один компонент для поддержкинескольких сценариев — такие сценарии называют взаимодействующими. Нужно оценитьсмысловые связи между взаимодействующими сценариями.Малая связанность по смыслу между взаимодействующими сценариями означает, чтокомпоненты, в которых они взаимодействуют, выполняют слабо связанные между собойзадачи и их стоит декомпозировать.Компоненты, в которых взаимодействуют много (> 2-х) сценариев, также являютсявозможными проблемными местами.806.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
