Повідомлень у темі: 37

[Tic-Sakyra]

Вас интересует программирование? И Вы не знаете основ? Милости прошу! Что знаю сама, все расскажу)))

[хоник]

Очень интересует,но я только учусь! Мне бы хотя бы какие то основы! И очень бы хотелось знать (не знаю в тему ли) все операции с кнопкой гтрл!
И с почином тебя!

[Tic-Sakyra]

Технология программирования

Математика делает то,
что можно, так, как нужно,
тогда как информатика делает то,
что нужно, так, как можно.
Программистский фольклор

Лекция 1.
НАДЕЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВА-НИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОН-ТЕКСТ ПРОГРАММИРОВАНИЯ

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

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

Целью программирования является описание процессов обра-ботки данных (в дальнейшем  просто процессов). Согласно ИФИПа [1.1]: данные (data)  это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация (information)  это смысл, который придается данным при их представлении. Обработка данных (data processing)  это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на т.н. носителях данных. Совокупность носителей данных, используемых при какой-либо обработке данных, будем называть информационной средой (data medium). Набор данных, содержащихся в какой-либо момент в информационной среде, будем называть состоянием этой информационной среды. Процесс можно определить как последовательность сменяющих друг друга состояний некоторой информационной среды.
Описать процесс  это значит определить последовательность состояний заданной информационной среды. Если мы хотим, чтобы по заданному описанию требуемый процесс порождался автоматически на каком-либо компьютере, необходимо, чтобы это описание было формализованным. Такое описание называется программой. С другой стороны, программа должна быть понятной и человеку, так как и при разработке программ, и при их использовании часто приходится выяснять, какой именно процесс она порождает. Поэтому программа составляется на удобном для человека формализованном языке программирования, с которого она автоматически переводится на язык соответствующего компьютера с помощью другой программы, называемой транслятором. Человеку (программи-сту), прежде чем составить программу на удобном для него языке программирования, приходится проделывать большую подготовительную работу по уточнению постановки задачи, выбору метода ее решения, выяснению специфики применения требуемой программы, прояснению общей организации разрабатываемой программы и многое другое. Использование этой информации может существенно упростить задачу понимания программы человеком, поэтому весьма полезно ее как-то фиксировать в виде отдельных документов (часто не форма-лизованных, рассчитанных только для восприятия человеком).
Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться люди, не участвующие в их разработке (их называют пользователями). Для освоения программы пользователем помимо ее текста требуется определенная дополнительная документация. Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осу-ществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.

1.2. Неконструктивность понятия правильной программы.

Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под «программой» часто понимают правильную программу, т.е. программу, не содержащую ошибок. Однако, понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Майерсу [1.2, стр. 10-13] будем считать, что в программе имеется ошибка, если она не выполняет того, что разумно ожидать от нее пользователю. «Разумное ожидание» пользователя формируется на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным. В ПС программы и документация взаимно увязаны, образуют некоторую целостность. Поэтому пра-вильнее говорить об ошибке не в программе, а в ПС в целом: будем считать, что в ПС имеется ошибка (software error), если оно не выполняет того, что разумно ожидать от него пользователю. В частности, разновидностью ошибки в ПС является несогласо-ванность между программами ПС и документацией по их применению. В работе [1.3] выделяется в отдельное понятие частный случай ошибки в ПС, когда программа не соответствует своей функциональной спецификации (описанию, разрабатываемому на этапе, предшествующему непосредственному программированию). Такая ошибка в указанной работе называется дефектом программы. Однако выделение такой разновидности ошибки в отдельное понятие вряд ли оправданно, так как причиной ошибки может оказаться сама функциональная спецификация, а не программа.
Так как задание на ПС обычно формулируется не формально, а также из-за того, что понятия ошибки в ПС не формализовано, то нельзя доказать формальными методами (математически) правильность ПС. Нельзя показать правильность ПС и тестированием: как указал Дейкстра [1.4], тестирование может лишь продемонстрировать наличие в ПС ошибки. Поэтому понятие правильной ПС неконструктивно в том смысле, что после окончания работы над созданием ПС мы не сможем убедиться, что достигли цели.

1.3. Надежность программного средства.

Альтернативой правильного ПС является надежное ПС. Надежность (reliability) ПС  это его способность безотказно выполнять определенные функции при заданных условиях в течение за-данного периода времени с достаточно большой вероятностью [1.5]. При этом под отказом в ПС понимают проявление в нем ошибки [1.2, стр. 10-13]. Таким образом, надежное ПС не исключает наличия в нем ошибок  важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС.
ПС может обладать различной степенью надежности. Как из-мерять эту степень? Так же как в технике, степень надежности можно характеризовать [1.2, стр. 10-13] вероятностью работы ПС без отказа в течение определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.
При оценке степени надежности ПС следует также учитывать последствия каждого отказа. Некоторые ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПС иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.

1.4. Технология программирования как технология разработки надежных программных средств.

В соответствии с обычным значением слова «технология» [1.6] под технологией программирования (programming technology) будем понимать совокупность производственных процессов, приводящую к созданию требуемого ПС, а также описание этой совокупности процессов. Другими словами, технологию программирования мы будем понимать здесь в широком смысле как технологию разработки программных средств, включая в нее все процессы, начиная с момента зарождения идеи этого средства, и, в частности, связанные с созданием необходимой программной документации. Каждый процесс этой совокупности базируется на использовании каких-либо методов и средств, например, компьютер (в этом случае будем говорить о компьютерной технологии программирования).
В литературе имеются и другие, несколько отличающиеся, определения технологии программирования. Эти определения обсуждаются в работе [1.7]. Используется в литературе и близкое к технологии программирования понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств [1.7, стр. 9-16]. Именно программной инженерии (software engineering) посвящена упомянутая работа [1.3]. Главное различие между технологией программирования и программной инженерией как дисциплинами для изучения заключается в способе рассмотрения и систе-матизации материала. В технологии программирования акцент де-лается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения  методы и инструментальные средства разработки ПС используются в этих процессах (их применение и образуют технологические процессы). Тогда как в программной инженерии изучаются различные методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей – эти методы и средства могут использоваться в разных технологических процессах (и в разных технологиях программирования).
Не следует также путать технологию программирования с ме-тодологией программирования [1.8]. В технологии программирования методы рассматриваются «сверху»  с точки зрения организации технологических процессов, а в методологии программирования методы рассматриваются «снизу»  с точки зрения основ их построения (в работе [1.9, стр. 25] методология программирования определяется как совокупность механизмов, применяемых в процессе разработки программного обеспечения и объединенных одним общим философским подходом).
Имея ввиду, что надежность является неотъемлемым атрибутом ПС, мы будем рассматривать технологию программирования как технологию разработки надежных ПС. Это означает, что

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

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

1.5. Технология программирования и информатизация общества.

Технологии программирования играло разную роль на разных этапах развития программирования. По мере повышения мощности компьютеров и развития средств и методологии программирования росла и сложность решаемых на компьютерах задач, что привело к повышенному вниманию к технологии программирования. Резкое удешевление стоимости компьютеров и, в особенности, стоимости хранения информации на компьютерных носителях привело к широкому внедрению компьютеров практически во все сферы человеческой деятельности, что существенно изменило направленность технологии программирования. Человеческий фактор стал играть в ней решающую роль. Сформировалось достаточно глубокое понятие качества ПС, причем предпочтение стало отдаваться не столько эффективности ПС, сколько удобству работы с ним для пользователей (не говоря уже о его надежности). Широкое использование компьютерных сетей привело к интенсивному развитию распределенных вычислений, дистанционного доступа к информации и электронного способа обмена сообщениями между людьми. Компьютерная техника из средства решения отдельных задач все более превращается в средство информационного моделирования реального и мыслимого мира, способное просто отвечать людям на интересующие их вопросы. Начинается этап глубокой и полной информатизации (компьютеризации) человеческого общества. Все это ставит перед технологией программирования новые и достаточно трудные проблемы.
Сделаем краткую характеристику развития программирования по десятилетиям.
В 50-е годы мощность компьютеров (первого поколения) была невелика, а программирование для них велось, в основном, в машинном коде. Решались, главным образом, научно-технические задачи (счет по формулам), задание на программирование содержало, как правило, достаточно точную постановку задачи. Использовалась интуитивная технология программирования: почти сразу приступали к составлению программы по заданию, при этом часто задание несколько раз изменялось (что сильно увеличивало время и без того итерационного процесса составления программы), минимальная документация оформлялась уже после того, как программа начинала работать. Тем не менее, именно в этот период родилась фундаментальная для технологии программирования концепция модульного программирования [1.10], ориентированная на преодоления трудностей программирования в машинном коде. Появились первые языки программирования высокого уровня, из которых только ФОРТРАН пробился для использования в следующие десятилетия.
В 60-е годы можно было наблюдать бурное развитие и широкое использование языков программирования высокого уровня (АЛГОЛ 60, ФОРТРАН, КОВОЛ и др.), значение которых в технологии программирования явно преувеличивалась. Надежда на то, что эти языки решат все проблемы, возникающие в процессе разработки больших программ, не оправдалась. В результате повышения мощности компьютеров и накопления опыта программирования на языках высокого уровня быстро росла сложность решаемых на компьютерах задач, в результате чего обнаружилась ограниченность языков, проигнорировавших модульную организацию программ. И только ФОРТРАН, бережно сохранивший возможность модульного про-граммирования, гордо прошествовал в следующие десятилетия (все его ругали, но его пользователи отказаться от его услуг не могли из-за грандиозного накопления фонда программных модулей, которые с успехом использовались в новых программах). Кроме того, было понято, что важно не только то, на каком языке мы программируем, но и то, как мы программируем [1.4]. Это было уже началом серьезных размышлений над методологией и технологией программиро-вания. Появление в компьютерах 2-го поколения прерываний при-вело к развитию мультипрограммирования и созданию больших программных систем. Широко стала использоваться коллективная разработка, которая поставила ряд серьезных технологических проблем [1.11].
В 70-е годы получили широкое распространение информаци-онные системы и базы данных. К середине 70-ых годов стоимость хранения одного бита информации на компьютерных носителях стала меньше, чем на традиционных носителях. Это резко повысило интерес к компьютерным системам хранения данных. Началось интенсивное развитие технологии программирования [1.2, 1.8, 1.12-1.14], прежде всего, в следующих направлениях:

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

80-е годы характеризуются широким внедрением персональ-ных компьютеров во все сферы человеческой деятельности и тем самым созданием обширного и разнообразного контингента пользователей ПС. Это привело к бурному развитию пользовательских интерфейсов и созданию четкой концепции качества ПС [1.5, 1.15-1.18]. Появляются языки программирования (например, Ада), учитывающие требования технологии программирования [1.19]. Развиваются методы и языки спецификации ПС [1.20-1.21]. Начинается бурный процесс стандартизации технологических процессов и, прежде всего, документации, создаваемой в этих процессах [1.22]. Выходит на передовые позиции объектный подход к разработке ПС [1.9]. Создаются различные инструментальные среды разработки и сопровождения ПС [1.3]. Развивается концепция компьютерных сетей.
90-е годы знаменательны широким охватом всего человеческого общества международной компьютерной сетью, персональные компьютеры стали подключаться к ней как терминалы. Это поставило ряд проблем (как технологического, так и юридического и этического характера) регулирования доступа к информации компьютерных сетей. Остро встала проблема защиты компьютерной информации и передаваемых по сети сообщений. Стали бурно развиваться компьютерная технология (CASE-технология) разработки ПС и связанные с ней формальные методы спецификации программ. Начался решающий этап полной информатизации и компьютеризации общества.

Упражнения к лекции 1.

1.1. Что такое информационная среда программы?
1.2. Что такое программное средство (ПС)?
1.3. Что такое ошибка в ПС?
1.4. Что такое надежность ПС?
1.5. Что такое технология программирования?

Литература к лекции 1.

1.1. И.Г.Гоулд, Дж.С.Тутилл. Терминологическая работа IFIP (Международная федерация по обработке информации) и ICC (Международный вычислительный центр) // Журн. вычисл. матем. и матем. физ., 1965, #2. - С. 377-386.
1.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980.
1.3. Ian Sommerville. Software engineering. - Addison-Wesley Publishing Company, 1992.
1.4. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-97.
1.5. Criteria for evaluation of software. - ISO TC97/SC7 #367 (Super-sedes Document #327).
1.6. С.И. Ожегов. Словарь русского языка. - М.: Советская энциклопедия, 1975.
1.7. Ф.Я. Дзержинский, И.М. Калиниченко. Дисциплина программирования Д: концепция и опыт реализации методических средств программной инженерии. - М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988.
1.8. В. Турский. Методология программирования. - М.: Мир, 1981.
1.9. Г. Буч. Объектно-ориентированное проектирование с примерами применения. - М.: Конкорд, 1992.
1.10. Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм / Система автоматизация программирования. - М.: Физматгиз, 1961. - С. 15-52.
1.11. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы. - М.: Наука, 1979.
1.12. R.C. Holt. Structure of computer programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
1.13. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. - М.: Мир, 1980.
1.14. Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, #2. - С. 44-49.
1.15. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981.
1.16. В.В. Липаев. Качество программного обеспечения. - М.: Фи-нансы и статистика, 1983.
1.17. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984.
1.18. Revised version of DP9126 - Criteria of the evaluation of software quality characteristics. ISO TC97/SC7 #610. Part 6.
1.19. В.Ш. Кауфман. Языки программирования. Концепции и принципы. - М.: Радио и связь, 1993.
1.20. Требования и спецификации в разработке программ. - М.: Мир, 1984.
1.21. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука (Сибирское отделение), 1987.
1.22. В.В. Липаев, Е.Н Филиппов. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, 1997.

Человеку свойственно ошибаться.
Сенека

Лекция 2.
ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ

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

2.1. Интеллектуальные возможности человека.

Дейкстра [2.1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:

• способность к перебору,
• способность к абстракции,
• способность к математической индукции.

Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой, позволяя узнавать искомый предмет. Эта способность весьма ограничена - в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последова-тельностями.
При разработке ПС человек имеет дело с системами. Под системой будем понимать совокупность взаимодействующих (находящихся в отношениях) друг с другом элементов. ПС можно рассматривать как пример системы. Логически связанный набор программ является другим примером системы. Любая отдельная программа также является системой. Понять систему  значит осмысленно перебрать все пути взаимодействия между ее элементами. В силу ограниченности человека к перебору будем различать простые и сложные системы [2.2]. Под простой будем понимать такую систему, в которой человек может уверенно перебирать все пути взаимодействия между ее элементами, а под сложной будем понимать такую систему, в которой он этого делать не в состоянии. Между простыми и сложными системами нет четкой границы, поэтому можно говорить и о промежуточном классе систем: к таким системам относятся программы, о которых программистский фольклор утверждает, что "в каждой отлаженной программе имеется хотя бы одна ошибка".
При разработке ПС мы не всегда можем уверенно знать о всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n  число ее элементов. Систему назовем малой, если n < 7 (6! = 720 < 1000), систему назовем большой, если n > 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования  научиться делать большие системы простыми.
Полученная оценка простых систем по числу элементов широко используется на практике. Так, для руководителя коллектива весьма желательно, чтобы в нем не было больше шести взаимодействующих между собой подчиненных. Весьма важно также следовать правилу: «все, что может быть сказано, должно быть сказано в шести пунктах или меньше». Этому правилу мы будем стараться следовать в настоящем пособии: всякие перечисления взаимосвязанных утверждений (набор рекомендаций, список требований и т.п.) будут соответствующим образом группироваться и обобщаться. Полезно ему следовать и при разработке ПС.

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

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

Рис. 2.1. Грубая схема разработки и применения ПС.

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

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

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

Рис.2.2. Модель перевода.

• он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;
• он запоминает полученную информацию в своей памяти M;
• он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
• с помощью этого механизма он фиксирует представление B.

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

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

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

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

Упражнения к лекции 2.

2.1. Что такое простая и сложная системы?
2.2. Что такое малая и большая системы?

Литература к лекции 2.

2.1. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-19.
2.2. Е.А. Жоголев. Технологические основы модульного програм-мирования. // Программирование, 1980, #2. - С. 44-49.
2.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980.

[Tic-Sakyra]

Лучшее - враг хорошего.
Народная мудрость

Лекция 3.
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ
ПРОГРАММНЫХ СРЕДСТВ

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

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

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

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

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

Под жизненным циклом ПС (software life cycle) понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [3.1-3.4]. Жизненный цикл охватывает довольно сложный процесс создания и использования ПС (software process). Этот процесс может быть организован по-разному для разных классов ПС и в зависимости от особенностей коллектива разработчиков.
В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС [3.5].
[l]• Водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС.
• Исследовательское программирование. Этот подход предполагает быструю (насколько это возможно) реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей. Такой подход применялся на ранних этапах развития программирования, когда технологии программирования не придавали большого значения (использовалась интуитивная технология). В настоящее время этот подход применяется для разработки таких ПС, для которых пользователи не могут точно сформулировать требования (например, для разработки систем искусственного интеллекта).

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

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

Рис. 3.1. Стадии и фазы жизненного цикла ПС.

Стадия разработки (development) ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управления (management) ПС. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Этап внешнего описания ПС включает процессы, приводящие к созданию некоторого документа, который мы будем называть внешним описанием (requirements document) ПС. Этот документ яв-ляется описанием поведения ПС с точки зрения внешнего по от-ношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со стороны пользователей (заказчика), а также включает процессы спецификации этих требований. Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.
Кодирование (coding) ПС включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС.
На этапе аттестации (acceptance) ПС производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается законченной. Это обычно оформляется в виде некоторого документа, фиксирующего решение комиссии, проводящей аттестацию ПС.
Программное изделие (ПИ)  экземпляр или копия разработанного ПС. Изготовление ПИ  это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ  это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [3.1]. Стадия производства ПИ в жизненном цикле ПС является, по существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [3.4, 3.5].
Применение (operation) ПС  это использование ПС для реше-ния практических задач на компьютере путем выполнения ее про-грамм.
Сопровождение (maintenance) ПС  это процесс сбора ин-формации о качестве ПС в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях [3.1, 3.4, 3.5].

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

Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество (quality) ПС  это совокупность его (Слово удалено системой) и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [3.6]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их наивысшей степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его исполь-зование.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteria of software quality) принято считать [3.6-3.10]:

* функциональность,
* надежность,
* легкость применения,
* эффективность,
* сопровождаемость,
* мобильность.

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

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

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

• предупреждение ошибок;
• самообнаружение ошибок;
• самоисправление ошибок;
• обеспечение устойчивости к ошибкам.

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

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

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

3.5. Методы борьбы со сложностью.

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

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

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

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

Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определенной дисциплины. Майерс предлагает использовать общую дисциплину решения задач, рассматривая перевод как решение задачи [3.11]. Лучшим руководством по решению задач он считает книгу Пойа "Как решать задачу" [3.12]. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:

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

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

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

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

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

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

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

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

Упражнения к лекции 3.

3.1. Что такое жизненный цикл программного средства (ПС)?
3.2. Что такое внешнее описание ПС?
3.3. Что такое сопровождение ПС?
3.4. Что такое качество ПС?
3.5. Что такое смежный контроль?

Литература к лекции 3.

3.1. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
3.2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 11.
3.3. К. Зиглер. Методы проектирования программных систем. - М.: Мир, 1985. - С. 15-23.
3.4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 53-67, 125-130.
3.5. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P. 5-10.
3.6. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
3.7. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
3.8. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 17-24.
3.9. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983. - С. 18-30.
3.10. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-103.
3.11. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 32-48.
3.12. Д. Пойа. Как решать задачу. - М.: Наука, 1961.
3.13. В.В. Липаев, Б.А. Позин, А.А. Штрик. Технология сборочного программирования. – М.: Радио и связь, 1992.?

[Tic-Sakyra]

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

Лекция 4.
ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО
СРЕДСТВА

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

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

Разработчикам больших программных средств приходится решать весьма специфические и трудные проблемы, особенно, если это ПС должно представлять собой программную систему нового типа, в плохо компьютеризированной предметной области. Разработка ПС начинается с процесса формулирования требований к ПС, в котором, исходя из довольно смутных пожеланий заказчика, должен быть создан документ, достаточно точно определяющий задачи разработчиков ПС. Этот документ мы называем внешним описанием ПС.
Очень часто требования к ПС путают с требованиями к процессам его разработки (технологическим процессам). Последние не следует включать во внешнее описание, если только они не связаны с оценкой качества ПС. В случае необходимости требования к технологическим процессам можно оформить в виде самостоятельного документа, который будет использоваться при управлении разработкой ПС.
Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Более того, оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС. Оно является исходным документом для трех параллельно протекающих процессов: разработки текстов (конструированию и кодированию) программ, входящих в ПС, разработки документации по применению ПС и разработки существенной части комплекта тестов для тестирования ПС. Ошибки и неточности во внешнем описании, в конечном счете, трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три параллельных процесса. Это требует принятия особенно серьезных мер по их предупреждению.
Исходным документом для разработки внешнего описания ПС является определение требований к ПС. Но так как через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, то формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с которого и начинается этап разработки требований к ПС [4.2]. Трудности, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в "узких" местах деятельности пользователей может на самом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадываются). Кроме того, проблемы, которые необходимо отразить в определении требований, могут не иметь определенной формулировки [4.1], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо "заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда бывает полезным разработка упрощенной версии требуемого ПС, называемую прототипом ПС. Анализ "пробного" применения прототипа позволяет выявить действительные потребности пользователей и существенно уточнить требования к ПС.
В определении внешнего описания легко бросаются в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [4.2], которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (в литературе ее часто называют нефункциональной спецификацией [4.1], но она, как правило, включает и требования к технологическим процессам). Она, в отличие от функциональной спецификации, представляется в неформализованном виде и играет роль тех ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ требуемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС.
Обычно разработка спецификации качества предшествует разработке функциональной спецификации ПС, так как некоторые требования к качеству ПС могут предопределять включение в функциональную спецификацию специальных функций, например, функции защиты от несанкционированного доступа к некоторым объектам информационной среды. Таким образом, структуру внешнего описания ПС можно выразить формулой:

Внешнее описание ПС = определение требований
+ спецификация качества ПС
+ функциональная спецификация ПС

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

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

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

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

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

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

Разработка спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС [4.2, 4.3]. В этой модели должен быть перечень всех тех достаточно элементарных свойств, которые необходимо обеспечить в требуемом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной степени конкретизировано с учетом определения требований к ПС и возможности оценки его наличия у разработанного ПС или необходимой степени обладания им этим ПС.
Для конкретизации качества ПС по каждому из критериев ис-пользуется стандартизованный набор достаточно простых свойств ПС [4.3-4.6], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.

Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устой-чивость, защищенность.
Легкость применения: П-документированность, информатив-ность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.

