Полная версия

Главная arrow Информатика arrow Введение в архитектуру программного обеспечения

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Содержание стандарта

Основу рекомендуемой практики определяет концептуальный каркас (framework), представленный на рис. 11 и раскрывающий то, что целесообразно включать в АО. Концептуальный каркас в стандарте оформлен в виде семантической сети, связывающей определенными отношениями основные понятия архитектуры ПО. За отбор подходящих средств и их использование несет ответственность архитектор.

В рамках концептуального каркаса указаны понятия (и их связи), относящиеся к понятию «архитектурное описание» («заинтересованные лица», «интерес заинтересованных лиц», «вид», «точка зрения» и другие детали) и контексту его употребления (система, среда, миссия, архитектура). За каждым понятием стоит его (потенциальное или реальное) материальное воплощение определенной составляющей (или ряда составляющих) процесса и/или результата разработки ПО. Факт отсутствия такого материального воплощения указывает на отклонение от схемы, которое (как показывает практика разработок ПО) может привести к негативным последствиям разработки [2].

На рис. 11 указаны связи между узлами, но не приведены (чтобы не загромождать рисунок) характеристики степени связи, т. е. кратности «один-к-одному (1..1)», «один-ко-многим» (1..N) и др.

Выборочно представим содержание узлов схемы. Толкование ряда особо важных понятий каркаса (архитектурной концептуальной схемы ПО) приведем с позиций тех требований, которые они выражают в системе требований к ПО.

1. «Лица, заинтересованные в разработке (Stakeholders)» вводятся для того, чтобы на множестве таких лиц определить типовые роли,

Стандартное описание архитектуры

Рис. 11. Стандартное описание архитектуры: отношения: 1 — различается; 2 — различается; 3 — выбирается; 4 — агрегируется; 5 — состоит из видов; 6 — имеет интерес; 7 — адресуется; 8 — реализуется; 9 — покрывает; 10 — устанавливает форму; 11 — состоит из моделей; 12 — содержит; 13 — убеждает; 14 — представляет; 15 — использует; 16 — имеет; 17 — размещена;

18 — обеспечивает

исполнение которых осуществляют в общем случае группы лиц. Необходимо всегда помнить и принимать в расчет, что архитектура разрабатывается именно для них.

К типовым ролям относятся: лица (Acquirers), приобретающие систему; эксперты-консультанты (Assesors), проверяющие целесообразность приобретения; пропагандисты (Communicators), распространяющие сведения об этом через документы и обучение; разработчики (Developers), создающие систему; сопровождающие (Mainteners) внедряющие, сопровождающие и развивающие систему; снабженцы (Suppliers), поставляющие «комплектующие части»; пользователи (Users), обеспечивающие использование системы по назначению; администраторы (Administrators), обеспечивающие функционирование системы; тестировщики (Testers), проверяющие корректность работы системы.

В конкретных инструментально-технологических системах разработки ПО могут быть использваны не только названные роли, но и многие другие. Так, например, в RUP различается около 70 ролей stackeholders.

Определение группы и конкретных лиц выполнено правильно, если эти лица информированы (что позволяет им принимать хорошие решения), способны принять на себя обязательства и ответственность (даже если решения трудные) и авторитетные (что повышает степень доверия к их решениям).

2. За понятием «Интерес (Concern)» стоит то, что принято называть интересом лица, находящегося в определенной роли к процессу разработки ПО, например «интерес к тем функциям, которые исполнимы в ПО, а значит, к поведению ПО», «интерес к защищенности ПО по отношению к несанкционированному доступу» или «интерес к позитивным эффектам, достижимым при использовании ПО». В общем случае конкретный «интерес» может выражать определенную заинтересованность группы лиц, исполняющих типовую роль, например групп «разработчики» или «пользователи».

