WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 || 3 | 4 |   ...   | 9 |

- дат возможность учитывать, согласовывать и предсказывать характеристики качества, в том числе и по результатам е исследования;

- дат информацию о распределении работ и их календарных планах;

- дат возможность для более точной оценки стоимости и расписания работ;

- снижает риски;

- является первой формой существования SIS, которая может быть проверена (испытана) как целое;

- предоставляет возможность для переноса или повторного использования стилей и архитектурных каркасов;

- приносит выгоду в ограничении «словаря» альтернатив проекта или его частей;

- помогает в эволюционном прототипировании;

- оформляет концептуальную целостность SIS и процесса е разработки;

- обслуживает понимание и взаимопонимание в индивидуальной и коллективной работе;

- есть средство выражения мыслей и рассуждений в коммуникации лиц, вовлечнных в разработку SIS;

- предоставляет возможность рассуждать о потенциальных изменениях по ходу разработки SIS и вносить вклад в управление такими изменениями;

- может быть базисом для изучения системы.

Приведнный перечень от разработки архитектуры впечатляет и, поэтому, трудно объяснить «Почему архитектуре до сих пор уделяется так мало внимания в разработке SIS». Разумеется, разработка архитектуры дорого стоит, но не дороже чем негативы от е отсутствия. Именно по этой причине Rational Unified Process построен как архитектурно-центрированный процесс разработки SIS [39].

2. Нормативные практики архитектурного описания SIS 2.1. Основные понятия В статье [52], которая относится к числу базовых фундаментальных публикаций, выделивших в программной инженерии «архитектуру ПО» как отдельную и важную проблемную область, была указана необходимость использования в архитектурных представлениях механизма «видов» на ПО, подобных «видам», применяемым в инженерной практике (например, в строительстве). Эта идея получила развитие, что привело к стандарту IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems [89] (Рекомендуемое для практики описание архитектуры систем, интенсивно использующих ПО).

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

Стандарт позиционирован его разработчиком (IEEE Architecture Planning Group) как «рекомендуемая практика». Он не является стандартом архитектуры, процесса архитектуры или метода разработки архитектуры, а предоставляет разработчикам SIS рекомендации для описания архитектуры (Architectural Description, AD). Его рекомендации используют модальности «должен» (без обязательности) и «можно» (как вариант).

Но рекомендации базируются на большом опыте успешных разработок SIS. Рекомендации приняты мировыми лидерами индустрии ПО и SIS.

Стандарт IEEE 1471 [89]:

- нацелен на его применение для архитектурного описания (АО) систем, интенсивно использующих программное обеспечение, в которых программная составляющая оказывает существенное влияние на проектирование, конструирование, развертывание и эволюцию системы как целого;

- предполагает, что организации и предприятия, решившие использовать стандарт, должны сами решать, в каком объме и как он будет внедряться в разработки SIS;

- дает широкие рамки интерпретации архитектуры, как средства, пригодного для процесса разработки SIS;

- исходит из того, что описание архитектуры может быть согласовано широким кругом лиц, вовлечнных в разработку SIS, в то время как система, проект, процесс и организация работ такой возможности обычно не предоставляют (из-за специфики разнородной профессиональной компетенции и языка);

- определяет концептуальную структуру (систему понятий) для описания архитектуры и его использования ;

- устанавливает термины и понятия для архитектурного мышления;

- устанавливает концептуальный каркас и словарь для рассуждений об архитектурной форме существования SIS, в виде архитектурного описания;

- обеспечивает средства для рассуждений об архитектурном описании в контексте лиц, вовлечнных в процесс разработки SIS, жизненного цикла SIS и использования АО;

- служит как базис для развития SIS на ранних этапах разработки, когда доступна только общая терминология об SIS, которая ещ не материализована;

- вводит в системы требований для разработки SIS специальный раздел «архитектурных требований»;

- идентифицирует и устанавливает тождество в описаниях архитектур и пропагандирует озвученное в архитектурной практике;

- открывает возможность для эволюции таких практик, как достигших достаточной инструментально-технологической зрелости;

- служит как базис для развития предметной области, в которой существует только общая терминология;

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



2.2. Содержание стандарта Перейдем к основе и деталям рекомендуемой практики, обслуживающей построение архитектурных описаний, документирующих архитектуры.

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

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

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

Среда Назначение 17 Система 16 Архитектура Обоснование Описание архитектуры 1 Заинтересованное лицо 2 3 Вид 7 «Точка зрения» 9 Модель «Интерес» Библиотека «Точек зрения» Рис. 5. Стандартное описание архитектуры (отношения: 1 различается, 2 различается, 3 выбирается, 4 агрегируется, 5 состоит из видов, 6 имеет, 7 адресуется, 8 реализуется, 9 покрывает, 10 устанавливает форму, 11 состоит из моделей, 12 содержит, 13 убеждает, 14 представляет, 15 использует, 16 имеет, 17 размещена, 18 обеспечивает) Выборочно представим содержание узлов схемы. Толкование ряда особо важных понятий каркаса (архитектурной концептуальной схемы SIS) проведм с позиций тех требований, которые они выражают в системе требований к SIS:

