WWW.DISSERS.RU

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

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


Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |
АРХИТЕКТУРНОЕ МОДЕЛИРОВАНИЕ СИСТЕМ, ИНТЕНСИВНО ИСПОЛЬЗУЮЩИХ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ П.И. Соснин Ульяновский государственный технический университет 432027, г. Ульяновск, ул. Северный Венец, д. 32 Аннотация. Представляется ретроспектива и современное состояние предметной области «Архитектурное моделирование систем, интенсивно использующих программное обеспечение (или Software Intensive Systems, SIS)». Последние 15 лет развития этой области квалифицируются, как «золотой век программной архитектуры». Основной причиной активного развития этой предметной области является чрезвычайно низкая успешность разработок SIS (около 35%) и недопустимые финансовые потери (более 100 млрд. долларов безвозвратных потерь в год). Обзор (только по зарубежным источникам) аналитически раскрывает сущность архитектурного моделирования, место и роль архитектуры в разработке SIS, сложившиеся нормативы архитектурного моделирования (стандарт IEEE-1471, DoDAF, TOGAF и другие …), и практику такого вида деятельности.

Annotation. The retrospective view and modern state of a subject area «Architectural modeling of Software Intensive Systems (SIS) » is represented. Last 15 years of the development in this area are qualified, as «the Golden Age of program architecture». The principal cause of active evolution of this subject area is extremely low success of developing the SIS (about 35 %) and inadmissible financial losses (more than 100 billion dollars of irrevocable losses a year). The review (only on foreign sources) analytically opens the essence of architectural modeling, a place and a role of architecture in development of the SIS, the useful instrumental means for architectural modeling (standard IEEE-1471, DoDAF, TOGAF and others …), and a practice of such kind of activity.

1 Введение Из года в год увеличиваются разнообразие и сложность систем, получивших в международной научно-технической практике название «Систем, интенсивно использующих программное обеспечение» (Software Intensive Systems, или, короче, SIS). В системах такого рода их функциональный потенциал либо определяется программным обеспечением (ПО), либо зависит от ПО в существенной мере [8]. На степень интенсивности ПО в конкретной SIS указывают относительные финансовые затраты на ПО на этапе исследований и разработок, в результате которых SIS была создана.

Общепризнанный законодатель в предметной области «Исследований и разработок SIS» Институт Программной Инженерии Университета Карнеги-Меллон (Software Engineering Institute, SEI) к классу SIS относит «системы, в которых ПО представляет существенный сегмент по следующим позициям: функциональность системы, е стоимость, риски в процессе разработки, время разработки» [80]. В таких системах компоненты ПО взаимодействуют с другими ПО-компонентами, компонентами и подсистемами другой природы, датчиками, приборами и людьми, вовлечнными в процессы использования SIS.

К числу SIS, например, относятся разнородные автоматизированные системы управления, встроенные бортовые транспортные системы, телекоммуникационные и корпоративные системы, в том числе и на базе web-сервисов. В отчте [8], прогнозирующем ближайшее будущее развития SIS, выделены их перспективы в автоматизации, аэронавтике, телекоммуникациях, медицине и экономике.

В российской терминологии системы типа SIS принято называть автоматизированными системами (АС). Основы стандартизации разработки и других аспектов существования АС отражены в группе стандартов 34-ой серии. Общим стандартом для АС и SIS, отражающим их «жизненный цикл», является стандарт ИСО/МЭК (Р)-(ISO/MEC 12207).

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

Разработки SIS слишком часто приводит к результатам, которые не соответствуют запланированным ожиданиям. Значительное число разработок, либо прекращается, либо превышает запланированное время и /или средства, либо завершается в более бедной версии. Степень успешности, выраженная в процентах числа проектов, завершившихся в соответствии с исходными замыслами и планами, чрезвычайно низка (около 35 %) И вс же, положение в этой предметной области год от года изменяется к лучшему. Свидетельством этого может служить статистика (рис. 1), регулярно представляемая в отчтах корпорации Standish Group [70].

