Текст книги "Программное обеспечение и его разработка"

Автор книги: Джозеф Фокс

сообщить о нарушении

Текущая страница: 13 (всего у книги 21 страниц)

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

Рис. 5.36. Разные формы существования письма.

Рис. 5.37. Разные способы существования программы.

Во время работы по заказу военно-морского флота, проводившейся на Западном побережье, мои 40 программистов сделали очень мало, основной причиной чего была недостаточно большая и недостаточно комплектная инструментальная машина IBM 370. Программы писались для выполнения на машине фирмы Sperry UNIVAC UYK20, а трансляция проводилась на IBM 370/138. Дело оказалось не только в том, что эта машина слишком мала (ее мощности явно не хватало), но также и в том, что на ней имелся всего один канал, а, значит, возможности ввода/вывода были сильно ограничены. Нам пришлось переходить на машину модели 148, на которой было больше каналов. Наша группа плохо произвела выбор инструментальной ЭВМ.

Однажды в Европе меня познакомили с разработкой системы, состоявшей из программ в 1 млн. операторов на Коболе. Программы, входившие в систему, были слишком велики, чтобы из них можно было составить хорошую модульную систему. «Почему так?» – спросил я. По той причине, что в вычислительную машину, использовавшуюся для компиляции, было слишком тяжело вводить отдельные задачи. Это привело к тому, что проект обеспечения времени использования был изменен таким образом, чтобы уменьшилось время, необходимое на трансляцию. Трансляция одного большого модуля занимала меньше времени, чем трансляция нескольких модулей меньших размеров, выполнявших все те же функции.

Программирование в диалоговом режиме

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

Но это далеко не так. Логично предположить, что предоставление терминалов всем программистам увеличит их производительность, но доказательств этому пока нет. К тому же терминалы стоят денег. На основе базы данных по производительности, созданной в отделении федеральных систем IBM, «кажется», можно прийти именно к такому выводу, но люди, изучавшие этот вопрос, не хотят делать такого заключения.

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

С чем же мы ведем диалог?

Давайте предположим, что я вошел в машинный зал и подошел к вычислительной машине. Никто мне ничего о машине не рассказывал, но я с радостью увидел, что это DEC 11/70, с которой я знаком, поскольку уже работал с ней. Я вижу, что машина включена и готова к использованию.

Возникает вопрос: пуста ли машина, ждет ли она самой первой команды? А есть ли в ней транслятор? Или операционная система?

В зависимости от ответов на эти вопросы я буду выдавать машине совершенно разные команды.

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

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

Если в машине находится транслятор, я должен вводить операторы языка высокого уровня.

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

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

В памяти вычислительной машины могут находиться или отсутствовать такие системы программ:

1) операционная система;

2) система управления базой данных;

3) система связи;

4) система управления дисплеями;

5) ассемблер (транслятор);

6) транслятор с ЯВУ;

7) прикладные программы.

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

Рис. 5.38. Взаимодействие с программой для вычислительной машины.

Рис. 5.39. Возможности ведения диалога с вычислительной машиной и программным обеспечением.

Очевидно, что по мере добавления различных программ и установления связи с ними мы получаем огромное число разных возможностей для ведения диалога. На рис. 5.39 изображены только некоторые способы связи программиста или пользователя с аппаратурой!

Если я нахожусь в точке A, я пишу на языке машины.

В точке В я использую язык ассемблера.

В точке С я использую язык транслятора.

В точке D я использую приказы операционной системы.

В точке Е я использую язык базы данных.

В точке F я использую язык системы связи.

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

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

Буквы со штрихами (E', F' и т. д.) обозначают не программистов, а пользователей. Обратите внимание на то, что их первое вхождение в вычислительную систему (аппаратура плюс программное обеспечение) осуществляется через прикладные программы. Пользователь вводит данные для прикладных программ, а результатом при этом будет не программа на машинном языке, а ответ ему либо несколько ответов.

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

Точка / является хотя и необычной, но не такой уж редкой ситуацией. Используются сразу все слои программного обеспечения. Такой случай возникает, когда мне приходится из одного города вести диалог через диалоговый транслятор с вычислительной машиной, находящейся в другом городе. Вариант К (без использования уровня ЯВУ) встречается очень часто.

Управление написанием программ

