Неправильный перевод информации как причина ошибок в программных средствах

СОДЕРЖАНИЕ: уметь оценивать сложность системы по числу её элементов, а именно по числу потенциальных путей взаимодействия между её элементами, т. е. п!, где п - число её элементов. Систему назовем малой, если п 7 (6! = 720 1000), систему назовем большой, если п 7. При п=7 имеем промежуточный класс систем.

уметь оценивать сложность системы по числу её элементов, а именно по числу потенциальных путей взаимодействия между её элементами, т. е. п!, где п - число её элементов. Систему назовем малой, если п 7 (6! = 720 1000), систему назовем большой, если п 7. При п=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Человек, создавший большую систему (систему требований, систему управления, программную сис­тему и т. п.), рискует увязнуть в переборе большого числа вариантов. Задача технологии программирования - научиться делать большие сис­темы простыми.

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

2.2. Неправильный перевод информации как причина ошибок в программных средствах

При разработке и использовании ПС мы многократно имеем дело [35, с. 22-28] с преобразованием (переводом) информации из одной формы в другую (см. рис. 2.1). Заказчик формулирует свои потребности в ПС в виде некоторых требований. Исходя из этих требований, разра­ботчик создает внешнее описание ПС, используя при этом специфика­цию (описание) заданной аппаратуры и, возможно, спецификацию ба­зового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является ис­ходной информацией при любом ее преобразовании, в частности, при исправлении в ней ошибки.

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

На каждом из этих этапов перевод информации может быть осуще­ствлён неправильно. Возникнув на одном из этапов разработки ПС, ошибка в представлении информации преобразуется в новые ошибки результатов, полученных на последующих этапах разработки, и, в ко­нечном счёте, окажется в ПС.

2.3. Модель перевода

Чтобы понять природу ошибок при переводе рассмотрим модель [35, с. 22-28], изображённую на рис. 2.2. На ней человек осуществляет перевод информации из представления А в представление В. При этом он совершает четыре основных шага перевода:

• он получает информацию, содержащуюся в представлении А, с по­мощью своего читающего механизма R;

• он запоминает полученную информацию в своей памяти М;

• он выбирает из своей памяти преобразуемую информацию и инфор­мацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;

• с помощью этого механизма он фиксирует представление В.

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

стремление человека быстрее зафиксировать информацию часто приво­дит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной ее интерпретации.

2.4. Основные пути борьбы с ошибками

Учитывая рассмотренные особенности действий человека при пе­реводе можно указать следующие пути борьбы с ошибками:

• сужение пространства перебора (упрощение создаваемых систем),

• обеспечение требуемого уровня подготовки разработчика (это функ­ции менеджеров коллектива разработчиков),

• обеспечение однозначности интерпретации представления информа­ции,

• контроль правильности перевода (включая и контроль однозначно­сти интерпретации).

Вопросы к главе 2

2.1. Что такое простая и сложная системы!

2.2. Что такое малая и большая системы!

2.3. Перечислите основные шаги, осуществляемые человеком при пере­воде информации из одного представления в другое, и какого рода ошибки он может совершать на этих шагах?

Лучшее - враг хорошего.

Народная мудрость

Глава 3

ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ

ПРОГРАММНЫХ СРЕДСТВ

Специфика разработки программных средств. Жизненный цикл про­граммного средства. Понятие качества программного средства. Обеспечение надёжности - основной мотив разработки программного средства. Методы борьбы со сложностью программных средств. Обеспечение точности пере­вода. Преодоление барьера между пользователем и разработчиком. Обеспе­чение контроля правильности принимаемых решений.

3.1. Специфика разработки программных средств

Разработка программных средств имеет ряд специфических осо­бенностей [22].

• Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а, как известно, переход от неформального к формальному существенно неформален.