Успех Провал Частично 1994 1996 1998 2000 2002 2004 Рис. 1. Статистика успехов и неудач в разработках SIS За те годы, которые отражены на рис.1, в системной и программной инженерии произошли существенные изменения:

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

- создан и подтвердил на практике свою исключительную полезность унифицированный язык моделирования UML;

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

- созданы технологии и инструментальные средства, аналогов которых в предшествующей инженерной практике не было (например, мастер-методология Rational Unified Process (RUP), инструментальные средства программирования для корпоративных сетей, в том числе и для WEB-программирования).



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

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

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

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

То, что «Сложность ПО является его существенным свойством, причм не случайным свойством», детально раскрывается в работе [12]. В этой публикации представлены, причм с акцентом на архитектурное моделирование, комментарии по следующим факторам, оказывающим воздействие на технологии разработки систем и приводящим к сложности ПО (а значит, и SIS): законы физики, законы ПО, изменение алгоритмов, трудности распределения структур и функций, проблемы проектирования, проблемы функциональности, важность организации, воздействие экономики, влияние политики, недостаток воображения.

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

У понятия «архитектура» в его применении к ПО и системам, базирующихся на ПО, достаточно долгая «жизнь». Начало этой «жизни» принято связывать с именами Э. Дейкстры, Ф. Брукса и Д. Парнаса, заложивших основы структурного и объектноориентированного программирования. Но «отсчт» современного значения этого понятия принято начинать с 1992 года с работы [52] Д. Перри и А. Вульфа. Период с года по 2000 год и перспективы развития архитектуры, представленные как «дорожная карта», нашли сво отражение в работе [32].

Основные вехи развития архитектуры в период с 1992 года по 2006 год, размеченные в публикации [43], доступной на русском языке по ссылке http://www.osp.ru/os/2006/03/1156577/, представлены на рис. 2.

Практически параллельно с работой [43] была опубликована работа [61] М. Шоу и П. Клементса, в которой содержание исследований и разработок периода, представленного на рис. 2, названо «Золотым веком архитектуры». В этой публикации раскрывается взгляд на историю предметной области архитектуры с позиций становления е зрелости.

За образец взята схема становления зрелости, которую часто повторяют новые технологии. Такая схема обычно развртывается на 15-летнем интервале и включает этапы:

1. Базовое исследование 2. Формулировка концепции 3. Развитие/расширение 4. Внутреннее расширение/исследование 5. Внешнее расширение/исследование 6. Популяризация Становление зрелости проблемной области «Архитектура SIS» проходило именно по такой схеме, причм так результативно и полезно, что название периода 1992-2006 г.г. «Золотым веком архитектуры» правомерно.

OOSA Wicsa EWSA Wicsa Clements Wicsa Evaluating… Clements SPLC 01 Documenting Wicsa UML Wicsa ADD Hofmelster Bass ATAM ISAW-Rechti ADML 9 n ISAW-Shaw COPA ISAW-Garian GOF Patterns Shaw Coming of ISAW-1 UML 1.BAPO Age 9 Обозначения:

1995 ATAM IEEE Witt Koala C2 Курсив - Методы Acme Darwin Обычный - Языки Rapld RUP Wrigh e Статьи t SAAM Книги Полужирный - Конференции Boxology До 1992 Perry,Wolf MIL CSP RM ODP Рис. 2. Ретроспектива исследований и разработок предметной области «Архитектура» 1. Нормативы архитектурного моделирования 1.1. Архитектура как форма концептуального существования SIS 1.1.1. Определения архитектуры и е значимость Известны многократные попытки определения понятия «архитектура». Наиболее богатая коллекции вариантов употреблений термина представлена на сайте SEI [80], где каждому, кто считает, что он сформулировал важную версию понятия, предоставлена возможность включить в общую коллекцию.