Из-за чрезвычайной гибкости запоминаемых программ программирование стало очень трудным делом; одна и та же задача может быть запрограммирована сотней разных способов, ответ будет один и тот же. Все варианты будут работать, все дают одинаковые ответы! Может ли один быть лучше другого? Может, причем по-разному. Один быстрее выполняется. Другой требует меньше памяти. Мой вариант, возможно, был запрограммирован быстрее, чем ваш. То, что ваше решение «работает быстрее», компенсируется тем, что вы дольше писали вашу программу.

Число различных последовательностей команд почти беспредельно, ведь в своей работе программист связывает воедино множество шагов, которые он предпринимает, чтобы решить задачу. Кто может сказать что-нибудь о правильности или хотя бы о работоспособности программы до тех пор, пока она не будет опробована? До тех пор, пока программа не будет выполнена на вычислительной машине?

Очень трудно управлять чьей-нибудь работой и быть уверенным, что у него все в порядке, если число вариантов, которые тот может предложить, практически неограниченно.

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

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

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

Различия уровня квалификации программистов

Изучение программирования «в малом», т. е. небольших программ, показывает просто фантастическое различие в производительности и конечных результатах работы среди программистов. Различие в производительности, выраженной в строках программы в единицу времени, достигает 25 раз. Это означает, что некоторые люди пишут в день в 25 раз больше строк программ, чем другие. Размеры получающихся программ также отличаются, коэффициент доходит до 20; программы одних программистов могут быть в 20 раз больше программ других. Эффективность программ изменяется в диапазоне от 1 до 10; одни программы работают в 10 раз быстрее, чем другие, выполняющие ту же работу.

Однако совершенно не обязательно будет так, что программист, пишущий в 25 раз быстрее другого, будет хорошим программистом. Строки программы – это обманчивое, несовершенное средство измерения качества. Но это все, что у нас есть. Более или менее подробно мы будем изучать эту меру в гл.6. Здесь мы хотели только указать, что среди программистов имеются значительные различия.

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

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

Главный программист

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

Очень многое зависит от работы, которую надо выполнить, от программиста, которому она поручена, времени, за которое нужно ее сделать, а также от тех средств, которые можно использовать при написании программ. В проекте системы для газеты «Нью-Йорк таймс» один программист, Т. Бейкер, за 22 мес. создал работающую программную систему, состоящую из 83 тыс. операторов на языке высокого уровня. Этим успехом мы обязаны тому, что в работе был применен метод X. Милса под названием «Группа главного программиста». Бейкер работал так, как работает хирург вовремя операции. Ему помогал библиотекарь, выполняющий все канцелярские дела, включая черную работу по отправке программ на вычислительную машину для проведения трансляции. Инструментальные средства, необходимые Бейкеру, поддерживались в нужном порядке кем-то еще. Один помощник проверял программы Бейкера и давал ему советы.

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

Метод главного программиста прекрасно проявил себя в проекте для «Нью-Йорк таймс» и еще в нескольких проектах после него. Но у этого метода есть один недостаток. Главный программист может проделать такой объем работы, только если он в шесть – десять раз превышает средний объем. Этот метод тем не менее не подходит для больших проектов, программы которых составляют сотни тысяч строк программного текста.

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

Из-за того что метод главного программиста был впервые применен в проекте «Нью-Йорк таймс», многие решили, что он является частью структурного программирования. Это не так!

Некоторые утверждали, что работы для «Нью-Йорк таймс» кончились неудачно. Но это не так. Мы (фирма IBM) сэкономили около 700 тыс. долларов, а система работала. Первое время в редакции «Нью-Йорк таймс» было слишком мало людей, которые имели опыт работы с системой. По мере подключения сотрудников газеты к работе в системе начались обычные проблемы перехода, которые всегда возникают при перекладывании ответственности за систему с группы разработчиков на группу сопровождения. Эти нормальные трудности были кое-кем неправильно истолкованы с целью бросить тень на великолепные результаты, полученные благодаря структурному программированию и использованию метода главного программиста.

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

Библиотекарь

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

Рис. 5.40 Работа над проектом с помощью библиотеки и библиотекарей.

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

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

Теперь руководитель работ может просмотреть легко читаемые, структурированные программы, которые вводятся в машину, и увидеть, сколько попыток сделал программист Джонс, чтобы получить работающую программу. Из частного дела программирование превращается в общественное.

«Библиотека» не имеет никакого отношения к библиотекарю. Библиотека – это собрание программ, обычно вспомогательных, которые могут найти применение в любое время.

Некоторые неправильно считают использование библиотекаря частью методики структурного программирования. Это разные понятия и методы.

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

Компоновка программ