Сопровождаемость: С данным критерием связано много раз-личных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость. Изучаемость:  это характеристики ПС, кото-рые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость  это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок.[/color]
Изучаемость: С - документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, модифицируемость (в узком смысле, как примитив качества), структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность. Ниже даются определения используемых примитивов качества ПС [4.3-4.5].
Завершенность (completeness)  свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность (accuracy)  мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.
Автономность (self-containedness) свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость (robustness) свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Защищенность (defensiveness)  свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
П-документированность (u. documentation)  свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.
Информативность (accountability) свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.
Коммуникабельность (communicativeness) свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием.
Временнáя эффективность (time efficiency)  мера, характеризующая способность ПС выполнять возложенные на него функции в течение определенного отрезка времени.
Эффективность по ресурсам (resource efficiency) мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях на используемые ресурсы (используемую память).
Эффективность по устройствам (device efficiency)  мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
С-документировапнность (documentation) свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данного ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.
Понятность (understandability) свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность, четкость и, собственно, понятность (текстов программ).
Структурированность (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. Что такое функциональная спецификация ПС?
4.7. Что такое ручная имитация внешнего описания ПС?

Литература к лекции 4.

4.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
4.2. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 49-77.
4.3. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
4.4. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
4.5. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
4.6. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 61-87.

[Tic-Sakyra]

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

Лекция 5.
МЕТОДЫ СПЕЦИФИКАЦИИ СЕМАНТИКИ
ФУНКЦИЙ

Основные подходы к спецификации семантики функций. Табличный под-ход, метод таблиц решений. Алгебраический подход: операционная, денотационная и аксиоматическая семантика. Логический подход. Языки спецификаций.

5.1. Основные подходы к спецификации семантики функций.

Для спецификации семантики функций используются следую-щие подходы: табличный, алгебраический и логический [5.1, стр. 30-73], а также графический [5.2].
Табличный подход для определения функций хорошо известен еще со средней школы. Он базируется на использовании таблиц. В программировании эти методы получили развитие в методе таблиц решений.
Алгебраический подход для определения функций базируется на использовании равенств. В этом случае для определения некоторого набора функций строится система равенств вида:

L1=R1,

. . .

(5.1)

Ln=Rn.

где Li и Ri, i=1, ... n, некоторые выражения, содержащие предопределенные операции, константы, переменные, от которых зависят определяемые функции (формальные параметры этих функций), и вхождения самих этих функций. Семантика определяемых функций извлекается в результате интерпретации этой системы равенств. Эта интерпретация может осуществляться по-разному (базироваться на разных системах правил), что порождает разные семантики. В настоящее время активно исследуются операционная, денотационная и аксиоматическая семантики.
Третий подход, логический, базируется на использовании предикатов  функций, у которых аргументами могут быть значения различных типов, а результатами являются логические значения (ИСТИНА и ЛОЖЬ). В этом случае набор функций может определяться с помощью системы предикатов. Заметим, что система равенств алгебраического подхода может быть задана с помощью следующей системы предикатов:

РАВНО(L1, R1),

. . . . . . .

(5.2)

РАВНО(Ln, Rn),

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

5.2. Метод таблиц решений.

Метод таблиц решений базируется на использовании таблиц следующего вида (см. табл. 5.1).
Верхняя часть этой таблицы определяет различные ситуации, в которых требуется выполнять некоторые действия (операции). Каждая строка этой части задает ряд значений некоторой переменной или некоторого условия. Первый столбец этой части представляет собой список переменных или условий, от значений которых зависит выбор определяемых ситуаций. В каждом следующем столбце указывается комбинация значений этих переменных (условий), определяющая конкретную ситуацию. При этом последний столбец определяет ситуацию, отличную от предыдущих, т.е. для любых других комбинаций значений (будем обозначать их звездочкой ), отличных от первых, определяется одна и та же, (m+1)-ая, ситуация. Впрочем, в некоторых таблицах решений этот столбец может отсутствовать.

Табл. 5.1. Общая схема таблиц решений.

Нижняя часть таблицы решений определяет действия, которые требуется выполнить в той или иной ситуации, определяемой в верхней части таблицы решений. Она также состоит из нескольких (k) строк, каждая из которых связана с каким-либо одним конкретным действием, указанным в первом поле (столбце) этой строки. В остальных полях (столбцах) этой строки (т.е. для u[i, j], i=1, ... m+1, j=1, ... k) указывается, следует ли выполнять (u[i, j]= '+' это действие в данной ситуации или не следует (u[i, j]= ''). Таким образом, первый столбец нижней части этой таблицы представляет собой список обозначений действий, которые могут выполняться в той или иной ситуации, определяемой этой таблицей. В каждом следующем столбце этой части указывается комбинация действий, которые следует выполнить в ситуации, определяемой в том же столбце верхней части таблицы решений. Для ряда таблиц решений эти действия могут выполняться в произвольном порядке, но для некоторых таблиц решений этот порядок может быть предопределен, например, в порядке следования соответствующих строк в нижней части этой таблицы.

Рис. 5.2. Таблица решений "Светофор у пешеходной дорожки".

Рассмотрим в качестве примера описание работы светофора у пешеходной дорожки. Переключение светофора в нормальных ситуациях должно производиться через фиксированное для каждого цвета число единиц времени (Tкр  для красного цвета, Tжел  для желтого, Tзел  для зеленого). У светофора имеется счетчик таких единиц. При переключении светофора в счетчике устанавливается 0. Работа светофора усложняется необходимостью пропускать привилегированные машины (при их появлении на светофор поступает специальный сигнал) с минимальной задержкой, но при обеспечении безопасности пешеходов. Приведенная на рис. 5.2 таблица решений описывает работу такого светофора и порядок движения у него в каждую единицу времени. Звездочка () в этой таблице означает произвольное значение соответствующего условия.

5.3. Операционная семантика.

В операционной семантике алгебраического подхода к описа-нию семантики функций рассматривается следующий частный слу-чай системы равенств (5.1):

f1(x1, x2, ... , xk)= E1,
f2(x1, x2, ... , xk)= E2,

. . . . . . . . . . . . .

(5.3)

fn(x1, x2, ... , xk)= En,

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

s
E
T

выражения (терма) T в выражение E вместо символа s (в частности, переменной) будем понимать переписывание выражения E с заменой каждого вхождения в него символа s на выражение T. Каждое равенство

fi(x1, x2, ... , xk)= Ei

задает в параметрической форме множество правил подстановок вида

где T1, T2, ... , Tk  конкретные аргументы (значения или определяющие их выражения) данной функции. Это правило допускает замену вхождения левой его части в какое-либо выражение на правую часть этого правила.
Интерпретация системы равенств (5.3) для получения значений определяемых функций в рамках операционной семантики производится следующим образом. Пусть задан набор входных данных (аргументов) d1, d2, ... , dk. На первом шаге осуществляется подстановка этих данных в левые и правые части равенств с выполнением там, где это возможно, предопределенных операций и с выписыванием получаемых в результате этого равенств. На каждом следующем шаге происходит переписывание этих равенств со следующими преобразованиями. Если правая часть очередного равенства является каким-либо значением, то это равенство не изменяется (это значение и является значением функции, указанной в левой части этого равенства). В противном случае правая часть является выражением, содержащим вхождения каких-либо определяемых функций с теми или иными наборами аргументов. В этом случае для каждого вхождения функции (с конкретным набором аргументов) просматриваются левые части преобразуемых равенств. Если для этого вхождения находится совпадающая с ним левая часть, то проверяется правая часть этого равенства и в случае, если она является уже вычисленным значением, производится подстановка этого значения вместо указанного вхождения определяемой функции. Если же эта правая часть не является вычисленным значением, то указанное вхождение переписывается в неизменном виде. В том же случае, если для указанного вхождения не находится совпадающей с ним левая части, то формируется (и дописывается к имеющимся) новое равенство. Это равенство получается из исходного равенства для определяемой функции, вхождение которой в данный момент исследуется, путем подстановки в него вместо параметров аргументов этой функции из исследуемого вхождения (с выполнением предопределенных операций там, где это возможно). Эти шаги будут осуществляться до тех пор, пока все определяемые функции не будут иметь вычисленные значения.
В качестве примера операционной семантики рассмотрим определение функции F(n)=n! Она определяется следующей системой равенств:
F(0)=1,
F(n)=F(n-1)n.
Для вычисления значения F(3) осуществляются следующие шаги.

1-й шаг:
F(0)=1,
F(3)=F(2)3.
2-й шаг:
F(0)=1,
F(3)=F(2)3,
F(2)=F(1)2.
3-й шаг:
F(0)=1,
F(3)=F(2)3,
F(2)=F(1)2,
F(1)=F(0)1.
4-й шаг:
F(0)=1,
F(3)=F(2)3,
F(2)=F(1)*2,
F(1)=1.
5-й шаг:
F(0)=1,
F(3)=F(2)3,
F(2)=2,
F(1)=1.
6-й шаг:
F(0)=1,
F(3)=3,
F(2)=2,
F(1)=1.
Значение F(3) на 6-ом шаге получено.

5.4. Денотационная семантика.

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

Как известно, формальный язык  это множество цепочек в некотором алфавите. Такую систему можно рассматривать как одну из интерпретаций набора правил некоторой грамматики, представленную в форме Бэкуса-Наура (каждое из приведенных уравнений является аналогом некоторой такой формулы). Пусть фиксирован некоторый алфавит A={a1, a2, ... , am} терминальных символов грамматики, из которых строятся цепочки, образующие используемые в системе (5.4) языки. Символы X1, X2, ... , Xn являются метапеременными грамматики, здесь будут рассматриваться как переменные, значениями которых являются языки (множества значений этих метапеременных). Символы phi[i,j], i=1,...,n, j=1,...,kj, обозначают цепочки в объединенном алфавите терминальных символов и метапеременных:

Цепочка phi[i,j] рассматривается как некоторое выражение, определяющее значение, являющееся языком (множеством цепочек в алфавите A). Такое выражение определяется следующим образом. Если значения X1, X2, ... , Xn заданы, то цепочка

Ti(X1, X2, ... , Xn).
Тогда система (5.4) примет вид

X1=T1(X1, X2, ... , Xn),
X2=T2(X1, X2, ... , Xn),

. . . . . . . . . . .

(5.5)

Xn=Tn(X1, X2, ... , Xn).

С помощью денотационной семантики можно определять более широкий класс грамматики по сравнению с формой Бэкуса-Наура. Так в форме Бэкуса-Наура не определены правила вида

X::= X

тогда как уравнение вида

X= X

имеет вполне корректную интерпретацию в денотационной семантике.

5.5. Аксиоматическая семантика.

В качестве примера рассмотрим систему равенств

УДАЛИТЬ(ДОБАВИТЬ(m, d))=m,
ВЕРХ(ДОБАВИТЬ(m, d))=d,
УДАЛИТЬ(ПУСТ)=ПУСТ,
ВЕРХ(ПУСТ)=ДНО,

5.6. Языки спецификаций.

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

Упражнения к лекции 5.

Литература к лекции 5.

5.1. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука (Сибирское отделение), 1987.
5.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
5.3. Д. Скотт. Теория решеток, типы данных и семантика / Данные в языках программирования. - М.: Мир, 1982. - С. 25-53.
5.4. К. Хоор. О структурной организации данных / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 98-197.

[Tic-Sakyra]

Разделяй и властвуй!
Латинское изречение

Лекция 6.
АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА

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

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

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

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

С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.

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

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

* цельная программа;
* комплекс автономно выполняемых программ;
* слоистая программная система;
* коллектив параллельно выполняемых программ.

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

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

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

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

Таким образом, в слоистой программной системе каждый слой может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [6.2]. Эта операционная система состоит из четырех слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение центрального процессора программам (процессам) в пакетном режиме. Только этот уровень осведомлен о мультипрограммных аспектах системы. На первом слое осуществляется управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не страничная) память. На втором слое осуществляется связь с консолью (пультом управления) оператора. Только этот слой знает технические характеристики консоли. На третьем слое осуществляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные про-граммы не знают технических характеристик устройств ввода и вывода.

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

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

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

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

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

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

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

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

Упражнения к лекции 6.

6.1. Что такое архитектура программного средства?
6.2. Что такое архитектурная функция?

Литература к лекции 6.

6.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 78-91.
6.2. E.W. Dijkstra. The Structure of the THE-Multiprogramming // Communications of the ACM. - 1968, 11(5). - Pp. 341-346.
6.3. М. Кристиан. Введение в операционную систему UNIX. - М.: Финансы и статистика, 1985. - С. 46-49.

[Tic-Sakyra]

Смотри в корень!
Козьма Прутков

Лекция 7.
РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И
МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ

Цель разработки структуры программы. Понятие программного модуля. Основные характеристики программного модуля. Методы разработки структуры программы. Спецификация программного модуля. Контроль структуры программы.

7.1. Цель модульного программирования.

Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями [7.1, 7.2]. А сам такой метод разработки программ называют модульным программированием [7.3]. Программный модуль  это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Модульное программирование является воплощением в процессе разработки программ обоих общих методов борьбы со сложностью (см. лекцию 3, п. 3.5): и обеспечение независимости компонент системы, и использование иерархических структур. Для воплощения первого метода формулируются определенные требования, которым должен удовлетворять программный модуль, т.е. выявляются основные характеристики «хорошего» программного модуля. Для воплощения второго метода используют древовидные модульные структуры программ (включая деревья со сросшимися ветвями).

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

Не всякий программный модуль способствует упрощению программы [7.2]. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт [7.4] предложил следующие два общих таких критерия:

• хороший модуль снаружи проще, чем внутри;
• хороший модуль проще использовать, чем построить.

Майерс [7.5] предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики:

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

Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность модуля  это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс [7.5] предлагает упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль, прочный по совпадению. Это такой модуль, между элементами которого нет осмысленных связей. Такой модуль может быть выделен, например, при обнаружении в разных местах программы повторения одной и той же последовательности операторов, которая и оформляется в отдельный модуль. Необходимость изменения этой последовательности в одном из контекстов может привести к изменению этого модуля, что может сделать его использование в других контекстах ошибочным. Та-кой класс программных модулей не рекомендуется для использования. Вообще говоря, предложенная Майерсом упорядоченность по степени прочности классов модулей не бесспорна. Однако, это не очень существенно, так как только два высших по прочности класса модулей рекомендуются для использования. Эти классы мы и рассмотрим подробнее.
Функционально прочный модуль  это модуль, выполняющий (реализующий) одну какую-либо определенную функцию. При реализации этой функции такой модуль может использовать и другие модули. Такой класс программных модулей рекомендуется для использования.
Информационно прочный модуль  это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из этих операций в таком модуле имеется свой вход со своей формой обращения к нему. Такой класс следует рассматривать как класс программных модулей с высшей степенью прочности. Информационно прочный модуль может реализовывать, например, абстрактный тип данных.
В модульных языках программирования как минимум имеются средства для задания функционально прочных модулей (например, модуль типа FUNCTION в языке ФОРТРАН). Средства же для задания информационно прочных модулей в ранних языках программирования отсутствовали. Эти средства появились только в более поздних языках. Так в языке программирования Ада средством задания информационно прочного модуля является пакет [7.6].
Сцепление модуля  это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает [7.5] упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать также сцепление по общей области  это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Такой вид сцепления модулей реализуется, например, при программировании на языке ФОРТРАН с использованием блоков COMMON. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу [7.5])  это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).
Рутинность модуля  это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Майерс [7.5] не рекомендует использовать зависящие от предыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация является неконструктивной, так как во многих случаях именно зависящий от предыстории модуль является лучшей реализаций информационно прочного модуля. Поэтому более приемлема следующая (более осторожная) рекомендация:

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

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

7.3. Методы разработки структуры программы.

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

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

Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС.
В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода [7.1, 7.7]: метод восходящей разработки и метод нисходящей разработки.
Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. Такой порядок разработки программы на первый взгляд кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется наличия текстов используемых им модулей  для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему «отладочного» программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе.
Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При этом первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа. При этом те модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми заглушками [7.5]). Каждый имитатор модуля представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров (иногда с их распечаткой) и выдает, если это необходимо, заранее запасенный подходящий результат. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется самим этим модулем и, кроме того, добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования при восходящем тестировании заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для того, чтобы подыгрывать процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.
Особенностью рассмотренных методов восходящей и нисходящей разработок (которые мы будем называть классическими) является требование, чтобы модульная структура программы была разработана до начала программирования (кодирования) модулей. Это требование находится в полном соответствии с водопадным подходом к разработке ПС, так как разработка модульной структуры программы и ее кодирование производятся на разных этапах разработки ПС: первая завершает этап конструирования ПС, а второе  открывает этап кодирования. Однако эти методы вызывают ряд возражений: представляется сомнительным, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. На самом деле это делать не обязательно, если не-сколько модернизировать водопадный подход. Ниже предлагаются конструктивный и архитектурный подходы к разработке программ [7.3], в которых модульная структура формируется в процессе программирования (кодирования) модулей.

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

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

Рис. 7.3. Классификация методов разработки структуры про-грамм.
Вклассическом методе нисходящей разработки рекомендуется сначала все модули разрабатываемой программы запрограммировать, а уж затем начинать нисходящее их тестирование [7.5], что опять-таки находится в полном соответствии с водопадным подходом. Однако такой порядок разработки не представляется достаточно обоснованным: тестирование и отладка модулей может привести к изменению спецификации подчиненных модулей и даже к изменению самой модульной структуры программы, так что в этом случае программирование некоторых модулей может оказаться бесполезно проделанной работой. Нам представляется более рациональным другой порядок разработки программы, известный в литературе как метод нисходящей реализации, что представляет некоторую модификацию водопадного подхода. В этом методе каждый запрограммированный модуль начинают сразу же тестировать до перехода к программированию другого модуля.
Все эти методы имеют еще различные разновидности в зависимости от того, в какой последовательности обходятся узлы (модули) древовидной структуры программы в процессе ее разработки [7.1]. Это можно делать, например, по слоям (разрабатывая все модули одного уровня, прежде чем переходить к следующему уровню). При нисходящей разработке дерево можно обходить также в лексикографическом порядке (сверху вниз, слева направо). Возможны и другие варианты обхода дерева. Так, при конструктивной реализации для обхода дерева программы целесообразно следовать идеям Фуксмана, которые он использовал в предложенном им методе вертикального слоения [7.8]. Сущность такого обхода заключается в следующем. В рамках конструктивного подхода сначала реализуются только те модули, которые необходимы для самого простейшего варианта программы, которая может нормально выполняться только для весьма ограниченного множества наборов входных данных, но для таких данных эта задача будет решаться до конца. Вместо других модулей, на которые в такой программе имеются ссылки, в эту программу вставляются лишь их имитаторы, обеспечивающие, в основном, сигнализацию о выходе за пределы этого частного случая. Затем к этой программе добавляются реализации некоторых других модулей (в частности, вместо некоторых из имеющихся имитаторов), обеспечивающих нормальное выполнение для некоторых других наборов входных данных. И этот процесс продолжается поэтапно до полной реализации требуемой программы. Таким образом, обход дерева программы производится с целью кратчайшим путем реализовать тот или иной вариант (сначала самый простейший) нормально действующей программы. В связи с этим такая разно-видность конструктивной реализации получила название метода целенаправленной конструктивной реализации. Достоинством этого метода является то, что уже на достаточно ранней стадии создается работающий вариант разрабатываемой программы. Психологически это играет роль допинга, резко повышающего эффективность разработчика. Поэтому этот метод является весьма привлекательным.
Подводя итог сказанному, на рис. 7.3 представлена общая классификация рассмотренных методов разработки структуры программы.

7.4. Контроль структуры программы.

Для контроля структуры программы можно использовать три метода [7.5]:

• статический контроль,
• смежный контроль,
• сквозной контроль.

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

Упражнения к лекции 7.

7.1. Что такое программный модуль?
7.2. Что такое прочность программного модуля?
7.3. Что такое сцепление программного модуля?

Литература к лекции 7.

7.1. Дж.Хьюз, Дж.Мичтом. Структурный подход к программированию. М.: Мир, 1980. - С. 29-71.
7.2. В.Турский. Методология программирования. - М.: Мир, 1981. - С. 90-164.
7.3. Е.А.Жоголев. Технологические основы модульного программирования//Программирование,1980, #2. - С. 44-49.
7.4. R.C.Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
7.5. Г.Майерс. Надежность программного обеспечения. М.: Мир, 1980. - С. 92-113.
7.6. Я.Пайл. АДА - язык встроенных систем. М.: Финансы и стати-стика, 1984. - С. 67-75.
7.7. М.Зелковец, А.Шоу, Дж.Гэннон. Принципы разработки про-граммного обеспечения. М.: Мир, 1982. - С. 65-71.
7.8. А.Л.Фуксман. Технологические аспекты создания программных систем. М.: Статистика, 1979. С. 79-94.

[Tic-Sakyra]

Переход от неформального
к формаль-ному существенно неформален.
М.Р. Шура-Бура

Лекция 8.
РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ

Порядок разработки программного модуля. Структурное программирование и пошаговая детализация. Понятие о псевдокоде. Контроль программного модуля.

8.1. Порядок разработки программного модуля.

При разработке программного модуля целесообразно придерживаться следующего порядка [8.1]:

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

Первый шаг разработки программного модуля в значительной степени представляет собой смежный контроль структуры программы снизу: изучая спецификацию модуля, разработчик должен убедиться, что она ему понятна и достаточна для разработки этого модуля. В завершении этого шага выбирается язык программирования: хотя язык программирования может быть уже предопределен для всего ПС, все же в ряде случаев (если система программирования это допускает) может быть выбран другой язык, более подходящий для реализации данного модуля (например, язык ассемблера).
На втором шаге разработки программного модуля необходимо выяснить, не известны ли уже какие-либо алгоритмы для решения поставленной и или близкой к ней задачи. И если найдется подходящий алгоритм, то целесообразно им воспользоваться. Выбор подходящих структур данных, которые будут использоваться при выполнении модулем своих функций, в значительной степени предопределяет логику и качественные показатели разрабатываемого модуля, поэтому его следует рассматривать как весьма ответственное решение.
На третьем шаге осуществляется построение текста модуля на выбранном языке программирования. Обилие всевозможных деталей, которые должны быть учтены при реализации функций, указанных в спецификации модуля, легко могут привести к созданию весьма запутанного текста, содержащего массу ошибок и неточностей. Искать ошибки в таком модуле и вносить в него требуемые изменения может оказаться весьма трудоемкой задачей. Поэтому весьма важно для построения текста модуля пользоваться технологически обоснованной и практически проверенной дисциплиной программирования. Впервые на это обратил внимание Дейкстра [8.2], сформулировав и обосновав основные принципы структурного программирования. На этих принципах базируются многие дисциплины программирования, широко применяемые на практике [8.3-8.6]. Наиболее распространенной является дисциплина пошаговой детализации [8.3], которая подробно обсуждается в разделах 8.2 и 8.3.
Следующий шаг разработки модуля связан с приведением текста модуля к завершенному виду в соответствии со спецификацией качества ПС. При программировании модуля разработчик основное внимание уделяет правильности реализации функций модуля, оставляя недоработанными комментарии и допуская некоторые нарушения требований к стилю программы. При шлифовке текста модуля он должен отредактировать имеющиеся в тексте комментарии и, возможно, включить в него дополнительные комментарии с целью обеспечить требуемые примитивы качества [8.1]. С этой же целью производится редактирование текста программы для выполнения стилистических требований.
Шаг проверки модуля представляет собой ручную проверку внутренней логики модуля до начала его отладки (использующей выполнение его на компьютере), реализует общий принцип, сформулированный для обсуждаемой технологии программирования, о необходимости контроля принимаемых решений на каждом этапе разработки ПС (см. лекцию 3). Методы проверки модуля обсуждаются в разделе 8.4.
И, наконец, последний шаг разработки модуля означает завершение проверки модуля (с помощью компилятора) и переход к процессу отладки модуля.

8.2. Структурное программирование.

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

Рис. 8.1. Основные управляющие конструкции структурного программирования.
Основными конструкциями структурного программирования являются: следование, разветвление и повторение (см. Рис. 8.1). Компонентами этих конструкций являются обобщенные операторы (узлы обработки [8.5]) S, S1, S2 и условие (предикат) P. В качестве обобщенного оператора может быть либо простой оператор используемого языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, являющийся композицией основных управляющих конструкций структурного программирования. Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход.
Весьма важно также, что эти конструкции являются уже математическими объектами (что, по существу, и объясняет причину успеха структурного программирования). Доказано, что для каждой неструктурированной программы можно построить функционально эквивалентную (т.е. решающую ту же задачу) структурированную программу. Для структурированных программ можно математически доказывать некоторые свойства, что позволяет обнаруживать в программе некоторые ошибки. Этому вопросу будет посвящена отдельная лекция.
Структурное программирование иногда называют еще "программированием без GO TO". Однако дело здесь не в операторе GO TO, а в его беспорядочном использовании. Очень часто при воплощении структурного программирования на некоторых языках программирования (например, на ФОРТРАНе) оператор перехода (GO TO) используется для реализации структурных конструкций, что не нарушает принципов структурного программирования. Запутывают программу как раз "неструктурные" операторы перехода, особенно переход к оператору, расположенному в тексте модуля выше (раньше) выполняемого оператора перехода. Тем не менее, попытка из-бежать оператора перехода в некоторых простых случаях может привести к слишком громоздким структурированным программам, что не улучшает их ясность и содержит опасность появления в тексте модуля дополнительных ошибок. Поэтому можно рекомендовать избегать употребления оператора перехода всюду, где это возможно, но не ценой ясности программы [8.1].
К полезным случаям использования оператора перехода можно отнести выход из цикла или процедуры по особому условию, "досрочно" прекращающего работу данного цикла или данной процедуры, т.е. завершающего работу некоторой структурной единицы (обобщенного оператора) и тем самым лишь локально нарушающего структурированность программы. Большие трудности (и усложнение структуры) вызывает структурная реализация реакции на возникающие исключительные (часто ошибочные) ситуации, так как при этом требуется не только осуществить досрочный выход из структурной единицы, но и произвести необходимую обработку (исключение) этой ситуации (например, выдачу подходящей диагностической информации). Обработчик исключительной ситуации может находиться на любом уровне структуры программы, а обращение к нему может производиться с разных нижних уровней. Вполне приемлемой с технологической точки зрения является следующая "неструктурная" реализация реакции на исключительные ситуации [8.7]. Обработчики исключительных ситуаций помещаются в конце той или иной структурной единицы и каждый такой обработчик программируется таким образом, что после окончания своей работы производит выход из той структурной единицы, в конце которой он помещен. Обращение к такому обработчику производится оператором перехода из данной структурной единицы (включая любую вложенную в нее структурную единицу).

8.3. Пошаговая детализация и понятие о псевдокоде.

Структурное программирование дает рекомендации о том, каким должен быть текст модуля. Возникает вопрос, как должен действовать программист, чтобы построить такой текст. Часто программирование модуля начинают с построения его блок-схемы, описывающей в общих чертах логику его работы. Однако современная технология программирования не рекомендует этого делать без подходящей компьютерной поддержки. Хотя блок-схемы позволяют весьма наглядно представить логику работы модуля, при их ручном кодировании на языке программирования возникает весьма специфический источник ошибок: отображение существенно двумерных структур, какими являются блок-схемы, на линейный текст, представляющий модуль, содержит опасность искажения логики работы модуля, тем более, что психологически довольно трудно сохранить высокий уровень внимания при повторном ее рассмотрении. Исключением может быть случай, когда для построения блок-схем используется графический редактор и они формализованы настолько, что по ним автоматически генерируется текст на языке программирования (как, например, это делается в Р-технологии [8.6]).
В качестве основного метода построения текста модуля совре-менная технология программирования рекомендует пошаговую детализацию [8.1, 8.3, 8.5]. Сущность этого метода заключается в разбиении процесса разработки текста модуля на ряд шагов. На первом
шаге описывается общая схема работы модуля в обозримой линейной текстовой форме (т.е. с использованием очень крупных понятий), причем это описание не является полностью формализованным и ориентировано на восприятие его человеком. На каждом следующем шаге производится уточнение и детализация одного из понятий (будем называть его уточняемым), в каком либо описании, разработанном на одном из предыдущих шагов. В результате такого шага создается описание выбранного уточняемого понятия либо в терминах базового языка программирования (т.е. выбранного для представления модуля), либо в такой же форме, что и на первом шаге с использованием новых уточняемых понятий. Этот процесс завершается, когда все уточняемые понятия будут уточнения (т.е. в конечном счете будут выражены на базовом языке программирования). Последним шагом является получение текста модуля на базовом языке программирования путем замены всех вхождений уточняемых понятий заданными их описаниями и выражение всех вхождений конструкций структурного программирования средствами этого языка программирования.
Пошаговая детализация связана с использованием частично формализованного языка для представления указанных описаний, который получил название псевдокода [8.5, 8.8]. Этот язык позволяет использовать все конструкции структурного программирования, которые оформляются формализованно, вместе с неформальными фрагментами на естественном языке для представления обобщенных операторов и условий. В качестве обобщенных операторов и условий могут задаваться и соответствующие фрагменты на базовом языке программирования.
Головным описанием на псевдокоде можно считать внешнее оформление модуля на базовом языке программирования, которое
должно содержать:

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

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

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

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

ИСКЛЮЧЕНИЕ имя_исключения
обобщенный_оператор
ВСЕ ИСКЛЮЧЕНИЕ

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

Рис. 8.4. Пример одного шага детализации на псевдокоде.
Идею пошаговой детализации приписывают иногда Дейкстре [8.1]. Однако Дейкстра предлагал принципиально отличающийся метод построения текста модуля [8.2], который нам представляется более глубоким и перспективным. Во-первых, вместе с уточнением операторов он предлагал постепенно (по шагам) уточнять (детализировать) и используемые структуры данных. Во-вторых, на каждом шаге он предлагал создавать некоторую виртуальную машину для детализации и в ее терминах производить детализацию всех уточняемых понятий, для которых эта машина позволяет это сделать. Таким образом, Дейкстра предлагал, по существу, детализировать по горизонтальным слоям, что является перенесением его идеи о слоистых системах (см. лекцию 6) на уровень разработки модуля. Такой метод разработки модуля поддерживается в настоящее время пакетами языка АДА [8.7] и средствами объектно-ориентированного программирования [8.9].

8.4. Контроль программного модуля.

Применяются следующие методы контроля программного модуля:

• статическая проверка текста модуля;
• сквозное прослеживание;
• доказательство свойств программного модуля.

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

Упражнения к лекции 8.

8.1. Что такое структурное программирование?
8.2. Что такое пошаговая детализация программного модуля?
8.3. Что такое псевдокод?

Литература к лекции 8.

8.1. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 127-154.
8.2. Э.Дейкстра. Заметки по структурному программированию / У.Дал, Э.Дейкстра, К.Хоор. Структурное программирование. - М.: Мир, 1975. - С. 24-97.
8.3. Н.Вирт. Систематическое программирование. - М.: Мир, 1977. - С. 94-164.

[Tic-Sakyra]

Встречаются две подруги. Одна говорит другой:
- С моим мужем творится что-то странное.
Приходит с работы, наливает полную ванну воды,
берет удочку и весь вечер ловит рыбу.
- А почему ты не обратишься к врачу?
- Надо бы. Но так хочется свежей рыбки!
Анекдот

