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