Сборка большого числа модулей в одну работающую систему программного обеспечения

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

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

Шесть фаз, выделенные нами в разработке программ, таковы:

Определение требований

Проектирование

Написание команд, программирование

Компоновка

Тестирование, или верификация

Документирование

Если нам нужна единственная, выполняемая сама по себе программа, фаза компоновки будет отсутствовать.

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

Эти средства жестко связаны с выбранным ранее языком программирования, а иногда и с операционной системой, но все же стоят особняком от них.

Например, с языком программирования Ада, который, видимо, будет стандартизован министерством обороны, связан большой набор программ сопровождения, составляющих некоторое «окружение», которое могут использовать разработчики программного обеспечения для компоновки длинных цепочек программ[30]30
  Мягко выражаясь, это утверждение не совсем верно (а точнее, совсем неверно). – Прим. ред.


[Закрыть]. Это окружение носит название APSE (Ada Programming Support Environment – окружение сопровождения программирования на языке Ада), в сам язык встроены специфические конструкции и описатели, позволяющие обращаться к элементам окружения.

Между языком и его окружением в этом случае есть тонкое различие. Это различие весьма существенно. Если мне не надо вставлять программу в большую систему, я могу пользоваться только языком, не обращаясь к его окружению. Мне, следовательно, может понадобиться только транслятор, и я потребую, чтобы этот транслятор мог работать отдельно от всего окружения.

Следует ли проводить компоновку перед тестированием?

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

Средства обслуживания руководства

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

Мы уже видели, как они оказывают помощь при программировании. Теперь посмотрим на то, как они могут помочь руководству.

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

1) взаимодействие;

2) распределение данных;

3) объединение;

4) выполнение собранных «кусков»;

5) отслеживание номеров версий и модулей.

Взаимодействие. Слово «заменимый» обозначает всем известное явление. Если я покупаю скобы к сшивателю бумаг, то, естественно, ожидаю, что смогу ими пользоваться. Это удается всегда. Удается потому, что их размеры, конструкция, форма, материал, вес и упаковка удовлетворяют некоторым стандартам. Такие скобы производят многие фирмы. Полная взаимозаменяемость скоб констатируется словами: «Скобы заменяемы». Взаимозаменяемы.

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

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

Автоматическая компоновка – объединение. Мы проектируем модули таким образом, чтобы их объединение проходило как можно легче и понятнее. Это дает нам возможность заменять ручной труд трудом автоматизированным с использованием программ, которые будут объединять модули автоматически. Раз наши правила ясны, объединение будет несложным делом. Процесс объединения имеет множество наименований:

Редактирование связей

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

Интеграция

Объединение

Связывание

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

Выполнение собранных частей. Здесь мы снова сталкиваемся с мощными новыми средствами. В прошлом на многих существующих в настоящее время вычислительных машинах группы программного обеспечения вручную управляли системой программирования. Если у нас сотни модулей, такая работа отнимает больше всего времени.

Рис. 5.41. Автоматическое управление версиями системы.

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

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

Автоматическое использование инструментальных средств

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

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

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

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

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

Рис. 5.42. Процесс, методика, инструментальные средства.

Выбор трансляторов и языков

В основании выбора транслятора лежит выбор двух типов проводимой нами оптимизации, мы оптимизируем:

1) либо использование транслятора (время трансляции),

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

Рис 5.43. Что оптимизировать при трансляции – использование или разработку?

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

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

Язык I (на рис. 5.44) оптимален в фазе разработки; язык II – в фазе сопровождения, но за счет времени первичной разработки.

Рис. 5.44. Выбор языка программирования

Рис. 5.45. Выбор языка программирования и последующий выбор транслятора.

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

Реализация сверху вниз

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

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

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

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

Окружение разработки программного обеспечения

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

1) мощная вычислительная машина, на которой проходит разработка;

2) мощный и стабильный комплект программ, помогающий при программировании;

3) хорошая группа людей, составляющая и сопровождающая программы;

4) мощный набор программ, помогающих управлять разработкой.

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

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

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

Пользователь должен иметь возможность извлекать из базы данных сведения:

о доступных инструментальных средствах, о способах работы,

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

Когда транслятор обнаруживает синтаксическую или логическую ошибку, он печатает сообщение об этом. Сообщение об ошибке, выдаваемое для разработчика программы, должно:

выдаваться развернутым текстом, а не каким-нибудь кодом,

указывать неправильную лексему, объект, действие пользователя,

указывать контекст, в котором обнаружена ошибка.

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

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

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

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