Содержание к диссертации
Введение
1. Проблемы архитектурной надежности в информационно-управляющих системах 14
1.1. Программная архитектура информационно-управляющих систем 15
1.2. Системная архитектура корпоративных систем по Захману 29
1.3. Повышение архитектурной надежности информационно-управляющих систем 33
1.4. Терминологические проблемы анализа архитектурной надежности 45 Выводы по разделу 1 50
2. Архитектура как обобщенная модель информационно-управляющей системы 52
2.1. Фазы разработки программного обеспечения 52
2.2. Анализ фазы архитектурного дизайна 53
2.3. Базовый архитектурный модуль системы 65
2.4. Общая характеристика инструментальных средств автоматизации проектирования информационно-управляющих систем 70
2.5. Архитектурная спецификация критичных информационно-управляющих систем 74 Выводы по разделу 2 82
3. Модель анализа архитектурной надежности в сложных информационно-управляющих системах 84
3.1. Описание предлагаемой модели анализа архитектурной надежности 84
3.2. Усовершенствованная модель надежностного анализа архитектур в сложных информационно-управляющих системах 93 Выводы по разделу 3 114
4. Модель архитектурной надежности приложений клиент-сервер комплексной системы автоматизации управления предприятием 115
4.1. Особенности архитектуры корпоративных информационно-управляющих систем 115
4.2. Системы с программной архитектурой клиент-сервер 119
4.3. Клиент-серверные приложения КСУП «Галактика» 124
4.4. Практическая реализация надежностного анализа архитектуры ИУС 131 Выводы по разделу 4 138
5. Экспресс-анализ эффективности функционирования архитектуры информационно-управляющих систем 139
5.1. Анализ архитектурной надежности программного комплекса автоматизированной системы технической диагностики 141
5.2. Программная реализация системы оценки надежности программной архитектуры ИУС
Заключение
Список использованной литературы
- Программная архитектура информационно-управляющих систем
- Анализ фазы архитектурного дизайна
- Описание предлагаемой модели анализа архитектурной надежности
- Особенности архитектуры корпоративных информационно-управляющих систем
Введение к работе
Состояние проблемы качества архитектур информационно-управляющих систем (ИУС) регулярно обсуждается в ряде журнальных публикаций, монографий и учебников [1,8,9,17,25,31-36]. В них, как и в базовых стандартах, большое внимание уделяется современным проблемам и процессам обеспечения качества технической продукции, технологий и услуг.
Известно, что качество конечной продукции, поставляемой на рынок или заказчику, является определяющим фактором для успеха современной индустрии и конкурентоспособности многих наукоемких технологий и предприятий. Однако практически отсутствует литература, систематически и достаточно полно отражающая особенности и методы обеспечения качества архитектур информационно-управляющих систем и их основной, интеллектуальной части - программных средств.
Быстрый рост сложности и размеров современных программных систем (ПС) при одновременном повышении ответственности выполняемых функций системы резко повысил требования со стороны заказчиков и пользователей к их качеству, надежности функционирования и безопасности применения. Принципиально изменились характеристики основных проектов - разработки перешли от программирования «в малом» к программированию «в большом». По мере расширения применения и увеличения сложности программных систем выделились области, в которых ошибки или недостаточное качество программ могут нанести ущерб, значительно превышающий положительный эффект от их использования. В этих критических случаях недопустимы аномалии и дефекты функционирования ПС при любых искажениях исходных данных, сбоя, частичных отказах аппаратуры и других нештатных ситуациях. Однако иногда излишне высокие требования к качеству программных средств для подобных систем принципиально не могут быть выполнены вследствие реальных ограничений всех видов ресурсов: бюджета, длительности разработки, характеристик
вычислительных систем и квалификации специалистов. Это обусловило появление, развитие и применение методов, стандартов и средств автоматизации промышленной программной инженерии, обеспечивающих создание сложных архитектур ПС с заданными высокими показателями качества при реальных ограничениях на использование ресурсов разработки.
В связи с этим стратегической задачей в жизненном цикле современных программных систем стало обеспечение требуемого качества программной архитектуры и архитектуры баз данных. Во многих случаях контракты и предварительные планы на создание сложных программных систем и баз данных для информационно-управляющих систем подготавливаются и оцениваются неквалифицированно, на основе неформализованных представлений заказчиков о требуемых функциях и характеристиках качества ПС [31].
Значительные системные ошибки при определении требуемых показателей качества, оценке трудоемкости, стоимости и длительности архитектурного проектирования ПО МУС являются достаточно массовыми и типичными. Многие созданные ИУС не способны выполнять полностью требуемые функциональные задачи с гарантированным качеством и их приходится долго и иногда безуспешно дорабатывать для достижения необходимого качества и надежности функционирования, затрачивая дополнительно большие средства и время. В результате часто проекты систем не соответствуют исходному, декларированному назначению и первоначальным спецификациям требований к характеристикам качества, не укладываются в согласованные графики и бюджет разработки. Проекты оказываются неудачными или даже терпят полный провал из-за недостаточной компетентности привлекаемых разработчиков, их неадекватного «оптимизма», а также вследствие отсутствия у них современной технологии, методов и стандартов, обеспечивающих требуемое высокое качество проектов ПС.
В Российской практике, как правило, имеющийся огромный опыт отдельных организаций, а также успешно реализованные ими планы и процессы разработки предшествующих ПС высокого качества игнорируются, не обобщаются и не используются в качестве реальной базы для прогнозирования и планирования новых проектов. Вследствие этого во многих проектах программных систем:
- не полностью реализуются цели и требования заказчика к функциям и
качеству комплексов программ;
низка достоверность первичных оценок необходимых бюджета, сроков и ресурсов для разработки ПС при заключении контрактов, вследствие чего не выполняются требования заказчика к качеству;
плохо ведется контроль за ходом проекта, из-за чего велик риск отсутствия у конечного продукта заданного качества, нарушения начальных планов, невыполнения функциональных и экономических требований контрактов на разработку ПС.
В технических заданиях и реализованных проектах ПС систематически умалчиваются и/или недостаточно формализуются понятия и метрики качества программного продукта: какими характеристиками они описываются, как их следует измерять и сравнивать с требованиями, отраженными в контракте, техническом задании или спецификациях. Кроме того, некоторые из характеристик часто вообще отсутствуют в требованиях и согласованных документах на ПС, что приводит к произвольному их учету или к пропуску при испытаниях. Этому способствует ограниченность ресурсов, особенно времени, необходимых для достижения и оценивания в процессах ЖЦ комплекса программ, требуемых значений характеристик качества, а также недостаточная формализация и документирование всего процесса выбора и анализа качества ПС.
Традиционная неопределенность понятий и характеристик качества, особенно присущая крупномасштабным, наукоемким проектам сложных программных систем, а также многочисленные спекуляции разработчиков на
их значениях приучили заказчиков не доверять рекламируемым достоинствам программных продуктов. Объективная сложность анализируемых объектов — сложных программных систем — и психологическая самоуверенность ряда программистов в собственной «непогрешимости» часто приводят к тому, что реальные характеристики качества функционирования ПС остаются неизвестными не только заказчикам и пользователям, но также и самим разработчикам. Отсутствие четкого декларирования в документах понятий и требуемых значений характеристик качества ПС вызывает конфликты между заказчиками-пользователями и разработчиками-поставщиками вследствие разной трактовки одних и тех же характеристик.
Объективное повышение сложности функций, реализуемых архитектурными компонентами программных систем, непосредственно приводит к увеличению их объема и трудоемкости создания. Соответственно росту сложности программ возрастает количество выявляемых и остающихся в них дефектов и ошибок, что отражается на качестве функционирования. Разработка и сопровождение сложных ПС на базе современных технологий позволяет предупреждать и устранять наиболее опасные системные и алгоритмические ошибки на ранних стадиях проектирования, а также использовать неоднократно проверенные в других проектах программные и информационные компоненты архитектуры ПС высокого качества.
Обширной практикой [31-36,40,49] доказано, что обнаружение и устранение ошибок и дефектов в комплексах программ на начальных этапах проектирования в десятки и сотни раз быстрее и дешевле, чем в процессе завершения разработки испытаний. По мере увеличения сложности задач, решаемых программами, ошибки могут угрожать катастрофами в системах, выполняющих критические функции управления крупными, дорогими и особенно важными объектами или процессами.
Многочисленные провалы проектов сложных программных систем показали необходимость формализации взаимодействия и обеспечения
взаимопонимания разработчиков с заказчиком или потенциальным пользователем создаваемой ПС с самого начала проекта с целью конкретизации функций и уточнения требований качеству разрабатываемого решения. Многие ошибки, обусловленные неопределенностью или некорректностью технических заданий и спецификаций требований, могут и должны быть выявлены на ранних стадиях архитектурного проектирования ПС. Тем самым должен обеспечиваться поступательный ход процесса разработки ПС, без возвратов для уточнения или переделки архитектурно-связанных компонентов или даже всего комплекса программ.
За последние несколько лет создано множество международных стандартов, регламентирующих процессы и продукты жизненного цикла программных систем и систем управления базами данных (СУБД) [6,31]. Международные стандарты ISO содержат результаты обобщения мирового опыта в различных сферах производства и применения продукции и носят рекомендательный характер. Одна из серий стандартов (ISO 9000) содержит и развивает основное положение о том, что «поставщик должен разрабатывать и поддерживать в рабочем состоянии документально оформленную систему качества как средство, обеспечивающее соответствие продукции установленным требованиям заказчика». Применение этих стандартов может служить основой для систем обеспечения качества программных систем, однако требуется корректировка, адаптация или исключение некоторых положений стандартов применительно к принципиальным особенностям технологий и характеристик этого вида продукции. Кроме того, при реализации систем качества ПС необходимо привлечение ряда стандартов, формально не относящихся к этой серии и регламентирующих показатели качества, верификацию и тестирование, испытания, документирование и другие особенности ЖЦ комплексов программ.
В России в области обеспечения жизненного цикла и качества сложных программных систем существует и применяется очень небольшая группа
устаревших стандартов (ГОСТов), которые отстают от мирового уровня на 5—10 лет [31]. Эти стандарты вынуждены использовать предприятия, выполняющие государственные заказы при создании ПС для применения внутри страны. Однако в экспортных заказах зарубежные клиенты требуют соответствия технологии проектирования, производства и качества продукции современным международным стандартам, которые необходимо осваивать и применять для обеспечения конкурентоспособности продукции на мировом рынке.
В отечественных программных системах все больше применяют программные компоненты и продукты зарубежных фирм, которые также не могут быть абсолютно гарантированы от проявления дефектов проектирования, программирования и документации. Для обеспечения требуемого качества функционирования комплексов программ с использованием импортных компонентов следует закупать только лицензионно-чистые продукты, поддерживаемые гарантированным сопровождением конкретных поставщиков. Эти компоненты архитектуры ПС должны сопровождаться полной эксплуатационной и технической документацией, сертификатом соответствия и комплектами тестов. Иначе, качество программной, продукции остается низким, неподдающимся достоверной оценке и не конкурентоспособным на международном рынке.
В связи с изложенным появилась настоятельная потребность в разработке эффективного модельно-алгоритмического обеспечения методов и средств надежностного анализа программных архитектур, реализуемого в виде интерактивных пользовательских сред экспресс-анализа, ориентированных на специалистов предметной области.
Работы в данной области надежностного исследования архитектур
сложных программных систем требуют больших затрат, однако современные
масштабы программных разработок и внедрения информационно-
управляющих систем (в том числе, информационно-технологических
комплексов систем реального времени), не оставляют сомнений в
экономической целесообразности, своевременности и актуальности поставленных в диссертации задач.
Целью настоящей работы является совершенствование модельной и алгоритмической поддержки многоэтапного анализа архитектурной надежности сложных информационно-управляющих систем.
Для достижения поставленной цели решались следующие задачи:
анализ существующих методик, моделей и алгоритмов оценки архитектурной надежности ПО сложных информационно-управляющих систем;
анализ методик, моделей и алгоритмов оценки надежности критичных программных систем на фазе архитектурной спецификации;
разработка универсальной модели анализа архитектурной надежности сложных информационно-управляющих систем, работающей на всех этапах жизненного цикла программного обеспечения;
формирование модели анализа архитектурной надежности корпоративных информационно-управляющих систем с программной архитектурой «клиент-сервер»;
реализация экспресс-анализа эффективности функционирования программной архитектуры автоматизированной системы технической диагностики и контроля;
разработка структуры и программная реализация системы модельно-алгоритмической поддержки многоэтапного анализа архитектурной надежности сложных информационно-управляющих систем;
применение системы при решении практических задач анализа и формирования эффективных по надежности программных архитектур информационно-управляющих систем.
Методы исследования. При выполнении работы использовались математическое и вероятностное моделирование параметров сложных систем, методы оценки надежности сложных систем, элементы теории
вероятностей, структурный и объектно-ориентированный анализ, теория надежности программного обеспечения.
Научная новизна исследований заключается в создании комплекса математических моделей и алгоритмов анализа архитектурной надежности сложных программных систем, отражающего многоуровневость и распределенность архитектуры программного обеспечения.
1. Аналитически определены показатели, характеризующие
надежность программной архитектуры сложной информационно-
управляющей системы и позволяющие выявить архитектурно-связанные
компоненты.
Предложена универсальная модель анализа архитектурной надежности сложных информационно-управляющих систем, работающая на всех этапах жизненного цикла системы, и ее модификации для корпоративных информационно-управляющих систем с программной архитектурой «клиент-сервер».
Разработана методика автоматизированного 'экспресс-анализа эффективности функционирования программной архитектуры автоматизированной ИУС технической диагностики и контроля, которая применена в рамках современной технологии программирования автоматизированных систем управления.
4. Предложена концептуальная схема и реализация программного
комплекса моделей и алгоритмов анализа архитектурной надежности
сложных информационно-управляющих систем на основных фазах
жизненного цикла программного обеспечения ИУС.
Значение для теории. Результаты, полученные при выполнении диссертационной работы, создают теоретическую основу для разработки моделей, методов и алгоритмов, направленных на эффективный анализ архитектурной надежности сложных информационно-управляющих систем.
Практическая ценность. Разработанная в диссертации система
модельно-алгоритмической . поддержки многоэтапного анализа
архитектурной надежности сложных программных систем позволяет
« осуществить обоснованный выбор варианта программной архитектуры и
оценить степень надежности программных приложений «клиент-сервер» корпоративных систем управления предприятиями.
На основе предложенных автором моделей и алгоритмов осуществлено надежностное формирование программной архитектуры автоматизированной системы технической диагностики и контроля, позволившее решить новые задачи по качественной оценке (экспресс-анализ) и быстрому восстановлению программной системы при введении оптимальной избыточности сбойных программных компонент.
Универсальная модель анализа архитектурной надежности применяется для программных систем, созданных как в рамках объектно-орентированного, так и мультиверсионного объектно-ориентированного подхода, учитывает распределенность и многоуровневость архитектуры системы и позволяет выявлять как критичные по надежности компоненты программных систем, так и диапазоны входных значений, в наибольшей
степени влияющие на надежность компонента.
Достоверность полученных результатов подтверждается тестированием и оценкой результатов применения разработанной системы в реальных проектах, а также согласованностью расчетных и экспериментальных данных.
Реализация результатов работы. Диссертационная работа выполнялась по проектам межотраслевых программ Минобразования России и Минатома России по направлению «Научно-инновационное сотрудничество» (проект VII-12), а также в рамках тематического плана НИР СибГАУ (2002-2005 гг.) и НИР КГТУ (2003-2005 гг.).
При использовании системы модельно-алгоритмической поддержки реализован модуль многоэтапного анализа архитектурной надежности распределенного ПО клиент-серверных приложений корпоративной системы управления предприятием «Галактика».
Разработанные на основе формальных моделей и алгоритмов
< программные системы анализа архитектурной надежности сложных
программных систем прошли экспертизу и зарегистрированы в Отраслевом фонде алгоритмов и программ (№ гос. регистрации 50200500208), что делает их доступными широкому кругу специалистов по системному анализу, надежностному моделированию и оптимизации сложных информационно-управляющих систем.
Материалы диссертационной работы введены в учебные курсы и используются при чтении лекций студентам кафедры информатики Красноярского государственного технического университета по дисциплинам «Программирование» и «Разработка программного обеспечения для информационно-управляющих систем».
На защиту выносятся:
универсальная модель и модификации универсальной модели анализа архитектурной надежности сложных программных систем, учитывающие многоуровневость и распределенность корпоративных информационно-управляющих систем с программной архитектурой «клиент-сервер»;
методика автоматизированного экспресс-анализа эффективности функционирования программной архитектуры автоматизированной системы технической диагностики и контроля;
модель и алгоритм оценки операционной надежности объектно-ориентированной архитектуры программной системы, предназначенной для обработки и хранения информации;
- система модельно-алгоритмической поддержки многоэтапного
анализа архитектрурной надежности сложных программных систем.
Апробация работы. Основные положения и результаты работы прошли всестороннюю апробацию на следующих всероссийских конференциях, научных семинарах и научно-практических конференциях:
- ежегодной Всероссийской электронной научно-технической
конференции Российской академии естествознания «Приоритетные
направления развития науки, технологий и техники» (Москва, 2004/2005);
Всероссийской научно-технической конференции «Современные проблемы радиоэлектроники» (Красноярск, 2005);
международной научной конференции «Татищевские чтения: актуальные проблемы науки и практики» (Тольятти, 2005);
Всероссийской научно-методической конференции «Совершенствование системы управления качеством подготовки специалистов» (Красноярск, 2001);
- научно-практической конференции «Актуальные проблемы науки в
России», Выпуск 2, 3 (Кузнецк, 2003 и 2005);
- еженедельных межвузовских семинарах Сибирского государ
ственного технологического университета (Красноярск, 2001/2002).
Диссертационная работа в целом обсуждалась на научных семинарах кафедры информатики Красноярского государственного технического университета (2002-2005 гг.) и кафедры системного анализа и исследования опрераций Сибирского государственного аэрокосмического университета (2004-2005 гг.).
Публикации. По теме диссертации опубликовано 11 печатных работ. Полный список публикаций представлен в конце автореферата.
Структура и объем работы. Диссертация состоит из введения, пяти глав, заключения и списка литературы.
Программная архитектура информационно-управляющих систем
Объективное повышение сложности функций, реализуемых архитектурными компонентами программных систем, непосредственно приводит к увеличению их объема и трудоемкости создания. Соответственно росту сложности программ возрастает количество выявляемых и остающихся в них дефектов и ошибок, что отражается на качестве функционирования. Разработка и сопровождение сложных ПС на базе современных технологий позволяет предупреждать и устранять наиболее опасные системные и алгоритмические ошибки на ранних стадиях проектирования, а также использовать неоднократно проверенные в других проектах программные и информационные компоненты архитектуры ПС высокого качества.
Обширной практикой [31-36,40,49] доказано, что обнаружение и устранение ошибок и дефектов в комплексах программ на начальных этапах проектирования в десятки и сотни раз быстрее и дешевле, чем в процессе завершения разработки испытаний. По мере увеличения сложности задач, решаемых программами, ошибки могут угрожать катастрофами в системах, выполняющих критические функции управления крупными, дорогими и особенно важными объектами или процессами.
Многочисленные провалы проектов сложных программных систем показали необходимость формализации взаимодействия и обеспечения взаимопонимания разработчиков с заказчиком или потенциальным пользователем создаваемой ПС с самого начала проекта с целью конкретизации функций и уточнения требований качеству разрабатываемого решения. Многие ошибки, обусловленные неопределенностью или некорректностью технических заданий и спецификаций требований, могут и должны быть выявлены на ранних стадиях архитектурного проектирования ПС. Тем самым должен обеспечиваться поступательный ход процесса разработки ПС, без возвратов для уточнения или переделки архитектурно-связанных компонентов или даже всего комплекса программ.
За последние несколько лет создано множество международных стандартов, регламентирующих процессы и продукты жизненного цикла программных систем и систем управления базами данных (СУБД) [6,31]. Международные стандарты ISO содержат результаты обобщения мирового опыта в различных сферах производства и применения продукции и носят рекомендательный характер. Одна из серий стандартов (ISO 9000) содержит и развивает основное положение о том, что «поставщик должен разрабатывать и поддерживать в рабочем состоянии документально оформленную систему качества как средство, обеспечивающее соответствие продукции установленным требованиям заказчика». Применение этих стандартов может служить основой для систем обеспечения качества программных систем, однако требуется корректировка, адаптация или исключение некоторых положений стандартов применительно к принципиальным особенностям технологий и характеристик этого вида продукции. Кроме того, при реализации систем качества ПС необходимо привлечение ряда стандартов, формально не относящихся к этой серии и регламентирующих показатели качества, верификацию и тестирование, испытания, документирование и другие особенности ЖЦ комплексов программ.
В России в области обеспечения жизненного цикла и качества сложных программных систем существует и применяется очень небольшая группа устаревших стандартов (ГОСТов), которые отстают от мирового уровня на 5—10 лет [31]. Эти стандарты вынуждены использовать предприятия, выполняющие государственные заказы при создании ПС для применения внутри страны. Однако в экспортных заказах зарубежные клиенты требуют соответствия технологии проектирования, производства и качества продукции современным международным стандартам, которые необходимо осваивать и применять для обеспечения конкурентоспособности продукции на мировом рынке.
В отечественных программных системах все больше применяют программные компоненты и продукты зарубежных фирм, которые также не могут быть абсолютно гарантированы от проявления дефектов проектирования, программирования и документации. Для обеспечения требуемого качества функционирования комплексов программ с использованием импортных компонентов следует закупать только лицензионно-чистые продукты, поддерживаемые гарантированным сопровождением конкретных поставщиков. Эти компоненты архитектуры ПС должны сопровождаться полной эксплуатационной и технической документацией, сертификатом соответствия и комплектами тестов. Иначе, качество программной, продукции остается низким, неподдающимся достоверной оценке и не конкурентоспособным на международном рынке.
В связи с изложенным появилась настоятельная потребность в разработке эффективного модельно-алгоритмического обеспечения методов и средств надежностного анализа программных архитектур, реализуемого в виде интерактивных пользовательских сред экспресс-анализа, ориентированных на специалистов предметной области. Работы в данной области надежностного исследования архитектур сложных программных систем требуют больших затрат, однако современные масштабы программных разработок и внедрения информационно управляющих систем (в том числе, информационно-технологических комплексов систем реального времени), не оставляют сомнений в экономической целесообразности, своевременности и актуальности поставленных в диссертации задач.
Анализ фазы архитектурного дизайна
Рассмотрим распределение моделей и методов оценки параметров надежности по фазам жизненного цикла разработки программных систем. В общем случае жизненный цикл ПО можно разделить на следующие фазы [9,12,40,48,50,58]: 1. Концептуальная фаза. Построение общей концепции будущей информационной системы. Аналитики и эксперты проблемной области изучают поставленные задачи. Результатом фазы является общая концепция построения системы. 2. Определение требований. На данном этапе разработчики взаимодействуют с заказчиком для выявления потребностей и требований к системе. На этом этапе делается незначительное количество ошибок. Изменение требований на более поздних стадиях может повлечь появление большого количества ошибок. 3. Дизайн архитектуры. Строится спецификация взаимосвязей модулей таким образом, что каждый модуль четко разделен, разрабатывается и тестируется независимо. Дизайн может пересматриваться для выявления ошибок. 4. Кодирование. На данном этапе пишется реальный код программы, как правило, на языке высокого уровня. Иногда возможно использование низкоуровневых языков программирования для достижения высокой производительности или для сопряжения с нестандартной аппаратурой. Код постоянно анализируется на предмет наличия ошибок. 5. Тестирование. Эта фаза одна из самых важных и трудоемких. Может занимать от 30 до 60% временных и материальных ресурсов проекта. Обычно разделяется на несколько последовательных фаз. 5.1. Тестирование модулей. На этом этапе каждый модуль тестируется отдельно, делаются модификации модуля для исправления ОШИбОК. КАЖДЫЙ модуль значительно меньше всей программы и может быть более тщательно протестирован. 5.2. Групповое тестирование. Модули группируются в подсистемы. Подсистемы тестируются независимо. Позволяет выявить ошибки в интерфейсах между модулями. Добавление и удаление модулей из подсистемы позволяет проще идентифицировать ошибки. 5.3. Тестирование системы. Тестируется вся система полностью. Отладка происходит до тех пор, пока не будет достигнут какой-либо критерий. Цель данного этапа - определить максимально возможное количество ошибок за минимальное время. 5.4. Тестирование приемлемости. Цель - оценка производительности и надежности в определенной операционной системе. Собирается информация о том, как пользователи будут использовать систему. Это называется «альфа-тестирование». Могут привлекаться реальные пользователи - в этом случае называется «бета-тестирование». 6. Использование. Система эксплуатируется и ошибки, выявленные пользователями, не исправляются пока не выйдет новая версия ПО. 7. Регрессивное тестирование. Новая версия тестируется на работоспособность и проверяется, не уменьшилась ли (регрессировала) надежность ПО. Известно, что наиболее важными являются фазы, которые вносят наибольший вклад в надежность ПО: фаза дизайна архитектуры, фаза кодирования, фаза тестирования компонент и фаза тестирования системы. В работе основное внимание уделено фазе архитектурного проектирования сложных программных систем, поэтому далее проведем детализацию содержания этапов архитектурного проектирования. 2.2. Анализ фазы архитектурного дизайна Широкое применение средств вычислительной техники породило понятие «архитектура ПО», которое, несмотря на свою распространенность, воспринимается, как правило, интуитивно и употребляется чаще всего при сравнении вычислительных машин. Под архитектурой ПО, как и вообще любых других средств обработки информации, понимают в узком смысле совокупность их свойств и характеристик, призванных удовлетворить запросы пользователей. В более широком смысле, архитектура ПО - обобщенная модель информационной системы, достаточная для понимания принципов ее функционирования. 2.2.1. Создание архитектуры программного обеспечения, как этап проектирования информационной системы Разработка архитектуры — это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы и уровни абстракции. Процесс разработки архитектуры — необходимый шаг в процессе проектирования программной системы или комплекса программ (КП) систем управления различного функционального назначения. КП представляет собой набор решений множества различных, но связанных между собой функциональных задач. 2.2.2. Зависимость системной надежности от архитектуры программной системы Надежность архитектуры включает в себя надежность индивидуальных элементов. Сбой отдельного элемента приводит к неработоспособности этого и, возможно, других элементов, но не всей системы в целом. Сбой в системе или ее функциях может выразиться в периоде простоя системы. Период простоя системы определятся, как отрезок времени, на котором система или ее часть не может выполнять функции. Период простоя системы приводит к резкому снижению производительности, поэтому уменьшение времени простоя системы является одним из наиболее важных факторов при разработке архитектур распределенного программного обеспечения.
Описание предлагаемой модели анализа архитектурной надежности
В качестве исходной рассматривается динамическая модель надежности для большой программной архитектуры телекоммуникационных систем реального масштаба времени [18,75]. Архитектурные зависимости компонентов позволяют неисправности распространяться из компонента, в котором она происходит к другим компонентам. Это распространение может вызывать сбои в цепочке (или в дереве) компонентов. Обнаружение отказов зависит от выполненных тестов или от количества и типа запросов пользователя. Ошибка может произойти в любом компоненте. Эта ошибка может быть вызвана неисправностью, переданной другим компонентом или это может быть неисправность произошедшая именно в этом компоненте. Ошибка может быть прослежена, через цепочку (или дерево) зависимости компонентов для устранения всех сбоев, которые связаны с этой ошибкой. Исходная модель надежности программного обеспечения использована при разработке проекта большой архитектуры телекоммуникационного ПО.
Архитектурные уровни модели надежности. Модель надежности ПО включает уровни, соответствующие различным компонентам и их зависимостям. В зависимости от того, где произошел сбой, длительность отказа системы и его влияние на надежность системы различны. Сбой может происходить на различных уровнях архитектуры, в модуле, процессе, интерфейсе компонента или в связи и механизме контроля.
Ранее отмечалось, что число архитектурных уровней в модели архитектуры ПО зависит от проекта системы. В примере модели архитектуры показанной на рис. 2.1 имеются два уровня компонентов программного обеспечения: модули и процессы. Каждый архитектурный уровень содержит граф компонентов каждого типа (граф модулей и граф процессов). Сплошные линии представляют дуги каждого графа внутри одного архитектурного уровня, прерывистые линии показывают соединения между архитектурными уровнями. Обратите внимание, что оба графа - направленные. Процессы используют модули в течение их выполнения: эти зависимости показаны прерывистыми линиями. Процесс может использовать несколько различных модулей, и модуль может использоваться несколькими различными процессами. Граф процессов представляет динамическую зависимость компонентов, а граф модулей представляет статическую зависимость компонентов. Эта архитектура может быть расширена до произвольного числа уровней с графами компонентов на различных уровнях.
В модели архитектуры граф процессов находится на самом верхнем уровне, а графы остальных компонентов, например - функции, примитивы, данные, структуры и сообщения находятся на отдельных уровнях. Используемые параметры и обозначения Для анализа надежности больших архитектур телекоммуникационного ПО реального времени используются следующие параметры и обозначения (заметим, что параметры компонентов применяются отдельно для каждого уровня архитектуры ПО): Обозначения: М число архитектурных уровней в архитектуре ПО; Nj число компонентов на уровне j, j є {1,..,М); Djj множество индексов компонентов, зависящих от компонента і на уровнеj,ie{l,..,Nj}, je{l,..,M}; F,j событие сбоя, произошедшего в компоненте і на уровне j, ie{l,..,Nj}, JG{1,..,M}; PUjj вероятность использования компонента і на уровне j, ie{l,..,Nj}, je{l,..,M}; PFjj вероятность появления сбоя в компоненте і на уровне j, ie{l,..,Nj}, je{l,..,M}; PL Jnm условная вероятность появления сбоя в компоненте m на уровне п при появлении сбоя в компоненте і на уровне j іє{l,..,Nj}, je{l,..,M}, ne{l,..,Nm}, тє{1,..,М}; TAy относительное время доступа к компоненту і на уровне j, ie{l,..,Nj}, je{l,..,M}, определяемое как отношение среднего времени доступа к компоненту і на уровне j к числу сбойных компонентов на малых уровнях архитектуры за одно и тоже время; TCjj относительное время анализа сбоя в компоненте і на уровне j, іє{l,..,Nj}, je{l,..,M}, определяемое как отношение среднего времени анализа сбоя в компоненте і на уровне j, ie{l,..,Nj}, j{l,..,M}, к числу сбойных компонентов на всех уровнях архитектуры, анализируемых в одно и тоже время.
Особенности архитектуры корпоративных информационно-управляющих систем
Очевидно, что вычислить транзакционную надежность системы можно только после составления операционных профилей и весовых векторов всех классов, т.е. только после полного тестирования готовой системы. Основное преимущество данной модели заключается в том, что все параметры данной модели можно получить из данных после теста системы, что дает возможность построить оценки параметров надежности [14,58].
Такая модель является полезной для оценки информационных систем обработки и хранения данных, например, для современных ERP-систем. 1. Введенные показатели архитектурной надежности программных систем устанавливают взаимосвязь между потенциально возможной производительностью и надежностью (безотказностью, готовностью) системы, т.е. характеризуют качество функционирования системных архитектур безотносительно к процессу решения функциональных задач программной системы. 2. На фазе анализа объектно-ориентированной программной системы под архитектурой ПС понимается совокупность иерархий классов. Каждый класс - совокупность свойств (переменных) и методов (функций) объекта.: Процесс - последовательный переход от метода одного класса к методу другого класса. 3. Под компонентом в объектно-ориентированной модели понимается класс или метод с операционными профилями, участвующих в финальной сборке системы. Класс рассматривается как компонент для оценки общей надежности системы - совокупности классов для решения задач из определенной проблемной области. 4. Для оценки архитектурной надежности сложных программных систем обработки и хранения данных (логической единицей работы в них является транзакция) определено понятие транзакционной надежности, которая зависит не только от надежности компонент, но и от конкретной проблемной области для которой ПС была разработана, формально - от набора операционных профилей программных компонент системы. 5. Архитектурная модель, учитывающая транзакционную надежность компонент ПС, может быть использована для анализа современных ERP систем. При этом для вычисления общей надежности R,r необходимо составить полный перечень всех транзакций и вычислить надежность каждой транзакции с использованием операционных профилей. 4. Модель архитектурной надежности приложений клиент-сервер комплексной системы автоматизации управления предприятием В данном разделе рассматривается анализ системной архитектуры программного обеспечения приложений клиент-сервер комплексной системы автоматизации управления предприятием, которая моделируются как набор сервисов, предоставляемых сервером клиентским процессам. Предлагаются процедуры вычисления показателей, определяющих безотказность и работоспособность программного обеспечения приложений клиент-сервер. 4.1. Особенности архитектуры корпоративных информационно-управляющих систем В [2] отмечается, что архитектуру корпоративных информационно-управляющих систем (КИУС) можно рассматривать с разных позиций. Функциональная архитектура КИУС определяет состав функциональных подсистем и комплексов задач, обеспечивающих реализацию бизнес-процессов. В соответствии с функциональной архитектурой формируются организационные компоненты системы, в первую очередь, это сеть коммуникаций, рабочие станции (автоматизированные рабочие места, АРМ) конечных пользователей и серверная подсистема сети, определяется их взаимодействие. Информационно-технологическая архитектура включает в себя аппаратно-программную платформу реализации КИУС, организационную форму базы данных, архитектуру и топологию компьютерной сети, средства телекоммуникации, комплекс технических средств обработки данных. Определяется информационно-технологическая архитектура КИУС используемыми программными и техническими средствами, в том числе средствами телекоммуникации и системами управления базами данных (СУБД). Компьютерные сети являются неотъемлемой и важнейшей частью КИУС, во многом определяющей ее архитектуру. На сегодняшний день сложились типовые информационно-технологические структуры КИУС и соответствующие структуры корпоративных компьютерных сетей (ККС).
Похожие диссертации на Многоэтапный анализ архитектурной надежности в сложных информационно-управляющих системах