• Разработка ПС носит творческий характер (на каждом шаге прихо­дится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регла­ментированных действий. Тем самым, эта разработка ближе к про­цессу проектирования каких-либо технических устройств, но никак не к их массовому производству. Этот творческий характер разра­ботки ПС сохраняется до самого её конца.

• Следует отметить также особенность продукта разработки. Он пред­ставляет собой некоторую совокупность текстов (т. е. статических объектов), смысл же (семантика) этих текстов выражается процесса­ми обработки данных и действиями пользователей, запускающих эти процессы (т. е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приёмов, методов и средств.

• Продукт разработки имеет и другую специфическую особенность: ПС при своём использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.

Эти особенности превращают разработку программных средств в уникальный вид человеческой деятельности. Первая особенность озна­чает, что разработка ПС является в значительной степени формализаци­ей описаний требуемых процессов обработки данных, при этом сохра­няется опасность, что полученное формальное описание будет недоста­точно точно отражать неформальное описание требуемых процессов обработки данных. Вторая особенность позволяет заметить сходство разработки ПС с проектированием технического устройства, но это сходство продолжается до самого конца разработки ПС. Другими сло­вами, можно сказать, что ПС является своим собственным проектом, а процесс его производства является вырожденным. В связи с этим весь­ма осторожно следует относиться к так называемому индустриальному подходу к разработке программных средств (точно так же, как бы мы относились к индустриальному подходу к проектированию). Третья особенность означает, что статическая форма представления программ­ного продукта слишком мало говорит о его приемлемости для пользо­вателя, ценности и надёжности. Всё это может быть выявлено только в результате его применения на компьютере. Четвёртая особенность от­ражает уникальные свойства информации: ПС как информационный объект после каждого его применения сохраняется в неизменном со­стоянии (не уменьшается, не «устает», не «стареет»). Его надёжность не связана со временем или интенсивностью его применения. Каждое его применение связано с работой компьютера, на котором ПС для выпол­нения своих функций использует память, каналы ввода и вывода и дру­гие ресурсы компьютера. После применения этого ПС все эти ресурсы сохраняются в компьютере и могут использоваться при применении другого ПС.

3.2. Жизненный цикл программного средства

Под жизненным циклом ПС { software life cycle ) понимают весь пе­риод его разработки и эксплуатации (использования), начиная от мо­мента возникновения замысла ПС и кончая прекращением всех видов его использования [22, 24, 25, 44]. Жизненный цикл охватывает доволь­но сложный процесс создания и использования ПС. Этот процесс может

быть организован по-разному для разных классов ПС и в зависимости от особенностей коллектива разработчиков.

В настоящее время можно выделить пять основных подходов к ор­ганизации процесса создания и использования ПС [65].

• Водопадный подход. При таком подходе разработка состоит из це­почки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требо­вания к ПС. В конце этой цепочки создаются программы, включае­мые в ПС.

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

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

• Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы пу­тем корректных преобразований. На этом подходе базируется ком­пьютерная технология (CASE-технология) разработки ПС.

• Сборочное программирование. При этом подходе предполагается, что ПС конструируется, главным образом, из программных компо­нент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может много­кратно использоваться в разных ПС. Такие компоненты называются

повторно используемыми { reusable ). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования [32].

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

В рамках водопадного подхода различают следующие стадии жиз­ненного цикла ПС (см. рис. 3.1): разработку ПС, производство про­граммных изделий (ПИ) и эксплуатацию ПС.

Стадия разработки ПС { software development ) состоит из этапов его внешнего описания, конструирования ПС, кодирования (программиро­вание в узком смысле) ПС и аттестации ПС. Всем этим этапам сопутст­вуют процессы документирования и управления ПС { software manage ­ ment ). Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых час­тей программного средства может быть начато до завершения этапа конструирования.

Этап внешнего описания ПС включает процессы, приводящие к созданию документа, который мы будем называть внешним описанием ПС { software requirements document ). Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюда­теля с фиксацией требований относительно его качества. Внешнее опи­сание ПС начинается с анализа и определения требований к ПС со сто-

роны пользователей (заказчика), а также включает процессы спе­цификации этих требований.

Рис. 3.1. Структура жизненного цикла ПС

Конструирование ПС { software design ) охватывает процессы: раз­работку архитектуры ПС, разработку структур программ ПС и их де­тальную спецификацию.

Кодирование ПС { software coding ) включает процессы создания текстов программ на языках программирование, их отладку с тестиро­ванием ПС.

На этапе аттестации ПС { software certfication ) производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается закон­ченной. Это обычно оформляется в виде документа, фиксирующего ре­шение комиссии, проводящей аттестацию ПС.

Программное изделие (ПИ) - экземпляр или копия разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [22]. Стадия производства ПИ в жизненном цикле ПС является, по существу, вырожденной (не сущест-

венной), так как представляет собой рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники, поэтому в лите­ратуре эту стадию, как правило, не включают в жизненный цикл ПС.

Стадия эксплуатации ПС охватывает процессы хранения, внедре­ния и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [44, 65].

Применение ПС ( software operation ) - это использование ПС для решения практических задач на компьютере путём выполнения его про­грамм.

Сопровождение ПС ( software maintenance ) - это процесс сбора ин­формации о качестве ПС в эксплуатации, устранения обнаруженных в нём ошибок, его доработки и модификации, а также извещения пользо­вателей о внесённых в него изменениях [22, 44, 65].

3.3. Понятие качества программного средства

Каждое ПС должно выполнять определённые функции, т. е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течение длительно­го периода, т. е. обладать определённым качеством. Качество (quality) ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданным потребностям пользователей [59]. Из этого определения не следует, что разные ПС должны обладать одной и той же совокупностью таких свойств с их наилучшими показа­телями, поскольку улучшение одного из таких свойств ПС часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и ухудшения других свойств этого ПС. Качество ПС являет­ся удовлетворительным, когда оно обладает указанными свойствами в такой степени, в какой гарантируется успешное его использование.

Совокупность свойств, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуата­ции этого ПС, т. е. от позиции, с которой должно рассматриваться каче­ство этого ПС. Поэтому при описании качества ПС должны быть фик­сированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteriaofsoftwarequality) принято считать [7, 30,49,59,63]:

• лёгкость применения,

• надёжность,

• функциональность,

• эффективность,

• сопровождаемость,

• мобильность.

Функциональность ( functionality ) ПС - это способность ПС выпол­нять набор функций, удовлетворяющих заданным или подразумевае­мым потребностям пользователей. Этот набор определяется во внешнем описании ПС.

Надёжность ПС подробно обсуждалась в первой главе.

Лёгкость применения ( easy of use ) ПС - это характеристики ПС, позволяющие минимизировать усилия пользователя по подготовке ис­ходных данных, применению ПС и оценке полученных результатов, а также вызывающие положительные эмоции определённого или подра­зумеваемого пользователя.

Эффективность ( efficiency ) ПС - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объёму используемых ресурсов.

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

Мобильность ( portability ) ПС - это способность ПС быть перене­сённым из одной среды применения в другую, в частности, с одного компьютера на другой.

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

3.4. Обеспечение надёжности - основной мотив разработки программных средств

Рассмотрим теперь общие принципы обеспечения надёжности ПС, что является основным мотивом разработки ПС, задающим специфиче-

скую окраску всем технологическим процессам разработки ПС. В тех­нике известны четыре подхода обеспечению надёжности [35]:

• предупреждение ошибок,

• самообнаружение ошибок,

• самоисправление ошибок,

• обеспечение устойчивости к ошибкам.

Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах (в нашем случае - в ПС) или хотя бы свести их ко­личество к минимуму. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:

• упрощение создаваемой ПС,

• обеспечение точности перевода,

• преодоление барьера между пользователем и разработчиком в пони­мании информации, которой они обмениваются,

• обеспечение контроля принимаемых решений.

Этот подход связан с организацией процессов разработки ПС, т. е. с технологией программирования. И хотя, как мы уже отмечали, гаранти­ровать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надёжности ПС.

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

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

3.5. Методы упрощения создаваемой ПС

Мы уже обсуждали в главе 2 сущность вопроса упрощения систем при разработке ПС. Известны два общих метода упрощения систем:

• обеспечения независимости компонент системы,

• использование в системах иерархических структур.

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

3.6. Обеспечение точности перевода

Обеспечение точности перевода направлено на достижение одно­значности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует при переводе информации при­держиваться определённых правил (определённой дисциплины). Май-ере предлагает использовать общую дисциплину решения задач, рас­сматривая перевод как решение задачи [35]. Лучшим руководством по решению задач он считает книгу Пойа «Как решать задачу» [38]. В со­ответствии с этим весь процесс перевода можно разбить на следующие этапы:

• обеспечение понимания задачи;

• составление плана (включая цели и методы решения);

• выполнение плана (с проверкой правильности каждого шага);

• анализ полученного решения.

Подробно обсуждать этот вопрос мы здесь не будем.

3.7. Преодоление барьера между пользователем и разработчиком

Как обеспечить, чтобы ПС выполняла то, что пользователю разум­но ожидать от нее? Для этого разработчикам необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, знать его уровень подготовки и окружающую его обстановку. Ясное описание соответствующей сферы деятельности пользователя или интересующей его проблемной области во многом облегчает достижение разработчи­ками этой цели. При разработке ПС следует привлекать пользователя для участия в процессах принятия решений, а также тщательно освоить особенности его работы (лучше всего - побывать в его шкуре).

3.8. Контроль принимаемых решений

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

С учётом специфики разработки ПС необходимо применять везде, где это возможно,

• смежный контроль,

• сочетание как статических, так и динамических методов контроля.

Смежный контроль означает, проверку полученного документа ли­цами, не участвующими в его разработке, с двух сторон: во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут использовать полученный документ в качестве исходного в последующих технологических процессах. Та­кой контроль позволяет обеспечивать однозначность интерпретации полученного документа.

Сочетание статических и динамических методов контроля означа­ет, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отража­ет одну из специфических особенность ПС (статическая форма, дина­мическое содержание).

Вопросы к главе 3

3.1. Что такое жизненный цикл ПС1

3.2. Что такое внешнее описание ПС1

3.3. Что такое сопровождение ПС!

3.4. Что такое качество ПС!

3.5. Что такое смежный контроль!

Не переходи мост, пока не дошёл до него. Народная пословица

Глава 4

ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО

СРЕДСТВА

Понятие внешнего описания, его назначение и роль в обеспечении каче­ства программного средства. Определение требований к программному сред­ству. Спецификация качества программного средства. Основные примитивы качества программного средства. Функциональная спецификация программ­ного средства. Контроль внешнего описания.

4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства

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

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

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

внешнем описании, в конечном счёте, трансформируются в ошибки са­мой ПС и обходятся особенно дорого, во-первых, потому, что они де­лаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три упомянутые параллельных процесса. Это требует принятия особенно серьёзных мер по их предупреждению.

Исходным документом для разработки внешнего описания ПС яв­ляется определение требований к ПС. Через этот документ передается от заказчика (пользователя) к разработчику основная информация отно­сительно требуемого ПС, поэтому формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком. Трудно­сти, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в узких местах деятельности пользователей может на са­мом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадывают­ся). Кроме того, проблемы, которые необходимо отразить в определе­нии требований, могут не иметь определённой формулировки [65], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесо­образно и реализуемо заказываемое ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обла­дать. Иногда бывает полезным разработка упрощенной версии требуе­мого ПС, называемую прототипом ПС. Анализ пробного применения прототипа позволяет выявить действительные потребности пользовате­лей и существенно уточнить требования к ПС.