Лекция 9.
ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ

Понятие обоснования программ. Формализация свойств программ, триады Хоора. Правила для установления свойств оператора присваивания, условного и составного операторов. Правила для установления свойств оператора цикла, понятие инварианта цикла. Завершимость выполнения программы.

9.1. Обоснования программ. Формализация свойств программ.

Для повышения надежности программных средств весьма полезно снабжать программы дополнительной информацией, с использованием которой можно существенно повысить уровень контроля ПС. Такую информацию можно задавать в форме неформализованных или формализованных утверждений, привязываемых к различным фрагментам программ. Будем называть такие утверждения обоснованиями программы. Неформализованные обоснования программ могут, например, объяснять мотивы принятия тех или иных решений, что может существенно облегчить поиск и исправление ошибок, а также изучение программ при их сопровождении. Формализованные же обоснования позволяют доказывать некоторые свойства программ как вручную, так и контролировать (устанавливать) их автоматически.
Одной из используемых в настоящее время концепций формальных обоснований программ является использование так называемых триад Хоора.Пусть S  некоторый обобщенный оператор над информационной средой IS, а P и Q  некоторые предикаты (утверждения) над этой средой. Тогда запись {P}S{Q} и называют триадой Хоора, в которой предикат P называют предусловием, а предикат Q  постусловием относительно оператора S. Говорят, что оператор (в частности, программа) S обладает свойством {P}S{Q}, если всякий раз, когда перед выполнением оператора S истинен предикат P, после выполнения этого оператора S будет истинен предикат Q.
Простые примеры свойств программ:

Для доказательства свойства программы S используются свойства простых операторов языка программирования (мы здесь ограничимся пустым оператором и оператором присваивания) и свойствами управляющих конструкций (композиций), с помощью которых строится программа из простых операторов (мы здесь ограничимся тремя основными композициями структурного программирования, см. Лекцию 8). Эти свойства называют обычно правилами верификации программ.

9.2. Свойства простых операторов.

Для пустого оператора справедлива Теорема 9.1.
Пусть P  предикат над информационной средой. Тогда имеет место свойство {P}{P}.
Доказательство этой теоремы очевидно: пустой оператор не изменяет состояние информационной среды (в соответствии со своей семантикой), поэтому его предусловие сохраняет истинность и после его выполнения.
Для оператора присваивания справедлива Теорема 9.2.
Пусть информационная среда IS состоит из переменной X и остальной части информационной среды RIS:
IS = (X, RIS).
Тогда имеет место свойство
{Q(F(X, RIS), RIS)} X:= F(X, RIS) {Q(X, RIS)} ,
где F(X, RIS)  некоторая однозначная функция, Q  предикат.
Доказательство. Пусть (X0, RIS0)  некоторое произвольное состояние информационной среды IS, и пусть перед выполнением оператора присваивания предикат Q(F(X0, RIS0), RIS0) является истинным. Тогда после выполнения оператора присваивания будет истинен предикат Q(X, RIS), так как X получит значение F(X0, RIS0), а состояние RIS не изменяется данным оператором присваивания, и, следовательно, после выполнения этого оператора присваивания в этом случае
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
В силу произвольности выбора состояния информационной среды теорема доказана.
Примером свойства оператора присваивания может служить пример 9.1.

9.3. Свойства основных конструкций структурного программирования.

Рассмотрим теперь свойства основных конструкций структурного программирования: следования, разветвления и повторения. Свойство следования выражает следующая
Теорема 9.3. Пусть P, Q и R  предикаты над информационной средой, а S1 и S2  обобщенные операторы, обладающие соответственно свойствами
{P}S{Q} и {Q}S2{R}.
Тогда для составного оператора
S1; S2
имеет место свойство
{P} S1; S2 {R} .

Доказательство. Пусть для некоторого состояния информаци-онной среды перед выполнением оператора S1 истинен предикат P. Тогда в силу свойства оператора S1 после его выполнения будет истинен предикат Q. Так как по семантике составного оператора после выполнения оператора S1 будет выполняться оператор S2, то предикат Q будет истинен и перед выполнением оператора S2. Следовательно, после выполнения оператора S2 в силу его свойства будет истинен предикат R, а так как оператор S2 завершает выполнение составного оператора (в соответствии с его семантикой), то предикат R будет истинен и после выполнения данного составного оператора, что и требовалось доказать.
Например, если имеют место свойства (9.2) и (9.3), то имеет
место и свойство
{n<m} n:= n + k; n:= 3n {n<3(m + k)}.
Свойство разветвления выражает следующая
Теорема 9.4. Пусть P, Q и R  предикаты над информационной средой, а S1 и S2  обобщенные операторы, обладающие соответственно свойствами
{P,Q} S1{R} и {P,Q} S2 {R}.
Тогда для условного оператора
ЕСЛИ P ТО S1ИНАЧЕ S2 ВСЕ ЕСЛИ
имеет место свойство
{Q} ЕСЛИ P ТО S1ИНАЧЕ S2 ВСЕ ЕСЛИ {R} .

Доказательство. Пусть для некоторого состояния информаци-онной среды перед выполнением условного оператора истинен предикат Q. Если при этом будет истинен также и предикат P, то выполнение условного оператора в соответствии с его семантикой сводится к выполнению оператора S1. В силу же свойства оператора S1 после его выполнения (а в этом случае  и после выполнения условного оператора) будет истинен предикат R. Если же перед выполнением условного оператора предикат P будет ложен (а Q, по-прежнему, истинен), то выполнение условного оператора в соответствии с его семантикой сводится к выполнению оператора S2. В силу же свойства оператора S2 после его выполнения (а в этом случае  и после выполнения условного оператора) будет истинен предикат R. Тем самым теорема полностью доказана.
Прежде чем переходить к свойству конструкции повторения следует отметить полезную для дальнейшего
Теорему 9.5. Пусть P, Q, P1 и Q1  предикаты над информационной средой, для которых справедливы импликации
P1 P и Q Q1,
и пусть для оператора S имеет место свойство {P}S{Q}.Тогда имеет место свойство {P1}S{Q1} .
Эту теорему называют еще теоремой об ослаблении свойств.
Доказательство. Пусть для некоторого состояния информационной среды перед выполнением оператора S истинен предикат P1. Тогда будет истинен и предикат P (в силу импликации P1 P). Следовательно, в силу свойства оператора S после его выполнения будет истинен предикат Q, а значит и предикат Q1 (в силу импликации Q Q1). Тем самым теорема доказана.
Свойство повторения выражает следующая

(по теореме 9.5 на основании имеющихся в условиях данной теоремы импликаций). Пусть для некоторого состояния информационной среды перед выполнением оператора цикла истинен предикат I. Если при этом предикат Q будет ложен, то оператор цикла будет эквивалентен пустому оператору (в соответствии с его семантикой) и в силу теоремы 9.1 после выполнения оператора цикла будет справедливо утверждение (I,Q). Если же перед выполнением оператора цикла предикат Q будет истинен, то оператор цикла в соответствии со своей семантикой может быть представлен в виде составного оператора
S; ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА
В силу свойства оператора S после его выполнения будет истинен предикат I, и возникает исходная ситуация для доказательства свойства оператора цикла: предикат I истинен перед выполнением оператора цикла, но уже для другого (измененного) состояния информационной среды (для которого предикат Q может быть либо истинен либо ложен). Если выполнение оператора цикла завершается, то, применяя метод математической индукции, мы за конечное число шагов придем к ситуации, когда перед его выполнением будет справедливо утверждение (I,Q). А в этом случае, как было доказано выше, это утверждение будет справедливо и после выполнения оператора цикла. Теорема доказана.

9.4. Завершимость выполнения программы.

Одно из свойств программы, которое нас может интересовать, чтобы избежать возможных ошибок в ПС, является ее завершимость, т.е. отсутствие в ней зацикливания при тех или иных исходных данных. В рассмотренных нами структурированных программах источником зацикливания может быть только конструкция повторения. Поэтому для доказательства завершимости программы достаточно уметь доказывать завершимость оператора цикла. Для этого полезна следующая:
Теорема 9.7. Пусть F  целочисленная функция, зависящая от со-стояния информационной среды и удовлетворяющая следующим условиям:
(1) если для данного состояния информационной среды истинен предикат Q, то ее значение положительно;
(2) она убывает при изменении состояния информационной среды в результате выполнения оператора S.
Тогда выполнение оператора цикла
ПОКА Q ДЕЛАТЬ S ВСЕ ПОКА
завершается.
Доказательство. Пусть IS  состояние информационной среды пе-ред выполнением оператора цикла и пусть F(IS)= k. Если предикат Q(IS) ложен, то выполнение оператора цикла завершается. Если же предикат Q(IS) истинен, то по условию теоремы k>0. В этом случае будет выполняться оператор S один или более раз. После каждого выполнения оператора S по условию теоремы значение функции F уменьшается, а так как перед выполнением оператора S предикат Q должен быть истинен (по семантике оператора цикла), то значение функции F в этот момент должно быть положительно (по условию теоремы). Поэтому в силу целочисленности функции F оператор S в этом цикле не может выполняться более k раз. Теорема доказана.
Например, для рассмотренного выше примера оператора цикла
условиям теоремы 9.7 удовлетворяет функция f(n, m)= nm. Так как перед выполнением оператора цикла m=1, то тело этого цикла будет выполняться (n1) раз, т.е. этот оператор цикла завершается.

9.5. Пример доказательства свойства программы.

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

Упражнения к лекции 9.

Литература к лекции 9.

9.1. С.А. Абрамов. Элементы программирования. - М.: Наука, 1982. С. 85-94.
9.2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки про-граммного обеспечения. - М.: Мир, 1982. С. 98-105.

[Tic-Sakyra]

Лишь та - ошибка, что не исправляется.
Конфуций

Лекция 10.
ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА

Основные понятия. Стратегия проектирования тестов. Заповеди отладки. Автономная отладка и тестирование программного модуля. Комплексная отладка и тестирование программного средства.

10.1. Основные понятия.

Отладка ПС  это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС  это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование.
В зарубежной литературе отладку часто понимают [10.1-10.3] только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами [10.4,10.5]. В нашей стране в понятие отладки обычно включают и тестирование [10.6 -10.8], поэтому мы будем следовать сложившейся традиции. Впрочем, совместное рассмотрение в данной лекции этих процессов делает указанное разночтение не столь существенным. Следует, однако, отметить, что тестирование используется и как часть процесса аттестации ПС (см. лекцию 14).

10.2. Принципы и виды отладки программного средства.

Успех отладки ПС в значительной степени предопределяет рациональная организация тестирования. При отладке ПС отыскиваются и устраняются, в основном, те ошибки, наличие которых в ПС устанавливается при тестировании. Как было уже отмечено, тестирование не может доказать правильность ПС [10.9], в лучшем случае оно может продемонстрировать наличие в нем ошибки. Другими словами, нельзя гарантировать, что тестированием ПС практически выполнимым набором тестов можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая задача: подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС. Отсюда вторая задача: определить момент окончания отладки ПС (или отдельной его компоненты). Признаком возможности окончания отладки является полнота охвата пропущенными через ПС тестами (т.е. тестами, к которым применено ПС) множества различных ситуаций, возникающих при выполнении программ ПС, и относительно редкое проявление ошибок в ПС на последнем отрезке процесса тестирования. Последнее определяется в соответствии с требуемой степенью надежности ПС, указанной в спецификации его качества.
Для оптимизации набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале времени, отведенном на тестирование) обнаруживать большее число ошибок в ПС, необходимо, во-первых, заранее планировать этот набор и, во-вторых, использовать рациональную стратегию планирования (проектирования [10.1]) тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПС. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить (см. рис. 9.1) между следующими двумя крайними подходами [10.1]. Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС (внешнего описания, описания архитектуры и спецификации модулей). Строение модулей при этом никак не учитывается, т.е. они рассматриваются как черные ящики. Фактически такой подход требует полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, а это значит, что содержащиеся в них ошибки не будут проявляться. Однако тестирование ПС полным множеством наборов входных данных практически неосуществимо. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться также чрезвычайно много, так что их тестирование также будет практически неосуществимо.

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

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

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

10.3. Заповеди отладки программного средства.

В этом разделе даются общие рекомендации по организации отладки ПС. Но сначала следует отметить некоторый феномен [10.1], который подтверждает важность предупреждения ошибок на предыдущих этапах разработки: по мере роста числа обнаруженных и исправленных ошибок в ПС растет также относительная вероятность существования в нем необнаруженных ошибок. Это объясняется тем, что при росте числа ошибок, обнаруженных в ПС, уточняется и наше представление об общем числе допущенных в нем ошибок, а значит, в какой-то мере, и о числе необнаруженных еще ошибок.
Ниже приводятся рекомендации по организации отладки в форме заповедей [10.1, 10.8].
Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.
Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.
Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.
Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить.
Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.
Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

10.4. Автономная отладка программного средства.

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

• простота подготовки тестов,
• возможность полной реализации плана тестирования модуля.

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

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

К достоинствам нисходящего тестирования относятся сле-дующие его особенности:

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

Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно  оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами. Это, во-первых, затрудняет подготовку тестов и требует высокой квалификации тестовика (разработчика тестов), а во-вторых, делает затруднительным или даже невозможным реализацию полного плана тестирования отлаживаемого модуля. Указанный недостаток иногда вынуждает разработчиков применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования. Исходя из того, что нисходящее тести-рование, в принципе, является предпочтительным, остановимся на приемах, позволяющих в какой-то мере преодолеть указанные трудности.
Прежде всего, необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены модули, осуществляющие ввод данных,  тогда тестовые данные можно готовить в форме, рассчитанной на пользователя, что существенно упростит подготовку последующих тестов. Далеко не всегда этот ввод осуществляется в головном модуле, поэтому приходится в первую очередь отлаживать цепочки модулей, ведущие к модулям, осуществляющим указанный ввод (ср. с методом целенаправленной конструктивной реализации в лекции 7). Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим ими-татором.
При нисходящем тестировании некоторые состояния информационной среды, при которых требуется тестировать отлаживаемый модуль, могут не возникать при выполнении отлаживаемой программы ни при каких входных данных. В этих случаях можно было бы вообще не тестировать отлаживаемый модуль, так как обнаруживаемые при этом ошибки не будут проявляться при выполнении отлаживаемой программы ни при каких входных данных. Однако так поступать не рекомендуется, так как при изменениях отлаживаемой программы (например, при сопровождении ПС) не использованные для тестирования отлаживаемого модуля состояния информационной среды могут уже возникать, что требует дополнительного тестирования этого модуля (а этого при рациональной организации отладки можно было бы не делать, если сам данный модуль не изменялся). Для осуществления тестирования отлаживаемого модуля в указанных ситуациях иногда используют подходящие имитаторы, чтобы создать требуемое состояние информационной среды. Чаще же пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их интеграцией предварительно тестируются отдельно (в этом случае в окружении отлаживаемого модуля появляется ведущий отладочный модуль, наряду с имитаторами модулей, к которым может обращаться отлаживаемый модуль). Однако, представляется более целесообразной другая модификация нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для достижимых тестовых состояний информационной среды следует его отдельно про-тестировать для остальных требуемых состояний информационной среды.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича [10.1]. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы. Этот метод при разумном порядке тестирования позволяет воспользоваться достоинствами как восходящего, так и нисходящего тестирования, а также в значительной степени нейтрализовать их недостатки.
Весьма важным при автономной отладке является тестирование
сопряжения модулей. Дело в том, что спецификация каждого модуля программы, кроме головного, используется в этой программы в двух ситуациях: во-первых, при разработке текста (иногда говорят: тела) этого модуля и, во-вторых, при написании обращения к этому модулю в других модулях программы. И в том, и в другом случае в результате ошибки может быть нарушено требуемое соответствие заданной спецификации модуля. Такие ошибки требуется обнаруживать и устранять. Для этого и предназначено тестирование сопряжения модулей. При нисходящем тестировании тестирование сопряжения осуществляется попутно каждым пропускаемым тестом, что считают достоинством нисходящего тестирования. При восходящем тестировании обращение к отлаживаемому модулю производится не из модулей отлаживаемой программы, а из ведущего отладочного модуля. В связи с этим существует опасность, что последний модуль может приспособиться к некоторым "заблуждениям" отлаживаемого модуля. Поэтому, приступая (в процессе интеграции программы) к отладке нового модуля, приходится тестировать каждое обращение к ранее отлаженному модулю с целью обнаружения несогласованности этого обращения с телом соответствующего модуля (и не исключено, что виноват в этом ранее отлаженный модуль). Таким образом, приходится частично повторять в новых условиях тестирование ранее отлаженного модуля, при этом возникают те же трудности, что и при нисходящем тестировании.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага [10.1].
Шаг 1.На основании спецификации отлаживаемого модуля под-готовьте тесты для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.
Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4.Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.

10.5. Комплексная отладка программного средства.

Как уже было сказано выше, при комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС [10.8]. Тестирование этих документов производится, как правило, в порядке, обратном их разработке. Исключение составляет лишь тестирование документации по применению, которая разрабатывается по внешнему описанию параллельно с разработкой текстов программ  это тестирование лучше производить после завершения тестирования внешнего описания. Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые в принципе могут возникнуть у пользователя (в частности, все тесты готовятся в форме, рассчитанной на пользователя), но, возможно, в моделируемой (а не в реальной) среде. Например, некоторые недоступные при комплексной отладке устройства ввода и вывода могут быть заменены их программными имитаторами.
Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы. Ошибки реализации архитектуры могут быть связаны, прежде всего, с взаимодействием этих подсистем, в частности, с реализацией архитектурных функций (если они есть). Поэтому хотелось бы проверить все пути взаимодействия между подсистемами ПС. При этом желательно хотя бы протестировать все цепочки выполнения подсистем без повторного вхождения последних. Если заданная архитектура представляет ПС в качестве малой системы из выделенных подсистем, то число таких цепочек будет вполне обозримо.
Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной спецификацией и совокупностью программ ПС. Несмотря на то, что все эти программы автономно уже отлажены, указанные расхождения могут быть, например, из-за несоответствия внутренних спецификаций программ и их модулей (на основании которых производилось автономное тестирование) функциональной спецификации ПС. Как правило, тестирование внешних функций производится так же, как и тестирование модулей на первом шаге, т.е. как черного ящика.
Тестирование качества ПС. Целью тестирования является по-иск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием (об оценке качества ПС см. лекцию 14). Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако, методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, защищенность, временная эффективность, в какой-то мере  эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает от-дельного рассмотрения. Мы здесь ограничимся лишь их перечислением. Легкость применения ПС (критерий качества, включающий несколько примитивов качества, см. лекцию 4) оценивается при тестировании документации по применению ПС.
Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также выявление неудобств, возникающих при применении ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию определения требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим воспользоваться ПС так, как это будет делать пользователь [10.1]. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Прежде всего, должны тестироваться возможности ПС как это делалось при тестировании внешних функций, но только на основании документации по применению. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации. Далее тестируются наиболее трудные случаи применения ПС с целью обнаружить нарушение требований относительности легкости применения ПС.
Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь ПС [10.1] как один из путей преодоления барьера между разработчиком и пользователем (см. лекцию 3). Обычно это тестирование производится с помощью контрольных задач  типовых задач, для которых известен результат решения. В тех случаях, когда разрабатываемое ПС должно придти на смену другой версии ПС, которая решает хотя бы часть задач разрабатываемого ПС, тестирование производится путем решения общих задач с помощью как старого, так и нового ПС (с последующим сопоставлением полученных результатов). Иногда в качестве формы такого тестирования используют опытную эксплуатацию ПС  ограниченное применение нового ПС с анализом использования результатов в практической деятельности. По существу, этот вид тестирования во многом перекликается с испытанием ПС при его аттестации (см. лекцию 14), но выполняется до аттестации, а иногда и вместо аттестации.

Упражнения к лекции 10.

10.1. Что такое отладка программного средства?
10.2. Что такое тестирование программного средства?
10.3. Что такое автономная отладка программного средства?
10.4. Что такое комплексная отладка программного средства?
10.5. Что такое ведущий отладочный модуль?
10.6. Что такое отладочный имитатор программного модуля?

Литература к лекции 10.

10.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 171-262.
10.2. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - С. 179-295.
10.3. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. - М.: Мир, 1980. - С. 254-268.
10.4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 227-241.
10.5. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 105-116.
10.6. Ю.М. Безбородов. Индивидуальная отладка программ. - М.: Наука, 1982. - С. 9-79.
10.7. В.В. Липаев. Тестирование программ. - М.: Радио и связь, 1986. - С. 15-47.
10.8. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
10.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-13.

[Tic-Sakyra]

Плохо не клади, вора в грех не вводи.
Народная пословица

Лекция 11.
ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОСТИ И
НАДЕЖНОСТИ ПРОГРАММНОГО СРЕДСТВА

Функциональность и надежность как обязательные критерии качества программного средства. Обеспечение завершенности программного средства. Защитное программирование и обеспечение устойчивости программного модуля. Виды защиты и обеспечение защищенности программного средства.

11.1. Функциональность и надежность как обязательные критерии качества программного средства.

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

11.2. Обеспечение завершенности программного средства.

Завершенность ПС является общим примитивом качества ПС для выражения и функциональности и надежности ПС, причем для функциональности она является единственным примитивом (см. лекцию 4).
Функциональность ПС определяется его функциональной спецификацией. Завершенность ПС как примитив его качества является мерой того, в какой степени эта спецификация реализована в разрабатываемом ПС. Обеспечение этого примитива в полном объеме означает реализацию каждой из функций, определенной в функциональной спецификации, со всеми указанными там деталями и особенностями. Все рассмотренные ранее технологические процессы показывают, как это может быть сделано.
Однако в спецификации качества ПС могут быть определены несколько уровней реализации функциональности ПС: может быть определена некоторая упрощенная (начальная или стартовая) версия, которая должна быть реализована в первую очередь; могут быть также определены и несколько промежуточных версий. В этом случае возникает дополнительная технологическая задача: организация наращивания функциональности ПС. Здесь важно отметить, что разработка упрощенной версии ПС не есть разработка его прототипа. Прототип разрабатывается для того, чтобы лучше понять условия применения будущего ПС [11.1], уточнить его внешнее описание. Он рассчитан на избранных пользователей и поэтому может сильно отличаться от требуемого ПС не только выполняемыми функциями, но и особенностями пользовательского интерфейса. Упрощенная же версия разрабатываемого ПС должна быть рассчитана на практически полезное применение любыми пользователями, для которых предназначено это ПС. Поэтому главный принцип обеспечения функциональности такого ПС заключается в том, чтобы с самого начала разрабатывать ПС таким образом, как будто требуется ПС в полном объеме, до тех пор, когда разработчики будут иметь дело непосредственно с теми частями или деталями ПС, реализацию которых можно отложить в соответствии со спецификацией его качества. Тем самым, и внешнее описание и описание архитектуры ПС должно быть разработано в полном объеме. Можно отложить лишь реализацию тех программных подсистем (определенных в архитектуре разрабатываемого ПС), функционирования которых не требуется в начальной версии этого ПС. Реализацию же самих программных подсистем лучше всего производить методом целенаправленной конструктивной реализации, оставляя в начальной версии ПС подходящие имитаторы тех программных модулей, функционирование которых в этой версии не требуется. Допустима также упрощенная реализация некоторых программных модулей, опускающая реализацию некоторых деталей соответствующих функций. Однако такие модули с технологической точки зрения лучше рассматривать как своеобразные их имитаторы (хотя и далеко продвинутые).
Достигнутый при обеспечении функциональности ПС уровень его завершенности на самом деле может быть не таким, как ожидалось, из-за ошибок, оставшихся в этом ПС. Можно лишь говорить, что требуемая завершенность достигнута с некоторой вероятностью, определяемой объемом и качеством проведенного тестирования. Для того чтобы повысить эту вероятность, необходимо продолжить тестирование и отладку ПС. Однако, оценивание такой вероятности является весьма специфической задачей, которая пока еще ждет соответствующих теоретических исследований.

11.3. Обеспечение точности программного средства.

Обеспечение этого примитива качества связано с действиями над значениями вещественных типов (точнее говоря, со значениями, представляемыми с некоторой погрешностью). Обеспечить требуемую точность при вычислении значения той или иной функции  значит получить это значение с погрешностью, не выходящей за рамки заданных границ. Видами погрешности, методами их оценки и методами достижения требуемой точности (т.н. приближенными вычислениями) занимается вычислительная математика [11.1, 11.2]. Здесь мы лишь обратим внимание на некоторую структуру погрешности: погрешность вычисленного значения (полная погрешность) зависит
• от погрешности используемого метода вычисления (в которую мы включаем и неточность используемой модели),
• от погрешности представления используемых данных (от т.н. неустранимой погрешности),
• от погрешности округления (неточности выполнения используемых в методе операций).

11.4. Обеспечение автономности программного средства.

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

11.5. Обеспечение устойчивости программного средства.

Этот примитив качества ПС обеспечивается с помощью так называемого защитного программирования. Вообще говоря, защитное программирование применяется при программировании модуля для повышения надежности ПС в более широком смысле. Как утверждает Майерс [11.3], «защитное программирование основано на важной предпосылке: худшее, что может сделать модуль, – это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат». Для того, чтобы этого избежать, в текст модуля включают проверки его входных и выходных данных на их корректность в соответствии со спецификацией этого модуля, в частности, должны быть проверены выполнение ограничений на входные и выходные данные и соотношений между ними, указанные в спецификации модуля. В случае отрицательного результата проверки возбуждается соответствующая исключительная ситуация. Для обработки таких ситуаций в конец этого модуля включаются фрагменты второго рода – обработчики соответствующих исключительных ситуаций. Эти обработчики помимо выдачи необходимой диагностической информации, могут принять меры либо по исключению ошибки в данных (например, потребовать их повторного ввода), либо по ослаблению влияния ошибки (например, во избежание поломки устройств, управляемых с помощью данного ПС, при аварийном прекращении выполнения программы осуществляют мягкую их остановку).
Применение защитного программирования модулей приводит к снижению эффективности ПС как по времени, так и по памяти. Поэтому необходимо разумно регулировать степень применения защитного программирования в зависимости от требований к надежности и эффективности ПС, сформулированных в спецификации качества разрабатываемого ПС. Входные данные разрабатываемого модуля могут поступать как непосредственно от пользователя, так и от других модулей. Наиболее употребительным случаем применения защитного программирования является применение его для первой группы данных, что и означает реализацию устойчивости ПС. Это нужно делать всегда, когда в спецификации качества ПС имеется требование об обеспечении устойчивости ПС. Применение защитного программирования для второй группы входных данных означает попытку обнаружить ошибку в других модулях во время выполнения разрабатываемого модуля, а для выходных данных разрабатываемого модуля  попытку обнаружить ошибку в самом этом модуле во время его выполнения. По существу, это означает частичное воплощение подхода самообнаружения ошибок для обеспечения надежности ПС, о чем шла речь в лекции 3. Этот случай защитного программирования применяется крайне редко  только в том случае, когда требования к надежности ПС чрезвычайно высоки.

11.6. Обеспечение защищенности программных средств.