1. Различные значения понятия «Лица, заинтересованные в разработке SIS.

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

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

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

Так, например, в RUP различается около 70 ролей stackeholders.

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

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

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

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

Для представления архитектурного вида используют, в общем случае, совокупность концептуальных моделей и документов, раскрывающих их содержание или дополняющих содержание, выраженное в моделях. Архитектурные виды SIS принято визуализировать в форме, подобной визуализации, представленной на рис. 6.





Контроль за граф обходов иками PPHPas sport.dll Карточка таксофона DBTaxАРМ оператора СКУТ. exe Q Q1 A Q A11 Редактор справочников Directo ry.dll Q A … Q1m A1m … Q2 A Q21 A Q A … Q A2n 2n.........

Qp Ap Qp1 Ap Q App … Q Apq pq Рис.6. Визуализированный набор архитектурных видов Виды в конкретной технологии разработки SIS оформлены на определнном языке (например, на языке UML и/или других языках описания архитектуры, Architecture Description Language) и визуализированы в соответствии с определнным набором правил: каждый вид соответствует вполне определнной точке зрения (рис. 7);

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

Архитектурное описание 1..* определяет Вид Точка зрения Рис.7. Фрагмент архитектурной семантической сети Стандарт не фиксирует определнный набор видов, поскольку число разнородных SIS и их приложений многообразно. В рамках вопроса об архитектурах SIS не может быть окончательно решн вопрос об окончательном и полном наборе точек зрения и видов. В то же время точка зрения должна быть объявлена до е использования.

Виды в конкретной технологии разработки SIS хорошо оформлены: каждый вид соответствует вполне определнной точке зрения; точка зрения является образцом для конструирования видов; точка зрения определяет правила не только для построения видов, но и для их использования.

Стандарт не фиксирует определнный набор видов, не может быть окончательно решн вопрос, откуда ещ могут прийти точки зрения, точка зрения должна быть объявлена до е использования.

Намерение использовать варианты употребления понятий стандарта IEEE-1471 в архитектурном описании предписывает определиться с их значениями, или, что то же самое, ввести архитектурные требования в систему требований SIS и специфицировать эти требования. Следовательно, необходимо определиться:

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

- с «интересами» типовых групп, провести их анализ и систематизировать;

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

- с совокупностями «видов» на SIS (возможно, выбрав подходящие в библиотеке «видов»), которые будут составлять архитектурное описание.

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

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

1. Анализ альтернативных проектов системы.

2. Планирование перепроектирования системы, внесения изменений в е организацию.

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

4. Выработка критериев примки системы при е сдаче в эксплуатацию.

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

6. Проектирование и разработка отдельных элементов системы.

7. Сопровождение, эксплуатация, управление конфигурациями и внесение изменений и поправок.

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

9. Проведение обзоров, анализ и оценка качества системы.

2.3. Представления схемы IEEE-Стандарт IEEE-1471 находит широкое применение на практике, что привело к его осмысливанию и переосмысливанию с различных позиций и применений. В таких действиях из семантического каркас стандарта либо извлекают часть сети, либо дополняют е или часть дополнительными фрагментами, либо строят родственные семантические сети.

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

Описание архитектуры 1 2 3 Заинтересованное Вид лицо 7 Точка зрения 9 «Интерес» Модель Рис. 8. Фрагмент семантической сети IEEE-В ряде публикаций и докладов G. Booch [10,14] связал со стандартом ряд мета моделей и рекомендовал их использовать в архитектурной практике. Одна из таких моделей представлена на рис. 9. Число узлов и связей этой модели (по отношению к базовой концептуальной схеме IEEE-1471) расширено.

Команда Инструменты Процесс Предметная Размещение Разработка область (география) Система Концептуальная схема IEEE-Архитектурное Среда Архитектура описание Родственные История «Силы» системы Стиль Спецификация Схема Рис. 9. Расширенная семантическая сеть Дополнительные узлы и связи, размещнные за рамками (двойная линия) схемы IEEE-1471, связаны с определнными узлами схемы IEEE-1471. Добавлены:

- для узла «система» е отношение с «предметной областью», к которой она принадлежит, пространственное «размещение» системы и е «разработка»;

- узел «разработка» детализирован до «команды», проводящей разработку, «процесса» е деятельности и применяемых «инструментов»;

Pages:     | 1 || 3 | 4 |   ...   | 9 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.