В определении внешнего описания сразу бросаются в глаза две са­мостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональ­ной спецификацией ПС. Функциональная спецификация определяет до­пустимые фрагменты программ, реализующих декларированные функ­ции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [35], которые он должен стремить­ся достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (ее часто называют не­функциональной спецификацией [65], но в этом случае она включает и требования к технологическим процессам). Она, в отличие от функцио-

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

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

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

4.2. Определение требований к программному средству

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

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

Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль тре­буемого ПС в среде его использования [65]. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований предста­вить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т. п.) и характеристики связей между ними.

Известны три способа разработки определения требований к ПС [35]:

• управляемая пользователем разработка,

• контролируемая пользователем разработка,

• независимая от пользователя разработка.

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

В контролируемой пользователем разработке, требования к ПС формулируются разработчиком при участии представителя пользовате­лей. Роль пользователя в этом случае сводится к информированию раз­работчика о своих потребностях в ПС, а также к контролю того, чтобы формулируемые требования действительно выражали его потребности в

ПС. Разработанные требования, как правило, утверждаются представи­телем пользователя.

В независимой от пользователя разработке, требования к ПС оп­ределяются без какого-либо участия пользователя (на полную ответст­венность разработчика). Это происходит обычно тогда, когда разработ­чик решает создать ПС широкого применения в расчёте на то, что раз­работанное им ПС найдёт спрос на рынке программных средств.

