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

Donald Ervin Knuth
Donald Ervin Knuth

Технологии программирования (Software Engineering)

Классические технологические процессы

Начнем знакомство с "девятки" классических технологических процессов.

2.1. Возникновение и исследование идеи

Погоня за идеей - занятие столь же захватывающее, как и погоня за китом.
Генри Норрис Рассел

Этот классический процесс имеет следующие действия:

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

2.1.1. Возникновение идеи решения проблемы

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

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

В научном творческом поиске [Шевчук, Харахоркина, Журавлев, Армен 1998] отрицательный результат, как правило, также имеет существенное значение. С самого начала научного поиска следует понять - где проходит граница между знанием и незнанием. Научный поиск отличает определенное достоинство, заключающееся в верности критерию сдержанности и проверки идей, систематичности объяснений.

Поиск решения может включать эвристические правила. В качестве примеров укажем подход, предложенный Д. Пойа [Пойа 1957] для решения новых задач, и алгоритм решения изобретательских задач Г. С. Альтшуллера . (http://www.triz.minsk.by/index0.htm). Роль интуиции в творческом поиске исследуется в книге "Интуиция и искусственный интеллект" [Грановская, Березная 1991].

Предложим несколько советов по организации поиска решения задачи [Косовский, Хитров 1997].

Эдвард де Боно (Edward de Bono) выделяет два типа мышления с соответствующими подходами решения задач (http://www.edwarddebono.org),

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

2.1.2. Постановка задачи

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

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

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

Одностраничный документ

Разработка руководства пользователя по OpenMP.

Краткий обзор

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

Введение

Описание особенностей поставки

Пользователи документа

Пользователь - опытный программист на языках С, C++, Pascal и FORTRAN, понимающий преимущества распараллеливания программ на многопроцессорных ЭВМ.

Сравнительный анализ

Многие разработчики компиляторов (например, компании SGI, Sun, IBM) уже включили поддержку OpenMP. Описание OpenMP они включают как отдельные главы в руководство пользователя по компиляторам с языков С, C++, Pascal и FORTRAN. С нашей точки зрения, лучшим решением будет иметь единый документ для всех компиляторов.

Описание технического процесса

Зависимости

Список основных документов

Спецификация OpenMP.

Основные даты

Ресурсы

Ресурсы, необходимые для реализации данного проекта, представлены в табл. 3.1.

Таблица 3.1. Ресурсы, необходимые для реализации проекта

Функция
Ставка
Комментарии
Инженер-разработчик
0.1
Консультирующий инженер, реализующий OpenMP
Технический писатель
1.0
Подготовка документа
Руководитель проекта
0.3
Управление, разработка плана и содержания

2.1.3. Принятие решения о начале работы над проектом

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

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

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

2.2. Управление

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

Вам никогда не будет хватать либо времени, либо денег.
Следствие из закона Лермана

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

2.2.1. Управление проектом

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

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

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

Предпринимательская деятельность фирмы строится исходя из этой задачи, объединяющей пять направлений [Пашкус, Мисько 1991].

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

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

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

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

Обязанности управляющего

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

Совместная деятельность менеджера и лидера проекта включает:

Исключительная ответственность менеджера заключается:

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

Еще раз обратимся к понятию "проект" и выделим четыре характеристики, делающих деятельность - проектом [Баранов 1998].

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

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

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

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

Мотивация

А на фига?!
А. Вознесенский

Метод "Кнута и Пряника" - алгоритм, описанный в известной монографии
Кнута [Кнут 2000] и позднее модифицированный
русским программистом Пряником.
Программистский фольклор

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

Потребность - осознанная недостаточность чего-либо. Именно потребности заставляют людей действовать определенным образом. Выделяют две основные группы потребностей.

Потребности можно удовлетворять с помощью вознаграждения. Менеджеры могут использовать внутренние вознаграждения (которые дает сама работа) и внешние (денежные выплаты и продвижение по службе).

Абрахам Маслоу (Abraham Maslow) в 40-х годах XX века разделил потребности на пять категорий.

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

2.2.2. Эволюция менеджмента

Наводить порядок надо тогда, когда еще нет смуты.
Лао Цзы

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

Особенности европейского менеджмента

Европейский менеджмент имеет очень хорошую теоретическую базу, основанную на работах Макса Вебера (Германия), Анри Файоля (Франция), Кароля Адамецки (Польша) и многих других. Приведем несколько принципов управления Файоля [Психология 2000].

Особенности американского менеджмента

Менеджеры как социальная группа составляют в Америке около 15% работающего населения. Условием квалифицированного руководства считается соблюдение трех правил.

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

Об особенностях американского менеджмента в области разработки программного обеспечения и о влиянии передовых информационных технологий на современный бизнес достаточно подробно рассказано в книге Билла Гейтса (Bill Gates) [Гейтс 2001].

О книге Билла Гейтса
Следует понимать, что данная книга предназначена для менеджеров, которые хотят познакомиться с передовыми методами ведения бизнеса. Программисты не найдут в ней практически ничего полезного для своей профессиональной работы. Интересную семантику заложили издатели в оформление обложки книги. Там крупными буквами написано Билл Гейтс и под именем нарисован значок @. Значок соответствует в английском языке предлогу "at" (являющемуся атрибутом адресов электронной почты), но традиционно произносится русскоязычными программистами как "собака". Это подчеркивает неоднозначное отношение программистов к Биллу Гейтсу.

Особенности японского менеджмента

На основе анализа деятельности японских компаний, И. Олстон сформулировал пять основных принципов японского менеджмента [Психология 2000].

Особенности российского менеджмента

Понимание необходимости целенаправленной подготовки специалистов для управленческой деятельности на научной основе сложилось в нашей стране лишь в 60-е годы XX века. Российский менеджмент должен учитывать особенности национальной психологии, исторический опыт, традиции и ценности, которые веками складывались в России. Существует ряд приоритетных ценностей, на которые российский менеджмент должен опираться [Психология 2000].

2.2.3. Методы управления проектами

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов XX века [Филлипс, Гарсиа-Диас 1984]. С помощью этих методик руководитель проекта может:

Следующие два метода были разработаны параллельно и независимо.

Для описания современных проектов, в которых связи между работами значительно сложнее, данные средства оказались недостаточными. Метод сетевого планирования описывает зависимости работ средствами теории графов [Романовский 1999].

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

Подчеркнем в виде неформальных требований необходимость наличия плана [Баранов 1998].

Заметим, что первое действие процесса планирования - это принятие решения о начале планирования.

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

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

Работа не может начаться раньше, чем будут выполнены все предшествующие ей работы. Продолжительность выполнения всего проекта не может быть меньше, чем сумма продолжительностей работ, входящих в любой путь от начального до заключительного события. Длиной пути назовем сумму продолжительностей работ, входящих в путь. Критическим путем будем называть путь наибольшей длины [Романовский 1999]. Наибольший риск в выполнении проекта будет иметь задержка в работах на критическом пути.

Методики оценок времени и затрат

Существует несколько методик оценок времени и затрат для составления планов и расчетов [Баранов 1998].

О формуле для оптимистов
Оптимистам после ряда провала сроков можно предложить "осторожную" формулу: O*Pi*e, где Pi и е - известные математические константы.

Распределение работ

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

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

2.2.4. Современные подходы к управлению проектом

Став бригадиром, я упростил этот процесс до мыслимого предела.
Б. Ерофеев. "Москва - Петушки"

Продолжающиеся непрерывные неудачи в крупных программных проектах заставили министерство обороны США сформировать подразделение, которое получило название Сеть менеджеров по разработке программного обеспечения (Software Program Managers Network - SPMN) (http://www.spmn.com). Для этой организации были сформулированы четыре главных цели ее работы.

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

Перечислим основные практики.

2.3. Анализ требований и проектирование

2.3.1. Введение в анализ требований и проектирование

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

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

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

Проектирование должно проводиться на двух уровнях:

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

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

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

В основе ведения процессов анализа и проектирования лежат методы, поддерживаемые языками и системами. Методы, объединенные в некоторую совокупность (комбинацию), образуют подходы к анализу и проектированию. Подходы имеют названия, среди которых много именных. Примеры подходов - подход Йордона и ДеМарко (структурная методология) и подход Шлеер и Меллора (объектно-ориентированная методология).

2.3.2. Отступление "о спецификациях"

- Вовочка, ты уже покрасил окна?
-Да, осталось покрасить только рамы!
Анекдот о необходимости точных спецификаций

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

Средства спецификации - любые средства получения или построения таких описаний.

Язык спецификации - рационально оформленный и синтаксически организованный набор таких средств.

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

Существует точка зрения об относительности понятия спецификации [Агафонов 1984]. Имея дело с одной и той же задачей, данные люди в данном окружении (включающем их знания, языки и т. п.) будут склонны считать спецификацией одно, а другие люди в другой обстановке - совсем другое. Например "х := х + i" будет лучшей спецификацией задачи "увеличить х на единицу" для человека, знакомого с оператором присваивания и его обозначением.

Средства спецификации, которые допускают машинную обработку, мы будем классифицировать по уровню формализации и по способу представления [Деметрович, Кнут, Радо 1989].

По уровню формализации выделим три класса.

Существует два основных способа представления спецификаций:

2.3.3. Отступление "об архитектуре"

Архитектура программного продукта - это его строение как оно видно (или должно быть видно) извне его, т. е. представление программного продукта как системы, состоящей из некоторой совокупности взаимодействующих подсистем [Жоголев 1996]. В качестве таких подсистем обычно выступают отдельные программы.

Следующее определение принадлежит Криспену (http://www.sei.cmu.edu/architecture/definitions.html): Архитектура состоит из (а) стратегии разделения и (б) стратегии объединения. Стратегия разделения заключается в делении монолитной системы на дискретные, полностью покрывающие ее части (или компоненты). Стратегия объединения заключается в явном определении интерфейсов между этими компонентами.

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

Выделяют следующие классы архитектур программных продуктов [Майерс 1980], такие как:

Можно определить четыре структуры, которые в совокупности описывают программную архитектуру [Ахтырченко, Леонтьев 2001].

Кроме этих четырех часто используются и другие структуры.

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

Мэри Шоу (Mary Shaw) и Дэвид Гарлан (David Garlan) предложили использовать каталог архитектурных стилей [Shaw, Garlan 1996].

Идентификация и документирование таких архитектурных стилей позволяет программистам использовать их в качестве стартовой точки. Хорошие примеры архитектурных паттернов (шаблонов) и каркасов проектирования приведены в книге [Гамма, Хелм, Джонсон, Влиссидес 2001].

2.3.4. Отступление "о классификации всего сущего"

Женщина.
Исихара Икидаэ (XI век). Из цикла "стихотворения из одного слова"

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

Большинство окружающих нас объектов относится к категориям, рассмотренных в книге [Шлеер, Меллор 1993].

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

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

2.3.5. Проектирование архитектуры (проектирование "в большом")

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

Структурная методология

Проектирование архитектуры (проектирование "в большом") для структурной методологии включает следующие основные методы:

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

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

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

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

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

Объектно-ориентированная методология

Проектирование архитектуры для объектно-ориентированной методологии включает следующие основные методы [Шлеер, Меллор 1993]:

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

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

2.3.6. Проектирование модулей (проектирование "в малом")

Жизнь без начала и конца. Нас всех подстерегает случай.
Александр Блок

Структурная методология

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

Диаграмма "сущность-связь" (Entity-Relation Diagram - ERD) - предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношений между ними.

При создании таких моделей рассматривают понятия:

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

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

Объектно-ориентированная методология

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

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

Объекты на диаграмме располагаются в виде вершин графа. Связи соединяют вершины дугами. Связи могут быть аннотированы сообщениями, которые объекты принимают и посылают.

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

Диаграмма развертывания (применения, размещения) (deployment diagram) отображает физические взаимосвязи между программными и аппаратными компонентами системы.

2.3.7. Методы анализа и построения спецификаций

Превосходно, Ватсон, Вы делаете успехи.
Правда, Вы упустили все существенные детали, зато хорошо усвоили метод.
Артур Конан Дойль. "Приключения Шерлока Холмса"

Структурная методология

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

Диаграмма потоков данных (Data Flow Diagram - DFD) - информационная модель, основные компоненты которой - различные потоки данных, переносящие информацию от одного модуля к другому.

Компонентами диаграммы потоков данных являются:

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

Диаграмма функционального моделирования (Structured Analysis and Design Technique - SADT) - модель, состоящая из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга.

В состав диаграммы входят:

Объектно-ориентированная методология

Перечислим основные методы ведения объектно-ориентированного анализа и рассмотрим подробно некоторые из них.

Карты класс-ответственность-кооперация (class-responsibility-collaboration) предназначены для описания классов. Первоначально они были созданы для обучения объектному языку (http://c2.com/doc/oopsla89/paper.html).

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов не содержит информации о временных аспектах функционирования системы.

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

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

Диаграмма объектов (object diagram) может понадобиться, если требуется рассмотреть взаимосвязи между отдельными объектами.

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

Диаграмма вариантов использования (use case diagram) - сценарий, позволяющий лучше понять требования к системе. В состав диаграммы входят:

Диаграмма состояний (statechart diagram) отражает модель поведения объектов в реальном или абстрактном мире. Все объекты имеют некоторый срок жизни:

Для представления этого жизненного цикла предлагается модель состояний, состоящая из:

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

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

Диаграмма последовательности (sequence diagram) предназначена для моделирования еще одной разновидности взаимодействия - взаимодействия во времени. С ее помощью отслеживается поведение взаимодействующих групп объектов. Диаграмма имеет два измерения.

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

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

2.3.8. Подходы к ведению анализа и проектирования

Структурная методология

Итак, комбинации структурных методов образуют структурные подходы. Можно выделить три группы структурных подходов на основе порядка построения модели [Калянов 1996].

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

Как правило, подходы используют две основные группы средств моделирования [Вендров 2000].

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

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

Подход Йордона и ДеМарко (Edward Yordon and Tom DeMarco) является процедурно-ориентированным и наиболее часто используемым (по статистике - в 36,5% случаев) [Калянов 1996]. Подход фокусирует внимание на потоках данных.

В нем интегрированы следующие средства:

Подход Гейна-Сарсона (Chris Gane and Tom Sarson) очень близок к предыдущему. Статистика утверждает, что он применяется в 20,2% случаев [Калянов 1996]. Главной отличительной чертой подхода является наличие этапа моделирования данных, определяющего содержимое хранилищ данных в диаграммах потоков данных в третьей нормальной форме. Этот этап включает:

Подход Джексона (Michael Jackson) ориентирован на данные. Базовая процедура проектирования включает четыре этапа [Калянов 1996], [Кинг 1991].

Объектно-ориентированная методология

Перечислим основные подходы к ведению объектно-ориентированного анализа и проектирования и рассмотрим подробно некоторые из них.

Подход на основе универсального языка моделирования UML (Unified Modeling Language) включает следующие основные типы диаграмм:

Подход на основе языка UML состоит из четырех основных фаз разработки (см. разд. 3.5.3.1), причем работа с диаграммами ведется в основном на второй и третьей фазах.

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

На третьей фазе - построения - продолжается итеративная работа с такими типами диаграмм, как:

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

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

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

Подход Шлеер-Меллора (Sally Shlaer and Stephen Mellor) использует три группы средств для создания модели предметной области.

Для анализа больших предметных областей используются диаграммы, по смыслу близкие к следующим диаграммам языка UML:

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

2.4. Программирование (реализация)

2.4.1. Стиль программирования

Стиль - это отражение мышления.
А. Шопенгауэр

Важнейшая технологическая задача, возникающая в процессе программирования, - соответствие единому стилю программирования. Под стилем программирования обычно понимают [Тассел 1985] набор приемов или методов программирования, которые используют опытные программисты, чтобы получить правильные, эффективные, удобные для применения и легкочитаемые программы. Правила хорошего стиля - результат соглашения между опытными программистами. Обычно принципы хорошего стиля программирования являются результатом здравого смысла, исходящего из опыта. Это не набор обязательных правил, установленный раз и навсегда. Брайан Керниган (Brian Kernighan) и Роб Пайк (Rob Pike) [Керниган, Пайк 2001] уточняют, что код должен быть прост и понятен, т. е. обладать следующими свойствами:

Правило стандартизации стиля заключается в том, что если существует более одного способа сделать что-либо и выбор произвольный, то следует остановиться на одном способе и всегда его придерживаться. Особое значение имеет единый стиль программирования в процессе работы над программным текстом в коллективных разработках. В большинстве крупных проектов существуют внутренние документы, определяющие стиль программирования команды разработчиков. Известным примером является документ по стилю программирования разработок GNU (http://www.gnu.org/prep/standards_ toc.html). Применение таких документов приводит к использованию единого стиля, а следовательно, к повышению читабельности и сопровождаемое(tm) программ, а во многих случаях и предотвращению большого класса ошибок. Обратим внимание на то, что есть универсальные рекомендации, а есть рекомендации, связанные с конкретными языками.

Приведем некоторые рекомендации по стилю написания программ на языках С и C++, сгруппировав их в тематические классы. Многие рекомендации имеют обоснование - в некоторых случаях строгое, в других - слабое.

Структура файлов

Приведем рекомендации по именованию файлов.

Опишем рекомендации по длине строк.

Далее представлены рекомендации по организации файлов.

Лексические соглашения

Приведем рекомендации по написанию идентификаторов.

Языковые детали

Рекомендации по выравниванию.

Об отступах
Величина отступа сильно зависит от языка программирования. Существуют языки программирования, в которых вложенность блоков определяется отступом (например, Occam или Python). Co стандартным отступом такие программы становятся просто неправильными.

Рекомендации по написанию выражений.

Рекомендации по объявлению переменных.

Рекомендации по написанию определения функций.

Пример форматирования условного оператора приведен в листинге 3.1.

Листинг 3.1. Пример форматирования условного оператора

if ( some_value > other_value && some_result = NULL && some_calculation()) {

do_something();

and_some_more();

}

else if ( some_value > main_result) {

do_something_else();

}

else {

do_something absolute_else();

}

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

Листинг 3.2. Пример форматирования оператора выбора

switch ( i) {

case 1:

do_something (); break;

case 2: {

do_something_else();

and_some_more();

break;

}

default:

assert(false);

break;

)

Рекомендации по написанию операторов цикла: в основных соглашениях следует опять ориентироваться на условный оператор.

Типичные примеры форматирования оператора цикла приведены в листинге 3.3.

Листинг 3.3. Пример форматирования оператора цикла

for ( i = some_initial_value();

i >= some_other_value();

i = some_new_value()) {

do_something();

and_some_more ();

}

do {

do_something();

and_some_more();

} while ( we_should_do());

Рекомендации по написанию оператора перехода: самое важное (и практически единственное) правило заключается в том, что оператор перехода не следует использовать.

2.4.2. Защитное программирование

Защитное программирование (defensive programming) - это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом [Тассел 1985].

Существуют три основных принципа защитного программирования.

Теперь дадим несколько рекомендаций по защитному программированию [Тассел 1985].

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

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

На выбор языка программирования влияют четыре основных фактора.

2.5. Тестирование и отладка

Гораздо легче найти ошибку, нежели истину.
Гете

2.5.1. Введение в тестирование и отладку

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

Отладка - процесс локализации и устранения ошибок.

Процессы тестирования и отладки схематически могут быть представлены следующим образом на рис. 3.4 [Липаев 1986]. Тестирование начинается с разработки множества тестов и их исполнения на основе одной из выбранных методик. После сравнения результатов с эталонными начинается либо диагностика проблемы (в случае расхождения результатов), либо оценка достаточности полноты тестирования. Подготовка дополнительных тестов потребуется при недостаточной полноте тестирования, невозможности локализовать проблему с помощью имеющихся тестов и необходимости выполнить контроль сделанного исправления (http://www.testingfaqs.org/).

2.5.2. Тестирование программных продуктов

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

Существуют также разновидности тестирования.

Типичные ошибки

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

Тестовые данные

Для тестирования программ методом черного ящика [Канер, Фолк, Нгуен 2000] готовятся определенные группы тестов.

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

Тестовое покрытие - это набор тестов, покрывающих программу (каждый линейный участок). Тестовое покрытие важно знать, чтобы определить участки кода, пропущенные при тестировании (см. разд. 5.2.5.2).

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

Тестирование программ в процессе разработки

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

Отслеживание ошибок

Проблема или ошибка может быть рассмотрена как некоторый объект в системе, который может находиться в одном из восьми состояний.

2.5.3. Отладка программных продуктов

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

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

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

О первом выловленном баге
На компьютерном жаргоне ошибка в программе называется багом (от англ, bug - жучок). Происхождение этого термина связывают с мошкой, извлеченной в 1947 году из реле компьютера "Марк II". Грейс Мюррей Хоппер приклеила ее в журнал с примечанием "первый случай выловленного бага".

2.6. Ввод программы в действие

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

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

Следует отметить, что в целом ряде случаев (например, работа с программой через Интернет) такое действие, как инсталляция (установка) программы, уходит в прошлое. Тем не менее, приведем правила хорошего тона при подготовке инсталляции (http://www.softshape.com/swrus/faq_swrus.html).

2.7. Эксплуатация и сопровождение

Под сопровождением будем понимать все действия по повышению надежности программного продукта после завершения отладки и разработку усовершенствованных версий. Пожалуй, основным принципом сопровождения является закон Биледи (Laszlo Belady): используемый программный продукт подвергается непрерывным изменениям для поддержания его экономической выгоды [Гласе, Нуазо 1983].

Перечислим четыре основные класса задач, решаемых на этапе сопровождения.

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

Для решения указанных задач выбирается один из следующих, наиболее подходящих типов сопровождения [Conger 1994], под которым будем понимать степень вмешательства в программу:

На выбор типа сопровождения влияют два фактора.

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

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

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

Источниками ("возбудителями") основных классов задач сопровождения могут быть:

Теперь рассмотрим - как четыре основных класса задач по сопровождению решаются применительно к компиляторам.

2.8. Завершение эксплуатации

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

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

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

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

Bourabai Research Institution home page

Bourabai Research - Технологии XXI века Bourabai Research Institution