Различают следующие виды защиты ПС от искажения информации:
• защита от сбоев аппаратуры;
• защита от влияния «чужой» программы;
• защита от отказов «своей» программы;
• защита от ошибок оператора (пользователя);
• защита от несанкционированного доступа;
• защита от защиты.
11.6.1 Защита от сбоев аппаратуры.В настоящее время этот вид защиты является не очень злободневной задачей (с учетом уровня достигнутой надежности компьютеров). Но все же полезно знать ее решение. Это обеспечивается организацией т.н. «двойных или тройных просчетов». Для этого весь процесс обработки данных, определяемый ПС, разбивается по времени на интервалы так называемыми «опорными точками». Длина этого интервала не должна превосходить половины среднего времени безотказной работы компьютера. В начале каждого такого интервала во вторичную память записывается с некоторой контрольной суммой копия состояния изменяемой в этом процессе памяти («опорная точка»). Для того, чтобы убедиться, что обработка данных от одной опорной точки до следующей (т.е. один «просчет») произведена правильно (без сбоев компьютера), производится два таких «просчета». После первого «просчета» вычисляется и запоминается указанная контрольная сумма, а затем восстанавливается состояние памяти по опорной точке и делается второй «просчет». После второго «просчета» вычисля-ется снова указанная контрольная сумма, которая затем сравнивается с контрольной суммой первого «просчета». Если эти две контрольные суммы совпадают, второй просчет считается правильным, в противном случае контрольная сумма второго «просчета» также запоминается и производится третий «просчет» (с предварительным восстановлением состояния памяти по опорной точке). Если контрольная сумма третьего «просчета» совпадет с контрольной суммой одного из первых двух «просчетов», то третий просчет считается правильным, в противном случае требуется инженерная проверка компьютера.
11.6.2. Защита от влияния «чужой» программы. При появлении мультипрограммного режима работы компьютера в его памяти может одновременно находиться в стадии выполнения несколько программ, попеременно получающих управление в результате возникающих прерываний (т.н. квазипараллельное выполнение программ). Одна из таких программ (обычно: операционная система) занимается обработкой прерываний и управлением мультипрограммным режимом. Здесь под «чужой» программой понимается программа (или какой-либо программный фрагмент), выполняемая параллельно (или квазипараллельно) по отношению к защищаемой программе (или ее фрагменту). Этот вид защиты должна обеспечить, чтобы эффект выполнения защищаемой программы не зависел от того, какие программы выполняются параллельно с ней, и относится, прежде всего, к функциям операционных систем.
Различают две разновидности этой защиты:
• защита от отказов «чужой» программы,
• защита от злонамеренного влияния «чужой» программы.
Защита от отказов «чужой» программы означает, что на выполнение функций защищаемой программой не будут влиять отказы (проявления ошибок), возникающие в параллельно выполняемых программах. Для того чтобы управляющая программа (операционная система) могла обеспечить защиту себя и других программ от такого влияния, аппаратура компьютера должна реализовывать следующие возможности:
* защиту памяти,
* два режима функционирования компьютера: привилегирован-ный и рабочий (пользовательский),
* два вида операций: привилегированные и ординарные,
* корректную реализацию прерываний и начального включения компьютера,
* временнóе прерывание.
Защита памяти означает возможность программным путем задавать для каждой программы недоступные для нее участки памяти. В привилегированном режиме могут выполняться любые операции (как ординарные, так и привилегированные), а в рабочем режиме  только ординарные. Попытка выполнить привилегированную операцию, а также обратиться к защищенной памяти в рабочем режиме вызывает соответствующее прерывание. К привилегированным операциям относятся операции изменения защиты памяти и режима функционирования, а также доступа к внешней информационной среде. Корректная реализация прерываний и начального включения компьютера означает обязательную установку привилегированного режима и отмену защиты памяти. В этих условиях управляющая программа (операционная система) может полностью защитить себя от влияния отказов других программ. Для этого достаточно, чтобы
• все точки передачи управления при начальном включении компьютера и при прерываниях принадлежали этой программе,
• она не позволяла никакой другой программе работать в привилегированном режиме (при передаче управления любой другой программе должен включаться только рабочий режим),
• она полностью защищала свою память (содержащую, в частности, всю ее управляющую информацию, включая так называемые вектора прерываний) от других программ.
Тогда никто не помешает ей выполнять любые реализованные в ней функции защиты других программ (в том числе и доступа к внешней информационной среде). Для облегчения решения этой задачи часть такой программы помещается в постоянную память. Наличие временнóго прерывания позволяет управляющей программе защититься от зацикливания в других программах (без такого прерывания она могла бы просто лишиться возможности управлять).
Защита от злонамеренного влияния «чужих» программ означает, что изменение внешней информационной среды, предоставленной защищаемой программе, со стороны другой, параллельно выполняемой программы будет невозможно или сильно затруднено без ведома защищаемой программы. Для этого операционная система должна обеспечить подходящий контроль доступа к внешней информационной среде. Необходимым условием обеспечение такого контроля является обеспечения защиты от злонамеренного влияния «чужих» программ хотя бы самой операционной системы. В противном случае такой контроль можно было бы обойти путем изменения операционной системы со стороны «злонамеренной» программы.
Этот вид защиты включает, в частности, и защиту от т.н. «компьютерных вирусов», под которыми понимают фрагменты программ, способные в процессе своего выполнения внедряться (копироваться) в другие программы (или в отдельные программные фрагменты). «Компьютерные вирусы», обладая способностью к размножению (к внедрению в другие программы), при определенных условиях вызывают изменение эффекта выполнения «зараженной» программы, что может привести к серьезным деструктивным изменениям ее внешней информационной среды. Операционная система, будучи защищен-ной от влияния «чужих» программ, может ограничить доступ к программным фрагментам, хранящимся во внешней информационной среде. Так, например, может быть запрещено изменение таких фрагментов любыми программами, кроме некоторых, которые знает операционная система, или, другой вариант, может быть разрешено только после специальных подтверждений программы (или пользователя).
11.6.3. Защита от отказов «своей» программы. Обеспечивается надежностью ПС, на что ориентирована вся технология программирования, обсуждаемая в настоящем курсе лекций.
11.6.4. Защита от ошибок пользователя. Здесь идет речь не об ошибочных данных, поступающих от пользователя ПС,  защита от них связана с обеспечением устойчивости ПС, а о действиях пользователя, приводящих к деструктивному изменению состояния внешней информационной среды ПС, несмотря на корректность используемых при этом данных. Защита от таких действий, частично, обеспечивается выдачей предупредительных сообщений о попытках изменить состояние внешней информационной среды ПС с требованием подтверждения этих действий. Для случаев же, когда такие ошибки совершаются, может быть предусмотрена возможность восстановления состояния отдельных компонент внешней информационной среды ПС на определенные моменты времени. Такая возможность базируется на ведении (формировании) архива состояний (или изменений состояния) внешней информационной среды.
11.6.5. Защита от несанкционированного доступа. Каждому пользователю ПС предоставляет определенные информационные и процедурные ресурсы (услуги), причем у разных пользователей ПС предоставленные им ресурсы могут отличаться, иногда очень существенно. Этот вид защиты должен обеспечить, чтобы каждый пользователь ПС мог использовать только то, что ему предоставлено (санкционировано). Для этого ПС в своей внешней информационной среде может хранить информацию о своих пользователях и предоставленным им правах использования ресурсов, а также предоставлять пользователям определенные возможности формирования этой информации. Защита от несанкционированного доступа к ресурсам ПС осуществляется с помощью т.н. паролей (секретных слов). При этом предполагается, что каждый пользователь знает только свой пароль, зарегистрированный в ПС этим пользователем. Для доступа к выделенным ему ресурсам он должен предъявить ПС свой пароль. Другими словами, пользователь как бы "вешает замок" на предоставленные ему права доступа к ресурсам, "ключ" от которого имеется только у этого пользователя.
Различают две разновидности такой защиты:
• простая защита от несанкционированного доступа,
• защита от взлома защиты.
Простая защита от несанкционированного доступа обеспечивает защиту от использования ресурсов ПС пользователем, которому не предоставлены соответствующие права доступа или который указал неправильный пароль. При этом предполагается, что пользователь, получив отказ в доступе к интересующим ему ресурсам, не будет предпринимать попыток каким-либо несанкционированным образом обойти или преодолеть эту защиту. Поэтому этот вид защиты может применяться и в ПС, которая базируется на операционной системе, не обеспечивающей полную защиту от влияния «чужих» программ.
Защита от взлома защиты  это такая разновидность защиты от несанкционированного доступа, которая существенно затрудняет преодоление этой защиты. Это связано с тем, что в отдельных случаях могут быть предприняты настойчивые попытки взломать защиту от несанкционированного доступа, если защищаемые ресурсы представляют для кого-то чрезвычайную ценность. Для такого случая приходится предпринимать дополнительные меры защиты. Во-первых, необходимо обеспечить, чтобы такую защиту нельзя было обойти, т. е. должна действовать защита от влияния «чужих» программ. Во-вторых, необходимо усилить простую защиту от несанкционированного доступа использованием в ПС специальных программистских приемов, в достаточной степени затрудняющих подбор подходящего пароля или его вычисление по информации, хранящейся во внешней информационной среде ПС. Использование обычных паролей оказывается недостаточной, когда речь идет о чрезвычайно настойчивом стремлении добиться доступа к ценной информации. Если требуемый пароль («замок») в явном виде хранится во внешней информационной среде ПС, то "взломщик" этой защиты относительно легко может его достать, имея доступ к этому ПС. Кроме того, следует иметь в виду, что с помощью современных компьютеров можно осуществлять достаточно большой перебор возможных паролей с целью найти подходящий.
Защититься от этого можно следующим образом. Пароль (секретное слово или просто секретное целое число) X должен быть известен только владельцу защищаемых прав доступа и он не должен храниться во внешней информационной среде ПС. Для проверки прав доступа во внешней информационной среде ПС хранится другое число Y=F(X), однозначно вычисляемое ПС по предъявленному паролю X. При этом функция F может быть хорошо известной всем пользователям ПС, однако она должна обладать таким свойством, что восстановление слова X по Y практически невозможно: при достаточно большой длине слова X (например, в несколько сотен знаков) для этого может потребоваться астрономическое время. Такое число Y будем называть электронной (компьютерной) подписью владельца пароля X (а значит, и защищаемых прав доступа).
Другой способ защиты от взлома защиты связан с защитой сообщений, пересылаемых по компьютерным сетям. Такое сообщение может представлять команду на дистанционный доступ к ценной информации, и этот доступ отправитель сообщения хочет защитить от возможных искажений. Например, при осуществлении банковских операций с использованием компьютерной сети. Использование компьютерной подписи в такой ситуации недостаточно, так как защищаемое сообщение может быть перехвачено «взломщиком» (например, на «перевалочных» пунктах компьютерной сети) и подменено другим сообщением с сохранением компьютерной подписи (или пароля).
Защиту от такого взлома защиты можно осуществить следующим образом [11.4]. Наряду с функцией F, определяющей компьютерную подпись владельца пароля X, в ПС определены еще две функции: Stamp и Notary. При передаче сообщения отправитель, помимо компьютерной подписи Y=F(X), должен вычислить еще другое число S=Stamp(X,R), где X  пароль, а R  текст передаваемого сообщения. Здесь также предполагается, что функция Stamp хорошо известна всем пользователям ПС и обладает таким свойством, что по S практически невозможно ни восстановить число X, ни подобрать другой текст сообщения R с заданной компьютерной подписью Y. При этом передаваемое сообщение (вместе со своей защитой) должно иметь вид:
(R Y S),
причем Y (компьютерная подпись) позволяет получателю сообщения установить истинность клиента, а S как бы скрепляет защищаемый текст сообщения R с компьютерной подписью Y. В связи с этим будем называть число S электронной (компьютерной) печатью. Функция Notary(R,Y,S).проверяет истинность защищаемого сообщения:
(R,Y,S).
Эта позволяет получателю сообщения однозначно установить, что текст сообщения R принадлежит владельцу пароля X.
11.6.6. Защита от защиты. Защита от несанкционированного доступа может создать нежелательную ситуацию для самого владельца прав доступа к ресурсам ПС  он не сможет воспользоваться этими правами, если забудет (или потеряет) свой пароль («ключ»). Для защиты интересов пользователя в таких ситуациях и предназначена защита от защиты. Для обеспечения такой защиты ПС должно иметь привилегированного пользователя, называемого администратором ПС. Администратор ПС должен, в частности, отвечать за функционирование защиты ПС: именно он должен формировать контингент пользователей данного экземпляра ПС, предоставляя каждому из этих пользователей определенные права доступа к ресурсам ПС. В ПС должна быть привилегированная операция (для администратора), позволяющая временно снимать защиту от несанкционированного доступа для пользователя с целью фиксации требуемого пароля («замка»).

Упражнения к лекции 11.

11.1. Что такое защитное программирование?
11.2. Какие виды защиты программного средства от искажения информации Вы знаете?
11.3. Какие требования предъявляются к компьютеру, чтобы можно было обеспечить защиту программы от отказов другой программы в мультипрограммном режиме?
11.4. Что такое компьютерная подпись?
11.5. Что такое компьютерная печать?

Литература к лекции 11.

11.1. И.С. Березин, Н.П. Жидков. Методы вычислений, т.т. 1 и 2. - М.: Физматгиз, 1959.
11.2. Н.С. Бахвалов, Н.П. Жидков, Г.М.Кобельков. Численные ме-тоды. - М.: Наука, 1987.
11.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 141-146.
11.4. А.Н. Лебедев. Защита банковской информации и современная криптография // Вопросы защиты информации, 2(29), 1995.

[Tic-Sakyra]

К чему ищу так славу я?
Известно, в славе нет блаженства,
Но хочет все душа моя
Во всем дойти до совершенства.
М.Ю. Лермонтов

Лекция 12.
ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА

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

12.1. Общая характеристика процесса обеспечения качества программного средства.

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

12.2. Обеспечение легкости применения программного средства.

Легкость применения, в значительной степени, определяется составом и качеством пользовательской документации, а также не-которыми свойствами, реализуемыми программным путем.
С пользовательской документацией связаны такие примитивы качества ПС, как П-документированность и информативность. Обеспечением ее качества занимаются обычно технические писатели. Этот вопрос будет обсуждаться в следующей лекции. Здесь лишь следует заметить, что там речь будет идти об автономной по отношению к программам документации. В связи с этим следует обратить внимание на широко используемый в настоящее время подход информирования пользователя в интерактивном режиме (в процессе применения программ ПС). Такое информирование во многих случаях оказывается более удобным для пользователя, чем с помощью автономной документации, так как позволяет пользователю без какого-либо поиска вызывать необходимую информацию за счет использования контекста ее вызова. Такой подход к информированию пользователя является весьма перспективным.
Программным путем реализуются такие примитивы качества ПС как коммуникабельность, устойчивость и защищенность. Обеспечение устойчивости и защищенности уже было рассмотрено в предыдущей лекции. Коммуникабельность обеспечивается соответствующей реализацией обработки исключительных ситуаций и созданием подходящего пользовательского интерфейса.
Возбуждение исключительной ситуации во многих случаях означает, что возникла необходимость информировать пользователя о ходе выполнения программы. При этом выдаваемая пользователю информация должна быть простой для понимания (см. лекцию 4). Однако исключительные ситуации возникают обычно на достаточно низком уровне модульной структуры программы, а создать понятное для пользователя сообщение можно, как правило, на более высоких уровнях этой структуры, где известен контекст, в котором были активизированы действия, приведшие к возникновению исключительной ситуации. Обработку исключительных ситуаций внутри модуля мы уже обсуждали в лекции 8. Для обработки возникшей исключительной ситуации в другом модуле приходится принимать не простые решения. Применяемый часто способ пере-дачи информации о возникшей исключительной ситуации по цепочке обращений к программным модулям (в обратном направлении) является тяжеловесным: он требует дополнительных проверок после возврата из модуля и часто усложняет само обращение к этим модулям за счет задания дополнительных параметров. Приемлемым решением является включение в операционную среду выполнения программ (в исполнительную поддержку) возможностей прямой передачи этой информации обработчикам исключительных ситуаций по динамически формируемой очереди таких обработчиков.
Пользовательский интерфейс представляет средство взаимодействия пользователя с ПС. При разработке пользовательского интерфейса следует учитывать потребности, опыт и способности пользователя [12.1]. Поэтому потенциальные пользователи должны быть вовлечены в процесс разработки такого интерфейса. Большой эффект здесь дает его прототипирование. При этом пользователи должны получить доступ к прототипам пользовательского интерфейса, а их оценка различных возможностей используемого прототипа должна существенно учитываться при создании окончательного варианта пользовательского интерфейса.
В силу большого разнообразия пользователей и видов ПС существует множество различных стилей пользовательских интерфейсов, при разработке которых могут использоваться разные принципы и подходы. Однако следующие важнейшие принципы следует соблюдать всегда [12.1]:
• пользовательский интерфейс должен базироваться на терминах и понятиях, знакомых пользователю;
• пользовательский интерфейс должен быть единообразным;
• пользовательский интерфейс должен позволять пользователю исправлять собственные ошибки;
• пользовательский интерфейс должен позволять получение пользователем справочной информации: как по его запросу, так и генерируемой ПС.
В настоящее время широко распространены командные и графические пользовательские интерфейсы.
Командный пользовательский интерфейс предоставляет пользователю возможность обращаться к ПС с некоторым заданием (запросом), представляемым некоторым текстом (командой) на специальном командном языке (языке заданий). Достоинствами такого интерфейса является возможность его реализации на дешевых алфавитно-цифровых терминалах и возможность минимизации требуемого от пользователя ввода с клавиатуры. Недостатками такого интерфейса являются необходимость изучения командного языка и достаточно большая вероятность ошибки пользователя при задании команды. В связи с этим командный пользовательский интерфейс обычно выбирают только опытные пользователи. Такой интерфейс позволяет им осуществлять быстрое взаимодействие с компьютером и предоставляет возможность объединять команды в процедуры и программы (см. например, язык Shell операционной системы Unix [12.2]).
Графический пользовательский интерфейс предоставляет пользователю возможности:
• обращаться к ПС путем выбора на экране подходящего графического или текстового объекта,
• получать от ПС информацию на экране в виде графических и текстовых объектов,
• осуществлять прямые манипуляции с графическими и текстовыми объектами, представленными на экране.
Графический пользовательский интерфейс позволяет
• размещать на экране множество различных окон, в которые можно выводить информацию независимо;
• использовать графические объекты, называемые пиктограммами (или иконами), для обозначения различных информационных объектов или процессов;
• использовать экранный указатель для выбора объектов (или их элементов), размещенных на экране; экранный указатель управляется (перемещается) с помощью клавиатуры или мыши.
Достоинством графического пользовательского интерфейса является возможность создания удобной и понятной пользователю модели взаимодействия с ПС (панель управления, рабочий стол и т.п.) без необходимости изучения какого-либо специального языка. Однако его разработка требует больших трудозатрат, сравнимых с трудозатратами по создания самого ПС. Кроме того, возникает серьезная проблема по переносимости ПС на другие операционные системы, так как графический интерфейс существенно зависит от возможностей (графической пользовательской платформы), предоставляемых операционной системой для его создания.
Графический пользовательский интерфейс обобщает такие виды пользовательского интерфейса, как интерфейс типа меню и интерфейс прямого манипулирования.

12.3. Обеспечение эффективности программного средства.

Эффективность ПС обеспечивается принятием подходящих решений на разных этапах его разработки, начиная с разработки его архитектуры. Особенно сильно на эффективность ПС (особенно по памяти) влияет выбор структуры и представления данных. Но и выбор алгоритмов, используемых в тех или иных программных модулях, а также особенности их реализации (включая выбор языка программирования) может существенно повлиять на эффективность ПС. При этом постоянно приходится разрешать противоречие между временнόй эффективностью и эффективностью по памяти (ресурсам). Поэтому весьма важно, чтобы в спецификации качества были явно указаны приоритеты или количественное соотношение между показателями этих примитивов качества. Следует также иметь в виду, что разные программные модули по-разному влияют на эффективность ПС в целом: одни модули могут сильно влиять на временнýю эффективность и практически не влиять на эффективность по памяти, а другие могут существенно влиять на общий расход памяти, не оказывая заметного влияния на время работы ПС. Более того, это влияние (прежде всего, в отношении временнóй эффективности) заранее (до окончания реализации ПС) далеко не всегда можно правильно оценить.
С учетом сказанного, рекомендуется придерживаться следующих принципов для обеспечения эффективности ПС [12.3, 12.4]:
• сначала нужно разработать надежное ПС, а потом уж заниматься доведением его эффективности до требуемого уровня в соответствии с его спецификацией качества;
• для повышения эффективности ПС, прежде всего, нужно ис-пользовать оптимизирующий компилятор - это может обеспе-чить требуемую эффективность;
• если эффективность ПС не удовлетворяет спецификации его качества, то найдите самые критические модули с точки зрения требуемой эффективности ПС; эти модули и попытайтесь оптимизировать в первую очередь путем их ручной переделки;
• не следует заниматься оптимизацией модуля, если этого не требуется для достижения требуемой эффективности ПС.
Для отыскания критических модулей с точки зрениявременнóй эффективности ПС потребуется получить распределение по модулям времени работы ПС путем соответствующих измерений во время выполнения ПС. Это может быть сделано с помощью динамического анализатора (специального программного инструмента), который может определить частоту обращения к каждому модулю в процессе применения ПС.

12.4. Обеспечение сопровождаемости программного средства.

Обеспечение сопровождаемости ПС сводится к обеспечению изучаемости ПС и к обеспечению его модифицируемости.
Изучаемость (подкритерий качества) ПС определяется составом и качеством документации по сопровождению ПС и выражается через такие примитивы качества ПС как С-документированность, информативность, понятность, структурированность и удобочитаемость. Последние два примитива качества и, в значительной степени, понятность связаны с текстами программных модулей. Вопрос о документации по сопровождению будет обсуждаться в следующей лекции. Здесь мы лишь сделаем некоторые общие рекомендации относительно текстов программ (модулей).
При окончательном оформлении текста программного модуля целесообразно придерживаться следующих рекомендаций, определяющих практически оправданный стиль программирования [12.3, 12.4]:
• используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля;
• используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени  4-12 литер, цифры  в конце), не используйте сходные имена и ключевые слова;
• соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы);
• не бойтесь использовать необязательные скобки  они обходятся дешевле, чем ошибки;
• размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки; этим обеспечивается удобочитаемость текста модуля;
• избегайте трюков, т.е. таких приемов программирования, когда создаются фрагменты модуля, основной эффект которых не очевиден или скрыт (завуалирован), например, побочные эффекты функций.
Структурированность текста модуля существенно упрощает его понимание. Обеспечение этого примитива качества подробно обсуждалось в лекции 8. Удобочитаемость текста модуля может быть обеспечена автоматически путем применения специального программного инструмента  форматера.
Модифицируемость (подкритерий качества) ПС определяется, частично, некоторыми свойствами документации, и свойствами, реализуемые программным путем, и выражается через такие примитивы качества ПС как расширяемость, модифицируемость, структурированность и модульность.
Расширяемость обеспечивается возможностями автоматически настраиваться на условия применения ПС по информации, задаваемой пользователем. К таким условиям относятся, прежде всего, конфигурация компьютера, на котором будет применяться ПС (в частности, объем и структура его памяти), а также требования конкретного пользователя к функциональным возможностям ПС (например, требования, которые определяют режим применения ПС или конкретизируют структуру информационной среды). К этим возможностям можно отнести и возможность добавления к ПС определенных компонент. Для реализации таких возможностей в ПС часто включается дополнительная компонента (подсистема), называемая инсталятором. Инсталятор осуществляет прием от пользователя необходимой информации и настройку ПС по этой информации. Обычно решение о включении в ПС такой компоненты принимается в процессе разработки архитектуры ПС.
Модифицируемость (примитив качества) обеспечивается такими свойствами документации и свойствами, реализуемые про-граммным путем, которые облегчают внесение изменений и доработок в документацию и программы ПС ручным путем (возможно, с определенной компьютерной поддержкой). В спецификации качества могут быть указаны некоторые приоритетные направления и особенности развития ПС. Эти указания должны быть учтены при разработке архитектуры ПС и модульной структуры его программ. Общая проблема сопровождения ПС  обеспечить, чтобы все его компоненты (на всех уровнях представления) оставались согласованными в каждой новой версии ПС. Этот процесс обычно называют управлением конфигурацией (configuration management).Чтобы помочь управлению конфигурацией, необходимо, чтобы связи и зависимости между документами и их частями фиксировать в специальной документации по сопровождению [12.5]. Эта проблема усложняется, если в процессе доработки может находиться сразу несколько версий ПС (в разной степени завершенности). Тогда без компьютерной поддержки довольно трудно обеспечить согласованность документов в разных конфигурациях. Поэтому в таких случаях в ПС включается дополнительная компонента (подсистема), называемая конфигуратором. С такой компонентой связывают специальную базу данных (или специальный раздел в базе данных), в которой фиксируются связи и зависимости между документами и их частями для всех версий ПС. Обычно решение о включении в ПС такой компоненты принимается в процессе разработки архитектуры ПС. Для обеспечения этого примитива качества в документацию по сопровождению включают специальное руководство, которое описывает, какие части ПС являются аппаратно- и программно-зависимыми, и как возможное развитие ПС учтено в его строении (конструкции).
Структурированность и модульность упрощают ручную модификацию программ ПС.

12.5. Обеспечение мобильности.

Проблема мобильности возникает из-за того, что быстрое развитие компьютерной техники и аппаратных средств делает жизненный цикл многих больших программных средств (программных систем) намного продолжительнее периода «морально» оправданного существования компьютеров и аппаратуры, для которых первоначально создавались эти программные средства. Поэтому обеспечение критерия мобильности для таких ПС является весьма важной задачей.
Мобильность ПС определяется такими примитивами качества ПС как независимость от устройств, автономность, структури-рованность и модульность.
Если бы ПС обладало таками примитивами качества, как независимость от устройств и автономность, и его программы были бы представлены на машинно-независимом языке программирования, то перенос ПС в другую среду обеспечивался бы перетрансляцией (перекомпиляцией) его программ в этой среде. Однако трудно представить реальное ПС, обладающее таким качеством. Тем не менее, таким качеством могут обладать отдельные части программ ПС и даже весьма значительные. А это уже явный намек на то, каким путем следует добиваться мобильности ПС.
Если ПС зависит от устройств (аппаратуры), то в спецификации качества должна быть описана эта компьютерно-аппаратная среда (будем ее называть аппаратной платформой [12.6]). Избавится от этой зависимости можно за счет такого примитива качества ПС как автономность. Как правило, ПС строится в рамках некоторой операционной системы (ОС), которая может спрятать специфику аппаратной платформы и, тем самым, сделать ПС независимым от устройств. Но тогда ПС не будет обладать свойством автономности. В этом случае в спецификации качества должна быть описана эта программная среда, над которой строится ПС (будем эту среду называть операционной платформой [12.6]). Таким образом, мобильность ПС будет непосредственно связано с мобильностью используемой ОС: перенос ПС на другую аппаратную платформу осуществляется автоматически, если будет осуществлен перенос на эту платформу используемой ОС. Но обеспечение мобильности ОС является самостоятельной и довольно трудной задачей.
Таким образом, для обеспечения мобильности ПС нужно ре-шить две задачи:
• выделение по возможности наибольшей части программ ПС, обладающей свойствами независимости от устройств и авто-номности (другими словами, независимой от аппаратно-операционной платформы);
• обеспечение сопровождаемости для остальных частей про-грамм ПС.
Для решения этих задач целесообразно выбрать в качестве архитектуры ПС слоистую систему (см. рис. 12.1). Основной слой, реализующий основные функции ПС, должен быть независимым от аппаратно-операционной платформы. Выделяется также слой (часто называемый ядром ПС), который включает программные модули, зависящие от аппаратно-операционной платформы. Этот слой должен обеспечивать, в частности, доступ к внешней информационной среде ПС. Между этими слоями должен быть определен интерфейс, независимый от аппаратно-операционной платформы и обеспечивающий правила обращения из основного слоя к модулям ядра. Будем называть этот интерфейс системным. Использование графических пользовательских интерфейсов требует выделение еще одного программного слоя, зависящего от той части аппаратно-операционной платформы (графической пользовательской платформы), на которой строятся пользовательские интерфейсы. Будем называть этот слой оболочкой ПС. Между оболочкой и основным слоем также должен быть определен интерфейс, независимый от графической пользовательской платформы и обеспечивающий правила обращения из оболочки к модулям основного слоя.