Выявить совокупность таких «интересов» и их значений, необходимых и достаточных для успешной разработки ПО, является одной из первоочередных и важнейших задач концептуального проектирования ПО, ответственного за «систему требований», «архитектуру» и «концептуальный проект».

  • 3. Понятие «Точка зрения. Viewpoint» раскрывает позицию, с которой определенная группа лиц или группа групп, заинтересованных в разработке ПО, желает, привыкла, готова или в состоянии представить ПО как целое.
  • 4. Понятие «Вид. View» является родственным для «видов», используемых в машиностроительном или строительном черчении. Понятие «вид» в архитектурных описаниях ПО соответствует «проекции ПО» на определенный интерес или интересы. Для представления архитектурного вида используют в общем случае совокупность концептуальных моделей и документов, раскрывающих их содержание или дополняющих содержание, выраженное в моделях. Архитектурные виды АС принято визуализировать в форме, представленной на рис. 12.

Виды в конкретной технологии разработки ПО могут быть оформлены на определенном языке (например, па языке UML и/или других языках описания архитектуры, Architecture Description Language) и визуализированы в соответствии с определенным набором правил: каждый вид соответствует вполне определенной точке зрения (рис. 13); точка зрения является образцом для конструирования видов, причем точка зрения определяет правила не только для построения видов, но и для их использования.

Визуализированный набор архитектурных видов

Рис. 12. Визуализированный набор архитектурных видов

Фрагмент архитектурной семантической сети

Рис. 13. Фрагмент архитектурной семантической сети

Стандарт не фиксирует определенный набор видов, поскольку число разнородных ПО и их приложений многообразно. В рамках вопроса об архитектурах ПО не может быть решен вопрос об окончательном и полном наборе точек зрения и видов. В то же время точка зрения должна быть объявлена до ее использования [20, 25, 261.

Отношения между «точкой зрения», «интересами» {сі}, «видами», «моделями» {ні]'} и документами {Эк}, обобщенно представленные на рис. 14, завершают толкование основных понятий стандарта ІЕЕЕ-1471—2000.

Намерение использовать варианты употребления понятий стандарта ІЕЕЕ-1471 в архитектурном описании предписывает определиться с их значениями, или, что то же самое, ввести архитектурные требования в систему требований ПО и специфицировать эти требования [2]. Следовательно, необходимо определиться:

• с «типовыми группами лиц», интересы которых следует или целесообразно учесть в разработке ПО;

Точка

Пространство

архитектуры

Совокупность «интересов» точки зрения Рис. 14. Образное представление отношений видов и точки зрения

зрения

  • • с «интересами» типовых групп, провести их анализ и систематизировать;
  • • с «точками зрения» (возможно, выбрав подходящие в библиотеке «точек зрения»), на основании которых будет строиться архитектурное описание ПО;
  • • с совокупностями «видов» на ПО (возможно, выбрав подходящие в библиотеке «видов»), которые будут составлять архитектурное описание.

Решения, принятые относительно этих требований, определят самое важное для действий по проектированию архитектуры ПО, в результате которого архитектурное описание наполнится деталями, в первую очередь подходящими концептуальными моделями и документами.

Стандарт ШЕЕ 1471 отмечает необходимость использования архитектуры системы для решения:

  • 1) анализ альтернативных проектов системы;
  • 2) планирование перепроектирования системы, внесения изменений в ее организацию;
  • 3) общение по поводу системы между различными организациями, вовлеченными в ее разработку, эксплуатацию, сопровождение, приобретающими систему или продающими ее;
  • 4) выработка критериев приемки системы при ее сдаче в эксплуатацию;
  • 5) разработка документации по ее использованию и сопровождению, включая обучающие и маркетинговые материалы;
  • 6) проектирование и разработка отдельных элементов системы;
  • 7) сопровождение, эксплуатация, управление конфигурациями и внесение изменений и поправок;
  • 8) планирование бюджета и использования других ресурсов в проектах, связанных с разработкой, сопровождением или эксплуатацией системы;
  • 9) проведение обзоров, анализ и оценка качества системы.
 
<<   СОДЕРЖАНИЕ   >>