технологии программирования к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL

Системный подход в технологии программирования

Профессиональное программирование

1.1. Профессионализм в программировании

1.1.1. Функции, черты и особенности мышления профессиональных программистов

1.1.1.1. Функции профессиональных программистов
1.1.1.2. Черты и особенности мышления программистов

1.2. Программирование. Что это такое?
1.3. Программирование. Чему учиться?

1.3.1. Подход на основе рекомендаций ACM/IEEE
1.3.2. Точка зрения профессионалов
1.3.3. Подход, предлагаемый данной книгой

1.3.3.1. Профессиональное программирование
1.3.3.2. Теория программирования
1.3.3.3. Математические основы программирования

1.4. Программирование. Как учиться?

1.4.1. Подход на основе рекомендаций ACM/IEEE
1.4.2. Подход Г. С. Цейтина
1.4.3. Роль наставника в процессе обучения

1.5. Программирование. Искусство, наука или ремесло?
1.6. Кризис программирования
1.7. Основные понятия профессионального программирования

1.7.1. Отступление "о понятиях, определениях и классификациях"
1.7.2. Программа и программный продукт
1.7.3. Алгоритмы
1.7.4. Модели и моделирование
1.7.5. Жизненный цикл программного обеспечения
1.7.6. Проект и команда

1.7.6.1. Проект
1.7.6.2. Участники процесса разработки

1.7.7. Основная задача профессионального программирования

ЛИТЕРАТУРА

В этом разделе рассматриваются вопросы, над которыми рано или поздно задумываются все программисты.

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

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

1.1. Профессионализм в программировании

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

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

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

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

Наряду с понятием "профессионализм" используют также понятия "образованность" и "компетентность".

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

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

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

1.1.1. Функции, черты и особенности мышления профессиональных программистов

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

1.1.1.1. Функции профессиональных программистов

Выделим основные функции профессиональных программистов [Цейтин 1990] [Буч, Рамбо, Джекобсон 2000].

Разработка систем большого объема. Профессионалы знают, что "выход за некоторую границу сложности создаваемого программного продукта без надлежащей технологии разработки вообще невозможен". Системы большого объема создают новые принципиальные трудности. Прекрасно сравнение программирования больших систем со смоляными ямами доисторических времен, в которых увязают динозавры [Брукс 1999]: "Казалось, ничто в отдельности не вызывает трудностей - одну лапу всегда можно вытащить. Однако накопление действующих одновременно и взаимовлияющих факторов все более и более замедляет движение". Еще один образный пример приводится в книге по языку UML [Буч, Рамбо, Джекобсон 2000]: "Если вы хотите соорудить собачью конуру, то можете приступить к работе, имея в наличии лишь кучу досок, горсть гвоздей, , молоток, плоскогубцы и рулетку. ...Хотя это и кажется комичным, многие компании, разрабатывающие программное обеспечение, хотят создать небоскреб, в то время как их подход к делу очень напоминает строительство собачьей конуры".
Создание системного и инструментального программного обеспечения, которым будут пользоваться остальные. Профессиональными программистами создается инструментальное обеспечение в большом диапазоне - от профессионального до массового. Важная подзадача в этой области - создание языков, систем, интерфейсов, позволяющих пользователю работать в его собственных понятиях, а не в тех, которые навязаны особенностями традиционного языка программирования или архитектурой компьютера.
Разработка программного продукта с предъявлением особых требований к его качеству и эффективности. Различные требования предъявляются к программам, создаваемым только для себя, и к программам, предназначенным для большого количества пользователей. Во втором случае любая неаккуратность и малейшая небрежность может повториться многократно в работах будущих пользователей.
Разработка программ на основе подхода открытых систем. Открытая система (open system) - система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы. Общие свойства открытых систем таковы:

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

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

1.1.1.2. Черты и особенности мышления программистов

Профессиональные программисты имеют свои черты, качества, способности и особенности мышления. Наиболее важными из них являются приведенные ниже [Цейтин 1990] [Дейкстра 1975].