Рис. 12.1. Рекомендуемая архитектура мобильного ПС.
Модульность ПС позволяет сформировать указанные слои, выделяя программные модули с требуемыми свойствами и распределяя их между указанными слоями. Модульность и структурированность оболочки и ядра позволяют обеспечить эти слои свойством модифицируемости. При этом желательно, чтобы каждый модуль этих слоев был ориентирован на реализацию каких-либо функций управления четко выделенной компоненты аппаратно-операционной среды. Для этого используются такие методы как унификация интерфейсов, стандартизация протоколов и т.п. [12.6].

Упражнения к лекции 12.

12.1. Какие задачи приходиться решать при обеспечении коммуникабельности ПС?
12.2. Какие возможности предоставляет пользователю графиче-ский пользовательский интерфейс?
12.3. Как нужно действовать для обеспечения эффективности ПС?
12.4. Что такое инсталятор программного средства (ПС)?
12.5. Что такое управление конфигурацией ПС?
12.6. Что такое ядро ПС?
12.7. Что такое оболочка ПС?

Литература к лекции 12.

12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P. 261-286.
12.2. М. Кристиан. Введение в операционную систему UNIX. - М.: Финансы и статистика, 1985. - С. 156-178.
12.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154, 160-164.
12.4. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. С. 8-44, 117-178.
12.5. М.М. Горбунов-Посадов. Конфигурации программ. Рецепты безболезненных изменений. – М.: «Малип», 1994.
12.6. В.В. Липаев, Е.Н Филиппов. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, 1997.

[Tic-Sakyra]

В начале было Слово…
Библия, Новый завет,
От Иоанна святое благовествование

Лекция 13
ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

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

При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы [13.1]:
• Документы управления разработкой ПС.
• Документы, входящие в состав ПС.
Документы управления разработкой ПС (software process do-cumentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers)  лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов [13.1]:
• Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.
• Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
• Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.
• Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.
• Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами)  во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти доку-менты образуют два комплекта с разным назначением:
• Пользовательская документация ПС (П-документация).
• Документация по сопровождению ПС (С-документация).

13.2. Пользовательская документация программных средств.

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС [13.1, 13.2.]. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.
В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или вы-полнять определенные действия, чтобы поддерживать ПС в рабо-чем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС [13.2]. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
В соответствии с работами [13.1, 13.2] можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:
• Общее функциональное описание ПС. Дает краткую характеристику функциональных возможностей ПС. Предназначено для пользователей, которые должны решить, насколько необходимо им данное ПС.
• Руководство по инсталяции ПС. Предназначено для администраторов ПС. Оно должно детально предписывать, как устанавливать системы в конкретной среде, в частности, должно содержать описание компьютерно-считываемого носителя, на котором поставляется ПС, файлы, представляющие ПС, и требования к минимальной конфигурации аппаратуры.
• Инструкция по применению ПС. Предназначена для ординар-ных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для ее изучения.
• Справочник по применению ПС. Предназначен для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска отдельных деталей.
• Руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.
Как уже говорилось ранее (см. лекцию 4), разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя (в противном случае это ПС, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками ПС, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользовательской документации разработан ряд стандартов (см. например, [13.2]), в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание.

13.3. Документация по сопровождению программных средств.

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение  это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС,  с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;
(2) документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
• Внешнее описание ПС (Requirements document).
• Описание архитектуры ПС (description of the system architec-ture), включая внешнюю спецификацию каждой ее программы (подсистемы).
• Для каждой программы ПС  описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
• Для каждого модуля  его спецификация и описание его строения (design description).
• Тексты модулей на выбранном языке программирования (program source code listings).
• Документы установления достоверности ПС (validation docu-ments), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым рекомендациям и стандартам [13.3 - 13.8].
Документация второй группы содержит
• Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.
Общая проблема сопровождения ПС  обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда ПС изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть отражены в руководстве по сопровождению, и зафиксированы в базе данных управления конфигурацией.

Упражнения к лекции 13.

13.1. Что такое менеджер программного средства?
13.2. Что такое ординарный пользователь программного средства?
13.3. Что такое администратор программного средства?
13.4. Что такое руководство по инсталляции программного сред-ства?
13.5. Что такое руководство по управлению программным средством?
13.6. Что такое руководство по сопровождению программного средства?

Литература к лекции 13.

13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Pub-lishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
13.5. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.
13.6. ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.

[Tic-Sakyra]

Губа не дура, язык не лопата.
Народная поговорка

Лекция 14.
УПРАВЛЕНИЕ РАЗРАБОТКОЙ И АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА.

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

14.1. Назначение и процессы управления разработкой программного средства.

Управление разработкой ПС (software management) – это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков ПС, на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПС, выполнения сроков и бюджета разработки ПС [14.1, 14.2]. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПС, а ход выполнения этих работ называют развитием программного проекта (software project progress). К необходимым условиям работы коллектива относятся помещения, аппаратно-программные средства разработки, документация и материально-финансовое обеспечение. Планирование и контроль предполагает разбиение всего процесса разработки ПС на отдельные конкретные работы (задания), подбор и расстановка исполнителей, установление сроков и порядка выполнения этих работ, оценка качества выполнения каждой работы. Финальной частью этой деятельности является организация и проведения аттестации (сертификации) ПС, которой завершается стадия разработки ПС. Влияние правильной расстановки исполнителей на обеспечение надежности ПС уже обсуждалось в лекции 2. Вопросы документации обсуждались в предыдущей лекции. Другие вопросы управления разработки ПС кратко обсудим в настоящей лекции.
Хотя виды деятельности по управлению разработкой ПС могут быть весьма разнообразными в зависимости от специфики разрабатываемого ПС и организации работ по его созданию, можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПС:
• составление плана-проспекта по разработке ПС;
• планирование и составление расписаний по разработке ПС;
• управление издержками по разработке ПС;
• текущий контроль и документирование деятельности кол-лектива по разработке ПС.
• подбор и оценка персонала коллектива разработчиков ПС.
Составление плана-проспекта по разработке ПС включает формулирование предложений о том, как выполнять разработку ПС. Прежде всего, должно быть зафиксировано, для кого разрабатывается ПС:
• для внешнего заказчика,
• для других подразделений той же организации,
• или является инициативной внутренней разработкой.
В плане-проспекте должны быть установлены общие очертания работ по создания ПС и оценена стоимость разработки, а также предоставляемые для разработки ПС материально-финансовые ресурсы и временные ограничения. Кроме того, он должен включать обоснование, какого рода коллективом должно разрабатываться ПС (специальной организацией, отдельной бригадой и т.п.). И, наконец, должны быть сформулированы необходимые технологические требования (включая, возможно, и выбор подходящей технологии программирования).
Планирование и составление расписаний по разработке ПС – это деятельность, связанная с распределением работ между исполнителями и по времени их выполнения в рамках намеченных сроков и имеющихся ресурсов. Более подробно этот процесс будет рассмотрен в п. 14.3.
Управление издержками по разработке ПС – это деятельность, направленная на обеспечение подходящей стоимости разработки в рамках выделенного бюджета. Она включает оценивание стоимости разработки проекта в целом или отдельных его частей, контроль выполнения бюджета, выбор подходящих вариантов расходования бюджета. Эта деятельность тесно связана с планированием и составлением расписаний в течение всего периода выполнения проекта. Основными источниками издержек являются
• затраты на аппаратное оборудование (hardware);
• затраты на вербовку и обучение персонала;
• затраты на оплату труда разработчиков.
Текущий контроль и документирование деятельности коллектива по разработке ПС – это непрерывный процесс слежения за ходом развития проекта, сравнения действительных состояния и издержек с запланированными, а также документирования различных аспектов развития проекта (см. лекцию 13). Этот процесс помогает вовремя обнаружить затруднения и предсказать возможные проблемы в развитии проекта.
Подбор и оценка персонала коллектива разработчиков ПС – это деятельность, связанная с формированием коллектива разработчиков ПС. Имеющийся в распоряжении штат разработчиков далеко не всегда будет подходящим по квалификации и опыту работы для данного проекта. Поэтому приходится, частично, вербовать подходящий персонал, а, частично, организовывать дополнительное обучение имеющихся разработчиков. В любом случае в формируемом коллективе хотя бы один его член должен иметь опыт разработки программных средств (систем), сопоставимых с ПС, который требуется разработать. Это поможет избежать многих простых ошибок в развитии проекта.

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

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

Рис. 14.1. Структура управления разработкой программных средств.
По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему непосредственно подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет планирование и составление расписаний работы этих бригад по разработке соответствующего ПС (см. следующий раздел).
Считается крайне нецелесообразным разработка большого ПС (программной системы) одной большой единой бригадой разработчиков. Для этого имеется ряд серьезных причин. В частности, в большой бригаде время, затрачиваемое на общение между ее членами, может быть больше времени, затрачиваемого на собственно разработку. Отрицательное влияние оказывает большая бригада на строение ПС и на интерфейс между отдельными его частями. Все это приводит к снижению надежности ПС. Поэтому обычно большой проект разбивается на несколько относительно независимых подпроектов таким образом, чтобы каждый подпроект мог быть выполнен отдельной небольшой бригадой разработчиков (обычно считается, что в бригаде не должно быть больше 8-10 членов). При этом архитектура ПС должна быть такой, чтобы между программными подсистемами, разрабатываемыми независимыми бригадами, был достаточно простой и хорошо определенный системный интерфейс.
Наиболее употребительны три подхода к организации бригад разработчиков [14.1, 14.3, 14.4]:
• обычные бригады,
• неформальные демократические бригады,
• бригады ведущего программиста.
В обычной бригаде старший программист (лидер бригады) непосредственно руководит работой младших программистов. Недостатки такой организации непосредственно связаны со спецификой разработки ПС: программисты разрабатывают сильно связанные части программной подсистемы, сам процесс разработки состоит из многих этапов, каждый из которых требует особенных способностей от программиста, ошибки отдельного программиста могут препятствовать работе других программистов. Успех работы такой бригады достигается в том случае, когда ее руководитель является компетентным программистом, способным предъявлять к членам бригады разумные требования и умеющим поощрять хорошую работу.
В неформальной демократической бригаде поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно в зависимости от способностей и опыта этих членов. Один из членов этой бригады является лидером (руководителем) бригады, но он также выполняет и некоторые задания, распределяемые между членами бригады. Неформальные демократические бригады могут весьма успешно справляться с порученной им работой, если большинство членов бригады являются опытными и компетентными специалистами. Если же неформальная демократическая бригада состоит, в основном, из неопытных и некомпетентных членов, в деятельности бригады могут возникать большие трудности. Без наличия в бригаде хотя бы одного квалифицированного и авторитетного члена, способного координировать и направлять работу членов бригады, эти трудности могут привести к неудаче проекта.
В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады: он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой [14.1, 14.4]. Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки. Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность – быть в курсе всего, что делает ведущий про-граммист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист. Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки (см. лекцию 16). В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены, такие как
• распорядитель бригады, выполняющий административные функции;
• технический редактор, осуществляющий доработку и техническое редактирование документов, написанных ведущим программистом;
• инструментальщик, отвечающий за подбор и функционирование программных средств, поддерживающих разработку программной подсистемы;
• тестовик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;
• один или несколько младших программистов, осуществляющих кодирование отдельных программных компонент по спецификациям, разработанным ведущим программистом.
Кроме того, к работе бригады может привлекаться для консультации эксперт по языку программированию.
Важное место в управлении разработкой ПС отводится управление обеспечением качества. Для руководства этой деятельностью назначается специальный менеджер, подчиненный непосредственно директору, – менеджер по качеству. Ему непосредственно подчинены формируемые бригады по контролю качества. Эти бригады работают с отдельными проектами, но непосредственно соответствующим менеджерам проектов не подчинены, сохраняя тем самым свою независимость от них.
Управление обеспечением качества означает контроль качества каждой работы, выполняемой разработчиками в рамках программного проекта, контроль каждого документа, включаемого в ПС. Качество ПС не может быть добавлено к ПС после того, как оно будет уже создано. Качество ПС формируется постепенно в процессе всей разработки ПС, в каждой отдельной работе, выполняемой по программному проекту. Поэтому для каждой такой работы, прежде чем она получит одобрение и будет считаться завершенной, организуется смотр (review) соответствующей бригадой по контролю качества. Этот смотр существенно отличается от контроля, осуществляемого разработчиками в конце каждого этапа разработки, так как последний является техническим процессом, связанным с обнаружением ошибок, тогда как смотр по контролю качества является функцией управления разработкой и связан с оценкой того, насколько результаты этой работы согласуются с декларированными требованиями относительно качества ПС.
Существенную роль в управлении качеством ПС играют программные (софтверные) стандарты [14.1, 14.2]. Они фиксируют удачный опыт высоко квалифицированных специалистов по разработке ПС для различных их классов и для разных моделей их качества. Следование подходящим стандартам может существенно облегчить достижение поставленных целей относительно качества ПС, а также упростить смотр по контролю качества. Кроме того, стандарты способствуют формированию взаимопонимания внутри коллектива разработчиков и упрощают процесс обучения новых членов этого коллектива.
Различают два вида таких стандартов:
• стандарты ПС (программного продукта),
• стандарты процесса создания и использования ПС.
Стандарты ПС определяют некоторые свойства, которыми должны обладать программы или документы ПС, т.е. определяют в какой-то степени качество ПС. При спецификации качества (см. лекцию 4) для конкретизации какого-либо примитива качества иногда достаточно указать, какому стандарту он должен соответствовать, в других случаях привязка примитива качества к стандарту может потребовать лишь незначительной дополнительной конкретизации этого примитива. Привязка примитивов качества к тем или иным стандартам сильно упрощает контроль и оценку качества ПС. К стандартам ПС относятся, прежде всего, стандарты на языки программирования, на состав документации, на структуру различных документов, на различные форматы и другие.
Стандарты процесса создания и использования ПС определяют, как должен проводится этот процесс, т.е. подход к разработке ПС, структуру жизненного цикла ПС и его технологические процессы. Хотя эти стандарты непосредственно не определяют качества ПС, однако считается, что качество ПС существенно зависит от качества процесса его разработки. Эти стандарты проще контролировать, поэтому повсеместно используются для управления качеством ПС.
В лекции 13 уже отмечалось, что эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС. Разработка последних стандартов является одной из функций управления обеспечением качества ПС.
Бригада по контролю качества состоит из ассистентов (рецензентов) по качеству ПС. Она проводит смотры тех или иных частей ПС или всего ПС в целом с целью поиска возникающих проблем в процессе его разработки. Смотру подлежат все программные компоненты и документы, включаемые в ПС, а также процессы их разработки. В процессе смотра учитываются требования, сформулированные в спецификации качества ПС, в частности, проверяется соответствие исследуемого документа или технологического процесса стандартам, указанным в этой спецификации. В результате смотра формулируются замечания, которые могут фиксироваться письменно или просто передаваться разработчикам устно.
Для смотра каждой конкретной программной компоненты или документа ПС создается комиссия (группа) во главе с председателем (chairman), который отвечает за организацию смотра. Он должен иметь достаточный опыт конструирования ПС, чтобы быть готовым принять ответственность за важные технические решения. В эту комиссию включаются два или три ассистента по качеству ПС, один из которых должен быть ответственным за запись решений, сделанных в течение смотра. К смотру обычно привлекаются разработчик исследуемой компоненты или исследуемого документа ПС, а также новые члены коллектива разработчиков в целях их обучения.

14.3. Планирование и составление расписаний по разработке ПС.

Общее представление об этой деятельности можно составить по ее описанию на псевдокоде (см. лекцию 8), приведенном на рис. 14.2 (см. также [14.1]). Это описание показывает, что планирование и составление расписаний по разработке ПС представляет собой итеративный процесс, который заканчивается только после прекращения работ по самому программному проекту.

Рис. 14.2. Описание на псевдокоде процесса планирования и составления расписаний по разработке ПС.
В начале этого описания оцениваются общий срок разработки ПС, используемые штаты исполнителей, предельный бюджет и другие ограничения (условия) разработки. С учетом этого фиксируются начальные параметры проекта (его структура и распределение функций). Должны быть также определены «вехи развития проекта» и их сроки. Веха развития проекта (project progress milestone) – это конечная точка некоторого этапа или процесса, с которой связывается выдача некоторого промежуточного продукта, представляющего собой некоторый четко определенный документ. Вехи развития проекта обеспечивают возможность контроля развития проекта и возможность модификации расписаний проекта.
Далее начинается итерационный процесс, основу которого составляет повторяющиеся составления расписаний. Составление расписания заключается
• в разделении всей работы, необходимой для выполнения проекта, на отдельные самостоятельно выполняемые задания;
• в составлении сетевого графика выполнения заданий;
• в составлении гистограммы выполнения заданий;
• в расстановке исполнителей заданий.
При выделении самостоятельных заданий для каждого из них оценивается время его выполнения и его зависимость от других заданий с точки зрения порядка выполнения. Сетевой график представляет собой схему (сеть) путей выполнения заданий с указанием времени выполнения каждого задания и с расстановкой вех развития проекта. В сетевом графике должен быть определен критический путь, представляющий собой такой путь заданий, суммарное время выполнения которых является наибольшим. Гистограмма выполнения заданий (activity bar chart) содержит для каждого задания свою временнýю полосу от момента, когда выполнение этого задания может быть начато, и до момента, когда выполнение этого задания должно быть закончено. В такой полосе фиксируется как продолжительность выполнения самого задания, так и возможный запас времени для завершения его выполнения. Это дает возможность модифицировать план развития проекта в определенных рамках без изменения общих сроков выполнения проекта. При расстановке исполнителей оценивается для каждого исполнителя соответствие его квалификации и опыта характеру предлагаемой работы. Особое внимание уделяется расстановке исполнителей заданий, находящихся на критическом пути.
Спустя некоторое время (обычно 2-3 недели) после активизации процессов, указанных в расписании, производится обозрение (просмотр) хода развития проекта и отмечаются возникшие противоречия. С учетом этого производится пересмотр (уточнение) параметров проекта и оценивается влияние измененных параметров на расписание проекта. Если окажется, что эти изменения увеличивают время разработки ПС, необходимо обсудить с заказчиком возможность изменения ограничений проекта и срока его завершения. В том случае, когда заказчик не может пойти на подходящие изменения, производится технический пересмотр проекта с целью поиска альтернативных подходов к разработке ПС.

14.4 Аттестации программного средства.

Завершающим этапом разработки ПС является аттестация ПС, подводящая итог всей разработке. Аттестация (certification) ПС  это авторитетное подтверждение качества ПС [14.5, 14.6]. Обычно для аттестации ПС создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит приемосдаточные испытания ПС с целью получения необходимой информации для оценки его качества. Под испытанием ПС здесь понимают [14.6, 14.7] процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. В этом процессе проверяется полнота и исследуется качество представленной программной документации, производится необходимое тестирование программ, входящих в состав ПС, а также исследуются и другие свойства ПС, декларированные в его спецификации качества. На основе полученной информации комиссия должна установить, в какой степени ПС выполняет декларированные функции и в какой степени ПС обладает декларированными примитивами и критериями качества. Решение аттестационной комиссии о произведенной оценке качества ПС фиксируется в соответствующем документе (сертификате), который подписывается членами комиссии.
Таким образом, оценка качества ПС является основным содержанием процесса аттестации. Прежде всего, следует отметить, что оценка качества ПС производится по предъявленной спецификации его качества, т.е. оценивается только декларированное разработчиками качество ПС. При этом оценка качества ПС по каждому из критериев сводится к оценке каждого из примитивов качества, связанному с этим критерием качества ПС, в соответствии с их конкретизацией в спецификации качества этого ПС (см. лекцию 4). Различают следующие группы методов оценки примитивов качества ПС:
• непосредственное измерение показателей примитива качества;
• тестирование программ ПС;
• экспертная оценка на основании изучения программ и документации ПС.
Непосредственное измерение показателей примитива качества производится путем проверки соответствия предъявленной доку-ментации (включая тексты программ на языке программирования) стандартам или явным требованиям, указанным в спецификации качества ПС, а также путем измерения времени работы различных устройств и используемых ресурсов при выполнении контрольных (тестовых) задач. Например, некоторым показателем эффективности по памяти может быть число строк программы на языке программирования, а некоторым показателем временнóй эффективности может быть время ответа на запрос пользователя.
Для оценки некоторых примитивов качества ПС используется тестирование [14.5-14.8]. К таким примитивам относятся, прежде всего, завершенность ПС, а также его точность, устойчивость, защищенность и другие примитивы качества. Этот вопрос уже обсуждался в лекции 10. Однако, во время приемосдаточных испытаний нет необходимости проведения тестирование ПС в полном объеме (это может слишком дорого стоить). Аттестационная комиссия должна, прежде всего, изучить предъявленную документацию по проведенному разработчиками тестированию ПС и лишь выборочно пропустить предъявленные тесты. Дополнительные тесты составляются, если у комиссии возникают определенные сомнения в полноте тестирования, проведенного разработчиками. Кроме того, обычно работоспособность и некоторые показатели качества ПС демонстрируются на решении контрольных задач, предъявляемых заказчиком.
В некоторых случаях для оценки качества ПС проводятся дополнительные полевые или промышленные испытания [14.8, 14.9]. Полевые испытания ПС – это демонстрация ПС вместе с технической системой, которой управляет эта ПС, с обеспечением тщательного наблюдения за поведением ПС. Заказчикам должна быть предоставлена возможность задания собственных контрольных примеров, в частности, с выходом в критические режимы работы технической системы, а также с вызовом в ней аварийных ситуаций. Промышленные испытания ПС – это процесс передачи ПС в постоянную эксплуатацию пользователям, представляющий собой опытную эксплуатацию ПС (см. лекцию 10) пользователями со сбором информации об особенностях поведения ПС и ее эксплуатационных характеристиках.
Многие примитивы качества ПС трудно уловимы с точки зрения их (объективной) оценки. В этих случаях иногда применяют метод экспертных оценок. Этот метод заключается в следующем. Назначается группа экспертов и каждый из этих экспертов в результате изучения представленной документации составляет свое мнение об обладании ПС требуемым примитивом качества. Затем голосованием членов этой группы устанавливается оценка требуемого примитива качества ПС, т.е. получаемая оценка является некоторым усреднением совокупности субъективных оценок. Эта оценка может производиться как по двухбалльной системе ("обладает"  "не обладает"), так и учитывать степень обладания ПС этим примитивом качества (например, производиться по пятибальной системе) в соответствии с требованиями относительно этого примитива, сформулированными в спецификации качества аттестуемого ПС.
Аттестация ПС похожа на смотр различных компонент ПС в процессе управления качеством ПС, однако, имеются и существенные различия [14.1]. Во-первых, смотр проводится менее представительной группой специалистов. Во-вторых, в процессе смотра не производится полной оценки качества ПС, а выявляются лишь отдельные просчеты и нарушения требований относительно качества ПС, связанные с обозреваемой компонентой (документом), при этом не требуется немедленного устранения выявленных недостатков, если они не мешают проведения последующих работ. Целью же аттестации является проверка и фиксация реальных показателей качества предъявленного ПС [14.7]. Если аттестационная комиссия подтверждает, что предъявленное ПС соответствует всем требованиям относительно его качества, сформулированным во внешнем описании этого ПС, то считается, что его разработка завершена успешно и заказчик обязан принять это ПС. Если же будут обнаружены отступления от этих требований, то должны приниматься определенные решения о продолжении или прекращении разработки предъявленного ПС, но это уже вопрос взаимоотношений между заказчиком и разработчиками. Таким образом, аттестационная комиссия, подписывая документ о произведенной оценке качества ПС, принимает на себя определенную ответственность за гарантию качества этого ПС. Но здесь имеются определенные правовые проблемы, обсуждение которых выходит за рамки темы этой лекции.

Упражнения к лекции 14.

14.1. Что такое управление разработкой ПС?
14.2. Что такое менеджер программного проекта?
14.3. Что такое неформальная демократическая бригада разра-ботчиков ПС?
14.4. Что такое бригада ведущего программиста?
14.5. Что такое смотр программной компоненты (программного документа)?
14.6. Что такое аттестация ПС?

Литература к лекции 14.

14.1. Ian Sommerville. Software Engineering. – Addison-Wesley Pub-lishing Company, 1992. – P. 479-493.
14.2. В.В. Липаев. Управление разработкой программных средств. Методы, стандарты, технология. – М.: Финансы и статистика, 1993.
14.3. Б. Шнейдерман. Психология программирования. – М.: Радио и связь, 1984. – С. 128-146.
14.4. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы. – М.: Наука, 1979.
14.5. Г. Майерс. Надежность программного обеспечения. – М.: Мир,1980. - С. 174-175.
14.6. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). – М.: "ДИАЛОГ-МГУ", 1994.
14.7. В.В. Липаев, Е.Н. Филинов. Мобильность программ и данных в открытых информационных системах. – М.: Научная книга, 1997. – С. 252-268.
14.8. В.В. Липаев. Тестирование программ. – М.: Радио и связь, 1986. – С. 231-245.
14.9. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и
испытание программ. – М.: Мир, 1985. – С. 281-283.

[Tic-Sakyra]

Не умножай число имеющихся сущностей.
Вильям Оккам

Лекция 15.
ОЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ
ПРОГРАММНЫХ СРЕДСТВ

15.1. Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.