В профессиональной литературе по программной инженерии наиболее часто ссылаются на следующие определения:

1. (SEI) Архитектура программы или SIS – это структура (или набор структур) системы, которая включает программные элементы, наблюдаемые из вне свойства этих элементов, и взаимодействие между ними.

2. (RUP – Rational Unified Process) Архитектура включает: существенные решения по организации SIS; выделенные структурные элементы с их интерфейсами и функциями, обеспечивающими взаимодействие элементов в рамках SIS; композиции структурных и функциональных элементов в подсистемы, в соответствии с архитектурным стилем, который определяет их организацию, элементы, интерфейсы, взаимодействие и композицию в более сложные образования. Архитектура затрагивает не только структуру и поведение, но также использование, функциональность, и другие аспекты.

3. (IEEE – Institute of Electrical and Electronic Engineers) В соответствии с рекомендуемой практикой архитектура определяется как фундаментальная организация системы, связывающая е компоненты, их взаимодействие между собой и с окружающей их средой, а также принципы управления проектированием и развитием.

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

В работе [26] проведн анализ третьего (из представленных выше вариантов) определения архитектуры со следующим толкованием его отдельных позиций: архитектура в любой версии определяет структуру; архитектура определяет поведение; архитектура фокусирует свои интересы на существенных элементах структуры и поведения; архитектура находит баланс для совокупности требований лиц, заинтересованных в е разработке; архитектура интегрирует существенные решения на основе принципов рациональности; архитектура должна быть согласована с архитектурным стилем или их совокупностью; на архитектуру оказывает воздействие е среда; архитектура воздействует на структуру команды, которая разрабатывает SIS; архитектура присутствует в любой SIS; архитектура имеет определнные границы.

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

1.1.2. Место архитектурных решений Содержание определений архитектуры явно и неявно указывает на место архитектурных решений и их роль в разработке SIS. Подчркивая особую важность UseCase моделей в процессе разработки SIS, И. Якобсон включает архитектуру в процесс, как показано на рис. 3.

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

В процессе разработки SIS границы между этапами жизненного цикла и итерациями в рамках одного и того же этапа «размыты». Это особенно типично для этапов анализа требований (результатом которого является Система Требований СТ) и разработки архитектуры (результатом которого является Архитектурное Описание АО).

Каждый из этапов «анализа» и «архитектуры» приводит к определнной форме существования SIS в рамках е жизненного цикла, что (с некоторыми деталями) показано на рис. 4.

Требования Многократное использование Архитектура Итерация Use Cases Анализ и дизайн планирования Бизнес Тесты моделирование Дизайн опыта пользователя Рис.3. Use-case центрированная разработка архитектура проект Определение Код требований Ко д реализация Система требований К о н тр ол ь з а гр афи к а м и о б х о д о в Pp o r t. d l l s P HP as К а рто ч к а та к с офон а D B Ta x Q А РУ Т. e x e тор а Q 1 A 1 С К М о п е ра Q 11 A Q 12 A … rd Q 1m A 1m Р е д а к то р с пр а в о ч н и ко в Di. ec t o ry l l … Q 2 A Q 21 A … Q 2n A 2n Q 22 A.........

Q p A p Q p2 A p … Q p1 A p Q pq A pq Стиль Архитектура Архитектурное представление АС Рис. 4. Архитектура, как форма концептуального существования SIS На рисунке отражн тот факт, что формы существования SIS на ранних этапах разработки являются концептуальными, то есть представляют собой связную совокупность текстовых (в том числе табличных) документов и графических моделей и диаграмм (очень часто использующих для своего представления язык UML).

1.1.3. Роль архитектурных решений Роль архитектуры и позитивы от е построения и использования перечислим без ссылок на публикации, в которых они названы. Архитектура:

- вносит вклад в извлечение тре6бований и формирование их системы;

- ясно показывает совокупность ранних проектных решений;

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

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 9 |










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

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