С точки зрения обеспечения надёжности ПС наиболее предпочти­тельным является контролируемая пользователем разработка.

4.3. Спецификация качества программного средства

Разработка спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС [22, 35]. В этой модели должен быть перечень всех тех свойств, которые необходимо обеспечить в этом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной мере конкретизировано с учётом определения требований к ПС, а также с учётом возможности оценки его наличия у разработанного ПС или оценки степени, в которой ПС обладает этим свойством.

Для конкретизации качества ПС по каждому из критериев исполь­зуется стандартизованный набор достаточно простых свойств ПС, раз­работанных ISO [7, 22, 59, 63], однозначно интерпретируемых разра­ботчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от при­митивов качества ПС.

Функциональность: завершённость.

Надёжность: завершённость, точность, автономность, устойчи­вость, защищённость.

Лёгкость применения: П-документированность, информативность (применительно к документации по применению), коммуникабель­ность, устойчивость, защищённость.

Эффективность: временная эффективность, эффективность по ре­сурсам (по памяти), эффективность по устройствам.

Сопровождаемоеть. С данным критерием связано много различ­ных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифици-

руемость. Изучаемость - это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и доку­ментации ПС. Модифицируемость - это характеристики ПС, которые по­зволяют автоматически настраивать на условия применения ПС или уп­рощают внесение в него вручную необходимых изменений и доработок.

Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.