Окружающий нас мир состоит из объектов и отношений между ними [15.1]. Согласно В. Далю [15.2] объект (предмет)  это все, что представляется чувствам (объект вещественный) или уму (объект умственный). Таким образом, объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с первым в каких-либо отношениях. Он может иметь внутреннюю структуру: состоять из других объектов, также находящихся между собой в некоторых отношениях. Исходя из этого, можно построить иерархическое строение мира из объектов. Однако, при каждом конкретном рассмотрении окружающего нас мира некоторые объекты считаются неделимыми, причем в зависимости от целей рассмотрения такими (неделимыми) могут приниматься объекты разного уровня иерархии. Отношение связывает некоторые объекты: можно считать, что объединение этих объектов обладает некоторым свойством. Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным). На каждом месте объединения объектов, которые могут быть связаны каким-либо конкретным отношением, могут находиться разные объекты, но вполне определенные (в этом случае говорят: объекты определенного класса). Одноместное отношение называется простым свойством объекта (соответствующего класса). Многоместное отношение объектов будем называть ассоциативным свойством объекта, если этот объект участвует в этом отношении. Состояние объекта может быть изучено по значению простых или ассоциативных свойств этого объекта. Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов.
В процессе познания или изменения окружающего нас мира мы всегда принимаем в рассмотрение ту или иную упрощенную модель мира (модельный мир), в которую включаем объекты и отношения некоторых интересующих нас классов из окружающего нас мира. Каждый объект, имеющий внутреннюю структуру, может представлять свой модельный мир, включающий объекты этой структуры и отношения, которые их связывают. Таким образом, окружающий нас мир, можно рассматривать (в некотором приближении) как иерархическую структуру модельных миров.
В настоящее время в процессе познания или изменения окружающего нас мира широко используется компьютерная техника для обработки различного рода информации. В связи с этим применяется компьютерное (информационное) представление объектов и отношений. Каждый объект информационно может быть представлен некоторой структурой данных, отображающей его состояние. Простые свойства этого объекта могут задаваться непосредственно в виде отдельных компонент этой структуры, либо специальными функциями над этой структурой данных. Ассоциативные свойства (n-местные отношения для n>1) можно представить либо в активной форме, либо в пассивной форме. В активной форме n-местное отношение представляется некоторым программным фрагментом, реализующим либо n-местную функцию (определяющую значение свойства соответствующего объединения объектов), либо процедуру, осуществляющую по состоянию представлений объектов, связываемых представляемым отношением, изменение состояний некоторых из них. В пассивной форме такое отношение может быть представлено некоторой структурой данных (в которую могут входить и представления объектов, связываемых этим отношением), интерпретируемую на основании принятых соглашений по общим процедурам, независящим от конкретных отношений (например, реляционная база данных). В любом случае представление отношения определяет некоторые действия по обработке данных.
При исследовании модельного мира пользователи могут по-разному получать (или захотеть получать) информацию от компьютера.
В одних случаях пользователей может интересовать получение информации об отдельных свойствах определенных объектов или результаты какого-либо взаимодействия между некоторыми объектами модельного мира. Для удовлетворения таких запросов разрабатываются соответствующие ПС, которые выполняют интересующие пользователей функции, или подходящие информационные системы, способные выдавать информацию об интересующих пользователей отношениях. В начальный период развития компьютерной техники (при не достаточно высокой мощности компьютеров) такой подход к исследованию модельного мира был вполне естественным. Именно он и провоцировал функциональный (реляционный) подход к разработке ПС, который был подробно рассмотрен в предшествующих лекциях. Сущность этого подхода состоит в систематическом использовании декомпозиции функций (отношений) для описания и построения структуры ПС (включая тексты программ). При этом сами объекты модельного мира, с которыми связаны заказываемые и реализуемые функции, представлялись фрагментарно (в том объеме, который необходим для выполнения этих функций) и в форме, удобной для реализации этих функций. Тем самым обеспечивалась эффективная реализация требуемых функций, но не создавалось цельного и адекватного компьютерного представления модельного мира, интересующего пользователя. Попытки даже незначительного расширения объема и характера информации об этом модельном мире, которую можно получить от ПС, могло потребовать серьезной модернизации этого ПС.
В других случаях пользователя может интересовать наблюдение за изменением состояний объектов модельного мира в результате их взаимодействий. Это требует использования подходящих информационных моделей таких объектов, создания программных средств, моделирующих процессы взаимодействия объектов модельного мира, и предоставление пользователю доступа к этим информационным моделям (к пользовательским объектам). С помощью традиционных методов разработки это оказалось довольно трудоемкой задачей. Наиболее полно отвечает решению этой задачи объектный подход к разработке ПС. Сущность его состоит в систематическом использовании декомпозиции объектов при описании и построении ПС. При этом функции (отношения), выполняемые таким ПС, будут выражаться через отношения объектов других уровней, т.е. их декомпозиция будет существенно зависеть от декомпозиции объектов.
С точки зрения разработчиков ПС следует различать следующие категории объектов (и, соответственно, их классов):
• объекты модельного (вещественного или умственного) мира,
• информационные модели объектов реального мира (будем называть их пользовательскими объектами),
• объекты процесса выполнения программ,
• объекты процесса разработки ПС (технологические объекты программирования).
Кроме того, в зависимости от способа представления в компьютере модельного мира и характера взаимодействия с ним со стороны пользователя следует различать пассивные и активные объекты. Пассивный объект представляет собой некоторый фрагмент информационной среды, который способен хранить разные данные определенного типа (представляющие разные состояния этого объекта) и с которым связан некоторый набор операций (применимых к этому объекту). Операции над таким объектом применяются под воздействием некоторой внешней по отношению к этому объекту активной силы, исходящей либо от пользователя, либо от какого-либо программного фрагмента в процессе его выполнения. Активный объект представляет собой такое расширение пассивного объекта, в котором фрагмент информационной среды способен также хранить и программные фрагменты, способные находиться в процессе выполнения (в активном состоянии). Активный объект, у которого какие-либо программные фрагменты находятся в активном состоянии, способен воспринимать сообщения или сигналы из операционной среды, в которую он погружен, и самостоятельно выполнять некоторые операции как реакцию на эти сообщения или сигналы. Таким образом, можно считать, что активный объект обладает внутренней активной силой.
Когда говорят об объектно-ориентированном подходе к разработке ПС, имеют в виду объектный подход с ориентацией на описание объектов модельного мира и построением их информационных моделей, причем используются, в основном, активные объекты. При этом многие процессы разработки ПС приобретают специфические («объектные») черты:
• использование системы понятий, позволяющих описывать объекты и их классы,
• декомпозиция объектов является основным средством упрощения ПС,
• использование внепрограммных абстракций для упрощения процессов разработки,
• предпочтение (приоритет) разработки структуры данных перед реализацией функций.
Основные из этих специфических особенностей разработки ПС по-кажем в рамках водопадной модели технологии.

15.2. Особенности объектного подхода к разработке внешнего описания программного средства.

При объектном подходе этап внешнего описания ПС оказывается существенно более емким и содержательным по сравнению с реляционным подходом [15.3, 15.4, 15.5].
Определение требований заключается в неформальном описании модельного мира, который пользователь собирается изучать или просто использовать с помощью требуемого ПС. При этом повышается роль прототипирования, которое при этом подходе часто окупается уменьшением объема работы на последующих этапах разработки ПС.
Спецификация качества сохраняет свое содержание.
Существенно изменяется содержание процесса спецификации требований: вместо разработки функциональной спецификации ПС создается формальное описание модельного мира, состоящее из трех частей:
• объектной модели,
• динамической модели,
• функциональной модели.
Назначение этих частей можно образно определить следующим образом [15.3]: объектная модель определяет то, с чем что-то случается; динамическая модель определяет, когда это случается; функциональная модель определяет то, что случается.
Объектная модель показывает статическую объектную структуру модельного мира, который должно представлять разрабатываемое ПС (программная система). Она включает определения используемых классов объектов и отношений между этими классами, а также определение используемых объектов этих классов и отношения между этими объектами.
Обычно класс объектов в объектной модели представляется в виде тройки
(Имя класса, Список атрибутов, Список операций).
Каждый атрибут представляется некоторым именем и может принимать значения определенного типа. По существу, атрибут класса выражает некоторое простое свойство объектов этого класса. Представление некоторых простых свойств объектов атрибутами весьма удобно, особенно когда по значениям этих атрибутов осуществляется классификация объектов. Операции, указываемые в представлении класса, отражают другие свойства объектов этого класса (как простые, так и ассоциативные). Они показывают, что можно делать с объектами этого класса (или что могут делать сами эти объекты).
В объектной модели отношение между объектами обобщаются в отношения между этими классами, к которым относятся эти объекты. При этом используются, как правило, только одноместные и двуместные отношения между объектами. Более сложные отношения приводит к неоправданному усложнению объектных моделей, а с другой стороны, такие отношения всегда могут быть сведены к двуместным за счет определения дополнительных классов. Одноместные отношения называют атрибутами, причем некоторые атрибуты объекта получаются из атрибутов класса присвоением им конкретных значений. Отношение между двумя (и более) объектами называют связями, а их обобщение (отношение между классами) обычно называют ассоциацией. Ассоциации играют важную роль в объектной модели  они определяют допустимые связи между объектами. Различают следующие виды ассоциаций:
• взаимодействия состояний объектов,
• агрегирования (структурирования) объектов,
• абстрагирования (порождения) классов.
Ассоциация «взаимодействие», по существу, означает, что объекты классов, находящихся в таком отношении, могут быть параметрами некоторых операций. Ассоциация «агрегирование» означает, что объект одного из классов, находящихся в таком отношении, включает (или может включать) в себя (как часть) объекты другого из этих классов. Ассоциация «абстрагирование» означает, что один из классов, находящихся в таком отношении, наследует свойства другого из этих классов и может обладать также и другими (дополнительными) свойствами.

Рис. 15.1. Пример отношения между классами объектов.
Для представления объектной модели часто используются графические языки спецификации объектов (например, язык UML [15.5]). На таких языках классы и объекты задаются прямоугольниками, которых указывается специфицирующая их информация. Для задания отношений между двумя классами соответствующие им прямоугольники связываются линией, снабженной различными графическими значками и некоторыми надписями. Графические значки специфицируют характер (вид) отношения между этими классами, а надписи обеспечивают полную идентификацию этого отношения (делают его конкретным). Например, на рис. 15.1 заданное отношение между классами Страна и Город имеет характер «один к одному». Более конкретно это отношение означает, что каждый объект класса Страна обязательно связан отношением «имеет столицей» с одним и только одним объектом класса Город, и этот объект класса Город не связан таким отношением ни с каким другим объектом класса Страна.
Для описания декомпозиции объектов используется отношение вида агрегирования. Например, отношение «программа состоит из одного или нескольких модулей» представлено на рис. 15.2.

Рис. 15.2. Пример отношения агрегирования между классами объектов.
Следует заметить, что объектная модель полностью включает описание внешней информационной среды при реляционном подходе.
Динамическая модель показывает допустимые последовательности изменений состояний объектов из объектной модели модельного мира, который должно представлять разрабатываемое ПС (программная система). Она описывает последовательности операций в ответ на внешние сигналы (взаимодействия) без рассмотрения того, что эти операции делают. Динамическая модель необходима, если в соответствующей объектной модели имеются активные объекты.
Основные понятия динамической модели: события и состояния объектов. Под событием здесь понимается элементарное воздействие одного объекта на другого, происходящее в определенный момент времени. Одно событие может логически предшествовать другому или быть не связанным с другим. Другими словами, события в динамической модели частично упорядочены. Под состоянием объекта здесь понимается совокупность значений атрибутов объекта и представления текущих связей этого объекта с другими объектами. Состояние объекта связывается с интервалом времени между некоторыми двумя событиями, на которые реагирует этот объект. Объект переходит из одного состояния в другое в результате реакции на некоторое событие (в конце интервала, связанного с этим состоянием).
В связи с этим в динамической модели для каждого класса активных объектов строится своя диаграмма состояний. Она представляет собой граф, вершинами которого являются состояния, а дугами – переходы между этими состояниями, обозначаемые именами событий. Некоторые переходы могут быть связаны с условиями, разрешающими эти переходы. Условие – это предикат, зависящий от значений некоторых атрибутов объекта. Каждое условие указывается на дуге, переходом по которой управляет это условие. Существенно, что в диаграмме состояний с некоторыми состояниями или событиями связываются определенные операции. Операция, связываемая с событием, обозначает реакцию объекта на это событие и считается, что она выполняется мгновенно (в точке некоторого временного интервала). Такая операция называется действием. Операция, связываемая с состоянием, выполняется в рамках временного интервала, с которым связано это состояние (т.е. имеет продолжительность, ограниченную этим интервалом). Такая операция называется деятельностью. Диаграмма состояний определяет управление активизацией указанных операций. Таким образом, диаграмма состояний описывает поведение одного класса объектов.
Динамическая модель в целом объединяет все диаграммы со-стояний с помощью событий между классами.
Функциональная модель показывает, как вычисляются выходные значения из входных без указания порядка, в котором эти значения вычисляются. Она определяет все операции, условия и ограничения, используемые в объектной и динамической моделях (внешние операции). Функциональная модель соответствует определению внешних функций при реляционном подходе к разработке ПС.
Для определения крупных операций в функциональной модели используются потоковые диаграммы (диаграммы потоков данных), позволяющие выразить эти операции через более простые операции. Основными понятиями потоковых диаграмм являются процессы, объекты и потоки данных. Потоковая диаграмма – это граф, вершинами которого являются объекты или процессы, а дугами – потоки данных. Процессы преобразуют данные, поступающие от одних объектов и направляемые для хранения в другие объекты. Эти процессы представляют внутренние операции, через которые выражается операция, представляемая данной потоковой диаграммой. Объекты могут быть пассивными (хранилищами данных) и активными (агентами). Пассивные объекты используются только для хранения данных, а активные объекты используются как для хранения, так и для преобразования данных. Потоки данных определяют допустимые направления перемещения данных и типы перемещаемых данных.
Процессы могут выражаться терминальными операциями (определяемые непосредственно) или с помощью других потоковых диаграмм. Таким образом, потоковые диаграммы являются иерархическими.
Терминальные операции определяются так же, как и при реляционном подходе (см. лекции 4 и 5). Впрочем, и диаграммы потоков данных используются при реляционном подходе.
Таким образом, основным содержанием этапа внешнего описания при объектном подходе является объектное моделирование. При этом широко используются формальные языки спецификаций, в том числе и графические. Одним из наиболее употребительных в настоящее время таких языков является язык UML [15.5].

15.3. Особенности объектного подхода на этапе конструирования программного средства.

На этапе конструирования при объектном подходе продолжается процесс объектного моделирования: уточняются модели, построенные на этапе внешнего описания, в терминах описания программных систем и производится дальнейшая декомпозиция объектов [15.3, 15.4, 15.5].
В процессе разработки объектной архитектуры ПС выделяются все объекты, с информационными моделями которых собирается непосредственно работать пользователь, и завершается их программная спецификация, а так же определяется их пользовательский интерфейс. Такие объекты мы будем называть пользовательскими. Классы таких объектов или отдельные активные объекты образуют архитектурные подсистемы. Определяется метод взаимодействия между этими подсистемами.
В случае использования активных объектов основным широким классом архитектур при объектном подходе является коллектив параллельно действующих программ (см. лекцию 6), причем здесь роль программ выполняют как раз эти активные объекты. Типичной архитектурой такого класса является архитектура «клиент-сервер». В такой системе один из активных объектов, называемый сервером, выполняет определенные программные услуги по запросам других активных объектов, называемых клиентами. Такой запрос передается серверу с помощью сообщения от клиента, результат выполнения сервером запроса передаются соответствующему клиенту с помощью другого сообщения.
Дальнейшая разработка структуры программных подсистем и их кодирование на языках программирования может осуществляться уже в рамках реляционного подхода на ориентированных на него языках программирования [15.6] – пользователь внутреннюю организацию этих подсистем уже «не видит». Однако, во многих случаях существуют сильные аргументы за то, чтобы продолжить объектную декомпозицию этих подсистем. Объектная структура этих подсистем может быть существенно более понятной разработчику, чем их структура при реляционном подходе. Кроме того, продолжение объектной декомпозиции и использование основных понятий и методов объектного подхода при дальнейшей разработке ПС представляется «естественным», так как весь процесс разработки становится единообразным (концептуально целостным). При этом приходится использовать языки программирования уже другого типа – объектно-ориентированные [15.6]. Объекты, возникающие в программах при такой декомпозиции архитектурных подсистем, мы будем называть объектами процесса выполнения программ.

Литература к лекции 15.

15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. – М.: Мир, 1988. С. 85-98.
15.2. В. Даль. Толковый словарь русского языка. –
15.3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenzen. Objekt-Oriented Modeling and Design. – Prentice Hall. 1991.
15.4. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. – М.: Конкорд, 1992.
15.5. М. Фаулер, К. Скотт. UML в кратком изложении. - М.: Мир, 1999.
15.6. В.Ш.Кауфман. Языки программирования. Концепции и принципы. – М.: Радио и связь, 1993.

[Tic-Sakyra]

Умный в гору не пойдет, умный гору обойдет.
Народная пословица (от И.Б. Задыхайло)

Лекция 16.
КОМПЬЮТЕРНАЯ ПОДДЕРЖКА РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ

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

16.1. Инструменты разработки программных средств.

При разработке программных средств используется в той или иной мере компьютерная поддержка процессов разработки и сопровождения ПС [16.1]. Это достигается путем представления хотя бы некоторых программных документов ПС (прежде всего, программ) на компьютерных носителях данных (например, на дискетах) и предоставлению в распоряжение разработчика ПС специальных ПС или включенных в состав компьютера специальных устройств, созданных для какой-либо обработки таких документов. В качестве такого специального ПС можно указать компилятор с какого-либо языка программирования. Компилятор избавляет разработчика ПС от необходимости писать программы на языке компьютера, который для разработчика ПС был бы крайне неудобен,  вместо этого он составляет программы на удобном ему языке программирования, которые соответствующий компилятор автоматически переводит на язык компьютера. В качестве специального устройства, поддерживающего процесс разработки ПС, можно указать, например, эмулятор какого-либо языка. Эмулятор позволяет выполнять (интерпретировать) программы на языке, отличном от языка компьютера, поддерживающего разработку ПС, например, на языке компьютера, для которого эта программа предназначена.
ПС, предназначенное для поддержки разработки других ПС, будем называть программным инструментом разработки ПС, а устройство компьютера, специально предназначенное для поддержки разработки ПС, будем называть аппаратным инструментом разработки ПС.
Инструменты разработки ПС могут использоваться в течение всего жизненного цикла ПС [16.2] для работы с разными программными документами. Так текстовый редактор может использоваться для разработки практически любого программного документа. С точки зрения функций, которые инструменты выполняют при разработке ПС, их можно разбить на следующие четыре группы:
* редакторы,
* анализаторы,
* преобразователи,
* инструменты, поддерживающие процесс выполнения про-грамм.
Редакторы поддерживают конструирование (формирование) тех или иных программных документов на различных этапах жизненного цикла. Как уже упоминалось, для этого можно использовать один какой-нибудь универсальный текстовый редактор. Однако, более сильную поддержку могут обеспечить специализированные редакторы: для каждого вида документов  свой редактор. В частности, на ранних этапах разработки в документах могут широко использоваться графические средства описания (диаграммы, схемы и т.п.). В таких случаях весьма полезными могут быть графические редакторы. На этапе программирования (кодирования) вместо текстового редактора может оказаться более удобным синтаксически управляемый редактор, ориентированный на используемый язык программирования.
Анализаторы производят либо статическую обработку доку-ментов, осуществляя различные виды их контроля, выявление определенных их свойств и накопление статистических данных (например, проверку соответствия документов указанным стандартам), либо динамический анализ программ (например, с целью выявление распределения времени работы программы по программным модулям).
Преобразователи позволяют автоматически приводить доку-менты к другой форме представления (например, форматеры) или переводить документ одного вида к документу другого вида (на-пример, конверторы или компиляторы), синтезировать какой-либо документ из отдельных частей и т.п.
Инструменты, поддерживающие процесс выполнения про-грамм, позволяют выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода, или машинный код с дополнительными возможностями его интерпретации. Примером такого инструмента является эмулятор кода другого компьютера. К этой группе инструментов следует отнести и различные отладчики. По существу, каждая система программирования содержит программную подсистему периода выполнения, которая выполняет программные фрагменты, наиболее типичные для языка программирования, и обеспечивает стандартную реакцию на возникающие при выполнении программ исключительные ситуации (такую подсистему мы будем называть исполнительной поддержкой). Такую подсистему также можно рассматривать как инструмент данной группы./color]

[color=green]16.2. Инструментальные среды разработки и сопровождения программных средств и принципы их классификации.

Компьютерная поддержка процессов разработки и сопровождения ПС может производиться не только за счет использования отдельных инструментов (например, компилятора), но и за счет использования некоторой логически связанной совокупности программных и аппаратных инструментов. Такую совокупность будем называть инструментальной средой разработки и сопровождения ПС.
Часто разработка ПС производится на том же компьютере, на котором оно будет применяться. Это достаточно удобно. Во-первых, в этом случае разработчик имеет дело только с компьютерами одного типа. А, во-вторых, в разрабатываемое ПС могут включаться компоненты самой инструментальной среды. Однако, это не всегда возможно. Например, компьютер, на котором должно применяться ПС, может быть неудобен для поддержки разработки ПС или его мощность недостаточна для обеспечения функционирования требуемой инструментальной среды. Кроме того, такой компьютер может быть недоступен для разработчиков этого ПС (например, он постоянно занят другой работой, которую нельзя прерывать, или он находится еще в стадии разработки). В таких случаях применяется так называемый инструментально-объектный подход [16.1]. Сущность его заключается в том, что ПС разрабатывается на одном ком-пьютере, называемым инструментальным, а применяться будет на другом компьютере, называемым целевым (или объектным).
Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет применяться разрабатываемое с помощью ее ПС.
Совокупность инструментальных сред можно разбивать на разные классы, которые различаются значением следующих признаков:
* ориентированность на конкретный язык программирования,
* специализированность,
* комплексность,
* ориентированность на конкретную технологию программирования,
* ориентированность на коллективную разработку,
* интегрированность.
Ориентированность на конкретный язык программирования (языковая ориентированность) показывает: ориентирована ли среда на какой-либо конкретный язык программирования (и на какой именно) или может поддерживать программирование на разных языках программирования. В первом случае информационная среда и инструменты существенно используют знание о фиксированном языке (глобальная ориентированность), в силу чего они оказываются более удобным для использования или предоставляют дополнительные возможности при разработке ПС. Но в этом случае такая среда оказывается не пригодной для разработки программ на другом языке. Во втором случае инструментальная среда поддерживает лишь самые общие операции и, тем самым, обеспечивает не очень сильную поддержку разработки программ, но обладает свойством расширения (открытости). Последнее означает, что в эту среду могут быть добавлены отдельные инструменты, ориентированные на тот или иной конкретный язык программирования, но эта ориентированность будет лишь локальной (в рамках лишь отдельного инструмента).
Специализированность инструментальной среды показывает: ориентирована ли среда на какую-либо предметную область или нет. В первом случае информационная среда и инструменты суще-ственно используют знание о фиксированной предметной области, в силу чего они оказываются более удобными для использования или предоставляют дополнительные возможности при разработке ПС для этой предметной области. Но в этом случае такая инструментальная среда оказывается не пригодной или мало пригодной для разработки ПС для других предметных областей. Во втором случае среда поддерживает лишь самые общие операции для разных предметных областей. Но в этом случае такая среда будет менее удобной для конкретной предметной области, чем специализированная на эту предметную область.
Комплексность инструментальной среды показывает: поддер-живает ли она все процессы разработки и сопровождения ПС или нет. В первом случае продукция этих процессов должна быть согласована. Поддержка инструментальной средой фазы сопровождения ПС, означает, что она должна поддерживать работу сразу с несколькими вариантами ПС, ориентированными на разные условия применения ПС и на разную связанную с ним аппаратуру, т.е. должна обеспечивать управление конфигурацией ПС [16.1, 16.3].
Ориентированность на конкретную технологию программирования показывает: ориентирована ли инструментальная среда на фиксированную технологию программирования [16.2] либо нет. В первом случае структура и содержание информационной среды, а также набор инструментов существенно зависит от выбранной технологии (технологическая определенность). Во втором случае инструментальная среда поддерживает самые общие операции разработки ПС, не зависящие от выбранной технологии программирования.
Ориентированность на коллективную разработку показывает: поддерживает ли среда управление (management) работой коллектива или нет. В первом случае она обеспечивает для разных членов этого коллектива разные права доступа к различным фрагментам продукции технологических процессов и поддерживает работу менеджеров [16.1] по управлению коллективом разработчиков. Во втором случае она ориентирована на поддержку работы лишь отдельных пользова-телей.
Интегрированность инструментальной среды показывает: является ли она интегрированной (и в каком смысле) или нет. Инструментальная среда считается интегрированной, если взаимодействие пользователя с инструментами подчиняется единообразным правилам, а сами инструменты действуют по заранее заданной информационной схеме, связаны по управлению или имеют общие части. В соответствие с этим различают три вида интегрированности:
* интегрированность по пользовательскому интерфейсу,
* интегрированность по данным,
* интегрированность по действиям (функциям),
Интегрированность по пользовательскому интерфейсу означает, что все инструменты объединены единым пользовательским интерфейсом. Интегрированность по данным означает, что инструменты действуют в соответствии с фиксированной информационной схемой (моделью) системы, определяющей зависимость друг от друга различных используемых в системе фрагментов данных (информационных объектов). В этом случае может быть обеспечен контроль полноты и актуальности программных документов и порядка их разработки. Интегрированность по действиям означает, что, во-первых, в системе имеются общие части всех инструментов и, во-вторых, одни инструменты при выполнении своих функций могут обращаться к другим инструментам.
Инструментальную среду, интегрированную хотя бы по данным или по действиям, будем называть инструментальной системой. При этом интегрированность по данным предполагает наличие в системе специализированной базы данных, называемой репозиторием. Под репозиторием будем понимать центральное компьютерное хранилище информации, связанной с проектом (разработкой) ПС в течение всего его жизненного цикла [16.1].

16.3. Основные классы инструментальных сред разработки и сопровождения программных средств.

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

Рис. 16.1. Основные классы инструментальных сред разработки и сопровождения ПС.
Инструментальная среда программирования предназначена в основном для поддержки процессов программирования (кодирования), тестирования и отладки ПС. Она не обладает рассмотренными выше свойствами комплексности, ориентированности на конкретную технологию программирования, ориентированности на коллективную разработку и, как правило, свойством интегрированности, хотя имеется некоторая тенденция к созданию интегрированных сред программирования (в этом случае их следовало бы называть системами программирования). Иногда среда программирования может обладать свойством специализированности. Признак же ориентированности на конкретный язык программирования может иметь разные значения, что существенно используется для дальнейшей классификации сред программирования.
Рабочее место компьютерной технологии ориентировано на поддержку ранних этапов разработки ПС (системного анализа и спецификаций) и автоматической генерации программ по спецификациям [16.1, 16.4]. Оно существенно использует свойства специализированности, ориентированности на конкретную технологию программирования и, как правило, интегрированности. Более поздние рабочие места компьютерной технологии обладают также свойством комплексности ([16.4]). Что же касается языковой ориентированности, то вместо языков программирования они ориентированы на те или иные формальные языки спецификаций. Свойством ориентированности на коллективную разработку указанные рабочие места в настоящее время, как правило, не обладают.
Инструментальная система технологии программирования предназначена для поддержки всех процессов разработки и сопровождения в течение всего жизненного цикла ПС и ориентирована на коллективную разработку больших программных систем с продолжительным жизненным циклом. Обязательными свойствами ее являются комплексность, ориентированность на коллективную разработку и интегрированность. Кроме того, она или обладает технологической определенностью или получает это свойство в процессе расширения (настройки). Значение признака языковой ориентированности может быть различным, что используется для дальнейшей классификации этих систем.

