Члены ostream
В классе ostream есть лишь несколько функций для управления выводом,большая часть таких функций находится в классе ios. class ostream: public virtual ios { //... public: ostream& flush(); ostream& seekp(streampos); ostream& seekp(streamoff, seek_dir); streampos tellp(); //... }; Как мы уже говорили, функция flush() опустошает буфер в выходной поток.Остальные функции используются для позиционирования в ostream призаписи. Окончание на букву p указывает, что именно позиция используетсяпри выдаче символов в заданный поток. Конечно эти функции имеют смысл,только если поток присоединен к чему-либо, что допускаетпозиционирование, например файл. Тип streampos представляет позицию символав файле, а тип streamoff представляет смещение относительно позиции,заданной seek_dir. Все они определены в классе ios: class ios { //... enum seek_dir { beg=0, // от начала файла cur=1, // от текущей позиции в файле end=2 // от конца файла }; //... }; Позиции в потоке отсчитываются от 0, как если бы файл был массивом изn символов: char file[n-1]; и если fout присоединено к file, то fout.seek(10); fout<<'#'; поместит # в file[10].Члены istream
Файлы и потоки
Ниже приведена программа копирования одного файла в другой. Именафайлов берутся из командной строки программы: #include <fstream.h> #include <libc.h> void error(char* s, char* s2 ="") { cerr << s << ' ' << s2 << '\n'; exit(1); } int main(int argc, char* argv[]) { if (argc!= 3) error("wrong number of arguments"); ifstream from(argv[1]); if (!from) error("cannot open input file",argv[1]); ostream to(argv[2]); if (!to) error("cannot open output file",argv[2]); char ch; while (from.get(ch)) to.put(ch); if (!from.eof() || to.bad()) error("something strange happened"); return 0; } Для открытия выходного файла создается объект класса ofstream -выходной поток файла, использующий в качестве аргумента имя файла.Аналогично, для открытия входного файла создается объект классаifstream - входной файловый поток, также использующий в качествеаргумента имя файла. В обоих случаях следует проверить состояниесозданного объекта, чтобы убедиться в успешном открытии файла, аесли это не так, операции завершатся не успешно, но корректно. По умолчанию ifstream всегда открывается на чтение, а ofstreamоткрывается на запись. В ostream и в istream можно использоватьнеобязательный второй аргумент, указывающий иные режимы открытия: class ios { public: //... enum open_mode { in=1, // открыть на чтение out=2, // открыть как выходной ate=4, // открыть и переместиться в конец файла app=010, // добавить trunc=020, // сократить файл до нулевой длины nocreate=040, // неудача, если файл не существует noreplace=0100 // неудача, если файл существует }; //... }; Настоящие значения для open_mode и их смысл вероятно будут зависетьот реализации. Будьте добры, за деталями обратитесь к руководству повашей библиотеке или экспериментируйте. Приведенные комментариимогут прояснить их назначение. Например, можно открыть файл с условием,что операция открытия не выполнится, если файл уже не существует: void f() { ofstream mystream(name,ios::out|ios::nocreate); if (ofstream.bad()) { //... } //... } Также можно открыть файл сразу на чтение и запись: fstream dictionary("concordance", ios::in|ios::out); Все операции, допустимые для ostream и ostream, можно применять кfstream. На самом деле, класс fstream является производным от iostream,который является, в свою очередь, производным от istream и ostream.Причина, по которой информация по буферизации и форматированию дляostream и istream находится в виртуальном базовом классе ios, в том,чтобы заставить действовать всю эту последовательность производныхклассов. По этой же причине операции позиционирования в istream иostream имеют разные имена - seekp() и seekg(). В iostream естьотдельные позиции для чтения и записи.Закрытие потоков
Строковые потоки
Как было показано, поток может быть привязан к файлу, т.е. массивусимволов, хранящемуся не в основной памяти, а, например, на диске. Точнотак же поток можно привязать к массиву символов в основной памяти.Например, можно воспользоваться выходным строковым потоком ostrstreamдля форматирования сообщений, не подлежащих немедленной печати: char* p = new char[message_size]; ostrstream ost(p,message_size); do_something(arguments,ost); display(p); С помощью стандартных операций вывода функция do_something может писатьв поток ost, передавать ost подчиняющимся ей функциям и т.п. Контрольпереполнения не нужен, поскольку ost знает свой размер и при заполненииперейдет в состояние, определяемое fail(). Затем функция display можетпослать сообщение в "настоящий" выходной поток. Такой прием наиболееподходит в тех случаях, когда окончательная операция выводапредназначена для записи на более сложное устройство, чем традиционное,ориентированное на последовательность строк, выводное устройство.Например, текст из ost может быть помещен в фиксированную область на экране. Аналогично, istrstream является вводным строковым потоком,читающим из последовательности символов, заканчивающейся нулем: void word_per_line(char v[], int sz) /* печатать "v" размером "sz" по одному слову в строке */ { istrstream ist(v,sz); // создать istream для v char b2[MAX]; // длиннее самого длинного слова while (ist>>b2) cout <<b2 << "\n"; } Завершающий нуль считается концом файла. Строковые потоки описаны в файле <strstream.h>.Буферизация
Все операции ввода-вывода были определены без всякой связи с типомфайла, но нельзя одинаково работать со всеми устройствами без учетаалгоритма буферизации. Очевидно, что потоку ostream, привязанному кстроке символов, нужен не такой буфер, как ostream, привязанному кфайлу. Такие вопросы решаются созданием во время инициализации разныхбуферов для потоков разных типов. Но существует только один наборопераций над этими типами буферов, поэтому в ostream нет функций, кодкоторых учитывает различие буферов. Однако, функции, следящие запереполнением и обращением к пустому буферу, являются виртуальными.Это хороший пример применения виртуальных функций для единообразнойработы с эквивалентными логически, но различно реализованнымиструктурами, и они вполне справляются с требуемыми алгоритмами буферизации.Описание буфера потока в файле <iostream.h> может выглядеть следующимобразом: class streambuf { // управление буфером потока protected: char* base; // начало буфера char* pptr; // следующий свободный байт char* gptr; // следующий заполненный байт char* eptr; // один из указателей на конец буфера char alloc; // буфер, размещенный с помощью "new" //... // Опустошить буфер: // Вернуть EOF при ошибке, 0 - удача virtual int overflow(int c = EOF); // Заполнить буфер: // Вернуть EOF в случае ошибки или конца входного потока, // иначе вернуть очередной символ virtual int underflow(); //... public: streambuf(); streambuf(char* p, int l); virtual ~streambuf(); int snextc() // получить очередной символ { return (++gptr==pptr)? underflow(): *gptr&0377; } int allocate(); // отвести память под буфер //... }; Подробности реализации класса streambuf приведены здесь только дляполноты представления. Не предполагается, что есть общедоступныереализации, использующие именно эти имена. Обратите внимание наопределенные здесь указатели, управляющие буфером; с их помощьюпростые посимвольные операции с потоком можно определить максимальноэффективно (и причем однократно) как функции-подстановки. Толькофункции overflow() и underflow() требует своей реализации для каждогоалгоритма буферизации, например: class filebuf: public streambuf { protected: int fd; // дескриптор файла char opened; // признак открытия файла public: filebuf() { opened = 0; } filebuf(int nfd, char* p, int l): streambuf(p,l) { /*... */ } ~filebuf() { close(); } int overflow(int c=EOF); int underflow(); filebuf* open(char *name, ios::open_mode om); int close() { /*... */ } //... }; int filebuf::underflow() // заполнить буфер из "fd" { if (!opened || allocate()==EOF) return EOF; int count = read(fd, base, eptr-base); if (count < 1) return EOF; gptr = base; pptr = base + count; return *gptr & 0377; // &0377 предотвращает размножение знака } За дальнейшими подробностями обратитесь к руководству по реализациикласса streambuf.Ввод-вывод в С
Поскольку текст программ на С и на С++ часто путают, то путают иногдаи потоковый ввод-вывод С++ и функции ввода-вывода семейства printf дляязыка С. Далее, т.к. С-функции можно вызывать из программы на С++, томногие предпочитают использовать более знакомые функции ввода-вывода С. По этой причине здесь будет дана основа функций ввода-вывода С.Обычно операции ввода-вывода на С и на С++ могут идти по очереди науровне строк. Перемешивание их на уровне посимвольного ввода-выводавозможно для некоторых реализаций, но такая программа может бытьнепереносимой. Некоторые реализации потоковой библиотеки С++ при допущенииввода-вывода на С требуют вызова статической функции-членаios::sync_with_stdio(). В общем, потоковые функции вывода имеют перед стандартнойфункцией С printf() то преимущество, что потоковые функции обладаютопределенной типовой надежностью и единообразно определяют выводобъектов предопределенного и пользовательского типов. Основная функция вывода С есть int printf(const char* format,...) и она выводит произвольную последовательность параметров в формате,задаваемом строкой форматирования format. Строка форматирования состоитиз объектов двух типов: простые символы, которые просто копируются ввыходной поток, и спецификации преобразований, каждая из которыхпреобразует и печатает очередной параметр. Каждая спецификацияпреобразования начинается с символа %, например printf("there were %d members present.",no_of_members); Здесь %d указывает, что no_of_members следует считать целым и печататькак соответствующую последовательность десятичных цифр. Еслиno_of_members==127, то будет напечатано there were 127 members present. Набор спецификаций преобразований достаточно большой и обеспечиваетбольшую гибкость печати. За символом % может следовать:- необязательный знак минус, задающий выравнивание влево в указанном поле для преобразованного значения;d необязательная строка цифр, задающая ширину поля; если в преобразованном значении меньше символов, чем ширина строки, то оно дополнится до ширины поля пробелами слева (или справа, если дана спецификация выравнивания влево); если строка ширины поля начинается с нуля, то дополнение будет проводится нулями, а не пробелами;. необязательный символ точка служит для отделения ширины поля от последующей строки цифр;d необязательная строка цифр, задающая точность, которая определяет число цифр после десятичной точки для значений в спецификациях e или f, или же задает максимальное число печатаемых символов строки;* для задания ширины поля или точности может использоваться * вместо строки цифр. В этом случае должен быть параметр целого типа, который содержит значение ширины поля или точности;h необязательный символ h указывает, что последующая спецификация d, o, x или u относится к параметру типа короткое целое;l необязательный символ l указывает, что последующая спецификация d, o, x или u относится к параметру типа длинное целое;% обозначает, что нужно напечатать сам символ %; параметр не нужен;c символ, указывающий тип требуемого преобразования. Символы преобразования и их смысл следующие: d Целый параметр выдается в десятичной записи; o Целый параметр выдается в восьмеричной записи; x Целый параметр выдается в шестнадцатеричной записи; f Вещественный или с двойной точностью параметр выдается в десятичной записи вида [-]ddd.ddd, где число цифр после точки равно спецификации точности для параметра. Если точность не задана, печатается шесть цифр; если явно задана точность 0, точка и цифры после нее не печатаются; e Вещественный или с двойной точностью параметр выдается в десятичной записи вида [-]d.ddde+dd; здесь одна цифра перед точкой, а число цифр после точки равно спецификации точности для параметра; если она не задана печатается шесть цифр; g Вещественный или с двойной точностью параметр печатается по той спецификации d, f или e, которая дает большую точность при меньшей ширине поля; c Символьный параметр печатается. Нулевые символы игнорируются; s Параметр считается строкой (символьный указатель), и печатаются символы из строки до нулевого символа или до достижения числа символов, равного спецификации точности; но, если точность равна 0 или не указана, печатаются все символы до нулевого; p Параметр считается указателем и его вид на печати зависит от реализации; u Беззнаковый целый параметр печатается в десятичной записи.Несуществующее поле или поле с шириной, меньшей реальной, приведетк усечению поля. Дополнение пробелами происходит, если толькоспецификация ширины поля больше реальной ширины.Ниже приведен более сложный пример: char* src_file_name; int line; char* line_format = "\n#line %d \"%s\"\n"; main() { line = 13; src_file_name = "C++/main.c"; printf("int a;\n"); printf(line_format,line,src_file_name); printf("int b;\n"); } в котором печатается int a; #line 13 "C++/main.c" int b; Использование printf() ненадежно в том смысле, что нет никакогоконтроля типов. Так, ниже приведен известный способ получениянеожиданного результата - печати мусорного значения или чего похуже: char x; //... printf("bad input char: %s",x); Однако, эти функции обеспечивают большую гибкость и знакомыпрограммирующим на С. Как обычно, getchar() позволяет знакомым способом читать символы извходного потока: int i;: while ((i=getchar())!=EOF) { // символьный ввод C // используем i } Обратите внимание: чтобы было законным сравнение с величиной EOF типаint при проверке на конец файла, результат getchar() надо помещать впеременную типа int, а не char. За подробностями о вводе-выводе на С отсылаем к вашему руководствупо С или книге Кернигана и Ритчи "Язык программирования С".Упражнения
1. (*1.5) Читая файл вещественных чисел, составлять из пар прочитанных чисел комплексные числа, записать комплексные числа.2. (*1.5) Определить тип name_and_address (тип_и_адрес). Определить для него << и >>. Написать программу копирования объектов потока name_and_address.3. (*2) Разработать несколько функций для запроса и чтения данных разных типов. Предложения: целое, вещественное число, имя файла, почтовый адрес, дата, личная информация, и т.п. Попытайтесь сделать их устойчивыми к ошибкам.4. (*1.5) Напишите программу, которая печатает: (1) строчные буквы, (2) все буквы, (3) все буквы и цифры, (4) все символы, входящие в идентификатор в вашей версии С++, (5) все знаки пунктуации, (6) целые значения всех управляющих символов, (7) все обобщенные пробелы, (8) целые значения всех обобщенных пробелов, и, наконец, (9) все изображаемые символы.5. (*4) Реализуйте стандартную библиотеку ввода-вывода С (<stdio.h>) с помощью стандартной библиотеки ввода-вывода С++ (<iostream.h>).6. (*4) Реализуйте стандартную библиотеку ввода-вывода С++ (<iostream.h>) с помощью стандартной библиотеки ввода-вывода С (<stdio.h>).7. (*4) Реализуйте библиотеки С и С++ так, чтобы их можно было использовать одновременно.8. (*2) Реализуйте класс, для которого операция [] перегружена так, чтобы обеспечить произвольное чтение символов из файла.9. (*3) Повторите упражнение 8, но добейтесь, чтобы операция [] была применима для чтения и для записи. Подсказка: пусть [] возвращает объект "дескриптор типа", для которого присваивание означает: присвоить через дескриптор файлу, а неявное приведение к типу char означает чтение файла по дескриптору.10.(*2) Повторите упражнение 9, позволяя операции [] индексировать объекты произвольных типов, а не только символы.11.(*3.5) Продумайте и реализуйте операцию форматного ввода. Используйте для задания формата строку спецификаций как в printf(). Должна быть возможность попыток применения нескольких спецификаций для одного ввода, чтобы найти требуемый формат. Класс форматного ввода должен быть производным класса istream.12.(*4) Придумайте (и реализуйте) лучшие форматы ввода.13.(**2) Определите для вывода манипулятор based с двумя параметрами: система счисления и целое значение, и печатайте целое в представлении, определяемом системой счисления. Например, based(2,9) напечатает 1001.14.(**2) Напишите "миниатюрную" систему ввода-вывода, которая реализует классы istream, ostream, ifstream, ofstream и предоставляет функции, такие как operator<<() и operator>>() для целых, и операции, такие как open() и close() для файлов. Используйте исключительные ситуации, а не переменные состояния, для сообщения об ошибках.15.(**2) Напишите манипулятор, который включает и отключает эхо символа.* ПРОЕКТИРОВАНИЕ И РАЗВИТИЕ
"Серебряной пули не существует." - Ф. Брукс В этой главе обсуждаются подходы к разработке программного обеспечения.Обсуждение затрагивает как технические, так и социологические аспектыпроцесса развития программного обеспечения. Программа рассматриваетсякак модель реальности, в которой каждый класс представляет определенноепонятие. Ключевая задача проектирования состоит в определении доступнойи защищенной частей интерфейса класса, исходя из которых определяютсяразличные части программы. Определение этих интерфейсов естьитеративный процесс, обычно требующий экспериментирования. Упорделается на важной роли проектирования и организационных факторовв процессе развития программного обеспечения.Введение
Создание любой нетривиальной программной системы - сложная и частовыматывающая задача. Даже для отдельного программиста собственно записьоператоров программы есть только часть всей работы. Обычно анализ всейзадачи, проектирование программы в целом, документация, тестирование,сопровождение и управление всем этим затмевает задачу написания иотладки отдельных частей программы. Конечно, можно все эти видыдеятельности обозначить как "программирование" и затем вполнеобоснованно утверждать: "Я не проектирую, я только программирую".Но как бы не назывались отдельные виды деятельности, бывает иногда важнососредоточиться на них по отдельности, так же как иногда бывает важнорассмотреть весь процесс в целом. Стремясь поскорее довести системудо поставки, нельзя упускать из вида ни детали, ни картину в целом,хотя довольно часто происходит именно это.Эта глава сосредоточена на тех частях процесса развития программы,которые не связаны с написанием и отладкой отдельных программныхфрагментов. Обсуждение здесь менее точное и детальное, чем во всехостальных частях книги, где рассматриваются конкретные черты языкаили определенные приемы программирования. Это неизбежно, поскольку нетготовых рецептов создания хороших программ. Детальные рецепты "как"могут существовать только для определенных, хорошо разработанных областейприменения, но не для достаточно широких областей приложения. Впрограммировании не существует заменителей разума, опыта и вкуса.Следовательно, в этой главе вы найдете только общие рекомендации,альтернативные подходы и осторожные выводы. Сложность данной тематики связана с абстрактной природой программи тем фактом, что приемы, применимые для небольших проектов (скажем,программа в 10000 строк, созданная одним или двумя людьми), нераспространяются на средние или большие проекты. По этой причине иногдамы приводим примеры из менее абстрактных инженерных дисциплин, а нетолько из программирования. Не преминем напомнить, что "доказательство поаналогии" является мошенничеством, и аналогии служат здесь только вкачестве примера. Понятия проектирования, формулируемыес помощью определенных конструкций С++, и поясняемые примерами, мыбудем обсуждать в главах 12 и 13. Предложенные в этой главе рекомендации,отражаются как в самом языке С++, так и в решении конкретных программныхзадач по всей книге. Снова напомним, что в силу чрезвычайного разнообразия областейприменения, программистов и среды, в которой развивается программнаясистема, нельзя ожидать, что каждый вывод, сделанный здесь, будетпрямо применим для вашей задачи. Эти выводы применимыво многих самых разных случаях, но их нельзя считать универсальнымизаконами. Смотрите на них со здоровой долей скептицизма. Язык С++ можно просто использовать как лучший вариант С. Однако,поступая так, мы не используем наиболее мощные возможности С++ иопределенные приемы программирования на нем, так что реализуем лишьмалую долю потенциальных достоинств С++. В этой главе излагается такойподход к проектированию, который позволяет полностью использоватьвозможности абстрактных данных и средства объектного программирования С++.Такой подход обычно называют объектно-ориентированным проектированием.В главе 12 обсуждаются основные приемы программирования на С++, там жесодержится предостережение от сомнительных идей, что есть только один"правильный" способ использования С++, и что для получениямаксимального выигрыша следует всякое средство С++применять в любой программе ($$12.1). Укажем некоторые основные принципы, рассматриваемые в этой главе: - из всех вопросов, связанных с процессом развития программного обеспечения, самый важный - четко сознавать, что собственно вы пытаетесь создать. - Успешный процесс развития программного обеспечения - это дли- тельный процесс. - Системы, которые мы создаем, стремятся к пределу сложности по отношению как к самим создателям, так и используемым средствам. - Эксперимент является необходимой частью проекта для разработки всех нетривиальных программных систем. - Проектирование и программирование - это итеративные процессы. - Различные стадии проекта программного обеспечения, такие как: проектирование, программирование и тестирование - невозможно строго разделить. - Проектирование и программирование нельзя рассматривать в отрыве от вопросов управления этими видами деятельности.Недооценить любой из этих принципов очень легко, но обычно накладно.В то же время трудно воплотить эти абстрактные идеи на практике.Здесь необходим определенный опыт. Подобно построению лодки, езде навелосипеде или программированию проектирование - это искусство, которымнельзя овладеть только с помощью теоретических занятий. Может быть все эти емкие принципы можно сжать в один:проектирование и программирование - виды человеческой деятельности;забудь про это - и все пропало.Слишком часто мы забываем про это и рассматриваем процесс развитияпрограммного обеспечения просто как "последовательность хорошоопределенных шагов, на каждом из которых по заданным правилампроизводятся некоторые действия над входными данными, чтобы получитьтребуемый результат". Сам стиль предыдущего предложения выдаетприсутствие человеческой природы!Эта глава относится к проектам, которые можно считать честолюбивыми,если учитывать ресурсы и опыт людей, создающих систему. Похоже, это вприроде как индивидуума, так и организации - браться за проекты напределе своих возможностей. Если задача не содержит определенный вызов,нет смысла уделять особое внимание ее проектированию. Такие задачирешаются в рамках уже устоявшейся структуры, которую не следует разрушать.Только если замахиваются на что-то амбициозное, появляется потребностьв новых, более мощных средствах и приемах. Кроме того, существуеттенденция у тех, кто "знает как делать", перепоручать проект новичкам,которые не имеют таких знаний. Не существует "единственного правильного способа" дляпроектирования и создания всей системы. Я бы считал веру в "единственныйправильный способ" детской болезнью, если бы этой болезнью слишкомчасто не заболевали и опытные программисты. Напомним еще раз: толькопо той причине, что прием успешно использовался в течение года дляодного проекта, не следует, что он без всяких изменений окажетсястоль же полезен для другого человека или другой задачи. Всегда важноне иметь предубеждений. Убеждение в том, что нет единственно верного решения, пронизываетвесь проект языка С++, и, в основном, по этой причине в первом изданиикниги не было раздела, посвященного проектированию: я не хотел, чтобыего рассматривали как "манифест" моих личных симпатий. По этой жепричине здесь, как и в главах 12 и 13, нет четко определенного взгляда напроцесс развития программного обеспечения, скорее здесь просто даетсяобсуждение определенного круга, часто возникающих, вопросов ипредлагаются некоторые решения, оказавшиеся полезными в определенныхусловиях. За этим введением следует краткое обсуждение целей и средствразвития программного обеспечения в $$11.2, а дальше глава распадаетсяна две основных части:- $$11.3 содержит описание процесса развития программного обеспечения.- $$11.4 содержит некоторые практические рекомендации по организации этого процесса.Взаимосвязь между проектированием и языком программирования обсуждаетсяв главе 12, а глава 13 посвящена вопросам проектирования библиотек дляС++. Очевидно, большая часть рассуждений относится к программным проектамбольшого объема. Читатели, которые не участвуют в таких разработках,могут сидеть спокойно и радоваться, что все эти ужасы их миновали,или же они могут выбрать вопросы, касающиеся только их интересов. Нетнижней границы размера программы, начиная с которой имеет смысл занятьсяпроектированием прежде, чем начать писать программу. Однако все-таки есть нижняяграница, начиная с которой можно использовать какие-либо методыпроектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2. Труднее всего в программных проектах бороться с их сложностью.Есть только один общий способ борьбы со сложностью: разделяй ивластвуй. Если задачу удалось разделить на две подзадачи, которые можнорешать в отдельности, то можно считать ее решенной за счет разделенияболее, чем наполовину. Этот простой принцип применим для удивительнобольшого числа ситуаций. В частности, использование модулей или классовпри разработке программных систем позволяет разбить программу на двечасти: часть реализации и часть, открытую пользователю - которыесвязаны между собой (в идеале) вполне определенным интерфейсом. Этоосновной, внутренне присущий программированию, принцип борьбы сосложностью.Подобно этому и процесс проектирования программы можно разбить наотдельные виды деятельности с четко определенным (в идеале)взаимодействием между людьми, участвующими в них. Это основной,внутренне присущий проектированию, принцип борьбы со сложностью иподход к управлению людьми,занятыми в проекте. В обоих случаях выделение частей и определение интерфейса междучастями - это то место, где требуется максимум опыта и чутья. Такоевыделение не является чисто механическим процессом, обычно оно требуетпроницательности, которая может появиться только в результате доско-нального понимания системы на различных уровнях абстракции (см.$$11.3.3, $$12.2.1 и $$13.3). Близорукий взгляд на программу или напроцесс разработки программного обеспечения часто приводит к дефектнойсистеме. Отметим, что как программы, так и программистов разделитьпросто. Труднее достигнуть эффективного взаимодействия между участникамипо обе стороны границы, не нарушая ее и не делая взаимодействие слишкомжестким. Здесь предложен определенный подход к проектированию, а не полноеформальное описание метода проектирования. Такое описание выходит запредметную область книги. Подход, предложенный здесь, можно применятьс различной степенью формализации, и он может служить базой для различныхформальных спецификаций. В тоже время нельзя считать эту главурефератом, и здесь не делается попытка рассмотреть каждую тему,относящуюся к процессу разработки программ или изложить каждую точкузрения. Это тоже выходит за предметную область книги. Реферат по этойтематике можно найти в [2]. В этой книге используется достаточнообщая и традиционная терминология. Самые "интересные" термины, как:проектирование, прототип, программист - имеют в литературе несколькоопределений, часто противоречащих друг другу, поэтому предостерегаем васот того, чтобы, исходя из принятых в вашем окружении определений терминов,вы не вынесли из книги то, на что автор совершенно не рассчитывал.Цели и средства
Цель программирования - создать продукт, удовлетворяющий пользователя.Важнейшим средством для достижении этой цели является созданиепрограммы с ясной внутренней структурой и воспитание коллективапрограммистов и разработчиков, имеющих достаточный опыт и мотивацию,чтобы быстро и эффективно реагировать на все изменения. Почему это так? Ведь внутрення структура программы и процесс, спомощью которого она получена, в идеале никак не касаются конечногопользователя. Более того, если конечный пользователь почему-тоинтересуется тем, как написана программа, то что-то с этой программойне так. Почему, несмотря на это, так важны структура программы и люди,ее создавшие? В конце концов конечный пользователь ничего об этомне должен знать. Ясная внутренняя структура программы облегчает: - тестирование, - переносимость, - сопровождение, - расширение, - реорганизацию и - понимание.Главное здесь в том, что любая удачная большая программа имеетдолгую жизнь, в течение которой над ней работаютпоколения программистов и разработчиков, она переносится на новуюмашину, приспосабливается к непредусмотренным требованиям и несколькораз перестраивается. Во все время жизни необходимо в приемлемое время ис допустимым числом ошибок выдавать версии программы. Не планировать всеэто - все равно, что запланировать неудачу. Отметим, что, хотя в идеальном случае случае пользователи недолжны знать внутреннюю структуру системы, на практике они обычнохотят ее знать. Например, пользователь может желать познакомиться вдеталях с разработкой системы с целью научиться контролироватьвозможности и надежность системы на случай переделок и расширений.Если рассматриваемый программный продукт есть не полная система, а наборбиблиотек для получения программных систем, то пользователь захочетузнать побольше "деталей", чтобы они служили источником идей ипомогали лучше использовать библиотеку. Нужно уметь очень точно определить объем проектирования программы.Недостаточный объем приводит к бесконечному срезанию острых углов("побыстрее передадим систему, а ошибку устраним в следующей версии").Избыточный объем приводит к усложненному описанию системы, в которомсущественное теряется в формальностях, в результате чего приреорганизации программы получение работающей версии затягивается ("новаяструктура намного лучше старой, пользователь согласен ждать ради нее").К тому же возникают такие потребности в ресурсах, которые непозволительныдля большинства потенциальных пользователей. Выбор объемапроектирования - самый трудный момент в разработке, именно здесьпроявляется талант и опыт. Выбор трудно сделать и для одного программистаили разработчика, но он еще труднее для больших задач, где занятомного людей разного уровня квалификации. Организация должна создавать программный продукт и сопровождатьего, несмотря на изменения в штате, в направлении работы или вуправляющей структуре. Распространенный способ решения этих проблемзаключался в попытке сведения процесса создания системы к несколькимотносительно простым задачам, укладывающимся в жесткую структуру.Например, создать группу легко обучаемых (дешевых) и взаимозаменяемыхпрограммистов низкого уровня ("кодировщиков") и группу не такихдешевых, но взаимозаменяемых (а значит также не уникальных)разработчиков. Считается, что кодировщики не принимают решений попроектированию, а разработчики не утруждают себя "грязными"подробностями кодирования. Обычно такой подход приводит к неудаче, агде он срабатывает, получается слишком громоздкая система с плохимихарактеристиками. Недостатки такого подхода состоят в следующем: - слабое взаимодействие между программистами и разработчиками приводит к неэффективности, промедлению, упущенным возможностям и повторению ошибок из-за плохого учета и отсутствия обмена опытом; - сужение области творчества разработчиков приводит к слабому профессиональному росту, безынициативности, небрежности и большой текучести кадров.По сути, подобные системы - это бесполезная трата редких человеческихталантов. Создание структуры, в рамках которой люди могут найтиприменение разным талантам, овладеть новым родом деятельности иучаствовать в творческой работе - это не только благородное дело, нои практичное, коммерчески выгодное предприятие. С другой стороны, нельзя создать систему, представить документациюпо ней и бесконечно ее сопровождать без некоторой жесткой организационнойструктуры. Для чисто новаторского проекта хорошо начать с того, чтопросто найти лучших специалистов и позволить им решать задачу всоответствии с их идеями. Но по мере развития проекта требуется всебольше планирования, специализации и строго определенного взаимодействиямежду занятыми в нем людьми. Под строго определенным понимается нематематическая или автоматически верифицируемая запись (хотя этобезусловно хорошо там, где возможно и применимо), а скорее наборуказаний по записи, именованию, документации, тестированию и т.п.Но и здесь необходимо чувство меры. Слишком жесткая структура можетмешать росту и затруднять совершенствование. Здесь подвергаетсяпроверке талант и опыт менеджера. Для отдельного работника аналогичнаяпроблема сводится к определению, где нужно проявить смекалку, а гдедействовать по рецептам. Можно рекомендовать планировать не на пе