Способность определить архитектуру программы, т. е. разбить сложную задачу на элементарные составляющие и задать их комбинирование. Это основное качество программиста, связанное непосредственно с написанием программ.
Умение видеть задачу одновременно на разных уровнях детализации. Программист должен свободно переходить от описания задачи в крупных понятиях к стоящим за этими понятиями сущностям более низкого уровня.
Умение представлять себе проектируемый процесс в динамике. Обрабатываемые данные в некоторый момент времени могут иметь одни значения и взаимоотношения, а в следующий момент некоторые из них могут измениться.
Умение видеть дальше одной разрабатываемой в данный момент программы. Следует учитывать широкое окружение данной частной задачи и возможность ее включения в некоторую общую систему. Считается, что эта черта в значительной степени отличает профессионального программиста от хакера, ориентированного на скорейшее получение конечного результата.
Умение обобщать типичные ситуации. Эта особенность означает, что необходимо уметь находить в программе идейно однородные участки. Для таких участков необходимо принять решение по их обобщению, выяснить его границы и выбрать наилучший способ программной реализации найденного решения. Это может быть как разработка функции или пакета, так и копирование в новую программу фрагментов из старой.
Умение применять и комбинировать хорошо известные программистские приемы и типовые алгоритмы. Большинство новых идей должно находиться в тесном взаимодействии с уже известными идеями и методами. Простые и изящные решения типичных задач, возникающих в объектно-ориентированном программировании, приведены в книге "приемы объектно-ориентированного программирования. Паттерны проектирования" [Гамма, Хелм, Джонсон, Влиссидес 2001].
Наличие комплексного мышления, включающего умение заранее определить этапы, которые нужно пройти, чтобы решить тот или иной вопрос;
Культура собственного труда, умение обеспечить себя необходимым инструментарием для работы.
Способность анализировать собственные ошибки. Эта черта указывает на требовательность программиста к себе с одной стороны и применение стиля программирования, уменьшающего количество ошибок, с другой.
Умение работать в коллективе. Практически любая крупная разработка носит коллективный характер. Успех всей работы зависит от взаимопонимания, распределения функций и взаимоотношений в коллективе.
Умение работать с пользователем. Профессиональный программист должен понимать потребности пользователя, уметь оценить удобство конкретных форм интерфейса, иметь возможность приучить пользователя к новым средствам и системам. Программист должен обладать хотя бы минимумом психологических знаний, помогающих ему в общении с пользователем.
Владение интеллектуальными средствами, которые применяются для понимания программы. Эдсгер Дейкстра (Edsger Dijkstra) [Дейкстра 1975] выделяет следующие три основных средства, которыми должен обладать профессиональный программист:

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

Следование вопросам общечеловеческой этики. Эти вопросы исследованы в книгах Достоевского [Достоевский 1985]. Анализ одной из программистских этических проблем представлен в работе [Leveson-Turner 1993].

Чарльз Уэзерелл (Charles Wetherell) [Уэзерелл 1982] перечисляет способности, которые необходимы программисту. Приведем некоторые из них.

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

1.2. Программирование. Что это такое?

Программирование - это то, чем занимаются программисты.
Программистский фольклор

"Программирование" - как и "любовь" - одно слово, за которым скрывается бесконечное множество занятий.
Д. Вейнберг

Любовь - это все. И это все, что мы о ней знаем.
Э. Дикинсон

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

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

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

Теория программирования, которая включает следующие направления [Лавров 2001]:

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

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

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

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

Инженерия программирования, которую мы понимаем как инженерное дело, творческую техническую деятельность. Инженерия изучает различные методы и инструментальные средства с точки зрения определенных целей, т. е. имеет очевидную практическую направленность. Основная идея инженерии программирования в том, что разработка программного обеспечения является формальным процессом, который можно изучать и совершенствовать. Данный раздел имеет четко определенную дату рождения - 1968 год. Причина его появления - реакция на так называемый "кризис программного обеспечения". Характерные вопросы и задачи инженерии программирования, изложенные Фредериком Бруксом (Frederick Brooks) [Брукс 1999], актуальны и по сегодняшний день.

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

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

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

О понятии "инженерия программирования"
Русскоязычный термин "технология программирования" долгое время понимался именно как "инженерия программирования". Новосибирский математик А. П. Ершов в конце 1960-х годов именно так предложил переводить "Software Engineering". Для начального этапа этой инженерно-технической дисциплины такой перевод был очень удачен. Однако сейчас оказалось более естественным вернуться к переводу "инженерия программирования" [Поттосин 1997].

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

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

1.3. Программирование. Чему учиться?

Двадцать лет Ли Чанг учился убивать страшных драконов.
И когда он овладел этим искусством в совершенстве, оказалось, что драконов на свете нет.
И тогда он стал учить этому других.
Китайская мудрость

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

Мы рассмотрим три подхода, связанных с обучением.

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

1.3.1. Подход на основе рекомендаций ACM/IEEE

Вот точка зрения на то, чему надо учиться, международных организаций, занимающихся стандартизацией:

ассоциации по вычислительной технике (The Association for Computing Machinery - ACM) (http://info.acm.org). Это международная научная и образовательная организация, основная задача которой - распростране-ние навыков, теорий и приложений из области информационных технологий;
института инженеров по электротехнике и электронике (Institute of Electrical and Electronic Engineers - IEEE) (http://www.ieee.org). Это всемирная организация инженеров, направляющая деятельность технических обществ и участвующая в разработке стандартов.

Рекомендации этих организаций - "Учебные программы по информатике" [Curriculum 1968], [Tucker 1991] формулируют общие требования к учебным программам по информатике в виде модулей знаний, размещенных в 11 блоках. Блоки соответствуют девяти предметным областям, предложенных Питером Деннингом (Piter Denning) [Denning 1989], дополненных блоками "Социальный контекст информатики" и "Введение в язык программирования". Последний блок является факультативным. Это отражает подход, согласно которому необходимые знания по конкретным языкам программирования и практический опыт их использования учащиеся должны приобретать самостоятельно или на факультативных курсах [Parnas 1990].

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

Модули знаний	Часы
Алгоритмы и структуры данных (AL)	47
AL1 Основные структуры данных	13
AL2 Абстрактные типы данных	2
AL3 Рекурсивные алгоритмы	3
AL4 Анализ сложности	4
AL5 Классы сложности	4
AL6 Сортировка и поиск	6
AL7 Эффективная вычислимость и неразрешимость	6
AL8 Стратегия решения задач	6
AL9 Параллельные и распределенные алгоритмы	3
Архитектуры (AR)	59
AR1 Цифровая логика	12
AR2 Цифровые системы	6
AR3 Машинное представление данных	3
AR4 Системы машинных команд	15
AR5 Организация памяти	13
AR6 Интерфейсы и коммуникации	5
AR7 Альтернативные архитектуры	5
Искусственный интеллект и робототехника (AI)	9
АI1 История и приложения искусственного интеллекта	3
AI2 Задачи, пространства состояний, стратегии поиска	6
Базы данных и информационный поиск (0В)	9
DB1 Обзор, модели и приложения систем баз данных	4
DB2 Реляционная модель данных	5
Человеко-машинное взаимодействие (HU)	8
HU1 Пользовательские интерфейсы	5
HU2 Машинная графика	3
Числовые и символьные вычисления (NU)	7
NU1 Представление чисел, ошибки, переносимость	3
NU2 Итерационные приближенные методы	4
Операционные системы (OS)	31
OS1 История, эволюция и философия	3
OS2 Мультипрограммирование	2
OS3 Взаимодействие и синхронизация процессов	4
OS4 Планирование процессов	3
OS5 Физическая и виртуальная память	4
OS6 Управление устройствами	2
OS7 Файловые системы	4
OS8 Безопасность и защита	3
OS9 Коммуникации и сети	3
OS10 Распределенные ОС и системы реального времени	3
Языки программирования (PL)	46
PL1 История и обзор языков программирования	2
PL2 Абстрактные машины	2
PL3 Представление типов данных	2
PL4 Управление последовательностью вычислений	4
PL5 Управление данными, разделение данных и контроль типов	4
PL6 Управление памятью	4
PL7 Конечные автоматы и регулярные выражения	6
PL8 Контекстно-свободные грамматики и МП-автоматы	4
PL9 Трансляторы	3
PL10 Семантика языков программирования	2
PL11 Парадигмы программирования	10
PL12 Конструкции параллельного программирования	3
Введение в язык программирования (PR) - факультативно	12
PR1 Введение в язык программирования	12
Программная инженерия и технология (SE)	44
SE1 Основы решения задач	16
SE2 Процесс разработки программного обеспечения	8
SE3 Техническое задание и спецификация	4
SE4 Разработка и реализация	8
SE5 Верификация и контроль качества	8
Социальные, этические и правовые вопросы (SP)	11
SP1 История и социальный контекст информатики	3
SP2 Профессиональная ответственность в информатике	3
SP3 Риск и материальная ответственность	3
SP4 Интеллектуальная собственность	2

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

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

Российские программы по информатике в большой степени соответствуют рекомендациям ACM/IEEE. Одной из наиболее известных и удачных отечественных программ является учебный план по специальности 220400 - "Программное обеспечение вычислительной техники и автоматизированных систем" [ГОС 220400] [Лавров, Слисенко, Цейтин 1985]. Основные направления развития информатики в целом соответствуют тем специальностям, которые выделены в российских стандартах. Российские стандарты и программы университетов многих стран мира в целом схожи друг с другом, что отражает тот факт, что видение тенденций развития информатики в России и в других странах практически идентично.

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

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

1.3.2. Точка зрения профессионалов

Тимоти Летбридж (Timothy С. Lethbridge) в 1998 году провел опрос более 200 опытных программистов [Lethbridge 2000]. Было выбрано 75 предметных областей, по которым есть учебные курсы практически в каждом высшем учебном заведении. Относительно каждой области был задан ряд вопросов.

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

Ответы давались в баллах в диапазоне от нуля (бесполезность или отсутствие влияния) до пяти (существенная польза или значительное влияние). Некоторые результаты опроса представлены в табл. 1.2. В графе "Полезность" вычислено среднее арифметическое значение граф "Подробности" и "Влияние". Предметные области перечислены в порядке убывания их значимости для опрашиваемых.

Таблица 1.2. Наиболее полезные области программирования

Предметная область	Полезность	Подробности	Влияние
Конкретные языки программирования	3.8	4.1	3.5
Структуры данных	3.6	3.7	3.4
Проектирование программ и паттерны	3.5	3.6	3.5
Архитектура программного обеспечения	3.4	3.5	3.3
Техническое задание и спецификация	3.4	3.5	3.3
Человеко-машинное взаимодействие	3.3	3.3	3.3
Объектно-ориентированный подход	3.3	3.3	3.3
Этика и профессионализм	3.3	3.2	3.4
Методы анализа и проектирования	3.3	3.3	3.3
Выступления и презентации	3.3	3.5	3.1
Управление проектами	3.3	3.4	3.2
Тестирование, верификация и качество	3.2	3.3	3.1
Проектирование алгоритмов	3.2	3.3	3.1
Написание технической документации	3.1	3.4	2.9
Операционные системы	3.1	3.3	3.0
Базы данных	3.1	3.3	2.8
Руководство проектами	3.0	3.1	3.0
Конфигурация и управление версиями	3.0	3.3	2.8
Передача данных и сети	3.0	3.1	2.8
Основы менеджмента	2.9	2.9	2.9

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

Таблица 1.3. Наиболее перспективные области программирования

Область программирования	Перспективность (%)
Язык программирования C++	46.2
Объектно-ориентированное проектирование	31.1
Операционная система Windows	26.2
Язык и система программирования Visual Basic	23.8
Проектирование графического пользовательского интерфейса	22.1
Язык запросов SQL	16.4
Операционная система Unix	15.6
Система управления базами данных Oracle	12.3
Система управления базами данных Sybase	10.7
Язык программирования Java	9.8
Разработка приложений для Интернета и язык HTML	9.0
Язык и система программирования Delphi	3.3

1.3.3. Подход, предлагаемый данной книгой

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

профессиональное программирование;
теория программирования;
математические основы программирования.

1.3.3.1. Профессиональное программирование

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

1.3.3.2. Теория программирования

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

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

"Искусство программирования" [Кнут 2000].
"Алгоритмы: построение и анализ" [Кормен, Лейзерсон, Ривест 1999].
"Алгебраическая алгоритмика" [Ноден, Китте 1999].
"Введение в теоретическое программирование" [Ершов 1977].

1.3.3.3. Математические основы программирования

Когда Дональд Кнут (Donald Knuth) задумал серию книг под названием "Искусство программирования", то он отметил необходимость для программирования важных математических инструментов. Была необходима именно та математика, которая требуется для досконального и обоснованного истолкования компьютерных программ. Как правило, это математика, которая имеет конкретные классические результаты, позволяющая получить удовольствие от решения численных задач или оценить по достоинству роль математических методов. При этом важно уметь исследовать с математической точки зрения как дискретные, так и непрерывные (континуальные) системы. На рис. 1.4 представлены разделы математики, наиболее важные для программирования.

Следующие четыре учебника представляют достаточно полную картину в области математических основ программирования:

"Конкретная математика. Основание информатики" [Грэхем, Кнут, Паташник 1998];
"Дискретный анализ" [Романовский 1999];
"Комбинаторика для программистов" [Липский 1988];
"Программирование. Математические основы, средства, теория" [Лавров 2001].

1.4. Программирование. Как учиться?

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

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

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

1.4.1. Подход на основе рекомендаций ACM/IEEE

Итак, рассмотрим методологический подход на уровне следования рекомендациям ACM/IEEE.

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

Первый из этих подходов - теория - присущ математике и включает в себя следующие элементы:

определения и аксиомы;
теоремы;
доказательства;
интерпретацию результатов.

Этот подход применяется в собственно математических дисциплинах и при изучении теоретических основ информатики.

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

сбор данных и выработку гипотез;
моделирование и предсказание;
планирование эксперимента;
анализ результатов.

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

Третий подход - конструирование - присущ инженерным дисциплинам, заключается в создании системы или устройства для решения поставленной задачи и включает в себя следующие элементы:

определение требований;
написание спецификаций;
разработку и реализацию;.
тестирование и анализ.

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

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

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

1.4.2. Подход Г. С. Цейтина

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

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

1.4.3. Роль наставника в процессе обучения

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

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

Наиболее развита традиция наставничества в России и в Японии. Японцы в целом расположены к помощи друг другу. Они не привыкли держать свои методы и приемы работы в тайне, а предпочитают учиться друг у друга. Эта традиция называется "минарай" - наблюдение за опытными рабочими с целью освоения их навыков [Психология 2000]. Интересно то, что многие японцы не доверяют официальному обучению в ВУЗах, поскольку оно построено по западным образцам. Они считают, что официальное обучение дает только основы специальности и развивает общие способности, но научиться тому, что им действительно нужно, можно только в процессе работы и через индивидуальное обучение.

1.5. Программирование. Искусство, наука или ремесло?

Искусство - это я, наука - это мы.
Виктор Гюго

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

Две программы, написанные разными людьми для решения одной и той же задачи, оказываются весьма непохожими друг на друга. Обратим внимание на то, что здесь нет четких критериев, как нет их и у искусствоведов. Лавров [Лавров 2000] отмечает, что "программирование часто становится мало похожим на искусство, опускаясь до уровня ремесла". Однако ремесленные по своей природе изделия в руках большого мастера приобретают высокую художественную ценность. Парадные портреты знатных людей писались мастерами как ремесленнические изделия, но стали произведениями искусства.

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

Дональд Кнут в лекции "Программирование как искусство" в качестве лауреата премии Тьюринга [Кнут 1974] сделал наиболее интересный анализ соотношения искусства и программирования. "Программирование - это искусство, поскольку оно является приложением накопленных знаний для практических целей, поскольку оно требует умения и мастерства, и в особенности потому, что продукты программирования могут представлять эстетическую ценность. Программист, который бессознательно ощущает себя художником, получает удовольствие от своей работы и справляется с ней лучше".
Дэвид Грис (David Gries) начинает свою книгу "Наука программирования" [Грис 1984] со следующего утверждения: "Программирование начиналось как искусство; даже сейчас большинство учится ему, наблюдая, как работают другие (например, преподаватель или более опытный коллега), постигая приемы и мало задумываясь над принципами, которые лежат в их основе. Однако в результате научных исследований последнего десятилетия найдены некоторые полезные теоретические положения и общие принципы, так что наступает время, когда можно начинать учить принципам и их осознанному применению. В этом учебнике я сделал попытку поделиться своим пониманием возникающей на наших глазах науки программирования и восхищением ею".
В то же время первые слова книги Уэзерелла "Этюды для программистов" [Уэзерелл 1982] звучат так: "Программирование - это ремесло, и каждый программист должен достичь нужного профессионального уровня".

Попытки исследовать творческую составляющую программирования предпринимались неоднократно. В статье "Программирование как высшая форма творчества" (http://www.hackzone.ru/articles/creative.html) указывается на различия программирования и любой другой формы творчества.

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

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

Программа представляет решение Г. С. Цейтина задачи расстановки ферзей на шахматной доске с хранением информации в локальных процедурах. Напомним, что в этой задаче требуется составить программу, генерирующую все расстановки восьми ферзей на шахматной доске из 8x8 полей с таким условием, чтобы ни один ферзь не мог бить никакого другого ферзя. Программа написана на языке Algol-68.

Кстати, на эту задачу обращали внимание многие великие программисты. Рекомендуем посмотреть вариант программы расстановки, предложенный Дейкстрой [Дейкстра 1975].

Листинг 1.1. Задача расстановки ферзей на шахматной доске

рrос Ферзи = (int k, proc(int, int) bool Можно, proc void Печать) void:
if k = 8 then Печать
else
int p = k+1;
for q to 8 do
if Можно (p,q) then
proc МожноНовое = (int x,y) bool:
if у = q or x-p = abs(y-q) then
false
else
Можно(x,y)
fi;
proc ПечатьНовое = void:
(Печать; print((",", "abcdefgh"[p], "12345678"[q])));
Ферзи(p, МожноНовое, ПечатьНовое)
fi
od
fi;
proc МожноНачальное = (int x, y) bool: true;
proc ПечатьНачальная = void: print(newline);
Ферзи(О, МожноНачальное, ПечатьНачальная);

1.6. Кризис программирования

Когда дело доходит до самооправдания, тут все мы гении.
3. Фрейд

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

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

Брукс [Брукс 1999] указывает в качестве основных причин существования кризиса программирования четыре присущих программному обеспечению свойства.

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

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

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

Существуют еще другие важные причины кризиса программирования.

Экстремальные условия, в которых выполняются многие проекты. Эдвард Йордон (Edward Yourdon) [Йордон 2001] вводит понятие "безнадежного проекта", т. е. проекта, хотя бы один параметр которого значительно отклоняется от нормальных значений. Перечислим эти параметры:

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

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

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

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

Отметим несколько причин, связанных с понятием "человеческий фактор".

Невозможность проанализировать и обобщить действия великих программистов за работой. Давно возникло понимание того, что некоторые программисты на порядок, а то и на несколько порядков, более полезны, чем остальные. К сожалению, немногочисленные объяснения причин такого состояния по-прежнему остаются лишь на уровне гипотез.
Неумение менеджера правильно сформировать проектную команду. Йордон [Йордон 2001] отмечает как минимум две составляющих решения проблемы. Первая - становление открытых и честных взаимоотношений в команде. Вторая - подбор психологически совместимых исполнителей.
Отсутствие нормальных условий работы. Том ДеМарко (Tom DeMarco) и Тим Листер (Tim Lister) [DeMarco Lister 1987] установили, что продуктивность работы тех, кто находится в хорошем офисе и может, закрыв дверь, не отвлекаться на телефонные звонки и посторонние дела, почти в 2,6 раза выше, чем у находящихся в коллективных комнатах.

1.7. Основные понятия профессионального программирования

Определение понятий - это начало ссылок.
Сократ

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

1.7.1. Отступление "о понятиях, определениях и классификациях"

Не забывай меня, казни меня,
Но дай мне имя, дай мне имя!
Мне будет легче с ним, пойми меня,
В беременной глубокой сини!
O.Э. Мандельштам

Существует шуточное утверждение, согласно которому определения нужны "для того, чтобы о том, что определяется, можно было сказать в дискуссии хоть что-нибудь определенное, а сама дискуссия не превращалась в бесплодный спор ослов о словах" [Шевчук, Харахоркина, Журавлев, Армен 1998]. На самом деле, понятия очень важны с точки Зрения теории познания и логики. Кибернетическое "понятие понятия" дано в книге [Турчин 2000].

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

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

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

Одна из наиболее известных и удачных классификаций - периодический закон и периодическая система химических элементов Дмитрия Ивановича Менделеева. Менделееву удалось найти такое расположение химических элементов, благодаря которому появилась возможность получить четкую картину соотношения элементов и предсказать открытие новых элементов. Если же классификационные принципы выбраны наугад, то мы получим нечто подобное следующей классификации, описанной аргентинским писателем Хорхе Луисом Борхесом в новелле "Аналитический язык Джона Уилкинса": "Животные подразделяются на: а) принадлежащих Императору, б) бальзамированных, в) прирученных, г) молочных поросят, д) сирен, е) сказочных, ж) бродячих собак, з) включенных в настоящую классификацию, и) буйствующих, как в безумии, к) неисчислимых, л) нарисованных очень тонкой кисточкой из верблюжьей шерсти, м) и прочих, н) только что разбивших кувшин, о) издалека кажущихся мухами".

Обратим внимание напоследок, что многие определения и классификации субъективны. Тем не менее, чтобы вести обсуждение какого-либо предмета, следует определить его и указать его место в картине мира. Надеемся, что область наших исследований будет сформулирована достаточно четко. А если кого-то и не устроят приведенные в этой книге определения, заметим, что даже для термина "математическая статистика" (наука, которой более 100 лет) существует коллекция из более 200 определений [Налимов 1979].

1.7.2. Программа и программный продукт

На наш взгляд, одни из наиболее удачных определений этих понятий принадлежат Бруксу [Брукс 1999].

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

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

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

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

Ряд авторов дополнительно вводят определение программного средства [Жоголев 1996].

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

1.7.3. Алгоритмы

Если "алгоритм", то "аритметика".
Программистский фольклор

Алгоритм - точное и конечное описание того или иного общего метода, основанного на применении исполнимых элементарных тактов обработки.

Компьютер - вычислитель, он не понимает программу, а исполняет ее. Наиболее естественный способ указать компьютеру ход исполнения программы - записать ее в виде алгоритма (на алгоритмическом языке). Современное значение слова "алгоритм" во многом аналогично таким понятиям, как рецепт, процесс, метод, способ. Алгоритм имеет пять важных свойств [Кнут 2000].

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

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

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

Большинство практических алгоритмов, с которыми работают программисты, являются полиномиальными. Это означает, что время работы алгоритма на входе длины n составляло не более o(nk) для некоторой константы k, не зависящей от n. Не всякая задача может быть решена за полиномиальное время. Некоторые решаются лишь за экспоненциальное, а некоторые вообще не могут быть решены никаким алгоритмом.

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

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

Где найти справочник по важнейшим классам быстрых алгоритмов? В этом случае можно порекомендовать четыре книги.

"Искусство программирования, том 1. Основные алгоритмы" [Кнут 2000].
"Алгоритмы: построение и анализ" [Кормен, Лейзерсон, Ривест 1999].
"Алгебраическая алгоритмика" [Ноден, Китте 1999].
"Алгоритмы и структуры данных" [Вирт 2001].

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

"Основы теории элементарных алгоритмов" [Косовский 1987].
"Теория алгоритмов: основные открытия и приложения" [Успенский, Семенов 1987].

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

1.7.4. Модели и моделирование

Придумать зеленое солнце легко; трудно создать мир,
в котором оно было бы естественным...
Дж. Р. Р. Толкиен

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

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

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

Наконец, моделирование - это попытка решить проблему сложности. Существует четыре основных принципа моделирования [Буч, Рамбо, Джекобсон 2000].

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

В общем случае выделяют четыре типа моделей.

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

1.7.5. Жизненный цикл программного обеспечения

Он пришел к реке. Река была на месте.
Э. Хемингуэй. "Большая река двух сердец"

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

Существует простейшее представление жизненного цикла, которое включает следующие стадии:

анализ;
проектирование;
программирование;
тестирование и отладка;
эксплуатация.

Цикл разработки программного обеспечения тесно связан с технологиями программирования, поэтому подробно его мы рассмотрим в гл. 3, посвященной технологиям.

1.7.6. Проект и команда

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

1.7.6.1. Проект

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

Рассмотрим три основных категории разработок и соответствующие им проекты. Проиллюстрируем их примерами из области разработки компиляторов.

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

Существует еще одна категория проектов.

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

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

проект для широкого круга пользователей',
проект для конкретного заказчика;

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

коммерческий проект. Это проект, разработчики которого ориентируются на получение прибыли от продажи программного продукта;
некоммерческий проект. Такие проекты обычно являются нерентабельными. Мотивация для участия в таких проектах - приобретение опыта в конкретной области программирования, приобретение статуса и уважения, обучение работе в коллективе. Некоммерческий проект может иметь особые, уникальные черты. Очень часто такие проекты являются "общинными" проектами (http://www.tuxedo.org/~esr/writings/cathedral-bazaar/). Они характеризуются децентрализацией. Менеджер (координатор) проекта практически все время выполнения проекта не знает точного количества участников. Практически всегда это разработка с открытыми и доступными всем текстами программного продукта. Как правило, некоммерческие разработки распространяются с лицензией, запрещающей их использование в коммерческих целях.

Еще одной характеристикой проекта является его масштаб. В зависимости от масштаба можно выделить четыре категории проектов [Йордон 2001]:

небольшой проект. Команда разработчиков включает менее 10 человек. Протяженность проекта от 3 до 6 месяцев;
средний проект. Команда разработчиков включает от 20 до 30 человек. Протяженность проекта от 1 до 2 лет;
крупномасштабный проект. Команда (иерархия команд разработчиков) включает от 100 до 300 человек. Протяженность проекта от 3 до 5 лет;
гигантский проект. Команда (иерархия команд разработчиков) включает от 1000 до 2000 человек. Протяженность проекта от 7 до 10 лет.

Мы еще раз вернемся к понятию проект при обсуждении процесса управления в разд. 3.2.2.

1.7.6.2. Участники процесса разработки

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

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

Рассмотрим роль отдельных действующих групп более подробно.

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

Существует два типа команд разработчиков - команда разработчиков компонента и команда разработчиков продукта.

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

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

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

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

инженеры-разработчики;
инженеры тестирования;
технические писатели.

Команда начинает работу сразу после завершения проектирования продукта. Именно эта команда после начала продаж продукта занимается сопровождением, исправляя ошибки, обнаруженные пользователем.

Существуют также команды, ориентированные на выпуск версии.

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

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

1.7.7. Основная задача профессионального программирования

Знай, читатель, что мудрость уменьшает жалобы, а не страдания!
Козьма Прутков

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

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

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

ЛИТЕРАТУРА

Достоевский дает мне больше, чем любой мыслитель...
Альберт Эйнштейн

1. Брукс 1999 - Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - СПб.: Символ-Плюс, 1999.

2. Буч, Рамбо, Джекобсон 2000 - Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМ К, 1998.

3. Вирт 2001 - Вирт Н. Алгоритмы и структуры данных. - СПб: Невский диалект, 2001.

4. Гамма, Хелм, Джонсон, Влиссидес 2001 - Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного программирования. Паттерны проектирования. - СПб.: Питер, 2001.

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

6. Грис 1984 - Грис Д. Наука программирования. - М.: Мир, 1984.

7. Грэхем, Кнут, Поташник 1998 - Грэхем Р., Кнут Д., Паташник О. Конкретная математика. Основание информатики. - М.: Мир, 1998.

8. Дейкстра 1975 - Дейкстра Э. Заметки по структурному программированию // Дал У., Дейкстра Э., Хоор К. Структурное программирование. - М.: Мир, 1975, с. 7-97.

9. Достоевский 1985 - Достоевский Ф. М. Преступление и наказание. - М.: Мир, 1985.

10. Ершов 1977 - Ершов А. П. Введение в теоретическое программирование. - М.: Наука, 1977.

11. Жоголев 1996- Жоголев Е. А. Лекции по технологии программирования. - М.: МГУ, факультет ВМиК, рукопись, 1996.

12. Йордон 2001 - Эдвард Йордон. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. - М.: ЛОРИ, 2001.

13. Кнут 1974- Дональд Кнут. Программирование как искусство. // Лекции лауреатов премии Тьюринга. 1966-1985. - М.: Мир, 1993.

14. Кнут 2000 - Дональд Кнут. Искусство программирования, том 1. Основные алгоритмы (3-е изд.). - М.: Издательский дом "Вильяме", 2000.

15. Кормен, Лейзерсон, Ривест 1999 - Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: построение и анализ. - М.: МЦНМО, 1999.

16. Косовский 1987- Косовский Н. К. Основы теории элементарных алгоритмов. - Л.: Изд-во Ленингр. ун-та, 1987.

17. Лавров 2000 - Лавров С. С. Так что же такое информатика? // Компьютерные инструменты в образовании. 2000, № 1, с. 22-25.

18. Лавров 2001 - Лавров С. С. Программирование. Математические основы, средства, теория. - СПб.: БХВ-Петербург, 2001.

19. Лавров, Слисенко, Цейтин 1985 - Лавров С. С., Слисенко А. О., Цейтин Г. С. Проект учебного плана специальности: "информатика и системное программирование", // Микропроцессорные средства и системы. 1985, № 4, с. 20-28.

20. Липский 1988 - Липский В. Комбинаторика для программистов. - М.: Мир, 1988.

21. Налимов 1979- Налимов В. В. Вероятностная модель языка. О соотношении естественных и искусственных языков. - М.: Наука, 1979.

22. Ноден, Китте 1999 - Ноден П., Китте К. Алгебраическая алгоритмика. - М.: Мир, 1999.

23. Поттосин 1997 - Поттосин И. В. Программистская инженерия: содержание, мнения и тенденции. // Программирование. - 1997. - № 4. - С. 26-37.

24. Психология 2000 - Психология менеджмента: Учебник. - СПб.: Изд-во Санкт-Петербургского университета, 2000.

25. Романовский 1999 - Романовский И. В. Дискретный анализ. - СПб.: Невский диалект, 1999.

26. Турчин 2000 - Турчин В. Ф. Феномен науки: кибернетический подход к эволюции. - М.: ЭТС, 2000.

27. Успенский, Семенов 1987 - Успенский В. А., Семенов А. Л. Теория алгоритмов: основные открытия и приложения. - М.: Наука, 1987.

28. Уэзерелл 1982 - Уэзерелл Ч. Этюды для программистов. - М.: Мир, 1982.

29. Цейтин 1990 - Цейтин Г. С. О профессионализме в программировании. - СПб.: ЛГУ, математико-механический факультет, рукопись, 1989.

30. Шевчук, Харахоркина, Журавлев, Армен 1998 - Шевчук О. Б., Харахоркина А. А., Журавлев Б. С., Армен В. А. Защищайтесь, сударь! Руководство по созданию и защите диссертаций. - СПб.: Политехника, 1998.

31. Curriculum 1968 - ACM Curriculum Committee on Computer Science. Curriculum 68: Recommendations for the undergraduate program in computer science. // CACM, March 1968. V. 11, N 3, pp. 151-197.

32. DeMarco, Lister 1987 - DeMarco Tom, Lister Tim. Peopleware. Dorset Publishing, 1987.

33. Denning 1989 - Denning P., et al. Computing as a Discipline // CACM, January, 1989. V. 32, N 1, pp. 9-23.

34. Glass 1996 - Robert L. Glass. The Relation Between Theory and Practice in Software Engineering. // CACM, November 1996. V. 39, N 11, pp. 11-13.

35. Lethbridge 2000 - Timothy C. Lethbridge. Priorities for the education and training of software engineers. // The Journal of Systems and Software, 53, 2000, pp. 53-57.

36. Leveson, Turner 1993 - Nancy G. Leveson, Clark S. Turner. An Investigation of the Therac-25 Accidents // Computer, July, 1993, pp. 18-41.

37. Parnas 1990 - Parnas D. L. Education for Computing Professionals // Computer, January, 1990. V. 23, N 1, pp. 17-22.

38. Tucker 1991 - Tucker A., et al. Computing Curricula 1991, Report of the ACM/IEEE-CS Joint Curriculum Task Force, ACM Press, N. Y. 1991.

технологии программирования к оглавлению к высокоуровн. языкам - 3GL к визуальным средам - 4GL

Знаете ли Вы, что карты класс-ответственность-кооперация, Class-responsibility-collaboration - карты класс-ответственность-кооперация - это методология объектно-ориентированного проектирования, предназначенная для описания классов и оперирующая понятиями:
- ответственность - суть - высокоуровневое описание функций, которые выполняет класс;
- кооперация - суть - ссылка на другие классы, с которыми необходимо кооперироваться для реализации функций.

НОВОСТИ ФОРУМА

Рыцари теории эфира