16.3. Инструментальные среды программирования.

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

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

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

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС).CASE  это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия Программирования). Но без помощи (поддержки) компьютера ПС уже давно не разрабатываются (используется хотя бы компилятор). В действительности, в это понятие вкладывается более узкий (специальный) смысл, который постепенно размывается (как это всегда бывает, когда какое-либо понятие не имеет строгого определения). Первоначально под CASE понималась [16.4] инженерия ранних этапов разработки ПС (определение требований, разработка внешнего описания и архитектуры ПС) с использованием программной поддержки (программных инструментов). Теперь под CASE может пониматься [16.4] и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.
В настоящее время компьютерную технологию разработки ПС можно характеризовать [16.1] использованием
• программной поддержки для разработки графических требований и графических спецификаций ПС,
• автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или полностью),
• программной поддержки прототипирования.
Говорят также, что компьютерная технология разработки ПС является "безбумажной", т.е. рассчитанной на компьютерное представление программных документов. Однако, уверенно отличить ручную технологию разработки ПС от компьютерной по этим признакам довольно трудно. Значит, самое существенное в компьютерной технологии не выделено.
На наш взгляд, главное отличие ручной технологии разработки ПС от компьютерной заключается в следующем. Ручная технология ориентирована на разработку документов, одинаково понимаемых разными разработчиками ПС, тогда как компьютерная технология ориентирована на обеспечение семантического понимания (интерпретации) документов программной поддержкой компьютерной технологии. Семантическое понимание документов дает программной поддержке возможность автоматически генерировать программы. В связи с этим существенной частью компьютерной технологии становится использование формальных языков уже на ранних эта-пах разработки ПС: как для спецификации программ, так и для спецификации других документов. В частности, широко используются формальные графические языки спецификаций. Именно это позволяет рационально изменить и саму совокупность технологических процессов разработки и сопровождения ПС.
Из проведенного обсуждения можно определить компьютерную технологию разработки ПС как технологию программирования, в которой используются программные инструменты для разработки формализованных спецификаций программ и других документов (включая и графические спецификации) с последующей автоматической генерацией программ и документов (или хотя бы значительной их части) по этим спецификациям.
Теперь становятся понятными и основные изменения в жизненном цикле ПС для компьютерной технологии. Если при использовании ручной технологии основные усилия по разработке ПС делались на этапах собственно программирования (кодирования) и отладки (тестирования), то при использовании компьютерной технологии  на ранних этапах разработки ПС (определения требований и функциональной спецификации, разработки архитектуры). При этом существенно изменился характер документации. Вместо целой цепочки неформальных документов, ориентированной на передачу информации от заказчика (пользователя) к различным категориям разработчикам, формируются прототип ПС, поддерживающий выбранный пользовательский интерфейс, и формальные функциональные спецификации (иногда и формальные спецификации архитектуры ПС), достаточные для автоматического синтеза (генерации) программ ПС (или хотя бы значительной их части). При этом появилась возможность автоматической генерации части документации, необходимой разработчикам и пользователям. Вместо ручного программирования (кодирования)  автоматическая генерация программ, что делает не нужной автономную отладку и тестирование про-грамм: вместо нее добавляется достаточно глубокий автоматический семантический контроль документации. Появляется возможность автоматической генерации тестов по формальным спецификациям для комплексной (системной) отладки ПС. Существенно изменяется и характер сопровождения ПС: все изменения разработчиком-сопроводителем вносятся только в спецификации (включая и прототип), остальные изменения в ПС осуществляются автоматически.
С учетом сказанного жизненный цикл ПС для компьютерной технологии можно представить [16.4] следующей схемой (рис. 16.3).

Рис. 16.3. Жизненный цикл программного средства для компьютерной технологии.
Прототипирование ПС является необязательным этапом жизненного цикла ПС при компьютерной технологии, что на рис. 16.3 показано пунктирной стрелкой. Однако использование этого этапа во многих случаях и соответствующая компьютерная поддержка этого этапа является характерной для компьютерной технологии. В некоторых случаях прототипирование делается после (или в процессе) разработки спецификаций ПС, например, в случае прототипирования пользовательского интерфейса. Это показано на рис. 16.3 пунктирной возвратной стрелки. Хотя возврат к предыдущим этапам мы допускаем на любом этапе, но здесь это показано явно, так как прототипирование является особым подходом к разработке ПС (см. лекцию 3). Прототипирование пользовательского интерфейса позволяет заменить косвенное описание взаимодействия между пользователем и ПС при ручной технологии (при разработке внешнего описания ПС) прямым выбором пользователем способа и стиля этого взаимодействия с фиксацией всех необходимых деталей. По существу, на этом этапе производится точное описание пользовательского интерфейса, понятное программной поддержке компьютерной технологии, причем с ответственным участием пользователя. Все это базируется на наличие в программной поддержке компьютерной технологии настраиваемой оболочки с обширной библиотекой заготовок различных фрагментов и деталей экрана. Такое прототипирование, по-видимому, является лучшим способом преодоления барьера между пользователем и разработчиком.
Разработка спецификаций ПС распадается на несколько разных процессов. Если исключить начальный этап разработки спецификаций (определение требований), то в этих процессах используются методы, приводящие к созданию формализованных документов, т. е. используются формализованные языки спецификаций. При этом широко используются графические методы спецификаций, приводящие к созданию различных схем и диаграмм, которые определяют структуру информационной среды и структуру управления ПС. К таким структурам привязываются фрагменты описания данных и программ, представленные на алгебраических языках спецификаций (например, использующие операционную или аксиоматическую семантику), или логических языках спецификаций (базирующихся на логическом подходе к спецификации программ). Такие спецификации позволяют в значительной степени или полностью автоматически генерировать программы. Существенной частью разработки спецификаций является создание словаря именованных сущностей, используемых в спецификациях.
Автоматизированный контроль спецификаций ПСиспользует то обстоятельство, что значительная часть спецификаций представляется на формальных языках. Это позволяет автоматически осуществлять различные виды контроля: синтаксический и частичный семантический контроль спецификаций, контроль полноты и состоятельности схем и диаграмм (в частности, все их элементы должны быть идентифицированы и отражены в словаре именованных сущностей), сквозной контроль сбалансированности уровней спецификаций и другие виды контроля в зависимости от возможностей языков спецификаций.
Генерация программ ПС. На этом этапе автоматически генерирует скелеты кодов программ ПС или полностью коды этих программ по формальным спецификациям ПС.
Автоматизированное документирование ПС. Предполагает возможность генерации различных форм документов с частичным заполнением их по информации, хранящейся в репозитории. При этом количество видов документов сокращается по сравнению с традиционной технологией.
Комплексное тестирование и отладка ПС. На этом этапе тестируются все спецификации ПС и исправляются обнаруженные при этом ошибки. Тесты могут создаваться как вручную, так и автоматически (если это позволяют используемые языки спецификаций) и пропускаются через сгенерированные программы ПС.
Аттестация ПС имеет прежнее содержание.
Сопровождение ПС существенно упрощается, так как основные изменения делаются только в спецификациях.
Рабочее место компьютерной технологии разработки ПС представляет собой инструментальную среду, поддерживающую все этапы жизненного цикла этой технологии. В этой среде существенно используется репозиторий. В репозитории хранится вся информация, создаваемая в процессе разработки ПС (в частности, словарь именованных сущностей и все спецификации). По существу, рабочее место компьютерной технологии является интегрированным хотя бы по пользовательскому интерфейсу и по данным. Основными инструментами такого рабочего места являются:
• конструкторы пользовательских интерфейсов;
• инструмент работы со словарем именованных сущностей;
• графические и тестовые редакторы спецификаций;
• анализаторы спецификаций;
• генератор программ;
• документаторы.

14.5. Инструментальные системы технологии программирования.

Инструментальная система технологии программирования  это интегрированная совокупность программных и аппаратных инструментов, поддерживающая все процессы разработки и сопровождения больших ПС в течение всего его жизненного цикла в рамках определенной технологии. Выше уже отмечалось (см. п. 14.3), что она помимо интегрированности обладает еще свойствами комплексности и ориентированности на коллективную разработку. Это означает, что она базируется на согласованности продукции технологических процессов. Тем самым, инструментальная система в состоянии обеспечить, по крайней мере, контроль полноты (комплектности) создаваемой документации (включая набор программ) и согласованности ее изменения (версионности). Поддержка инструментальной системой фазы сопровождения ПС, означает, что она должна обеспечивать управление конфигурацией ПС [16.1, 16.3]. Кроме того, инструментальная система поддерживает управление работой коллектива и для разных членов этого коллектива обеспечивает разные права доступа к различным фрагментам продукции технологических процессов и поддерживает работу менеджеров [16.1] по управлению коллективом разработчиков. Инструментальные системы технологии программирования представляют собой достаточно большие и дорогие ПС, чтобы как-то была оправданна их инструментальная перегруженность. Поэтому набор включаемых в них инструментов тщательно отбирается с учетом потребностей предметной области, используемых языков и выбранной технологией программирования.
С учетом обсужденных свойств инструментальных систем технологии программирования можно выделить три их основные компоненты:
• репозиторий,
• инструментарий,
• интерфейсы.
Инструментарий  набор инструментов,определяющий возможности, предоставляемые системой коллективу разработчиков. Обычно этот набор является открытым и структурированным. По-мимо минимального набора (встроенные инструменты), он содержит средства своего расширения (импортированными инструментами). Кроме того, в силу интегрированности по действиям он состоит из некоторой общей части всех инструментов (ядра) и структурных (иногда иерархически связанных) классов инструментов.
Интерфейсы разделяются на пользовательский и системные. Пользовательский интерфейс обеспечивает доступ разработчикам к инструментарию. Он реализуется оболочкой системы. Системные интерфейсы обеспечивают взаимодействие между инструментами и их общими частями. Системные интерфейсы выделяются как архитектурные компоненты в связи с открытостью системы  их обязаны использовать новые (импортируемые) инструменты, включаемые в систему.
Самая общая архитектура инструментальных систем технологии программирования представлена на рис. 16.4.

[url=http://ifotki.info/14/353918128b171a69b7914365dc6f42755ee6f6154967168.png.html][/URL

]
Рис. 16.4. Общая архитектура инструментальных систем технологии программирования.
Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.
Инструментальная система поддержки проекта  это открытая система, способная поддерживать разработку ПС на разных языках программирования после соответствующего ее расширения программными инструментами, ориентированными на выбранный язык. Набор инструментов такой системы поддерживает разработкой ПС, а также содержит независимые от языка программирования инструменты, поддерживающие разработку ПС (текстовые и графические редакторы, генераторы отчетов и т.п.). Кроме того, он содержит инструменты расширения системы. Ядро такой системы обеспечивает, в частности, доступ к репозиторию.
Языково-зависимая инструментальная система  это система поддержки разработки ПС на каком-либо одном языке программирования, существенно использующая в организации своей работы специфику этого языка. Эта специфика может сказываться и на возможностях ядра (в том числе и на структуре репозитория), и на требованиях к оболочке и инструментам. Примером такой системы является среда поддержки программирования на Аде (APSE [16.5]).

Упражнения к лекции 16.

16.1. Что такое программный инструмент разработки ПС?
16.2. Что такое аппаратный инструмент разработки ПС?
16.3. Что такое инструментальная среда разработки и сопровождения ПС?
16.4. Что такое инструментально-объектный подход к разработке программного средства?
16.5. Какие признаки классификации инструментальных сред раз-работки и сопровождения ПС Вы знаете?
16.6. Что такое интегрированность инструментальной среды разработки и сопровождения ПС?
16.7. Какие виды интегрированности инструментальной среды разработки и сопровождения ПС Вы знаете?
16.8. Что такое репозиторий инструментальной среды разработки и сопровождения ПС?
16.9. Что такое инструментальная среда программирования?
16.10. Что такое языково-ориентированная инструментальная среда программирования?
16.11. Что такое компьютерная технология (CASE-технология) разработки ПС?
16.12. Какие отличия жизненного цикла ПС при компьютерной технологии программирования от жизненного цикла ПС при традиционной (ручной) технологии программирования (при водопадном подходе)?
16.13. Что такое рабочее место компьютерной технологии разработки и сопровождения ПС?
16.14. Что такое инструментальная система технологии про-граммирования?
16.15. Что такое языково-зависимая инструментальная система технологии программирования?
16.16. Что такое ядро инструментальной системы технологии программирования?
16.17. Что такое встроенный инструмент инструментальной системы технологии программирования?
16.18. Что такое импортируемый инструмент инструментальной системы технологии программирования?
16.19. Что такое оболочка инструментальной системы техноло-гии программирования?

Литература к лекции 16.

16.1. Ian Sommerville. Software Engineering. - Addison-Wesley Pub-lishing Company, 1992. P. 349-369.
16.2. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
16.3. М.М. Горбунов-Посадов. Конфигурации программ. Рецепты безболезненных изменений. – М.: «Малип», 1994.
16.4. CASE: Компьютерное проектирование программного обеспечения. - Издательство Московского университета, 1994.
16.5. Requirements for Ada Programming Support Environments. - USA: DoD, Stoneman, 1980.

[Tic-Sakyra]

 

Список клавишных команд Windows

Клавишные команды

Операции в окнах проводника или папок

Другие операции в окнах папок и проводника

Управление древовидной структурой объектов в проводнике

Окна свойств

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

Сочетания с клавишей Windows

Диалоговые окна

Горячие клавиши с кнопкой Win

Компьютеры, на которых установлена операционная система Windows, как правило, имеют Windows-совместимую клавиатуру. На такой клавиатуре есть специальные кнопки, например, клавиша с изображением логотипа Windows Ее сокращенно называют Win.
Может ещё быть отдельная клавиша контекстного меню. Обычно эти кнопки расположены в нижнем ряду – около кнопок Ctrl и Alt.
Предлагаю Вашему вниманию список горячих клавиш с клавишей Win:

В этом списке не имеет значения регистр указанных букв, то есть это может быть и английская раскладка, и русская раскладка. Например, сочетание Win+D в английской раскладке делает тоже самое, что и сочетание Win+В в русской раскладке, то есть при однократном нажатии сворачивает все окна и показывает рабочий стол.
Список горячих клавиш для операционной системы, отличной от Windows XP, можно найти в интернете. Для этого следует набрать в поисковике, например, поисковый запрос «горячие клавиши Windows 7», либо «горячие клавиши Windows Vista», либо «mac горячие клавиши».
Упражнения по компьютерной грамотности:
1) Посмотрите на своем компьютере, как действуют горячие клавиши из приведенной выше таблицы.
2) Предлагаю записать на листе бумаги или блокнота те сочетания клавиш (и их действие), которые Вы бы хотели использовать в дальнейшем и поместить их рядом с компьютером. Минимум горячих клавиш, на мой взгляд: Win, Win+D, Win+F1.

Стандартные горячие клавиши в Windows XP

Многие стандартные горячие клавиши работают не только в Windows XP, но и в других операционных системах.

Комбинация клавиш Ctrl+Shift+Esc выводит на экран Диспетчер задач, с помощью которого можно завершить «зависшую» (то есть, не отвечающую на действия пользователя) программу. С моей точки зрения, необходимо знать и пользоваться такими горячими клавишами, как Ctrl+C, Ctrl+V, Ctrl+X, Ctrl+A, Alt+F4, Ctrl+Alt+Delete, PrtSc.
Упражнение по компьютерной грамотности:
Выбрать из приведенного выше списка полезные, с Вашей точки зрения, горячие клавиши, записать (или распечатать) их c целью дальнейшего применения в своей работе на ПК.

Дуэт мышки и клавиатуры

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

Но если эту клавишу использовать одновременно с мышкой, то она позволяет выделять целые куски текста, например, в редакторе Word или в Блокноте. Это можно использовать для последующего копирования выделенного фрагмента в буфер обмена. Для этого нужно:
• C начала подвести курсор мышки к началу выделяемого фрагмента.
• Сделать щелчок левой кнопкой мыши и отпустить ее. Появится значок курсора.
• Затем нажать на клавиатуре клавишу Shiftи, удерживая ее нажатой, подвести курсор мыши к концу выделяемого фрагмента, после чего сделать щелчок левой кнопкой мыши.
Фрагмент страницы будет выделен. Очень удобно для выделения больших фрагментов текста, которые не помещаются в видимую часть окна.
Клавиша Ctrl (сокращение английского слова Control – в данном контексте это переводится как «специальный») позволяет вводить с клавиатуры специальные символы. А при применении одновременно с мышкой эта клавиша позволяет выделять сразу несколько фрагментов текста. Работает это следующим образом:
• Сначала используя левую кнопку мышки, выделяем один фрагмент страницы.
• Затем перемещаем указатель мышки на следующий фрагмент.
• Нажимаем клавишу Ctrlи, не отпуская ее, выделяем следующий фрагмент. После этого клавишу Ctrlнужно отпустить.
Очень важно при одновременном выделении нескольких фрагментов текста нажимать сначала клавишу Ctrl, а только затем, удерживая эту клавишу нажатой, приступать к выделению следующего фрагмента.
Если же не нажать на Ctrl, а сразу приступить к выделению нового фрагмента (нажав на левую кнопку мыши), то прежние выделения текста будут отменены, так как компьютерная программа интерпретирует нажатие на левую кнопку мыши (если не нажата клавиша Ctrl) как отмену всех ранее сделанных выделений текста.
Данный метод позволяет выделить любое количество фрагментов в редакторе Word или Блокноте. Кроме того, этот сервис является очень удобным при использовании таблиц MS Excel для одновременного выделения нескольких клеток таблицы, которые не находятся возле друг друга.
С помощью клавиши Ctrlможно не только выделять, но и копировать фрагменты текста. Например, в редакторе MS Word можно выделить часть текста, подвести к этому выделенному фрагменту курсор мыши.
Если затем нажать и удерживать нажатой левую кнопку мыши, то перемещая мышь, данный фрагмент текста можно поместить в другую часть редактируемого текста. Подобным образом можно, например, переставлять слова в тексте.
Но если вам нужно чтобы перемещаемый фрагмент текста сохранился и на старом месте, то достаточно при перемещении удерживать клавишу Ctrlна клавиатуре. В этом случае под указателем мыши появится маленький плюсик (+), который означает автоматическое создание копии выделенного фрагмента текста. Он будет скопирован в новое место и, кроме этого, сохранен на старом месте.
Очень интересный эффект можно наблюдать при одновременном использовании клавиши Ctrl и колесика мышки. Если нажать и удерживать клавишу Ctrlи одновременно покрутить колесико, то видимое на экране монитора изображение будет увеличиваться при вращении колесика «от себя», либо уменьшаться при вращении колесика «на себя».
Рекомендуется при этом крутить колесико медленно, иначе можно не уследить за происходящими изменениями масштаба изображения или текста. Данный метод очень удобен при чтении текстов с мелким шрифтом или при просмотре интернет-страниц, в которых также применяется шрифт маленького размера.
Думаю, многие согласятся, что информация усваивается лучше, когда она представлена в комфортном для восприятия масштабе, да и для зрения это важно.
Таким образом, мы видим, что возможности манипулятора «мышь», в том числе при одновременном использовании с клавиатурой, гораздо больше, чем при обычном использовании ее только в сочетании с левой кнопкой.
Но и это еще не все. Можно использовать клавиатуру для выполнения часто повторяющихся действий. Например, при редактировании текстов часто приходится копировать выделенные фрагменты текста, а затем вставлять их в другие части документа, или в другие одновременно редактируемые документы.
В этом случае удобно использовать сочетания клавиш Ctrl и «C» для копирования выделенного фрагмента, а Ctrl и «V» для вставки скопированного фрагмента (такие сочетания записываются в литературе по компьютерной тематике как Ctrl+C, Ctrl+Vи т.д.)
При этом мышка используется сначала для выделения копируемого фрагмента, а затем для указания места, куда следует этот фрагмент вставить, а сами процессы копирования и вставки выполняются путем нажатия на указанные клавиши.
Кстати, обратите, пожалуйста, внимание на то, что если указано любое сочетание клавиш (например, Ctrl+C), то сначала нажимать нужно первую указанную в сочетании клавишу (в данном примере – это клавиша Ctrl), и затем, удерживая эту клавишу нажатой, следует нажать на вторую клавишу (в нашем случае – это клавиша с изображением латинской буквы C).
Также поступают, если указано сочетание трех клавиш одновременно. Их нажимают последовательно с первой по третью: сначала первую клавишу, затем, не отпуская ее, нажимают на вторую, и, наконец, не отпуская первые две клавиши, нажимают на третью клавишу. После завершения операции все клавиши можно отпустить одновременно. Но если их одновременно нажать, то ожидаемый результат может и не получиться.
Еще следует отметить, что в сочетаниях клавиш всегда указываются латинские обозначения. Это не означает, что при использовании сочетания клавиш следует включать регистр для ввода английского текста. Сочетания клавиш действуют независимо от того, какая раскладка клавиатуры включена в данный момент. Латинские наименования клавиш пишут в таких сочетаниях клавиш для того, чтобы они были понятны пользователям из любых стран, говорящих на любых языках.
Как ни странно, но опытные пользователи очень часто предпочитают использовать сочетания клавиш Ctrl и Shift с другимиклавишами клавиатуры (это называется термином«горячие клавиши»), и особенно часто это применяется при редактировании изображений.
С бытовой точки зрения, для редактирования изображений как раз наиболее подходящей является мышь, так как ее применение дает большую наглядность. Но оказывается тем, кто профессионально занимается «рисованием» или «черчением» на компьютере, во многих случаях быстрее и проще использовать «горячие клавиши», так как они обеспечивают скорость, точность и качество выполнения конкретных операций, закрепленных за этими клавишами.
Сочетания Ctrlс другими клавишами клавиатуры в разных программах может иметь разное значение. Однако постепенно эти сочетания «горячих клавиш» стандартизуются. Так, например, во многих программах сочетание Ctrl+A означает«выделить весь документ». Так же во многом совпадают описанные выше сочетания Ctrl+C, Ctrl+V и т.п. «Горячие клавиши» - это не только сочетания Ctrl с другими клавишами, но и просто отдельные клавиши. Например, нажатие на клавишу «Del» (сокращение от английского Delete – «удалить») почти всегда означает удаление выделенного фрагмента документа.
В качестве «горячих клавиш» используется сочетание не только с клавишей Ctrl, но и с клавишей Shift. Также для этого используются клавиши F1-F12 и т.п.
Можно достаточно просто узнать назначение «горячих клавиш», если обратить внимание на основное меню программы. Вы увидите, что возле некоторых наименований пунктов меню записано и сочетание клавиш, которые это действие выполняют.
Например, если в Блокноте(Пуск-->Программы-->Стандартные-->Блокнот) щелкнуть на слово «Файл» в основном меню, то в открывшемся окошке рядом с действием «Создать» будет записано сочетание клавиш Ctrl+N, рядом с «Сохранить» - Ctrl+S и т.п.
Таким образом, если постепенно освоить сочетания «горячих клавиш» и сочетания клавиш, работающих одновременно с мышкой, то это позволит более уверенно, быстро и профессионально вводить и редактировать тексты, изображения и другие элементы информации.
Упражнения по компьютерной грамотности:
1) С помощью «горячих клавиш»Ctrl+C и Ctrl+V скопируйте текст этой статьи вместе с упражнениями по компьютерной грамотности и поместите его в текстовый редактор (например, Блокнот).
Выделите с помощью клавиатуры текст данного задания №1. Правда, понадобится мышка, чтобы установить с её помощью курсор слева от первого символа выделяемого фрагмента. После установки курсора отпустите мышку, нажмите клавишу Shift и, удерживая ее нажатой, переместите курсор с помощью клавиатуры (клавиша «стрелка вправо») на конец выделяемого фрагмента. Фрагмент будет выделен.
2) Выделите только с помощью клавиатуры текст задания №2. Для этого поместите с помощью мыши курсор слева от первого символа предложения, нажмите клавишу Shift и, удерживая ее нажатой, один раз нажмите на клавишу «стрелка вниз», а затем, многократно нажимая (или нажав один раз и удерживая нажатой) клавишу «стрелка вправо» выделите текст до символа «.» - конец предложения.
Если Вы «проскочили» конец предложения и выделили больше, чем необходимо, то, продолжая удерживать клавишу Shift, отмените лишние выделения путем нажатия на клавишу «стрелка влево». Почувствуйте, как происходит выделение текста или отмена выделения, произвольно перемещая курсор вниз, вверх, влево и вправо, оставляя нажатой клавишу Shift.
Поймите, как можно обходиться без мышки для выполнения операций по выделению фрагментов текста.
3) Выделите 1-е и 3-е предложения в тексте задания №2. Для этого сначала с помощью мышки выделите 1-е предложение, нажмите и удерживайте нажатой клавишу Ctrl, переместите курсор мышки на начало 3-го предложения, после чего, не отпуская Ctrl, выделите 3-е предложение в тексте.
Если Вы делаете 3-ье упражнение прямо на этой Интернет-странице и оно не получается, причина может быть в браузере. Попробуйте все то же самое сделать не на Интернет-странице, а в текстовом редакторе.
4) С помощью «горячих клавиш» Ctrl+C и Ctrl+V скопируйте текст задания №3 в свой документ, созданный с помощью редактора MS Word или в Блокноте. Для этого выделите (любым теперь известным Вам способом) данный фрагмент текста, нажмите сочетание «горячих клавиш» Ctrl+C (сначала нажмите Ctrl, затем, удерживая ее нажатой, нажмите клавишу с изображением латинской буквы C, независимо от установленной раскладки клавиатуры).
После этого зайдите в редактор MS Word или в Блокнот, создайте новый документ, установите курсор в начало документа и нажмите сочетание клавиш Ctrl+V. Скопированный Вами текст должен появиться на экране, если все было сделано без ошибок. Посмотрите, что получится, если еще раз нажать сочетание клавиш Ctrl+V.
5) Попробуйте увеличить - уменьшить размер шрифта на своем экране, используя колесико мышки и клавишу Ctrl.
Большие секреты маленькой мышки
На начальном этапе освоения компьютера кажется, что клавиатура нужна исключительно для ввода и редактирования текстовой информации, а мышка – для редактирования текстовой информации и ввода/редактирования изображений.
Здесь начинающие пользователи исходят из того, что на клавиатуре нанесены изображения букв и символов (поэтому это нужно для ввода этих символов), а мышка позволяет плавно передвигать курсор по экрану, а значит, используется для «рисования» или редактирования текстов и изображений.
Однако это только видимая часть того, что нам позволяет мышка и клавиатура. На самом деле, профессиональные пользователи компьютеров активно используют клавиатуру для «рисования» или редактирования изображений (и зачастую отдают предпочтение клавиатуре из-за большей скорости и высокой точности рисования и редактирования изображений!), а также активно работают с мышкой и клавиатурой одновременно.

