Читать онлайн «Программное обеспечение и его разработка». Страница 48

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

Проект отвечает на вопрос КАК; требования отвечают на вопрос ЧТО.

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

С одной точки зрения некоторая вещь кажется проектом; с другой — она же кажется требованием, (см. рис. 5.30.)

Если уж слово «автомобиль» может быть и требованием, и проектом, то и подавно документ в 100 страниц может быть и проектом и требованием.

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

В нашем распоряжении имеется чересчур много новых методов проектирования. Многие из этих методов являются в сущности методами записи, а не ведения процесса. Они достаточно ценны, поскольку любая помощь при проектировании только приветствуется. У них множество имен: метод Вернера — Орра и Джексона, метод HIPO, SADT (технология структурного анализа и проектирования), IA (информационный анализ), структурное проектирование — все они лучше, чем отсутствие какого-либо формализма при проектировании. Все они большей частью связаны с документированием и демонстрацией проекта, чем с его созданием, причем в значительной степени это относится к последним двум стадиям — структуризации и представлению, чем к первой — созданию.

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

С чего начинать — с данных или с процесса, — зависит от прикладной области или от проектируемой системы: что в данном случае имеет превалирующее значение. В больших системах типа III это данные, поэтому проектирование нужно начинать с них. Большие системы типов IV и V, вероятнее всего, следует начинать с проектирования процесса.

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

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

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

Как и всякая новая человеческая деятельность, новые методы проектирования оказываются тоже очень трудными для введения. Изменениям сопротивляются; правила раздражают; строгости кажутся бесполезными. Но это бывает только в начале. Как и многие другие полезные новые методы, эти методы в конце концов признаются «единственно возможными», а на все старые при этом начинают смотреть с изумлением и весьма критически.

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

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

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

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

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

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

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

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

Важнейшие моменты, связанные с написанием текста программ, таковы:

1. Ясность того, что нужно сделать — это мы уже обсуждали.