Модифицируемость: расширяемость, лёгкость изменения, структу­рированность, модульность.

Мобильность: независимость от устройств, автономность, структу­рированность, модульность.

Ниже определяются используемые примитивы качества ПС [22, 59, 63]. Здесь приводится достаточно большой список, состоящий из 19 примитивов качества, которые следует рассматривать как независимые (самостоятельные) понятия. Некоторые их комбинации образуют более крупные понятия - критерии и подкритерии качества. Такие комбина­ции можно рассматривать как определённые системы. Но ни одна из этих комбинаций не содержит более шести примитивов (см. выше), так что правило, сформулированное в п. 2.1, здесь не нарушается.

Завершённость { completeness ) ПС - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, тре­бующимися для выполнения своих явных и неявных функций.

Точность { accuracy ) ПС - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

Автономность { self - containedness ) ПС - свойство, характеризую­щее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.

Устойчивость { robustness ) ПС - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.

Защищённость { defensiveness ) ПС - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным дест­руктивным (разрушающим) действиям пользователя.

П-документированностъ {и. documentation ) ПС - свойство, харак­теризующее наличие, полноту, понятность, доступность и наглядность

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

Информативность { accountability ) ПС - свойство, характеризую­щее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существую­щих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функ­ционирования.

Коммуникабельность { communicativeness ) ПС - свойство, характе­ризующее степень, в которой ПС облегчает задание или описание вход­ных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием.

Временная эффективность { time efficiency ) ПС - мера, характери­зующая способность ПС выполнять возложенные на него функции в течение определённого отрезка времени.

Эффективность по ресурсам { resource efficiency ) ПС - мера, ха­рактеризующая способность ПС выполнять возложенные на него функ­ции при определённых ограничениях на используемые ресурсы (па­мять).

Эффективность по устройствам { device efficiency ) ПС — мера, ха­рактеризующая экономичность использования устройств компьютера для решения поставленной задачи.

С-документированность ПС { documentation ) - свойство, характе­ризующее с точки зрения наличия документации, отражающей требо­вания к ПС и результаты различных этапов разработки данного ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.

Понятность { understandability ) ПС - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его на­значение, сделанные допущения и ограничения, входные данные и ре­зультаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких при­митивов ISO [59], как согласованность, самодокументированность, чет­кость и, собственно, понятность (текстов программ).

Структурированность { structuredness ) ПС - свойство, харак­теризующее программы ПС с точки зрения организации взаимосвязан­ных их частей в единое целое определённым образом (например, в со­ответствии с принципами структурного программирования).

Удобочитаемость ( readability ) ПС - свойство, характеризующее лёгкость восприятия текста программ ПС (отступы, фрагментация, фор-матированность).

Расширяемость ( augmentability ) ПС - свойство, характеризующее способность ПС к наращиванию объёма памяти для хранения данных или расширению функциональных возможностей отдельных компо­нент.

Лёгкость изменения ( modifiability ) ПС - мера, характеризующая ПС с точки зрения простоты внесения необходимых изменений и дора­боток на всех этапах и стадиях жизненного цикла ПС.

Модульность ( modularity ) ПС - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компо­нент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.

Независимость ПС от устройств ( device independence ) - свойство, характеризующее способность ПС работать на разнообразном аппарат­ном обеспечении (различных типах, марках, моделях компьютеров).