Давайте посмотрим с точки зрения компьютерной грамотности на некоторые дополнительные возможности самостоятельного (без применения клавиатуры) использования манипулятора «мышь» (в просторечии «мышь» или «мышка»). Обратим внимание на колесико мыши. Если вращать колесико «на себя», то текст или изображение будут перемещаться снизу вверх (в направлении, в котором происходит чтение текста).
При обратном вращении колесика «от себя» текст и изображение будут также перемещаться в обратном направлении. Данная опция работает в большинстве современных программ, в том числе в MS Word или интернет браузерах. С помощью колесика вы можете «прокручивать» изображение интернет-страниц, в том числе, страницы моего блога. Вращение колесика позволяет быстрее находить интересующие места на странице, концентрировать внимание на интересующих моментах.
Скорость перемещения текста и графических изображений регулируется в окне настройки мыши Панели управления на вкладке «Колесико» (Пуск-->Панель управления-->Мышь-->Колесико). Указывая количество строк, на которое должен переместиться текст при вращении колесика, Вы можете ускорить или замедлить перемещение.
Чем больше строк Вы укажете, тем быстрее будет двигаться видимая вами страница. Можно перемещать сразу на целый экран одним щелчком колесика, если отметить значок «На один экран». Следует отметить, что чем большая скорость перемещения задана, тем труднее следить за перемещением информации при вращении колесика, поэтому начинающим пользователям лучше задавать скорость перемещения не больше, чем 3-5 строк за один щелчок при повороте колесика.

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

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

Изображение, составленное из 4-х стрелок, направленных на все четыре стороны, появляется в том случае, если окно имеет полосы прокрутки вверх-вниз и влево-вправо (то есть кроме вертикального лифта, имеется ещё и горизонтальный для перемещения в пределах окна). Правда, при использовании данного сервиса («нажать на колесико и отпустить») в редакторе MS Word появляется только изображение из 2-х стрелок для любых окон.

3. После этого нужно медленно передвинуть мышь вверх или вниз, влево или вправо от появившегося изображения двух или четырех стрелок, ничего больше не нажимая, ни колесико, ни левую, ни правую кнопки.
Вы увидите, что текст или изображение (видимая страница) начнет плавно перемещаться («поплывёт») в указанную с помощью мышки сторону. Причем перемещение будет происходить очень плавно и с одной и той же скоростью. Для ускорения перемещения курсор мышки нужно отодвинуть подальше от изображения двух или четырех стрелок, а для замедления, наоборот, приблизить курсор к этому изображению.
Само изображение двух или четырех стрелок не будет перемещаться по экрану, именно поэтому и рекомендуется перед началом операции установить курсор мыши в самом краю текста или страницы, чтобы изображение двух или четырех стрелок не мешало чтению информации с экрана монитора.
Таким образом, можно, например, отрегулировать скорость перемещения текста большой многостраничной книги, и затем спокойно читать текст с экрана, не трогая больше мышь, ее кнопки и ее колесико. Кстати, чтобы отключить подобный плавный режим просмотра и вернуться к обычному использованию мыши, нужно еще раз нажать и отпустить колесико, используя его как третью кнопку мыши. Получается, что как включили режим просмотра, так и выключили его.
У колёсика мышки есть ещё одно интересное свойство. Если на интернет-странице есть какая-либо ссылка, то она не всегда открывается в новой вкладке. Как же быть, если хочется и статью дочитать, и посмотреть, что скрывается за ссылкой? Надо просто подвести указатель мышки к ссылке и щелкнуть по ней при помощи колёсика мышки, после чего Вы останетесь в прежнем окне и сможете дочитать статью, пока в новом окне будет грузиться страница по ссылке, которую можно будет посмотреть позднее. Попробуйте, это очень удобно!
Отдельно следует сказать и о правой кнопке мыши. Эта кнопка позволяет выполнять так называемые контекстные операции. Под контекстом понимается набор действий, которые можно применить к выделенному объекту в данном конкретном случае. Например, выделенный (с помощью той же мышки) текст может быть скопирован в буфер обмена, удален, перемещен и т.п.
Можно проверить, что разрешено сделать с выделенной частью страницы, если подвести к этому выделенному фрагменту курсор мыши так, чтобы он находился внутри выделения, и нажать на правую кнопку. Появится так называемоеконтекстное меню (иногда его называют контексно-зависимое меню, либо меню правой кнопки мыши), выбирая из которого ту или иную операцию, можно выполнить указанные в меню действия.
Контекстное меню облегчает работу, так как позволяет выбирать из меню только то, что можно сделать в данный конкретный момент, и не заниматься поиском тех же операций, но уже в главном меню программы, расположенном, как правило, вверху окна программы. Также контекстное меню облегчает изучение и освоение программ, так как служит своего рода подсказкой пользователю о том, что он может сделать в данном конкретном случае с выделенным объектом.
Кстати, первые компьютерные программы, первые языки программирования практически не позволяли использовать контексты, так как предписывали компьютерам строгую последовательность действий без возможности выбора или отклонений от заданного алгоритма. Например, первые диалоговые программы позволяли только выводить на экран вопросы, предлагать варианты выбора ответов на эти вопросы, а потом в зависимости от ответа,«продвигались»дальше.
Теперь поговорим про возможность замены левой и правой кнопок мыши. Или о том, как настроить мышь для левши. Итак, поехали: Пуск-->Панель управления--> Мышь --> Кнопки мыши. Если поставить флажок в опции «Обменять назначение кнопок», то сразу после этого Вы, не успев моргнуть глазом, из правши «автоматически превращаетесь» в левшу: чтобы кликнуть по ОК, надо уже щёлкать правой (!) кнопкой мыши. Чтобы поменять все обратно (стать правшой), надо взять мышь в левую руку и использовать правую кнопку мыши так, как Вы раньше использовали левую кнопку мыши (когда «были правшой»). Кстати, если у Вас ноутбук и Вы пользуетесь встроенной мышью, то она таким же образом перенастраивается «под левшу».
Упражнения по компьютерной грамотности:
1) Выделите только с помощью мышки и ее левой кнопки текст из нижеследующего задания №2.
2) «Полистайте» блог «Компьютерная грамотность с Надеждой» с помощью колесика мышки. Сначала сделайте это путем вращения колесика вниз и вверх. А затем используйте режим плавной прокрутки страницы блога путем нажатия на колесико, как на третью кнопку мыши. При этом добейтесь самой медленной скорости движения страницы, насколько это у Вас получится. После этого попробуйте плавно увеличивать скорость так, чтобы установить наиболее приемлемую для вас скорость перемещения страницы с целью ее спокойного прочтения.
3) Попробуйте кликнуть при помощи колёсика мышки по ссылке в конце статьи «Разговор по мышам». Она должна открыться в новом окне.
4) Посмотрите, что Вам предложит контексное меню, если на блоге «Компьютерная грамотность» Вы выделите любую картинку или любую часть текста и щёлкните правой кнопкой мыши. Обратите внимание, есть ли разница в опциях контексного меню для картинок и для текста.
5) Попробуйте настроить мышь для левши, а потом вернуть настройки обратно на правшу.

Значение некоторых клавиш на клавиатуре
Некоторые советы по использованию клавиатуры были даны в статье "Дуэт мышки и клавиатуры". Рассмотрим значение некоторых клавиш на клавиатуре. В верхнем правом углу клавиатуры со 101-ой клавишей находятся три световых индикатора (проще говоря, лампочки):
• Caps Lock – режим прописных букв,
• Num Lock – режим блокировки цифр,
• Scroll Lock – режим блокировки прокрутки.

Включение и выключение вышеперечисленных режимов происходит путем нажатия на одноименные клавиши: Caps Lock, Num Lock (Num Lk), Scroll Lock (Scr Lk).

В ноутбуках, где количество клавиш меньше, клавиша Caps Lock находится там же, где и в 101-клавишной клавиатуре. Клавиша Num Lock находится обычно вместе с F11, а клавиша Scroll Lock – вместе с F12. Чтобы перейти в режим Num Lock или Scroll Lock, следует нажать клавишу Fn, которая находится в левом нижнем углу, и, не отпуская ее, нажать на клавишу Num Lock или Scroll Lock в зависимости от того, какой режим требуется.
Рассмотрим подробнее эти три режима.

1) Клавиша Caps Lock (в переводе «фиксация прописных букв») находится на клавиатуре слева. Если не нажимать на Caps Lock (т.е. лампочка не горит) и зайти в текстовый редактор (например, Word или Блокнот), то при вводе текста все буквы (как английские, так и русские) будут выводиться маленькими.
Если нажать наCaps Lock (лампочка, точнее, световой индикатор горит), тогда при вводе текста буквы будут выводиться прописными (большими). В этом режиме при нажатии на клавишу Shift будут выводиться строчные (маленькие) буквы (прямо противоположное действие тому, что делается в обычном режиме, когда лампочка Caps Lock не горит).
РежимCaps Lock (или режим прописных букв) удобен при вводе текста, состоящего из таких букв. Чтобы ввести одну большую букву удобнее, конечно, нажать клавишу Shift, и, не отпуская её, нажать на клавишу с изображением соответствующей буквы.
Клавиша Tab (табуляция) находится сверху над клавишей Caps Lock. При редактировании текстов Tab обычно используется для перехода к следующей позиции табуляции, то есть после нажатия на Tab курсор перемещается сразу на заданное количество позиций. В других программах ее функционал может меняться, например, Tab может выполнять переключение между полями запроса и т.п.
Клавиша Esc(Escape – «убегать, спасаться») находится выше клавиши Tabи применяется, в основном, для отмены какого-либо действия.
2) Клавиша Num Lock (в переводе «фиксация цифр») на клавиатуре находится справа. Она отвечает за работу малой цифровой клавиатуры в двух режимах: если индикатор Num Lock горит (т.е. нажали на клавишу Num Lock), тогда малая цифровая клавиатура работает в режиме ввода цифр от 0 до 9 и точки.
Если индикатор Num Lock не горит, тогда малая цифровая клавиатура работает в режиме управления курсором (стрелки вверх, вниз, вправо, влево, Home, End, PageUp, PageDown). Еще о клавише Num Lock читайте здесь.
Клавиша Delete («удаление») или Del обычно используется для удаления символов, находящихся справа от курсора. Клавиша Backspace («шаг назад») или длинная стрелка влево над клавишей Enter обычно удаляет символ, находящийся слева от курсора.
Я знаю, что некоторые пользователи при удалении символов пользуются преимущественно клавишей Delete, а некоторые отдают предпочтение клавише Backspace. Все дело в привычке.
Клавиша Insert («вставка») или Ins обычно используется для переключения между двумя режимами ввода символов:
• ввода с раздвижкой символов (режим вставки) и
• ввода с замещением ранее набранных символов, то есть новый текст вводится, при этом «старый» текст автоматически стирается (режим замены).
В редакторе MS Word 2007 режим вставки/замены по умолчанию отключен. По-видимому, это сделано специально, так как случайное нажатие на клавишу Insert приводило в более ранних версиях Word к тому, что включался режим замещения, когда старый текст удалялся, а вместо него вводился новый.
Чтобы в редакторе MS Word 2007 включить режим вставки/замены нажмите кнопку Office (круглую в левом верхнем углу). В открывшемся окне кликните кнопку "Параметры Word". Затем выберите вкладку "Дополнительно", в разделе "Параметры правки" поставьте галочку около пункта "Использовать клавишу INS для переключения режимов вставки и замены".
Как уже отмечалось выше, клавиши Home, End, PageUp, PageDown, стрелки вверх, вниз, влево и вправо называют клавишами управления курсором. Нажатие на них, как правило, приводит к перемещению курсора в необходимом направлении или к «перелистыванию» того, что находится на экране.
Нажатие на клавиши Home и End обычно перемещает курсор соответственно в начало и в конец строки.
Нажатие на клавиши PageUp («страница вверх») и PageDown («страница вниз») приводит к перелистыванию содержимого экрана, например, при редактировании документа на страницу вверх или вниз.
3) Scroll Lock (на клавиатуре сверху справа) - широко применялась в начале 80-х годов, когда не было манипулятора мышь. При включенном режиме «Scroll Lock» клавиши управления курсором выполняли функцию передвижения экрана (вверх, вниз, влево, вправо).
Когда режим Scroll Lock отключён, тогда клавиши управления курсором работают в привычном для нас режиме – изменение положения курсора (вверх, вниз, влево, вправо). Сейчас на действие этой кнопки можно посмотреть, например, в электронных таблицах Excel. Если запустить Excel и нажать Scroll Lock, тогда клавиши управления курсором будут передвигать таблицу, а не отдельную выделенную ячейку.
А вообще, клавиша Scroll Lock в разных программах может работать так, как она будет запрограммирована.

Упражнения по компьютерной грамотности:

1. Введите в текстовом редакторе русские и английские буквы при включенном индикаторе Caps Lock. Повторите то же самое, удерживая нажатой клавишу Shift. Обращаем внимание на то, какие выводятся буквы: строчные или прописные.
2. Печатаем теперь при выключенном индикаторе Caps Lock. Затем печатаем, удерживая Shift. Когда вводятся строчные, а когда прописные буквы?
3. Смотрим режим работы Num Lock. Когда малая цифровая клавиатура работает в режиме ввода цифр 0, 1, …, 9 и точки, а когда – в режиме управления курсором?
4. Скопируйте текст этого задания в текстовый редактор на своем ПК, поставьте курсор посередине текста и проверьте, как происходит удаление символов при помощи клавиши Delete и Backspase. Когда символы удаляются слева от курсора, а когда – справа от него?
5. Испытайте клавишу Insert. Если у Вас Word 2007, тогда, возможно, необходимо сначала провести необходимые настройки для включения этого режима. Поставьте курсор в середине текста, нажмите Insert и вводите текст. Что при этом происходит: вставка символов или их замена (удаление старых и на их место ввод новых символов)?
6. Можно проверить мало используемую клавишу Scroll Lock. Мышка здесь не понадобится. Заходим в электронные таблицы Excel, посередине вводим в ячейку, например, цифру 100. Нажимаем на клавишу Scroll Lock, при этом можно стрелками (вверх, вниз, влево, вправо) перемещаться по таблице. Получается клавиатурный аналог работы мышки при перемещении внутри окна Excel.
7. Посмотрите в текстовом редакторе на действие клавиш Home, End, стрелки вверх, вниз, влево, вправо в пределах двух-трех строк, а на действие PageUp, PageDown – в пределах двух или более страниц экрана.
8. В текстовый редактор скопируйте несколько строк. Поставьте курсор в начало текста, нажмите на клавишу Tab. Если все сделали правильно, то текст должен начинаться с «красной строки».

[Tic-Sakyra]

Как узнать, сколько байт в мегабайте

Для того, чтобы узнать сколько, например, байт в 1 мегабайте можно воспользоваться специальной таблицей.

Также вы можете воспользоваться конвертером.

Биты, байты, килобайты, мегабайты, гигабайты и терабайты

Можно просто сказать, что бит- это единица измерения информации. Кое-где такое определение бита и дается, но это не совсем корректное определение - потому что нет четкого определения понятия "информация". Более корректно сказать, что бит- это компьютерная буква. Компьютер знает всего две буквы: "0" и "1". Можно называть их и по другому: "ложь" и "истина", суть от этого не меняется.
Байт - это компьютерное слово. Исторически сложилось так, что в байте 8 бит. Длинна байта в 8 бит устанавливалась по простым соображениям, 7 бит - мало, а 9 бит - уже много. Вот так и получилось, что длина байта равна 8 битам.
Килобайт - в компьютерном мире очень ценятся числа, являющиеся степенью 2 (т.к. компьютер знает всего две буквы), таким образом получается, что килобайт это 2 в десятой степени или 1024 байт.
Мегабайт - это 2 в 20-ой степени или 1024 килобайт, или 1048576 байт. Я думаю, теперь вы поняли принцип и поймете, чему равны гигабайт и терабайт. Для представления реального объема можно сказать, что одну машинописную страницу текста можно закодировать примерно одним килобайтом. Только представьте, сколько таких страниц может содержать современный жесткий диск объемом 2 терабайта!

Сколько «весит» 1 байт, килобайт, мегабайт, гигабайт и т.д.?

Ниже приведен список всех общепринятых значений единиц емкости дискового пространства. Важно понимать, что не все производители и разработчики используют эти значения. Например, производитель может рассматривать гигабайт как 1000000000, а не 1073741824 байт. Мы перечислили общепринятые значения в двоичной системе исчисления объема информации.
Примечание: Все значения ниже выражены целыми числами. Это означает, что ГБ может может содержать только один компакт-диск 650 Мб, хотя в действительности 1GB может содержать 1,5753 от 650 Мб CD. Так как мы создали этот список, чтобы показать, сколько информации каждое значение может содержать в целом, десятичные доли просто игнорируются. Другими словами, вы можете вставить только один полный 650 Мб CD на 1 ГБ диска, так как два полных диска 650MB будут превышать 1 Гб.

Бит
Бит — наименьшая единица информации, имеющая значение 0 или 1.
Байт
Байт равен 8 битам.
Килобайт (KB)
Килобайт равен 1024 байт.
Мегабайт (MB)
Мегабайт 1048576 байт или 1024 килобайт
873 страницы текста (1200 знаков)
4 книги (200 страниц или 240 000 символов)
Гигабайт(GB)
Гигабайт равен 1 073 741 824 (230) байт, 1024 мегабайта или 1048576 килобайт.
894784 страницы текста (1200 знаков)
4473 книги (200 страниц или 240 000 символов)
341 цифровая фотография (средний размер файла — 3 МБ)
256 MP3 аудио-файлов (средний размер файла — 4 МБ)
1 CD — 650 Мб
Терабайт(Т
Терабайт равен 1 099 511 627 776 (240) байт, 1024 гигабайт, или 1048576 мегабайт.
916 259 689 страниц текста (1200 знаков)
4581298 книг (200 страниц или 240 000 символов)
349 525 цифровых фотографий (средний размер файла — 3 МБ)
262144 MP3 аудио-файла (средний размер файла — 4 МБ)
1613 компакт-дисков по 650 Мб
233 DVD-диска по 4.38GB
40 Blu-Ray дисков по 25 Гб
Петабайт(PB)
Петабайт равен 1 125 899 906 842 624 (250) байт, 1024 терабайт или 1048576 гигабайт.
938 249 922 368 страниц текста (1200 знаков)
4691249611 книг (200 страниц или 240 000 символов)
357 913 941 цифровая фотография (средний размер файла — 3 МБ)
268 435 456 MP3 аудио-файлы (средний размер файла — 4 МБ)
1651910 компакт-дисков по 650 Мб
239400 DVD-дисков по 4.38GB
41943 Blu-Ray дисков по 25 Гб
Экзабайт(ЕВ)
Экзабайт равен 1 152 921 504 606 846 976 (260) байт, 1024 петабайт, или 1048576 терабайт.
960 767 920 505 705 страниц текста (1200 знаков)
4 803 839 602 528 книги (200 страниц или 240 000 символов)
366 503 875 925 цифровых фотографий (средний размер файла — 3 МБ)
274 877 906 944 MP3 аудио-файлов (средний размер файла — 4 МБ)
1691556350 компакт-дисков по 650 Мб
245146535 DVD-дисков по 4.38GB
42949672 Blu-Ray дисков по 25 Гб
Зеттабайт(ZB)
Зеттабайт равен 1 180 591 620 717 411 303 424 (270) байт, 1024 эксабайт, или 1048576 петабайт.
983 826 350 597 842 752 страницы текста (1200 знаков)
4 919 131 752 989 213 книг (200 страниц или 240 000 символов)
375 299 968 947 541 цифровая фотография (средний размер файла — 3 МБ)
281 474 976 710 656 аудиофайлов в формате MP3 (средний размер файла — 4 МБ)
1 732 153 702 834 компакт-дисков по 650 Мб
251 030 052 003 DVD-диска по 4.38GB
43 980 465 111 Blu-Ray дисков по 25 Гб
Йоттабайт(YB)
Йоттабайт равен 1,208,925,819,614,629,174,706,176 (280) байт, 1024 Zettabytes или 1048576 эксабайт.
1 007 438 183 012 190 978 921 страниц текста (1200 знаков)
5 037 190 915 060 954 894 книги (200 страниц или 240 000 символов)
384 307 168 202 282 325 цифровых фотографий (средний размер файла — 3 МБ)
288 230 376 151 711 744 аудиофайла в формате MP3 (средний размер файла — 4 МБ)
1 773 725 391 702 841 компакт-диск по 650 Мб
257 054 773 251 740 DVD-дисков по 4.38GB
45 035 996 273 704 Blu-Ray диска по 25 Гб

[Tic-Sakyra]

Обеспечение безопасности данных.

Обеспечение безопасности данных.

1. Введение

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

2. Теоретическая часть
2.1. Основные причины защиты информации.

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

Несанкционированный доступ извне, копирование или изменение информации случайные или умышленные действия, приводящие к :

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

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

• ошибок в прикладном или сетевом ПО;
• заражения систем компьютерными вирусами.

Технические сбои оборудования, вызванные:

• отключением электропитания;
• отказом дисковых систем и систем архивации данных;
• нарушением работы серверов, рабочих станций, сетевых карт, модемов.

Ошибки обслуживающего персонала.

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

2.2. Средства для мониторинга сетей.

Средства для мониторинга сети и обнаружения в её работе “узких мест” можно разделить на два основных класса:
• стратегические;
• тактические.

Назначение стратегических средств состоит в контроле за широким спектром параметров функционирования всей сети и решении проблем конфигурирования ЛВС.
Назначение тактических средств – мониторинг и устранение неисправностей сетевых устройств и сетевого кабеля.
К стратегическим средствам относятся:

• системы управления сетью
• встроенные системы диагностики
• распределённые системы мониторинга
• средства диагностики операционных систем, функционирующих на больших машинах и серверах.

Наиболее полный контроль за работой, осуществляют системы управления сетью, разработанные такими фирмами, как DEC, Hewlett – Packard, IBM и AT&T. Эти системы обычно базируются на отдельном компьютере и включают системы контроля рабочих станций, кабельной системой, соединительными и другими устройствами, базой данных, содержащей контрольные параметры для сетей различных стандартов, а также разнообразную техническую документацию.
Одной из лучших разработок для управления сетью, позволяющей администратору сети получить доступ ко всем её элементам вплоть до рабочей станции, является пакет LANDesk Manager фирмы Intel, обеспечивающий с помощью различных средств мониторинг прикладных программ, инвентаризацию аппаратных и программных средств и защиту от вирусов. Этот пакет обеспечивает в реальном времени разнообразной информацией о прикладных программах и серверах, данные о работе в сети пользователей.
Встроенные системы диагностики стали обычной компонентой таких сетевых устройств, как мосты, репиторы и модемы. Примерами подобных систем могут служить пакеты Open – View Bridge Manager фирмы Hewlett – Packard и Remote Bridge Management Software фирмы DEC. К сожалению большая их часть ориентирована на оборудование какого – то одного производителя и практически несовместима с оборудованием других фирм.
Распределённые системы мониторинга представляют собой специальные устройства, устанавливаемые на сегменты сети и предназначенные для получения комплексной информации о трафике, а также нарушениях в работе сети. Эти устройства, обычно подключаемые к рабочей станции администратора, в основном используются в много сегментных сетях.
К тактическим средствам относят различные виды тестирующих устройств ( тестеры и сканеры сетевого кабеля ), а также устройства для комплексного анализа работы сети – анализаторы протоколов. Тестирующие устройства помогают администратору обнаружить неисправности сетевого кабеля и разъёмов, а анализаторы протоколов – получать информацию об обмене данными в сети. Кроме того, к этой категории средств относят специальное ПО, позволяющее в режиме реального времени получать подробные отчёты о состоянии работы сети.

2.3. Надёжность работы кабельной системы

По данным зарубежных исследований, с неисправностями сетевого кабеля и соединительных разъёмов связано почти 2/3 всех отказов в работе сети. К неисправностям кабельной системы приводят обрывы кабеля, короткое замыкание и физическое повреждение соединительных устройств. Большие неприятности могут доставлять электромагнитные наводки различного происхождения, например, от излучения бытовых электроприборов, стартеров ламп дневного света и т. д.
Основными электрическими характеристиками кабеля, определяющими его работу, является затухание, импеданс и перекрёстные наводки. Эти характеристики позволяют определить простые и вместе с тем достаточно универсальные приборы, предназначенные для установления не только причины, но и места повреждения кабельной системы – сканеры сетевого кабеля. Сканер посылает в кабель серию коротких электрических импульсов и для каждого импульса измеряет время от подачи импульса до прихода отражённого сигнала и его фазу. По фазе отражённого импульса определяется характер повреждения кабеля ( короткое замыкание или обрыв). А по времени задержки – расстояние до места повреждения. Если кабель не повреждён, то отражённый импульс отсутствует. Современные сканеры содержат данные о номинальных параметрах распространения сигнала для сетевых кабелей различных типов, позволяют пользователю самостоятельно устанавливать такого рода параметры, а также выводить результаты тестирования на принтер.
На рынке сетевых сканеров в настоящее время предлагается много устройств, различных по своим техническим характеристикам, точности измерений и цене. Среди них сканер Fuke 650 LAN CableMeter компании John Fuke Manufacturing, семейство сканеров фирмы Microtest, тестеры LANTech 10 корпорации Wavetek. WireScope 16 фирмы Scope Communications Inc., а также сканеры фирмы Datacom.
Наиболее универсальными являются сканеры фирмы Microtest, с помощью которых можно тестировать основные виды сетевых кабелей следующих стандартов:

• IEEE 802,3 Ethernet (10BASE – 5 – толстый кабель, 10BASE – 2 – тонкий кабель, 10BASE – Т – витая пара);
• IEEE 802,4 Arcnet;
• IEEE 802,5 Token Ring/

Кроме того, их можно применять и для тестирования оптоволоконных сетевых кабелей.
Все сканеры этого семейства оборудованы автономными источниками питания и малогабаритны (не больше видеокассеты), что делает их высокомобильными. Дополнительно поставляется набор аксессуаров, который обеспечивает совместимость этих сканеров с любыми типами сетей и разъёмов.
Надёжность кабельной системы зависит и от качества самого сетевого кабеля. В соответствия с международным стандартом ANSI/EIA/TIA – 568 в современных ЛВС, как правило, используют сетевые кабели трёх уровней: третьего, четвёртого и пятого. ( Кабель уровня 1 представляет собой обычный телефонный кабель, кабель уровня 2 используется для передачи малых объёмов данных с небольшой скоростью.) Основные электрические характеристики кабелей уровней 3-5 представлены в таблице:
Стандартные электромагнитные параметры для кабелей уровня 3-5.