4.4. Функциональная спецификация программного средства

С учётом назначения функциональной спецификации ПС и тяжё­лых последствий неточностей и ошибок в этом документе, функцио­нальная спецификация должна быть математически точной. Это не оз­начает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать программы, решающие поставленную задачу. А означает лишь, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточно часто функ­циональная спецификация формулируется на естественном языке. Тем не менее, использование математических методов и формализованных языков при разработке функциональной спецификации весьма жела­тельно, так что этим вопросам будет посвящена отдельная глава.

Функциональная спецификация состоит из трёх частей:

• описания внешней информационной среды, к которой должны при­меняться программы разрабатываемой ПС;

• определение функций ПС, определённых на множестве состояний этой информационной среды (такие функции будем называть внеш­ними функциями ПС);

• описание нежелательных (исключительных) ситуаций, которые мо­гут возникнуть при выполнении программ ПС, и реакций на эти си­туации, которые должны обеспечить соответствующие программы.

В первой части должны быть определены на концептуальном уров­не все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. При­мером описания информационной среды может быть концептуальная схема базы данных или описание сети датчиков и приборов, которой должна управлять разрабатываемая ПС.

Во второй части вводятся обозначения всех определяемых функ­ций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты. И, наконец, определяется семантика каждой из этих функций, что является наиболее трудной задачей функциональ­ной спецификации ПС. Обычно эта семантика описывается неформаль­но на естественном языке - примерно так, как это делается при описа­нии семантики многих языков программирования. Эта задача может быть в ряде случаев существенно облегчена при достаточно четком описании внешней информационной среды, если внешние функции за­дают какие-либо манипуляции с её объектами.

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

4.5. Методы контроля внешнего описания программного средства

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

этапа будет, как правило, еще неформализованный текст, здесь на пер­вый план выступают психологические факторы контроля. Можно выде­лить следующие методы контроля, применяемые на этом этапе:

• статический просмотр,

• смежный контроль,

• пользовательский контроль,

• ручная имитация.

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

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

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

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

за которым сидит разработчик, играющий роль программ ПС. Получен­ные результаты передаются через компьютер на первый терминал.

Вопросы к главе 4

4.1. Что такое определение требований к ПС!

4.2. Что такое спецификации качества ПС!

4.3. Что такое устойчивость { robustness ) ПС!

4.4. Что такое защищённость ( defensiveness ) ПС!

4.5. Что такое коммуникабельность { communicativeness ) ПС!

4.6. Что такое функциональная спецификация ПС!

А.1. Что такое ручная имитация внешнего описания ПС!

Разделяй и властвуй!

Латинское изречение

Глава 6 АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА

Понятие архитектуры и задачи её описания. Основные классы архитек­тур программных средств. Взаимодействие между подсистемами и архи­тектурные функции. Контроль архитектуры программных средств.

6.1. Понятие архитектуры программного средства

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

Основные задачи разработки архитектуры ПС:

• выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

• определение способов взаимодействия между выделенными программными подсистемами.

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

6.2. Основные классы архитектур программных средств

Различают следующие основные классы архитектур программных средств [35]:

• цельная программа;

• комплекс автономно выполняемых программ;

• слоистая программная система;

• коллектив параллельно действующих программ.

Цельная программа представляет вырожденный случай архитекту­ры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну ка-

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

Комплекс автономно выполняемых программ состоит из набора программ, такого, что:

• любая из этих программ может быть активизирована (запущена) пользователем;

• при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не за­кончит выполнение активизированная программа;

• все программы этого набора применяются к одной и той же информационной среде.

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

Слоистая программная система состоит из упорядоченной сово­купности программных подсистем, называемых слоями, такой, что:

• на каждом слое ничего не известно о свойствах (и даже существова­нии) последующих (более высоких) слоев;

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

• каждый слой располагает определёнными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их аб­стракции.

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

В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [60]. Эта опера­ционная система состоит из четырёх слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение централь-

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

Прикладные программы

3: Управление входными и выходными потоками данных

2: Обеспечение связи с консолью оператора

1: Управление памятью

0: Диспетчеризация и синхронизация процессов

Компьютер

Рис. 6.1. Архитектура операционной системы THE

Коллектив параллельно действующих программ представляет со­бой набор программ, способных взаимодействовать между собой, нахо­дясь одновременно в стадии выполнения. Это означает, что такие про­граммы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько цен­тральных процессоров, а во-вторых, осуществлять между собой дина­мические (в процессе выполнения) взаимодействия, на базе которых производится их синхронизация. Обычно взаимодействие между таки­ми процессами производится путём передачи друг другу некоторых со­общений.

Простейшей разновидностью такой архитектуры является конвей­ер. Возможности для организации конвейера имеются, например, в опе­рационной системе UNIX [28]. Конвейер представляет собой последова-

тельность программ, в которой стандартный вывод каждой программы, кроме самой последней, связан со стандартным вводом следующей про­граммы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступа­ет на ввод первой программе, которая переработанное сообщение пере­даёт следующей программе, а сама начинает обработку очередного со­общения потока. Таким же образом действует каждая программа кон­вейера: получив сообщение от предшествующей программы и, обрабо­тав его, она передаёт переработанное сообщение следующей программе и приступает к обработке следующего сообщения. Последняя програм­ма конвейера выводит результат работы всего конвейера (результи­рующее сообщение). Таким образом, в конвейере, состоящим из п про­грамм, может одновременно находиться в обработке до п сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необхо­димо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо воз­можности передать переработанное сообщение, либо возможности по­лучить очередное сообщение).

Рис. 6.2. Конвейер параллельно действующих программ

В общем случае коллектив параллельно действующих программ может быть организован в систему с портами сообщений. Порт сооб­щений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выда­вать очередное сообщение другой программе по ее требованию. Сооб­щение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и использовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в поряд­ке очереди не будет передано какой-либо программе по ее запросу. Та­ким образом, программа, передающая сообщение, не будет находиться в стадии ожидания, пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен при­нимающий порт).

Пример программной системы с портами сообщений приведен на рис. 6.3. Порт Uможет рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно дейст­вующих программ, а порт W - как порт выводных сообщений для этого коллектива программ.

Рис. 6.3. Пример программной системы с портами сообщений

Программные системы с портами сообщений могут быть как жёст­кой конфигурации, так и гибкой конфигурации. В системах с портами жёсткой конфигурации каждая программа жёстко связывается с одним или с несколькими входными портами. Для передачи сообщения такая программа должна явно указать адрес передачи: имя программы и имя её входного порта. В этом случае при изменении конфигурации систе­мы придётся корректировать используемые программы: изменять адре­са передач сообщений. В системах с портами гибкой конфигурации с каждой программой связаны как входные, так и выходные виртуальные порты. Перед запуском такой системы должна производиться предвари­тельная настройка программ по информации, задаваемой пользовате­лем. Эта настройка производится с помощью специальной программной

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

6.3. Архитектурные функции

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

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

тектуре ПС, и выполняемую программной компонентой ПС, видимой из-вне ПС, будем называть архитектурной функцией.

6.4. Контроль архитектуры программных средств

Для контроля архитектуры ПС используется смежный контроль и ручная имитация.

Смежный контроль архитектуры ПС сверху - это её контроль раз­работчиками внешнего описания: разработчиками спецификации каче­ства и разработчиками функциональной спецификации. Смежный кон­троль архитектуры ПС снизу - это ее контроль потенциальными разра­ботчиками программных подсистем, входящих в состав ПС в соответ­ствии с разработанной архитектурой.

Ручная имитация архитектуры ПС производится аналогично руч­ной имитации функциональной спецификации, только целью этого кон­троля является проверка взаимодействия между программными подсис­темами. Так же, как и в случае ручной имитации функциональной спе­цификации ПС, должны быть сначала подготовлены тесты. Затем груп­па разработчиков должна для каждого такого теста имитировать работу каждой программной подсистемы, входящей в состав ПС. При этом ра­боту каждой подсистемы имитирует один какой-либо разработчик (не автор архитектуры), тщательно выполняя все взаимодействия этой под­системы с другими подсистемами (точнее, с разработчиками, их имити­рующими) в соответствии с разработанной архитектурой ПС. Тем са­мым обеспечивается имитационное функционирование ПС в целом в рамках проверяемой архитектуры.

Вопросы к главе 6

6.1. Что такое архитектура ПС!

6.2. Какие классы архитектур Вы знаете?

6.3. Что такое архитектурная функция!

Скачать архив с текстом документа