КАМАЕВ В.А., КОСТЕРИН В.В

ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ

ПРЕДИСЛОВИЕ

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

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

Данная книга ориентирована именно на решение данных проблем.

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

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

Авторы книги сделали максимум возможного, чтобы избежать привязки только к одному языку программирования. Иллюстрирующие примеры даются в основном на языках Pascal и Object Pascal, являющихся «языком эксперанто» для программистов. Авторы надеются, что знание других процедурно-ориентированных и объектно-ориентированных языков программирования, например С, C++, позволит без дополнительного обучения понять суть иллюстрирующих примеров.

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

Согласно квалификационному справочнику должностей руководителей, специалистов и других служащих (утв. постановлением Минтруда РФ от 21 августа 1998 г. № 37) (с изменениями от 21 января, 4 августа 2000 г., 20 апреля 2001 г.), обязанности, знания, навыки и умения инженера-программиста (программиста) характеризуются следующими нормативами.

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

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

— разрабатывать технологию решения задачи по всем этапам обработки информации;

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

— определять информацию, подлежащую обработке средствами вычислительной техники, ее объемы, структуру, макеты и схемы ввода, обработки, хранения и вывода, методы ее контроля;

— выполнять работу по подготовке программ к отладке и проводить отладку;

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

— осуществлять запуск отлаженных программ и ввод исходных данных, определяемых условиями поставленных задач;

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

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

— определять возможность использования готовых программных продуктов;

— осуществлять сопровождение внедренных программ и программных средств;

— разрабатывать и внедрять системы автоматической проверки правильности программ, типовые и стандартные программные средства;

— составлять технологию обработки информации;

— выполнять работу по унификации и типизации вычислительных процессов;

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

Должен знать:

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

— виды программного обеспечения;

— технико-эксплуатационные характеристики, конструктивные особенности, назначение и режимы работы ЭВМ, правила ее технической эксплуатации;

— технологию автоматической обработки информации;

— виды технических носителей информации;

— методы классификации и кодирования информации;

— формализованные языки программирования;

— действующие стандарты, системы счислений, шифров и кодов;

— порядок оформления технической документации;

— передовой отечественный и зарубежный опыт программирования и использования вычислительной техники;

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

— основы трудового законодательства;

— правила и нормы охраны труда.

Требования к квалификации:

— Инженер-программист I категории: высшее профессиональное (техническое или инженерно-экономическое) образование, стаж работы в должности инженера-программиста II категории не менее трех лет.

— Инженер-программист II категории: высшее профессиональное (техническое или инженерно-экономическое) образование, стаж работы в должности инженера-программиста III категории или других инженерно-технических должностях, замещаемых специалистами с высшим профессиональным образованием, не менее трех лет.

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

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

Профессионализм — это интегральная личностная характеристика человека. Профессиональный программист — это программист [24], который:

• овладел нормами профессиональной деятельности и общения и осуществляет их на высоком уровне, добиваясь профессионального мастерства в своей области (программировании);

• следует профессиональной ценностной ориентации, соблюдая профессиональную этику;

• развивает свою личность средствами профессии;

• стремится внести творческий вклад в профессию, обогащая ее опыт;

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

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

Костерин В.В. осуществил сбор, анализ, синтез нового материала для написания учебника, провел его апробацию в учебном процессе. Камаев В.А. отбросил не менее 90 % собранного материала и, неоднократно редактируя текст учебника, сделал его понятным. Авторы выражают благодарность всем специалистам и студентам за замечания в адрес учебника.

ВВЕДЕНИЕ

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

До конца 70-х годов программирование, как правило, было работой отдельных одаренных людей. Из-за несовершенства первых методик программирования даже относительно короткие программы (длиной около 600 строк) создавались в течение нескольких месяцев.

Начало 80-х годов соответствовало широкому внедрению в практику программирования методов проектирования, заимствованных из техники. Например, по примеру техники, внедряется ГОСТ 19.102—77, регламентирующий стадии и этапы программных разработок. Данный стандарт входит в группу стандартов единой системы программной документации (ЕСПД). ЕСПД сыграла значимую положительную роль в практике отечественного программирования и пережила без значительных изменений уже несколько новых технологий программирования, например, технологию структурного программирования и технологию объектно-ориентированного программирования.

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

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

С появлением систем авоматизированного проектирования (САПР) в 80-х годах были сделаны обобщения теории проектирования технических систем и устройств с выявлением инвариантов в виде проектных процедур, особенно эвристических. Были намечены пути и сделаны первые попытки их автоматизации. Наиболее высокую трудность представляет автоматизация ранних этапов проектирования. На этих этапах для удовлетворения потребности преодоления дискомфорта необходимо синтезировать идеи реализации систем и устройств.

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

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

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

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

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

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

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

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

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

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

В восьмой главе рассматривается технология объектно-ориентированного проектирования. Разбираются основные понятия технологии. Даются шаги этапов выполняемых работ. Рассматриваются примеры выполнения проектов малой и средней сложности.

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

В десятой главе раскрывается понятие САПР программных разработок, основанных на CASE-средствах, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения программного проекта и разрабатывать приложения в соответствии с информационными потребностями пользователей. В главе рассматривается CASE-средство Rational Rose фирмы «Software Corporation» (США), предназначенное для автоматизации этапов анализа и проектирования программных систем, а также для генерации кодов на различных языках и выпуска проектной документации.

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

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

Приложение 1 необходимо для понимания стадий и этапов разработки программ по ГОСТ 19.102—77, но оно не заменяет, возможно, изменившийся текст стандарта.

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

Приложение 3 дает представление о фонде эвристических приемов проектирования программ.

Приложение 4 содержит описание элементов языка программирования Object Pascal, оно необходимо для лучшего понимания гл. 8 и 9.

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

Глава 1

МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1. ОБЩИЕ ПОЛОЖЕНИЯ ТЕОРИИ ПРОЕКТИРОВАНИЯ

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

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

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

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

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

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

Необходимость в проекте вызвана сложностью задачи.

Следующий пример показывает нелинейную зависимость роста сложности задачи от ее размера. Необходимо в уме сложить числа 4 и 3. Ответ, разумеется, — 7. Необходимо в уме перемножить числа 7 и 9. Ответ, конечно, — 63. Но если не знаете таблицу умножения, то надо выполнить нестандартное преобразование в виде многократного сложения. Трудно ли оно для вас? Необходимо в уме перемножить числа 289 и 347. Если вы не феноменальный счетчик, то хватит ли в вашей голове оперативной памяти? А сможете ли вы перемножить в уме шестизначные числа? Но если декомпозировать данную задачу на вычисление ряда произведений одного из сомножителей на отдельные цифры другого сомножителя и затем найденные произведения сложить (при этом записывать на бумаге все промежуточные результаты), то с этой задачей вполне может справиться заурядный человек.

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

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

В табл. 1.1 приведены пять признаков сложной системы вместе с примерами. Эти признаки инвариантны как для осязаемой системы из реального мира «музыкальный центр», так и для программной системы — текстового редактора.

Таблица 1.1.

Примеры музыкального центра и текстового редактора как сложных систем

Признаки

Музыкальный центр

Текстовый редактор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектной ситуацией называют реальность (ситуацию), в которой ведется проектирование. Паровоз и электровоз проектировались в разных проектных ситуациях, определенных уровнем знаний человечества. Именно поэтому XIX в. стал веком паровоза.

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

— информация об условии (условие задачи) — что задано;

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

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

Проектная задача (англ. Engineering Task) характеризуется неопределенностью априори информации: что требуется получить, что задано. Более того, способ решения задачи является объектом проектирования. И наконец, решение проектной задачи должно быть найдено в рамках ограничений внешней среды проектирования: доступных денежных средств, заранее заданных сроков, возможностями технических средств и инструментария программирования, научных знаний, программных заделов и т. д.

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

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

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

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

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

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

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

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

Методика (от греч. methodike) — упорядоченная совокупность методов практического выполнения чего-нибудь.

Методики проектирования излагаются в виде описаний проектных процедур и проектных операций.

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

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

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

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

Современное значение слова «алгоритм» во многом аналогично таким понятиям, как рецепт, процесс, методика, способ. Согласно Д. Кнуту [17], алгоритм имеет пять важных свойств.

Конечность. Алгоритм всегда должен заканчиваться после выполнения конечного числа шагов.

Определенность. Каждый шаг алгоритма должен быть точно определен.

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

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

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

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

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

Инженерия программирования (англ. software engineering, в терминах автоматизированных систем — разработка программного обеспечения) — инженерное дело, творческая техническая деятельность. Инженерия опирается на специфические методы и методики, в том числе эвристические. Инженерия [20] изучает различные методы и инструментальные средства с точки зрения определенных целей, т. е. имеет очевидную практическую направленность. Основная идея инженерии программирования в том, что разработка программного обеспечения является формальным процессом, который можно изучать, выражать в методиках и совершенствовать.

Инженерия программирования имеет четкую определенную дату рождения — 1968 г. Причина ее появления — реакция на так называемый «кризис программного обеспечения», вызванный достижением непреодолимого уровня сложности. Характерные вопросы и задачи инженерии программирования, изложенные Фредериком Бруксом, актуальны и по сегодняшний день.

Как проектировать и строить программы, образующие системы?

Как проектировать и строить программы и системы, являющиеся надежным, отлаженным, документированным и сопровождаемым продуктом?

Как осуществлять интеллектуальный контроль в условиях большой сложности?

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

Важными при разработке процессов проектирования являются такие понятия, как стратегия и тактика.

Стратегия (от греч. stratos — войско и ago — веду) — наука, искусство генерации наиболее существенных общих долгосрочных целей и наиболее общего плана достижения преимущества, курса действий и распределения ресурсов еще до выполнения реальных действий.

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

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

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

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

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

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

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

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

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

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

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

Главное различие между технологией программирования и программной инженерией заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки программ (технологических процессов) в порядке их прохождения — методы и инструментальные средства разработки программ используются в этих процессах (их применение и образуют технологические процессы). В программной инженерии изучаются прежде всего методы и инструментальные средства разработки программ с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Как эти методы и средства образуют технологические процессы — вопрос второстепенный.

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

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

При исследовании систем решаются задачи анализа и синтеза.

Анализ (от греч. analysis — разложение, расчленение) — прием умственной деятельности, связанный с мысленным (или реальным) расчленением на части предмета, явления или процесса.

Синтез (от греч. synthesis — соединение, сочетание, составление) — метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое.

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

В теории проектирования используются следующие понятия анализа и синтеза.

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

Синтез — процесс построения описания системы по заданному функционированию.

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

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

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

1.2. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММ

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

Частотный принцип. Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.

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

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

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

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

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

1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ

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

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

Структурный анализ — выявление элементов объекта и связей между ними.

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

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

Генетический анализ — исследование объекта на его соответствие законам развития программных систем. В процессе анализа изучается история развития (генезис) исследуемого объекта: конструкции аналогов и возможных частей, технологии изготовления, объемы тиражирования, языки программирования и т. д.

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

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

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

Локальная оптимизация подразумевает улучшение параметров внутри каждой простой задачи.

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

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

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

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

1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:

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

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

3) принцип развития, предусматривающий в ПО возможность его наращивания и совершенствования компонентов и связей между ними;

4) принцип комплексности, заключающийся в том, что ПО обеспечивает связанность обработки информации как отдельных элементов, так и всего объема данных в целом на всех стадиях обработки;

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

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

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

1.5. ОСОБЕННОСТИ ПРОГРАММНЫХ РАЗРАБОТОК

Томас Кун в 1977 г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило (modus operandi) развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.

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

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

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

— процедурно-ориентированные — алгоритмы;

— объектно-ориентированные — классы и объекты;

— логически-ориентированные — цели, выраженные в исчислении предикатов;

— ориентированные на правила — правила «если…, то…»;

— ориентированные на ограничения — инвариантные соотношения;

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

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

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

1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ

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

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

Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.

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

В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.

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

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

1.7. ОПИСАНИЕ ЦИКЛА ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

Рис. 1.1. Жизненный цикл программных изделий

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

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

1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ

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

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

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

Стадии и этапы разработки программ по ГОСТ 19.102—77 на момент написания книги даны в приложении 1.

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

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

«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.

«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.

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

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

В соответствии с ГОСТ 19.102—77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).

Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:

• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);

• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);

• РП (около месяца);

• внедрение.

Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.

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

• ТЗ;

• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;

• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;

• внедрение.

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

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

Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:

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

2) определение целей, достигаемых разрабатываемыми программами;

3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;

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

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

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

7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;

8) составление и проверка спецификаций модулей;

9) составление описаний логики модулей;

10) составление окончательного плана реализации программ;

11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;

12) комплексное тестирование;

13) разработка эксплуатационной документации на программу;

14) проведение приемо-сдаточных и других испытаний;

15) корректировка программ по результатам испытаний;

16) окончательная сдача программного изделия заказчику;

17) тиражирование программного изделия;

18) сопровождение программы.

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

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

1.9. ТИПОВЫЕ ОШИБКИ ОБУЧАЕМЫХ ПРИ СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

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

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

Ниже приведены типовые ошибки обучаемых при написании требований к функциональным характеристикам:

• непонимание термина «функциональные характеристики» (Смысл этого термина характеризуется следующим предложением: «Проектируемый завод в нормальном режиме работы должен обеспечить выпуск за одну 8-часовую смену не менее 40 пропашных тракторов». Эта фраза содержит как назначение проектируемого объекта — завода, так и то, что выпускает завод и при каких ограничениях. Применительно к программам, для правильного написания требований к функциональным характеристикам необходимо сторонними глазами будущего пользователя рассмотреть, что делает полезного программное изделие и при каких ограничениях.);

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

• написание заведомо нереализуемых требований.

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

1.10. МОДЕЛИРОВАНИЕ И ПРОГРАММИРОВАНИЕ. ПОНЯТИЕ СПЕЦИФИКАЦИЙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уже в первичных спецификациях можно выделить две части: функциональную и эксплуатационную.

Первичная функциональная спецификация в первую очередь описывает:

— объекты, участвующие в задаче (что делает программа и что делает человек, работающий с этой программой);

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

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

То есть вначале фиксируются внешние функциональные спецификации, а затем и внутренние.

В общем случае внешние функциональные спецификации включают:

— описание того, что делает программа;

— определение, что делает человек, а что машина (по каким эвроритмам работает человек, откуда он берет информацию и как ее готовит к вводу в ЭВМ);

— спецификации входных и выходных данных;

— реакции на исключительные ситуации.

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

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

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

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

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

Рис. 1.2. Абстракция программы как набора процедур, обрабатывающих данные

Рис. 1.3. Абстракция процедуры

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

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

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

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

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

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

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

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

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

На процедурной абстракции основана разработка структуры программы в технологии структурного программирования. Базовая компонента технологии структурного программирования — модуль, которому обычно соответствует подпрограмма (процедура или функция на языках программирования высокого уровня).

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

В технологии абстрактных данных Дейкстры применяется функциональная модель в виде набора диаграмм потоков данных (далее — ДПД; DFD — Data Flow Diagram), которые описывают смысл операций и ограничений. ДПД отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. ДПД — это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах. Фрагменты ДПД показаны на рис. 1.6.

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

Рис. 1.5. Абстракция данных

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

Хранилище данных — это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления либо по ключам.

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

Рис. 1.6. Фрагменты диаграммы потоков данных (ДПД):

а — копирование данных (числа); б — расщепление данных; в — активный объект «Клиент» посредством операции «Нахождение цены» работает с хранилищем «Прайс-лист»

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

Если в структурном программировании главными являются функции и процедуры (действия), то в технологии абстрактных данных Дейкстры во главе ставятся данные.

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

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

Шаг 1. Основываясь на потоке данных в задаче, выделите 3—10 смысловых частей обработки данных.

Шаг 2. Доопределите главный входной и выходной потоки данных задачи.

Шаг 3. Проследите, как следует входной поток от части к части, от входа к концу обработки, найдите эту точку. Проследите от конца к началу, как следует выходной поток; найдите абстрактную точку, где он появился (рис. 1.7).

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

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

Шаг 5. Определите сопряжения подпрограмм по данным.

Рис. 1.7. Превращение главного входного потока информации в выходной поток:

1 — участок соответствует преобразованию информации входного потока в промежуточную информацию; 2 — участок соответствует получению выходной и промежуточной информации из входной и промежуточной информации; 3 — участок соответствует получению выходной информации из промежуточной информации

Современная, вытесняющая технологии структурного программирования и абстракции данных объектно-ориентированная технология сочетает в себе абстракции процедур и данных в новой абстракции — объекте (рис. 1.8). Понятие абстракции данных расширено до того, что как внутренние данные, так и код процедур рассматриваются как новый тип данных — объект.

Объектная модель базируется на двух постулатах: все есть объекты; объекты взаимодействуют передачей сообщений.

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

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

Рис. 1.8. Абстракция объекта

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

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

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

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

1.11. МНЕМОНИКА ИМЕН В ПРОГРАММАХ

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

— соответствовать назначению (из имени должно однозначно следовать его назначение и, наоборот, из назначения — его имя);

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

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

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

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

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

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

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

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

Итак, имя состоит из слов. Пусть длина имени — это количество слов, использованных в этом имени. Имя А является родительским по отношению к имени Б, если длина имени Б больше, чем длина имени А, и первые (слева) слова имени Б совпадают со словами имени А в том же порядке. Имя А можно рассматривать как общий префикс для имен группы Б. Например, имя debug является родительским для имен debug_info, debug_mode, debug_log, debug_error_get, debug_error_set и т. п. Имя debug_error, в свою очередь, является родительским для debug_error_get, debug_error_set.

Имя А является дочерним по отношению к имени Б, если имя Б является родительским по отношению к имени А.

Имена принадлежат одной группе, если эти имена имеют одинаковую длину и одного общего предка А. Длина имени А на единицу меньше длины имен этой группы. В таком случае А будет являться именем этой группы. Например, имена debug_error_get, debug_error_set являются именами группы debug_error. Имена debug__info, debug_mode, debug_log и debug_error, в свою очередь, являются именами группы debug.

Пусть мощность группы А — общее количество имен в этой группе. Префикс имени — это слово, которое записывается самым первым в имени и не учитывается при определении длины, родства и принадлежности группе. Префиксы используют, например, для указания типов переменных или полей: i_count, b_valid, is_protected. i, b, is — префиксы.

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

Если имя А является дочерним по отношению к имени Б, то имя Б является обозначением некоторого объекта. Это означает, что все слова имени, кроме последнего имени, могут быть образованы только именами существительными. Только самое последнее слово в имени может быть существительным, глаголом или прилагательным. Это правило, однако, может иногда нарушаться. Например, есть некоторое действие и набор глобальных настроек (констант), которые контролируют это действие. В таком случае в именах этих констант предпоследним словом будет глагол.

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

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

Пример 2. passport_password_change или passport_password_change — хорошие имена. В системе есть подсистема управления аккаунтами пользователей, называемая passport. Часть этой подсистемы, занимающаяся управлением паролями, называют passport_password. Одну из функций этой части — изменение пароля — называют passport_password_change.

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

Пример 1. ConvertlntegerDateToSQLStrDate — плохое имя. Как вы думаете, вспомните ли вы его с точностью до символа через день?

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

Слово "Date" повторять два раза не нужно, поскольку и исходное данное, и результат являются датой.

Все SQL-запросы в программе — это строки. Поэтому слово "Str" — лишнее.

Пример 2. IntegerDateSQL — приемлемое имя. Есть подсистема управления датами, и эта функция конвертирует дату, представленную в виде целого числа в строку, которую можно использовать в SQL-запросе. Недостатком этого имени является отсутствие активного глагола. Сравните это имя с исходным вариантом примера 1.

В системе не может появиться группа имен мощностью 1.

Пример 1. PASSPORT_DEAD_REMOVE_TIMEOUT — плохое имя, если с умершими пользователями (так на сайте названы пользователи, которые слишком долго не появляются) нельзя производить никаких других операций, кроме удаления.

Пример 2. PASSPORT_DEAD_TIMEOUT — хорошее имя.

Пример 3. passport_is_login_valid — плохое имя. Слово "is" — лишнее.

Пример 4. passport_login_valid — хорошее имя. Есть подсистема управления аккаунтами passport. В ней есть часть, которая занимается управлением логинами пользователей passport_login. Функция passport_login_valid проверяет, является ли "логин" правильным.

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

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

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

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

Слова не в начальной форме могут быть использованы только в том случае, если они используются МНОГО раз и при этом во ВСЕХ местах — одинаково.

Следствие: в качестве последнего слова имени может быть использовано только общепринятое сокращение (или неначальная форма), которое ВЕЗДЕ (и много раз) в программе используется именно в таком варианте. Если сокращение используется редко, то предпочтительнее использовать начальную форму слова.

Пример 1. StrToFloat — плохое имя. В ряде языков программирования есть зарезервированное слово "String". В таком случае получается, что в некоторых случаях к строкам обращаемся по полному имени, а в некоторых — по сокращению. Однако сокращение "Str" — общепринятое в системах программирования фирмы "Borland". При использовании этих систем, но не в SQL-запросах, такое сокращение резонно использовать, и имя StrToFloat становится хорошим именем.

Пример 2. StringToFloat — хорошее имя (если не учитывать наличие лишнего слова "То", но "То" хорошо показывает, что это имя процедуры конвертора типов).

Пример 3. mp_pagelist — хорошее имя, если в группе "mp" много имен или это сокращение используется в таком же написании и таком же смысле большое количество раз в других именах (mp — сокращение от "main page").

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

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

Пример 6. TPassport_Privilege — хорошее имя, однако если бы не велась речь о базах данных, префикс "T" соответствовал бы типу, а не переменной.

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

Случаи, в которых использование префиксов оправдано:

• если это не имена переменных, а имена типов переменных, можно использовать префикс "T";

• если имена ваших сущностей будут перемешиваться с посторонними именами;

• в случае локальных имен.

Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, p и q — для указателей, s — для строковых, а ch — для литерных переменных. Эти традиционные кратчайшие имена могут соответствовать префиксам, поясняющим тип переменных.

Пример 1. is_passport_privilege_valid — плохое имя. Префикс в глобальном имени излишен.

Пример 2. passport_privilege_valid — хорошее имя.

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

Дополнительные рекомендации по составлению имен:

• не начинайте и не заканчивайте имена символом подчеркивания;

• не используйте имена, состоящие только из строчных букв (исключения составляют имена констант и макроопределений);

• не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв — строчной или прописной;

• в зависимости от возможностей языка программирования можно разделять части имен символом подчеркивания или написанием с большой буквы очередной части имени;

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

Ряд понимаемых трудно имен следует тщательно комментировать. Такой комментарий лучше приводить справа от описания имени.

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

Рефакторинг (от англ. refactoring) — оптимизация, улучшение реализации программы без изменения ее функциональности.

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

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

Непонятные имена — это нечитаемая программа, а нечитаемую программу тяжело сопровождать.

Рассмотрим случаи, в которых может потребоваться рефакторинг имен:

Случай 1 — изменение правил. Можно составить разные правила образования имен и следовать сначала одним правилам, потом, уточнив эти правила, следовать другим. Неизменным должно оставаться только одно правило: все имена в проекте должны быть построены по одним правилам.

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

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

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

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

1.12. ПРОБЛЕМА ТИПОВЫХ ЭЛЕМЕНТОВ В ПРОГРАММИРОВАНИИ

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

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

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

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

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

Для тиражирования таких элементов программ, как редактор текстов, система иерархического меню, элементов диалога типа "заполнения бланков" фирма "Borland Inc." предложила применять TPU — Turbo Pascal Unit (модуль OBJ в ряде языков). TPU-файл позволил использовать механизм сокрытия в секции Implementation неинтересных внутренних подпрограмм и внутренних данных и, наоборот, вне файла механизм сокрытия обеспечил открытость вызова только полезных для пользователя процедур и использование внутренних глобальных переменных, описанных в секции Interface. После этого нововведения программисту для использования, например, редактора, написанного не им, надо знать лишь информацию, описанную в секции Interface. Механизм сокрытия информации в пределах файла был введен еще в целый ряд компиляторов разных языков. Реализация механизма сокрытия упростила задачу использования "кубиков".

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

1) механизм классов, порождающих при выполнении любое количество однотипных объектов, например, ряд однотипных кнопок;

2) возможность тиражирования объектов от породившей программы во все новые программы;

3) динамически линкуемые библиотеки с порождающими объекты классами;

4) механизм сборки программ из "кубиков" — объектов в процессе их выполнения.

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

Второй механизм привел к возникновению объектно-ориентированных СУБД, поставляющих программам не только данные, но и код, обрабатывающий эти данные.

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

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

ВЫВОДЫ

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

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

• При разработке программного обеспечения следует использовать следующие общие принципы: частотный; модульности; функциональной избирательности; генерируемости; функциональной избыточности; "по умолчанию".

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

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

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

• Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.

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

• В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.

• Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.

• Каждая стадия проекта завершается утверждением программных документов. Документы включают описания (спецификации). Спецификации являются моделями. Спецификации делятся на внешние и внутренние.

• Рациональный выбор стандартных элементов ("кубиков") имеет два аспекта: удобство при повторном использовании и возможность осуществления синтеза из малых элементов более общих элементов.

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

Контрольные вопросы

1. Дайте определение проектированию.

2. Что такое эвристика?

3. В чем состоит схожесть и различие алгоритма и эвроритма?

4. Что решает задача оптимизации разработки программ?

5. Назовите пять признаков сложной системы.

6. На чем основан частотный принцип разработки программ?

7. Какие виды анализа используются при системном подходе?

8. Что такое принцип совместимости?

9. Для чего необходима стандартизация проектирования и программирования?

10. Назовите основные этапы жизненного цикла программных изделий.

11. Назовите основные стадии и этапы разработки программ по ГОСТ 19.102-77.

12. В чем суть моделирования?

13. Какие типы абстракций вы знаете?

14. Что такое первичная функциональная спецификация?

15. Какие механизмы использования "кубиков" дали объектно-ориентированные языки программирования?

16. Что такое рефакторинг?

17. Зачем нужен рефакторинг имен?

18. Почему трудно определять идеальные имена?

Глава 2

ОПТИМИЗАЦИЯ ПРОГРАММНЫХ РАЗРАБОТОК

2.1. ВЫБОР ОПТИМАЛЬНОГО ВАРИАНТА ПРОЕКТНОГО РЕШЕНИЯ

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

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

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

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

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

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

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

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

2) показатели надежности, характеризующие свойства программной системы сохранять свою работоспособность во времени;

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

4) эргономические показатели, характеризующие систему человек — изделие — среда и учитывающие комплекс гигиенических, антропологических, физиологических и психических свойств человека, проявляющихся в производственных и бытовых условиях;

5) эстетические показатели, характеризующие внешние свойства системы: выразительность, оригинальность, гармоничность, целостность, соответствие среде и стилю;

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

7) патентно-правовые показатели, определяющие число используемых патентов, степень патентной защиты, патентную чистоту;

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

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

2.2. ПРИМЕР ВЫБОРА ОПТИМАЛЬНОГО ВАРИАНТА ПРОГРАММНОГО РЕШЕНИЯ

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

Фирма "Borland Inc.", создав свой компилятор, решила разработать демонстрационную программу, которая могла бы показать наибольшее количество возможностей компилятора. В табл. 2.1 приводятся наименования критериев, варианты реализации программ и оценки по пятибалльной шкале. Эту таблицу составили обучаемые на одном из практических занятий. Ими же были выставлены оценки.

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

Таблица 2.1

Балльная оценка вариантов реализации программы по критериям

Критерии

Варианты реализации

СУБД

ЭТ

ОС

Редактор текстов

Игра

Объем программы

4

4

4

2,5

3

Понятность

2

4

1

5

2

Новые знания

2

4

2

3

2

Интерес

4

3

3

3

5

Использование в собственных разработках

2

5

5

4

1

Система управления базами данных (СУБД) может быть большой или не очень большой программой. Главное в СУБД — мало понятные алгоритмы обработки данных. Интерес для пользователя представляет библиотека обработки данных, а не готовая программа.

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

Операционная система (ОС) может иметь любой объем. Понятность текстов ОС невысокая.

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

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

Фирма "Borland Inc." с ранними разработками компилятора (Turbo Pascal 4.0) поставляла демонстрационную программу простейшей электронной таблицы MicroCalc.

В более позднем дистрибутиве Turbo Pascal 6.00 появилась новая демонстрационная версия электронной таблицы TurboCalc, реализованная с использованием объектно-ориентированной технологии. Поскольку и другие варианты реализации программ вызывают интерес у пользователей, фирма с поздними разработками компилятора начала поставлять и их. Так поставлялись: игра в шахматы с непонятными алгоритмами; текстовый редактор как библиотечная программа; библиотека поддержки работы с базами данных. Сам компилятор в исходном коде фирмой "Borland Inc." никогда не поставлялся.

2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение проводится в два этапа — генерации и анализа. На этапе генерации создается творческая группа из 5—15 человек (специалисты-смежники и люди "со стороны", не имеющие никакого опыта в области, к которой относится решаемая задача). Группе объясняется суть задачи, требующей решения, и проводится этап генерации идей. На этом этапе не допускается критика предлагаемых идей. Поощряется выдвижение даже сумасбродных идей. Затем группа экспертов анализирует высказанные идеи и отбирает те, которые заслуживают более тщательной проработки.

Методом мозгового штурма работают команды знатоков в популярной телепередаче: "Что? Где? Когда?" Пятьдесят секунд идет генерация идей и только десять секунд тратится на обсуждение выдвинутых идей.

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

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

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

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

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

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

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

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

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

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

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

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

Интересно отметить, что число возможных реализаций алгоритмов нелинейного программирования по этой таблице составляет N = 5*6*8*5*7*7*6 = 352800, что значительно превышает число опубликованных методов (около 2000)!

Таблица 2.2

Морфологическая таблица принципов функционирования алгоритмов нелинейного программирования

Классификационные признаки

Значения классификационных признаков

Начальная точка поиска

1.1

1.2

1.3

1.4

1.5

Зондирование гиперповерхности

2.1

2.2

2.3

2.4

2.5

2.6

Стратегия шагов поиска

3.1

3.2

3.3

3.4

3.5

3.6

3.7

3.8

Направление поиска на шаге

4.1

4.2

4.3

4.4

4.5

Стратегия шага поиска

5.1

5.2

5.3

5.4

5.5

5.6

Механизм самообучения

6.1

6.2

6.3

6.4

6.5

6.6

6.7

Механизм завершения поиска

7.1

7.2

7.3

7.4

7.5

7.6

Значения классификационных признаков классификационного признака "Механизм начальной точки поиска":

признак 1.1 — из точки, указанной пользователем;

признак 1.2 — из средней точки области определения;

признак 1.3 — из точки на границе области определения;

признак 1.4 — из случайной начальной точки поиска;

признак 1.5 — начальная точка поиска не задается.

Значения классификационных признаков классификационного признака "Первичное зондирование гиперповерхности":

признак 2.1 — в виде большого числа случайных точек, зондирующих всю гиперповерхность;

признак 2.2 — поочередные спуски из ряда случайных начальных точек;

признак 2.3 — конкурирующие спуски из добавляемых случайных точек;

признак 2.4 — зондирование гиперповерхности случайными точками с выявлением и более тщательным исследованием "подозрительных областей";

признак 2.5 — сканирование всей гиперповерхности с использованием различных разверток, например Пеано;

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

Значения классификационных признаков классификационного признака "Стратегия шагов поиска":

признак 3.1 — один шаг;

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

признак 3.3 — осуществлять все шаги по одному и тому же механизму;

признак 3.4 — переключать механизмы шагов от глобального метода до локального;

признак 3.5 — переключать механизмы шагов от глобальных далее до усредненных и до локальных;

признак 3.6 — переключать механизмы шагов по эвристическим правилам;

признак 3.7 — малое количество последовательных шагов из ограниченного ряда лидирующих конкурирующих начальных точек;

признак 3.8 — шаги поиска отсутствуют.

Значения классификационных признаков классификационного признака "Направление поиска на шаге":

признак 4.1 — новая точка в направлении аппроксимации градиента, построенного на основе данных текущей и предшествующей пробной точек;

признак 4.2 — по результатам обработки небольшого числа перспективных точек, полученных на предшествующих шагах;

признак 4.3 — по результатам анализа функции, аппроксимирующей случайные точки в перспективном направлении;

признак 4.4 — зондирование гиперповерхности большим количеством случайных точек и последующим построением аппроксимирующей функции;

признак 4.5 — вдоль границы области определения целевой функции;

признак 4.6 — механизм отсутствует.

Значения классификационных признаков классификационного признака "Механизм стратегии шага поиска":

признак 5.1 — пробные точки только на расстоянии предполагаемого экстремума;

признак 5.2 — пробные точки на большем расстоянии, чем предполагаемый экстремум;

признак 5.3 — пробные точки на расстоянии, несколько меньшем, чем у предполагаемого экстремума;

признак 5.4 — объединение признаков 5.1 и 5.2;

признак 5.5 — объединение признаков 5.1, 5.2 и 5.3;

признак 5.6 — совмещение поиска направления и расстояния до экстремума;

признак 5.7 — разделение поиска направления и расстояния до экстремума.

Значения классификационных признаков классификационного признака "Механизм самообучения":

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

признак 6.2 — постепенное повышение точности поиска;

признак 6.3 — выявление формы гиперповерхности по результатам предшествующих шагов и переход на специальный механизм уточнения экстремума;

признак 6.4 — выявление формы гиперповерхности по результатам предшествующих шагов и переход на специальный механизм продвижения вдоль оврагов;

признак 6.5 — выявление формы гиперповерхности по результатам предшествующих шагов и отказ от текущего найденного экстремума;

признак 6.6 — изменение плотности вероятности случайных точек для разных зон поиска;

признак 6.7 — механизм отсутствует.

Значения классификационных признаков классификационного признака "Механизм завершения поиска":

признак 7.1 — не выявляется направление улучшения функции на следующем шаге;

признак 7.2 — израсходован ресурс времени;

признак 7.3 — достигнуто заранее заданное значение целевой функции;

признак 7.4 — исчерпаны возможности алгоритма поиска экстремума;

признак 7.5 — выполнено заранее заданное количество шагов поиска;

признак 7.6 — нет улучшений в "дальней" и "близкой" окрестностях.

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

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

2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ

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

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

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

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

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

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

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

Рис. 2.1. Этапы проведения системного анализа информационных систем

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

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

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

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

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

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

1) аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;

2) заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — нет;

3) аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;

4) спецификация системы из-за объема и технических терминов непонятна для заказчика;

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

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

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

• имеется перечень потребностей, которые необходимо удовлетворить;

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

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

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

Как правило, все ошибки начальных этапов, выявленные на последующих этапах, имеют следующие причины:

1) постановка недостижимой цели;

2) стремление разработчика и постановщика задачи упростить задачу;

3) неумение разработчика выделить из формулировки постановщика отдельно описание проблемы и постановку задачи;

4) не выявленные ограничения.

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

Можно сформулировать последовательность рекомендаций (контрольных вопросов):

Рекомендация 1. Не доверяйте имеющимся формулировкам задачи; решение начинайте с нуля, с выделения субъекта, выявления причин его дискомфорта и потребностей. Дело в том, что зачастую формулировка, предлагаемая заказчиком, неудачна или вовсе неприемлема, так как описывает на самом деле неудовлетворенную потребность, выдавая ее за задачу.

Рекомендация 2. Уточните требования к конечному результату:

1) какие функции и с какими показателями качества должен выполнять функции объект?

2) какой эффект будет получен в случае успешного решения задачи?

3) каковы допустимые затраты, как они связаны с показателями качества?

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

Рекомендация 3. Уточните условия, в которых предполагается реализация найденного решения:

1) тщательно исследуйте связанные с этим ограничения и убедитесь, что все они действительно имеют место;

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

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

1) как решаются задачи, близкие к рассматриваемой?

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

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

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

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

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

В процессе анализа рассматриваются:

1) работа без ЭВМ и с ЭВМ с разной степенью автоматизации;

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

3) варианты со специально созданными программами;

4) время обработки информации;

5) стоимость обработки информации;

6) вероятность ошибок, их последствия и качество обработки информации.

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

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

При проектировании необходимо учитывать следующие эффекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап формулировки целей может привести к различным ситуациям.

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

Ситуация 2. Диаметрально противоположный вариант — новые цели. В этом случае мы имеем дело с задачей, у которой имеется в наличии явно видимая цель и отсутствуют средства для ее непосредственного достижения.

2.5. ПРОЕКТНАЯ ПРОЦЕДУРА ПОСТАНОВКИ ЗАДАЧИ РАЗРАБОТКИ ПРОГРАММЫ

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

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

Суть проектной процедуры.

Шаг 1. Проанализируйте выход системы, определите состав и форму выходных данных.

Шаг 2. Проанализируйте вход системы, определите состав и форму входных данных.

Шаг 3. Определите критерии качества преобразования входной информации в выходную информацию.

Шаг 4. Определите ограничения.

Рис. 2.2. Модель "черного ящика" проектируемого объекта

Шаг 5. Определите основные алгоритмы обработки информации и рассчитайте время их выполнения.

Шаг 6. Доопределите ограничения.

Шаг 7. До нахождения приемлемой постановки генерируйте варианты постановок. Используйте классификации алгоритмов, критериев, методов принятия решений, эвристические приемы, практические приемы.

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

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

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

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

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

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

Закономерность 1. С точки зрения потребительских функций: "Чем шире состав потребительских функций, чем интенсивнее количественная сторона их проявления, тем совершеннее система".

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

Попробуйте самостоятельно решить задачу: "Какая из известных вам программ редактора текстов более совершенна?"

Закономерность 2. С точки зрения воздействия факторов внешней среды компьютера: "Чем шире интервал условий внешней среды, внутри которого способны реализовываться потребительские свойства конкретной системы, тем система совершеннее".

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

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

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

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

Какой редактор текстов предпочтительнее: 1) со встроенным орфографическим контролем; 2) с внешней программой орфографического контроля, разработанной иным производителем?

Шаг 1. Сформулировать задачи развития по каждому из потребительских свойств.

Шаг 2. Исследовать и спрогнозировать тенденции развития потребительского спроса по каждому из потребительских свойств.

Шаг 3. На основе прогноза о тенденциях развития потребительского спроса составить полный приоритетный список всех возможных задач совершенствования объекта.

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

Шаг 1. Перечислим основные функции ЭА:

• сканирование;

• распознавание и корректирование ошибок;

• создание и миграция электронных документов и образов;

• индексирование документов;

• оперативный поиск и отображение документов.

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

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

— невозможность хранения образа документов с использованием магнитных дисковых носителей вследствие их высокой стоимости и невысокой надежности без многократного резервирования;

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

— СУБД, особенно реляционного типа, изначально не ориентированы на интенсивную обработку сверхбольшого объема информации.

Шаг 2. Задачи проектирования:

1) развертывание высокопроизводительной сети, включающей графические рабочие станции и мощные серверы ввода и обработки информации;

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

3) обеспечение эффективного индексирования и полнотекстового поиска неструктурированной информации большого объема.

Шаг 3. Возможность технической реализации рассматриваемой системы:

— появились дешевые носители — компактные диски; резко снизился показатель стоимость/производительность для высокоскоростных вычислительных систем, сетей и устройств;

— получили развитие аппаратно-программные системы, реализующие параллельную обработку запросов; повысился уровень интерфейса работы с СУБД;

— появились новые информационные технологии индексирования сверхбольших массивов данных;

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

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

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

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

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

3) из-за высоких требований к скорости доступа к поисковому образу документа и его целостности, осуществление его хранения в высокоскоростных отказоустойчивых системах хранения, например RAID-массивах. Наиболее подходящими носителями могут быть магнитооптические, фазоинверсные (PD/CD), компакт- (CD-R) и WORM-диски. Для автоматизации поиска информации, размещенной на этих дисках, ее извлечения и работе собственно с дисками используются автоматические библиотеки, или оптические дисковые автоматы (JukeBox);

4) использование только мощных масштабируемых RISC-платформ, ориентированных на параллельные вычисления.

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

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

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

Признак 2. Сравнение систем и поиск решения на основе максимального резерва развития.

2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ

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

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

Логический метод рассуждения. У человека он основан на интуиции, использовании накопленного опыта и воображении. Метод ЭВМ — строгий и систематический. Наиболее удачным является сочетание реализованных на ЭВМ отдельных расчетных процедур с определением человеком их логической последовательности.

Способность к обучению. Человек обучается постепенно, степень же "образованности" ЭВМ определяется ее программным обеспечением. Желательно, чтобы количество информации, получаемой на запрос пользователя, было переменным и могло изменяться по требованию пользователя.

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

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

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

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

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

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

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

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

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

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

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

2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ

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

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

Рис. 2.3. Диалог типа вопрос-ответ

Диалог типа меню не является универсальным. Довольно сложно реализовать с использованием диалога данного типа ввод значений в широком диапазоне. Вертикальные меню предпочтительнее горизонтальных. Нежелательно в отдельных меню предлагать более семи тем. Меню с большим количеством тем желательно представить системой иерархической системы подменю. Часто используется в программах меню в стиле фирмы "Lotus" из одного главного горизонтального меню и иерархически построенных остальных вертикальных подменю. Строка единственного главного горизонтального меню придает уверенность начинающему пользователю путем сообщения ему факта о том, что имеется подменю в программе. Диалог типа меню представлен на рис. 2.4.

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

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

Рис. 2.4. Диалог типа меню

Рис. 2.5. Диалог типа заполнения бланков

Рис. 2.6. Диалог на основе команд

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

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

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

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

Рис. 2.7. Диалог типа работы в окнах

Рис. 2.8. Диалог типа по принципу электронной таблицы

Рис. 2.9. Диалог типа гипертекста

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

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

ВЫВОДЫ

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

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

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

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

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

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

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

Контрольные вопросы

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

2. Дайте определение понятия "эвристический прием".

3. Опишите основные шаги, по которым осуществляется системный анализ.

4. Опишите суть проектной процедуры раскрытия проектной ситуации.

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

6. Назовите основные классы существующих программ.

7. Назовите основные особенности взаимодействия человека и ЭВМ.

8. Дайте краткую характеристику основным типам диалога программ.

9. В чем состоит основная задача оптимизации на этапе разработки программ?

Глава 3

ОСНОВНЫЕ ИНЖЕНЕРНЫЕ ПОДХОДЫ К СОЗДАНИЮ ПРОГРАММ

3.1. ОСНОВНЫЕ СВЕДЕНИЯ

Традиционно инженеры стремились, а некоторые из них, не снижая качества проектов, добивались значительного сокращения сроков проектирования. В начале Великой Отечественной войны начальник Центрального артиллерийского конструкторского бюро В.Г. Грабин разработал и применил методы скоростного комплексного проектирования артиллерийских систем с одновременным проектированием технологического процесса. Внедрение этого метода позволило сократить сроки проектирования, производства и испытаний артиллерийских орудий с 30 мес (1939) до 2–2,5 мес (1943), увеличить их выпуск, уменьшить стоимость, упростить эксплуатацию.

Инженерный технологический подход [20] определяется спецификой комбинации стадий разработки, этапов и видов работ, ориентированной на разные классы программного обеспечения и особенности коллектива разработчиков.

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

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

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

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

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

Подходы со слабой формализацией

Подход "кодирование и исправление"

Строгие подходы

Каскадные технологические подходы:

— классический каскадный;

— каскадно-возвратный;

— каскадно-итерационный;

— каскадный подход с перекрывающимися видами работ;

— каскадный подход с подвидами работ;

— спиральная модель.

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

— рациональный унифицированный подход к видам работ.

Генетические технологические подходы:

— синтезирующее программирование;

— сборочное (расширяемое) программирование;

— конкретизирующее программирование.

Подходы на основе формальных преобразований:

— технология стерильного цеха;

— формальные генетические подходы.

Гибкие подходы

Ранние подходы быстрой разработки:

— эволюционное прототипирование;

— итеративная разработка;

— постадийная разработка.

Адаптивные технологические подходы:

— экстремальное программирование;

— адаптивная разработка;

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

— компьютерный дарвинизм.

3.2. РАННИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

Подход "кодирование и исправление" (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколь-либо серьезным проектированием. Все ошибки обнаруживаются, как правило, к концу кодирования и требуют исправления через повторное кодирование.

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

Этот подход может быть рекомендован к использованию в двух случаях:

• для очень маленьких проектов, которые должны завершиться разработкой демонстрационного прототипа;

• для доказательства некоторой программной концепции.

3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

Классический каскадный подход (от англ. pure waterfall — чистый водопад) считается "дедушкой" технологических подходов к ведению жизненного цикла. Его можно рассматривать как отправную точку для огромного количества других подходов. Сформировался классический каскадный подход в период с 1970 по 1985 г. Специфика "чистого" каскадного подхода такова, что переход к следующему виду работ осуществляется только после того, как завершена работа с текущим видом работы (рис. 3.1). Возвраты к уже пройденным видам работ не предусмотрены.

Рис. 3.1. Классический каскадный подход

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

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

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

Каскадный подход с перекрывающимися видами работ (англ. waterfall with overlapping), так же как и классический каскадный подход предполагает проведение работ отдельными группами разработчиков, но эти группы не меняют специализацию от разработки к разработке, что позволяет распараллелить работы и в определенной степени сократить объем передаваемой документации (рис. 3.4).

Рис. 3.2. Каскадно-возвратный технологический подход

Рис. 3.3. Каскадно-итерационный технологический подход

Рис. 3.4. Каскадный подход с перекрывающимися видами работ

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

Рис. 3.5. Каскадный подход с подвидами работ

Рис. 3.6. Спиральная модель

Спиральная модель (spiral model) была предложена Барри Боэмом (Barry Boehm) в середине 80-х годов XX в. с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа — программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется в несколько витков спирали, каждый из которых состоит из "анализа риска", "некоторого вида работ" и "верификации" (рис. 3.6). Обращение к каждому виду работы предваряет "анализ риска", причем если риск превышения сроков и стоимости проекта оказывается существенным, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.

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

3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

Рациональный унифицированный подход к выполнению работ

(rational unified process-RUP), изложенный подробно в десятой главе данного учебника, вобрал в себя лучшее из технологических подходов каскадной группы. Весомое преимущество данного подхода состоит в созданном инструментарии его автоматизированной поддержки — программного продукта Rational Rose фирмы "Rational Software Corpation".

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

Основные особенности данного подхода:

• итеративность с присущей ей гибкостью;

• контроль качества с возможностью выявления и устранения рисков на самых ранних этапах;

• предпочтение отдается моделям, а не бумажным документам;

• основное внимание уделяется раннему определению архитектуры;

• возможность конфигурирования, настройки и масштабирования.

Рис. 3.7. Рациональный унифицированный подход к видам работ

3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

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

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

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

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

— зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу;

— осуществить трансформацию представления (из спецификации в исполняемую программу на языке реализации);

— отладить и протестировать исполняемую программу.

Автоматическая генерация программ по спецификациям возможна для многих языков спецификаций, особенно для SDL, ASN.1, LOTOS, Estelle, UML (Rational Rose).

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

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

— выработка стиля программирования, соответствующего принятым принципам модульности;

— повышение эффективности межмодульных интерфейсов; важность аппаратной поддержки модульности;

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

Рис. 3.8. Сборочное программирование

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

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

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

3. Компонентное сборочное программирование предусматривает распространение классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы, что позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий классов без перекомпиляции использующих их приложений. Существуют конкретные технологические подходы, поддерживающие компонентное сборочное программирование — COM (DCOM, COM+), CORBA, Net. (см. 6.6).

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

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

Наиболее известная технология конкретизирующего программирования — это подход с применением паттернов проектирования (см. 8.6).

Дополнительно к паттернам существуют каркасы (framework) — наборы взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения, в нем аккумулированы проектные решения, общие для проектной области. Например, существуют каркасы, которые используются для разработки компиляторов.

3.6. ПОДХОДЫ НА ОСНОВЕ ФОРМАЛЬНЫХ ПРЕОБРАЗОВАНИЙ

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

Технология стерильного цеха. Основные идеи технологии стерильного цеха (cleanroom process model) были предложены Харланом Миллзом в середине 80-х годов XX в. Технология складывается из следующих частей (рис. 3.9):

• разработка функциональных и пользовательских спецификаций;

• инкрементальное планирование разработки;

• формальная верификация;

• статистическое тестирование.

Процесс проектировании связан с представлением программы как функции в виде так называемых "ящиков":

• черного ящика с фиксированными аргументами (стимулами) и результатами (ответами);

• ящика с состоянием, в котором выделяется внутреннее состояние;

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

Использование ящиков определяют следующие три принципа:

— все определенные при проектировании данные скрыты (инкапсулированы) в ящиках;

— все виды работ определены как использующие ящики последовательно или параллельно;

— каждый ящик занимает определенное место в системной иерархии.

Рис. 3.9. Технология стерильного цеха

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

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

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

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

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

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

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

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

3.7. РАННИЕ ПОДХОДЫ БЫСТРОЙ РАЗРАБОТКИ

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

• итерационную разработку прототипа;

• тесное взаимодействие с заказчиком.

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

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

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

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

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

Рис. 3.10. Эволюционное прототипирование

Рис. 3.11. Итеративная разработка

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

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

3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во время работы в них необходимо учитывать природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).

Экстремальное программирование. Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (extreme programming) (XP) (http://www.extremeprogramming.org). Две основные черты, присущие быстрым разработкам, являются базовыми и в этом подходе. Методы, объединенные в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование дают существенные результаты и успешно выполненные проекты. Наибольшую пользу подход экстремального программирования может принести в разработке небольших систем, требования к которым четко не определены и позднее могут измениться.

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

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

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

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

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

— этап выпуска версии: разработчики устанавливают систему, заказчики принимают работу.

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

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

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

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

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

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

Рис. 3.12. Работа над проектом на основе экстремального программирования

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

• программисты сами пишут тесты для тестирования программы;

• эти тесты пишутся до начала кодирования.

Для любого автономного модуля (класса, процедуры, Unit-модуля) программисты пишут отдельный модульный тест, который должен тестировать все основные варианты использования этого модуля и храниться вместе с ним. Результаты прогонов тестов должны быть лаконичными, например "ОК! (10 tests)". Главное — тест должен писаться до написания самого модуля! Такое тестирование называют опережающим. Внесение изменений на каждой итерации проекта (рефакторинг) всегда сопровождается прогоном всех тестов, чтобы гарантировать стабильную работу системы. Уверенность в нормальной работе как каждого отдельного теста, так и всех тестов комплексного теста придает разработчикам уверенность в нормальной работе очередной версии системы на каждой итерации проекта.

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

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

Рис. 3.13. Работа на итерации экстремального программирования

Рис. 3.14. Коллективное владение кодом при экстремальном программировании

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

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

Адаптивная разработка. В основу подхода адаптивной разработки (Adaptive Software Development — ASD) положены три нелинейных перекрывающих друг друга этапа — обдумывание, сотрудничество и обучение. Автор данного подхода Джим Хайсмит (Jim Highsmith) обращает особое внимание на использование идей из области сложных адаптивных систем.

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

Рис. 3.15. Работа над кодом парой программистов при экстремальном программировании

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

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

3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ

Исследовательское программирование имеет следующие особенности (http://www.osp.ru/pcworld/2001/01/062.htm):

— разработчик ясно представляет направление поиска, но не знает заранее, как далеко он сможет продвинуться к цели;

— нет возможности предвидеть объем ресурсов для достижения того или иного результата;

— разработка не поддается детальному планированию, она ведется методом проб и ошибок;

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

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

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

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

Подход состоит из трех основных видов работ:

• макетирование (прототипирование);

• тестирование;

• отладка.

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

ВЫВОДЫ

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

• Инженерный технологический подход определяется спецификой комбинации стадий и видов работ, ориентированной на разные классы программного обеспечения и на особенности коллектива разработчиков.

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

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

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

• Каркасные подходы представляют собой каркас для видов работ. Одним из ярких представителей каркасного подхода является рациональный унифицированный подход к выполнению работ, поддерживаемый САПР на основе программного продукта Rational Rose фирмы "Rational Software Corporation".

• Термин "генетический" в названии группы генетических технологических подходов связывается с происхождением программы и дисциплиной ее создания.

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

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

Контрольные вопросы

1. За счет чего инженеры добиваются резкого сокращения сроков выполнения проектов?

2. Какие известны основные группы инженерных технологических подходов?

3. Какой классификационный признак положен в основу разделения инженерных технологических подходов на основные группы?

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

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

6. Какой вид работ отсутствует в технологии стерильного цеха?

7. В каких случаях разумно применять эволюционное прототипирование?

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

9. В чем состоит суть адаптивной разработки?

Глава 4

СТРУКТУРА ДАННЫХ ПРОГРАММ

4.1. ПОНЯТИЕ СТРУКТУРЫ ДАННЫХ ПРОГРАММ

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

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

Н. Вирт определил понятие программы следующим образом:

Алгоритмы + структуры данных = программы

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

Что же характеризует данные более содержательно, чем значения? В 1973 г. Н. Виртом была опубликована статья "Типы данных — это не значения". С его точки зрения тип данных — это множество значений. В статье говорилось также, что данные прежде всего характеризуются набором операций, которые можно выполнять над этими данными, множеством значений. Этот взгляд и дал миру впоследствии некоторые очень полезные идеи. Главная формула, которой стали придерживаться:

ТИП ДАННЫХ = МНОЖЕСТВО ЗНАЧЕНИЙ + НАБОР ОПЕРАЦИЙ

Важно понять, что понятия данных и операций очень взаимосвязаны. Пусть есть некоторая структура данных, для которой существует операция Length, которая возвращает длину этой структуры в некоторых единицах. Возникает вопрос: есть ли где-то данные, называющиеся длиной, или нет. С содержательной точки зрения это совершенно неважно. Если эта операция применяется к строкам, признак конца которых ноль (null terminated string), то вычисление длины — это, действительно, операция, требующая вычислений. Если эта операция применяется к строкам, первый байт которых означает длину строки, а дальше идет сама строка (как в Turbo Pascal), то здесь происходит просто взятие данных из памяти, т. е. длина может быть операцией, а может быть данными, хотя это и неважно для программиста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2. ОПЕРАЦИИ НАД СТРУКТУРАМИ ДАННЫХ

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

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

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

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

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

Операция копирования создает копию данных в новом месте памяти.

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

4.3. ОБЩАЯ КЛАССИФИКАЦИЯ ЛОГИЧЕСКИХ СТРУКТУР ДАННЫХ

Упорядоченность элементов структуры данных является важным ее признаком.

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

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

Пример широко известных структур данных с разной упорядоченностью приведен на рис. 4.1.

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

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

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

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

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

Рис. 4.1. Примеры широко известных структур данных

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

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

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

Динамические переменные размещаются в динамически распределяемой области памяти (ДРП). Область ДРП находится вне области кода программы. В зарубежных источниках ДРП обозначается термином "heap" — куча. Обычно заполнение области ДРП осуществляется при помощи стандартных процедур диспетчирования ДРП.

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

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

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

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

— информационного поля, или поля данных, в котором содержатся те данные (в том числе и интегрированные), ради которых оно и создается;

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

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

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

• размер структуры ограничивается только доступным объемом машинной памяти;

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

Недостатки связного представления:

• работа с указателями требует, как правило, более высокой квалификации от программиста;

• на поля связок расходуется дополнительная память;

• доступ к элементам связной структуры может быть менее эффективным по времени.

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

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

4.4. КЛАССИФИКАЦИЯ ВИДОВ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ ПО ИХ ЛОГИЧЕСКОМУ УСТРОЙСТВУ

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

Статический массив — такая структура данных, которая характеризуется:

1) фиксированным набором элементов одного и того же типа;

2) каждый элемент имеет уникальный набор значений индексов;

3) количество индексов определяет мерность массива, например, два индекса — двухмерный массив, или матрица, три индекса — трехмерный массив, один индекс — одномерный массив, или вектор;

4) обращение к элементу массива выполняется по имени массива и значениям индексов для данного элемента.

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

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

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

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

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

<имя переменной — записи>.<имя поля>

В ряде прикладных задач программист может столкнуться с группами объектов, чьи наборы свойств перекрываются лишь частично. Для задач подобного рода развитые языки программирования предоставляют в распоряжение программиста записи с вариантами (union в С, case в Turbo Pascal).

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

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

Базовыми операциями над строками являются:

• определение длины строки;

• присваивание строк;

• конкатенация (сцепление) строк;

• выделение подстроки;

• поиск вхождения.

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

Операция присваивания имеет тот же смысл, что и для других типов данных.

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

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

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

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

Статическая строка (тип String) в языке Pascal представляет собой одномерный массив, в нулевом элементе которого находится дескриптор с количеством символов в строке, а в последующих элементах — коды символов строки.

Главный недостаток статической строки — неизменность физической длины, что приводит к неэффективному расходу памяти.

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

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

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

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

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

Стек — это линейный список с одной точкой доступа к его элементам, называемой вершиной стека. Добавить или убрать элементы можно только через его вершину. Принцип работы стека: LIFO (Last In-First Out — последним пришел — первым исключается).

Основные операции над стеком:

• включение нового элемента (англ. push — заталкивать);

• исключение элемента из стекла (англ. pop — выскакивать).

Вспомогательные операции:

• определение текущего числа элементов в стеке;

• просмотр элементов стека (например, для печати);

• очистка стека;

• неразрушающее чтение элемента из вершины стека (может быть реализовано как комбинация основных операций: pop и push).

Очередь — это линейная структура данных, в один конец которой добавляются элементы, а с другого конца изымаются. Принцип работы очереди: FIFO (First In — First Out — первым пришел — первым вышел).

Дек (от англ. deq — double ended queue) — особый вид очереди в виде последовательного списка, в котором как включение, так и исключение элементов может осуществляться с любого из двух концов списка. Частный случай дека — дек с ограниченным входом и дек с ограниченным выходом.

Разветвленный список, или дерево, — это список, элементами которого могут быть тоже списки.

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

Биранрное дерево — дерево, в каждом узле которого происходит разветвление только на два поддерева (ветви): левое и правое.

Лесом называют конечное множество непересекающихся деревьев.

Граф — сложная нелинейная многосвязная динамическая структура, отображающая свойства и связи сложного объекта, обладает следующими свойствами:

• на каждый элемент (узел, вершину) может быть произвольное количество ссылок;

• каждый элемент может иметь связь с любым количеством других элементов;

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

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

Граф, все связи которого ориентированные, называют ориентированным графом, или орграфом; со всеми неориентированными связями — неориентированным графом; со связями обоих типов — смешанным графом.

Конкретные организации структур данных и алгоритмы реализации операций с ними рассмотрены в [21, 23, 25].

4.5. ПРОЕКТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ

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

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

Пусть требуется спроектировать программу электронной таблицы. Такой проект выполнила фирма "Borland Inc", когда ей понадобилась демонстрационная программа. Обоснование потребности и цели разработки этого проекта были рассмотрены в гл. 2.

Что видит пользователь при работе с электронной таблицей? — Огромный двухмерный массив клеток.

Что пользователь может записать в клетки? — Числовые значения, строки текстов и формулы. Каждая клетка также должна хранить информацию о формате вывода числовых значений (форматы: целый, денежный, научный и т. д.). Значит, каждая клетка должна содержать атрибут того, что находится в клетке: пустая клетка, числовое значение в клетке, строка текста, корректная формула, некорректная формула. Пусть информация о значении числа имеет тип расширенный, вещественный (10 байт); строки текста содержат до 79 символов; информация формулы состоит из поля со значением, рассчитанного по формуле (10 байт), а также поля текста формулы (79 байт). Самая длинная информация у клетки с формулой: информация формата (2 байта), значение, рассчитанное по формуле (10 байт), поле текста формулы (79 байт). Итого длина информации клетки составляет 91 байт.

Пусть программа будет работать с электронной таблицей размером 100 × 100 клеток. Тогда информация электронной таблицы в случае использования структуры данных в виде статической матрицы занимает 91 × 100 × 100 байт = 910 000 байт ≈ 889 кбайт.

Требуемый объем для размещения структуры превышает стандартную память компьютера класса IBM PC XT — 640 кбайт, поэтому надо отказаться от использования структуры данных в виде статической матрицы.

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

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

Например, квадратная матрица, у которой элементы, расположенные симметрично относительно главной диагонали, попарно равны друг другу, называют симметричной. Если матрица порядка n симметрична, то в ее физической структуре достаточно отобразить не n^2, а лишь n(n + 1)/2 ее элементов. Доступ к треугольному массиву организуется таким образом, чтобы можно было обращаться к любому элементу исходной логической структуры, в том числе и к элементам, значения которых, хотя и не представлены в памяти, могут быть определены на основе значений симметричных им элементов. На практике для работы с симметричной матрицей разрабатываются следующие процедуры:

• формирование вектора;

• преобразование индексов матрицы в индекс вектора;

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

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

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

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

• массивы, в которых местоположения элементов со значениями, отличными от фонового значения, могут быть описаны математическими закономерностями;

• массивы со случайным расположением элементов.

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

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

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

Структура данных пустой электронной таблицы в виде статической матрицы теперь занимает (2 + 4) * 100 * 100 = 60 000 байт ≈ 59 кбайт. Объем менее 64 кбайт для единой статической структуры соответствует возможностям Turbo Pascal.

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

По окончании ввода информации в выбранную клетку, если клетка не пустая (значение указателя на структуру клетки * Nil), то освобождается память, выделенная ранее под прежнюю информацию клетки. Новая информация клетки записывается в участок ДРП, равный по объему только полезной информации клетки. В соответствующее поле указателя выбранной клетки записывается значение указателя выделенного участка ДРП. Для записи только полезной информации в клетки применяем записи с вариантами (union в С, case в Turbo Pascal).

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

Пусть электронная таблица заполнена 300 числовыми значениями, 200 текстовыми строками длиной в 40 символов и 400 формулами с текстом формул по 30 символов. В этом случае для размещения электронной таблицы в оперативной памяти потребуется всего

300 * (2 + 10) + 200 * (2 + 41) + 400 * (2 + 10 + 31) = 29 400 байт ≈ 28,8 кбайт.

Как видно, при работе с электронной таблицей объем информации, занимаемой динамической структурой клеток, растет медленно. Окончательно принимаем данный вариант к реализации, выделив из атрибута случай ошибки при расчете формулы в отдельный атрибут Error.

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

Туре

Real = Extended; {Требуется сопроцессор}

Const

{Структура данных электронной таблицы}

MAXCOLS = 100; {Размер таблицы}

MAXROWS = 100;

MAXINPUN = 79; {Длина вводимой строки}

{Значение атрибута вида клетки}

ТХТ = 0; {В клетке текст}

VALUE = 1; {В клетке значение}

FORMULA = 2; {В клетке формула}

{Тип вариантной информации клеток}

Туре

TString = String [MAXINPUT]; {Тип вводимых строк}

TCellRec = record {Тип информации клетки}

Error: Boolean; {Поле ошибки формулы}

case Attrib: Byte of {Attrib — это поле}

TXT: (TextStr: TString); {В клетке текст}

VALUE: (Value: Real); {В клетке значение}

FORMULA: (Fvalue: Real; {В клетке формула}

Formula: TString);

end;

end;

{Тип указателя на тип клетки}

TCellPtr = ^TCellRec;

{Тип элемента таблицы}

TCellTableElement = record

CellFormat: Word: {Формат клетки}

CellPtr: TCellPtr; {Указатель на клетку в ДРП}

end:

{Тип массива информации клеток таблицы}

TCellsTable = array [1..MAXCOLS, 1..MAXROWS] of TCellPtr;

Var {Глобальные переменные}

Cells: TCellsTable; {Статическая матрица всех клеток}

CurCell: TCellPtr; {Указатель на текущую клетку}

CurCol, {Колонка текущей клетки}

CurRow: Word; {Строка текущей клетки}

Как видно, с целью краткости вызовов большинства процедур программы было принято решение об использовании весьма небольшого набора глобальных переменных. При именовании констант использованы только строчные буквы. Имена типов имеют префикс "Т". Имена, используемые часто в паре, выровнены по длине, например: MAXCOLS, MAXROWS, CurCol, CurRow. Два последних имени, используемых парно, были выровнены по длине. При выравнивании сокращено слово column — колонка. Используемые во многих процедурах глобальные имена сделаны краткими.

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

4.6. ФАЙЛОВЫЕ СТРУКТУРЫ

4.6.1. Физическая организация файлов

Файл — упорядоченный набор информации на внешнем носителе (наиболее часто на дисковом носителе).

Физическая информация файла на внешнем носителе соотносится с логической структурой данных оперативной памяти методами доступа операционных систем.

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

• управление файлами: хранение файлов, обращение к ним, их коллективное использование и защита;

• обеспечение целостности файлов — гарантирование того, что файл содержит только то, что требовалось;

• средства управления внешней памятью (распределяют внешнюю память для размещения файлов).

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

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

1) строковое имя файла;

2) тип файла (расширение имени) — информация для пользователя о предполагаемой информации в файле;

3) размещение файла во внешней памяти;

4) тип организации файла (прямой, последовательный, индексно-последовательный и т. д.);

5) тип устройства (несъемный, съемный, допускающий только чтение и т. д.);

6) данные (атрибуты) для контроля доступа (владелец, групповой пользователь, допущенный и общедоступный пользователи);

7) диспозицию (файл постоянный или временный);

8) дату и время создания;

9) дату и время последней модификации.

Элементы перечисления 1, 2 и 3 определяют полное имя файла.

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

Наиболее общими операциями работы с файлами являются следующие операции:

• связывание полного имени файла с файловыми переменными;

• открытие файла (например, для записи, только чтения, изменения длины);

• закрытие файлов;

• установление атрибутов файла.

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

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

4.6.2. Логическая организация файлов

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

Операторы языка Read, ReadLn, Write, WriteLn (при файловой переменной типа Text) обеспечивают работу с файлами единственного типизированного в языке Pascal вида — текстовыми файлами, представляющими собой на логическом уровне последовательность текстовых строк. Сами текстовые файлы на логическом уровне имеют последовательную организацию. Например, чтобы прочитать сотую строку, необходимо до этого прочитать все 99 предшествующие строки. Для текстового файла в языке Turbo Pascal имеется процедура "Append" добавления текстовой информации в конец текстового файла. Процедура "Append" полностью характеризует возможность изменчивости текстовых файлов (в текстовых файлах даже нельзя заменить содержимое одной строки на другую строку).

Операторами языка Read, Write (файловая переменная имеет тип File of тип_записи) также можно последовательно записывать в файл или считывать из файла в той же последовательности одну или несколько записей строго определенного типа (фиксированной длины). Такие файлы называют типизированными или файлами в виде сблокированных записей фиксированной длины. Если записей в типизированных файлах несколько, то при помощи операции "Seek" можно задать любой номер последующей изменяемой или считываемой записи. Таким образом, реализованы методы как последовательного, так и прямого доступа к информации файла, что одновременно образует комбинированный доступ.

Файлам с произвольной организацией на языке Turbo Pascal соответствуют нетипизированные файлы, или бинарные. С любым типизированным файлом можно работать как с нетипизированным файлом.

Нетипизированные файлы в языке Turbo Pascal описываются с помощью зарезервированного слова "File". Обычно работу с такими файлами осуществляют при помощи подпрограмм BlockRead, BlockWritte, Seek. Также к нетипизированным файлам могут быть применены все стандартные средства работы с файлами, кроме Read, Write, Flush. При использовании процедуры "Seek" каждый блок нетипизированного файла рассматривается как физическая запись длиной 128 байт.

Текстовые файлы Turbo Pascal (как в кодировке MS DOS, так и в Windows) обычно имеют расширение (тип) txt и в бинарном (физическом) представлении представляют собой одну запись произвольной длины, содержащую последовательность всех символов строк, заканчивающихся символами "0D_16", "0A_16". Последним символом файла (необязательно) может быть символ "1A_16", являющийся признаком конца текстового файла. Символ "0D_16" (CR) — возврат каретки без продвижения бумаги. Символ "0A_16" (LF) — передвижение бумаги на одну строку вниз.

Таким образом, можно рассматривать типизированный текстовый файл как нетипизированный (бинарный), состоящий из одной записи в виде массива символов.

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

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

4.6.3. Документирование файлов

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

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

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

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

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

Практика показала, что использование документации файлов, составленной сторонними фирмами по второму и особенно по третьему способу не вызывало затруднений.

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

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

При разработке структуры файла были добавлены следующие глобальные описания:

Const

{Характеристики файла}

FILEIDENT = 'My Spreadsheet'; {Идентификатор}

FILESEXTENSION = 'MSS'; {Стандартный тип файла}

Var

FeleName: String; {Имя файла таблицы}

{Видимая ширина колонок таблицы}

ColWidth: array [1..MAXCOLS] of Byte;

{Информация о заполнении таблицы}

LastCol, {Последняя заполненная колонка таблицы}

LastRow: Word; {Последняя заполненная строка таблицы}

Локальные описания:

Var

EndOfFile; Char; {Признак конца текстового файла}

Col; Word; {Номер колонки клетки}

Row; Word; {Номер столбца клетки}

Count; Word; {Число заполненных клеток таблицы}

Size; Word; {Длина информации клетки}

CPtr; TCellPtr; {Указатель на клетку}

F; File; {Файловая переменная}

Blocks; Word; {Прочитано или записано байт}

Файл хранения электронной таблицы является файлом постоянного хранения, бинарным произвольной длины; имеет имя, определенное пользователем, но с расширением имени "MSS".

Организация заголовочной части файла электронной таблицы представлена в табл. 4.1.

Таблица 4.1

Заголовочная часть файла электронной таблицы

Оперативная информация

Длина оперативной информации, байт

Комментарий

FILEIDENT

Length (FILEIDENT)

Константа строки идентификации

EndofFile

SizeOf (EndOfFile)

Признак конца текстового файла

LastCol

SizeOf (LastCol)

Последняя заполненная колонка таблицы

LastRow

Sizeof (LastRow)

Последняя заполненная строка таблицы

Count

Sizeof (Count)

Число заполненных клеток таблицы на участке таблицы (1, 1, LastCol, LastRow)

ColWidth

Sizeof (ColWidth[1] * MAXCOLS)

Вектор ширин колонок таблицы от 1 до MAXCOLS

Запись в файл EndOfFile со значением 26_10 = 1A_16 (Ctrl + Z) обеспечивает вывод на экран только строки идентификации при просмотре файла с помощью большинства программ просмотра текстовых файлов.

При чтении файла электронной таблицы считанная информация первой текстовой строки файла проверяется на совпадение с FILEIDENT.

Информация о заполнении таблицы характеризует участок таблицы (1, 1, LastCol, LastRow), в пределах которого пользователь внес изменения информации таблицы.

Значение Count при записи рассчитывается с использованием двух вложенных циклов, задающих номера всех клеток на участке таблицы (1, 1, LastCol, LastRow). В циклах значение Count увеличивается на единицу, если значение указателя на информацию клетки ≠ Nil.

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

Таблица 4.2

Информация очередной непустой клетки файла электронной таблицы

Оперативная информация

Длина оперативной информации, байт

Комментарий

Col

SizeOf (Col)

Номер колонки клетки

Row

SizeOf (Row)

Номер строки клетки

Cells [Col, Row].CellFormat

Sizeof (Word)

Формат клетки

Size

Sizeof (Size)

Длина информации клетки

Фактическая информация клетки

Size

Информация клетки

Значение Col, Row определяют сохраняемые или сохраненные в файле координаты каждой непустой клетки. Фрагмент кода программы сохранения информации непустой клетки таблицы приведен ниже:

if Cells [Col, Row].CellPtr <> nil then

begin

CPtr:= Cells [Col, Row].CellPtr;

case CPtr^.Attrib of

TXT: Size:= Length (CPtr^.TextStr) + 3;

VALUE: Size:= Sizeof (Real) + 2;

FORMULA: Size: = Length (CPtr^.Formula) + Sizeof (Real) + 3;

end; {case}

BlockWrite (F, Col, SizeOf (Col), Blocks);

BlockWrite (F, Row, SizeOf (Row), Blocks);

BlockWrite (F, Cells [Col, Row].CellFormat, Sizeof (Word), Blocks);

BlockWrite (F, Size, SizeOf (Size), Blocks);

BlockWrite (F, CPtr^, Size, Blocks);

end;

ВЫВОДЫ

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

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

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

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

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

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

• Файл — упорядоченный набор информации на внешнем носителе (наиболее часто на дисковом носителе).

Контрольные вопросы

1. Что такое структура данных программы?

2. Что понимают под организованностью данных?

3. В какой форме могут представляться данные?

4. Что отражает физическая структура данных?

5. В чем различие между физической и логической структурами данных?

6. Какие операции могут выполняться под структурами данных?

7. Приведите примеры широко известных структур данных.

8. Чем характеризуется статический массив?

9. Что такое строка? Какие бывают виды строк?

10. Назовите простейший метод поиска элемента.

11. Назовите основные операции над стеком.

12. Назовите процедуры для работы с симметричной матрицей.

13. Приведите пример реализации на языке Turbo Pascal структуры данных электронной таблицы.

14. Какие средства содержит файловая система?

15. Какую информацию содержит дескриптор файла или блок управления файлом?

16. С чего, как правило, начинается описание файлов?

17. Какими способами обычно выполняют документирование сложных нетипизированных файлов?

18. Что такое рефакторинг?

19. В каких случаях может потребоваться рефакторинг имен?

Глава 5

ПРОЕКТНАЯ ПРОЦЕДУРА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ ОПИСАНИЙ

5.1. ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТНОЙ ПРОЦЕДУРЕ

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

Программисты могут применять проектную процедуру при написании:

— документальных описаний вычислительных и иных алгоритмов, предназначенных для тиражирования;

— инструкций работы пользователя в системе организации (учреждения) с использованием ЭВМ и разрабатываемой программы;

— описаний внешнего функционирования программы в форме сценария работы программы (такие описания предшествуют внутреннему проектированию программы);

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

— исходных текстов модулей программы при использовании технологии структурного программирования;

— кода методов объектов при использовании технологии объектно-ориентированного программирования;

— текстов помощи по использованию программы.

Умение применять проектную процедуру полезно и непрограммистам. При помощи данной проектной процедуры можно составлять:

• короткие и понятные описания любых процессов;

• приказы и распоряжения на выполнение работ;

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

• описания принципов функционирования изделий;

• описания бизнес-процессов;

• бухгалтерские инструкции по проведению расчетов;

• тексты должностных инструкций организационного обеспечения.

Данный список не является исчерпывающим и возможны все новые применения.

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

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

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

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

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

Помимо апробации в области программирования авторы учебника провели апробацию изложенных в нем методик при обучении непрограммирующих специальностей. Оказалось, что обучение методике разработки функциональных описаний (на примерах составления инструкций вообще, описаний бизнес-процессов) вполне доступно студентам второго курса специальности бухгалтерский учет, даже если они не изучали эту методику в курсе программирования. Более того, половина учеников девятого класса обычной школы вполне способна полностью освоить данный материал. Следует отметить такой факт: до обучения лишь несколько учеников класса реально могли написать план, а потом сочинение. После обучения практически три четверти обучаемых могли написать план, а затем его развить в сочинение, т. е. школьники реально освоили элементы дедуктивного мышления! Затраты на освоение материала составили 8 ч лекционных и 16 ч практических занятий. Таким образом, у обучаемых всего за 24 ч учебных занятий удается развить первичные навыки дедуктивного мышления и владение начальными методами системного подхода.

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

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

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

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

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

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

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

5.2. ИСТОРИЯ ВОЗНИКНОВЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ

С появлением ЭВМ актуальным стал поиск способов описания вычислительных алгоритмов. В 60-х годах уже применялись два способа описания алгоритмов: словесный пошаговый и графический в виде схем алгоритмов программ (жаргонно: блок-схем алгоритмов).

Рис. 5.1. Изображение алгоритма в форме графической схемы алгоритма

При словесно-пошаговом способе алгоритмы описывались по изложенному ниже принципу.

Шаг 1. Выполняется такое-то действие для того-то. Если получается, что А < В, то переходим к шагу 4.

Шаг 2. Выполняется такое-то действие для того-то.

Шаг 3. Если А > В, то переходим к выполнению шага 1.

Шаг 4. Выполняется такое-то действие для того-то.

Шаг 5. Если А > В, то переходим к выполнению шага 2.

Изображение того же алгоритма в форме схемы алгоритма приведено на рис. 5.1.

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

Таблица 5.1

Недостатки словесно-пошагового и графического способов в виде схем описания алгоритмов программ

Способ описания

Недостатки

Словесно-пошаговый

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

Графический в виде схем алгоритмов программ

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

До конца 70-х годов проектная процедура получения алгоритмов базировалась на операционном (маршрутном) мышлении, которое закладывается еще в школе математическими и физическими учебными дисциплинами. Операционный подход не требует свободного владения дедуктивным мышлением и основан на более простом и уже освоенном индуктивном мышлении "от частного к общему". При операционном мышлении сначала записываются последовательные действия по главному основному маршруту. Затем эти действия дополняются операциями ветвления (if), операциями безусловного перехода (go to) и дополнительными действиями других маршрутов.

В результате использования операционного подхода получались программы (подпрограммы) со структурными элементами в виде операторов языка программирования и единственной сверхсложной структурой "вся программа" типа "спагетти" — множеством неупорядоченных передач управлений вперед и назад (см. рис. 5.1). Все это можно отнести и к большинству текстовых инструкций.

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

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

Составлению описания проектной процедуры предшествовали труды Дейкстры (с концепцией программирования без go to), одна из первых работ по структурному кодированию программ [9] и длительный опыт программирования и преподавания авторов.

5.3. ОБЩЕЕ ОПИСАНИЕ ПРОЕКТНОЙ ПРОЦЕДУРЫ

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

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

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

При разработке эвроритмов инструкций входная, промежуточная и выходная информация характеризуется набором предметов (физических и документов) и их состоянием, например: пустой чайник; чайник, заполненный наполовину объема холодной водой; включен выключатель "сеть" в правом верхнем углу панели; документ по форме № 5 с заполненной первой графой. Здесь уместно дополнять описания предметов их рисунками. Учитывайте, что предметы изменяются во времени и пространстве.

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

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

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

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

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

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

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

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

Структуре СЛЕДОВАНИЕ в инструкциях и программах соответствует строго одно действие.

Далее проектная процедура выполняется итеративными шагами: до достижения элементарных действий (элементарных операторов языка программирования или элементарных операций) отдельные структуры СЛЕДОВАНИЕ, из которых состоит описание любого алгоритма или эвроритма, декомпозируются с соблюдением принципа от общего к частному одной из трех стандартных структур (рис. 5.2): ЦЕПОЧКА СЛЕДОВАНИЙ; ЦЕПОЧКА АЛЬТЕРНАТИВ; ПОВТОРЕНИЕ.

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

Рис. 5.2. Выявление вида очередной структуры при выполнении проектной процедуры разработки функциональных описаний

Из трех выявленных структур любая структура содержит в себе одну или несколько новых структур вида СЛЕДОВАНИЕ с более частными действиями. Эти новые СЛЕДОВАНИЯ могут подвергаться декомпозиции на следующей итерации выполнения проектной процедуры.

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

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

Таблица 5.2.

Сводная таблица характеристик структур и признаков структур

Структура

Характеристики

Признак

СЛЕДОВАНИЕ

Описывается либо простыми распространенными предложениями естественного языка, либо предложениями без сказуемого (например, "Погрузка мебели", "Решение квадратного уравнения")

Соответствует строго одному действию

ЦЕПОЧКА СЛЕДОВАНИЙ

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

Последовательно выполняемые разнородные действия

ЦЕПОЧКА АЛЬТЕРНАТИВ:

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

простая АЛЬТЕРНАТИВА

Описывается конструкцией: "Если выполняется какое-то условие, то выполняется СЛЕДОВАНИЕ 1"

АЛЬТЕРНАТИВА из двух действий

Описывается конструкцией: "Если выполняется какое-то условие, то выполняется СЛЕДОВАНИЕ 1, в противном случае выполняется СЛЕДОВАНИЕ 2"

ВЫБОР

Представляет собой цепочку из более чем двух простейших альтернатив с одним действием

ПОВТОРЕНИЕ:

Многократно выполняемое действие (но обязательно конечное число раз). Повторениям соответствуют мысли: "Это действие должно быть выполнено пять раз"; "Это действие выполняется многократно до наступления такого-то события". Признаками ПОВТОРЕНИЙ также являются переменное количество АЛЬТЕРНАТИВ, любая мысль о возврате "назад", чтобы повторить какие-то действия. Часто главный общий процесс вида ПОВТОРЕНИЕ скрыт в контексте "и т. д." или "и т. п.", "это совсем просто", или даже в многоточиях "…"

ПОВТОРЕНИЕ "ДО"

Описывается конструкцией: "До выполнения какого-то условия многократно выполнять СЛЕДОВАНИЕ"

ПОВТОРЕНИЕ "ПОКА"

Описывается конструкцией: "Пока выполняется какое-то условие, многократно выполнять СЛЕДОВАНИЕ"

НЕУНИВЕРСАЛЬНОЕ ПОВТОРЕНИЕ

Обеспечивает заданное количество повторений

Набор эвристических приемов:

1. "Хорошие наглядные иллюстрации — залог успеха!".

2. "Думай от общего к частному!".

3. "Общий процесс определяет работу частных!".

4. "Это не главный процесс, вы увязли в частностях!".

5. "Не забывай вводить новые термины (имена переменных)!".

6. "Выделив главное действие, вы уже решаете более простую задачу!".

7. "Если закончилась информация в обобщающих тестах, то готовьте новые обобщающие тесты для решения все новых частных задач!".

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

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

Каждое СЛЕДОВАНИЕ соответствует строго одному действию. Главное в действиях — глагол. Основное, что необходимо выполнить при описании отдельной структуры СЛЕДОВАНИЕ: в описании должна содержаться лишь одна мысль. Любая структура вида СЛЕДОВАНИЕ может быть описана простым распространенным предложением естественного (русского) языка. Например, "Следующее действие заключается в погрузке мебели в автомобиль". Однако учитывая то, что в случае составления алгоритмов программ суть типовых структур поясняется самими операторами языка программирования, применяется более краткое описание в виде неполного предложения без сказуемого. В последнем случае подлежащее образуют от глаголов. Например, "Погрузка мебели", "Решение квадратного уравнения", "Ввод данных".

Порядок детализации одиночного СЛЕДОВАНИЯ с использованием модели "черного ящика" показан на рис. 5.2; 5.3:

1) предварительное выявление сути действия;

2) выявление выходной информации, ибо выход определяет вход, а не наоборот;

3) выявление входной информации;

Рис. 5.3. Модель "черного ящика"

4) запись уточненного комментария сути действия или одного заключительного элементарного оператора.

При описании физических и технических систем необходимо использовать более полную модель "черного ящика" (см. рис. 2.2).

ЦЕПОЧКА СЛЕДОВАНИЙ соответствует однозначному описанию последовательности действий.

Признаком ЦЕПОЧКИ СЛЕДОВАНИЙ является никогда не нарушаемая последовательность действий (последовательность СЛЕДОВАНИЙ). ЦЕПОЧКЕ СЛЕДОВАНИЙ соответствует последовательность простых предложений и сложносочиненные предложения, которые лучше преобразовать в простые предложения.

Порядок детализации ЦЕПОЧКИ СЛЕДОВАНИЙ показан на рис. 5.4:

1) предварительное выявление сути действий каждого из СЛЕДОВАНИЙ, определение количества СЛЕДОВАНИЙ;

2) детализация каждого из СЛЕДОВАНИЙ как одиночного СЛЕДОВАНИЯ;

Рис. 5.4. Порядок действий при детализации структуры ЦЕПОЧКА СЛЕДОВАНИЙ

3) проверка информационной согласованности всех СЛЕДОВАНИЙ, а также входной и выходной информации всей ЦЕПОЧКИ СЛЕДОВАНИЙ;

4) рационализация порядка СЛЕДОВАНИЙ (сосредоточение СЛЕДОВАНИЙ, сотрудничающих в информационном обмене);

5) сверка с обобщающими тестами.

Отдельные СЛЕДОВАНИЯ структуры ЦЕПОЧКА СЛЕДОВАНИЙ в дальнейшем могут быть декомпозированы ЦЕПОЧКОЙ СЛЕДОВАНИЙ (более частных). Однако встречаются отдельные структуры СЛЕДОВАНИЯ, которые не могут быть декомпозированы ЦЕПОЧКОЙ СЛЕДОВАНИЙ. Такие СЛЕДОВАНИЯ могут быть описаны или структурой вида ЦЕПОЧКА АЛЬТЕРНАТИВ (ВЕТВЛЕНИЕ), или структурой вида ПОВТОРЕНИЕ (ЦИКЛ).

Признаком ЦЕПОЧКИ АЛЬТЕРНАТИВ или ВЫБОРА является одно или несколько действий, каждое из которых выполняется при определенном условии или не выполняется вообще (обязательно конечное число разных действий при разных условиях).

ЦЕПОЧКА АЛЬТЕРНАТИВ, в частном случае, может состоять из одной или нескольких простейших альтернатив с одним действием. Предложение простейшая АЛЬТЕРНАТИВА с одним действием имеет следующую конструкцию: "Если выполняется какое-то условие, то выполняется такой-то процесс (СЛЕДОВАНИЕ)". (В противном случае СЛЕДОВАНИЕ пропускается.) Предложение АЛЬТЕРНАТИВА из двух действий имеет следующую конструкцию: "Если выполняется какое-то условие, то выполняется СЛЕДОВАНИЕ 1, в противном случае выполняется СЛЕДОВАНИЕ 2". В принципе структура АЛЬТЕРНАТИВА из двух действий эквивалентна цепочке из двух простейших альтернатив с одним действием. При детализации процессов, включающих более двух альтернатив, может быть получена единая структура— ВЫБОР в виде цепочки последовательно записанных структур АЛЬТЕРНАТИВА с одним действием. Здесь следует отметить, что от внешне похожей ЦЕПОЧКИ СЛЕДОВАНИЙ, каждое СЛЕДОВАНИЕ которой является простейшей АЛЬТЕРНАТИВОЙ с одним действием, структура ВЫБОР отличается таким свойством, что при выполнении всей ЦЕПОЧКИ АЛЬТЕРНАТИВ может выполняться лишь одно из альтернативных СЛЕДОВАНИЙ или ни одного из альтернативных СЛЕДОВАНИЙ.

Пример условий альтернатив в случае структуры ВЫБОР:

Если А < В, то выполнить СЛЕДОВАНИЕ1;

Если А = В, то выполнить СЛЕДОВАНИЕ2;

Если А > В, то выполнить СЛЕДОВАНИЕЗ.

АЛЬТЕРНАТИВОЙ с одним действием можно осуществить досрочное прекращение процесса выполнения алгоритма в том случае, который соответствует обнаружению условий невозможности правильного дальнейшего выполнения алгоритма или эвроритма.

Детализациям всех последующих структур предшествует нулевое действие — запись в начале и в конце входных и выходных данных, выявленных в процессе детализации предшествующих им СЛЕДОВАНИЙ.

Порядок детализации ЦЕПОЧКИ АЛЬТЕРНАТИВ показан на рис. 5.5:

1) предварительное выявление сути действия каждого из СЛЕДОВАНИЙ альтернативных действий, определение количества таких СЛЕДОВАНИЙ;

Рис. 5.5. Порядок действий при детализации цепочки АЛЬТЕРНАТИВ, согласно проектной процедуре разработки функциональных описаний

2) детализация каждого из СЛЕДОВАНИЙ как одиночного СЛЕДОВАНИЯ;

3) выявление и запись логического условия выполнения каждого из альтернативных СЛЕДОВАНИЙ;

4) проверка информационной согласованности всех СЛЕДОВАНИЙ и логических условий в цепочке, а также входной и выходной информации всей ЦЕПОЧКИ АЛЬТЕРНАТИВ;

5) рационализация порядка альтернатив;

6) проверка выполнения всех маршрутов на тестах, полученных из обобщающего теста.

Признаком ПОВТОРЕНИЯ является многократно выполняемое действие (но обязательно конечное число раз). ПОВТОРЕНИЯМ соответствуют мысли: "Это действие должно быть выполнено пять раз"; "Это действие выполняется многократно до наступления такого-то события". Признаки ПОВТОРЕНИЙ — переменное количество АЛЬТЕРНАТИВ, любая мысль о возврате "назад", чтобы повторить какие-то действия. Часто главный более общий процесс вида ПОВТОРЕНИЕ прячется в контексте "и т. д." или "и т. п.", "это совсем просто", или даже в многоточиях "…".

Предложение вида ПОВТОРЕНИЕ может быть записано или в форме ПОВТОРЕНИЕ "ДО" (ЦИКЛ "ДО"), или в форме ПОВТОРЕНИЕ "ПОКА" (ЦИКЛ "ПОКА").

Предложение ПОВТОРЕНИЕ "ДО" имеет следующую конструкцию: "До выполнения какого-то условия многократно выполнять СЛЕДОВАНИЕ".

Предложение ПОВТОРЕНИЕ "ПОКА" имеет следующую конструкцию: "Пока выполняется какое-то условие, многократно выполнять СЛЕДОВАНИЕ".

Разница между предложениями ПОВТОРЕНИЕ "ДО" и ПОВТОРЕНИЕ "ПОКА" заключается в том, что, согласно первому предложению, действие СЛЕДОВАНИЕ должно быть выполнено хотя бы один раз, а согласно второму, — СЛЕДОВАНИЕ может не выполняться ни разу.

Структура НЕУНИВЕРСАЛЬНОЕ ПОВТОРЕНИЕ или просто обеспечивает заданное количество повторений какого-либо процесса или выполнение какого-то процесса при значении переменной цикла, значение которой изменяется по правилам арифметической прогрессии.

Порядок детализации ПОВТОРЕНИЙ показан на рис. 5.6.

Детализация повторений ведется в вариантной постановке

Рис. 5.6. Порядок действий при детализации ПОВТОРЕНИЙ

1) выявление и запись логического условия завершения ПОВТОРЕНИЯ "ДО" или условия продолжения выполнения ПОВТОРЕНИЯ "ПОКА";

2) выявление действий прекращения выполнения повторения;

3) выявление действий СЛЕДОВАНИЯ подготовки выполнения ПОВТОРЕНИЯ;

4) детализация СЛЕДОВАНИЯ оставшегося действия как одиночного СЛЕДОВАНИЯ;

5) проверка информационной согласованности всех СЛЕДОВАНИИ, логических условий, а также входной и выходной информации всего ПОВТОРЕНИЯ;

6) проверка на 2–3 тестах, полученных из обобщающего теста;

7) окончательный выбор варианта реализации ПОВТОРЕНИЯ в виде структуры ПОВТОРЕНИЕ "ПОКА" или в виде структуры ПОВТОРЕНИЕ "ДО".

5.4. РЕКОМЕНДАЦИИ НАЧИНАЮЩИМ ПО СОСТАВЛЕНИЮ ОПИСАНИЙ АЛГОРИТМОВ И ЭВРОРИТМОВ

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

Выполнение проектной процедуры начинается с подготовки и рассмотрения тестовых примеров для детализации всего описываемого процесса в виде одного СЛЕДОВАНИЯ.

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

Параллельно с подготовкой тестов осуществляем анализ модели "черного ящика". Берем еще один чистый лист бумаги, внизу листа записываем термины выходных объектов и их состояния. Применительно к алгоритмам определяем структуру данных: вводим обозначения переменных, последовательностей, векторов, матриц и определяем порядок размещения в них информации. Применительно к физическим системам определяем месторасположения и состояния объектов. Например, чайник без воды находится на полке. Результат действий — чайник, заполненный кипятком до половины объема, находится на плите. Выход определяет вход, а не наоборот! Поэтому сначала записываются результаты действий и лишь затем состояния объектов до действий.

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

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

Обучаемым, которые находятся на начальной стадии изучения, рекомендуется предварительно описать протекание процесса по принципу: "Как можешь!" Качество описания должно соответствовать попытке объяснения процесса какому-то заурядному человеку или даже ребенку. Данный текст поможет (с использованием признаков) отличить общие действия от частных.

Наконец, приступаем к составлению семантического скелета структурированного описания функционирования.

При обучении детализации очередной структуры следует осуществлять на отдельном листе. При детализации ЦЕПОЧЕК СЛЕДОВАНИЙ рекомендуется ориентировать лист узкой стороной вверх, а при детализации ЦЕПОЧЕК АЛЬТЕРНАТИВ и ПОВТОРЕНИЙ лист лучше ориентировать широкой стороной вверх (это позволит размещать на листе трассы просчета тестов). Предварительно в верхней части листа записывается предложение, которое было получено ранее из детализации каждого из этих процессов в виде одного СЛЕДОВАНИЯ. Под ним записывается входная информация СЛЕДОВАНИЯ, а внизу листа — выходная информация. Далее осуществляется сама детализация, результаты которой после проверки на тестовых примерах и литературной обработки переносятся в чистовик описания алгоритма в целом.

При детализации ЦЕПОЧКИ СЛЕДОВАНИЙ равномерно по свободной части листа записываются предложения сути последовательно выполняемых действий (конкретный смысловой комментарий к процессу). Далее осуществляется работа над каждым из них как над отдельным СЛЕДОВАНИЕМ. Далее осуществляется проверка информационной согласованности следований и рационализируется их порядок, уточняется суть СЛЕДОВАНИЙ. При проверке необходимо убедиться, что для последующих СЛЕДОВАНИЙ данные уже были определены предшествующими СЛЕДОВАНИЯМИ.

При детализации ЦЕПОЧКИ АЛЬТЕРНАТИВ равномерно по свободной части листа записываются (в количестве альтернативных действий) конструкции в виде нужного количества следующих последовательных предложений: слово "Если", несколько чистых строк для поля условия, слова "то выполняется действие", далее оставляется несколько чистых строк для предложения СЛЕДОВАНИЕ (конкретный смысловой комментарий процесса).

После детализация всех записанных СЛЕДОВАНИЙ как одного СЛЕДОВАНИЯ осуществляется запись условий выполнения альтернативных процессов. Далее осуществляется проверка информационной согласованности входа и выхода каждого из СЛЕДОВАНИЙ, их условий выполнения, а также входной и выходной информации всей ЦЕПОЧКИ АЛЬТЕРНАТИВ. Цепочка только из двух альтернатив может быть описана предложением вида: "Если выполняется условие (конкретное условие выполнения действия по ТО), то выполняется процесс (конкретный смысловой комментарий процесса), в противном случае выполняется иной процесс (конкретный смысловой комментарий процесса).

При детализации ПОВТОРЕНИЙ на свободной части листа записываются слова обоих заготовок для ПОВТОРЕНИЯ "ДО" и ПОВТОРЕНИЯ "ПОКА". Каждая заготовка начинается с чистых строк для будущего СЛЕДОВАНИЯ определения подготовки повторяющихся действий. Далее для ПОВТОРЕНИЯ "ДО": записывается строка "До выполнения условия окончания повторяющегося процесса"; оставляется несколько чистых строк для записи условия окончания повторяющегося действия; записывается строка "многократно выполняется следующее действие:…". Для ПОВТОРЕНИЯ "ПОКА" записывается строка "Пока выполняется условие"; оставляется несколько чистых строк для записи условия продолжения выполнения повторяющегося действия; записывается строка "многократно выполняется следующее действие:…". Под этими строками на обеих заготовках оставляются чистые строки для СЛЕДОВАНИЯ, определяющего окончание повторения процесса и СЛЕДОВАНИЯ многократно выполняемого действия. Заполнение заготовок осуществляется в следующем порядке: сначала условие окончания (продолжения для ПОВТОРЕНИЯ "ПОКА") выполнения повторяющегося действия; затем записывается СЛЕДОВАНИЕ, определяющее окончание повторения процесса; потом — СЛЕДОВАНИЕ определения подготовки повторяющихся действий и в последнюю очередь — СЛЕДОВАНИЕ многократно выполняемого действия. Далее осуществляется проверка информационной согласованности входа и выхода каждого из СЛЕДОВАНИЙ, условия выполнения действия, а также входной и выходной информации всей структуры. Если до начала детализации не было ясно, какой из вариантов повторений рациональнее детализировать в первую очередь, то последовательно детализируются обе заготовки. Окончательный вариант отбирается путем их сравнения по критериям краткости и понятности.

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

5.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССА "КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ"

Ниже показано пошаговое выполнение проектной процедуры на примере разработки описания процесса "Кипячение воды в чайнике". Дополните данное описание наглядными рисунками на листе 1 самостоятельно.

Лист 2. Анализ процесса как одного СЛЕДОВАНИЯ.

Первичное описание сути действия: "Кипячение воды в чайнике".

Выход: Чайник, заполненный кипятком до половины объема, находится на газовой плите. Конфорка выключена.

Вход: Чайник без воды находится на полке. Конфорка выключена. Требуемый объем кипятка — половина чайника.

Окончательное описание сути действия: "Получение чайника, заполненного кипятком до заданного объема".

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

Нами получено СЛЕДОВАНИЕ (рис. 5.7).

Лист 3 — содержит изображение процессов инструкции в наглядной форме. Разработайте его самостоятельно.

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

Рис. 5.7. Детализация с применением графического изображения "черного ящика"

Лист 5. Декомпозиция процесса "Получение чайника, заполненного кипятком до заданного объема".

Первоначально на лист переносим информацию предшествующей структуры СЛЕДОВАНИЕ, получаем макет листа, представленный на рис. 5.8.

Далее, исходя из соображений, что для этого процесса необходимо выполнить ряд последовательных действий, получаем макет листа с ЦЕПОЧКОЙ СЛЕДОВАНИЙ, представленный на рис. 5.9.

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

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

Действие 1 может быть декомпозировано еще одной ЦЕПОЧКОЙ СЛЕДОВАНИЙ, изображенной на рис. 5.11.

Рис. 5.8. Первоначальный вид листа 5

Рис. 5.9. Вид листа 5 после предварительного выявления сути действий

Действие 1 "Заполнение чайника водой" может быть декомпозировано еще одной ЦЕПОЧКОЙ СЛЕДОВАНИЙ, изображенной на рис. 5.11.

Действие 4 "Наполнение чайника водой", показанное на рис. 5.11, декомпозируется ПОВТОРЕНИЕМ, представленным на рис. 5.12.

Рис. 5.10. Окончательный вид листа

Декомпозиция цепочкой СЛЕДОВАНИЙ действия "Анализ процесса заполнения чайника на форс-мажорные обстоятельства" представлена на рис. 5.13.

Рис. 5.11. Детализация СЛЕДОВАНИЯ "Заполнение чайника водой", выявленного на рис. 5.10

Действие "Форс-мажорное завершение инструкции" представляет цепочку СЛЕДОВАНИЙ, показанной на рис. 5.14. Обратим внимание на то, что выходная информация аварийного завершения инструкции определяется входной информацией всей инструкции (см. рис. 5.7).

Рис. 5.12. Декомпозия ПОВТОРЕНИЕМ действия 4 "Наполнение чайника водой" (см. рис. 5.11)

Рис. 5.13. Декомпозиция ЦЕПОЧКОЙ СЛЕДОВАНИЙ действия "Анализа процесса заполнения чайника на форс-мажорные обстоятельства" (см. рис. 5.12)

Рис. 5.14. Декомпозиция действия "Форс-мажорное завершение инструкции" представляет цепочку СЛЕДОВАНИЙ

Действие 2 (см. рис. 5.10) "зажигание газовой горелки" декомпозируется циклом: пока не зажглась конфорка или не выявлены форс-мажорные обстоятельства, многократно выполнять действие "Зажигание конфорки". Дальнейшее развитие алгоритма позволило выявить структуры, изложенные далее.

Действие (СЛЕДОВАНИЕ) "Зажигание конфорки" представляет собой ЦЕПОЧКУ СЛЕДОВАНИЙ: "Зажигание спички", "Включение газа", "Поджигание газа", "Отключение газа при неудаче", "тушение спички", "выбрасывание спички". Форс-мажорными обстоятельствами является отсутствие газа или окончание спичек. Им соответствует логическая переменная.

Действие (СЛЕДОВАНИЕ) "Отключение газа при неудаче" представляет собой альтернативу: если газ не зажегся, а спичка прогорела, то необходимо закрыть газ.

Здесь выявлена предшествующая недоработка с выходными данными действия 2. Ведь по окончании действия 2 конфорка может быть как включена, так и не включена. Исправить ситуацию можно двумя способами. По первому способу за действием 2 можно вставить простейшую альтернативу с одним действием: если выявлены форс-мажорные обстоятельства, то аварийно завершить инструкцию. Согласно второму способу, действия 3, 4, 5 могут быть представлены одним СЛЕДОВАНИЕМ, внутри которого должна находиться ЦЕПОЧКА АЛЬТЕРНАТИВ последовательного выполнения каждого из прежних действий 3, 4, 5 при условии отсутствия выявления форс-мажорных обстоятельств.

5.6. ПРИМЕР ОПИСАНИЯ ПРОГРАММЫ "РЕДАКТОР ТЕКСТОВ"

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

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

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

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

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

После осуществляется очистка буферного массива редактора строковых переменных из 5 * 23 = 115 строк длиной по 225 символов.

Далее при параметре "Первая строка файла" выполняется алгоритм "Загрузка строк файла, начиная с указанной строки в буферный массив редактора". Потом до подачи пользователем одной из команд завершения редактирования с сохранением информации (или без сохранения) выполняется главный цикл программы. Наконец, если была дана команда завершения с сохранением информации, то информация из буферного массива переписывается в файл. Выполнение программы завершается очисткой экрана.

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

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

5.7. РЕФАКТОРИНГ АЛГОРИТМОВ И ЭВРОРИТМОВ

Алгоритм Нелдера — Мида является широко известным и применяется в качестве алгоритма прямого поиска локального экстремума вещественных функций от 2 до 6 вещественных переменных.

Следующий абзац содержит фрагмент текста из книги Д. Химмельблау [26], в котором содержится часть описания алгоритма Нелдера — Мида (метода деформируемого многогранника).

В методе Нелдера и Мида минимизируется функция n независимых переменных с использованием n + 1 вершин деформируемого многогранника в En. Каждая вершина может быть идентифицирована вектором x. Вершина (точка) в En, в которой значение f(x) максимально, проектируется через центр тяжести (центроид) оставшихся вершин. Улучшенные (более низкие) значения целевой функции находятся последовательной заменой точки с максимальным значением f(x) на более "хорошие" точки, пока не будет найден минимум f(x).

Начальный многогранник обычно выбирается в виде регулярного симплекса (но это не обязательно) с точкой в начале координат. Процедура отыскания вершины в En, в которой f(x) имеет лучшее значение, состоит из следующих операций:

Отражение — проектирование x(k)h через центр тяжести в соответствии с соотношением x(k)n+3 = x(k)n+2 + α(x(k)n+2 — x(k)h), где α > 0 является коэффициентом отражения; x(k)n+2 — центр тяжести, x(k)h — вершина, в которой функция f(x) принимает наибольшее из n + 1 ее значений на k-м этапе.

Растяжение выполняется, если f(x(k)n+3) ≤ f(x(k)i), то вектор (x(k)n+3 — x(k)n+2) растягивается в соответствии с соотношением x(k)n+4 = x(k)n+2 + γ(x(k)n+3 — x(k)n+2), где γ — коэффициент растяжения. Если f(x(k)n+4) < f(x(k)i), то x(k)h заменяется на x(k)n+4 и процедура продолжается с шага 1 (k = k + 1), иначе x(k)n заменяется на x(k)n+3, процедура продолжается с шага 1 (k = k + 1).

Сжатие — если f(x(k)n+3) > f(x(k)i) для всех i ≠ h, то вектор (x(k)h — x(k)n+2) сжимается в соответствии с формулой x(k)n+5 = x(k)n+2 + β(x(k)h — x(k)n+2), где 0 < β < 1 представляет собой коэффициент сжатия. Затем x(k)h заменяется на x(k)n+5 и переходит на шаг 1 (k = k + 1).

Редукция — если f(x(k)n+3) > f(x(k)h), все векторы (x(k)i — x(k)1), i = 1…n + 1 уменьшаются в 2 раза с отсчетом от x(k)1 в соответствии с формулой x(k)i = x(k)i + 0,5(x(k)i — x(k)1), i = 1…n + 1. Затем возвращаемся к шагу 1 для продолжения поиска на k + 1 шаге.

Критерий окончания поиска, использованный Нелдером и Мидом, состоял в проверке условия среднего квадратичного отклонения функций f(x(k)i) от произвольного малого числа ε.

Химмельблау воспользовался традиционным математическим стилем для изложения описания алгоритма. Алгоритм имеет структуру вида "спагетти", что видно из схемы алгоритма, разработанной автором (рис. 5.15). Схема в виде "спагетти" — это скрытые go to, которые мы обнаруживаем в тексте программы, разработанной автором. Он же приводит графические рисунки принципа расчета точек и графический рисунок последовательности продвижения лучших точек симплекса по шагам метода при решении тестовой задачи. Затратив 11 страниц текста, приведя текст неструктурированной программы на 12 страницах, автор книги [26] так и не сумел понятно описать свой алгоритм.

Рис. 5.15. Схема алгоритма, разработанная Д. Химмельблау

Сравните способ подачи описания алгоритма, составленный автором [22], и функциональное описание алгоритма после рефакторинга. Функциональное описание алгоритма приведено ниже.

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

Вводимая информация:

n — число переменных минимизируемой функции;

X^0 = (x^0_1, x^0_2…, x^0n) — точка первого начального приближения;

h — шаг регуляризации симплекса;

εx — погрешность нахождения экстремума по параметрам.

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

Процедура регуляризации симплекса состоит в копировании во все поля значений аргументов симплекса значения вектора X^0, и далее производятся изменения значений диагональных компонент векторов с номерами от 2 до n + 1 путем их увеличения на шаг регуляризации симплекса h.

В симплексе Q_1, Q_2, Q_3…, Qn+1 — это рассчитанные значения минимизируемой функции при соответствующих по строке значениях аргументов минимизируемой функции.

Далее до выполнения условия окончания поиска осуществляются итерации (шаги) поиска. Условием окончания поиска этого метода является неудаленность от лучшей точки симплекса остальных точек симплекса более чем на e^2x.

Каждая итерация начинается с нахождения номеров l и k, соответственно лучшей и худшей по значению функции точек симплекса. Далее осуществляется расчет точки Xц — положения центра масс всех точек симплекса за исключением наихудшей точки 1. Это позднее улучшение алгоритма. Д. Химмельблау не исключал наихудшей точки.

где n — количество точек в симплексе; i — номер компоненты вектора X(i = 1, 2…, n); j — номер точки в симплексе.

Считаются нулевыми значения xkj слагаемых сумм, где k — номер наихудшей точки.

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

Xα = Xц + α(Xц — Xk), Xβ = Xц + β(Xц — Xk), Xγ = Xц + γ(Xц — Xk).

Целесообразно эти похожие формулы реализовать одной функцией.

Значения коэффициентов α = 1, β = 0,5 и γ = 2 подобраны экспериментальным путем (в оригинале описания алгоритма эти значения можно выявить лишь из текста программ). Расчет точек α, β, γ целесообразно осуществлять одной процедурой с параметром в виде значений коэффициентов α, β, γ.

После расчета точки Xц вычисляется пробная точка α. Далее выполняется одно из альтернативных действий.

Если Qα ≤ Q_1, то выполняются действия достижения сильного успеха. Если Q_1 ≤ Qα < Qk, то имеется слабый успех, а точка α записывается на место k-точки. Если Qα ≥ Qk, то выполняются действия отсутствия успеха. Рассчитывается Xβ и Qβ. Далее, если Qβ ≤ Qk, то точка β записывается на место k-точки, иначе, если точка β хуже точки k, выполняется процедура редукции симплекса и процедура расчета значения функции в точках симплекса.

Действия достижения сильного успеха. Рассчитывается Xγ и Qγ. Наилучшая из точек α или β записывается на место наихудшей k-точки симплекса.

Действия отсутствия успеха. Рассчитывается Xβ и Qβ. Далее выполняется действие по изменению симплекса при отсутствии успеха.

Действие по изменению симплекса при отсутствии успеха представляет собой альтернативу: если Qβ ≤ Qk, то точка β записывается на место k-точки, иначе, если точка β хуже точки k, выполняется процедура редукции симплекса.

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

5.8. КОДИРОВАНИЕ ТИПОВЫХ СТРУКТУР НА ЯЗЫКАХ ПРОГРАММИРОВАНИЯ

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

Кодирование программы должно осуществляться только с использованием стандартных структур! Запрещено использование меток, операторов безусловного перехода на метку (go to), операторов досрочного выхода из структуры break!

При кодировании на языке С оператор break может использоваться только при кодировании структуры switch.

При использовании другого процедурно-ориентированного языка программирования (не Pascal) необходимо предварительно закодировать на используемом языке программирования все описанные в этом подразделе стандартные структуры без изменения их логики!

Так, при программировании на языке С структура УНИВЕРСАЛЬНЫЙ ЦИКЛ — "ДО" будет включать операцию "!" (НЕ):

/* подготовка цикла */

do

{

/* Тело цикла */

…

}

while (! (L));

В приведенной выше структуре ненулевое значение переменной L соответствует окончанию выполнения цикла, а не его продолжению выполнения, как в операторе языка программирования! Использование "линией" операции (!) НЕ никак не удлинит программу. Современные компиляторы автоматически инвертируют логическое условие завершения цикла.

Структуре СЛЕДОВАНИЕ в программах могут соответствовать: выполнение всей программы; вызов процедуры.

Согласно стандарту проекта, АЛЬТЕРНАТИВА имеет четыре конструкции. Рассмотрим их запись на языке программирования Pascal.

Конструкция для одной альтернативы:

if L then begin

{Действие при L=True}

…

end;

Конструкция для двух альтернатив:

if L then begin

{Действие при L=True}

…

end

else

begin

{Действие при L=False}

…

End;

Первый вариант конструкции для нескольких альтернатив (ВЫБОРА):

if L1 then Begin

{Действие при L1=True}

end;

…

if L2 then

begin

{Действие при L2=True}

…

end;

if L3 then

begin

{Действие при L3=True}

…

end;

Второй вариант конструкции для нескольких альтернатив (ВЫБОРА):

Switch:= 0;

L1:=…;

L2:=…;

L3:=…;

…

if L1 then Switch:= 1;

if L2 then Switch:= 2;

if L3 then Switch:= 3;

…

case Switch of

1:begin

{Действие при L1=True}

…

end;

2:begin

{Действие при L2=True}

…

end;

3:begin

{Действие при L3=True}

…

end;

else

begin

{Вывод сообщения об ошибочном кодировании модуля}

…

end;

end; {End of Case}

Рассмотрим запись вариантов кодирования структуры АЛЬТЕРНАТИВА на языке программирования С.

Конструкция для одной альтернативы:

if (L)

{

/*Действие при L ≠ 0*/

…

}

Конструкция для двух альтернатив:

if (L)

{

/*Действие при L ≠ 0*/

…

}

else

{

/*Действие при L = 0*/

…

}

Первый вариант конструкции для нескольких альтернатив (ВЫБОРА)

if (L1)

{

/*Действие при L1 ≠ 0*/

…

}

else if (L2)

{

/*Действие при L2 ≠ 0*/

…

}

else if(L3)

{

/*Действие при L3 ≠ 0*/

…

}

…

}

Второй вариант конструкции для нескольких альтернатив (ВЫБОРА):

Selector = 0;

L1 =…;

L2 =…;

L3 =…;

…

if (L1) Selector = 1;

else if (L2) Selector = 2;

else if (L3) Selector = 3;

…

switch (Selector)

case 1:

/*Действие при L1 ≠ 0*/

…

break;

case 2:

/*Действие при L2 ≠ 0*/

…

break;

case 3:

/*Действие при L3 ≠ 0*/

…

break;

default:

/*Вывод сообщения об ошибочном кодировании модуля*/

exit (-1);

} /*Конец switch*/

Правая конструкция соответствует очень сложной логике условий. В простейших случаях допускается упрощенная кодировка (первый пример на Pascal, второй на Q:

if a > b then x:=y+3 else x:=у+6; {Язык Pascal}

if (a > b) x=y+3; else x=у+6; /*Язык С*/

ВЫБОР из двух и более АЛЬТЕРНАТИВ нельзя кодировать при помощи вложения других структур простейших АЛЬТЕРНАТИВ из-за большой вероятности ошибок.

Порядок детализации структур АЛЬТЕРНАТИВА:

1) в зависимости от количества альтернативных действий записываются все операторы структуры;

2) определяются сами альтернативные действия как СЛЕДОВАНИЯ;

3) записываются логические условия альтернативных действий;

4) проверяется информационная согласованность логических условий и действий;

5) на нескольких текстовых примерах осуществляется проверка. ПОВТОРЕНИЯ в программировании называются циклами.

Обычно стандартом проекта предусмотрен ряд конструкций циклов. Неуниверсальный ЦИКЛ-ДО имеет две конструкции и используется для задания заданного числа повторений. Рассмотрим их запись на языке программирования Pascal.

Конструкция по возрастанию:

for i:=3 to 5 do begin

{тело цикла i=3,4,5}

…

end;

Конструкция по убыванию:

for i:=5 downto 3 do begin

{тело цикла i=5,4,3}

…

end;

Рассмотрим запись вариантов кодирования структуры неуниверсальный ЦИКЛ-ДО на языке программирования С.

Конструкция по возрастанию:

for (i=3; i<=5; i++)

{

/*тело цикла i=3,4,5*/

…

}

Конструкция по убыванию:

for (i=5; i>=3; i-)

{

/*тело цикла i=5,4,3*/

…

}

Здесь i — переменная цикла. Обычно эти циклы не требуют после кодирования дополнительного тестирования.

Универсальные циклы имеют конструкции ЦИКЛ-ДО и ЦИКЛ-ПОКА. Их запись на языке Pascal приведена ниже:

Универсальный ЦИКЛ-ПОКА:

{Подготовка}

while L do

begin

{Тело цикла}

…

end;

Универсальный цикл ЦИКЛ-ДО:

{Подготовка}

repeat

{Тело цикла}

…

until L;

Ниже приведена запись тех же структур на языке С:

Универсальный ЦИКЛ-ПОКА:

/*Подготовка*/

while (L)

{

/*Тело цикла*/

…

}

Универсальный ЦИКЛ-ДО:

/*Подготовка*/

do

{

/* Тело цикла */

…

}

while (!(L))

Здесь L логическое выражение. Его значение True является условием продолжения выполнения ЦИКЛ-ПОКА или условием окончания выполнения ЦИКЛ-ДО. Подготовка и тело цикла являются СЛЕДОВАНИЯМИ. Тело цикла выполняется столько раз, сколько и весь цикл. Признаком ЦИКЛ-ПОКА является возможность не выполнения тела цикла ни разу. При равноценности из двух конструкций ЦИКЛ-ДО и ЦИКЛ-ПОКА выбирают ту, запись которой короче.

Вообще ЦИКЛ-ДО можно закодировать структурой ЦИКЛ-ПОКА, если в подготовке записать некоторые действия из тела цикла. Из ЦИКЛА-ДО получается ЦИКЛ-ПОКА при его охвате структурой АЛЬТЕРНАТИВА.

Порядок декомпозиции циклов:

1) набирается "пустой" текст оператора цикла;

2) записывается логическое условие продолжения ЦИКЛ-ПОКА или завершения ЦИКЛ-ДО (при этом выявляется переменная цикла);

3) декомпозируется то действие тела цикла, которое изменяет логическое условие до невыполнения условия ЦИКЛ-ПОКА или до выполнения условия ЦИКЛ-ДО;

4) детализируется СЛЕДОВАНИЕ "Подготовка цикла";

5) детализируется оставшееся действие тела цикла как СЛЕДОВАНИЕ;

6) проводится проверка информационной согласованности всех элементов цикла;

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

В текстах программ может использоваться еще одна вычислительная структура — РЕКУРСИЯ. Признаком этой структуры является наличие рекурсивных формул и вычислений. Все, что делает рекурсия, можно реализовать при помощи циклов и массивов. Однако если язык программирования допускает рекурсию, то ее использование может сократить код программы. Рекурсия всегда очень тщательно комментируется.

5.9. МЕТОДИКА РАЗРАБОТКИ АЛГОРИТМОВ ПРОГРАММ

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

ax^2 + bx + c = 0.

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

Первоначально алгоритм должен представлять одну типовую структуру СЛЕДОВАНИЕ (одно действие со смыслом выполнить все действия программы, например, программа начисления заработанной платы, но не программа начисления заработанной платы и/или решения квадратного уравнения).

Глядя на тесты и изображение модели "черного ящика" (см. рис. 5.3), детализируем весь алгоритм как одно СЛЕДОВАНИЕ (последовательно выполняемое действие) в порядке: а) предварительная запись смысла действия "черного ящика"; б) выходная и/или выводимая информация; в) входная и/или вводимая информация; г) определяется действие в "черном ящике" (одно предложение).

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

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

Исследуя "черный ящик" применительно к решению квадратного уравнения, можем записать предварительный комментарий сути всех действий программы: "Программа решения квадратного уравнения вида a*x*x + b*x + c = 0".

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

Итак, пусть известна "школьная" формула решения квадратного уравнения вида ax^2 + bx + с = 0.

Известно также, что первоначально надо вычислить дискриминант уравнения D:

D = b^2 — 4ac.

Даже если забыли о случае отрицательности дискриминанта — ничего страшного нет. Записываем формулу решения:

Нам известно, что если D < 0, то из отрицательного числа нельзя извлекать квадратный корень. Поэтому вспоминаем, что при отрицательном дискриминанте нет корней. Еще обнаруживаем факт особого случая, которому соответствует факт при D = 0 наличия двух равных корней. Еще известно, что делить на ноль нельзя, а при a = 0 имеем именно этот случай. В этом случае исходное квадратное уравнение превращается в линейное уравнение:

bx + c = 0.

Решение получившегося уравнения будет следующим:

x = (—c)/b.

Это решение возможно лишь в случае a = 0 и (одновременно) b ≠ 0. В случае a = 0 и (одновременно) b = 0 и (одновременно) c ≠ 0 линейное уравнение не имеет решения.

Анализируя исходное уравнение, выясняем, что в случае a = 0 и (одновременно) b = 0 и (одновременно) c = 0 уравнение имеет бесчисленное множество решений (корни x1 и x2 — любые числа).

Составим наглядную таблицу правил решения квадратного уравнения (табл. 5.3).

Таблица 5.3

Наглядная таблица правил решения квадратного уравнения

№ п/п

а

b

с

d

Вариант решения

1

a ≠ 0

Любое

Любое

d > 0

Два различных корня

2

a ≠ 0

Любое

Любое

d = 0

Два равных корня

3

a ≠ 0

Любое

Любое

d < 0

Нет решения

4

а = 0

b ≠ 0

Любое

Нет

Есть корень линейного уравнения

5

а = 0

b = 0

c ≠ 0

Нет

Нет решения

6

а = 0

b = 0

с = 0

Нет

Бесчисленное множество решений

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

1) уравнение имеет бесчисленное множество решений (корни x1 и x2 — любые числа);

2) значения двух различных корней x1 и x2;

3) значения двух равных корней в виде x1 и дополняющей надписи о двух равных корнях;

4) надпись нет решения;

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

Тип переменных, в которых размещаются выходные значения корней x1 и x2, — вещественный (Real). Теперь определяем входную информацию. Из исходного уравнения следует, что входной информацией являются значения трех коэффициентов a, b, c типа вещественный (Real). В ходе анализа формул было установлено, что значения трех коэффициентов a, b, c могут принимать любые значения, что было не очевидно до анализа формул решения уравнения (например, случай a = 0).

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

Окончательный комментарий сути действий всей программы: "Программа решения квадратного уравнения a*x*x + b*x + c = 0 с произвольными значениями коэффициентов a, b, c типа вещественный". Факт произвольности значений коэффициентов a, b, c на этапе предварительного выявления сути действия "черного ящика" еще не был выявлен.

Наконец, готовим тестовые примеры.

Совокупность тестов для всех выявленных случаев решения квадратного уравнения:

1) при a = 0, b = 0, c = 0 бесчисленное множество решений (корни x1 и x2 — любые числа);

2) при a = 2, b = 3, c = —2 значения двух различных корней x1 = —2 и x2 = 0,5;

3) при a = 1, b = 4, c = 4 значения двух равных корней в виде x1 = x2 = —2 и вывод дополняющей надписи о двух равных корнях;

4) при а = 2, b = 5, с = 4 вывод надписи "нет решения";

5) при a = 0, b = 2, c = —8 значение одного корня x1 = 4 с надписью, что уравнение является линейным;

6) при a = 0, b = 0, c = 2 вывод надписи "нет решения". Теперь можно сразу написать фрагмент программы, соответствующий проделанной работе:

Program Kvadrat;

{ Программа решения квадратного уравнения

вида a*x*x + b*x + c = 0 с произвольными

значениями коэффициентов a, b, c типа

вещественный }

Uses

Crt, Dos;

Var

a, b, c: Real; {Коэффициенты квадратного уравнения}

xl, x2: Real; {Корни квадратного уравнения}

begin

end.

Путем компиляции фрагмента программы на компьютере можно проверить корректность синтаксиса. Теперь подготовим макет изображения экрана монитора (рис. 5.16). На макете изображения экрана монитора символами □ отмечены поля ввода информации, а символами — поля вывода информации.

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

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

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

Первоначально нужно выполнить действия, определенные макетом изображения на экране монитора, так как для выполнения алгоритма решения квадратного уравнения необходимы исходные данные в виде коэффициентов a, b, c. Однако вводу должен предшествовать вывод информации, поясняющей назначение программы и суть очередной вводимой порции данных. Это предопределяет первичную детализацию одиночное СЛЕДОВАНИЕ в ЦЕПОЧКУ СЛЕДОВАНИЙ. Первичное одиночное СЛЕДОВАНИЕ не может содержать входной и выходной информации. Входная информация должна либо быть введена, либо присвоена. Выходная информация по завершении программы никого не интересует. Итак, ниже представлена цепочка последовательных действий.

Рис. 5.16. Макет изображения экрана монитора

ClrScr; {Очистка экрана}

{Вывод информации о назначении программы}

WriteLn ('Программа решения квадратного уравнения');

WriteLn ('вида а*x*x + b*x + с = 0 с произвольны','ми значениями');

WriteLn ('коэффициентов a, b, c типа вещественный');

WriteLn;

{Ввод значений коэффициентов a, b, c}

Write ('Укажите значение коэффициента а = ');

ReadLn (a); {Ввод а}

Write ('Укажите значение коэффициента b = ');

ReadLn (b); {Ввод b}

Write ('Укажите значение коэффициента с = ');

ReadLn (с); {Ввод с}

{ Вывод проверочно-протокольной информации о введенных значениях коэффициентов a, b, c}

WriteLn;

WriteLn ('Решается квадратное уравнение');

WriteLn (а:10:4, '*x*x + ', b:10:4, '* x + ', с:10:4, ' = 0:'); { Само решение квадратного уравнения }

WriteLn;

Write ('Для завершения программы нажмите');

WriteLn (' любую клавишу…');

Repeat until KeyPressed; { Цикл ожидания нажатия любой клавиши }

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

Написание операторов WriteLn, Write, ReadLn не вызвало затруднений благодаря заранее подготовленному макету изображения экрана монитора.

Действие "Само решение квадратного уравнения" представлено комментарием и пустой строкой, отмечающей факт добавления действий в будущем. Это объясняется тем, что решение и вывод результатов решения многовариантны, а, следовательно, действие "Само решение квадратного уравнения" нельзя представить ЦЕПОЧКОЙ СЛЕДОВАНИЙ. Многовариантность предполагает управляющие структуры.

Уточняем комментарии, операторы вывода Write и WriteLn.

Проводим проверку информационной согласованности СЛЕДОВАНИЙ в цепочке. Убеждаемся, что все последующие действия обеспечены информацией, определенной предшествующими действиями, в конкретном случае — операторами ReadLn. Особое внимание обращаем на действия, использующие ранее определенную информацию. Это оператор

WriteLn (a:10:4, '*x*x + ', b:10:4, '*x + ', c: 10:4, ' = 0: ');

и будущее действие

{ Само решение квадратного уравнения }.

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

Program Kvadrat;

{ Программа решения квадратного уравнения

вида а*х*х + Ь*х + с = 0 с произвольными значениями

коэффициентов а, Ь, с типа вещественный }

Uses

Crt, Dos;

Var

a, b, c: Real; {Коэффициенты квадратного уравнения}

xl, x2: Real; {Корни квадратного уравнения}

begin

ClrScr; {Очистка экрана}

{Вывод информации о значении программы}

WriteLn ('Программа решения квадратного уравнения');

Write ('вида а*х*х + b*х + с = 0 с произвольными');

Write ('значениями');

WriteLn ('коэффициентов а, b, с типа вещественный');

WriteLn

{Ввод значений коэффициентов a, b, c}

Write ('Укажите значение коэффициента а = ');

ReadLn (a); { Ввод а}

Write ('Укажите значение коэффициента b = ');

ReadLn (b); { Ввод b}

Write ('Укажите значение коэффициента с = ');

ReadLn (c); { Ввод с}

{ Вывод проверочно-протокольной информации о введенных значениях коэффициентов а, Ь, с }

WriteLn;

WriteLn ('Решается квадратное уравнение');

Write (a:10:4, '*x*x + ', b:10:4, '*x + ');

WriteLn (c:10:4, ' = 0: ');

{ Само решение квадратного уравнения }

WriteLn;

WriteLn ('Для завершения программы нажмите ', 'любую клавишу…');

repeat until KeyPressed; { Цикл ожидания нажатия любой клавиши}

end.

При сборке программы пришлось осуществить перенос части оператора WriteLn на новую строку.

Теперь осуществляем декомпозицию действия "Само решение квадратного уравнения".

Многовариантность вычислений предполагает цепочку альтернатив. Анализируя математические формулы обобщающего теста, табл. 5.3 и состав наборов выходной информации, выявляем, что ЦЕПОЧКА АЛЬТЕРНАТИВ содержит четыре альтернативных действия. Строкам с 1-й по 3-ю табл. 5.3 соответствует одно действие, поскольку для их выполнения требуется уже вычисленное значение дискриминанта d. Записываем комментарий предшествующего СЛЕДОВАНИЯ всей ЦЕПОЧКИ АЛЬТЕРНАТИВ, набор входной информации (выходной информации — нет) и оформляем заготовку операторов ЦЕПОЧКИ АЛЬТЕРНАТИВ вместе с подчиненными СЛЕДОВАНИЯМИ:

Входная информация: a, b, c

{ Само решение квадратного уравнения }

if

then

begin

{ Продолжение решения с вычислением дискриминанта }

end;

if

then

begin

{ Решение линейного уравнения }

end;

if

then

begin

{ Ввод сообщения: линейное уравнение не имеет решения }

WriteLn ("Нет решения ')

end;

if

then

begin

{ Вывод сообщения: бесчисленное множество решений уравнения }

Write ('бесчисленное множество решений уравне');

WriteLn ('ния (корни — любые числа)');

end;

В последней альтернативе одна строка выводится одним оператором.

Далее в соответствии с действиями запишем логические условия выполнения действий. При этом простым сравнением проверять на равенство значения двух вещественных переменных нельзя. Например, при сравнении f = g, считающихся равными 5, даже если g = 5,00000, в силу округлений при вычислениях значение f может оказаться равным либо 4,99999, либо 5,00000, либо 5,00001. Согласно данному примеру путем простой проверки на равенство факт равенства будет установлен в одном случае из трех.

Для надежного сравнения двух вещественных чисел используют прием использования неравенства |f — g| ≤ ε, где ε — заведомо малое число. На языке программирования это неравенство имеет вид

Abs (f — g) <= 1е — 6

Продолжаем кодирование структуры. Глядя на действия, записываем логические условия выполнения действий. Входная информация: a, b, c.

{ Само решение квадратного уравнения }

if (Abs(а) > 1e — 6)

then

begin

{ Продолжение решения с вычислением дискриминанта }

end;

if ((Abs (a) <= 1e — 6) and (Abs (b) > 1e — 6))

then

begin

{ Решение линейного уравнения }

end;

if ((Abs(a) <= 1e — 6) and (Abs(b) <= 1e — 6 and (Abs(c) > 1e — 6))

then

begin

{ Вывод сообщения: линейное уравнение не имеет решения }

WriteLn ('Нет решения');

end;

if ((Abs(a) <= 1e — 6) and (Abs(b) <= 1e — 6 and (Abs(c) <= 1e — 6))

then

begin

{ Вывод сообщения: бесчисленное множество решений уравнения }

Write ('бесчисленное множество решений уравне');

WriteLn ('ния (корни — любые числа)');

end;

Осуществим сборку получившейся программы. При сборке удалим избыточные комментарии и избыточные операторные скобки begin — end, охватывающие лишь один оператор. Испытаем полученную программу на тестах a = 0, b = 0, c = 0 a = 0, b = 0, c = 2. Собранный вариант программы:

Program Kvadrat;

{ Программа решения квадратного уравнения

вида a*x*x + b*x + c = 0 с произвольными значениями

коэффициентов a, b, c типа вещественный }

Uses

Crt, Dos;

Var

a, b, c: Real; {Коэффициенты квадратного уравнения}

xl, x2: Real; {Корни квадратного уравнения}

begin

ClrScr; { Очистка экрана }

{Вывод информации о назначении программы}

WriteLn ('Программа решения квадратного уравнения');

Write ('вида a*x*x + b*x + c = 0 с произвольными');

Write ('значениями');

WriteLn ('коэффициентов a, b, c типа вещественный');

WriteLn;

{Ввод значений коэффициентов а, b, с};

Write ('Укажите значение коэффициента а = ');

ReadLn(a); { Ввод а}

Write ('Укажите значение коэффициента b = ');

ReadLn(b); { Ввод b}

Write ('Укажите значение коэффициента с = ');

ReadLn(c); { Ввод с}

{ Вывод проверочно-протокольной информации

о введенных значениях коэффициентов a, b, c }

WriteLn;

WriteLn ('Решается квадратное уравнение');

Write (a:10:4, '*x*x + ', b:10:4, '*x + ');

WriteLn(с:10:4, ' = 0:');

{ Само решение квадратного уравнения }

if (Abs (a) > 1e — 6)

then

begin

{ Продолжение решения с вычислением дискриминанта }

end;

if ((Abs(a) <= 1e — 6) and (Abs(b) > 1e — 6))

then

begin

{ Решение линейного уравнения }

end;

if ((Abs(a) <= 1e — 6) and (Abs(b) <= 1e — 6) and (Abs(c) > 1e — 6))

then

WriteLn ('Нет решения');

if ((Abs(a) <= 1e — 6) and (Abs(b) <= 1e — 6 and (Abs(c) <= 1e — 6))

then

begin

Write ('бесчисленное множество решений уравне');

WriteLn ('ния (корни — любые числа)');

end;

WriteLn;

Write ('Для завершения программы нажмите');

WriteLn ('любую клавишу…');

repeat until KeyPressed; { Цикл ожидания нажатия любой клавиши }

end.

Декомпозируем действие "Решение линейного уравнения". Это действие представляет цепочку из двух элементарных операторов. Выполним проверку информационной согласованности действий:

Входная информация: b, с.

{ Решение линейного уравнения }

x1:= — c/b;

WriteLn ('уравнение линейное x = ', x1: 10: 4);

Декомпозируем действие "Продолжение решения с вычислением дискриминанта". Данное действие представляет ЦЕПОЧКУ СЛЕДОВАНИЙ из двух СЛЕДОВАНИЙ.

Входная информация: а, Ь, с

{ Продолжение решения с вычислением дискриминанта }

{ Вычисление дискриминанта квадратного уравнения }

d:= Sqr (b) — 4.0*а*с; { Решение уравнения }

Переменная d у нас не описана, поэтому в секцию Var необходимо добавить строку описания:

d: Real; { Значение дискриминанта }

Декомпозируем действие "Решение уравнения". Согласно табл. 5.3 данное действие представляет ЦЕПОЧКУ АЛЬТЕРНАТИВ из трех альтернатив в цепочке. Осуществив детализацию этих альтернатив в установленном порядке, получим:

Входная информация: a, b, c, d.

{ Решение уравнения }

if d > 1e-6

then

begin

{ Расчет двух различных корней }

end;

if ((d >= -1e-6) and (d <= 1e-6))

then

begin

{ Расчет двух равных корней }

WriteLn ('два равных корня x = ', (-b)/(2.0 * а):10:4);

end;

if d < -1e-6 then begin

{ Вывод надписи: уравнение не имеет решения }

WriteLn ('уравнение не имеет решения');

end;

Декомпозируем действие "Расчет двух различных корней". Это действие представляет цепочку из трех элементарных операторов. Выполним проверку информационной согласованности действий:

Входная информация: a, b, c, d

{ Расчет двух различных корней }

x1:= ((-b) — Sqrt (d))/(2.0*a);

x2:= ((-b) + Sqrt (d))/(2.0*а);

Write ('два различных корня x1 = ', x1:10:4);

WriteLn (' x2 = ', х2:10:4);

Здесь вывод одной строки осуществлен двумя операторами. Осуществим сборку всей программы, удалив избыточные комментарии и избыточные операторные скобки begin — end, охватывающие лишь один оператор. Испытаем полученную программу на всех заранее подготовленных тестах. Собранный вариант программы:

Program Kvadrat;

{ Программа решения квадратного уравнения

вида a*x*x + b*x + c = 0 с произвольными значениями

коэффициентов a, b, c типа вещественный }

Uses

Crt, Dos;

Var

a, b, c: Real; {Коэффициенты квадратного уравнения}

xl, x2: Real; {Корни квадратного уравнения}

dl: Real; {Значение дискриминанта}

begin

ClrScr; { Очистка экрана }

{Вывод информации о назначении программы}

WriteLn ('Программа решения квадратного уравнения');

WriteLn ('вида a*x*x + b*x + c = 0 с произвольными', 'значениями');

WriteLn ('коэффициентов a, b, c типа ', 'вещественный');

WriteLn

{Ввод значений коэффициентов a, b, c}

Write ('Укажите значение коэффициента а = ');

ReadLn(a); { Ввод а }

Write ('Укажите значение коэффициента b = ');

ReadLn(b); { Ввод b}

Write ('Укажите значение коэффициента с = ');

ReadLn(c); { Ввод с }

{ Вывод проверочно-протокольной информации

о введенных значениях коэффициентов a, b, c }

WriteLn;

WriteLn ('Решается квадратное уравнение');

WriteLn (а:10:4, '*x*x + ', b:10:4, '*x + ', с:10:4, ' = 0:');

{ Само решение квадратного уравнения }

if (Abs (a) > 1e-6)

then

begin

{ Продолжение решения с вычислением дискриминанта }

{ Вычисление дискриминанта квадратного уравнения }

d:= Sqr(b) — 4.0*а*с;

{ Решение уравнения }

if d > 1e-6

then

begin

{ Расчет двух различных корней }

x1:= (-b) — Sqrt(d)/(2.0*a);

х2:= (-b) + Sqrt(d)/(2.0*a);

Write ('два различных корня x1 = ', x1:10:4);

WriteLn (' х2 = ', х2:10:4);

end;

if ((d >= -1e-6) and (d <= 1e-6))

then

WriteLn ('два равных корня х = ', (-b)/(2.0*a):10:4);

if d < -1e-6 then

WriteLn ('уравнение не имеет решения');

end;

if ((Abs(a) <= 1e-6) and (Abs(b) > 1e-6))

then

begin

{ Решение линейного уравнения }

x1:= — c/b;

WriteLn ('уравнение линейное х = ', x1:10:4);

end;

if ((Abs(a) <= 1e-6) and (Abs(b) <= 1e-6 and (Abs(c) > 1e-6))

then

WriteLn ('Нет решения');

if ((Abs(a) <= 1e-6 and (Abs(b) <= 1e-6 and (Abs(c) <= 1e-6))

then

begin

Write ('Бесчисленное множество решений',

'уравне');

WriteLn ('ния (корни — любые числа)');

end;

WriteLn;

Write ('Для завершения программы нажмите');

WriteLn ('любую клавишу…');

repeat until KeyPressed; { Цикл ожидания нажатия любой клавиши }

end.

5.10. ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОЙ РАБОТЫ "РАЗРАБОТКА АЛГОРИТМА УМНОЖЕНИЯ"

В качестве примера приводится учебная работа, выполненная одним из обучаемых. Работа была оформлена на отдельных листах формата A4. Курсивом выделены пояснения авторов учебника, которые были дополнительно ими внесены в текст работы.

Страница 1 (без нумерации) представляет собой титульный лист с наименованием: "ЗАДАНИЕ НА СОСТАВЛЕНИЕ СТРУКТУРИРОВАННОГО АЛГОРИТМА".

Страница 2 содержит постановку задачи и набор тестов, составленных до разработки алгоритма процесса.

Шаг 1. ПОСТАНОВКА ЗАДАЧИ

Составить алгоритм умножения двух положительных чисел с произвольным (до ста) количеством цифр. Цифры сомножителей и результата должны находиться в одномерных массивах. Разрядность результата не должна превышать 100 цифр.

Шаг 2. НАБОР ТЕСТОВ, СОСТАВЛЕННЫХ ДО РАЗРАБОТКИ АЛГОРИТМА ПРОЦЕССА

Пусть предельная разрядность сомножителей равна трем цифрам, а результата — четырем. Аналогично приведенному образцу умножения чисел 391*56 = 21896 (переполнение) были составлены тесты: 23*132 = 3036; 111*11 = 1221; 999*99 = 98901 (переполнение); 00*000 = 0; 1*0 = 0.

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

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

Шаг 3. АНАЛИЗ ВЫХОДНОЙ И ВХОДНОЙ ИНФОРМАЦИИ ВЫЧИСЛИТЕЛЬНОГО ПРОЦЕССА

Анализ выходной и входной информации начинается с рассмотрения модели "черного" ящика, показанной на рис. 5.3.

Program MultNumbers;

{Расчет произведения двух чисел}

uses

Crt;

const

Digits = 100; {Число цифр в числах}

type

TNumber = record

D: array[1..Digits] of Byte;

{B D[1] находится младший разряд числа}

N: word; {Число разрядов в числе от 1 до Digits}

end;

var

C1: TNumber; {Первый сомножитель}

C2: TNumber; {Второй сомножитель}

R: TNumber; {Результат умножения}

Error: boolean; {True — ошибка переполнения}

Макет экрана со строками диалога программы приведен на рис. 5.17. Вместо трех последних строк возможен вывод: "Ошибка переполнения".

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

Рис. 5.17. Макет экрана со строками диалога программы

Шаг 4. НАГЛЯДНОЕ ИЗОБРАЖЕНИЕ ПРОЦЕССА ПРЕОБРАЗОВАНИЯ ВХОДНЫХ ДАННЫХ ОБОБЩАЮЩЕГО ТЕСТА В ВЫХОДНЫЕ

Вводим описание новых внутренних переменных:

var {Рабочие переменные}

i, j: word;

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

На странице 4 или следующей иногда полезно поместить описание алгоритма в обыденном неструктурированном понимании.

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

Шаг 5. ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕТАЛИЗАЦИИ АЛГОРИТМА

Шаг 5.1. Результаты детализации СЛЕДОВАНИЯ "Вся программа"

Следование "Вся программа" детализируется ЦЕПОЧКОЙ СЛЕДОВАНИЙ:

begin

ClrScr; {Очистка экрана}

{Ввод корректного значения числа цифр первого сомножителя}

C1.N

Write('Вводите цифры первого сомножителя ');

{Ввод цифр первого сомножителя в порядке от C1.D[C1.N] до C1.D[1]}

C1.D

WriteLn;

{Ввод корректного значения числа цифр второго сомножителя}

С2.N

Write('Вводите цифры второго сомножителя ');

{Ввод цифр второго сомножителя в порядке от C2.D[C2.N] до C2.D[1]}

WriteLn;

{Расчет произведения сомножителей}

R.D R.N Error

{Устранение лидирующих нулей}

WriteLn;

{Вывод результата произведения}

WriteLn;

end.

Без отступов показана входная и выходная информация структур, которая использовалась при проверке информационной согласованности СЛЕДОВАНИЙ в ЦЕПОЧКЕ СЛЕДОВАНИЙ.

СЛЕДОВАНИЕ "Устранение лидирующих нулей" необходимо при использовании сомножителя, состоящего из нескольких нулей.

Шаг 5.2. Детализация СЛЕДОВАНИЯ "Ввод корректного значения числа цифр первого сомножителя"

СЛЕДОВАНИЕ "Ввод корректного значения числа цифр первого сомножителя" декомпозируется циклом:

{Ввод корректного значения числа цифр первого сомножителя}

repeat

Write('Введите число цифр первого сомножителя');

Write(' от 1 до ', Digits, ' ');

ReadLn(C1.N);

until ((C1.N >= 1) and (C1.N <= Digits));

Цикл оттестирован тремя тестами: C1.N=1; C1.N=3; C1.N=Digits.

Аналогично декомпозируется процесс "Ввод корректного значения числа цифр второго сомножителя".

Шаг 5.3. Детализация СЛЕДОВАНИЯ "Ввод цифр первого сомножителя в порядке от C1.D[C1.N] до C1.D[1]

СЛЕДОВАНИЕ "Ввод цифр первого сомножителя в порядке от C1.D[C1.N] до C1.D[1] декомпозируется циклом:

{Ввод цифр первого сомножителя в порядке от C1.D[C1.N] до C1.D[1]}

for i:= C1.N downto 1 do begin

{До ввода корректного символа цифры}

repeat

ch:= ReadKey; {Чтение символа клавиатуры}

Val(ch, C1.D[i], InCode); {Преобразование в значение}

until(InCode = 0);

Write(ch);

end;

Описания новых переменных:

var {Рабочие переменные}

InCode: word;

ch: Char;

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

Аналогично декомпозируется процесс "Ввод цифр второго сомножителя в порядке от C2.D[C2.N] до C2.D[1].

Шаг 5.4. Детализация СЛЕДОВАНИЯ "Вывод результата произведения"

СЛЕДОВАНИЕ "Вывод результата произведения" декомпозируется АЛЬТЕРНАТИВОЙ — РАЗВИЛКА С ДВУМЯ ДЕЙСТВИЯМИ:

{Вывод результата произведения}

if ERROR

then

WriteLn(Ошибка переполнения)

else

begin

{Вывод продукта умножения}

end;

Тесты: ERROR = True; ERROR = False.

Шаг 5.5. Детализация СЛЕДОВАНИЯ "Вывод продукта умножения"

СЛЕДОВАНИЕ "Вывод продукта умножения" декомпозируется циклом:

{Вывод продукта умножения}

for i:= R.N downto 1 do

Write(R.D[i]);

В тестировании нет необходимости.

Шаг 5.6. Детализация СЛЕДОВАНИЯ "Устранение лидирующих нулей"

СЛЕДОВАНИЕ "Устранение лидирующих нулей" декомпозируется циклом:

{Устранение лидирующих нулей}

while ((R.N > 1) and (R.D[i] = 0)) do

Dec(R.N); {R.N:= R.N — 1}

В тестировании нет необходимости.

Шаг 5.7. Детализация СЛЕДОВАНИЯ "Расчет произведения сомножителей"

СЛЕДОВАНИЕ "Расчет произведения сомножителей" декомпозируется циклом:

Вход: C1, C2.

{Расчет произведения сомножителей}

{Цикл задает номер j очередной цифры второго сомножителя}

ERROR:= False;

j:= 1;

R.D[1]:= 0;

while ((j <= C2.N) and

(not(ERROR))) do

begin

{Увеличение результата на сдвинутый продукт умножения первого сомножителя на j-ю цифру второго сомножителя}

Inc(j); {j:= j + 1}

end;

Выход: R.D, R.N, ERROR

Структура тестировалась на тестах: 390*56; 390*56, но при Digits = 5; 0*0 при C1.N = 0; 1*0 при C1.N = 1 и других тестах.

Шаг 5.8. Детализация СЛЕДОВАНИЯ "Увеличение результата на сдвинутый продукт умножения первого сомножителя на j-ю цифру второго сомножителя

СЛЕДОВАНИЕ детализируется циклом:

Вход: C1, C2.

{Увеличение результата на сдвинутый продукт умножения первого сомножителя на j-ю цифру второго сомножителя}

p:= 0;

i:= 0; {Номер цифры первого сомножителя}

while(((i < C1.N) or (p <> 0)) and (not(ERROR))) do

begin

Inc(i);

{Расчет очередной цифры результата и цифры переноса}

end;

Выход: R.D, R.N, ERROR

Шаг 5.9. Детализация СЛЕДОВАНИЯ "Расчет очередной цифры результата и цифры переноса"

СЛЕДОВАНИЕ детализируется альтернативой:

Вход: i, j, C1.D[i], C2.D[j], p, R.D, Digits.

{Расчет очередной цифры результата и цифры переноса}

{Контролируемый расчет ir — номера очередной цифры результата}

ir:= i + j — 1;

if (ir > Digits) then

ERROR:= True else

begin

{Изменение длины результата R.N}

if (R.N < ir)

then

begin

R.N:= ir;

R.D[ir]:= 0; {Обнуление новой цифры результата}

end;

{Получение очередной цифры C1D первого сомножителя}

if (i <= C1.N) then C1D:= C1.D[i] else C1D:= 0;

{Изменение очередной цифры результата и p}

RD:= р + R.D[ir] + C1D * С2.D[j];

R.D[ir]:= RD mod 10;

p:= RD div 10;

end;

Выход: R.D, R.N, ERROR, p.

Описания новых переменных:

var

ir, C1D, RD: word; {Рабочие переменные}

Шаг 6. РЕЗУЛЬТАТЫ СБОРКИ ПРОГРАММЫ

Program MultNumbers;

{Расчет произведения двух чисел}

uses

Crt;

const

Digits = 100; {Число цифр в числах}

type

TNumber = record

D: array[1..Digits] of Byte;

{BD[1] находится младший разряд числа}

N: word; {Число разрядов в числе от 1 до Digits}

end;

var

C1: TNumber; {Первый сомножитель}

C2: TNumber; {Второй сомножитель}

R: TNumber; {Результат умножения}

Error: boolean; {True — ошибка переполнения}

var

p: word; {Значение числа переноса при умножении C1.D на очередную цифру C2.D}

var {Рабочие переменные}

i, j, ir, C1D, RD, InCode: word;

ch: char; begin

ClrScr; {Очистка экрана}

{Ввод корректного значения числа цифр первого сомножителя}

repeat

Write('Введите число цифр первого сомножителя)

Write(' 1 до ', Digits, ' ');

ReadLn(C1.N);

until ((C1.N >= 1) and (C1.N <= Digits));

Write('Вводите цифры первого сомножителя ');

{Ввод цифр первого сомножителя в порядке от C1.D[C1.N] до C1.D[1]}

for i:= C1.N downto 1 do

begin

{До ввода корректного символа цифры}

repeat

ch:= ReadKey; {Чтение символа клавиатуры}

Val(ch, C1.D[i], InCode); {Преобразование в значение}

until(InCode = 0);

Write(ch);

end;

WriteLn;

{Ввод корректного значения числа цифр второго сомножителя}

repeat

Write('Введите число цифр второго сомножителя');

Write(' от 1 до ', Digits,' ');

ReadLn(C2.N);

until ((C2.N >= 1) and (C2.N <= Digits));

Write('Вводите цифры второго сомножителя ');

{Ввод цифр второго сомножителя в порядке от C2.D[C2.N] до C2.D[1]}

for i:= C2.N downto 1 do

begin

{До ввода корректного символа цифры}

repeat

ch:= ReadKey; {Чтение символа клавиатуры}

Val(ch, C2.D[i], InCode); {Преобразование в значение}

until(InCode = 0);

Write(ch);

end;

WriteLn;

{Расчет произведения сомножителей}

{Цикл задает номер j очередной цифры второго сомножителя}

ERROR:= False;

j:= 1;

R.D[1]:= 0;

while ((j <= C2.N) and (not(ERROR))) do

begin

{Увеличение результата на сдвинутый продукт умножения первого сомножителя на j-ю цифру второго сомножителя}

Р:= 0;

i:= 0; {Номер цифры первого сомножителя}

while(((i < C1.N) or (p <> 0)) and (not(ERROR))) do

begin

Inc(i);

{Расчет очередной цифры результата и цифры переноса}

{Контролируемый расчет ir — номера очередной цифры результата}

ir: = i + j — 1;

if (ir > Digits) then

ERROR:= True

else

begin

{Изменение длины результата R.N}

if (R.N < ir)

then

begin

R.N:= ir;

R.D[ir]:= 0; {Обнуление новой цифры результата}

end;

{Получение очередной цифры C1D первого сомножителя}

if (i <= C1.N)

then

C1D:= C1.D[i]

else

C1D:= 0;

{Изменение очередной цифры результата и p}

RD:= p + R.D[ir] + C1D * C2.D[j];

R.D[ir]:= RD mod 10;

p:= RD div 10;

end;

end;

Inc(j); {j:= j + 1}

end;

{Устранение лидирующих нулей}

while ((R.N > 1) and (R.D[i] =0)) do

Dec(R.N); {R.N:= R.N — 1}

WriteLn;

{Вывод результата произведения}

if ERROR

then

WriteLn('Ошибка переполнения')

else

begin

{Вывод продукта умножения}

for i:= R.N downto 1 do

Write(R.D[i]);

end;

WriteLn;

end.

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

5.11. ПРИМЕР ПРИМЕНЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ ДЛЯ КОДИРОВАНИЯ ПРОГРАММЫ ПЕЧАТИ КАЛЕНДАРЯ НА ПРИНТЕРЕ

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

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

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

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

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

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

Программа печати календаря заданного года

Укажите год распечатываемого календаря после 1917 года

(Не могу составить календарь  года

Для завершения программы нажмите любую клавишу…)

Ждите, идет печать…

Для завершения программы нажмите любую клавишу…

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

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

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

Program Calendar;

{Программа печати календаря заданного года на матричном принтере.

Год должен быть начиная с YEARBASE года}

Uses

Crt, Dos;

Const

YEARBASE = 1917; {Начальный базовый год }

BLANKS1917 = 0; {Число пустых клеток в начале января базового года}

KVARTALNAME: array [1…4] of String [53] =

({Константы укорочены при макетировании! }

' Январь Февраль Март',

' Апрель Май Июнь',

' Июль Август Сентябрь',

' Октябрь Ноябрь Декабрь'

);

WEEKDAYNAME: Array [1…7] of String [2] = ('Пн', 'Вт', 'Ср', 'Чт', 'Пт', 'Сб', 'Вс');

Var

F: Text; {Файловая переменная}

Year: Word; {Год распечатываемого календаря}

Kvartal: Word; {Квартал года}

{Количество дней в каждом месяце}

MonthsDays: Array [1…12] of Word;

{Количество пустых клеток в начале января года Year}

Balnks: Word;

{Количество пустых клеток в начале каждого месяца }

BlanksDaus: Array [1…12] of Word;

idW: Word; {Номер дня недели }

iMonth: Word; {Номер месяца в году }

iKvartalMonth: Word; {Номер месяца в квартале }

iCol: Word; {Номер колонки в месяце квартала }

iCell: Word; {Номер клетки в месяце квартала}

i: Integer;

Function Vys (Year: Word): Boolean;

{Функция возвращает True в случае високосности года Year}

begin

Vys: = False;

if (((Year mod 4 = 0) and (Year mod 100<>0))

or (Year mod 1000 = 0))

then

Vys: = True;

end; {Vys}

begin { Основная программа }

ClrScr; {Очистка экрана }

Write ('Программа печати календаря');

WriteLn ('заданного года');

Write ('Укажите год распечатываемого');

WriteLn ('календаря после', YEARBASE: 5, 'года');

ReadLn (Year);

{Контроль введенного года }

if Year < YEARBASE then

begin

{Аварийное завершение программы }

Write ('He могу составить календарь');

WriteLn (Year: 5, 'года');

Write ('Для завершения программы');

WriteLn ('нажмите любую клавишу…');

repeat until KeyPressed;

Halt (1);

end;

WriteLn ('Ждите, идет печать…');

Assign (F, 'PRN');

Rewrite (F);

{Печать календаря на принтере }

{Часть пробелов в следующей строке была изъята!}

WriteLn (F, ' ', Year);

{Подготовка информации}

{Определение количества пустых клеток в январе года Year}

Blanks: = BLANKS1917;

i:= YEARBASE;

while (I Year) do begin

{Увеличение Blanks}

Inc (Blanks); {В любой год плюс 1 }

if Vys (i)

then

Inc (Blanks); {Прошлый год високосный, +2}

{Корректировка Blanks}

if (Blanks >= 7) then Blanks:= Blanks — 7;

Inc (i); {Текущий год }

end;

{Определение количества дней в каждом месяце }

for i:= 1 to 12 do

MonthsDays [i]:= 31;

MonthsDays [4]:= 30;

MonthsDays [6]:= 30;

MonthsDays [9]:= 30;

MonthsDays [11]:= 30;

MonthsDays [2]:= 28;

if Vys (Year) then MonthsDays [2]: = 29;

{Определение количества пустых клеток в начале каждого месяца }

BlanksDays [1]:= Blanks;

for i: = 2 to 12 do

if BlanksDays [i — 1] + MonthsDays [i — 1] < 35

then

BlanksDays [i]:= BlanksDays [i — 1] + MonthsDays [i — 1] — 28

else

BlanksDays [i]:= BlanksDays [i — 1] + MonthsDays [i — 1] — 35;

{Задание номеров кварталов }

{Печать тела календаря }

for Kvartal:= 1 to 4 do begin

{Печать наименования квартала }

WriteLn (F, KVARTALNAME [Kvartal]);

{Печать дат квартала }

{Задание номера дня недели }

for iDW:= 1 to 7 do

begin

{Печать наименования дней недель }

Write (f, WEEKDAYNAME [iDW];

{Печать трех месяцев дат квартала }

for iKvartalMonth: = 1 to 3 do begin

{Расчет номер месяца в квартале }

iMonth: = (Kvartal — 1) * 3 + iKvartalMonth;

{Печать шести колонок дат дня недели квартала}

for iCol:= 1 to 6 do begin

iCell:= (iCol — 1)*7 + iDW;

if ((iCell > BlanksDays [iMonth]) and (iCell <= BlanksDays [iMonth] + MonthsDays [iMonth]))

then

Write (F, iCell — BlanksDays [iMonth]: 3)

else

Write (F, ' ');

end;

end;

{Печать наменования дней недель }

WriteLn (F, WEEKDAYNAME [iDW];

end;

end;

Close (F);

Write ('Для завершения программы');

WriteLn ('нажмите любую клавишу…');

Repeat until KeyPressed;

end.

ВЫВОДЫ

• С появлением ЭВМ актуальным стал поиск способов описания вычислительных алгоритмов. В 60-х годах уже применялись два способа описания алгоритмов: словесный пошаговый и графический в виде схем алгоритмов (жаргонно: блок-схем алгоритмов).

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

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

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

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

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

• Первоначально алгоритм или эвроритм должен представлять одну типовую структуру СЛЕДОВАНИЕ (одно действие со смыслом "выполнить все действия программы"). Далее до достижения элементарных действий (элементарных операторов языка программирования или элементарных операций) отдельные структуры СЛЕДОВАНИЕ декомпозируются с соблюдением принципа от общего к частному одной из трех стандартных структур: ЦЕПОЧКА СЛЕДОВАНИЙ; ЦЕПОЧКА АЛЬТЕРНАТИВ; ПОВТОРЕНИЕ.

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

• Алгоритм во многом определяется структурой данных.

• Тесты — необходимый атрибут разработки алгоритма.

• Обобщающий тест или тесты — минимальный набор тестовых данных, охватывающих все возможные случаи вычислений.

• Алгоритмы из старых книг лучше понимаются после их рефакторинга.

КОНТРОЛЬНЫЕ ВОПРОСЫ

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

2. Что такое функциональное описание?

3. Для чего предназначена проектная процедура разработки функциональных описаний?

4. Изложите требования к способу мышления пользователя проектной процедурой разработки функциональных описаний.

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

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

7. Каковы основные характеристики структур СЛЕДОВАНИЕ, АЛЬТЕРНАТИВА и ПОВТОРЕНИЕ?

8. Каков порядок основных шагов (этапов) выполнения проектной процедуры?

9. Приведите пример описания внешних и внутренних данных программы.

10. Зачем нужна модель "черного ящика"?

11. Назовите тесты, разрабатываемые до программирования. Назначение. Содержание. Формы.

12. Назовите признаки структуры ЦЕПОЧКА СЛЕДОВАНИЙ.

13. Назовите порядок детализации одиночного СЛЕДОВАНИЯ.

14. Назовите порядок детализации ЦЕПОЧКИ СЛЕДОВАНИЙ.

15. Назовите признаки структур вида АЛЬТЕРНАТИВА.

16. Назовите порядок детализации ЦЕПОЧКИ АЛЬТЕРНАТИВ.

17. Запишите пример кодировки альтернатив с одним и двумя действиями.

18. Запишите пример кодировки альтернатив с тремя и более действиями.

19. Назовите признаки структуры ПОВТОРЕНИЕ.

20. Назовите порядок детализации структур универсальных циклов ДО и ПОКА.

21. Запишите пример кодировки структуры НЕУНИВЕРСАЛЬНЫЙ ЦИКЛ-ДО.

22. Запишите пример кодировки структур УНИВЕРСАЛЬНЫЕ ЦИКЛЫ ДО и ПОКА.

23. Как производится доказательство корректности алгоритмов при выполнении проектной процедуры.

24. Дополните описание процесса "Кипячение воды в чайнике" наглядными рисунками.

Глава 6

АРХИТЕКТУРА ПРОГРАММНЫХ СИСТЕМ

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

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

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

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

Примеры систем: ОС, СУБД, система продажи авиабилетов и др.

Примеры программ: редактор текстов, компилятор, программы посылки запросов от кассира и др.

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

6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ

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

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

Уже в конце 70-х годов этим способом можно было быстро реализовать весьма удобный ввод данных в программу. Применительно к более поздней операционной системе MS DOS достаточно было написать текстовый файл maket.txt с текстами пояснений сути данных и символом "?" обозначить поля вводимых данных. Далее готовился командный файл с последовательностью команд:

1) удаление файла work.txt с диска;

2) копирование файла maket.txt в файл work.txt;

3) запуск готовой программы текстового редактора с параметром work.txt;

4) запуск программы пользователя обработки данных (входная информация программы — файл work.txt, выходная информация программы — файл result.txt);

5) запуск готовой программы просмотра текстовых файлов с параметром result.txt.

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

Если надо реализовать меню выбора отдельных программ, то невозможно обойтись последовательным вызовом команд командного файла. Для этого случая можно написать программу, которая визуализирует меню на экране и возвращает номер выбранного пользователем меню операционной системе. Возвратить номер выбранной темы меню можно вызовом подпрограммы Halt (номер_мен) модуля DOS Turbo Pascal, где номер_мен — значение выбранного номера темы меню.

Далее, используя команды DOS, организуйте вызов нужных программ командным файлом:

IF ERRORLEVEL 2 GOTO ITEM2

IF ERRORLEVEL 1 GOTO ITEM1

……………………..

:ITEM1

……………………..

:ITEM2

……………………..

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

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

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

6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ

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

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

6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ

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

6.5. ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ

Самый нижний уровень абстракции — это уровень аппаратуры. Каждый уровень реализует абстрактную машину с все большими возможностями.

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

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

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

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

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

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

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

Принцип 8. Всякая функция, выполняемая уровнем абстракции, должна быть представима единственным входом. Аргументы, пересылаемые между уровнями, должны быть отдельными элементами данных, а не сложными структурами.

Подход к проектированию архитектуры системы на основе абстрактных машин Дейкстры можно пояснить на следующем примере.

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

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

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

После установки операционной системы MS Windows 3.1 (при установке операционной системы MS Windows 95 одновременно устанавливается и MS DOS) появляются новые команды управления окнами для работы специалистов "со столами, заваленными бумагами". Появляется возможность одновременного запуска разных программ в разных окнах с возможностью междуоконного обмена информацией.

После установки программного комплекса Microsoft Office появляются среды и команды работы над документами, расчетными таблицами и т. д.

6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ

СОМ — Component Object Model (модель компонентных объектов) — это спецификация метода создания компонент и построения из них программ.

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

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

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

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

СОМ — это инструмент разработки развивающихся и рассредоточенных (многомашинных) комплексов программ, основанная на модели компонентных объектов.

Главное в СОМ — следование стандартным спецификациям интерфейса компонент. Однажды принятый стандарт спецификаций интерфейса никогда не изменяется. Однако после разработки нового стандарта новые компоненты сами будут опознавать старый и новый стандарты. После замены некоторого числа компонент программа вдруг заработает по-новому!

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

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

Рис. 6.1. Собираемые в период выполнения программы из отдельных компонент

Один из самых многообещающих аспектов внедрения компонентной архитектуры — быстрая разработка программ. Вы сможете выбирать компоненты из библиотеки и составлять из них, как из деталей конструктора, цельные приложения методом морфологического синтеза! Практически все продаваемые сегодня приложения Microsoft используют СОМ. Технология ActiveX этой фирмы построена на основе компонент СОМ. Программисты на Visual Basic, C++, Delphi и Java могут воспользоваться управляющими элементами ActiveX для ускорения разработки своих приложений и страниц Web. Конечно, каждому приложению по-прежнему будут нужны и некоторые специализированные компоненты, но для построения простых приложений можно обойтись стандартными.

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

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

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

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

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

Ограничение 1. Компонента должна скрывать используемый язык программирования. Компоненты могут быть разработаны с помощью практически любого процедурного языка, включая Ada, С, Java, Modula-3, Oberon и Pascal. Любой язык, в том числе Smalltalk и Visual Basic, можно приспособить к использованию компонент СОМ. Любой клиент должен иметь возможность использовать компоненту независимо от языков программирования, на которых написаны тот и другой.

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

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

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

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

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

Рис. 6.2. Поэтапное получение новых приложений

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

ВЫВОДЫ

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

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

• Традиционно программа проектировалась из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое.

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

Контрольные вопросы

1. Что такое архитектура программ?

2. Являются ли синонимами понятия "структура" и "архитектура"?

3. В чем заключается процесс разработки архитектуры программы?

4. Как реализуется архитектура системы из отдельных программ?

5. Что такое резидентная программа?

6. Как осуществляется обмен данными через порты?

7. Перечислите принципы подхода к проектированию архитектуры системы с позиции уровней абстракции Дейкстры.

8. Почему из обычной программы создать распределенную программу легче, если она состоит из компонент?

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

10. Посредством чего предусматривается взаимозаменяемость компонент?

Глава 7

ТЕХНОЛОГИЯ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

7.1. ПОНЯТИЕ СТРУКТУРЫ ПРОГРАММЫ

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

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

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

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

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

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

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

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

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

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

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

7.2. МОДУЛЬ И ОСНОВНЫЕ ПРИНЦИПЫ СТРУКТУРНОГО ПОДХОДА

7.2.1. Понятие модуля

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

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

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

Модуль — это подпрограмма, но оформленная в соответствии с особыми правилами.

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

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

Правило 3. Модуль может вызывать другие модули по их именам.

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

Правило 5. Модуль кодируется только стандартными структурами и тщательно комментируется.

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

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

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

Рис 7.1. Схема иерархии простой программы

Такая схема иерархии обычно дополняется расшифровкой функций, выполняемых модулями.

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

Расчленение должно обеспечивать удобный порядок ввода частей в эксплуатацию.

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

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

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

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

— модульность программ;

— структурное кодирование модулей программ;

— нисходящее проектирование рациональной иерархии модулей программ;

— нисходящая реализация программы с использованием заглушек;

— осуществление планирования на всех стадиях проекта;

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

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

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

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

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

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

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

7.2.2. Понятие заглушки модуля

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

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

Написание заглушек — "лишняя" работа, но требуется искусство проектировщика, чтобы максимальное количество заглушек были простыми, а тестирование уже собранной части программы было бы полным.

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

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

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

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

Рис. 7.2. Схема иерархии одной и той же программы: а — с вертикальными вызовами; б — с горизонтальными вызовами

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

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

7.2.4. Критерии оценки качества схемы иерархии

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

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

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

Фонд критериев оптимальности схем иерархии является необходимым подспорьем при оптимизации схем иерархии и состоит из 13 критериев.

Первый — полнота выполнения специфицированных функций.

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

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

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

Пятый — возможность связывания программы с обширной многоуровневой схемой иерархии конкретным редактором связей (линковщиком). Если начинаете работать над новой программой, то очень полезно выполнить на ЭВМ ее модель в виде пустых заглушек модулей, которые не содержат никаких действий.

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

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

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

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

Десятый — всемерное сокращение затрат на тестирование уже собранного ядра программы по ключевым датам сетевого графика реализации. Характеризуется простотой используемых заглушек и качеством тестирования по всем вычислительным маршрутам модулей. Достигается первичной реализацией сверху вниз модулей ввода и вывода программы с отсрочкой реализации остальных ветвей схемы иерархии. Обычно затраты на тестирование как по срокам, так и деньгам составляют около 60 % стоимости всего проекта. Хорошая схема иерархии сокращает затраты на тестирование по сравнению с первоначальным вариантом в 2–5 раз и более.

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

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

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

Итак, хорошая структура программы обеспечивает сокращение общего объема текстов в 2 или 3 раза, что соответственно удешевляет проект; на несколько порядков удешевляет тестирование (на тестирование обычно приходится не менее 60 % от общих затрат проекта), а также облегчает и удешевляет сопровождение программы.

7.2.5. Рекомендации по организации процесса разработки схемы иерархии

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

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

• описание алгоритма (функционирования) программы или методов решения задачи вместе с описанием данных;

• схема иерархии модулей программы с расшифровкой обозначений и функций модулей;

• паспорта модулей.

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

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

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

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

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

Здесь очень важным является составление удобного графика работы с учетом планирования общего числа кодировщиков программ и их равномерной загрузки по срокам проекта, а также окончание проекта в назначенный срок.

Схема иерархии должна отражаться на файлы с исходными текстами программ таким образом, чтобы каждый файл содержал как можно большее количество готовых функций с общим назначением. Это желательно для облегчения их использования в последующих разработках.

Таким образом, помимо получения денег от заказчика за разработку, программист обязан повышать свой интеллектуальный капитал тоже за деньги заказчика.

Существует очень много автоматизированных систем по формированию декомпозиции схем иерархии, например HIPO, SADT, R-TRAN.

7.3. РЕТРОСПЕКТИВНОЕ ПРОЕКТИРОВАНИЕ ДЕМОНСТРАЦИОННОЙ ПРОГРАММЫ MCALC ФИРМЫ "BORLAND INC."

Согласно ретроспективно проведенного системного анализа (см. гл. 2), фирма "Borland Inc." приняла решение о реализации демонстрационного примера программы электронной таблицы. Вполне возможно сгенерировать множество вариантов реализации электронной таблицы, начиная от варианта со всеми клетками в одном окне и кончая, например, вариантом Excel. Однако фирма "Borland Inc." избрала вариант с прокруткой информации клеток в окне, изменением адресов клеток при вставках строк и столбцов, а также при их удалении. В проект введены требования разработки некоммерческого изделия. Размер таблицы ограничен 100–100 клетками. В программе отсутствует функция копирования клеток. Избранная сложность реализуемого варианта соответствует многофайловому проекту. Программа имеет функции поддержки вывода на дисплей, ввода с клавиатуры; в ней реализован интерпретатор формул с математическими функциями; для сохранения информации таблицы используется файл сложной организации, рассмотренный в гл. 3. Все это позволяет продемонстрировать возможности компилятора.

Программа Mcalc 1985–1988 гг. (Turbo Pascal 5.0) состоит из следующих файлов:

• mcalc.pas — файл основной программы;

• mcvars.pas — файл глобальных описаний;

• mcdisply.pas — файл подпрограмм работы с дисплеем;

• mcmvsmem.asm — ассемблерный файл подпрограмм запоминания в оперативной памяти информации экрана, а также восстановления ранее сохраненной информации экрана;

• mcinput.pas — файл подпрограмм ввода данных с клавиатуры;

• mcommand.pas — файл подпрограмм, обслуживающих систему меню и действий, выбранных посредством меню;

• mcutil.pas — файл вспомогательных подпрограмм;

• mcparser.pas — файл интерпретатора арифметических выражений формул клеток.

Все файлы закодированы с соблюдением развиваемых стандартов оформления. Так, в файлах mcdisply.pas, mcinput.pas описания прототипов подпрограмм выполнены с использованием более раннего синтаксиса языка программирования, что говорит об их заимствовании из программ, написанных ранее; при этом можно выявить их небольшое модифицирование (рефакторинг).

Хотя фирма "Borland Inc." занимается разработкой компиляторов, файл mcparser.pas также является заимствованным из UNIX YACC utility и лишь частично модифицированным. Остальные файлы являются оригинальными.

Ассемблерный файл mcmvsmem.asm является искусственно добавленным. Цель его добавления — демонстрация возможности использования ассемблерных вставок. Содержащиеся в нем алгоритмы вполне можно было бы реализовать на языке Pascal. Более того, можно было бы вообще обойтись без реализованных в нем подпрограмм, правда, при этом были бы видны некоторые задержки вывода информации на экран.

С целью совершения улучшающей проект новой проектной итерации получим из существующего проекта проектную документацию, состоящую из описания структуры данных программы; функционального описания основного ядра программы; схемы иерархии модулей основного ядра программы; спецификации назначения модулей основного ядра программы.

Рассмотрим организацию файла mcvars.pas, содержащего в основном описание структуры внутренних данных программы. Файл содержит описания в секции interface. Секция implementation пустая.

В начале файла содержится код, который в зависимости от наличия сопроцессора транслируется в одном из двух вариантов:

{$IFOPT N+}

{Есть встроенный сопроцессор}

type

Real = Extended; {Замена типа Real на Extended}

const

EXPLIMIT = 11356; {Предельное значение аргумента экспоненты}

SQRLIMIT = 1Е2466;{Предельное значение аргумента SQRT}

….

{$ELSE}

const

{Тип Real не переопределен}

EXPLIMIT = 88; {Предельное значение аргумента экспоненты}

SQRLIMIT = 1E18; {Предельное значение аргумента SQRT}

….

{$ENDIF}

Описания констант содержат следующие блоки:

— блок строчных констант, содержащих информацию всех выводимых на экран и в файлы текстовых надписей (для русификации всей программы требуется изменить только эту информацию);

— блок парных строк текстов меню и "горячих" клавиш выбора тем меню;

— блок описания важнейших констант, определяющих размерность таблицы и расположение информации на экране

MAXCOLS = 100; { Maximum is 702 } {Размер таблицы}

MAXROWS = 100;

MINCOLWIDTH = 3; {Минимальная ширина столбца}

MAXCOLWIDTH = 77; {Максимальная ширина столбца}

….

— блок описания цветов всех полей экрана, модификация констант которого позволяет оперативно изменять цвета;

— основные константы, мнемоника имен которых облегчает восприятие текстов программы

HIGHLIGHT = True; {Подсвеченная текущая клетка}

NOHIGHLIGHT = False; {Неподсвеченная клетка}

{Атрибут содержимого клетки}

ТХТ = 0;

VALUE = 1;

FORMULA = 2;

….

{Разрешенные буквы}

LETTERS: set of Char = ['A'..'Z', 'a'..'z'];

— коды управляющих клавиш клавиатуры.

Следует отметить, что приведены даже коды неиспользуемых в программе управляющих клавиш клавиатуры. Это соответствует факту копирования данных кодов из кода какой-то другой разработки.

Далее следуют описания типа информации содержимого табличной клетки и типа указателя на клетку:

type

CellRec = record

Error: Boolean;

case Attrib: Byte of

TXT: (T: IString);

VALUE: (Value: Real);

FORMULA: (Fvalue: Real;

Formula: IString);

end;

CellPtr = ^CellRec; {Указатель на клетку}

Данный тип организован так, что клетка всегда может содержать признак ошибки расчетов Error и размещать три варианта информации: текст, значение и формулу.

Далее описаны основные глобальные переменные. Описания начинаются с определения двухмерного, постоянно находящегося в памяти массива Cell указателя на клетки таблицы. Это позволяет не расходовать память на пустые клетки. Память под информацию клетки выделяется динамически в количестве, строго соответствующем информации клетки. Без использования динамически выделяемой памяти было бы невозможно разместить информацию клеток таблицы в 640К памяти машин того времени.

MAXCOLS*MAXROWS*[SizeOf(Istring)+SizeOf(Extened)] = 100*100*[80+10] = 900K

Далее следуют описание переменной, являющейся указателем на текущую клетку таблицы, описание массива форматов клеток и переменных позиционирования информации на экране.

Cell: array [1..MAXCOLS, 1..MAXROWS] of CellPtr;

CurCell: CellPtr; {Указатель на текущую клетку}

Format: array [1..MAXCOLS, 1..MAXROWS] of Byte;

LeftCol, RightCol, TopRow, BottomRow,

{Позиционирование}

CurCol, CurRow, LastCol, LastRow: Word;

….

Следует отметить, что выделение отдельного массива форматов информации клеток является не оправданным. Практичнее ввести байт информации формата клетки в тип CellRec.

Сравните этот проект структуры данных с проектом структуры данных электронной таблицы, представленной в гл. 3.

Для составления оставшейся проектной документации выполним трассировку программы. После двойного нажатия клавиши <F7> начинает исполняться настроечный код, содержащийся в файлах *.TPU, и далее начинают выполняться операторы основной программы program Mcalc, находящейся в файле mcalc.pas.

В результате исследований была выявлена схема иерархии модулей программы, изображенная на рис. 7.3–7.5. Расшифровка обозначений схемы иерархии представлена в табл. 7.1.

Рис. 7.3. Фрагмент схемы иерархии основных модулей программы

Рис. 7.4. Схема иерархии модуля RedrawScreen

Рис. 7.5. Сокращенная схема иерархии модуля Run

Таблица 7.1

Расшифровка обозначений схемы иерархии

Имя модуля

Файл

Назначение модуля

Act

Mclib

Обрабатывает информацию введенной строки, занося ее в клетку

CenterColString

Mcutil

Рассчитывает X координату центрируемой в поле вывода строки

ChangeAutoCalc

Mclib

Устанавливает автоматический и ручной режимы рекалькуляции таблицы

ChangeFormDisplay

Mclib

Устанавливает режим видимости значений формул или текста формул

ClearInput

Mcdisplay

Очищает на экране поле строки ввода

ClrScr

Crt

Очищает информацию в окне экрана

DisplayCell

Mclib

Выводит на экран информацию клетки

DisplayScreen

Mclib

Отображает на экране внутреннюю информацию таблицы

EditCell

Mcommand

Осуществляет редактирование содержимого клетки

EditString

Mcinput

Редактор текстовой строки

EgaInstalled

Mcdisplay

Функция, определяющая наличие видеокарты EGA

FillChar

Dos

Присваивает элементам массива значение символа

GetCursor

Mcdisplay

Считывает толщину курсора в переменную

GetInput

Mcinput

Получив первый введенный символ, продолжает ввод информации клетки

GetKey

Mcinput

Формирует слово расширенного кода клавиши

GetSetCursor

Mcdisplay

Считывает толщину курсора в переменную и устанавливает новую толщину курсора

GotoXY

Mcdisplay

Перемещает курсор в соответствии с заданными координатами дисплея

InitColorTable

Mcdisplay

Инициализирует массив пересчета цветов для монохромного монитора

InitDisplay

Mcdisplay

Инициализирует видеокарту на работу в режиме 80-25

InitVars

Mcutil

Инициализирует значения основных переменных программы

Intr

Dos

Вызывает прерывание MS DOS

LoadSheet

Mcommand

Загружает информацию таблицы из файла

MainMenu

Mcommand

Реализует выбор тем меню программы

Mcalc

Mcalc

Главная программа

ParamCount

Dos

Счетчик полей командной строки запуска программы Mcalc

ParamStr

Dos

Возвращает значения заданного поля командной строки запуска программы Mcalc

PrintCol

Mcdisplay

Выводит значение координаты колонки таблицы

PrintFreeMem

Mcdisplay

Выводит на экран значение остатка свободной памяти

PrintRow

Mcdisplay

Выводит значение координаты строки таблицы

ReadKey

Mcinput

Считывает короткий код одной нажатой клавиши

Recalc

Mclib

Осуществляет перерасчет значений формул клеток таблицы

RedrawScreen

Mclib

Отображает на экране всю информацию таблицы

Run

Mcalc

Главный цикл программы

Scroll

Mcdisplay

Прокручивает информацию экрана в указанном направлении; устанавливает цвет фона освободившейся части экрана

SetBottomRow

Mcdisplay

Выводит на экран столбец с номерами строк таблицы

SetColor

Mcdisplay

Устанавливает цвет вывода строк на экран

SetCursor

Mcdisplay

Устанавливает заданную толщину курсора

SetRightCol

Mcdisplay

Выводит на экран строку с наименованиями столбцов таблицы

ShowCellType

Mcdisplay

Выводит на экран надпись о типе текущей клетки таблицы

TextMode

Dos

Переводит экран в указанный текстовый режим

Window

Crt

Определяет окно на экране дисплея

Write

-

Оператор вывода языка Pascal

WriteXY

Mcdisplay

Осуществляет вывод заданного числа символов заданной строки по заданным координатам дисплея

Рассмотрим функциональное описание основного ядра программы. В файле mcutil.pas исполняется рудиментарный, оставшийся от прежних разработок код:

HeapError:= @HeapFunc;

В файле mcdisplay.pas последовательно выполняются подпрограммы: InitDisplay, GetSetCursor, Window, EGAInsalled.

Процедура InitDisplay инициализирует видеокарту на работу в режиме 80 25 при помощи вызова прерывания 10h и вызовом процедуры InitColorTable инициализирует массив пересчета цветов для монохромного монитора. Последний массив используется при вызовах процедуры SetColor.

Процедура GetSetCursor при помощи процедуры GetCursor считывает толщину курсора в переменную OldCursor и при помощи процедуры SetCursor устанавливает новую толщину курсора (NOCURSOR).

Процедура Window определяет окно на экране дисплея для размещения информации всей таблицы. Далее начинает выполняться код главной программы Mcalc.

Присваиванием CheckBreak:= False запрещается использование клавиши <Ctrl+Break> немедленного завершения программы.

Вывод начальной заставки осуществляется следующими вызовами подпрограмм. Процедурами SetColor и ClrScr производится очистка окна программы. Двойным вызовом процедур SetColor и WriteXY выводятся две строки начальной заставки. Несмотря на отсутствие курсора, отрабатывается рудиментарный вызов "сокрытия" курсора GotoXY(80,25). При помощи функции GetKey осуществляется ожидание нажатия пользователем любой клавиши.

Процедурами SetColor и ClrScr производится очистка окна программы.

Вызовом процедуры InitVars инициализируются значения основных переменных программы. Массивы инициализируются значениями по умолчанию вызова процедуры FillChar.

Присваиванием Changed:= False указывается факт неизменности информации клеток таблицы после момента инициализации переменных для запрещения срабатывания автосохранения.

Вызовом процедуры RedrawScreen производится отображение на экране всей информации таблицы.

Если значение ParamCount = 1, то в командной строке MS DOS вызова программы было указано имя файла таблицы. В этом случае выполняется процедура LoadSheet, которая загружает информацию таблицы из файла с именем файла, полученном при помощи вызова функции ParamStr.

Наконец, отрабатывает "лишний" вызов Clearlnput, который дублируется в начале последующей процедуры Run, содержащей главный цикл программы.

При завершении выполнения программы последовательно производится установка цвета экрана, вызовом TextMode переводится экран в текстовый режим, запомненный в переменной OldMode, и, наконец, вызовом SetCursor восстанавливается толщина курсора, запомненная в переменной OldCursor.

Работа процедуры RedrawScreen заключается в последовательном выводе на экран информации:

• процедурой SetRightCol выводится на экран строка с наименованиями столбцов таблицы;

• процедурой SetBottomRow выводится на экран колонка с номерами строк таблицы;

• процедурами GotoXY и Write выводятся надписи в верхней строке экрана, хотя имеется более удобная процедура WriteXY;

• выводится число остатка байт памяти;

• процедурой DisplayScreen отображается на экране внутренняя информация таблицы.

Внешний вид программы Mcalc приведен на рис. 7.6.

Работа процедуры Run начинается с установления переменной главного цикла Stop:= False и выполнения процедуры Clearlnput. Главный цикл программы выполняется до изменения значения переменной Stop на True. Такое изменение возможно лишь при выборе пользователем темы меню Quit — завершение работы с программой.

Внутри главного цикла последовательно выполняются следующие действия:

— при помощи процедуры DisplayCell выводится на экран подсвеченная клеточным курсором текущая клетка (клетка А1 на рис. 7.6);

— при помощи процедуры ShowCellType выводится в нижнем левом углу экрана надпись типа текущей клетки таблицы (см. рис. 7.6);

— оператором Input:= GetKey в переменную Input вводится код символа клавиши, нажатой пользователем;

— выполняются действия отработки клавиши, нажатой пользователем.

Действия отработки клавиши, нажатой пользователем, представляют собой цепочку альтернативных действий, реализованную структурой ВЫБОР. Сначала отрабатываются действия "горячих" клавиш. В секции default (если клавиша не была "горячей") вызовом процедуры Getlnput начинается занесение информации в текущую клетку таблицы. Процедура Getlnput, занеся символ Input в редактируемую строку, первоначально вызывает EditString — редактор текстовой строки информации клетки и затем вызывает процедуру Act, которая обрабатывает информацию введенной строки, занося ее в клетку.

Рис. 7.6. Внешний вид программы Mcalc

Анализ схемы иерархии программы и функционального описания основного ядра программы показал, что основная программа перегружена вспомогательными действиями, выделение процедуры Run является искусственным разделением основной программы без продуманного структурного разбиения. Все это приводит к потере понятности текста программы.

С целью повышения понятности программы были приняты новые проектные решения, отраженные схемой иерархии (рис. 7.7).

Выполнение основной программы Mcalc начинается с запуска нового модуля Starting подготовительных действий программы. Модуль Starting является монитором последовательного исполнения модулей InitDisplay, Greeter, InitVars.

Новый модуль InitDisplay теперь является монитором последовательного исполнения модулей GetSetMode, GetCursor, SetCursor, Egalnstalled, Window, InitColorTable.

У нового модуля GetSetMode явно в качестве входного параметра указывается новый устанавливаемый видеорежим, а на выходе — старый видеорежим. Такая организация предпочтительнее прямого вызова Intr, поскольку по списку формальных параметров ясно видно назначение модуля. Реализация двух функций по выявлению и установке видеорежимов в одном модуле здесь вполне оправдана, поскольку все они реализуются вызовом одного прерывания.

Не является оправданным использование модуля с двумя функциями GetSetCursor, который являлся монитором последовательного исполнения модулей GetCursor, SetCursor. Этот модуль исключен из проекта. Все функции вывода начальной заставки переданы новому модулю Greeter.

Из модуля RedrawScreen исключен вызов модуля DisplayScreen. Это позволило избежать повторного вызова модуля DisplayScreen в модуле LoadSheet. Также исправлена ошибка использования операторов Write для вывода информации на экран путем использования вызовов процедуры WriteXY.

Далее начинает исполняться главный цикл программы. Модуль Run удален из проекта с целью увеличения понятности программы. Длинный текст выбора действий по коду нажатой пользователем клавиши заменен одной альтернативой:

If (not(HotKey(Input)) and (ConditionalKey(Input)))

then

GetInput(Input).

Новая функция HotKey в случае нажатия пользователем горячей клавиши возвращает значение TRUE, в противном случае функция возвращает значение FALSE.

Новая функция ConditionalKey в случае нажатия пользователем клавиши с кондиционным для занесения в таблицу кодом возвращает значение TRUE, в противном случае функция возвращает значение FALSE.

Рис. 7.7. Переработанная схема иерархии модулей программы

Новая процедура WriteXY теперь не использует вызов медленной процедуры GotoXY и медленно выполняемый оператор Write и использует прямой доступ к видеопамяти. Это позволило значительно ускорить вывод информации на дисплей. Более того, в процедуру добавлен новый параметр атрибута цвета выводимой строки, что позволило избежать цепочек первоначального вызова SetColor, а затем WriteXY.

Завершается выполнение программы вызовом нового модуля Finishing. Данный пример показал самодостаточность избранной проектной документации для получения нового оптимального варианта построения структуры программы.

ВЫВОДЫ

• Структура программы — искусственно выделенные программистом взаимодействующие части программы. Использование рациональной структуры устраняет проблему сложности разработки; делает программу понятной людям; повышает надежность работы программы при сокращении срока ее тестирования и сроков разработки вообще.

• Модуль — функциональный элемент технологии структурного программирования. Это подпрограмма, но оформленная в соответствии с особыми правилами.

• В понятие структуры программы включается состав и описание связей всех модулей, которые реализуют самостоятельные функции программы и описание носителей данных, участвующих в обмене как между отдельными подпрограммами, так и вводимыми и выводимыми с/на внешних устройств.

• Вероятно, наиболее общая тактика программирования состоит в разложении процесса на отдельные действия: функционального описания на подфункции, а соответствующих программ — на отдельные инструкции.

• Самым главным в схеме иерархии является минимизация усилий по сборке и тестированию программы. При использовании заглушек можно хорошо тестировать сопряжения модулей, но не сами модули. Тестирование самих модулей потребует изощренных сложных заглушек и астрономического числа тестов. Выход — до интеграции модулей тестировать модули с использованием ведущих программ.

• Схема иерархии должна отражаться на файлах с исходными текстами программ таким образом, чтобы каждый файл содержал как можно больше готовых функций с общим назначением. Это облегчит их использование в последующих разработках.

Контрольные вопросы

1. Дайте определение понятию "структура программы".

2. Что такое модуль программы и какими характеристиками он должен обладать?

3. Что отражает схема иерархии?

4. Какие принципы необходимо соблюдать, если следовать технологии структурного программирования?

5. Дайте определение понятию "заглушка модуля".

6. Перечислите основные средства изменения топологии схемы иерархии программы.

7. Назовите критерии оценки качества схемы иерархии.

8. Для чего нужен паспорт модуля?

Глава 8

ТЕХНОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

8.1. ИСТОРИЯ СОЗДАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

Практически сразу после появления языков третьего поколения (1967) ведущие специалисты в области программирования выдвинули идею преобразования постулата фон Неймана: "данные и программы неразличимы в памяти машины". Их цель заключалась в максимальном сближении данных и кода программы. Решая поставленную задачу, они столкнулись с задачей, решить которую без декомпозиции оказалось невозможно, а традиционные структурные декомпозиции не сильно упрощали задачу. Усилия многих программистов и системных аналитиков, направленные на формализацию подхода, увенчались успехом.

Были разработаны три основополагающих принципа того, что потом стало называться объектно-ориентированным программированием (ООПр): наследование; инкапсуляция; полиморфизм.

Результатом их первого применения стал язык Симула-1 (Simula-1), в котором был введен новый тип — объект. В описании этого типа одновременно указывались данные (поля) и процедуры, их обрабатывающие — методы. Родственные объекты объединялись в классы, описания которых оформлялись в виде блоков программы. При этом класс можно использовать в качестве префикса к другим классам, которые становятся в этом случае подклассами первого. Впоследствии Симула-1 был обобщен, и появился первый универсальный ООПр — объектно-ориентированный язык программирования — Симула-67 (67 — по году создания).

Как выяснилось, ООПр оказались пригодными не только для моделирования (Simula) и разработки графических приложений-(SmallTalk), но и для создания большинства других приложений, а их приближенность к человеческому мышлению и возможность многократного использования кода сделали их наиболее используемыми в программировании.

Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как уменьшение сложности программного обеспечения; повышение надежности программного обеспечения; обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов; обеспечение возможности повторного использования отдельных компонентов программного обеспечения.

8.2. ВВЕДЕНИЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММ

В основу структурного мышления положены структуризация и декомпозиция окружающего мира. Задача любой сложности разбивается на подзадачи, а те в свою очередь разбиваются далее и т. д., пока каждая подзадача не станет простой, соответствующей модулю.

Модуль в понятии структурного программирования — это подпрограмма (функция или процедура), оформленная определенным образом и выполняющая строго одно действие. Методы структурного проектирования используют модули в качестве строительных блоков программы, а структура программы представляется иерархией подчиненности модулей.

Модуль ООПр — файл описаний объектов и действий над ними.

Методы объектно-ориентированного проектирования используют в качестве строительных блоков объекты. Каждая структурная составляющая является самостоятельным объектом, содержащим свои собственные коды и данные. Благодаря этому уменьшена или отсутствует область глобальных данных.

Объектно-ориентированное мышление адекватно способу естественного человеческого мышления, ибо человек мыслит "образами" и "абстракциями". Чтобы проиллюстрировать некоторые из принципов объектно-ориентированного мышления, обратимся к следующему примеру, основанному на аналогии мира объектов реальному миру.

Рассмотрим ситуацию из обыденной жизни. Допустим, вы решили поехать в другой город на поезде. Для этого вы приходите на ближайшую железнодорожную станцию и сообщаете кассиру номер нужного поезда и дату, когда планируете уехать. Теперь можете быть уверены, что ваш запрос будет удовлетворен (при условии, что вы покупаете билет заранее).

Таким образом, для решения своей проблемы вы нашли объект "кассир железнодорожной кассы" и передали ему сообщение, содержащее запрос. Обязанностью объекта "кассир железнодорожной кассы" является удовлетворение запроса.

У кассира имеется некоторый определенный метод, или эвроритм, или последовательность операций (процедура), которые используют работники кассы для выполнения вашего запроса. Имеются у кассира и другие методы, например по сдаче денег, — инкассации.

Вам совершенно не обязательно знать не только детально метод, который используется кассиром, но даже весь набор методов работы кассира. Однако если бы вас заинтересовал вопрос как работает кассир, то обнаружили бы, что кассир пошлет свое сообщение автоматизированной системе железнодорожного вокзала. Та, в свою очередь, примет необходимые меры и т. д. Тем самым ваш запрос, в конечном счете, будет удовлетворен через последовательность запросов, пересылаемых от одного объекта к другому.

Таким образом, действие в объектно-ориентированном программировании инициируется посредством передачи сообщений объекту, ответственному за действие. Сообщение содержит запрос на осуществление действия конкретным объектом и сопровождается дополнительными аргументами, необходимыми для его выполнения. Пример аргументов вашего сообщения: дата отъезда, номер поезда, тип вагона. Сообщения кассира: дайте паспорт, заплатите такую-то сумму, получите билет и сдачу.

Кассир, находящийся на рабочем месте, не обязан отвлекаться от работы для пустой болтовни с покупателем билета, например, сообщать ему свой домашний телефон или сумму денег, находящуюся в сейфе кассы. Таким образом, кассир взаимодействует с другими объектами ("покупатель билета", "автоматизированная система", "инкассатор", "бригадир" и т. д.) только по строго регламентированному интерфейсу. Интерфейс — это набор форматов допустимых сообщений. Для исключения возможных, но недопустимых сообщений используется механизм сокрытия информации (инструкция, запрещающая кассиру болтать впустую на рабочем месте).

Помимо методов, кассир для успешной работы должен располагать наборами чистых бланков билетов, купюрами и монетами наличных денег (хотя бы для сдачи покупателю). Такие наборы хранятся в особых отсеках кассы, особых коробках. Места хранения этих наборов называют полями объектов. В программах полям объектов соответствуют переменные, которые могут хранить какие-то значения.

Покупатель билета не может положить деньги непосредственно в отсек кассового аппарата или сейф кассира, а также самостоятельно отсчитать себе сдачу. Таким образом, кассир как бы заключен в оболочку, или капсулу, которая отделяет его и покупателя от лишних взаимодействий. Помещение кассы (капсула) имеет особое устройство, исключающее доступ покупателей билетов к деньгам. Это и есть инкапсуляция объектов, позволяющая использовать только допустимый интерфейс — обмен информацией и предметами только посредством допустимых сообщений, а может быть, еще и подаваемых в нужной последовательности. Именно только через вызов сообщениями особых методов осуществляется обмен данных, отделяя покупателей от полей. Благодаря инкапсуляции покупатель может лишь отдавать в качестве оплаты деньги за билет в форме сообщения с аргументом "сумма". Аналогично, но в обратном направлении кассир возвращает сдачу.

Вы можете передать свое сообщение, например, объекту "свой приятель", и он его, скорее всего, поймет, и как результат — действие будет выполнено (а именно билеты будут куплены). Но если вы попросите о том же объект "продавец магазина", у него может не оказаться подходящего метода для решения поставленной задачи. Если предположить, что объект "продавец магазина" вообще воспримет этот запрос, то он "выдаст" надлежащее сообщение об ошибке. В отличие от программ, люди работают не по алгоритмам, а по эвроритмам. Человек может самостоятельно менять правила методов своей работы. Так, продавец магазина при виде аргумента "очень большая сумма", может закрыть магазин и побежать покупать железнодорожный билет. Напомним, что такие ситуации для программ пока еще невозможны.

Различие между вызовом процедуры и пересылкой сообщения состоит в том, что в последнем случае существует определенный получатель и интерпретация (т. е. выбор подходящего метода, запускаемого в ответ на сообщение), которая может быть различной для разных получателей.

Обычно конкретный объект-получатель неизвестен вплоть до выполнения программы, так что определить, какой метод, какого объекта будет вызван, заранее невозможно (конкретный кассир заранее не знает, кто и когда из конкретных покупателей обратится к нему). В таком случае говорят, что имеет место позднее связывание между сообщением (именем процедуры или функции) и фрагментом кода (методом), исполняемым в ответ на сообщение. Эта ситуация противопоставляется раннему связыванию (на этапе компилирования или компоновки программы) имени с фрагментом кода, что происходит при традиционных вызовах процедур.

Фундаментальной концепцией в объектно-ориентированном программировании является понятие классов. Все объекты являются представителями, или экземплярами, классов. Например: у вас наверняка есть примерное представление о реакции кассира на запрос о заказе билетов, поскольку вы имеете общую информацию о людях данной профессии (например, кассире кинотеатра) и ожидаете, что он, будучи представителем данной категории, в общих чертах будет соответствовать шаблону. То же самое можно сказать и о представителях других профессий, что позволяет разделить человеческое общество на определенные категории по профессиональному признаку (на классы). Каждая категория в свою очередь делится на представителей этой категории. Таким образом, человеческое общество представляется в виде иерархической структуры с наследованием свойств классов объектов всех категорий. В корне такой классификации может находиться класс "HomoSapience" или даже класс "млекопитающие" (рис. 8.1).

Метод, активизируемый объектом в ответ на сообщение, определяется классом, к которому принадлежит получатель сообщения. Все объекты одного класса используют одни и те же методы в ответ на одинаковые сообщения.

Классы могут быть организованы в иерархическую структуру с наследованием свойств. Класс-потомок наследует атрибуты родительского класса, расположенного ниже в иерархическом дереве (если дерево иерархии наследования растет вверх). Абстрактный родительский класс — это класс, не имеющий экземпляров объектов. Он используется только для порождения потомков. Класс "HomoSapience", скорее всего, будет абстрактным, поскольку для практического применения, например работодателю, экземпляры его объектов не интересны.

Рис. 8.1. Понятие создания объекта как экземпляра класса ПТИЦЫ

Итак, пусть абстрактным родительским классом у работодателя будет класс "трудоспособный человек", который включает методы доступа к внутренним данным, а также поля самих внутренних данных: фамилия; имя; отчество; дата рождения; домашний адрес; домашний телефон; сведения об образовании; сведения о трудовом стаже и т. д. От данного класса могут быть унаследованы классы: "кассир", "водитель автомобиля", "музыкант". Класс "кассир" располагает методами работы: общение с клиентом по правилам, получение денег, выдача денег, общение с инкассатором и т. д. От класса "кассир" могут быть унаследованы классы: "кассир, выдающий зарплату", "кассир железнодорожной кассы". Кассир железнодорожной кассы отличается от кассира, выдающего зарплату, дополнительными знаниями и навыками работы.

От класса "кассир железнодорожной кассы" могут быть получены экземпляры объектов: "кассир кассы № 1", "кассир кассы № 2", "кассир кассы № 3" и т. д.

В помещении большого вокзала можно обнаружить множество одинаково оборудованных объектов — касс. Однако среди касс можно выделить различающиеся кассы: суточные, предварительные, воинские, работающие по бронированию билетов и т. д. Для того чтобы начальнику вокзала поменять один вид кассы на другой, нет необходимости перестраивать помещение кассы и менять оборудование. Ему достаточно заменить в кассе кассира с одними навыками на кассира с другими навыками. Кассир вставляет табличку с новой надписью вида кассы — и все. Заметим, что смена функции касс произошла без остановки работы вокзала. Такая замена становится простой именно потому, что все помещения касс имеют одинаковый интерфейс с кассирами и клиентами. Теперь разные объекты, поддерживающие одинаковые интерфейсы, могут выполнять в ответ на запросы разные операции.

Ассоциация запроса с объектом и одной из его операций во время выполнения называется динамическим связыванием. Динамическое связывание позволяет во время выполнения подставить вместо одного объекта другой, если он имеет точно такой же интерфейс. Такая взаимозаменяемость называется полиморфизмом и является еще одной фундаментальной особенностью объектно-ориентированных систем (рис. 8.2).

Пусть, согласно произведенной классификации, объекты "скрипач с фамилией Петров" и "водитель автомобиля Сидоров" будут экземплярами разных классов. Для того чтобы получить объект "Иванов, являющийся одновременно скрипачом и водителем", необходим особый класс, который может быть получен из классов "скрипач" и "водитель автомобиля" множественным наследованием (рис. 8.3). Теперь работодатель, послав особое сообщение делегирования, может поручить (делегировать) объекту "Иванов" выполнять функцию либо водителя, либо скрипача. Объект "Иванов", находящийся за рулем автомобиля, не должен начать играть на скрипке. Для этого должен быть реализован механизм самоделегирования полномочий — объект "Иванов", находясь за рулем, запрещает сам себе игру на скрипке. Таким образом, понятие обязанности или ответственности за выполнение действия является фундаментальным в объектно-ориентированном программировании.

Рис. 8.3. Пример простого и множественного наследования

В системах программирования с отсутствующим множественным наследованием задачи, требующие множественного наследования, всегда могут быть решены композицией (агрегированием) с последующим делегированием полномочий.

Композиция объектов — это реализация составного объекта, состоящего из нескольких совместно работающих объектов и образующих единое целое с новой, более сложной функциональностью.

Агрегированный объект — объект, составленный из подобъектов. Подобъекты называются частями агрегата, и агрегат отвечает за них. Например, в системах с множественным наследованием шахматная фигура ферзь может быть унаследована от слона и ладьи. В системах с отсутствующим множественным наследованием можно получить ферзя двумя способами. Согласно первому способу, можно создать класс "любая_фигура" и далее, в периоде выполнения, делегировать полномочия каждому объекту-экземпляру данного класса быть ладьей, слоном, ферзей, пешкой и т. д. По второму способу после получения классов "ладья" и "слон" их можно объединить композицией в класс "ферзь". Теперь объект класса "ферзь" можно использовать как объект "ферзь" или даже как объект "слон", для чего объекту "ферзь" делегируется выполнение полномочий слона. Более того, можно делегировать объекту "ферзь" полномочия стать объектами "король" или даже "пешка"! Для композиции требуется, чтобы объединяемые объекты имели четко определенные интерфейсы. И у наследования, и у композиции есть достоинства и недостатки.

Наследование класса определяется статически на этапе компиляции; его проще использовать, поскольку оно напрямую поддержано языком программирования.

Но у наследования класса есть и минусы. Во-первых, нельзя изменить унаследованную от родителя реализацию во время выполнения программы, поскольку само наследование фиксировано на этапе компиляции. Во-вторых, родительский класс нередко, хотя бы частично, определяет физическое представление своих подклассов. Поскольку подклассу доступны детали реализации родительского класса, то часто говорят, что наследование нарушает инкапсуляцию. Реализации подкласса и родительского класса настолько тесно связаны, что любые изменения последней требуют изменять и реализацию подкласса.

Композиция объектов определяется динамически во время выполнения за счет того, что объекты получают ссылки на другие объекты. Композицию можно применить, если объекты соблюдают интерфейсы друг друга. Для этого, в свою очередь, требуется тщательно проектировать интерфейсы, так чтобы один объект можно было использовать вместе с широким спектром других. Но и выигрыш велик, поскольку доступ к объектам осуществляется только через их интерфейсы, мы не нарушаем инкапсуляцию. Во время выполнения программы любой объект можно заменить другим, лишь бы он имел тот же тип. Более того, поскольку при реализации объекта кодируются прежде всего его интерфейсы, то зависимость от реализации резко снижается.

Композиция объектов влияет на дизайн системы и еще в одном аспекте. Отдавая предпочтение композиции объектов, а не наследованию классов, вы инкапсулируете каждый класс и даете ему возможность выполнять только свою задачу. Классы и их иерархии остаются небольшими, и вероятность их разрастания до неуправляемых размеров невелика. С другой стороны, дизайн, основанный на композиции, будет содержать больше объектов (хотя число классов, возможно, уменьшится), и поведение системы начнет зависеть от их взаимодействия, тогда как при другом подходе оно было бы определено в одном классе.

Это подводит еще к одному правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса.

В идеале, чтобы добиться повторного использования кода, вообще не следовало бы создавать новые компоненты. Хорошо бы, чтобы можно было получить всю нужную функциональность, просто собирая вместе уже существующие компоненты. На практике, однако, так получается редко, поскольку набор имеющихся компонентов все же недостаточно широк. Повторное использование за счет наследования упрощает создание новых компонентов, которые можно было бы применять со старыми. Поэтому наследование и композиция часто используются вместе.

Тем не менее опыт показывает, что проектировщики злоупотребляют наследованием. Нередко программы могли бы стать проще, если бы их авторы больше полагались на композицию объектов.

С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование. При делегировании в процесс обработки запроса вовлечено два объекта: получатель поручает выполнение операций другому объекту — уполномоченному. Примерно так же подкласс делегирует ответственность своему родительскому классу. Но унаследованная операция всегда может обратиться к объекту-получателю через переменную-член (в C++) или переменную self (в Smalltalk). Чтобы достичь того же эффекта для делегирования, получатель передает указатель на самого себя соответствующему объекту, чтобы при выполнении делегированной операции последний мог обратиться к непосредственному адресату запроса.

Например, вместо того чтобы делать класс Window (окно) подклассом класса Rectangle (прямоугольник) — ведь окно является прямоугольником, — мы можем воспользоваться внутри Window поведением класса Rectangle, поместив в класс Window переменную экземпляра типа Rectangle и делегируя ей операции, специфичные для прямоугольников. Другими словами, окно не является прямоугольником, а содержит его. Теперь класс Window может явно перенаправлять запросы своему члену Rectangle, а не наследовать его операции.

Главное достоинство делегирования в том, что оно упрощает композицию поведения во время выполнения. При этом способ комбинирования поведения можно изменять. Внутреннюю область окна разрешается сделать круговой во время выполнения простой подставкой вместо экземпляра класса Rectangle экземпляра класса Circle. Предполагается, конечно, что оба эти класса имеют одинаковый тип.

У делегирования есть и недостаток, свойственный и другим подходам, применяемым для повышения гибкости за счет композиции объектов. Заключается он в том, что динамическую, в высокой степени параметризованную программу труднее понять, чем статическую. Есть, конечно, и некоторая потеря машинной производительности, но неэффективность работы проектировщика гораздо более существенна. Делегирование можно считать хорошим выбором только тогда, когда оно позволяет достичь упрощения, а не усложнения. Нелегко сформулировать правила, ясно говорящие, когда следует пользоваться делегированием, поскольку эффективность его зависит от контекста и личного опыта программиста.

Таким образом, можно выделить следующие фундаментальные характеристики объектно-ориентированного мышления:

Характеристика 1. Любой предмет или явление могут рассматриваться как объект.

Характеристика 2. Объект может размещать в своей памяти (в полях) личную информацию, независимую от других объектов. Рекомендуется использовать инкапсулированный (через особые методы) доступ к информации полей.

Характеристика 3. Объекты могут иметь открытые по интерфейсу методы обработки сообщений. Сами сообщения вызовов методов посылаются другими объектами, но для осуществления разумного интерфейса между объектами некоторые методы могут быть скрыты.

Характеристика 4. Вычисления осуществляются путем взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие (метод). Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. Объект — получатель сообщения — обрабатывает сообщения своими внутренними методами.

Характеристика 5. Каждый объект является представителем класса, который выражает общие свойства объектов данного класса в виде одинаковых списков набора данных (полей) в своей памяти и внутренних методов, обрабатывающих сообщения. В классе методы задают поведение объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.

Характеристика 6. Классы организованы в единую квазидревовидную структуру с общим корнем, которая называется иерархией наследования. Обычно корень иерархии направлен вверх. При множественном наследовании ветви могут срастаться, образуя сеть наследования. Память и поведение, связанные с экземплярами определенного класса, автоматически являются доступными любому классу, расположенному ниже в иерархическом дереве.

Характеристика 7. Благодаря полиморфизму — способности подставлять во время выполнения вместо одного объекта другой, с совместимым интерфейсом, в периоде выполнения одни и те же объекты могут разными методами исполнять одни и те же запросы сообщений.

Характеристика 8. Композиция является предпочтительной альтернативой множественному наследованию и позволяет изменять состав объектов агрегата в процессе выполнения программы.

Характеристика 9. Структура объектно-ориентированной программы на этапе выполнения часто имеет мало общего со структурой ее исходного кода. Последняя фиксируется на этапе компиляции. Ее код состоит из классов, отношения наследования между которыми неизменны. На этапе же выполнения структура программы — быстро изменяющаяся сеть из взаимодействующих объектов. Две эти структуры почти независимы.

8.3. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

Для проведения сравнительного анализа технологий структурного и объектно-ориентированного программирования разработана специальная методика, основанная на таких объективных принципах, как арифметический подсчет элементов текста программы, анализе алгоритмов программ. Арифметический подсчет выполнялся ручным счетом и был дополнен статистическими данными, выдаваемыми компиляторами и текстовыми редакторами. Итоговые таблицы и их визуализация осуществлялась при помощи программы Excel. Таблицы включают информацию по отдельным файлам и расчет итоговой информации по всей программе.

Информация по отдельным файлам представлена:

1) именем файла;

2) общим количеством строк файла (показывается текстовым редактором);

3) количеством строк операторов описаний данных во всем файле;

4) общим количеством комментариев в файле (выявляется контекстным поиском признака комментария в тексте файла);

5) количеством строк отдельных комментариев в файле;

6) количеством пустых строк в файле (выявляется визуальным анализом текста файла);

7) количеством подпрограмм в файле (является контекстным поиском заголовков procedure и function в тексте файла);

8) количеством операторов описания подпрограмм в файле;

9) количеством строк кода, рассчитанных по формуле: количество строк кода = 2) — 3) — 5) — 6) — 8).

Количество операторов описания подпрограмм в файле выявляется по принципу подсчета всех срок, например, в следующем примере выявлено четыре строки:

function CellString (Col, Row: Word; var Color: Word;

Formatting; Boolean): String;

Begin

End; {CellStrung}

Для проведения объективного сравнительного анализа потребовался выбор функционально похожих программ:

— Mcalc — рассмотренная ранее в гл. 2 и 7 демонстрационная программа, реализованная по технологии структурного программирования;

— Tcalc — демонстрационная программа, реализованная по технологий объектно-ориентированного программирования — функционально полный аналог программы Mcalc.

Результаты арифметического анализа текста программы MCalc, разработанной по технологии структурного программирования, представлены в табл. 8.1.

Таблица 8.1

Результаты анализа текста программы MCalc

Имя файла

Всего строк

Количество описательных операторов

Комментарии

Пустых строк

Количество процедур

Количество описательных операторов процедур

Код

Всего

Строк

Mcalc

143

8

11

7

5

2

6

117

Mcdisply

357

54

47

15

49

18

64

175

Mcinput

240

33

18

8

19

7

25

155

Mclib

503

68

47

20

46

21

73

296

Mcommand

873

88

63

19

54

24

86

626

Mcparser

579

51

33

21

16

12

36

455

Mcutil

413

62

46

16

45

18

75

215

mcvars

124

96

9

5

19

0

0

0

Итого:

3232

460

274

111

253

102

365

2043

15,4%

3,7%

12,3%

68,6%

Анализ демонстрационный программы TCalc "Borland Inc."

Программа TCalc 1993 (Turbo Pascal 6.0) состоит из следующих файлов:

tcalc.pas — файл основной программы;

tcell.pas — файл работы с клетками;

tcellsp.pas — файл дополнений работы с клетками (изменение значений);

tchash.pas — файл дополнений работы с клетками (значения в клетках);

tcinput.pas — файл подпрограмм ввода данных с клавиатуры;

tclstr.pas — файл подпрограмм работы со строками;

tcmenu.pas — файл подпрограмм, обслуживающих систему меню;

tcparser.pas — файл интерпретатора арифметических выражений формул клеток;

tcrun.pas — файл инициализации и запуска основных объектов;

tcscreen.pas — файл подпрограмм работы с дисплеем;

tcsheet.pas — файл подпрограмм, обслуживающих действия, выбранных посредством меню;

tcutil.pas — файл вспомогательных подпрограмм;

mcmvsmem.asm — ассемблерный файл подпрограмм запоминания в оперативной памяти информации экрана, а также восстановления ранее сохраненной информации экрана.

Все файлы закодированы с соблюдением стандартов оформления.

Хотя фирма "Borland Inc." занимается разработкой компиляторов, файл mcparser.pas также является заимствованным из UNIX YACC utility и лишь частично модифицирован. Остальные файлы являются оригинальными.

Ассемблерный файл mcmvsmem.asm является искусственно добавленным. Цель его добавления — демонстрация возможности использования ассемблерных вставок. Результаты арифметического анализа текста программы представлены в табл. 8.2.

Таблица 8.2

Результаты анализа текста программы TCalc

Имя файла

Всего строк

Количество описательных операторов

Комментарии

Пустых строк

Количество процедур

Количество описательных операторов процедур

Код

Всего

Строк

Tcalc

21

2

9

3

5

1

3

8

Tcell

1962

490

206

20

153

46

152

1147

Tcellsp

228

39

24

5

18

6

25

141

Tchash

262

50

47

23

23

14

43

123

Tcinput

334

63

39

15

22

9

32

202

Tclstr

243

45

120

20

12

15

52

114

Tcmenu

234

48

40

20

21

22

66

79

Tcparser

677

73

29

5

17

9

64

518

Tcrun

1367

146

128

59

57

47

163

942

Tcscreen

523

215

92

37

16

8

96

159

Tcsheet

1722

240

170

40

44

32

101

1297

Tcutil

379

114

55

38

70

29

115

42

Итого:

7952

1525

959

285

458

238

912

4772

20,3%

3,8%

12,2%

63,7%

В табл. 8.3 и на рис. 8.3 отображены результаты сравнительного анализа технологий структурного и объектно-ориентированного программирования.

Таблица 8.3

Результаты сравнительного анализа технологий структурного и объектно-ориентированного программирования

Имя программы

Всего строк

Количество описательных операторов

Комментарии

Пустых строк

Количество процедур

Количество операторов процедур

Код

Всего

Строк

MCalc

3232

460

274

111

253

102

365

2043

15,4%

3,7%

12,3%

68,6%

TCalc

7952

1525

959

285

458

238

912

4772

20,3%

3,8%

12,2%

63,7%

Сравнительный анализ технологий структурного и объектно-ориентированного программирования установил, что для этих технологий наблюдается практически полное совпадение:

• процентного состава описательных операторов;

• процентного состава количества комментариев;

• процентного состава описательных операторов процедур;

• процентного состава операторов кода программы.

Рис. 8.3. Результаты сравнительного анализа технологий структурного и объектно-ориентированного программирования

При проведении разработки по технологии объектно-ориентированного программирования по сравнению с технологией структурного программирования объем кода увеличился в 2,34 раза с учетом только кода, выполняющего одни и те же функции (для этого был исключен код функций, аналогичных функциям работы с clipboard Windows). Общее число строк увеличилось в 2,46 раза. Во столько и даже более раз увеличилась трудоемкость разработки.

Собственно функционально полезный код программ Mcalc и Tcalc — одинаковый и составляет порядка 1500 строк.

Почти 2,3–3,5 кратное увеличение трудоемкости разработки объясняется платой за организацию самостоятельности поведения объектов и их завершенную функциональность для повторного использования.

8.4. ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ

С чего же начинается создание объектно-ориентированной программы?

Конечно, с объектно-ориентированного анализа (ООА — object-oriented analysis), который направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения. Объектно-ориентированный анализ (ООА) — это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, прагматически выявленных в предметной области.

На результатах QOA формируются модели, на которых основывается объектно-ориентированное проектирование (object-oriented design, OOD).

Объектно-ориентированное проектирование (ООП) — это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.

Что же такое объектно-ориентированное программирование (ООПр) (object-oriented programming)? Программирование прежде всего подразумевает правильное и эффективное использование механизмов конкретных языков программирования. Объектно-ориентированное программирование — это процесс реализации программ, основанный на представлении программы в виде совокупности объектов. ООПр предполагает, что любая функция (процедура) в программе представляет собой метод объекта некоторого класса, причем класс должен формироваться в программе естественным образом, как только в программе возникает необходимость описания новых физических предметов или их абстрактных понятий (объектов программирования). Каждый новый шаг в разработке алгоритма также должен представлять собой разработку нового класса на основе уже существующих классов, т. е. технология ООПр иначе может быть названа как программирование "от класса к классу".

Можно ли реализовать объектно-ориентированную программу не на объектно-ориентированных языках? Ответ, скорее всего, положителен, хотя придется преодолеть ряд трудностей. Ведь главное, что требуется, — это реализовать объектную модель. Сокрытие информации при использовании обычных языков, в принципе, можно реализовать сокрытием доступности вызовов подпрограмм в файлах (Unit). Инкапсуляцию объектов можно достичь как и в объектно-ориентированных языках написанием отдельных подпрограмм. Далее можно считать, что каждый объект порождается от своего уникального класса. Конечно, иерархии классов в таком проекте не будет и для достижения параллелизма придется писать код для организации вызова к исполнению как бы сразу нескольких копий процедур, но программа при этом будет вполне объектно-ориентированной.

8.5. ОСНОВНЫЕ ПОНЯТИЯ, ИСПОЛЬЗУЕМЫЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКАХ

Класс в одном из значений этого термина обозначает тип структурированных данных.

Объект — это структурированная переменная типа класс. Каждый объект является представителем (экземпляром) определенного класса. В программе может быть несколько объектов, являющихся экземплярами одного и того же класса. Все объекты — экземпляры данного класса — аналогичны друг другу, поскольку имеют одинаковый интерфейс, один и тот же набор операций (методов) и полей, определяемых в их классе. Интерфейс класса иногда называют особенностями класса.

Класс является описанием того, как будет выглядеть и вести себя его представитель. Обычно проектируют класс как образование (матрицу), отвечающее за создание своих новых представителей (экземпляров или объектов). Экземпляр объекта создается при помощи особого метода класса, называемого конструктором, так как необходимо создать экземпляр, прежде чем он станет активным и начнет взаимодействовать с окружающим миром. Уничтожение экземпляров поддерживает сам активный экземпляр, имеющий соответствующий метод — деструктор.

Объект — это структурированная переменная типа класс, содержащая всю информацию о некотором физическом предмете или реализуемом в программе понятии.

Объект — это логическая единица, которая содержит данные и правила (методы с кодом алгоритма) (см. рис. 1.8). Другими словами, объект — это расположенные в отдельном участке памяти:

— порция данных объекта или атрибуты исходных данных, называемые еще полями, членами данных (data members), значения которых определяют текущее состояние объекта;

— методы объекта (methods, в разных языках программирования еще называют подпрограммами, действиями, member functions или функциями-членами), реализующие действия (выполнение алгоритмов) в ответ на их вызов в виде переданного сообщения;

— часть методов, называемых свойствами (property), которые, в свою очередь, определяют поведение объекта, т. е. его реакцию на внешние воздействия (в ряде языков программирования свойства оформляются особыми операторами).

Объекты в программах воспроизводят все оттенки явлений реального мира: "рождаются" и "умирают"; меняют свое состояние; запускают и останавливают процессы; "убивают" и "возрождают" другие объекты.

Объявления классов определяют уже описанные три характеристики объектов: поля объекта, методы объекта, свойства объектов. Также в объявлениях может указываться предок данного класса.

В соответствии с описанием класса внутри объекта данные и методы могут быть как открытыми по интерфейсу public, так и сокрытыми private.

Во время выполнения программы объекты взаимодействуют друг с другом посредством вызова методов вызываемого объекта — в этом и заключается передача сообщений. Для того чтобы объект послал сообщение другому объекту, в большинстве языков программирования требуется после указания имени вызываемого объекта записать вызов подпрограммы (метода) с соответствующим именем и указанием необходимых фактических параметров (аргументов). Получив сообщение, объект-получатель начинает выполнять код вызванной подпрограммы (метода) с полученными значениями аргументов. Таким образом, функционирование программы (выполнение всего алгоритма программы) осуществляется последовательным вызовом методов от одного объекта к другому.

Хотя можно получить прямой доступ к полям объекта, использование такого подхода не поощряется. Одно из больших преимуществ ООПр — это инкапсуляция, предназначенная для разрешения работы с данными в полях объектов только через сообщения. Для реализации методов обработки таких сообщений используются свойства. Свойства — это особым образом оформленные методы, предназначенные как для чтения и контролируемого изменения внутренних данных объекта (полей), так и выполнения действий, связанных с поведением объекта.

Так, например, если в заданном месте экрана уже отображена какая-то строка и мы хотим изменить положение строки на экране, то мы посылаем объекту новое значение свойства в виде набора нужных координат. Далее свойство автоматически трансформируется в вызов метода, который изменит значение поля координат отображения строки и выполнит действия по уничтожению изображения строки на прежнем месте экрана, а также по отображению строки в новом месте экрана.

Можно выделить несколько преимуществ инкапсуляции.

Преимущество 1. Надежность данных. Можно предотвратить изменение элемента данных, выполнив в свойстве (методе) дополнительную проверку значения на допустимость. Тем самым можно гарантировать надежное состояние объекта.

Преимущество 2. Целостность ссылок. Перед доступом к объекту, связанному с данным объектом, можно удостовериться, что косвенное поле содержит корректное значение (ссылку на экземпляр).

Преимущество 3. Предусмотренные побочные эффекты. Можно гарантировать, что каждый раз, когда выполняется обращение к полю объекта, синхронно с ним выполняется какое-либо специальное действие.

Преимущество 4. Сокрытие информации. Когда доступ к данным осуществляется только через методы, можно скрыть детали реализации объекта. Позднее, если реализация изменится, придется изменить лишь реализацию методов доступа к полям. Те же части программы, которые использовали этот класс, не будут затронуты.

Весьма удобно рассматривать объекты как попытку создания активных данных. Смысл, вкладываемый в слова "объект представляет собой активные данные", основан на объектно-ориентированной парадигме выполнения операций, состоящей в посылке сообщений. В посылаемых объекту сообщениях указывается, что мы хотим, что бы он выполнил. Так, например, если мы хотим вывести на экране строку, то мы посылаем объекту строки сообщение, чтобы он изобразил себя. В этом случае строка — это уже не пассивный кусок текста, а активная единица, знающая, как правильно производить над собой различные действия.

Одна из фундаментальных концепций ООП — это понятие наследования классов, устанавливающее между двумя классами отношения "родитель-потомок".

Наследование — отношение самого высокого уровня и играет важную роль на стадии проектирования. Наследование — это определение класса и затем использование его для построения иерархии производных классов, причем каждый класс-потомок наследует от класса-предка интерфейс всех классов-предков в виде доступа к коду их методов и данным. При этом, возможно, переопределение или добавление как новых данных, так и методов.

Класс-предок — это класс, предоставляющий свои возможности и характеристики другим классам через механизм наследования. Класс, который использует характеристики другого класса посредством наследования, называется его классом-потомком.

Итак, наследование проявляется в том, что любой класс-потомок имеет доступ или, другими словами, наследует практически все ресурсы (методы, поля и свойства) родительского класса и всех предков до самого верхнего уровня иерархии.

Рассмотрим, как информация, содержащаяся в классе-потомке, может переопределять информацию, наследуемую от предков. Очень часто при реализации такого подхода метод, соответствующий подклассу, имеет то же имя, что и соответствующий метод в родительском классе. При этом для поиска метода, подходящего для обработки сообщения, используется следующее правило. Поиск метода, который вызывается в ответ на определенное сообщение, начинается с методов, принадлежащих классу получателя. Если подходящий метод не найден, то поиск продолжается до родительского класса. Поиск продвигается вверх по цепочке родительских классов до тех пор, пока не будет найден нужный метод или пока не будет исчерпана последовательность родительских классов. В первом случае выполняется найденный метод, во втором выдается сообщение об ошибке. Во многих языках программирования уже на этапе компилирования, а не при выполнении программы определяется, что подходящего метода нет вообще и выдается сообщение об ошибке.

Семантически наследование описывает отношение типа "is-a". Например, медведь есть млекопитающее, дом есть недвижимость и "быстрая сортировка" есть сортирующий алгоритм. Таким образом, наследование порождает иерархию "обобщение — специализация", в которой подкласс представляет собой специализированный частный случай своего суперкласса. "Лакмусовая бумажка" наследования — обратная проверка: так, если В не есть А, то В не стоит производить от А.

Повторное использование — это использование в программе класса для создания экземпляров или в качестве базового для создания нового класса, наследующего часть или все характеристики родителя. Порождая классы от базовых, вы эффективно повторно используете код базового класса для собственных нужд. Повторное использование сокращает объем кода, который необходимо написать и оттестировать при реализации программы, что сокращает объемы труда.

Таким образом, наследование выполняет в ООП несколько важных функций:

• моделирует концептуальную структуру предметной области;

• экономит описания, позволяя использовать их многократно для задания разных классов;

• обеспечивает пошаговое программирование больших систем путем многократной конкретизации классов.

Ряд языков, например Object Pascal, описание которого дается в приложении 4, поддерживает модель наследования, известную как простое наследование и которая ограничивает число родителей конкретного класса одним. Другими словами, определенный пользователем класс имеет только одного родителя. Схема иерархии классов в этом случае представляет собой ряд одиночно стоящих деревьев (hierarchical classification).

Более мощная модель сложного наследования, называемая множественным наследованием, в которой каждый класс может, в принципе, порождаться сразу от нескольких родительских классов, наследуя поведение всех своих предков. Множественное наследование не поддерживается в Delphi, но поддерживается в Visual C++ и ряде других языков. При множественном наследовании составляется уже не схема иерархии, а сеть, которая может включать деревья со сросшимися кронами.

Обычно если объекты соответствуют конкретным сущностям реального мира, то классы являются абстракциями, выступающими в роли понятий. Между классами, как между понятиями, существует иерархическое отношение конкретизации, связывающее класс с классом-потомком. Это отношение реализуется в системах ООП механизмом наследования. Наследование — это способность одного класса использовать характеристики другого.

Наследование позволяет практически без ограничений последовательно строить и расширять классы, созданные вами или кем-то еще. Начиная с самых простых классов можно создавать производные классы по возрастающей сложности, которые не только легки при отладке, но и просты по внутренней структуре.

Множественное наследование многие аналитики считают "вредным" механизмом, приводящим к сложно разрешимым проблемам проектирования и реализации. В языках с отсутствующим множественным наследованием целей множественного наследования достигают агрегированием объектов с дополнительным делегированием полномочий.

На агрегировании основана работа таких систем визуального программирования, как Delphi, C++ Builder. В этих системах имеется порождающий объект пользователя класс-форма (пустое окно Windows). Системы обеспечивают подключение к форме через указатели нужных пользователю объектов, например кнопок, окон редакторов и т. д. При перерисовке формы на экране монитора как бы одновременно с ней перерисовываются изображения агрегированных объектов. Более того, при активизации формы агрегированные объекты также становятся активными: кнопки начинают нажиматься, а в окна редакторов можно начинать вводить информацию.

Одним из базовых понятий технологии ООП является полиморфизм. Термин "полиморфизм" имеет греческое происхождение и означает приблизительно "много форм" (poly — много, morphos — форма).

Полиморфизм — это средство для придания различных значений одному и тому же событию в зависимости от типа обрабатываемых данных, т. е. полиморфизм определяет различные формы реализации одноименного действия (см. рис. 8.2.).

Целью полиморфизма применительно к объектно-ориентированному программированию является использование одного имени для задания общих для класса действий, причем каждый объект имеет возможность по-своему реализовать это действие своим собственным, подходящим для него кодом.

Полиморфизм является предпосылкой для расширяемости объектно-ориентированных программ, поскольку он предоставляет способ старым программам воспринимать новые типы данных, которые не были определены во время написания программы.

Противоположность полиморфизму называется мономорфизмом; он характерен для языков с сильной типизацией и статическим связыванием (Ada).

В более общей трактовке полиморфизм — это способность объектов, принадлежащих к разным типам, демонстрировать одинаковое поведение; способность объектов, принадлежащих к одному типу, демонстрировать разное поведение.

Рассмотрим "вырожденный пример" полиморфизма. В MS DOS есть понятие "номер прерывания", за которым скрывается адрес в памяти. Поместите в ту же ячейку другой адрес — и программы начнут вызывать процедуру с другим "именем" и из другого модуля. Как видно из примера, принцип полиморфизма можно реализовать и не в объектно-ориентированных программах.

Ряд авторов книг по теории объектно-ориентированного проектирования соотносят термин "полиморфизм" с разными понятиями, например понятием перегрузки; для обозначения одного-двух или большего количества механизмов полиморфизма; чистого полиморфизма.

Перегрузка функций. Одним из применений полиморфизма в C++ является перегрузка функций. Она дает одному и тому же имени функции различные значения. Например, выражение а + b имеет различные значения, в зависимости от типов переменных а и b (допустим, если это числа, то "+" означает сложение, а если строки, — то склейку этих строк или вообще сложение комплексных чисел, если а и b комплексного типа). Перегрузка оператора "+" для типов, определяемых пользователем, позволяет использовать их в большинстве случаев так же, как и встроенные типы. Двум или более функциям (операция — это тоже функция) может быть дано одно и то же имя. Но при этом функции должны отличаться сигнатурой (либо типами параметров, либо их числом).

Полиморфный метод в C++ называется виртуальной функцией, позволяющей получать ответы на сообщения, адресованные объектам, точный вид которых неизвестен. Такая возможность является результатом позднего связывания. При позднем связывании адреса определяются динамически во время выполнения программы, а не статически во время компиляции как в традиционных компилируемых языках, в которых применяется раннее связывание. Сам процесс связывания заключается в замене виртуальных функций на адреса памяти.

Виртуальные методы определяются в родительском классе, а в производных классах происходит их доопределение и для них создаются новые реализации. Основой виртуальных методов и динамического полиморфизма являются указатели на производные классы. При работе с виртуальными методами сообщения передаются как указатели, которые указывают на объект вместо прямой передачи объекту.

Практический смысл полиморфизма заключается в том, что он позволяет посылать общее сообщение о сборе данных любому классу, причем и родительский класс, и классы-потомки ответят на сообщение соответствующим образом, поскольку производные классы содержат дополнительную информацию. Программист может сделать регулярным процесс обработки несовместимых объектов различных типов при наличии у них такого полиморфного метода.

8.6. ЭТАПЫ И МОДЕЛИ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ

Почему в начале процесса проектирования работу начинают с анализа функционирования или поведения системы? Дело в том, что поведение системы обычно известно задолго до остальных ее свойств. Программа должна выполнять набор действий, согласно выявленным ее функциям. Процесс разработки модели в форме функциональной спецификации уже был изложен ранее в гл. 5.

Объектно-ориентированная технология создания программ основывается на так называемом объектном подходе. Одним из проявлений этого подхода является то, что сначала довольно долго создаются и оптимизируются объектная модель и иные модели и лишь затем осуществляется кодирование.

Обычно проектируемая программная система первоначально представляется в виде трех взаимосвязанных моделей:

1) объектной модели, которая представляет статические, структурные аспекты системы;

2) динамической модели, которая описывает работу отдельных частей системы;

3) функциональной модели, в которой рассматривается взаимодействие отдельных частей системы (как по данным, так и по управлению) в процессе ее работы.

Эти три вида моделей должны позволить рассматривать три взаимно-ортогональных представления системы в одной системе обозначений.

Объектная модель на более поздних этапах проектирования дополняется моделями, отражающими как логическую (классы и объекты), так и физическую структуру системы (процессы и деление на компоненты, файлы или модули).

Поскольку при разработке объектно-ориентированного проекта используется множество моделей, которые необходимо увязать в единое целое, далее в гл. 10 рассматриваются средства автоматизации составления, верификации (проверки) и графической визуализации этих моделей.

Процесс построения объектной модели включает в себя следующие, возможно, повторяющиеся до достижения приемлемого качества модели этапы:

1) определение объектов;

2) подготовку словаря объектов с целью исключения схожих (синонимичных) понятий и уточнения имен, классификацию объектов, выделение классов;

3) определение взаимосвязей между объектами;

4) определение атрибутов объектов и методов (определение уровней доступа и проектирование интерфейсов классов);

5) исследование качества модели.

Теперь, используя функциональную модель, можно начинать работу с динамической моделью, наделяя объекты необходимыми методами и данными.

Модели, разработанные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, ее отладку и тестирование, сопровождение и дальнейшую модификацию.

Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается прежде всего прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.

Прагматика определяется целью разработки программной системы: для обслуживания покупателей железнодорожных билетов, управления работой аэропорта, обслуживания чемпионата мира по футболу и т. п. В формулировке цели участвуют предметы и понятия реального мира, имеющие отношение к разрабатываемой программной системе.

Объектную модель можно описать следующим образом:

1) основные элементы модели — объекты и сообщения;

2) объекты создаются, используются и уничтожаются подобно динамическим переменным в обычных языках программирования;

3) выполнение программы заключается в создании объектов и передаче им последовательности сообщений.

Объектная модель базируется на четырех главных принципах: абстрагировании; инкапсуляции; модульности; иерархии.

Эти принципы являются главными в том смысле, что без любого из них модель не будет по-настоящему объектно-ориентированной.

Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования.

Все абстракции обладают как статическими, так и динамическими свойствами. Например, файл как объект требует определенного объема памяти на конкретном устройстве, имеет имя и содержание. Эти атрибуты являются статическими свойствами. Конкретные же значения каждого из перечисленных свойств динамичны и изменяются в процессе использования объекта: файл можно увеличить или уменьшить, изменить его имя и содержимое.

Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Чаще всего инкапсуляция дополняется сокрытием информации, т. е. маскировкой всех внутренних деталей, не влияющих на внешнее поведение. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого объекта, скрыты от внешних компонент.

При объектно-ориентированном проектировании необходимо физически разделить классы и объекты, составляющие логическую структуру проекта. Такое разделение делает возможным повторно использовать во все новых проектах код модулей, написанных ранее. Модулю в данном контексте соответствует отдельный файл исходного текста. На выбор разбиения на модули могут влиять и некоторые внешние обстоятельства. При коллективной разработке программ распределение работы осуществляется, как правило, по модульному принципу, и правильное разделение проекта минимизирует связи между участниками.

Таким образом, принципы абстрагирования, инкапсуляции и модульности являются взаимодополняющими. Объект логически определяет границы определенной абстракции, а инкапсуляция и модульность делают их физически незыблемыми.

Имея выявленные объекты, можно приступить к выявлению классов. Классы чаще всего строятся постепенно, начиная от простых родительских классов и заканчивая более сложными. Непрерывность процесса основана на наследовании. Каждый раз, когда из предыдущего класса производится последующий, производный класс наследует какие-то или все родительские качества, добавляя к ним новые. Завершенный проект может включать десятки и сотни классов, но часто все они произведены от считанного количества родительских классов.

8.7. КАКИМИ БЫВАЮТ ОБЪЕКТЫ ПО УСТРОЙСТВУ

Под паттернами проектирования понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. Паттерн проектирования — это образец, типовое решение какого-либо механизма объектно-ориентированной программы. Паттерны создавались несколько лет коллективом с целью уравнивания шансов на хороший проект опытных и не очень опытных проектировщиков. По словам архитектора Кристофера Александра, "любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно потом использовать миллион раз, ничего не изобретая заново".

В общем случае паттерн состоит из четырех основных элементов: имени, задачи, решения, результатов.

Имя. Сославшись на него, можно сразу описать проблему проектирования, ее решения и их последствия. С помощью словаря паттернов можно вести обсуждение с коллегами, упоминать паттерны в документации.

Задача — описание того, когда следует применять паттерн. Здесь может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов. Иногда отмечается, какие структуры классов или объектов свидетельствуют о негибком дизайне. Также может включаться перечень условий, при выполнении которых имеет смысл применять данный паттерн.

Решение — описание элементов дизайна, отношений между ними, функций каждого элемента. Конкретный дизайн или реализация не имеются в виду, поскольку паттерн — это шаблон, применимый в самых разных ситуациях. Просто дается абстрактное описание задачи проектирования и того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов (в нашем случае классов и объектов).

Результаты — это следствия применения паттерна и разного рода компромиссы. Хотя при описании проектных решений о последствиях часто не упоминают, знать о них необходимо, чтобы можно было осуществить выбор различных вариантов и оценить преимущества и недостатки выбранного паттерна. Здесь речь идет о выборе языка и реализации. Поскольку в объектно-ориентированном проектировании повторное использование зачастую является важным фактором, то к результатам следует относить и влияние на степень гибкости, расширяемости и переносимости системы. Перечисление всех последствий поможет вам понять и оценить их роль. Ниже приведен полный список разделов описания паттерна:

— название и классификация паттерна (название паттерна должно четко отражать его назначение);

— назначение (лаконичный ответ на следующие вопросы: каковы функции паттерна, его обоснование и назначение, какую конкретную задачу проектирования можно решить с его помощью);

— известен также под именем (другие распространенные названия паттерна, если таковые имеются);

— мотивация (сценарий, иллюстрирующий задачу проектирования и то, как она решается данной структурой класса или объекта. Благодаря мотивации, можно лучше понять последующее, более абстрактное описание паттерна);

— применимость (описание ситуаций, в которых можно применять данный паттерн; примеры проектирования, которые можно улучшить с его помощью);

— структура (графическое представление классов в паттерне с использованием нотации, основанной на методике ОМТ, а также с использованием диаграмм взаимодействий для иллюстрации последовательностей запросов и отношений между объектами);

— участники (классы или объекты, задействованные в данном паттерне проектирования, и их функции);

— отношения (взаимодействие участников для выполнения своих функций);

— результаты (насколько паттерн удовлетворяет поставленным требованиям? Результаты применения, компромиссы, на которые приходится идти. Какие аспекты поведения системы можно независимо изменять, используя данный паттерн?);

— реализация (сложности и так называемые "подводные камни" при реализации паттерна; советы и рекомендуемые приемы; есть ли у данного паттерна зависимость от языка программирования?);

— пример кода (фрагмент кода, иллюстрирующий вероятную реализацию на языках C++ или Smalltalk);

— известные применения (возможности применения паттерна в реальных системах; даются, по меньшей мере, два примера из различных областей);

— родственные паттерны (связь других паттернов проектирования с данными, важные различия, использование данного паттерна в сочетании с другими).

Каталог содержит 23 паттерна. Ниже для удобства перечислены их имена и назначение.

1. Abstract Factory (абстрактная фабрика). Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

2. Adapter (адаптер). Преобразует интерфейс класса в некоторый другой интерфейс, ожидаемый клиентами. Обеспечивает совместную работу классов, которая была бы невозможна без данного паттерна из-за несовместимости интерфейсов.

3. Bridge (мост). Отделяет абстракцию от реализации, благодаря чему появляется возможность независимо изменять то и другое.

4. Builder (строитель). Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

5. Chain of Responsibility (цепочка обязанностей). Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

6. Command (команда). Инкапсулирует запрос в виде объекта, позволяя тем самым параметризовывать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

7. Composite (компоновщик). Группирует объекты в древовидные структуры для представления иерархий типа "часть-целое". Позволяет клиентам работать с единичными объектами так же, как с группами объектов.

8. Decorator (декоратор). Динамически возлагает на объект новые функции. Декораторы применяются для расширения имеющейся функциональности и являются гибкой альтернативой порождению подклассов.

9. Facade (фасад). Предоставляет унифицированный интерфейс к множеству интерфейсов в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой.

10. Factory Method (фабричный метод). Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами.

11. Flyweight (приспособленец). Использует разделение для эффективной поддержки большого числа мелких объектов.

12. Interpreter (интерпретатор). Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление.

13. Iterator (итератор). Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.

14. Mediator (посредник). Определяет объект, в котором инкапсулировано знание о том, как взаимодействуют объекты из некоторого множества. Способствует уменьшению числа связей между объектами, позволяя им работать без явных ссылок друг на друга. Это, в свою очередь, дает возможность независимо изменять схему взаимодействия.

15. Memento (хранитель). Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

16. Observer (наблюдатель). Определяет между объектами зависимость типа "один ко многим", так что при изменении состояния одного объекта все зависящие от него получают извещение и автоматически обновляются.

17. Prototype (прототип). Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования.

18. Proxy (заместитель). Подменяет другой объект для контроля доступа к нему.

19. Singleton (одиночка). Гарантирует, что некоторый класс может иметь только один экземпляр, и предоставляет глобальную точку доступа к нему.

20. State (состояние). Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что поменялся класс объекта.

21. Strategy (стратегия). Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. Можно менять алгоритм независимо от клиента, который им пользуется.

22. Template Method (шаблонный метод). Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.

23. Visitor (посетитель). Представляет операцию, которую надо выполнить над элементами объекта. Позволяет определить новую операцию, не меняя классы элементов, к которым он применяется.

8.8. ПРОЕКТНАЯ ПРОЦЕДУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПО Б. СТРАУСТРУПУ

8.8.1. Укрупненное изложение проектной процедуры Б. Страуструпа

Б. Страуструп — автор объектно-ориентированного языка программирования C++ с множественным наследованием. У Б. Страуструпа при описании методики проектирования вводится единица проектирования — "компонента". Под компонентой понимается множество классов, объединенных некоторым логическим условием, иногда это общий стиль программирования или описания, иногда — предоставляемый сервис. Ряд авторов вместо термина "компонента" используют термин "модуль".

Структура компонент проектируется использованием итерационного нарастающего процесса. Обычно для получения проекта, который можно уверенно использовать для первичной реализации

или повторной, нужно несколько раз проделать последовательность из следующих четырех шагов.

Шаг 1. Выделение понятий (классов, порождающих объекты) и установление основных связей между ними.

Шаг 2. Уточнение классов с определением наборов операций (методов) для каждого.

Шаг 3. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.

Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные. Определяются типы операций над классами.

8.8.2. Шаг 1. Выделение понятий и установление основных связей между ними

Выделение объектов производится во время процесса мысленного представления системы. Часто это происходит как цикл вопросов "что/кто". Команда программистов определяет: что требуется делать? Это немедленно приводит к вопросу: кто будет выполнять действие? Теперь программная система в значительной мере становится похожей на некую организацию. Действия, которые должны быть выполнены, присваиваются некоторому программному объекту в качестве его обязанностей.

Понятия (объекты) соответствуют порождающим классам и могут иметь форму в виде имен существительных и, как экзотика, глаголов и имен прилагательных.

Часто говорят, что понятия в форме имен существительных играют роль классов и объектов, используемых в программе. Например: трактор, редуктор, гайка, редактор, кнопка, файл, матрица. Это действительно так, но это только начало.

Глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать манипуляторы, предложенные А. Кенигом. Суть идеи манипулятора в том, что создается объект, который можно передавать куда угодно и который используется как функция. Такие глаголы, как "повторить" или "совершить", могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных.

Даже имена прилагательные можно успешно представлять с помощью классов. Например, такими классами могут быть: "хранимый", "параллельный", "регистровый", "ограниченный", — а также классы, которые помогут разработчику или программисту, задав виртуальные базовые классы, специфицировать и выбрать нужные свойства для классов, проектируемых позднее.

Все классы можно условно разделить на две группы: классы из предметной (прикладной) области и классы, являющиеся артефактами реализации или абстракциями периода реализации.

Классы из предметной (прикладной) области — непосредственно отражают понятия из прикладной области, т. е. понятия, которые использует конечный пользователь для описаний своих задач и методов их решения.

Лучшее средство для поиска этих понятий/классов — грифельная доска, а лучший метод первого уточнения — беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный словарь терминов и понятийную структуру.

Главное в хорошем проекте — прямо отразить какое-либо понятие "реальности", т. е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например с помощью наследования, и повторить эти действия на разных уровнях абстракции.

Классы, являющиеся артефактами реализации или абстракциями периода реализации, — это те понятия, которые применяют программисты и проектировщики для описания методов реализации:

• классы, отражающие ресурсы оборудования (оперативная память, механизмы управления ресурсами, дисковое пространство);

• классы, представляющие системные ресурсы (процессы, потоки ввода-вывода);

• классы, реализующие программные структуры (стеки, очереди, списки, деревья, словари и т. п.);

• другие абстракции, например элементы управления программой (кнопки, меню и т. п.).

Хорошо спроектированная система должна содержать классы, которые дают возможность рассматривать систему с логически разных точек зрения.

Пример:

1) классы, представляющие пользовательские понятия (например, легковые машины и грузовики);

2) классы, представляющие обобщения пользовательских понятий (движущиеся средства);

3) классы, представляющие аппаратные ресурсы (например, класс управления памятью);

4) классы, представляющие системные ресурсы (например, выходные потоки);

5) классы, используемые для реализации других классов (например, списки, очереди);

6) встроенные типы данных и структуры управления.

В больших системах очень трудно сохранять логическое разделение типов различных классов и поддерживать такое разделение между различными уровнями абстракции. В приведенном выше перечислении представлены три уровня абстракции:

(1+2) — представляет пользовательское отражение системы;

(3+4) — представляет машину, на которой будет работать система;

(5+6) — представляет низкоуровневое (со стороны языка программирования) отражение реализации.

Чем больше система, тем большее число уровней абстракции необходимо для ее описания и тем труднее определять и поддерживать эти уровни абстракции. Отметим, что таким уровням абстракции есть прямое соответствие в природе и в различных построениях человеческого интеллекта. Например, можно рассматривать дом как объект, состоящий из атомов; молекул; досок и кирпичей; стен, пола и потолков; комнат.

Пока удается хранить раздельно представления этих уровней абстракции, можно поддерживать целостное представление о доме. Однако если смешать их, возникнет бессмыслица.

Взаимоотношения, о которых мы говорим, естественно устанавливаются в области приложения или (в случае повторных проходов по шагам проектирования) возникают из последующей работы над структурой классов. Они отражают наше понимание основ области приложения и часто являются классификацией основных понятий. Пример такого отношения — машина с выдвижной лестницей есть грузовик, есть пожарная машина, есть движущееся средство.

8.8.3. Шаг 2. Уточнение классов с определением набора операций (методов) для каждого

В действительности нельзя разделить процессы определения классов и выяснения того, какие операции для них нужны. Однако на практике они различаются, поскольку при определении классов внимание концентрируется на основных понятиях, не останавливаясь на программистских вопросах их реализации, тогда как при определении операций прежде всего сосредоточиваются на том, чтобы задать полный и удобный набор операций. Часто бывает слишком трудно совместить оба подхода, в особенности, учитывая, что связанные классы надо проектировать одновременно.

Возможно несколько подходов к процессу определения набора операций. Предлагаем следующую стратегию:

— рассмотрите, каким образом объект класса будет создаваться, копироваться (если нужно) и уничтожаться;

— определите минимальный набор операций, необходимый для понятия, представленного классом;

— рассмотрите операции, которые могут быть добавлены для удобства записи, и включите только несколько действительно важных;

— рассмотрите, какие операции можно считать тривиальными, т. е. такими, для которых класс выступает в роли интерфейса для реализации производного класса;

— рассмотрите, какой общности именования и функциональности можно достигнуть для всех классов компонента.

Очевидно, что это стратегия минимализма. Гораздо проще добавить любую функцию, приносящую ощутимую пользу, и сделать все операции виртуальными. Но чем больше функций, тем больше вероятность, что они не будут использоваться, наложат определенные ограничения на реализацию и затруднят эволюцию системы. Гораздо легче включить в интерфейс еще одну функцию, как только установлена потребность в ней, чем удалить ее оттуда, когда уже она стала привычной.

Причина, по которой мы требуем явного принятия решения о виртуальности данной функции, не оставляя его на стадию реализации, в том, что, объявив функцию виртуальной, существенно повлияем на использование ее класса и на взаимоотношения этого класса с другими.

При определении набора операций (методов) больше внимания следует уделять тому, что надо сделать, а не тому, как это сделать.

Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:

1) базовые операции: конструкторы, деструкторы, операции копирования;

2) селекторы: операции, не изменяющие состояния объекта;

3) модификаторы: операции, изменяющие состояние объекта;

4) операции преобразований, т. е. операции, порождающие объект другого типа, исходя из значения (состояния) объекта, к которому они применяются;

5) повторители: операции, которые открывают доступ к объектам класса или используют последовательность объектов.

Кроме уже перечисленных групп методов, в классы могут быть введены дополнительные методы самотестирования и проверки корректности данных. Это не есть разбиение на ортогональные группы операций. Например, повторитель может быть спроектирован как селектор или модификатор.

Выделение этих групп просто предназначено помочь в процессе проектирования интерфейса класса. Конечно, допустима и другая классификация.

8.8.4. Шаг 3. Уточнение классов с точным определением их зависимостей от других классов

Виды взаимоотношений между классами могут быть следующими: отношения наследования; отношения включения; отношения использования; запрограммированные отношения.

Еще одно взаимоотношение — отношение включения {агрегирования) — класс содержит в виде члена объект или указатель на объект другого класса. Позволяя объектам содержать указатели на другие объекты, можно создавать так называемые "иерархии объектов". Такие реализации альтернативно дополняют возможности использования иерархии классов.

Очень важным при проектировании является вопрос: какое отношение выбрать — агрегации (включения) или наследования. В принципе эти методы взаимозаменяемы, кроме случая, когда используется позднее связывание. Наиболее предпочтителен тот вариант, в котором наиболее точно моделируется окружающая действительность, т. е. если понятие X является частью понятия Y, то используется включение. Если понятие X более общее, чем Y, — то наследование.

Для составления и понимания проекта часто необходимо знать, какие классы и каким способом они используются, другими словами, отношения использования. Возможно следующим образом классифицировать те способы, с помощью которых класс X может использовать класс Y.

— X использует Y;

— X вызывает функцию-член (метод) Y;

— X читает член Y;

— X пишет в член Y;

— X создает Y;

— X размещает переменную из Y

Анализ подобных взаимосвязей позволяет выявить потребности в определенных методах классов или, наоборот, выявить их ненужность.

Запрограммированные отношения — те отношения проекта, которые не могут быть прямо представлены в виде конструкций языка. Допустим, в проекте оговорено, что каждая операция, не реализованная в классе А, должна обслуживаться объектом класса В. К запрограммированным отношениям относят также операции преобразования типов. Следует, по возможности, избегать применения этого вида отношений из-за усложнения реализации. Идеальный класс должен в минимальной степени зависеть от остального мира. Следовательно, следует стараться минимизировать зависимости.

8.8.5. Шаг 4. Задание интерфейсов классов

Спрячем подробности реализации за фасадом интерфейса. Объект инкапсулирует поведение, если он умеет выполнять некоторые действия, но подробности, как это делается, остаются скрытыми за фасадом интерфейса. Эта идея была сформулирована специалистом по информатике Дэвидом Парнасом в виде правил, которые часто называются принципами Парнаса.

Правило 1. Разработчик программы должен предоставлять пользователю всю информацию, которая нужна для эффективного использования приложения, и ничего кроме этого.

Правило 2. Разработчик программного обеспечения должен знать только требуемое поведение объекта и ничего кроме этого.

Следствие принципа отделения интерфейса от реализации состоит в том, что программист может экспериментировать с различными алгоритмами, не затрагивая остальные классы объектов программы.

На этом шаге дается четкое описание классов, их данных и методов (опуская реализацию и, возможно, скрытые методы). Всем методам задаются точные типы параметров.

Идеальный интерфейс представляет пользователю полный и последовательный набор понятий; согласован со всеми частями компоненты; не открывает подробности реализации и может быть реализован различными способами; ограниченно и четко определенным образом зависит от других интерфейсов.

Интерфейсы классов предоставляют полную информацию для реализации классов на этапе кодирования.

Существует золотое правило: если класс не допускает, по крайней мере, двух существенно отличающихся реализаций, то что-то явно не в порядке с этим классом, это просто замаскированная реализация, а не представление абстрактного понятия. Во многих случаях для ответа на вопрос: "Достаточно ли интерфейс класса независим от реализации?" — надо указать, возможна ли для класса схема обычных вычислений.

8.8.6. Перестройка иерархии классов

Пытаясь провести классификацию некоторых новых объектов, задаем следующие вопросы: В чем сходство этого объекта с другими объектами общего класса? В чем его различия? Каждый класс имеет набор поведений и характеристик, которые его определяют. Начнем с верхушки фамильного дерева образца и будем спускаться по ветвям, задавая эти вопросы на протяжении всего пути. Более высокие уровни являются более общими, а вопросы — более простыми. Каждый уровень является более специфическим, чем предыдущий уровень, и менее общим.

Без сомнения, это тривиальная задача, но установить идеальную иерархию классов для определенного применения очень трудно. Прежде чем написать строку кода программы, необходимо хорошо подумать о том, какие классы необходимы и на каком уровне. По мере того как увеличивается понимание, может оказаться, что необходимы новые классы, которые фундаментально изменяют всю иерархию классов.

На втором и третьем шагах итеративной процедуры проектирования производится выявление того, насколько адекватно классы и их иерархия подходят по сути проекта. Проектировщики вынуждены реорганизовывать, улучшать проект и повторять все шаги сначала, и так до тех пор, пока качество проекта не будет удовлетворительным.

При перестройке иерархии классов применяются четыре процедуры: расщепление класса на два и более; абстрагирование (обобщение); слияние; анализ возможности использования существующих разработок.

Расщепление применяется в следующих случаях:

1) если имеется сложный класс, иногда имеет смысл разделить его на несколько простых классов и тем самым обеспечить поэтапную разработку;

2) класс содержит ряд несвязанных между собой функций или набор независимых друг от друга данных.

Обобщение — выявление в группе классов общих свойств и вынесение их в общий базовый класс. Признаки необходимости обобщения таковы:

1) общая схема использования;

2) сходство между наборами операций;

3) сходство реализаций;

4) эти классы часто фигурируют вместе в дискуссиях по проекту.

Слияние — объединение нескольких небольших, но тесно взаимодействующих классов в один. Таким образом, взаимодействие будет скрыто в реализации нового класса.

Использование существующих разработок. Обособленный класс или группа классов из уже существующего проекта может быть легко интегрирована в новый класс. Однако подобная интеграция вносит определенные ограничения в структуру системы и может сказаться на эффективности разработки самой программы. Изготовители систем объектно-ориентированного программирования поставляют системы с совместимыми библиотеками классов. Очевидно, чем больше готовых библиотечных классов будет использовано в программе, тем меньше кода придется писать при реализации программы.

8.8.7. Свод правил

В рассмотренных ранее темах не было дано настоятельных и конкретных рекомендаций по проектированию. Это соответствует убеждению, что нет "единственно верного решения". Принципы и приемы следует применять такие, которые лучше подходят для решения конкретных задач. Для этого нужен вкус, опыт и разум. Тем не менее можно указать некоторый свод правил (эвристических приемов), который разработчик может использовать в качестве ориентиров, пока не будет достаточно опытен, чтобы выработать лучшие правила. Ниже приведен свод таких эвристических правил.

Правило 1. Узнайте, что вам предстоит создать.

Правило 2. Ставьте определенные и осязаемые цели.

Правило 3. Не пытайтесь с помощью технических приемов решить социальные проблемы.

Правило 4. Рассчитывайте на большой срок в проектировании и управлении людьми.

Правило 5. Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.

Правило 6. Проектируйте в расчете на изменения: гибкость, расширяемость, переносимость, повторное использование.

Правило 7. Документируйте, предлагайте и поддерживайте повторно используемые компоненты.

Правило 8. Поощряйте и вознаграждайте повторное использование: проектов, библиотек, классов.

Правило 9. Сосредоточьтесь на проектировании компоненты.

Правило 10. Используйте классы для представления понятий.

Правило 11. Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.

Правило 12. Проводите строгую типизацию интерфейсов всегда, когда это возможно.

Правило 13. Используйте в интерфейсах типы из области приложения всегда, когда это возможно.

Правило 14. Многократно исследуйте и уточняйте как проект, так и реализацию.

Правило 15. Используйте лучшие доступные средства для проверки и анализа проекта и реализации.

Правило 16. Экспериментируйте, анализируйте и проводите тестирование на самом возможном раннем этапе.

Правило 17. Стремитесь к простоте, максимальной простоте, но не сверх того.

Правило 18. Не разрастайтесь, не добавляйте возможности "на всякий случай".

Правило 19. Не забывайте об эффективности.

Правило 20. Сохраняйте уровень формализации, соответствующий размеру проекта.

Правило 21. Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.

8.8.8. Пример простейшего проекта

Б. Страуструп придумал реализацию механизма множественного наследования и при этом отвергал агрегирование, хотя и реализовал это в своем языке C++.

Приведенный далее пример показывает невозможность осуществления решения следующей простой задачи двумя способами решения — с использованием множественного наследования и агрегирования. В процессе решения задач было выявлено, что в ряде задач без выполнения третьего шага невозможно корректное выполнение второго шага. Таким образом, при решении одного и того же примера двумя способами второй и третий шаги проекта были взаимно переставлены. Также добавлен шаг "классификация объектов" (составление словаря).

Первый способ решения задачи — использование множественного наследования.

Постановка задачи примера. Вывести на экран фигуру, показанную на рис. 8.4.

Рис. 8.4. Изображение выводимой фигуры

Изображенная на рис. 8.4 фигура состоит из правильного пятиугольника и описанной вокруг него окружности, где хс, yc — координаты центра описанной вокруг пятиугольника окружности; R — радиус описанной вокруг пятиугольника окружности.

Кроме того, фигура рисуется заданным цветом.

Следует отметить, что задача может быть решена несколькими способами.

Шаг 1а. Определение объектов и выявление их свойств.

Объект — Рисунок. Свойства объекта:

— радиус окружности (R);

— координаты центра окружности (xc; yc);

— цвет линий.

Объект — Пятиугольник. Свойства объекта:

— радиус описанной вокруг него окружности (R);

— координаты центра описанной вокруг него окружности (хс; yc):

— цвет линии.

Объект — Окружность. Свойства объекта:

— радиус (R);

— координаты центра (хс; yc);

— цвет линии.

Решение задачи примера с использованием множественного наследования.

Шаг 1б. Классификация объектов (составление словаря).

Пятиугольник — центрально-симметричная фигура с пятью вершинами.

Окружность — центрально-симметричная фигура, каждая точка которой отстоит от заданной точки — центра, на заданную величину — радиус окружности.

Полученный граф наследования классов изображен на рис. 8.5.

Шаг 2. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.

Рис. 8.5. Граф наследования классов согласно первому способу

Поскольку Пятиугольник и Окружность — это разновидности центрально-симметричных фигур, то им может соответствовать следующая иерархия классов. Базовый класс: Центрально-симметричная фигура с данными R, хс, yc. Классы Пятиугольник и Окружность являются наследниками этого класса, а класс Рисунок является наследником классов Окружность и Пятиугольник, поскольку в данной задаче рисунок является сочетанием пятиугольника и окружности.

Шаг 3. Уточнение классов с определением наборов операций для каждого. Здесь анализируется потребность в конструкторах, деструкторах и операциях копирования. При этом принимается во внимание минимальность, полнота и удобство.

Класс Рисунок. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Рисунок должны присутствовать конструкторы и функция — член рисования рисунка. Тогда получаем:

• конструктор без параметров;

• конструктор с параметрами (Радиус, х-координата, y-координата, Цвет);

• функцию-член вывода рисунка — "Начертить".

Класс Пятиугольник. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Пятиугольник должны присутствовать конструкторы и функция-член рисования пятиугольника. Тогда получаем:

• конструктор без параметров;

• конструктор с параметрами (Радиус, х-координата, y-координата);

• функцию-член вывода пятиугольника на экран — "Начертить".

Класс Окружность. Экземпляр этого класса должен создаваться и рисоваться, а следовательно, в интерфейсе класса Окружность должны присутствовать конструкторы и функция-член вывода окружности на экран. Тогда получаем:

• конструктор без параметров;

• конструктор с параметрами (Радиус, х-координата, у-координата);

• функцию-член вывода окружности на экран — "Начертить".

Класс Центрально-симметричная фигура. Экземпляр данного класса должен содержать информацию о центрально-симметричной фигуре в виде данных с защищенным доступом (не интерфейсная часть класса) и иметь чисто-виртуальную функцию перерисовки вместе с конструкторами. Тогда получаем:

• конструктор без параметров;

• конструктор с параметрами (Радиус, х-координата, y-координата);

• чисто-виртуальную функцию-член вывода изображения на экран.

Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные методы. Определяются типы операций над классами.

Данные, расположенные в классе Центрально-симметричная фигура (R, хс, yc), должны быть доступны классам-наследникам Пятиугольник и Окружность, но недоступны "извне", значит, уровень доступа — "защищенный". В классе Центрально-симметричная фигура нужно расположить функцию "Нарисовать", которую предполагается сделать чисто-виртуальной. Классы, наследующие у класса Центрально-симметричная фигура, смогут переопределить функцию "Нарисовать" для рисования самих себя.

Поскольку обоим объектам — экземплярам классов Пятиугольник и Окружность нужен только один центр на двоих, то, следовательно, экземпляр класса Центрально-симметричная фигура должен создаваться только один, а значит, при описании наследования в языке C++ нужно добавить зарезервированное слово virtual. Наследование классами Пятиугольник и Окружность признаков у класса Центрально-симметричная фигура должно происходить с открытым уровнем доступа, иначе при создании класса Рисунок мы не сможем запустить конструктор класса верхнего уровня. Наследование классом Рисунок признаков классов Пятиугольник и Окружность должно происходить закрыто, чтобы к методам этих классов нельзя было обратиться через объект класса Рисунок. К наследуемым признакам добавляется свойство "Цвет линии", значение которого будет храниться в классе Рисунок. В классе Рисунок, так же как и в классах Пятиугольник и Окружность, можно переопределить метод "Нарисовать". Этот метод выводит изображения на экран, в нем как раз и будет устанавливаться цвет линий, при котором будут рисоваться фигуры.

Второй способ решения задачи с использованием агрегирования. Поскольку шаги 1а и 1б выполняются полностью аналогично предшествующему способу решения, начинаем с шага 2.

Шаг 2. Уточнение классов с точным определением их зависимостей от других классов. Выясняется наследование и использование зависимостей.

Объект рисунок состоит из объектов пятиугольник и окружность, форма и размер которых определяются настройками, задаваемыми при создании объекта рисунок, т. е. можно создать два независимых класса Пятиугольник (правильный) и Окружность, а затем экземпляры этих классов агрегировать в объект рисунок — экземпляр класса Рисунок.

Шаг 3. Уточнение классов с определением наборов операций для каждого. Здесь анализируется потребность в конструкторах, деструкторах и операциях копирования. При этом принимается во внимание минимальность, полнота и удобство.

Класс Рисунок. Объект этого класса должен уметь создать, уничтожить и нарисовать себя, поэтому интерфейсная часть класса будет следующей:

• конструктор без параметров;

• конструктор с параметрами (Радиус, x-координата, y-координата, Цвет);

• метод вывода рисунка на экран;

• деструктор для уничтожения создаваемых включенных объектов.

Примечание. Включение объектов типов Пятиугольник и Окружность происходит в закрытой, не интерфейсной части класса.

Класс Пятиугольник. Объект класса Пятиугольник должен уметь создать и рисовать себя, поэтому интерфейсная часть класса будет выглядеть следующим образом:

• конструктор без параметров;

• конструктор с параметрами (Радиус, x-координата, y-координата);

• метод вывода пятиугольника на экран.

Класс Окружность. Объект класса Окружность должен создавать и рисовать сам себя, поэтому интерфейсная часть класса будет выглядеть следующим образом:

• конструктор без параметров;

• конструктор с параметрами (Радиус, x-координата, y-координата);

• метод вывода окружности на экран.

Шаг 4. Задание интерфейсов классов. Более точно определяются отношения классов. Методы разделяются на общие и защищенные. Определяются типы операций над классами.

Классы Окружность и Пятиугольник должны содержать внутри себя переменные R, xc, yc, которые должны быть закрыты для доступа; функцию-член вывода фигуры на экран для доступа — открытую (как и конструкторы).

Для класса Рисунок включаемые экземпляры классов Пятиугольник и Окружность являются полями, поэтому их нужно скрыть, чтобы командовать этими объектами мог только экземпляр класса Рисунок. Функцию вывода рисунка на экран, как и конструкторы, нужно сделать открытыми.

Анализ результатов шагов 2 и 3 показывает, что проектная процедура допускает предварительное выполнение определения набора операций до определения зависимостей класса от других классов с последующим уточнением наборов операций классов.

8.9. ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ОБЯЗАННОСТЕЙ

8.9.1. RDD-технология проектирования на основе обязанностей

Далее будет изложена технология проектирования на основе обязанностей (или RDD-проектирование — Responsibility-Driven-Design), предложенная Т. Бадтом. Технология ориентирована на малые и средние проекты. Она основана на поведении систем. Данная технология по способу мышления аналогична разработке структуры служб какой-то организации: директора, заместителей директора, служб и подразделений.

Чтобы выявить отдельные объекты и определить их обязанности, команда программистов прорабатывает сценарий системы, т. е. мысленно воспроизводится запуск приложения как если бы оно уже было готово. Любое действие, которое может произойти, приписывается некоторому объекту в качестве его обязанности.

В качестве составной части этого процесса полезно изображать объекты с помощью CRC-карточек. Название CRC-карточки образовано от слов: Component, Responsibility, Collaborator — компонента (объект), обязанности, сотрудники. По мере того как для объектов выявляются обязанности, они записываются на лицевой стороне CRC-карточки (рис. 8.6).

Рис. 8.6. Образец CRC-карточки

При проработке сценария полезно разделить CRC-карточки между различными членами проектной группы. Человек, имеющий карточку, которая представляет собой определенный объект, записывает его обязанности и исполняет функции заменителя программной системы, передавая "управление" следующему члену команды, когда программная система нуждается в услугах других объектов.

Преимущества CRC-карточек в том, что они недорогие и с них можно стирать информацию. Это стимулирует экспериментирование, поскольку альтернативные проекты могут быть испробованы, изучены и отброшены с минимальными затратами. Физическое разделение карточек стимулирует интуитивное понимание важности логического разделения классов объектов. Небольшой размер карточки служит хорошей оценкой примерной сложности отдельного класса объекта. Объект, которому приписывается больше задач, чем может поместиться на его карточке, вероятно, является излишне сложным. Может быть, следует пересмотреть разделение обязанностей или разбить объект на два.

8.9.2. Начинаем с анализа функционирования. Учебный пример объектно-ориентированного проекта средней сложности

Из-за чего процесс проектирования начинают с анализа функционирования или поведения системы? Простой ответ состоит в том, что поведение системы обычно известно задолго до остальных ее свойств.

Поведение — это нечто, что может быть описано в момент возникновения идеи программы и (в отличие от формальной спецификации системы) выражено в терминах, понятных как для программиста, так и для клиента.

Представим себе, что вы являетесь главным архитектором программных систем в ведущей компьютерной фирме. Однажды появляется ваш начальник с идеей, которая, как он надеется, будет очередным успехом компании. Вам поручают разработать систему под названием "Интерактивный разумный кухонный помощник" (РКП).

Задача, поставленная перед вашей командой программистов, сформулирована в нескольких скупых словах. Программа "разумный кухонный помощник" (РКП) предназначена для домашних персональных компьютеров. Ее цель — заменить собой набор карточек с рецептами, который можно встретить почти в каждой кухне.

Анализ аналогов выявил, что уже известен ряд программных реализаций электронных поваренных книг с рецептами блюд. В данной области применения новой была бы программа, позволяющая планировать питание на заданный период. План питания на заданный период состоит из ежедневных планов питания с трех- или четырехразовым приемом пищи. Что надо учесть при разработке ежедневных планов питания? Число человек, калорийность питания каждого человека, любимые и нелюбимые блюда, затраты на питание. Ранние, описанные в литературе попытки оптимизации питания с учетом только продуктов, их калорийности и цен привели к решениям вида: оптимальный завтрак — 12 чашек уксуса. Генерация меню обеда с использованием датчика случайных чисел может привести к решениям с несовместимыми блюдами: молочный суп, сельдь с гороховым гарниром, квас. Решение проблемы — использование набора комплексных завтраков, обедов и ужинов. Есть ли в литературе достаточное описание возможных комплексов? Необходимо ли привлечь специалистов по питанию для разработки требуемого количества комплексов? Сколько будет стоить база данных комплексов? Следует ли реализовать функцию автоматической передачи заказа на продукты в магазин? На эти и другие вопросы необходимо дать ответ, чтобы уложиться в отпущенные средства и сроки.

Как это обычно бывает при первоначальном описании многих программных систем, первичные спецификации весьма двусмысленны.

Команда разработчиков решает, что когда система начинает работу, пользователь видит привлекательное информационное окно. Ответственность за его отображение приписывается объекту Greeter. CRC-карточка Greeter представлена на рис. 8.6. Некоторым, пока еще неопределенным образом (с помощью кнопок, всплывающего меню и т. д.) пользователь выбирает одно из следующих восьми действий.

1. Просмотреть базу данных с рецептами, но без ссылок на какой-то план питания.

2. Добавить новый рецепт в базу данных.

3. Редактировать или добавить комментарий к существующему рецепту.

4. Просмотреть базу данных комплексов.

5. Добавить новый комплекс в базу данных.

6. Редактировать или добавить комментарий к существующему комплексу.

7. Создать новый план питания.

8. Пересмотреть существующий план в отношении некоторых дат, блюд и продуктов.

Более детальное описание функций программы представлено на рис. 8.7.

Рис. 8.7. Детальное описание функций программы

Программа должна обеспечивать ведение базы данных (добавление, удаление и другие действия с отдельным рецептом или набором рецептов). Это, в общем-то, стандартные функции СУБД. Что касается функции планирования, то подразумевается, что программа по запросу пользователя будет составлять план питания на определенный период времени (неделю, месяц, год) для всей семьи или отдельных ее членов, исходя из заданных ограничений (например, ограничение на калорийность). После создания плана пользователю будет предоставлены следующие возможности:

— просмотр плана питания на каждый день из заданного периода действия плана, причем пользователь сможет не только просматривать предлагаемые наборы блюд на обед, ужин и т. д., но и редактировать рецепты их приготовления, выбирать рецепт блюда из предложенного программой списка или добавлять свой из базы данных рецептов;

— получение списка продуктов, которые необходимо закупить на расчетный период;

— осуществление распечатки данного плана питания или списка требуемых продуктов;

— создание нового плана на данный период, но с другим ограничением (например, ограничение на продукты питания — церковный пост) или создание нового плана с тем же ограничением, но на другой период.

Важной задачей является уточнение спецификации. В исходных спецификациях наиболее понятны лишь общие положения. Вероятно то, что спецификации для конечного продукта будут изменяться во время разработки программной системы. Далее действия, осуществляемые программной системой, приписываются объектам.

Первые три действия связаны с базой данных рецептов; следующие три действия связаны с базой данных комплексов, последние два — с планированием питания. В результате команда принимает следующее решение: создать объекты, соответствующие этим двум обязанностям.

Таким образом, может быть сформулирована постановка задачи: разработать и реализовать систему по ведению базы данных рецептов с возможностью планирования питания членов семьи. Система должна содержать:

• стандартные средства по ведению базы данных рецептов (просмотр, добавление, редактирование, удаление записей рецептов);

• стандартные средства по ведению базы данных комплексов (просмотр, добавление, редактирование, удаление записей комплексов);

• средства разработки плана питания (создание, корректировка) на определенный период (неделя, месяц, год), исходя из заданных групповых и индивидуальных ограничений (на калорийность, содержание определенных компонентов) для каждого члена семьи;

• возможность вывода информации по приготовляемым блюдам в соответствии с планом питания (на экран, принтер) на весь расчетный период или на требуемый день;

• возможность вывода информации о составе продуктов (на экран, на принтер) как за весь период, так и по датам закупок, исходя из сроков хранения.

Создание сложной физической системы, подобной зданию или автомобилю, упрощается с помощью разбиения проекта на структурные единицы. Точно так же разработка программного обеспечения облегчается после выделения отдельных объектов программы. Объект — это просто абстрактная единица, которая может выполнять определенную работу (т. е. иметь определенные обязанности). На этом этапе нет необходимости знать в точности то, как задается объект или как он будет выполнять свою работу. Объект может в конечном итоге быть преобразован в отдельную функцию, структуру или же совокупность других объектов. На этом уровне разработки имеются две важные особенности: объект должен иметь небольшой набор четко определенных обязанностей; объект должен взаимодействовать с другими объектами настолько слабо, насколько это возможно.

Отложенные действия. В конце концов придется решать, как пользователь станет просматривать базу данных. Например, должен ли он сначала входить в список таких категорий, как "супы", "салаты", "горячие блюда", "десерты"? С другой стороны, может ли пользователь задавать ключевые слова поиска ингредиентов, например "клубника", "сыр". Следует применять полосы прокрутки или закладки в виртуальной книжке?

Размышлять об этих предметах доставляет удовольствие, но важно то, что нет необходимости принимать конкретные решения на данном этапе проектирования. Поскольку они влияют только на отдельный объект и не затрагивают функционирования остальных частей системы, то все, что надо для продолжения работы над сценарием, — это информация о том, что пользователь должен выбрать комплекс с конкретными рецептами.

Что такое план питания? План питания это список объектов DateList — дат. Дата это объект Date с включенными кулинарными рецептами, с соблюдением правил комплексов завтраков, обедов и ужинов.

Каждый кулинарный рецепт будет идентифицироваться с конкретным объектом. Если рецепт выбран пользователем, управление передается объекту, ассоциированному с рецептом. Рецепт должен содержать определенную информацию, которая в основном состоит из списка ингредиентов и действий, необходимых для трансформирования составляющих в конечный продукт. Согласно нашему сценарию объект-рецепт должен выполнять и другие действия. Например, он будет отображать рецепт на экране. Пользователь получит возможность снабжать рецепт аннотацией, менять список ингредиентов или набор инструкций, а также может потребовать распечатать рецепт на принтере. Все эти действия являются обязанностью объекта Recipe. На этапе проектирования мы можем рассматривать Recipe как прототип многочисленных объектов-рецептов.

Определив вчерне, как осуществить просмотр базы данных, вернемся к ее блоку управления и предположим, что пользователь хочет добавить новый рецепт. В блоке управления базой данных некоторым образом определяется, в какой раздел поместить новый рецепт (в настоящее время нас не интересуют детали), запрашивается имя рецепта и выводится окно для набора текста. Таким образом, эту задачу естественно отнести к такому объекту, который отвечает за редактирование рецептов.

Вернемся к блоку Greeter (см. рис. 8.6). Планирование меню, как вы помните, было поручено объекту PlanManager. Пользователь должен иметь возможность сохранить существующий план. Следовательно, объект PlanManager может запускаться либо в результате открытия уже существующего плана питания, либо при создании нового. В последнем случае пользователя необходимо попросить ввести интервалы времени (список дат) для нового плана. Каждая дата ассоциируется с отдельным объектом типа Date. Пользователь может выбрать конкретную дату для детального исследования. В этом случае управление передается соответствующему объекту Date. Объект PlanManager должен уметь распечатывать меню питания на планируемый период. Наконец, пользователь может попросить объект PlanManager сгенерировать список продуктов на указанный период.

В объекте Date хранятся следующие данные: список блюд на соответствующий день и (необязательно) текстовые комментарии, добавленные пользователем (например, юбилейные даты). Объект должен выводить на экран вышеперечисленные данные. Кроме того, в нем должна быть предусмотрена функция печати. В случае желания пользователя более детально ознакомиться с тем или иным блюдом следует передать управление объекту Meal.

В объекте Meal хранится информация о блюде. Не исключено, что у пользователя окажется несколько рецептов одного блюда. Поэтому необходимо удалять и добавлять рецепты. Кроме того, желательно иметь возможность распечатать информацию о том или ином блюде. Разумеется, должен быть обеспечен вывод информации на экран. Пользователю, вероятнее всего, захочется обратиться еще к каким-нибудь рецептам. Следовательно, необходимо наладить контакт с базой данных рецептов, а значит, объекты Meal и база данных должны взаимодействовать между собой.

Рис. 8.8. Схема статических связей между объектами программы РКП

Далее команда разработчиков продолжает исследовать все возможные сценарии. Необходимо предусмотреть обработку исключительных ситуаций. Например, что происходит, если пользователь задает ключевое слово для поиска рецепта, а подходящий рецепт не найден? Как пользователь сможет прервать действие (например, ввод нового рецепта), если он не хочет продолжать дальше? Все это должно быть изучено. Ответственность за разработку подобных ситуаций следует распределить между объектами.

Изучив различные сценарии, команда разработчиков в конце решает, что все действия надлежащим образом могут быть распределены между семью объектами (рис. 8.8). Объект Greeter взаимодействует только с PlanManager и Recipe Database. Объект PlanManager "зацепляется" только с DateList, DateList с Date, a Date, в свою очередь, — с Meal. Объект Meal обращается к RecipeManager и через посредство этого объекта к конкретным рецептам (см. рис. 8.8).

Отдельные слова имеют слишком много интерпретаций. Поэтому необходимо в самом начале проектирования подготовить словарь, содержащий четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте. Без такого словаря обсуждение проекта с коллегами по разработке и заказчиками системы не имеет смысла, так как каждый может по-своему интерпретировать обсуждаемые термины.

8.9.3. Динамическая модель системы

Объектная модель представляет статическую структуру проектируемой системы (подсистемы). Однако знания статической структуры недостаточно, чтобы понять и оценить работу подсистемы. Схема, изображенная на рис. 8.8, не годится для описания динамического взаимодействия во время выполнения программы.

Динамическая модель подсистемы строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена.

Динамическая модель системы представляется диаграммой последовательности и диаграммой состояний объектов.

На рис. 8.9 показана часть диаграммы последовательности для РКП. Время изменяется сверху вниз. Каждый объект представлен вертикальной линией. Сообщение от одного объекта к другому изображается горизонтальной стрелкой между вертикальными линиями. Возврат управления (и, возможно, результата) в объект представлен стрелкой в обратном направлении. Некоторые авторы используют для этих целей пунктирную стрелку. Комментарий справа от рисунка более подробно объясняет взаимодействие.

Благодаря наличию оси времени диаграмма последовательности лучше описывает последовательность событий в процессе работы программы. Поэтому диаграммы последовательности являются полезным средством документирования для сложных программных систем.

Состояние определяется совокупностью текущих значений атрибутов. Например, банк может иметь состояния — платежеспособный и неплатежеспособный (когда большая часть банков одновременно оказывается во втором состоянии, наступает банковский кризис). Состояние определяет реакцию объекта на поступающее в него событие (в том, что реакция различна, нетрудно убедиться с помощью банковской карточки: в зависимости от состояния банка обслуживание или реакция банка на предъявление карточки будет разным). Реакция объекта на событие может включать некоторое действие и/или перевод объекта в новое состояние.

При определении состояний мы не рассматриваем те атрибуты, которые не влияют на поведение объекта, и объединяем в одно состояние все комбинации значений атрибутов и связей, которые дают одинаковые реакции на события.

Рис. 8.9. Пример диаграммы последовательности

Рис. 8.10. Пример диаграммы состояний

Диаграмма состояний связывает события и состояния. При приеме события следующее состояние системы зависит как от ее текущего состояния, так и от события (рис. 8.10). Смена состояния называется переходом. Диаграмма состояний — это граф, узлы которого представляют состояния, а направленные дуги, помеченные именами соответствующих событий, — переходы. Диаграмма состояний позволяет получить последовательность состояний по заданной последовательности событий.

Являясь описанием поведения объекта, диаграмма состояний должна описывать, что делает объект в ответ на переход в некоторое состояние или на возникновение некоторого события. Для этого в диаграмму состояний включаются описания активностей и действий.

Активностью называется операция, связанная с каким-либо состоянием объекта (она выполняется, когда объект попадает в указанное состояние); выполнение активности требует определенного времени. Примеры активностей: выдача картинки на экран телевизора, телефонный звонок, считывание порции файла в буфер и т. п.; иногда активностью бывает просто приостановка выполнения программы (пауза), чтобы обеспечить необходимое время пребывания в соответствующем состоянии (это бывает особенно важно для параллельной асинхронной программы).

8.9.4. Уточнение классов с точным определением их зависимостей от других классов. Продолжение учебного примера

Продолжим разработку программы РКП. На следующих этапах уточняется описание объектов. Сначала формализуются способы взаимодействия.

Следует определить, как будет реализован каждый из объектов. Объект, характеризуемый только поведением (не имеющий внутреннего состояния — внутренних данных), может быть оформлен в виде функции. Например, объект, заменяющий в строке все прописные буквы на строчные, лучше представить в виде функции. Объекты со многими функциями лучше реализовать в виде классов. Каждой обязанности, перечисленной на CRC-карточке, присваивается имя. Эти имена станут затем названиями функций или процедур. Вместе с именами определяются типы аргументов, передаваемых функциям и процедурам. Затем описывается вся информация, содержащаяся внутри класса объекта. Если объекту требуются некоторые данные для выполнения конкретного задания, их источник (аргумент функции, глобальная или внутренняя переменная) должен быть описан явно.

Как только для всех действий выбраны имена, CRC-карточка для каждого объекта переписывается заново с указанием имен функций и списка формальных параметров (рис. 8.11). Теперь CRC-карточка в себе отражает всю информацию для записи описания класса, порождающего объект, отображенный на этой карточке.

Идея классификации классов объектов программы через их поведение имеет чрезвычайное следствие. Программист знает, как использовать объект, разработанный другим программистом, и при этом ему нет необходимости знать, как он реализован. Пусть классы шести объектов РКП разрабатываются шестью программистами. Программист, разрабатывающий класс объекта Meal, должен обеспечить просмотр базы данных с рецептами и выбор отдельного рецепта при составлении блюда. Для этого объекта Meal просто вызывает функцию browse, привязанную к объекту RecipeDatebase. Функция browse возвращает отдельный рецепт Recipe из базы данных. Все это справедливо вне зависимости от того, как конкретно реализован внутри Recipe Database просмотр базы данных.

Рис. 8.11. Уточненная CRC-карточка

Вероятно, в реальном приложении будет много рецептов. Однако все они будут вести себя одинаково. Отличается лишь состояние: список ингредиентов и инструкций по приготовлению. На ранних стадиях разработки нас должно интересовать поведение, общее для всех рецептов. Детали, специфические для отдельного рецепта, не важны. Заметим, что поведение ассоциировано с классом, а не с индивидуальным представителем, т. е. все экземпляры класса воспринимают одни и те же команды и выполняют их сходным образом. С другой стороны, состояние является индивидуальным, и это видно на примере различных экземпляров класса Recipe. Все они могут выполнять одни и те же действия (редактирование, вывод на экран, печать), но используют различные данные.

Двумя важными понятиями при разработке программ является зацепление (cohesion) и связанность (coupling). Связанность — это мера того, насколько отдельный объект образует логически законченную, осмысленную единицу. Высокая связанность достигается объединением в одном объекте соотносящихся (в том или ином смысле) друг с другом функций. Наиболее часто функции оказываются связанными друг с другом при необходимости иметь доступ к общим данным. Именно это объединяет различные части объекта Recipe.

В частности, зацепление возникает, если один объект должен иметь доступ к данным (состоянию) другого объекта. Следует избегать подобных ситуаций. Возложите обязанность осуществлять доступ к данным на объект, который ими владеет. Например, за редактирование рецептов ответственность должна лежать на объекте RecipeDatabase, поскольку именно в нем впервые в этом возникает необходимость. Но тогда объект RecipeDatabase должен напрямую манипулировать состоянием отдельных рецептов (их внутренними данными: списком ингредиентов и инструкциями по приготовлению). Лучше избежать столь тесного сцепления, передав обязанность редактирования непосредственно рецепту.

С другой стороны, зацепление характеризует взаимосвязь между объектами программы. В общем случае желательно, как только можно, уменьшить степень зацепления, поскольку связи между объектами программы препятствуют их модификации и мешают дальнейшей разработке или повторному использованию в других программах.

8.9.5. Совместное рассмотрение трех моделей

В результате анализа получаем три модели: объектную, динамическую и функциональную. При этом объектная модель составляет базу, вокруг которой осуществляется дальнейшая разработка. При построении объектной модели в ней не всегда указываются операции над объектами, так как с точки зрения объектной модели объекты — это прежде всего структуры данных. Поэтому разработка системы начинается с сопоставления действиям и активностям динамической модели и процессам функциональной модели операций и внесения этих операций в объектную модель. С этого начинается процесс разработки программы, реализующей поведение, которое описывается моделями, построенными в результате анализа требований к системе.

Поведение объекта задается его диаграммой состояния; каждому переходу на этой диаграмме соответствует применение к объекту одной из его операций; можно каждому событию, полученному объектом, сопоставить операцию над этим объектом, а каждому событию, посланному объектом, сопоставить операцию над объектом, которому событие было послано. Активности, запускаемой переходом на диаграмме состояний, может соответствовать еще одна (вложенная) диаграмма состояний.

Результатом этого этапа проектирования является уточненная объектная модель, содержащая все классы проектируемой программной системы, в которых специфицированы все операции над их объектами.

8.10. ПРИМЕР РЕТРОСПЕКТИВНОЙ РАЗРАБОТКИ ИЕРАРХИИ КЛАССОВ БИБЛИОТЕКИ ВИЗУАЛЬНЫХ КОМПОНЕНТ DELPHI И C++ BUILDER

Delphi и C++ Builder представляет собой визуальное средство разработки корпоративных информационных систем. В C++ Builder используется язык объектно-ориентированного программирования C++, а в Delphi — Object Pascal. Несмотря на это, обе среды используют одни и те же модули библиотеки визуальных компонент, написанных на Object Pascal.

Каждый тип органов управления системы описывается классом, а помещаемые на формы конкретные органы управления являются объектами соответствующих классов. Так, например, Button1, Button2…, ButtonN являются объектами класса TButton; Edit1, Edit2…, EditM — объектами класса TEdit и т. п. Когда пользователь создает форму в визуальной интегрированной среде, он, по сути (в отличие от других органов управления), создает новый класс, объектом которого будет форма, появляющаяся при выполнении приложения (например, класс — TForm1, объект класса — Form1).

С целью уяснения процессов разработки иерархии классов предпримем попытку ретроспективного анализа иерархии классов системы Delphi/C++ Builder.

В процессе анализа была расписана иерархия классов, избранных для примера органов управления, выделены некоторые обязанности, которые мог бы наложить на них разработчик, а затем на основе сравнения списков выделенных обязанностей предпринята попытка обосновать иерархию классов, принятую в средах Delphi/C++ Builder.

Следует отметить, что данный анализ проводится с чисто учебными целями, поэтому здесь не рассмотрены все органы управления, а также все обязанности, которые может наложить разработчик на тот или иной орган управления.

Рассмотрим органы управления, которые могут быть получены транспортировкой их при помощи мыши с палитры компонент Delphi/C++ Builder.

— TButton — обыкновенная кнопка;

— TRadioButton — радиокнопка (группа кнопок с зависимой фиксацией, обеспечивающей возможность выбора лишь одной кнопки из группы);

— TListBox — обычный список;

— TDBListBox — список для работы с таблицами данных;

— TDataSource — источник данных (является посредником между элементами DataAccess: Table, Query, — и органами управления базами данных DataControls: DBGrid, DBEdit и т. п.).

Попытаемся в общих чертах прокомментировать данную иерархию и обосновать ее на основе метода распределения обязанностей. Ниже приведен набор обязанностей для перечисленных компонентов.

Обязанности объектов класса TDataSource:

— контролировать доступ пользователя к элементам TDataSet;

— обеспечивать возможность определения, подключен ли TDataSource к некоторому элементу TDataSet;

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса TButton:

— обрабатывать сообщения WMLBUTTONDOWN и WMLBUTTONDBLCLK (нажатие и двойное нажатие левой кнопки мыши);

— программно эмулировать нажатие кнопки;

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BMCLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя);

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса TRadioButton:

— обрабатывать сообщения WMLBUTTONDOWN и WMLBUTTONDBLCLK (нажатие и двойное нажатие левой кнопки мыши);

— определять, какая выбрана кнопка из группы кнопок;

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BMCLICK. (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя);

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса TListBox:

— очищать список;

— обеспечивать возможность нахождения нескольких элементов из списка;

— определять номер элемента списка по координатам точки, принадлежащей объекту класса TListBox;

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BM_CLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя);

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса TDBListBox:

— обеспечивать связь с источником данных (TDataSource);

— очищать список;

— обеспечивать возможность вывода нескольких элементов из списка;

— определять номер элемента списка по координатам точки, принадлежащей объекту класса TDBListBox;

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BMCLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя);

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

При внимательном рассмотрении обязанностей, вменяемых объектам перечисленных классов, можно заметить, что некоторые из них совпадают, т. е. оказываются общими для объектов разных классов. Следует также отметить, что некоторые из обязанностей являются общими для объектов всех классов, а некоторые — лишь для ограниченного набора.

Логично было бы ввести дополнительные классы, объекты которых имели бы общие для рассмотренных классов обязанности. Тогда рассмотренные классы (TDataSource, TButton, TRadioButton, TListBox, TDBListBox) могли бы унаследовать функции, обеспечивающие выполнение этих обязанностей у введенных дополнительных классов (в объектно-ориентированном программировании имеется механизм, который так и называется — механизм наследования, — который делает доступными из дочерних классов свойства и методы, с учетом прав доступа, разумеется, из родительских (или базовых) классов).

Попытаемся выделить упомянутые классы и назначить им их обязанности:

Обязанности объектов класса Класс_1:

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса Класс_2:

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BM_CLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя).

Обязанность объектов класса Класс_3:

— обрабатывать сообщения WM_LBUTTONDOWN и WM_LBUTTONDBLCLK (нажатие и двойное нажатие левой кнопки мыши).

Обязанности объектов класса Класс_4:

— очищать список;

— обеспечивать возможность нахождения нескольких элементов из списка;

— определять номер элемента списка по координатам точки, принадлежащей объекту класса TDBListBox.

Теперь, исключив из множества обязанностей объектов рассматриваемых классов те, которые переданы дополнительным классам, перечислим оставшиеся обязанности:

Обязанности класса TDataSource:

— контролировать доступ пользователя к элементам TDataSet;

— обеспечивать возможность определения, подключен ли TDataSource к некоторому элементу TDataSet.

Итак, обязанности класса Tbutton — программно эмулировать нажатие кнопки; класса TradioButton — определять, какая из кнопок с зависимой фиксацией выбрана; классов TlistBox и TDBListВох — обеспечивать связь с источником данных (TDataSource).

В результате получена иерархия классов (рис. 8.12), которая обеспечивает исключение избыточности кода (функции, осуществляющие выполнение объектами разных классов одинаковых обязанностей, кодируются приблизительно, а иногда совершенно одинаково), повышает обозримость кода программы, а следовательно, потенциально сокращает время на ее отладку.

Теперь рассмотрим на рис. 8.13 фрагмент схемы иерархии классов для перечисленных элементов (до корневого суперкласса).

Сравнивая рисунки 8.12 и 8.13, можно заметить:

1. Класс_1 в нашей иерархии соответствует ветви TObject → TPersistent → TComponent;

2. Класс_2 — TControl —> TWinControl;

3. Класс_3 — TbuttonControl;

4. Класс_4 — TCustomListBox.

Если с двумя последними классами все понятно, то возникает вопрос: почему первые два класса нашей иерархии соответствуют не одному, а целым цепочкам классов C++ Builder? Дело в том, что в рассматриваемом примере описаны не все классы C++ Builder. Поэтому те из них, которые приводят к разветвлению двух первых цепочек, здесь просто не учтены. Например, элемент TImage, предназначенный для расположения на формах графических изображений, имеет следующую цепочку наследования классов: TObject → TPersistent → TComponent → TControl → TGraphicsControl, — т. е. цепочка TControl → TWinControl превращается в дерево, на котором классы TWinControl и TGraphicsControl оказываются на одном уровне. Данный фрагмент схемы иерархии классов изображен на рис. 8.14.

Рис. 8.12. Предварительная иерархия классов

Рис. 8.13. Иерархия некоторых классов C++ Builder

Рис. 8.14. Фрагмент схемы иерархии

8.11. АЛЬТЕРНАТИВНЫЙ ПРОЕКТ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА

При развитии программ постоянно возникает проблема увеличения функциональных возможностей одного объекта за счет функциональных возможностей другого. Актуальнейшая проблема программирования — написание гибких программ, приспособленных для модификации и развития.

Вначале надо ввести всего одно понятие, предложенное Александром Усовым: контейнер-менеджер, или просто контейнер. Следует отметить, что здесь не идет речь о контейнере C++. Итак, контейнер — это класс, который позволяет объединять (агрегировать) в себе самые разные классы объектов, в том числе и другие контейнеры. Одной из наиболее сложных задач проектирования является агрегация разнородных элементов в новое единое целое. Контейнер — один из механизмов решения проблемы гибкой агрегации.

Простейший контейнер — это список ссылок на объекты. Далее если воспользоваться механизмом сообщений, то… всех этих затруднений можно избежать! Ни строчки нового кода! Сообщения, приходящие контейнеру, проецируются на принадлежащие ему объекты. Но допустима и более сложная логика обработки запросов, перед тем как они попадут к объекту-обработчику.

Сообщения, которые может обрабатывать класс, образуют его интерфейс. При использовании таких контейнеров нет нужды объявлять поля класса private или protected либо еще как-нибудь, поскольку их вообще не должно быть видно (исходные тексты класса больше не надо поставлять вместе с его кодом). Для всех разработчиков, использующих данный класс, достаточно знать его типы и структуры сообщений, т. е. сообщения обеспечивают максимальную защиту полей объектов и при этом не требуют накладных расходов.

Сообщения позволяют увеличить виртуализацию кода, что положительно сказывается на снижении его объема. Сообщения в отличие от вызова процедуры проще перехватить, дабы выполнить над ними предварительную обработку, например фильтрацию или сортировку. Наконец, сообщения позволяют максимально увеличить производительность системы, что недостижимо при вызове процедур.

Контейнеры бывают двух типов: однородные (динамические) и разнородные (статические).

Однородный контейнер может включать произвольное множество объектов одного класса либо классов, производных от данного класса. Логика работы такого контейнера предельно проста, например распределять поступающие сообщения по всем включенным в него объектам. Поскольку включенные в него объекты принадлежат одному классу, то, следовательно, они имеют единый интерфейс, но тогда становится совершенно неважно, сколько объектов включено в контейнер в любой момент времени, т. е. это число произвольно. Логика работы такого контейнера с включенными в него объектами одинакова и не зависит от конкретного объекта. Типичный представитель такого контейнера — список (например, строк). При добавлении (удалении) новых объектов (строк) логика работы самого контейнера остается неизменной.

Напротив, контейнер разнородных элементов может состоять из объектов самых разных классов. Его можно представить как схему, где каждый элемент (объект) имеет свою смысловую (функциональную) нагрузку. События, поступающие на такой контейнер, не транслируются примитивно на все объекты, а распределяются между ними по заданной схеме. Для данного типа контейнера применимо понятие "конструирование".

Другим отличием контейнера от множественного наследования является то, что можно произвольно во время работы или проектирования включать новые или исключать старые объекты, например, для того чтобы обеспечить их перенос из одного контейнера в другой. При этом состояние объектов остается тем же самым, мы просто меняем ссылки у контейнеров. Можно динамически подгружать новые логические схемы работы контейнера или изменять старые, что для множественного наследования, наверное, недостижимо в принципе. Следовательно, контейнер может гибко реализовывать полиморфизм в наиболее общем смысле!

Отметим еще раз, что взаимосвязь между объектами осуществляется посредством сообщений. Но здесь сообщения — специальный класс. Именно этот класс несет ответственность за полиморфизм свойств, но никак не классы основной иерархии. В таком случае у нас есть возможность объявить некоторый класс-сообщение и создать набор полиморфных классов-наследников, которые будут обрабатываться объектами основной иерархии классов.

Удобство работы с сообщениями вовсе не означает, что можно менять (добавлять или модифицировать) набор свойств класса основной иерархии. Нет, свойства каждого класса задаются на этапе проектирования иерархии.

При использовании контейнеров ни в одном объекте не используются ни конструкторы, ни деструкторы. Это не случайно. В чем суть конструктора? Реально он должен выполнить два действия: проинициализировать указатель на таблицу виртуальных методов (VMT) и проинициализировать собственные данные.

Рассмотрим пример проекта с использованием контейнеров. Предположим, что перед вами стоит задача разработки графического интерфейса, аналогичного GUI Microsoft Windows. Аналогичный интерфейс создавали разработчики Delphi, и ранее мы ретроспективно выполняли данный проект.

У вас несколько разработчиков (проектировщиков и программистов), и задачу надо решить в максимально короткий срок. Здесь следует отметить следующий важный момент: вы не сразу пишете программу, а скорее создаете инструментарий ее решения.

Прежде всего вы определяете все многообразие элементов GUI: labels, shapes, edit fields, buttons, check radio buttons, list combo boxes, bitmap и т. д. Несложно заметить, что большинство элементов представляет собой простые комбинации из двух или более визуальных элементов: например строка и рамка. Интуитивно понятно, что визуальный элемент и элемент интерфейса — это не одно и то же. Главной функцией элемента интерфейса является получение информации от пользователя, в то время как визуальный элемент служит для ее (информации) отображения. Это важно.

Теперь раздробим нашу команду на четыре подкоманды.

Первая команда займется графикой, т. е. визуальными элементами. Им необходимо выстроить иерархию объектов — графических примитивов, начиная от точки и заканчивая фонтами, произвольными многоугольниками и т. п.

Вторая команда должна специфицировать иерархию элементов интерфейса.

Третья команда займется построением дерева сообщений, при помощи которого элементы интерфейса будут взаимодействовать не только между собой, но и с ядром операционной системы.

И наконец, функцией четвертой команды будет создание иерархии объектов ввода-вывода (клавиатура, мышь, дисплей и т. д.).

Задачи каждой из подкоманд в достаточной степени независимы друг от друга и могут выполняться параллельно. Это тоже важно.

Теперь перейдем к контейнерам, для чего вырежем небольшой фрагмент из работы ваших команд. Предположим, что первая группа специфицировала (отметьте, только специфицировала, но еще, возможно, не создала ни одного объекта) дерево визуальных элементов. Пусть где-то в этой иерархии найдется место, скажем, для прямоугольника и строки. Теперь вторая команда может создать свой элемент интерфейса — предположим, что это будет банальная кнопка. Что такое кнопка — прямоугольная рамка и строка. Поскольку мы предполагаем обойтись без множественного наследования, то разумно предположить, что это контейнер. Следовательно, иерархия элементов интерфейса должна включать в себя контейнеры для визуальных элементов. Контейнер распределяет входное воздействие по составляющим его элементам, следовательно, контейнер есть менеджер объектных запросов.

Как представить графы реакций, которые можно условно назвать кодом контейнера? Теперь для нас весьма важно добиться быстрой реакции на каждое событие. Проблема могла бы быть решена множественным наследованием. Но поступим иначе.

У нас была выделена специальная команда, которая должна была разработать механизм объектных сообщений. Дадим им слово. Когда мы им сказали, какого типа объекты будут использоваться в нашей системе, они разработали иерархию сообщений. Да, каждое сообщение является классом, но удивительно не только это, а и то, что сообщения, обрабатываемые каждым классом, компилируются вместе с кодом данного класса. Это в первом приближении можно представить как таблицу виртуальных методов, только раздробленную на кусочки. Таким образом, каждое сообщение несет в себе адрес функции, его обрабатывающей. Когда контейнер получает такое сообщение, он подставляет в него ссылку на принадлежащий экземпляр объекта данного класса и производит вызов. И все…

Что же теперь имеем? Предположим, что надоели прямоугольные кнопки и захотелось круглых, многоугольных или вообще произвольных кнопок. "Ну, уж нет", — сказал бы специалист по множественному наследованию. Но мы спросим: "Вам в runtime или специально настроить?" Действительно, любой наследник от плоской фигуры может быть подставлен в контейнер в любое время, включая время выполнения. И тут вы с удивлением замечаете, что можно считать проект готовым к употреблению, отладив его схемы взаимодействия всего на одном-двух реальных объектах и добавляя все остальное по мере необходимости.

Предложенная Александром Усовым агрегация есть один из механизмов реализации в рамках ООП, который удачно пересекается и дополняет механизмы наследования, инкапсуляции и полиморфизма.

Вероятно, для обеспечения динамики будет сделан следующий шаг — использовать теорию ролей. Теория ролей — это просто удобное человеческое название много раз здесь упомянутого разделения объявленного интерфейса и его реализации некоторым объектом (актером), который умеет эту роль исполнять.

8.12. ПРОЕКТ АСУ ПРЕДПРИЯТИЯ

Развивая идею использования контейнеров А. Усова, можно получить идею системы генерации все новых программ с используемыми "кубиками" — готовыми объектами, которые при формировании программы автоматически извлекаются объектно-ориентированной СУБД из базы данных объектов.

Создав систему программирования с использованием базы данных объектов и генератором схем свойств контейнеров, А. Усов разработал ядро типовой АСУ предприятия, позволяющее за короткие сроки и при малом количестве программистов генерировать АСУ все новых предприятий.

Информационное пространство любого предприятия состоит из двух частей — зависимой и независимой от профиля предприятия. Независимая часть базируется на общности свойств, которые присущи любому предприятию. Благодаря этому, во-первых, можно построить классификатор предприятий любого профиля так, как это принято в технологии объектно-ориентированного проектирования. Во-вторых, это позволяет объединять предприятия разного профиля в единую корпорацию. В-третьих, можно создавать абстрактные предприятия, требующие минимальной настройки на конкретный профиль. Наконец, благодаря наличию общих свойств у всех предприятий, внешние организации могут контролировать деятельность предприятия.

Каждое предприятие имеет, как правило, иерархическую структуру подразделений. Структурное подразделение (СП) включает в себя три информационных класса: служащие, оборудование и материалы. Здесь под оборудованием будут пониматься основные фонды предприятия или данного СП. Термином "материалы" обозначаются те сущности, которые потребляются в процессе производства. Базовые информационные классы — служащие, оборудование и материалы — могут иметь общий суперкласс (НЕЧТО, УЧАСТВУЮЩЕЕ В ПРОИЗВОДСТВЕ) или нет (дело вкуса).

Таким образом, создав необходимые информационные классы, сложив их в контейнер СП и представив набор этих контейнеров в виде иерархии владения, мы тем самым создаем абстрактное предприятие. Да, это предприятие ничего не производит, ибо производство является специфичным и определяет профиль предприятия. Но такой класс позволяет создавать подклассы предприятий будь то промышленные, муниципальные, транспортные, финансовые или другие. Каждый из этих классов предприятий может образовывать свое поддерево классов.

Есть еще ряд моментов, на которых остановимся. Существующие системы достаточно громоздки и тяжелы в настройке. Перед их установкой, как правило, проводятся исследования по организации бизнес-процессов. По результатам этих обследований выдаются рекомендации, целью которых является оптимизация основных процессов. Однако после внедрения систем переорганизация производства требует значительных усилий по настройке системы на новые условия. Обычно к этой работе привлекаются специальные фирмы, занимающиеся сопровождением АСУ. Но современные условия ведения бизнеса требуют высокой гибкости, которая пока остается недостижимой мечтой.

В предлагаемом решении каждое структурное подразделение выделено в самостоятельную сущность, это позволяет, во-первых, моделировать и просчитывать новые схемы управления производством, а во-вторых, дает возможность внедрять эти схемы "на ходу". Действительно, предприятие, как уже было сказано, представляет собой контейнер с наличием ряда свойств. Разложение этих свойств по СП есть генерация схем. Имея механизм версионности схем, можно строить модели, оптимизируя их по различным критериям и используя строгие математические методы.

Здесь же можно отметить, что современная теория управления предприятиями базируется на BPR (bussiness process re-engineering) и TQM (total quality managment). Одно из основных положений BPR говорит о необходимости переноса точки принятия тактических решений как можно ближе к исполнителям, т. е. СП должно быть в максимальной степени самостоятельным, самодостаточным и компетентным в принятии решений.

Опять же, приобретая возможность рассматривать каждое СП как самостоятельную часть предприятия, нам гораздо легче решить данную задачу. Не составляет труда оценить, во что обходится каждое СП и какую оно дает отдачу, насколько продумана внутренняя структура СП и его место в общей структуре производства. Так же как и на уровне производства, можно заниматься оптимизацией бизнес-процессов на уровне отдельного подразделения. Наконец, перенос точки принятия тактических решений внутрь СП позволяет если не упразднить совсем, то, по крайней мере, существенно облегчить работу многих отделов, функционирующих на уровне предприятия (отдел кадров, планирование закупок оборудования и проведения ремонтов и т. п.).

Функциональная часть предприятий различна и зависит от профиля предприятия. Поэтому возьмем за основу рассмотрения типичное (обобщенное) промышленное предприятие, производственный цикл которого можно представить следующей схемой, показанной на рис. 8.15.

Рис. 8.15. Производственный цикл промышленного предприятия

Каждая фаза производства дробится на более мелкие, например, стадия "Сырье" состоит в поиске поставщиков, заключении договоров, получении и оплате счетов, получении и складировании сырья и т. п. Деление происходит до получения элементарных операций, реализуемых в виде наборов сервисов.

Когда выполнено разложение исходной задачи на сервисы, можно приступить к комплектованию должностей. Должность определяется набором доступных и необходимых сервисов, т. е. должность представима контейнером сервисов. В свою очередь должности соединяются в структурные подразделения. Таким образом, произошло соединение функциональной и функционально-независимой частей. Мы сохранили возможность динамического изменения как отдельной должности, так и структурного подразделения, следовательно, нам доступно и динамическое перепрофилирование предприятия в целом.

Система поддерживает произвольное количество логических слоев (аналог — многоуровневые системы клиент — сервер). Слой хранения информации представлен средой хранения (СУБД), слой отображения — средой отображения, основанной на GUI (пользовательскими приложениями), слой бизнес правил — схемами и т. д.

Каждый сервис представляет собой группу классов (возможно, иерархий). Классы могут быть объединены в контейнеры, свойства которых реализуются в виде схем. Приложение, взаимодействуя с контейнерами явно или опосредованно, запускает те или иные схемы, реализуя тем самым собственную логику работы.

8.13. ОБЗОР ОСОБЕННОСТЕЙ ПРОЕКТОВ ПРИКЛАДНЫХ СИСТЕМ

Проектируя систему одного из перечисленных далее типов, имеет смысл обратиться к одному из соответствующих решений. Далее рассматриваются следующие типы систем:

— системы пакетной обработки — обработка данных производится один раз для каждого набора входных данных;

— системы непрерывной обработки — обработка данных производится непрерывно над сменяющимися входными данными;

— системы с интерактивным интерфейсом — системы, управляемые внешними воздействиями;

— системы динамического моделирования — системы, моделирующие поведение объектов внешнего мира;

— системы реального времени — системы, в которых преобладают строгие временные ограничения;

— системы управления транзакциями — системы, обеспечивающие сортировку и обновление данных; имеют коллективный доступ (типичной системой управления транзакциями является СУБД).

При разработке системы пакетной обработки необходимо выполнить следующие шаги:

— разбиваем полное преобразование на фазы, каждая из которых выполняет некоторую часть преобразования; система описывается диаграммой потока данных, которая строится при разработке функциональной модели;

— определяем классы промежуточных объектов между каждой парой последовательных фаз, при этом каждая фаза знает об объектах, расположенных на объектной диаграмме до и после нее (эти объекты представляют соответственно входные и выходные данные фазы);

— составляем объектную модель каждой фазы (она имеет такую же структуру, что и модель всей системы в целом: фаза разбивается на подфазы) и далее разрабатываем каждую подфазу.

При разработке системы непрерывной обработки необходимо выполнить следующие шаги:

— строим диаграмму потока данных (активные объекты в ее начале и конце соответствуют структурам данных, значения которых непрерывно изменяются, а хранилища данных, связанные с ее внутренними фазами, отражают параметры, которые влияют на зависимость между входными и выходными данными фазы);

— определяем классы промежуточных объектов между каждой парой последовательных фаз, при этом каждая фаза знает об объектах, расположенных на объектной диаграмме до и после нее (эти объекты представляют соответственно входные и выходные данные фазы);

— представляем каждую фазу как последовательность изменений значений элементов выходной структуры данных в зависимости от значений элементов входной структуры данных и значений, получаемых из хранилища данных (значение выходной структуры данных формируется по частям).

При разработке системы с интерактивным интерфейсом необходимо выполнить следующие шаги:

— выделяем объекты, формирующие интерфейс;

— если есть возможность, используем готовые объекты для организации взаимодействия (например, для организации взаимодействия системы с пользователем через экран дисплея можно использовать библиотеку системы X-Window, обеспечивающую работу с меню, формами, кнопками и т. п.);

— структуру программы определяем по ее динамической модели, а для реализации интерактивного интерфейса используем параллельное управление (многозадачный режим) или механизм со-

бытии (прерывания), а не процедурное управление, когда время между выводом очередного сообщения пользователю и его ответом система проводит в режиме ожидания;

— из множества событий выделяем физические (аппаратные, простые) события и стараемся при организации взаимодействия использовать в первую очередь их.

При разработке системы динамического моделирования необходимо выполнить следующие шаги:

— по объектной модели определяем активные объекты; эти объекты имеют атрибуты с периодически обновляемыми значениями;

— определяем дискретные события; такие события соответствуют дискретным взаимодействиям объекта (например, включение питания) и реализуются как операции объекта;

— определяем непрерывные зависимости (например, зависимости атрибутов от времени), при этом значения таких атрибутов должны периодически обновляться в соответствии с зависимостью;

— моделирование управляется объектами, отслеживающими временные циклы последовательностей событий.

Разработка системы реального времени аналогична разработке системы с интерактивным интерфейсом.

При разработке системы управления транзакциями необходимо выполнить следующие шаги:

— отобразить объектную модель на базу данных;

— определить асинхронно работающие устройства и ресурсы с асинхронным доступом; в случае необходимости определить новые классы;

— определить набор ресурсов (в том числе структур данных), к которым необходим доступ во время транзакции (участники транзакции);

— разработать параллельное управление транзакциями; системе может понадобиться несколько раз повторить неудачную транзакцию, прежде чем выдать отказ.

8.14. ГИБРИДНЫЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

8.14.1. Игнорирование классов

Процедурно-ориентированный и объектно-ориентированный подходы к программированию различаются по своей сути и обычно ведут к совершенно разным решениям одной задачи. Этот вывод верен как для стадии реализации, так и для стадии проектирования: вы концентрируете внимание или на предпринимаемых действиях, или на представляемых сущностях, но не на том и другом одновременно.

Тогда почему метод объектно-ориентированного проектирования предпочтительнее метода функциональной декомпозиции? Главная причина в том, что функциональная декомпозиция не дает достаточной абстракции данных. А отсюда уже следует, что проект будет менее податливым к изменениям; менее приспособленным для использования различных вспомогательных средств; менее пригодным для параллельного развития; менее пригодным для параллельного выполнения.

Дело в том, что функциональная декомпозиция вынуждает объявлять "важные" данные глобальными, поскольку если система структурирована как дерево функций, всякое данное, доступное двум функциям, должно быть глобальным по отношению к ним. Это приводит к тому, что "важные" данные "всплывают" к вершине дерева по мере того, как все большее число функций требует доступа к ним.

В точности так же происходит в случае иерархии классов с одним корнем, когда "важные" данные всплывают по направлению к базовому классу (рис. 8.16).

Рис. 8.16. Игнорирование классов и их наследования

8.14.2. Игнорирование наследования

Рассмотрим второй вариант — проект, который игнорирует наследование. Считать наследование всего лишь деталью реализации — значит игнорировать иерархию классов, которая может непосредственно моделировать отношения между понятиями в области приложения. Такие отношения должны быть явно выражены в проекте, чтобы дать возможность разработчику продумать их.

Таким образом, политика "никакого наследования" приведет лишь к тому, что в системе будет отсутствовать целостная общая структура, а использование иерархии классов будет ограничено определенными подсистемами.

8.14.3. Игнорирование статического контроля типов

Рассмотрим третий вариант, относящийся к проекту, в котором игнорируется статический контроль типов. Распространенные доводы в пользу отказа на стадии проектирования от статического контроля типов сводятся к тому, что "типы — это продукт языков программирования" или что "более естественно рассуждать об объектах, не заботясь о типах", или "статический контроль типов вынуждает нас думать о реализации на слишком раннем этапе". Такой подход вполне допустим до тех пор, пока он работает и не приносит вреда.

Рассмотрим следующую аналогию: в физическом мире мы постоянно соединяем различные устройства, и существует кажущееся бесконечным число стандартов на соединения. Главная особенность этих соединений — они специально спроектированы таким образом, чтобы сделать невозможным соединение двух устройств, не рассчитанных на него, т. е. соединение должно быть сделано единственным правильным способом. Вы не можете подсоединить радиотрансляционный приемник к розетке с высоким напряжением. Если бы вы смогли сделать это, то сожгли бы приемник или сгорели сами.

Здесь практически прямая аналогия: статический контроль типов эквивалентен совместимости на уровне соединения, а динамические проверки соответствуют защите или адаптации в цепи. Результатом неудачного контроля как в физическом, так и в программном мире будет серьезный ущерб. В больших системах используются оба вида контроля (рис. 8.17).

На раннем этапе проектирования вполне достаточно простого утверждения:

Рис. 8.17. Игнорирование статического контроля типов

"Эти два устройства необходимо соединить", но скоро становится существенным, как именно следует их соединить: "Какие гарантии дает соединение относительно поведения устройств?" или "Возникновение каких ошибочных ситуаций возможно?", или "Какова приблизительная цена такого соединения?"

8.14.4. Гибридный проект

Переход на новые методы работы может быть мучителен для любой организации. Поскольку в объектно-ориентированных языках возможны несколько схем программирования, язык допускает постепенный переход на него, используя следующие преимущества такого перехода:

1) изучая объектно-ориентированное проектирование, программисты могут продолжать работать по технологии структурного программирования;

2) в окружении, бедном на программные средства, использование объектно-ориентированных языков может принести значительные выгоды.

Рис. 8.18. Гибридный проект

Идея постепенного, пошагового овладения объектно-ориентированными языками и технологий их применения, а также возможность смешения объектно-ориентированного кода с кодом структурного программирования естественно приводит к проекту, имеющему гибридный стиль. Большинство интерфейсов можно пока оставить на процедурном уровне, поскольку что-либо более сложное не принесет немедленного выигрыша (рис. 8.18).

ВЫВОДЫ

• Процедурно-ориентированный и объектно-ориентированный подходы к программированию различаются по своей сути и обычно ведут к совершенно разным решениям одной задачи.

• Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как:

— уменьшение сложности программного обеспечения;

— повышение надежности программного обеспечения;

— обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;

— обеспечение возможности повторного использования отдельных компонентов программного обеспечения.

• Методы объектно-ориентированного проектирования используют в качестве строительных блоков объекты.

• Принципы абстрагирования, инкапсуляции и модульности являются взаимодополняющими. Объект логически определяет границы определенной абстракции, а инкапсуляция и модульность делают их физически незыблемыми.

• Наследование выполняет в ООП несколько важных функций:

— моделирует концептуальную структуру предметной области;

— экономит описания, позволяя использовать их многократно для задания разных классов;

— обеспечивает пошаговое программирование больших систем путем многократной конкретизации классов.

• Классы из предметной (прикладной) области непосредственно отражают понятия, которые использует конечный пользователь для описаний своих задач и методов их решения.

• Идеальный класс должен в минимальной степени зависеть от остального мира. Каждый класс имеет набор поведений и характеристик, которые его определяют.

• При перестройке иерархии классов применяются четыре процедуры:

1) расщепление класса на два и более;

2) абстрагирование (обобщение);

3) слияние;

4) анализ возможности использования существующих разработок.

• Разработка проекта начинается с составления функциональной модели.

• Объектная модель представляет статическую структуру проектируемой системы (подсистемы).

• Динамическая модель системы представляется диаграммой последовательности и диаграммой состояний объектов.

Контрольные вопросы

1. При решении каких проблем лучше использовать объектно-ориентированный подход?

2. Какие характеристики являются фундаментальными в объектно-ориентированном мышлении?

3. На каких принципах базируется объектная модель?

4. Что такое паттерн проектирования?

5. Какому паттерну соответствует динамический и статический контейнер А. Усова?

6. Какие преимущества дает объектная модель?

7. В чем заключаются преимущества инкапсуляции?

8. В чем заключается важность наследования?

9. Для чего полезен полиморфизм?

10. Что такое агрегирование объекта?

11. Из каких этапов состоит процесс построения объектной модели?

12. Каким образом взаимодействуют между собой объекты в программе?

13. Какие процедуры применяются при перестройке схемы наследования классов?

14. Почему так важен анализ функционирования системы?

15. В чем заключается удобство использования CRC-карточек?

16. Какие диаграммы используют в проектах средней сложности?

Глава 9

ВИЗУАЛЬНОЕ ПРОГРАММИРОВАНИЕ

9.1. ОБЩЕЕ ПОНЯТИЕ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ

Визуальное программирование является в настоящее. время одной из наиболее популярных парадигм программирования. Визуальное программирование состоит в автоматизированной разработке программ с использованием особой диалоговой оболочки. Рассматривая системы визуального программирования, легко увидеть, что все они базируются на объектно-ориентированном программировании и являются его логическим продолжением. Наиболее часто визуальное программирование используется для создания интерфейса программ и систем управления базами данных.

С объектно-ориентированными системами ассоциируется программа Browser (рис. 9.1). Это средство вместе с системой экранных подсказок позволяет программисту по желанию просматривать некоторые части программного окружения и видеть весь проект уже созданной программы. Под проектом программы здесь понимается структура программы — состав файлов, объектов и их порождающих классов, которые слагают программу в целом.

Рис. 9.1. Browser в Delphi 5.0

Одну из ключевых возможностей программы Browser предоставляет окно, в котором находится список всех классов системы. При выборе одного из классов в специальных окнах отображаются его локальные функции и переменные. Затем при выборе одного из методов на отдельной панели высвечивается его код. Обычно в системе присутствуют средства для добавления и удаления классов из проекта. Программа Browser — это не просто визуализатор. Это основной, интегрирующий инструмент, который помогает одновременно рассматривать существующую систему и разрабатывать документацию программного проекта.

Структурной единицей визуального программирования в Delphi и C++Builder является компонента. Компонента представляет собой разновидность объекта, который можно перенести (агрегировать) в приложение из специальной Палитры компонент (рис. 9.2). Компонента имеет набор свойств, которые можно изменять, не изменяя исходный код программы.

Компоненты бывают визуальными и невизуальными. Первые предназначены для организации интерфейса с пользователем. Это различные кнопки, списки, статический и редактируемый текст, изображения и многое другое. Эти компоненты отображаются при выполнении разрабатываемого приложения. Невизуальные компоненты отвечают за доступ к системным ресурсам: драйверам баз данных, таймерам и т. д. Во время разработки они отображаются своей пиктограммой, но при выполнении приложения, как правило, невидимы. Компонента может принадлежать либо другой компоненте, либо форме.

Формой называется визуальная компонента, обладающая свойством окна Windows (рис. 9.3). При разработке на форме помещаются необходимые компоненты (например, элементы требуемого диалога). Форм в приложении может быть несколько — по требуемому числу открываемых при выполнении диалога окон, их можно добавлять и удалять.

Рис. 9.2. Палитра компонент Delphi 5.0

Рис. 9.3. Пустая форма

Программные средства разработки приложений, относящиеся к предыдущему поколению, предлагают интерактивные средства решения типовых задач (мастера в Borland C++ и Wizards или волшебники в Visual C++), которые позволяют в диалоге с программистом создавать и вставлять в программы готовые фрагменты исходного кода.

Технология создания приложений в среде Delphi вышла на новый уровень развития этих идей. В Delphi разработчик из меню палитры компонент выбирает необходимую компоненту, например кнопку, и буксирует ее при помощи мыши в нужное место окна разрабатываемой формы. При этом кнопке автоматически присваивается название (имя или идентификатор), и она описывается в модуле формы (рис. 9.4).

Щелкнув по изображению компоненты на форме, можно сделать ее активной. Затем, перемещая при помощи мыши границы кнопки и работая в окне Inspector, можно задать надпись (например, ОК) и/или графическую пиктограмму на кнопке, задать цвета и другие настроечные параметры кнопки. Двойной щелчок по кнопке — и в исходном тексте формы появится шаблон подпрограммы (метода) нужного типа реакции на щелчок (рис. 9.5). Работая в окне редактора текста, можно оформить тело подпрограммы реакции кнопки на щелчок.

Рис. 9.4. Форма с двумя компонентами — кнопками

Рис. 9.5. Оформление события (метода) нажатия кнопки в Delphi 5.0

Рис. 9.6. Object Inspector в Delphi 5.0

Программа Inspector позволяет входить в исходные тексты методов (подпрограммы обработки событий, названных Events), например, на нажатие Enter, а также задавать начальные значения полям данных, названных Properties (рис. 9.6).

9.2. ТЕХНОЛОГИЯ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ

Начальные шаги технологии визуального программирования определяются оболочкой самой среды визуального программирования. Сначала создаются экранные формы простейшей буксировкой мыши. В инспекторе объектов производится настройка их свойств путем заполнения отдельных полей. На главную форму помимо визуальных компонент наносятся невизуальные компоненты. Формы объединяются в единый проект. Далее в соответствии со сценарием диалога программируются методы события основной и подчиненных форм. Программы "пустых" методов событий появляются в окне редактора после нажатия соответствующих клавиш или действий мыши. "Пустые" методы дополняются определенными операторами активации и дезактивации форм. По окончании начальных шагов получается работающий "скелет" программы с источниками данных из файловых баз данных и со сгенерированными формами документов, выводимых на печать. Исследователь (Browser) обеспечивает визуализацию схемы иерархии классов полученного "скелета" программы. Другими словами, технический проект реализованной части программы формируется автоматически.

Дальнейшая разработка программы ведется по технологии объектно-ориентированного программирования. Можно часть программы реализовать по технологии структурного программирования. Некоторые недостающие визуальные и невизуальные компоненты получаются модификацией исходных текстов наиболее близких прототипов имеющихся компонент. Рекомендуется новые компоненты помещать в палитру компонент. Это облегчит их повторное использование в данной или последующих разработках. Код, относящийся только к данной разработке, набирается по тексту программы.

ВЫВОДЫ

• Визуальное программирование во многом автоматизирует труд программиста по написанию программ.

• Визуальное программирование — одна из самых популярных парадигм программирования на данный момент. Оно базируется на технологии ООП.

• Среда визуального программирования поддерживает работу браузеров (Browser), при помощи которых можно автоматически получить документацию по структуре программы.

• Основным элементом в средствах визуального программирования является компонент. Компоненты бывают визуальными и невизуальными.

• Технология визуального программирования состоит в следующем: создание экранных форм, нанесение визуальных и невизуальных компонент, программирование событий и методов оконных форм.

Контрольные вопросы

1. Назовите основные функции браузера.

2. Какие бывают компоненты?

3. Что такое палитра компонент?

4. Опишите функциональные возможности инспектора объектов.

5. Назовите основные шаги технологии визуального программирования.

Глава 10

CASE-СРЕДСТВА И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ

10.1. ПРЕДПОСЫЛКИ ПОЯВЛЕНИЯ CASE-СРЕДСТВ

Тенденции развития современных информационных технологий приводят к постоянному усложнению автоматизированных систем (АС). Для борьбы со сложностью проектов в настоящее время созданы системы автоматизированного проектирования (САПР) самих программных проектов.

Для успешной реализации проекта объект проектирования (АС) должен быть прежде всего адекватно описан, должны быть построены полные, а также непротиворечивые функциональные и информационные модели АС. Накопленный к настоящему времени опыт проектирования АС показывает, что это трудоемкая и длительная по времени работа.

Все это способствовало появлению программно-технологических средств особого назначения — CASE-средств, реализующих CASE-инженерию создания и сопровождения АС. Термин "CASE" (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных АС в целом.

Теперь под термином "CASE-средства" понимаются программные средства, поддерживающие процессы создания и сопровождения АС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки АС.

CASE-технология представляет собой методологию проектирования АС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения АС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

На основании анкетирования более тысячи американских фирм фирмой "Systems Development Inc." в 1996 г. был составлен обзор передовых технологий (Survey of Advanced Technology). Согласно этому обзору CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85 % завершились успешно). Однако несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения. В связи с этим необходимо отметить следующее:

— CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;

— реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

— CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

Для успешного внедрения CASE-средств организация должна обладать такими качествами, как:

• технология — понимание ограниченности существующих возможностей и способность принять новую технологию;

• культура — готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

• управление — четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

10.2. ОБЗОР CASE-СИСТЕМ

На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

• Vantage Team Builder (Westmount I–CASE);

• Designer/2000;

• Silverrun;

• ERwin+BPwin;

• S-Designor;

• CASE.Аналитик;

• Rational Rose.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы, так и новые версии и модификации перечисленных систем.

CASE-средство Silverrun американской фирмы "Computer Systems Advisers, Inc." (CSA) используется для анализа и проектирования АС бизнес-класса и ориентировано в большей степени на спиральную модель жизненного цикла. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между ДПД различных уровней декомпозиции).

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, SQL Server и др. Для передачи данных в средства разработки приложений имеются мосты к языкам: 4GL, JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели жизненного цикла (ЖЦ) ПО и поддержку полного жизненного цикла ПО.

Система обеспечивает выполнение следующих функций:

— проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

— проектирование диаграмм архитектуры системы SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

— генерацию кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

— программирование на языке С со встроенным сервером SQL;

— управление версиями и конфигурацией проекта;

— генерацию проектной документации по стандартным и индивидуальным шаблонам.

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

CASE-средство Designer/2000 2.0 фирмы "ORACLE" является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного жизненного цикла ПО для систем, использующих СУБД ORACLE.

Базовая методология Designer/2000 (CASE Method) — структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла AC. Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозитарий.

Среда функционирования Designer/2000 — Windows 3.x, Windows 95, Windows NT.

ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжениринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитарий данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.

BPwin — средство функционального моделирования, реализующее методологию IDEF0.

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжениринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитарии данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования. Его основные функции:

• анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;

• получение разнообразных отчетов по проекту;

• генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор-386 и выше, основная память 4 Мб, дисковая память 5 Мб, MS Windows 3.x или Windows 95.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитик, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

И наконец, Rational Rose — CASE-средство фирмы "Rational Software Corporation" (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует объединенную методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQL Windows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжениринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

10.3. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ В RATIONAL ROSE

Изучая требования к системе, вы берете за основу запросы пользователей и далее преобразуете их в такую форму, которую ваша команда сможет понять и реализовать. На основе этих требований вы генерируете код. Формально преобразуя требования в код, вы гарантируете их соответствие друг другу, а также возможность в любой момент вернуться от кода к породившим его требованиям. Этот процесс называется моделированием. Моделирование позволяет проследить путь от запросов пользователей к требованиям модели и затем к коду и обратно, не теряя при этом своих наработок.

Визуальным моделированием называют процесс графического представления модели с помощью некоторого стандартного набора графических элементов. Наличие стандарта жизненно необходимо для реализации одного из преимуществ визуального моделирования — коммуникации. Общение между пользователями, разработчиками, аналитиками, тестировщиками, менеджерами и всеми остальными участниками проекта является основной целью графического визуального моделирования.

Созданные модели представляются всем заинтересованным сторонам, которые могут извлечь из них ценную информацию. Например, глядя на модель, пользователи визуализируют свое взаимодействие с системой. Аналитики увидят взаимодействие между объектами модели. Разработчики поймут, какие объекты нужно создать и что эти объекты должны делать. Тестировщики визуализируют взаимодействие между объектами, что позволит им построить тесты. Менеджеры увидят как всю систему в целом, так и взаимодействие ее частей. Наконец, руководители информационной службы, глядя на высокоуровневые модели, поймут, как взаимодействуют друг с другом системы в их организации. Таким образом, визуальные модели предоставляют мощный инструмент, позволяющий показать разрабатываемую систему всем заинтересованным сторонам.

10.4. ДИАГРАММЫ UML

10.4.1. Типы визуальных диаграмм UML

UML позволяет создавать несколько типов визуальных диаграмм:

• диаграммы вариантов использования;

• диаграммы последовательности;

• кооперативные диаграммы;

• диаграммы классов;

• диаграммы состояний;

• диаграммы компонент;

• диаграммы размещения.

Диаграммы иллюстрируют различные аспекты системы. Например, кооперативная диаграмма показывает, как должны взаимодействовать объекты, чтобы реализовать некоторую функциональность системы. У каждой диаграммы есть своя цель.

10.4.2. Диаграммы вариантов использования

Диаграммы вариантов использования отображают взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему. Пример диаграммы вариантов использования для банковского автомата (ATM) показан на рис. 10.1.

Рис. 10.1. Диаграмма вариантов использования

На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица по отношению к создаваемой системе. Диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере клиент банка инициирует различные варианты использования: "Снять деньги со счета", "Перевести деньги", "Положить деньги на счет", "Показать баланс", "Изменить идентификационный номер", "Произвести оплату". Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо — она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.

Из диаграмм вариантов использования можно получить довольно много информации о системе. Этот тип диаграмм описывает общую функциональность системы. Пользователи, менеджеры проектов, аналитики, разработчики, специалисты по контролю качества и все, кого интересует система в целом, могут, изучая диаграммы вариантов использования, понять, что система должна делать.

10.4.3. Диаграммы последовательности

Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Снять деньги" предусматривает несколько возможных последовательностей: снятие денег, попытка снять деньги при отсутствии их достаточного количества на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые другие. Нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. 10.2.

Рис 10.2. Диаграмма последовательности снятия клиентом Джо $20 со счета

В верхней части диаграммы показаны все действующие лица и объекты, требуемые системе для выполнения варианта использования "Снять деньги". Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектом или между объектами для выполнения требуемых функций. Следует отметить также, что на диаграмме последовательности показаны именно объекты, а не классы. Классы представляют собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме последовательности представлен конкретный клиент Джо.

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения — этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". В то же время осуществляется проверка, что на этом счету лежат, по крайней мере, $20 и из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию "выдать чек и $20 наличными". Наконец, все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики — объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

10.4.4. Кооперативные диаграммы

Кооперативные диаграммы отражают ту же самую информацию, что и диаграммы последовательности. Однако дела, ют они это по-другому и с другими целями. Показанная на рис. 10.2 диаграмма последовательности представлена на рис. 10.3 в виде кооперативной диаграммы.

Как и раньше, объекты изображены в виде прямоугольников, а действующие лица в виде фигур. Если диаграмма последовательности показывает взаимодействие между действующими лицами и объектами во времени, то на кооперативной диаграмме связь со временем отсутствует. Так, можно видеть, что устройство для чтения карточки выдает "счету Джо" инструкцию открыться, а "счет Джо" заставляет это устройство вернуть карточку владельцу. Непосредственно взаимодействующие объекты соединены линиями. Если, например, устройство для чтения карточки общается непосредственно с экраном ATM, между ними следует провести линию. Отсутствие линии означает, что непосредственное сообщение между объектами отсутствует.

Рис. 10.3. Кооперативная диаграмма, описывающая процесс снятия денег со счета

Итак, на кооперативной диаграмме отображается та же информация, что и на диаграмме последовательности, но нужна она для других целей. Специалисты по контролю качества и архитекторы системы смогут понять распределение процессов между объектами. Допустим, что какая-то кооперативная диаграмма напоминает звезду, где несколько объектов связаны с одним центральным объектом. Архитектор системы может сделать вывод, что система слишком сильно зависит от центрального объекта, и необходимо перепроектировать ее для более равномерного распределения процессов. На диаграмме последовательности такой тип взаимодействия было бы трудно увидеть.

10.4.5. Диаграммы классов

Диаграммы классов отражают взаимодействие между классами системы. Например, "счет Джо" — это объект. Типом такого объекта можно считать счет вообще, т. е. "Счет" — это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Так, класс Счет содержит идентификационный номер клиента и проверяющие его действия. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или Кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. 10.4.

На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Связывающие классы линии показывают взаимодействие между классами.

Рис. 10.4. Диаграмма классов

Разработчики используют диаграммы классов для реального создания классов. Такие инструменты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщающимися классами не определено никаких связей. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.

10.4.6. Диаграммы состояний

Диаграммы состояний предназначены для моделирования различных состояний, в которых может находиться объект. В то время как диаграмма классов показывает статическую картину классов и их связей, диаграммы состояний применяются при описании динамики поведения системы.

Диаграммы состояний отображают поведение объекта. Так, банковский счет может иметь несколько различных состояний. Он может быть открыт, закрыт или может быть превышен кредит по нему. Поведение счета меняется в зависимости от состояния, в котором он находится. На диаграмме состояний показывают именно эту информацию. На рис. 10.5 приведен пример диаграммы состояний для банковского счета.

Рис. 10.5. Диаграмма состояний для класса Account

На данной диаграмме показаны возможные состояния счета, а также процесс перехода счета из одного состояния в другое. Например, если клиент требует закрыть открытый счет, последний переходит в состояние "Закрыт". Требование клиента называется событием, именно события вызывают переход из одного состояния в другое.

Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие определяет, когда может или не может произойти переход из одного состояния в другое.

На диаграмме имеются два специальных состояния — начальное и конечное. Начальное состояние выделяется черной точкой: оно соответствует состоянию объекта в момент его создания. Конечное состояние обозначается черной точкой в белом кружке: оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно или их может не быть вообще.

Когда объект находится в каком-то конкретном состоянии, могут выполняться те или иные процессы. В нашем примере при превышении кредита клиенту посылается соответствующее сообщение. Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями.

Диаграммы состояний не нужно создавать для каждого класса, они применяются только в очень сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из них ведет себя по-разному, для него, вероятно, потребуется такая диаграмма. Однако во многих проектах они вообще не используются. Если же диаграммы состояний все-таки были построены, разработчики могут применять их при создании классов.

Диаграммы состояний необходимы в основном для документирования.

10.4.7. Диаграммы компонент

Диаграммы компонент показывают, как выглядит модель на физическом уровне. На ней изображаются компоненты программного обеспечения вашей системы и связи между ними. При этом выделяют два типа компонент: исполняемые компоненты и библиотеки кода.

На рис. 10.6 изображена одна из диаграмм компонент для системы ATM. На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением. СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Выделенная темная компонента называется спецификацией пакета и соответствует файлу тела класса ATM на языке C++ (файл с расширением. СРР). Невыделенная компонента также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением. Н). Компонента АТМ. ехе является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки — это исполняемая программа.

Компоненты соединены штриховой линией, отображающей зависимости между ними. У системы может быть несколько диаграмм компонент в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонент.

Диаграммы компонент применяются теми участниками проекта, кто отвечает за компиляцию системы. Диаграмма компонент дает представление о том, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. Диаграмма показывает соответствие классов реализованным компонентам. Итак, она нужна там, где начинается генерация кода.

Рис. 10.6. Диаграмма компонент

10.4.8. Диаграммы размещения

Диаграммы размещения показывают физическое расположение различных компонент системы в сети. В нашем примере система ATM состоит из большого количества подсистем, выполняемых на отдельных физических устройствах или узлах. Диаграмма размещения для системы ATM представлена на рис. 10.7.

Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы ATM будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществляться сообщение клиентов с региональным сервером ATM. На нем будет работать программное обеспечение сервера ATM. В свою очередь, посредством локальной сети региональный сервер будет взаимодействовать с сервером банковской базы данных, работающим под управлением Oracle. Наконец, с региональным сервером ATM соединен принтер.

Итак, данная диаграмма показывает физическое расположение системы. Например, наша система ATM соответствует трехуровневой архитектуре, когда на первом уровне размещается база данных, на втором — региональный сервер, а на третьем — клиент.

10.7. Диаграмма размещения

Диаграмма размещения используется менеджером проекта, пользователями, архитектором системы и эксплуатационным персоналом для выяснения физического размещения системы и расположения ее отдельных подсистем. Менеджер проекта объяснит пользователям, как будет выглядеть готовый продукт. Эксплуатационный персонал сможет планировать работу по установке системы.

10.5. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ И ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

10.5.1. Достоинства и недостатки типов процесса разработки

Программное обеспечение может быть создано разными способами. Существует несколько различных типов процесса разработки, которые могут быть использованы в проекте: от "водопада" до объектно-ориентированного подхода. У каждого есть свои преимущества и недостатки. Здесь не указывается, какой именно процесс проектирования необходимо применять разработчикам в своей работе, а представляем лишь краткое описание процесса, связанного с визуальным моделированием.

Долгое время программное обеспечение разрабатывали, следуя так называемой модели "водопада". В соответствии с ней необходимо было сначала проанализировать требования к будущей системе, спроектировать, создать и протестировать систему, а затем установить ее у пользователей. Как видно из названия, движение в обратную сторону по этой цепочке было невозможно — вода не потечет вверх. Данный метод был официальной методологией, применявшейся в тысячах проектов, но в чистом виде, как его принято понимать, он не использовался ни разу. Одним из главных недостатков модели "водопада" является невозможность возврата назад на пройденные этапы. В начале проекта, следующего такой модели, перед разработчиками стоит обескураживающая задача — полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут до конца и не ознакамливаться с его результатами. Таким способом на стадии анализа при некотором везении удается собрать около 80 % требований к системе.

Затем начинается этап проектирования. Необходимо сесть и определить архитектуру будущей системы. Мы выясняем, где будут установлены программы и какая аппаратура нужна для достижения приемлемой производительности. На данном этапе могут обнаружиться новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. Итак, приходится возвращаться к анализу.

После нескольких таких кругов, наконец, наступает этап написания программного кода. На этом этапе обнаруживается, что некоторые из принятых ранее решений невозможно осуществить. Приходится возвращаться к проектированию и пересматривать эти решения. После завершения кодирования наступает этап тестирования, на котором выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад, на этап анализа, и пересматривать эти требования.

Наконец, система готова и поставлена пользователям. Поскольку прошло уже много времени и бизнес, вероятно, уже успел измениться, пользователи воспринимают ее без большого энтузиазма, отвечая примерно так: "Да, это то, что я просил, но не то, что я хочу!" Эта магическая фраза, заклинание разом состарит всю команду разработчиков как минимум на 10 лет!

Состоит ли проблема в том, что правила бизнеса изменяются слишком быстро? Может быть, пользователи не могут объяснить, чего они хотят или не понимают команду разработчиков? Или сама команда не придерживается определенного процесса? Ответы на эти вопросы: да, да и нет. Бизнес меняется очень быстро, и профессионалы-программисты должны поспевать за этим. Пользователи не всегда могут сказать, чего они хотят, поскольку их работа стала для них "второй натурой". Спрашивать об этом прослужившего 30 лет банковского клерка — примерно то же самое, что спрашивать, как он дышит. Работа стала для него настолько привычной, что ее уже трудно описать. Еще одна проблема заключается в том, что пользователи не всегда понимают команду разработчиков. Команда показывает им графики, выпускает тома текста, описывающего требования к системе, но пользователи не всегда понимают, что именно им дают. Есть ли способ обойти эту проблему? Да, здесь поможет визуальное моделирование. И наконец, команда разработчиков точно следует процессу — методу "водопада". К сожалению, планирование и реализация метода — две разные вещи.

Итак, одна из проблем заключается в том, что разработчики использовали метод "водопада", заключающийся в аккуратном и последовательном прохождении через все этапы проекта, но им приходилось возвращаться на пройденные этапы. Происходит ли это из-за плохого планирования? Вероятно, нет. Разработка программного обеспечения — сложный процесс, и его поэтапное, аккуратное выполнение не всегда возможно. Если же игнорировать необходимость возврата, то система будет содержать дефекты проектирования, и некоторые требования будут потеряны, возможны и более серьезные последствия. Прошли годы, пока мы не научились заранее планировать возвраты на пройденные этапы.

Таким образом, мы пришли к итеративной разработке. Это название означает лишь, что мы собираемся повторять одни и те же этапы снова и снова. В объектно-ориентированном процессе нужно по многу раз небольшими шагами проходить этапы анализа, проектирования, разработки, тестирования и установки системы.

Невозможно выявить все требования на ранних этапах проектирования. Мы учитываем появление новых требований в процессе разработки, планируя проект в несколько итераций. В рамках такой концепции проект можно рассматривать как последовательность небольших "водопадиков". Каждый из них достаточно велик, чтобы означать завершение какого-либо важного этапа проекта, но мал, чтобы минимизировать необходимость возврата назад. Мы проходим четыре фазы (этапа) проекта: начальная фаза, уточнение, конструирование и ввод в действие.

Начальная фаза — это начало проекта. Мы собираем информацию и разрабатываем базовые концепции. В конце этой фазы принимается решение продолжать (или не продолжать) проект.

В фазе уточнения детализируются варианты использования и принимаются архитектурные решения. Уточнение включает в себя некоторый анализ, проектирование, кодирование и планирование тестов.

В фазе конструирования разрабатывается основная часть кода.

Ввод в действие — это завершающая компоновка системы и установка ее у пользователей. Далее рассмотрим, что означает каждая из этих фаз в объектно-ориентированном проекте.

10.5.2. Начальная фаза

Начальная фаза — это начало работы над проектом, когда кто-нибудь говорит: "А хорошо бы, чтобы система делала…" Затем кто-то еще изучает идею, и менеджер спрашивает, сколько времени потребует ее реализация, сколько это будет стоить и насколько она выполнима. Начальная фаза как раз и заключается в том, чтобы найти ответы на эти вопросы. Мы исследуем свойства системы на высоком уровне и документируем их. Определяем действующих лиц и варианты использования, но не углубляемся в детали вариантов использования, ограничиваясь одним или двумя предложениями. Готовим также оценки для высшего руководства. Итак, применяя Rose для поддержки нашего проекта, создаем действующих лиц и варианты использования, а также строим диаграммы вариантов использования. Начальная фаза завершается, когда данное исследование закончено и для работы над проектом выделены необходимые ресурсы.

Начальная фаза проекта в основном последовательна и не итеративна. В отличие от нее другие фазы повторяются несколько раз в процессе работы над проектом. Так как проект может быть начат только один раз, начальная фаза также выполняется лишь однажды, поэтому в начальной фазе должна быть решена еще одна задача — разработка плана итераций. Это план, описывающий, какие варианты использования, на каких итерациях должны быть реализованы. Если, например, в начальной фазе было выявлено 10 вариантов использования, можно создать следующий план:

Итерация 1 Варианты Использования 1, 5, 6

Итерация 2 Варианты Использования 7, 9

Итерация 3 Варианты Использования 2, 4, 8

Итерация 4 Варианты Использования 3, 10

План определяет, какие варианты использования надо реализовать в первую очередь. Построение плана требует рассмотрения зависимостей между вариантами использования. Если для того, чтобы мог работать Вариант Использования 5, необходима реализация Варианта Использования 3, то описанный выше план неосуществим, поскольку Вариант Использования 3 реализуется на четвертой итерации — значительно позже Варианта Использования 5 из первой итерации. Такой план нужно пересмотреть, чтобы учесть все зависимости.

10.5.3. Использование Rose в начальной фазе

Некоторые задачи начальной фазы включают в себя определение вариантов использования и действующих лиц. Rose можно применять для документирования этих вариантов использования и действующих лиц, а также для создания диаграмм, показывающих связи между ними. Полученные диаграммы вариантов использования можно показать пользователям, чтобы убедиться, что они дают достаточно полное представление о свойствах системы.

В фазе уточнения проекта выполняются некоторое планирование, анализ и проектирование архитектуры. Следуя плану итерации, уточнение проводится для каждого варианта использования в текущей итерации. Уточнение включает в себя такие аспекты проекта, как кодирование прототипов, разработка тестов и принятие решений по проекту.

Основная задача фазы уточнения — детализация вариантов использования. Предъявляемые к вариантам использования требования низкого уровня предусматривают описание потока обработки данных внутри них, выявление действующих лиц, разработку диаграмм Взаимодействия для графического отображения потока обработки данных, а также определение всех переходов состояний, которые могут иметь место в рамках варианта использования. Из требований, определенных в форме детализированных вариантов использования, составляется документ под названием "Спецификация требований к программному обеспечению".

В фазе уточнения выполняются и такие задачи, как уточнение предварительных оценок, изучение модели вариантов использования с точки зрения качества проектируемой системы, анализ рисков. Можно уточнить модель вариантов использования, а также разработать диаграммы последовательности и кооперативные диаграммы для графического представления потока обработки данных. Кроме того, в этой фазе проектируются диаграммы классов, описывающие объекты, которые необходимо создать.

Фаза уточнения завершается, когда варианты использования полностью детализированы и одобрены пользователями, прототипы завершены настолько, чтобы уменьшить риски, разработаны диаграммы классов. Иными словами, эта фаза пройдена, когда система спроектирована, рассмотрена и готова для передачи разработчикам.

Фаза уточнения предоставляет несколько возможностей для применения Rational Rose. Так как уточнение — это детализация требований к системе, модель вариантов использования может потребовать обновления. Диаграммы последовательности и кооперативные диаграммы помогают проиллюстрировать поток обработки данных при его детализации. С их помощью можно также спроектировать требуемые для системы объекты. Уточнение предполагает подготовку проекта системы для передачи разработчикам, которые начнут ее конструирование. В среде Rose это может быть выполнено путем создания диаграмм классов и диаграмм состояний.

Конструирование — процесс разработки и тестирования программного обеспечения. Как и в случае уточнения, эта фаза выполняется для каждого набора вариантов использования на каждой итерации. Задачи конструирования включают в себя определение всех оставшихся требований, разработку и тестирование программного обеспечения (ПО). Так как ПО полностью проектируется в фазе уточнения, конструирование не предполагает большого количества решений по проекту, что позволяет команде работать параллельно. Это означает, что разные группы программистов могут одновременно работать над различными объектами ПО, зная, что по завершении фазы система "сойдется". В фазе уточнения мы проектируем объекты системы и их взаимодействие. Конструирование только запускает проект в действие, а новых решений по нему, способных изменить это взаимодействие, не принимается.

Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rational Rose способна генерировать "скелетный код" системы. Для использования этой возможности следует разработать компоненты и диаграмму компонентов на раннем этапе конструирования. Генерацию кода можно начать сразу после создания компонентов и нанесения на диаграмму зависимостей между ними. В результате будет автоматически построен код, который можно создать, основываясь на проекте системы. Это не означает, что с помощью Rose можно получить любой код, реализующий бизнес-логику приложений. Результат сильно зависит от используемого языка программирования, но в общем случае предполагает определение классов, атрибутов, областей действия. Это позволяет сэкономить время, так как написание кода вручную — довольно кропотливая и утомительная работа. Получив код, программисты могут сконцентрироваться на специфических аспектах, связанных с бизнес-логикой. Еще одна группа разработчиков должна выполнить экспертную оценку кода, чтобы убедиться в его функциональности и соответствии стандартам и соглашениям по проекту. Затем объекты должны быть подвергнуты оценке качества. Если в фазе конструирования были добавлены новые атрибуты или функции или если были изменены взаимодействия между объектами, код следует преобразовать в модель Rose с помощью обратного преобразования.

Конструирование можно считать завершенным, когда программное обеспечение готово и протестировано. Важно убедиться в адекватности модели и программного обеспечения. Модель будет чрезвычайно полезна в процессе сопровождения ПО.

В фазе конструирования пишется большая часть кода проекта. Rose позволяет создать компоненты в соответствии с проектированием объектов. Чтобы показать зависимости между компонентами на этапе компиляции, создаются диаграммы компонентов. После выбора языка программирования можно осуществить генерацию скелетного кода для каждого компонента. По завершении работы над кодом модель можно привести в соответствие с ним с помощью обратного проектирования.

Фаза ввода в действие наступает, когда готовый программный продукт передают пользователям. Задачи в этой фазе предполагают завершение работы над финальной версией продукта, завершение приемочного тестирования, завершение составления документации и подготовку к обучению пользователей. Чтобы отразить последние внесенные изменения, следует обновить спецификацию требований к программному обеспечению, диаграммы вариантов использования, классов, компонентов и размещения. Важно, чтобы ваши модели были синхронизированы с готовым продуктом, поскольку они будут использоваться при его сопровождении. Кроме того, модели будут неоценимы при внесении усовершенствований в созданную систему уже через несколько месяцев после завершения проекта. В фазе ввода в действие Rational Rose не настолько полезна, как в других фазах. В этот момент приложение уже создано. Rose предназначена для оказания помощи при моделировании и разработке программного обеспечения и даже при планировании его размещения. Однако Rose не является инструментом тестирования и не способна помочь в планировании тестов или процедур, связанных с размещением ПО. Для этой цели созданы другие продукты. Итак, в фазе ввода в действие Rose применяется, прежде всего, для обновления моделей после завершения работы над программным продуктом.

10.6. РАБОТА НАД ПРОЕКТОМ В СРЕДЕ RATIONAL ROSE

Из всех рассмотренных видов канонических диаграмм в среде Rational Rose 98/98i не поддерживается только диаграмма деятельности.

В ходе работы над диаграммами проекта имеется возможность удаления и добавления соответствующих графических элементов, установления отношений между этими элементами, их спецификации и документирования.

Общая последовательность работы над проектом аналогична последовательности рассмотрения канонических диаграмм в книге.

Одним из наиболее мощных свойств среды Rational Rose является возможность генерации программного кода после построения и проверки моделей. Общая последовательность действий, которые необходимо выполнить для этого, состоит из шести этапов:

— проверки модели независимо от выбора языка генерации кода;

— создания компонентов для реализации классов;

— отображения классов на компоненты;

— установки свойств генерации программного кода;

— выбора класса, компонента или пакета;

— генерации программного кода.

ВЫВОДЫ

• CASE-средства позволяют в автоматизированном режиме реализовать проектные модели.

• Реализованные проектные модели должны быть полными, отражать как функциональные, так и информационные аспекты проектируемых автоматизированных систем.

• CASE-средства включают набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения программного проекта и разрабатывать приложения в соответствии с информационными потребностями "пользователей.

• Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

• Передовые CASE-средства способны не только составлять спецификации, но и их проверять, а также генерировать исходный код программ.

• CASE-средства производятся множеством производителей и только наиболее удачные из них проходят проверку практикой.

• CASE-средство Rational Rose фирмы "Software Corporation" (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует объединенную методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона.

• Язык UML CASE-средства Rational Rose позволяет создавать несколько типов визуальных диаграмм:

— диаграммы вариантов использования;

— диаграммы последовательности;

— кооперативные диаграммы;

— диаграммы классов;

— диаграммы состояний;

— диаграммы компонент;

— диаграммы размещения.

Контрольные вопросы

1. Что такое CASE-средства?

2. Зачем необходимы CASE-средства?

3. В чем заключается сущность визуального моделирования?

4. Что отображают диаграммы вариантов использования?

5. Что отображают диаграммы последовательности?

6. Что отображают кооперативные диаграммы?

7. Что отображают диаграммы классов?

8. Что отображают диаграммы состояний?

9. Что отображают диаграммы компонент?

10. Что отображают диаграммы размещения?

11. В чем состоит суть модели разработки программного обеспечения "водопад", ее особенности и недостатки?

12. Изложите шаги методики разработки приложений с использованием Rational Rose.

Глава 11

ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

11.1. ОСНОВНЫЕ СВЕДЕНИЯ

Любой заказчик хочет получить надежное программное изделие, которое полностью удовлетворяет его потребности. Различные уровни надежности обеспечиваются разными инженерными подходами к тестированию. Другими словами, за достаточные средства можно достичь уровня надежности как у такой-то фирмы или даже уровня, необходимого для атомной энергетики или космических исследований.

Итак, уровень надежности программных изделий определяется инженерией тестирования. Как достичь высочайшего уровня надежности? Ясно, что тексты программ, написанные в одной организации, можно заново инспектировать, тестировать автономно и в составе ядра в иной организации. В самой программе можно одновременно производить расчеты по разным алгоритмам с использованием разных вычислительных методов и сличать результаты в контрольных точках, использовать подстановки рассчитанных результатов в исходные уравнения и тем самым контролировать результаты решения. Из изложенного видно, что уровень надежности программных изделий напрямую связан с затратами как денежных средств, так и времени проекта.

Как известно, при создании типичного программного проекта около 50 % общего времени и более 50–60 % общей стоимости расходуется на проверку (тестирование) разрабатываемой программы или системы. Кроме того, доля стоимости тестирования в общей стоимости программ имеет тенденцию возрастать при увеличении сложности программных изделий и повышении требований к их качеству.

Учитывая это, при выборе способа тестирования программ следует четко выделять определенное (по возможности не очень большое) число правил отладки, обеспечивающих высокое качество программного продукта и снижающих затраты на его создание.

Тестирование осуществляется путем исполнения тестов. Смысл теста программ показан на рис. 11.1.

Аксиомы тестирования, выдвинутые ведущими программистами:

— хорош тот тест, для которого высока вероятность обнаружения ошибки;

— главная проблема тестирования — решить, когда закончить (обычно решается просто — кончаются деньги);

— невозможно тестировать свою собственную программу;

— необходимая часть тестов — описание выходных результатов;

— избегайте невоспроизводимых тестов;

— готовьте тесты как для правильных, так и для неправильных данных;

— не тестируйте "с лету";

— детально изучайте результаты каждого теста;

— по мере обнаружения все большего числа ошибок в некотором модуле или программе, растет вероятность обнаружения в ней еще большего числа ошибок;

— тестируют программы лучшие умы;

— считают тестируемость главной задачей разработчиков программы;

— не изменяй программу, чтобы облегчить тестирование;

— тестирование должно начинаться с постановки целей.

Если в программе ставят комментарии на месте вызова модуля вместо использования заглушки, то исключают возможность проверки типов данных, а также часто забывают снимать комментарии. Для поиска "забытых" комментариев необходима трудоемкая отладка.

Среди приемов тестирования стоит выделить также так называемую отладочную печать. Если отладочные печати изымаются из текста, то утяжеляется сопровождение. Вывод: никогда не изымай отладочные печати даже с использованием препроцессора:

{$IFDEF DEBUG THEN}

…

{$ELSE}

…

{$ENDIF}

Рис. 11.1. Смысл теста программ

Лучше опишите глобальную переменную DebugLevel и программируйте условные отладочные печати:

var

DebugLevel: word; {0-нет ни одной отладочной печати, чем больше значение, тем подробнее отладочная печать}

DebugFile: text; {файл отладочной печати}

DebugLevel:= 4; {задание уровня отладки}

if DebugLevel >= 3 then

WriteLn(DebugFile, 'Модуль:', 'MyModule, 'результат:');

11.2. СВОЙСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Следует выделить следующие свойства программного обеспечения.

Корректность программного обеспечения — свойство безошибочной реализации требуемого алгоритма при отсутствии таких мешающих факторов, как ошибки входных данных, ошибки операторов ЭВМ (людей), сбои и отказы ЭВМ.

В интуитивном смысле под корректностью понимают свойства программы, свидетельствующие об отсутствии в ней ошибок, допущенных разработчиком на различных этапах проектирования (спецификации, проектирования алгоритма и структур данных, кодировании). Корректность самой программы понимают по отношению к целям, поставленным перед ее разработкой (т. е. это относительное свойство).

Устойчивость — свойство осуществлять требуемое преобразование информации при сохранении выходных решений программы в пределах допусков, установленных спецификацией. Устойчивость характеризует поведение программы при воздействии на нее таких факторов неустойчивости, как ошибки операторов ЭВМ, а также не выявленные ошибки программы.

Восстанавливаемость — свойство программного обеспечения, характеризующее возможность приспосабливаться к обнаружению ошибок и их устранению.

Надежность можно представить совокупностью следующих характеристик:

— целостностью программного средства (способностью его к защите от отказов);

— живучестью (способностью к входному контролю данных и их проверки в ходе работы);

— завершенностью (бездефектностью готового программного средства, характеристикой качества его тестирования);

— работоспособностью (способностью программного средства к восстановлению своих возможностей после сбоев).

Отличие понятия корректности и надежности программ состоит в следующем:

— надежность характеризует как программу, так и ее "окружение" (качество аппаратуры, квалификацию пользователя и т. п.);

— говоря о надежности программы, обычно допускают определенную, хотя и малую долю ошибок в ней и оценивают вероятность их появления.

Вернемся к понятию корректности. Очевидно, что не всякая синтаксически правильная программа является корректной в указанном выше смысле, т. е. корректность характеризует семантические свойства программ.

С учетом специфики появления ошибок в программах можно выделить две стороны понятия корректности:

— корректность как точное соответствие целям разработки программы (которые отражены в спецификации) при условии ее завершения или частичная корректность;

— завершение программы, т. е. достижение программой в процессе ее выполнения своей конечной точки.

В зависимости от выполнения или невыполнения каждого из двух названных свойств программы различают шесть задач анализа корректности:

1) доказательство частичной корректности;

2) доказательство частичной некорректности;

3) доказательство завершения программы;

4) доказательство не завершения программы;

5) доказательство тотальной (полной) корректности (т. е. одновременное решение 1-й и 3-й задач);

6) доказательство некорректности (решение 2-й или 4-й задачи). Методы доказательства частичной корректности программ, как

правило, опираются на аксиоматический подход к формализации семантики языков программирования. Аксиоматическая семантика языка программирования представляет собой совокупность аксиом и правил вывода. С помощью аксиом задается семантика простых операторов языка (присваивания, ввода-вывода, вызова процедур). С помощью правил вывода описывается семантика составных операторов или управляющих структур (последовательности, условного выбора, циклов). Среди этих правил вывода надо отметить правило вывода для операторов цикла, так как оно требует знания инварианта цикла (формулы, истинность которой не изменяется при любом прохождении цикла).

Наиболее известным из методов доказательства частичной корректности программ является метод индуктивных утверждений, предложенный Флойдом и усовершенствованный Хоаром. Один из важных этапов этого метода — получение аннотированной программы. На этом этапе для синтаксически правильной программы должны быть заданы утверждения на языке логики предикатов первого порядка: входной предикат; выходной предикат.

Эти утверждения задаются для входной точки цикла и должны характеризовать семантику вычислений в цикле.

Доказательство неистинности условий корректности свидетельствует о неправильности программы или ее спецификации, или программы и спецификации.

По влиянию на результаты обработки информации к надежности и устойчивости программного обеспечения близка и точность программного обеспечения, определяемая ошибками метода и ошибками представления данных.

Наиболее простыми методами оценки надежности программного обеспечения являются эмпирические модели, основанные на опыте разработки программ: если до начала тестирования на 1000 операторов приходится 10 ошибок, а приемлемым качеством является 1 ошибка, то в ходе тестирования надо найти:

Более точна модель Холстеда: N ошибок = N операторов * log_2(N операторов — N операндов),

где N операторов — число операторов в программе; N операндов — число операндов в программе.

Эмпирическая модель фирмы IBM:

N ошибок = 23 M(10) + 2 M(1),

где M(10) — число модулей с 10 и более исправлениями; M(1) — число модулей с менее 10 исправлениями.

Если в модуле обнаружено более 10 ошибок, то его программируют заново.

По методу Милса в разрабатываемую программу вносят заранее известное число ошибок. Далее считают, что темпы выявления ошибок (известных и неизвестных) одинаковы.

11.3. СВЯЗЬ ПРОЦЕССОВ ТЕСТИРОВАНИЯ С ПРОЦЕССОМ ПРОЕКТИРОВАНИЯ

Из рис. 11.2 видно, что ошибки на ранних этапах проекта исчерпывающе могут быть выявлены в самом конце работы.

Тестирование программ охватывает ряд видов деятельности:

• постановку задачи;

• проектирование тестов;

• написание тестов;

• тестирование тестов;

• выполнение тестов;

• изучение результатов тестирования.

Здесь наиболее важным является проектирование тестов.

Итак, тестирование — это процесс выполнения программы с целью обнаружения ошибок.

11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ

Рассмотрим два самых противоположных подхода к проектированию тестов.

Сторонник первого подхода ориентируется только на стратегию тестирования, называемую стратегией "черного ящика", тестированием с управлением по данным или тестированием с управлением по входу-выходу. При использовании этой стратегии программа рассматривается как черный ящик. Тестовые данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре). Недостижимый идеал сторонника первого подхода — проверить все возможные комбинации и значения на входе. Обычно их слишком много даже для простейших алгоритмов. Так, для программы расчета среднего арифметического четырех чисел надо готовить 10^7 тестовых данных.

Рис. 11.2. Взаимосвязь процессов проектирования и тестирования

При первом подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Следовательно, приходим к выводу, что для исчерпывающего тестирования программы требуется бесконечное число тестов, а значит, построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий отсутствие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям. Поскольку исчерпывающее тестирование исключается, нашей целью должна стать максимизация результативности капиталовложений в тестирование (максимизация числа ошибок, обнаруживаемых одним тестом). Для этого необходимо рассматривать внутреннюю структуру программы и делать некоторые разумные, но, конечно, не обладающие полной гарантией достоверности предположения.

Сторонник второго подхода использует стратегию "белого ящика", или стратегию тестирования, управляемую логикой программы, которая позволяет исследовать внутреннюю структуру программы. В этом случае тестировщик получает тестовые данные путем анализа только логики программы; стремится, чтобы каждая команда была выполнена хотя бы один раз. При достаточной квалификации добивается, чтобы каждая команда условного перехода выполнялась бы в каждом направлении хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Цель тестирования всех путей извне также недостижима. В программе из двух последовательных циклов внутри каждого из них включено ветвление на десять путей, имеется 10^18 путей расчета. Причем выполнение всех путей расчета не гарантирует выполнения всех спецификаций. Для справки: возраст Вселенной 10^17с.

Сравним способ построения тестов при данной стратегии с исчерпывающим входным тестированием стратегии "черного ящика". Неверно предположение, что достаточно построить такой набор тестов, в котором каждый оператор исполняется хотя бы один раз. Исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов. Подразумевается, что программа проверена полностью, если с помощью тестов удается осуществить выполнение этой программы по всем возможным маршрутам ее потока (графа) передач управления.

Последнее утверждение имеет два слабых пункта: во-первых, число не повторяющих друг друга маршрутов — астрономическое; во-вторых, даже если каждый маршрут может быть проверен, сама программа может содержать ошибки (например, некоторые маршруты пропущены).

Свойство пути выполняться правильно для одних данных и неправильно для других — называемое чувствительностью к данным, наиболее часто проявляется за счет численных погрешностей и погрешностей усечения методов. Тестирование каждого из всех маршрутов одним тестом не гарантирует выявление чувствительности к данным.

В результате всех изложенных выше замечаний отметим, что ни исчерпывающее входное тестирование, ни исчерпывающее тестирование маршрутов не могут стать полезными стратегиями, потому что оба они нереализуемы. Поэтому реальным путем, который позволит создать хорошую, но, конечно, не абсолютную стратегию, является сочетание тестирования программы несколькими методами.

Рассмотрим пример тестирования оператора

if A and В then…

при использовании разных критериев полноты тестирования.

При критерии покрытия условий требовались бы два теста: А = true, В = false и А = false, В = true. Но в этом случае не выполняется then-предложение оператора if.

Существует еще один критерий, названный покрытием решений/условий. Он требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз; все результаты каждого решения выполнялись тоже один раз и каждой точке входа передавалось управление, по крайней мере, один раз.

Недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий. Часто подобное выполнение имеет место вследствие того, что определенные условия скрыты другими условиями. Например, если условие AND есть ложь, то никакое из последующих условий в выражении не будет выполнено. Аналогично, если условие OR есть истина, то никакое из последующих условий не будет выполнено. Следовательно, критерии покрытия условий и покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.

Критерием, который решает эти и некоторые другие проблемы, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении и все точки входа выполнялись, по крайней мере, один раз.

В случае циклов число тестов для удовлетворения критерию комбинаторного покрытия условий обычно больше, чем число путей.

Легко видеть, что набор тестов, удовлетворяющий критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

Таким образом, для программ, содержащих только одно условие на каждое решение, минимальным является критерий, набор тестов которого вызывает выполнение всех результатов каждого решения, по крайней мере, один раз; передает управление каждой точке входа (например, оператор CASE).

Для программ, содержащих решения, каждое из которых имеет более одного условия, минимальный критерий состоит из набора тестов, вызывающих все возможные комбинации результатов условий в каждом решении и передающих управление каждой точке входа программы, по крайней мере, один раз.

Деление алгоритма на типовые стандартные структуры, согласно проектной процедуре кодирования текста модуля (метода) из пятой главы учебника, позволяет минимизировать усилия программиста, затрачиваемые им на тестирование. Запрет на вложенные структуры как раз и объясняется излишними затратами на тестирование. Использование цепочки простых альтернатив с одним действием или структуры ВЫБОР вместо вложенных простых АЛЬТЕРНАТИВ значительно сокращает число тестов!

11.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ

Проектирование тестов больших программ пока в большей мере остается искусством и в меньшей мере является наукой. Чтобы построить разумную стратегию тестирования, надо разумно сочетать оба этих два крайних подхода и пользоваться математическими доказательствами.

Восходящее тестирование. Сначала автономно тестируются модули нижних уровней, которые не вызывают других модулей. При этом достигается такая же их высокая надежность, как и у встроенных в компилятор функций. Затем тестируются модули более высоких уровней вместе с уже проверенными модулями и т. д. по схеме иерархии.

При восходящем тестировании для каждого модуля необходима ведущая программа. Это монитор или драйвер, который подает тесты в соответствии со спецификациями тестов. Ряд фирм выпускает промышленные драйверы или мониторы тестов.

Нисходящее тестирование. При этом подходе изолированно тестируется головной модуль или группа модулей головного ядра. Программа собирается и тестируется сверху вниз. Недостающие модули заменяются заглушками.

Достоинства нисходящего тестирования: этот метод совмещает тестирование модуля с тестированием сопряжений и частично тестирует функции модуля. Когда уже начинает работать ввод/вывод модуля, удобно готовить тесты.

Недостатки нисходящего тестирования: модуль редко досконально тестируется сразу после его подключения. Для основательного тестирования требуются изощренные заглушки. Часто программисты откладывают тщательное тестирование и даже забывают о нем. Другой недостаток — желание начать программирование еще до конца проектирования. Если ядро уже запрограммировано, то возникает сопротивление всяким его изменениям, даже для улучшения структуры программы. В конечном итоге, именно рационализация структуры программы за счет проведения проектных итераций способствует достижению большей экономии, чем даст раннее программирование.

Модифицированный нисходящий метод. Согласно этому методу, каждый модуль автономно тестируется перед включением в программу, собираемую сверху вниз.

Метод большого скачка — каждый модуль тестируется автономно. По окончании автономного тестирования всех модулей модули просто интегрируются в готовую программную систему. Как правило, этот метод нежелателен. Однако если программа мала и хорошо спроектирована по сопряжениям, то метод большого скачка вполне приемлем.

Метод сандвича представляет собой компромисс между нисходящим и восходящим подходами. По этому методу реализация и тестирование ведутся одновременно сверху и снизу, и два этих процесса встречаются в заранее намеченной временной точке.

Модифицированный метод сандвича: нижние модули тестируются строго снизу вверх, а модули верхних модулей сначала тестируются автономно, а затем собираются нисходящим методом.

11.6. КРИТЕРИИ ВЫБОРА НАИЛУЧШЕЙ СТРАТЕГИИ РЕАЛИЗАЦИИ

Критериями выбора наилучшей стратегии реализации программы являются:

• время до полной сборки программы;

• время реализации скелета программы;

• имеющийся инструментарий тестирования;

• мера параллелизма ранних этапов реализации;

• возможность проверки любых путей программы данными из заглушек;

• сложность планирования и соблюдения графика реализации;

• сложность тестирования.

11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ

Существуют два способа тестирования: публичный и приватный.

Публичное тестирование означает, что любой желающий может получить данный продукт (либо бесплатно, либо по цене дисков и доставки).

Приватный способ тестирования означает, что проверку продукта производит ограниченный круг тестировщиков, которые выразили согласие активно работать с продуктом и оперативно сообщать обо всех выявленных дефектах. Часто используются оба способа: сначала программа проходит приватное тестирование, а затем, когда все крупные проколы уже выявлены, начинается ее публичное тестирование, чтобы собрать отзывы широкого круга пользователей.

Большинство компаний-разработчиков требуют, чтобы приватный бета-тестировщик подписал "Соглашение о неразглашении" (NDA, Non-Disclosure Agreement). Тем самым он обязуется не разглашать подробности о тестируемом продукте и не передавать его копии третьим лицам. Подобные соглашения подписываются в целях сохранения коммерческой тайны и во избежание недобросовестной конкуренции.

Так, фирма "Microsoft" использует все перечисленные выше подходы для тестирования своих продуктов. С ее сайтов всегда можно бесплатно загрузить большое количество продуктов, проходящих публичное бета-тестирование. Однако их появлению предшествует многомесячный процесс приватного тестирования. Фирма "Microsoft" проводит политику открытого набора приватных бета-тестировщиков, при которой каждый желающий может сообщить корпорации о своем желании принять участие в тестировании того или иного продукта. На самом деле круг приватных бета-тестеров Microsoft очень узок, и шанс, что вас включат в их число, невелик. Тем не менее он существует, а попадают в список бета-тестеров практически пожизненно.

Приватное тестирование подпрограмм начинается с этапа контроля, основными разновидностями которого являются: визуальный, статический и динамический.

Визуальный контроль — это проверка текстов "за столом", без использования компьютера.

На первом этапе визуального контроля осуществляется чтение текста подпрограммы, причем особое внимание уделяется: комментариям и их соответствию тексту программы; условиям в операторах условного выбора и цикла; сложным логическим выражениям; возможности незавершения итерационных циклов.

Второй этап визуального контроля — сквозной контроль текста подпрограммы (его ручная прокрутка на нескольких заранее подобранных простых тестах). Распространенное мнение, что более выгодным является перекладывание большей части работы по контролю программных средств на компьютер, ошибочно. Основной довод в пользу этого таков: при работе на компьютере главным образом совершенствуются навыки в использовании клавиатуры, в то время как программистская квалификация приобретается, прежде всего, за столом.

Статический контроль — это проверка текста подпрограммы (без выполнения) с помощью инструментальных средств.

Первой, наиболее известной формой статического контроля является синтаксический контроль программы с помощью компилятора, при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.

Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня тяжести нарушения синтаксиса языка программирования:

1) информационные сообщения и предупреждения, при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);

2) сообщения об ошибках, при обнаружении которых компилятор пытается их исправить и строит объектный код, но его корректность маловероятна и дальнейшая работа с ним, скорее всего, невозможна;

3) сообщения о серьезных ошибках, при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;

4) сообщения об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода.

Однако практически любой компилятор пропускает некоторые виды синтаксических ошибок. Место обнаружения ошибки может находиться далеко по тексту подпрограммы от места истинной ошибки, а текст сообщения компилятора может не указывать на истинную причину ошибки. Одна синтаксическая ошибка может повлечь за собой генерацию компилятором нескольких сообщений об ошибках (например, ошибка в описании переменной приводит к появлению сообщения об ошибке в каждом операторе подпрограммы, использующем эту переменную).

Второй формой статического контроля может быть контроль структурированности текста подпрограммы, т. е. проверка выполнения соглашений и ограничений структурного программирования. Примером подобной проверки может быть выявление в тексте подпрограммы ситуаций, когда цикл образуется с помощью оператора безусловного перехода (использования оператора GOTO для перехода вверх по тексту программы). Для проведения контроля структурированности могут быть созданы специальные инструментальные средства, а при их отсутствии эта форма статического контроля может совмещаться с визуальным контролем.

Третья форма статического контроля — контроль правдоподобия подпрограммы, т. е. выявление в ее тексте конструкций, которые хотя и синтаксически корректны, но скорее всего содержат ошибку или свидетельствуют о ней. Основные неправдоподобные ситуации:

• использование в программе неинициализированных переменных (т. е. переменных, не получивших начального значения);

• наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;

• наличие в тексте подпрограммы фрагментов, никогда не выполняющихся;

• наличие в тексте программы переменных, ни разу не используемых для чтения после присваивания им значений;

• наличие в тексте подпрограммы заведомо бесконечных циклов.

Даже если присутствие в тексте программы неправдоподобных конструкций не приводит к ее неправильной работе, исправление этого фрагмента повысит ясность и эффективность программы, т. е. благотворно скажется на ее качестве.

Для возможности проведения контроля правдоподобия в полном объеме также должны быть созданы специальные инструментальные средства, хотя ряд возможностей по контролю правдоподобия имеется в существующих отладочных и обычных компиляторах.

Следует отметить, что создание инструментальных средств контроля структурированности и правдоподобия программ может быть упрощено существенно при применении следующих принципов:

1) проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ;

2) максимальное использование результатов компиляции и линковки программы и, в частности, информации, включаемой в листинг компилятора и линкера;

3) вместо полного синтаксического разбора текста проверяемой программы необходимо построение для нее списка идентификаторов и списка операторов с указанием всех их необходимых признаков.

При отсутствии инструментальных средств контроля правдоподобия эта фаза статического контроля также может объединяться с визуальным контролем.

Четвертой формой статического контроля программ является их верификация, т. е. аналитическое доказательство их корректности.

Несмотря на достаточную сложность процесса верификации программы и на то, что даже успешно завершенная верификация не дает гарантий качества программы (так как ошибка может содержаться и в верификации), применение методов аналитического доказательства правильности очень полезно для уточнения смысла разрабатываемой программы, а знание этих методов благотворно сказывается на квалификации программиста.

Динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т. е. тестирование. Минимальное автономное тестирование подпрограммы должно обеспечивать прохождение всех путей вычислений.

Проектная процедура тестирования подпрограммы заключается в следующем:

— по внешним спецификациям модуля подготовьте тесты для каждой ситуации и каждого недопустимого условия;

— просмотрите текст подпрограммы, чтобы убедиться, что все условные переходы будут выполняться в каждом направлении; при необходимости добавьте тесты;

— убедитесь по тексту подпрограммы, что тесты охватывают достаточно много путей; для циклов должны быть тесты без повторения, с одним повторением и с несколькими повторениями;

— проверьте по тексту подпрограммы ее чувствительность к особым значениям данных (наиболее опасные числа — это ноль и единица), в случае необходимости добавьте тесты.

11.8. ПРОЕКТИРОВАНИЕ КОМПЛЕКСНОГО ТЕСТА

В комплексном тесте должны проводиться следующие виды тестирования:

• работоспособности;

• стрессов;

• предельного объема вводимых данных;

• конфигурации различных технических средств;

• совместимости;

• защиты;

• требуемой памяти;

• производительности;

• настройки;

• надежности;

• средств восстановления при отказе;

• удобства обслуживания;

• программной документации;

• психологических факторов;

• удобства эксплуатации.

11.9. СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Генераторы тестов (automatic unit test) случайным образом генерируют данные.

Статические анализаторы программ, анализируют исходный тест и строят диаграммы маршрутов; анализируют присваивание данных и делают попытки построений данных, приводящих к ошибке.

Средства периода выполнения обычно производят статистический подсчет количества выполнения каждого оператора и позволяют контролировать полноту тестов.

ВЫВОДЫ

• Тестирование программ — главное, что определяет важнейшее качество программ — надежность.

• На тестирование расходуется основная часть средств и времени проекта.

• При разработке любой программы или системы тестирование отбирает большую часть времени и денег. Учитывая это, необходимо определить не очень большое количество тестов, обеспечивающих высокую вероятность обнаружения тех или иных ошибок.

• Аксиомы тестирования определяют основные цели и принципы тестирования.

• Если из текста исключить отладочные печати, то существенно усложнится сопровождение.

• Существуют два крайних подхода к проектированию тестов: стратегия "черного ящика" и стратегия "белого ящика". Бесполезно следовать только одному подходу. Необходимо строить стратегию тестирования только на основе сочетания подходов.

• При проектировании многомодульных программ используется восходящее тестирование (автономное тестирование нижних модулей, не вызывающих других модулей) и нисходящее тестирование (применение заглушек нижних уровней). Но у каждого из них есть свои достоинства и недостатки. Возможны также варианты:

— модифицированный нисходящий метод — согласно этому методу каждый модуль автономно тестируется перед включением в программу, собираемую сверху вниз;

— метод большого скачка — каждый модуль тестируется автономно, далее модули просто интегрируются в готовую программную систему;

— метод сандвича — по этому методу реализация и тестирование ведутся одновременно сверху и снизу, и два этих процесса встречаются в заранее намеченной временной точке;

— модифицированный метод сандвича — нижние модули тестируются строго снизу вверх, а модули верхних модулей сначала тестируются автономно, а затем собираются нисходящим методом. Этот метод апробирован при создании ОС.

• Существует деление тестирования на публичное и приватное. Часто используются оба способа: сначала программа проходит приватное тестирование, а затем, когда все крупные "проколы" уже выявлены, начинается ее публичное тестирование, чтобы собрать отзывы широкого круга пользователей.

Контрольные вопросы

1. Назовите основные аксиомы тестирования.

2. В чем преимущество отладочной печати?

3. Какие свойства программного обеспечения оказывают наибольшее влияние на процесс обнаружения ошибок при тестировании?

4. Для чего нужны эмпирические модели? Как производится их анализ?

5. Какова связь между процессами тестирования и проектирования?

6. В чем достоинства и недостатки восходящего и нисходящего проектирования? Ответ обосновать на примере конкретной программы.

7. Какой тест максимально быстро обнаружит зацикливание?

8. Выделите несколько основных критериев при выборе параметров тестирования.

Глава 12

МЕНЕДЖМЕНТ ПРОГРАММНЫХ РАЗРАБОТОК

12.1. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ СИСТЕМ

Управление разработкой программных систем (software management) — это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков программного обеспечения (ПО), на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПО, выполнения сроков и бюджета разработки ПО. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПО, а ход выполнения этих работ называют развитием программного проекта (software project progress).

К необходимым условиям работы коллектива относят помещения, аппаратно-программные средства разработки, документацию и материально-финансовое обеспечение. Планирование и контроль предполагают разбиение всего процесса разработки ПО на отдельные конкретные работы (задания), подбор и расстановку исполнителей, установление сроков и порядка выполнения этих работ, оценку качества выполнения каждой работы. Финальной частью этой деятельности является организация и проведение аттестации (сертификации) ПО, которой завершается стадия разработки ПО.

Хотя виды деятельности по управлению разработкой ПО могут быть весьма разнообразными, в зависимости от специфики разрабатываемого ПО и организации работ по его созданию можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПО:

— составление плана-проспекта по разработке ПО;

— планирование и составление расписаний по разработке ПО;

— управление издержками по разработке ПО;

— текущий контроль и документирование деятельности коллектива по разработке ПО;

— подбор и оценка персонала коллектива разработчиков ПО.

Составление плана-проспекта по разработке ПО включает формулирование предложений о том, как выполнять разработку ПО. Прежде всего должно быть зафиксировано, для кого разрабатывается ПО:

• для внешнего заказчика;

• для других подразделений той же организации;

• является инициативной внутренней разработкой.

В плане-проспекте должны быть установлены общие очертания работ по созданию ПО и оценена стоимость разработки, а также предоставляемые для разработки ПО материально-финансовые ресурсы и временные ограничения. Кроме того, он должен включать обоснование, какого рода коллективом должно разрабатываться ПО (специальной организацией, отдельной бригадой и т. п.). И наконец, должны быть сформулированы необходимые технологические требования (включая, возможно, и выбор подходящей технологии программирования).

Планирование и составление расписаний по разработке ПО — это деятельность, связанная с распределением работ между исполнителями и по времени их выполнения в рамках намеченных сроков и имеющихся ресурсов.

Управление издержками по разработке ПО — это деятельность, направленная на обеспечение подходящей стоимости разработки в рамках выделенного бюджета. Она включает оценивание стоимости разработки проекта в целом или отдельных его частей, контроль выполнения бюджета, выбор подходящих вариантов его расходования. Эта деятельность тесно связана с планированием и составлением расписаний в течение всего периода выполнения проекта. Основными источниками издержек являются затраты на аппаратное оборудование (hardware), вербовку и обучение персонала, оплату труда разработчиков.

Текущий контроль и документирование деятельности коллектива по разработке ПО — это непрерывный процесс слежения за ходом развития проекта, сравнения действительных состояния и издержек с запланированными, а также документирования различных аспектов развития проекта. Этот процесс помогает вовремя обнаружить затруднения и предсказать возможные проблемы в развитии проекта.

Подбор и оценка персонала коллектива разработчиков ПО — это деятельность, связанная с формированием коллектива разработчиков ПО. Имеющийся в распоряжении штат разработчиков далеко не всегда будет подходящим по квалификации и опыту работы для данного проекта. Поэтому приходится частично вербовать подходящий персонал и частично организовывать дополнительное обучение имеющихся разработчиков. В любом случае в формируемом коллективе хотя бы один его член должен иметь опыт разработки программных средств (систем), сопоставимых с ПО, которое требуется разработать. Это поможет избежать многих простых ошибок в развитии проекта.

Обеспечение качества. Качество ПО формируется постепенно в процессе всей разработки ПО в каждой отдельной работе, выполняемой по программному проекту. Не могут вноситься изменения по улучшению качества в уже созданную программу.

Для руководства этой деятельностью назначается специальный менеджер, подчиненный непосредственно директору, — менеджер по качеству. Ему непосредственно подчинены формируемые бригады по контролю качества. Для каждой работы организуется смотр (review) соответствующей бригадой. Смотру подлежат все программные компоненты и документы, включаемые в ПО, а также процессы их разработки. Смотр по контролю качества является функцией управления разработкой и связан с оценкой того, насколько результаты этой работы согласуются с декларированными требованиями относительно качества ПО.

Для оценки существуют программные стандарты. Они фиксируют удачный опыт высококвалифицированных специалистов по разработке ПО для различных его классов и для разных моделей качества.

Различают два вида таких стандартов:

• стандарты ПО (программного продукта);

• стандарты процесса создания и использования ПО.

Стандарты ПО определяют некоторые свойства, которыми должны обладать программы или документы ПО, т. е. определяют в какой-то степени качество ПО. К стандартам ПО относятся прежде всего стандарты на языки программирования, состав документации, структуру различных документов, различные форматы и др.

Стандарты процесса создания и использования ПО определяют, как должен проводиться этот процесс, т. е. подход к разработке ПО, структуру жизненного цикла ПО и его технологические процессы. Хотя эти стандарты непосредственно не определяют качества ПО, однако считается, что качество ПО существенно зависит от качества процесса его разработки.

12.2. СТРУКТУРА УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ СРЕДСТВ

Разработка ПО обычно производится в организации, в которой одновременно могут вестись разработки ряда других программных средств. Для управления всеми этими программными проектами используется иерархическая структура управления (рис. 12.1).

Рис. 12.1. Структура управления разработкой программных средств

Во главе иерархии находится директор программистской организации, отвечающий за управление всеми разработками программных средств. Ему непосредственно подчинены несколько менеджеров сферы разработок и один менеджер по качеству программных средств. В результате общения с потенциальными заказчиками директор принимает решение о начале выполнения какого-либо программного проекта, поручая его одному из менеджеров сферы разработок, а также решение о прекращении того или иного проекта. Он участвует в обсуждении общих организационных требований к программному проекту и возникающих проблем, решение которых требует использования общих ресурсов программистской организации или изменения заказчиком общих требований.

Менеджер сферы разработок отвечает за управление разработками программных средств (систем) определенного типа, например программные системы в сфере бизнеса, экспертные системы, программные инструменты и инструментальные системы, поддерживающие процессы разработки программных средств, и др. Ему непосредственно подчинены менеджеры проектов, относящихся к его сфере. Получив поручение директора по выполнению некоторого проекта, организует формирование коллектива исполнителей по этому проекту, участвует в обсуждении плана-проспекта программного проекта, относящегося к сфере разработок, за которую он отвечает, а также в обсуждении и решении возникающих проблем в развитии этого проекта. Он организует обобщение опыта разработок программных средств в его сфере и накопление программных средств и документов для повторного использования.

По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему непосредственно подчинены лидеры бригад разработчиков.

Менеджер проекта осуществляет планирование и составление расписаний работы бригад по разработке соответствующего программного средства.

Считается крайне нецелесообразным разработка большой программной системы одной большой единой бригадой разработчиков. Для этого имеется ряд серьезных причин. В частности, в большой бригаде время, затрачиваемое на общение между ее членами, может быть больше времени, затрачиваемого на собственно разработку. Отрицательное влияние оказывает большая бригада на строение ПО и на интерфейс между отдельными его частями. Все это приводит к снижению надежности ПО. Поэтому обычно большой проект разбивается на несколько относительно независимых подпроектов таким образом, чтобы каждый подпроект мог быть выполнен отдельной небольшой бригадой разработчиков (обычно считается, что в бригаде не должно быть больше 8—10 членов). При этом архитектура ПО должна быть такой, чтобы между программными подсистемами, разрабатываемыми независимыми бригадами, был достаточно простой и хорошо определенный системный интерфейс.

Наиболее часто применяемыми являются четыре подхода к организации бригад разработчиков: обычные бригады; неформальные демократические бригады; бригады ведущего программиста; бригада по контролю качества.

В обычной бригаде старший программист (лидер бригады) непосредственно руководит работой младших программистов. Недостатки такой организации непосредственно связаны со спецификой разработки ПО: программисты разрабатывают сильно связанные части программной подсистемы; сам процесс разработки состоит из многих этапов, каждый из которых требует особенных способностей от программиста; ошибки отдельного программиста могут препятствовать работе других программистов. Успех работы такой бригады достигается в том случае, когда ее руководитель является компетентным программистом, способным предъявлять к членам бригады разумные требования и умеющим поощрять хорошую работу.

В неформальной демократической бригаде поручаемая ей работа обсуждается совместно всеми ее членами, а задания между ее членами распределяются согласованно, в зависимости от способностей и опыта членов бригады. Один из членов такой бригады является руководителем бригады. Он также выполняет некоторые задания, распределяемые между членами бригады. Неформальные демократические бригады могут весьма успешно справляться с порученной им работой, если большинство членов бригады являются опытными и компетентными специалистами. Если же неформальная демократическая бригада состоит в основном из неопытных и некомпетентных членов, в деятельности бригады могут возникать большие трудности. Без наличия в бригаде хотя бы одного квалифицированного и авторитетного члена, способного координировать и направлять работу членов бригады, эти трудности могут привести к неудаче проекта.

В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек — ведущий программист (chief programmer), являющийся лидером бригады: он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады в основном создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой. Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки.

Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность — быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист.

Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки. В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены:

• распорядитель бригады, выполняющий административные функции;

• технический редактор, осуществляющий доработку и техническое редактирование документов, написанных ведущим программистом;

• инструментальщик, отвечающий за подбор и функционирование программных средств, поддерживающих разработку программной подсистемы;

• тестировщик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;

• один или несколько младших программистов, осуществляющих кодирование отдельных программных компонент по спецификациям, разработанным ведущим программистом.

Кроме того, к работе бригады может привлекаться для консультации эксперт по языку программирования.

Бригада по контролю качества состоит из ассистентов (рецензентов) по качеству ПО. В ее обязанности входят смотры тех или иных частей ПО или всего ПО в целом с целью поиска возникающих проблем в процессе его разработки. Смотру подлежат все программные компоненты и документы, включаемые в ПО, а также процессы их разработки. В процессе смотра учитываются требования, сформулированные в спецификации качества ПО, в частности, проверяется соответствие исследуемого документа или технологического процесса стандартам, указанным в этой спецификации. В результате смотра формулируются замечания, которые могут фиксироваться письменно или просто передаваться разработчикам устно.

12.3. ПОДБОР КОМАНДЫ

Каждая разработка собирает вокруг себя команду проекта. Эта команда проекта состоит из личностей нескольких типов: конечные пользователи; разработчики; начальник отдела; начальник отдела информационных систем; ответственный за гарантию качества; группа, ответственная за бета-тестирование.

Конечные пользователи осуществляют ввод тестов в систему, которая разрабатывается, обеспечивают обратную связь в проекте интерфейса, проводят бета-тестирование и помогают управлять определением достижения конечной цели.

Разработчики отвечают за исследования, проект и создание программного обеспечения, включая альфа-тестирование своей работы. Один из разработчиков является руководителем команды проекта, регулирующим поток информации между членами команды.

Начальник отдела отвечает за достоверность данных, выдаваемых этим отделом информационной системе. Кроме того, начальник отдела отвечает за то, соответствует ли законченное приложение поставленным в проекте задачам.

Начальник отдела информационных систем определяет цели (планы) для разработчиков, основанные на информации, полученную от менеджеров других отделов и главного управления.

Кроме того, устанавливает приоритеты между проектами и работает в качестве источника информации между отделами и между разработчиками, распределяет объемы ресурсов, требуемых для выполнения каждого проекта.

Ответственным за гарантию качества является один человек, но следят за качеством все члены команды проекта. Ответственный следит, чтобы проект приложения достиг намеченных целей; проект приложения отвечал описанию системы; план тестирования и план преобразования данных отвечали требованиям; стандарты разработки информационных систем соблюдались.

Группа ответственных за бета-тестирование состоит из программистов и возможных конечных пользователей и осуществляет два типа тестирования. Первый тип использует планы специального тестирования, разработанные ответственным за гарантию качества. При втором типе используются тесты, которые разработали сами ответственные за бета-тестирование, применяя критерии ответственного за гарантию качества.

Независимые консультанты обычно концентрируют внимание на стоимости проекта. Часто они не принимают в расчет затраты на проведение системного анализа и разработку проекта и дают неправильную оценку времени реализации данного проекта. Хотя известно, что необходимо выполнить детальный анализ задачи перед тем, как проект будет утвержден, пользователи не склонны затрачивать дополнительные средства на исследование. К сожалению, это часто приводит к большому количеству затруднений в процессе разработки, а иногда к развалу всего проекта.

12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ

Взаимодействие в команде. Ответственность за проект несет разработчик, а не начальник отдела. Начальники являются членами команды — последнее слово в некоторых важных вопросах принадлежит им. Однако на самом деле проектом управляет разработчик. Когда разработчики выполняют "собственный" проект, их интерес в успехе этого проекта и, следовательно, вероятность его успешного выполнения увеличивается в геометрической прогрессии.

Если разработчики полностью изучат типы связей между всеми частями проекта (в отличие от одной его части), их квалификация повысится. Это обеспечивает тип перекрестного обучения в двух очень важных факторах успешной разработки программного обеспечения. Означает ли это, что разработчик выполняет меньше собственно программистской работы? Конечно. Когда разработчику нужна помощь в программировании для конкретного проекта, привлекается отдел информационных систем и сторонних разработчиков, сотрудничающих по контракту.

Все члены команды точно знают свои обязанности. Это достигается с помощью встреч (сессий), на которых обсуждаются отдельные части проекта. В каждый момент времени на определенной стадии проекта все члены команды знают точно, что они должны делать. Это достигается с помощью постановки задач и определения локальных заданий.

Определенная методология разработки программного обеспечения устраняет разногласия и отсутствие связи между членами команды разработчиков и между программистами и конечными пользователями.

Новые люди "безболезненно" подключаются к проекту на любой стадии разработки.

Конечное приложение базируется на фундаментальном анализе задачи, что позволяет свести к минимуму затраты на дальнейшую доработку, модификацию и сопровождение продукта.

В процессе разработки создается мощный пакет документации, позволяющий в дальнейшем упростить неизбежное сопровождение и дополнения программного продукта.

12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ

Получив некоторое представление о необходимости рассмотрения методологии управления проектом, рассмотрим отдельные ее составляющие: предварительный анализ; четкая формулировка цели; составленные модели данных и словари; выходные формы; безопасность системы и данных; платформа и окружение; контингент будущих пользователей.

Предварительный анализ является очень важным этапом. Вы должны быть уверены, что имеете всю необходимую информацию о клиенте, прежде чем возьметесь за реализацию проекта.

Четкая формулировка цели должна отвечать на вопросы: "Что система должна делать?"; "Была ли четко сформулирована цель создания системы?"; "Знает ли конечный пользователь, что система действительно должна делать?" Конечно, очень важно найти истинную цель приложения, чтобы иметь возможность определить границы проекта. Это необходимо сделать настолько быстро, насколько возможно.

Модели данных и словари необходимы для того, чтобы данные, обрабатываемые в приложении, были выделены и определены в понятиях, доступных как конечным пользователям, так и команде разработчиков. Часто случается, что заранее не существует какой-либо сформировавшейся модели данных, и проектировщик должен создать словарь и модель данных, а затем вернуться к пользователю и оговорить с ним разработанную схему, чтобы пользователь понимал ее.

Выходные формы. При предварительном опросе пользователя необходимо сделать наброски всех выходных форм, поскольку может потребоваться дополнительное наращивание словаря для обеспечения реализации того или иного.

Безопасность системы и данных. Прежде чем начать разработку, конечный пользователь должен определить необходимость обеспечения безопасности системы и данных. Включение системы обеспечения безопасности должно рассматриваться на самой ранней стадии проектирования.

Платформа и окружение. Важно оценить окружение, в котором будет работать система. Клиенты тратят большие средства на приобретение аппаратных средств еще до того, как обращаются к вам. Вы должны выяснить все детали: о сетевых аппаратных и программных ресурсах; о типах компьютеров; об операционной системе; о типах принтеров, мониторов, дисководов, других периферийных устройств.

Контингент будущих пользователей. Часто понятие "кто" значительно важнее понятия "что". Хорошее понимание категорий конечных пользователей может дать вам важную стартовую информацию для начала создания проекта. Вы должны постоянно изучать, что хотят ваши конечные пользователи. Различные типы пользовательских групп имеют различные требования, которые должны быть учтены при проектировании программного обеспечения.

Если вы делаете приложения для общего рынка, то можете создать только очень грубое представление о конечном пользователе. Если вы пишите какую-либо общую программу учета, то можете лишь предположить, что мой клиент имеет общее представление о компьютере и у него есть необходимость что-либо учитывать.

Если вы пишите программу поддержки офиса бюро путешествий и экскурсий, то знаете, что конечные пользователи будут использовать данное приложение именно в этой области. Таким образом, вы можете оптимизировать систему учета и расчетов, учитывая конкретную специфику. Однако вы не знаете ни опыта работы конечных пользователей с вычислительной техникой, ни уровня их профессионализма в их собственном бизнесе.

Если вы пишете пользовательское приложение, например офисную систему для офиса "Иванов и сыновья", то можете непосредственно общаться с конечными пользователями и выяснять их уровень познания вычислительной техники и опыт работы в собственном бизнесе, что даст возможность разработчику заранее предусмотреть большинство конфликтных ситуаций между вашим приложением и конечными пользователями.

Что ожидают от вас конечные пользователи?

Каждая группа конечных пользователей имеет различные требования и ожидания от вашей системы. Перед началом проектирования системы необходимо выяснить, на что рассчитывает конечный пользователь. Необходимо обратить внимание на следующие аспекты: начальное обследование и составление технического задания, инсталляция, обучение, поддержка, помощь в эксплуатации.

Резюме. Как проектировщик системы, вы должны вернуться на уровень предварительного анализа задачи и удостовериться, что вся необходимая информация вами получена. При несоблюдении данного требования вы можете значительно замедлить реализацию проекта вследствие многократного повторного обращения к пользователю за уточнением неверно трактованных деталей и необговоренных условий.

12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА

Существует огромная пропасть между идеями пользователей и представлением о возможных способах реализации этих идей конкретными разработчиками. Мостом между этими двумя понятиями должен быть первичный этап обследования проекта и составление технического задания на данный проект. Эта задача делится на три стадии: изучение требований заказчика, уточнение функциональной специфики задачи и техническое проектирование задачи.

Анализ требований и пожеланий заказчика начинается с получения заказа на новую разработку (или на модификацию существующей) и заканчивается составлением документа, в деталях описывающего данную разработку. Это должен быть интерактивный процесс, в результате которого появляется документ, полностью описывающий задачу и удовлетворяющий обе стороны, включающий рассмотрение всех проблем и решаемых задач, множество листов с требованиями и пожеланиями заказчика и прочую необходимую информацию.

Наиболее важная цель, которой необходимо достигнуть на этом первом этапе, — это найти и понять, что же НА САМОМ ДЕЛЕ ХОЧЕТ ПОЛЬЗОВАТЕЛЬ. Иной раз сделать это не так просто, поскольку пользователь не всегда точно представляет, ЧТО он действительно хочет получить. Банальным примером могут служить пользователи, заказывающие, например, одновременно несколько больших задач типа "Учет заработной платы", "Ведение складского учета", "Составление табеля" и т. п., называя все это "Бухгалтерией". Если проигнорировать данный этап, то проект может в конце концов быть осужден на большое количество доработок, достраивание кода "на коленке" и непременное сидение программистов по выходным, чтобы сделать клиенту действительно то, что он хочет и что не было оговорено заранее.

Очевидно, что любой проект начинается с идеи. Как только появляется идея, один или несколько человек начинают ее развивать. Эти люди — заказчики или потенциальные пользователи. Они определяют начальные требования и принимают решение о создании того или иного программного продукта. Таким образом, необходимо выяснить, что же эти люди хотят получить от программного продукта.

Перед началом обсуждения будущего проекта очень важно убедиться, что с обеих сторон стола переговоров сидят именно те люди, которые требуются для совместного обсуждения проекта. Три наиболее распространенные ошибки допускаются на данном этапе.

Ошибка 1. Пользователи, начинающие обсуждение проекта, не являются людьми, которые будут принимать окончательное решение о требованиях к обсуждаемой системе (т. е. они не являются людьми, имеющими полное представление об описываемой ими задаче).

Ошибка 2. Участники обсуждения со стороны разработчиков не являются людьми, имеющими отношение к технической разработке проекта.

Ошибка 3. Технические специалисты не понимают пользователей (или не прилагают усилий к пониманию), либо разработчики плохо разбираются в делопроизводстве и бизнесе, либо они последнюю часть жизни провели не отходя от монитора и могут разговаривать только на языке битов и байтов.

В первом случае пользователи, участвующие в обсуждении проекта, описывают все, с их точки зрения, детали предстоящей задачи и остаются удовлетворенными мыслью, что они точно изложили все требования и пожелания к задаче. К сожалению, если пользователи, участвовавшие в обсуждении, не являются конечными пользователями данной системы, то после составления конечного документа, который в деталях описывает решаемую задачу, у людей, подписывающих данный документ, возникают вопросы и какие-либо новые предложения по усовершенствованию отдельных деталей или их изменению. Эта ситуация возникает в большинстве подобных случаев. Такая ситуация отбрасывает процесс разработки приложения на стадию анализа предстоящего проекта. Налицо потеря времени и средств.

Аналогичная проблема возникает при участии в составлении проекта людей, которые никогда не будут использовать создаваемую программу. Это общая проблема проектирования программного обеспечения. Когда весь проект разработан, реализован, оттестирован и представлен заказчику, конечные пользователи, те, кто действительно будет использовать созданное приложение, выясняют, что оно, скорее, помеха, нежели помощь в их работе.

Третья из описанных выше проблем заключается в том, что пользователи, предъявившие минимальные требования к системе на стадии системного проектирования и оставившие разработку проекта на рассмотрение производителя, начинают возмущаться, что продукт не удовлетворяет тем или иным требованиям, а поэтому работает некорректно и требует переделки.

Еще одной распространенной ошибкой является выбор руководителя проекта, не обладающего соответствующими техническими знаниями для реализации данного проекта. Эта проблема обычно встречается при разработке крупных проектов, где необходима большая команда программистов. Часто существует технический лидер, который может управлять проектом так же хорошо, как и решать технические вопросы. Использование его в качестве менеджера проекта более предпочтительно, нежели использование простого администратора.

В процессе анализа требований заказчика важно, чтобы в переговорах участвовал один из членов команды разработчиков, а в лучшем случае, ведущий технический специалист или технический руководитель проекта. К сожалению, достаточно тяжело собрать в одной комнате и в одно время всех людей, которым необходимо принимать участие в обсуждении проекта.

Если в процессе обсуждения участвует только административное лицо либо руководитель проекта, далекий от проблем непосредственного кодирования, то возникает множество проблем и вопросов, связанных с возможной оптимизацией отдельных операций, созданием словаря баз данных, системными требованиями к создаваемому программному обеспечению и т. д. В данном случае отдельным членам приходится повторно общаться с конечными пользователями для выяснения неучтенных или плохо продуманных вопросов, что в конце концов может испортить отношения между командой разработчиков и конечными пользователями. С другой стороны, участие в обсуждении проекта технических специалистов может привести к заметному упрощению проекта за счет приведения отдельных требований пользователя к уже существующим и ранее разработанным технологиям удовлетворения данных требований. Когда необходимый технический персонал просто не может присутствовать на всех заседаниях обсуждения проекта или технический специалист должен временно переключиться на другие действия в процессе обсуждения, может помочь так называемый протокол заседаний. Данный протокол содержит заметки обо всех обсуждаемых на данном заседании вопросах, а также имена, должности и телефоны участников обсуждения как с одной, так и с другой стороны. Данный протокол также должен содержать информацию о принятых решениях, оговоренных нюансах и любых деталях, обсуждение которых уже производилось. В конце концов данные заметки должны перерасти в конечный документ, описывающий результат, полученный в процессе обсуждения всех частей и деталей проекта.

Если указанные рекомендации будут соблюдены, то техническая сторона разработки будет рассмотрена более полно, что даст возможность впоследствии избежать многих ошибок, связанных с непониманием той или иной стороной технических особенностей проекта.

Избегайте программистов, которые могут просидеть несколько суток над созданием функции, которая фактически не нужна конечному пользователю. Программисты, которые не умеют работать с пользователями, не понимают вопросов, связанных со спецификой работы конечного пользователя, или не умеющие изложить более или менее сложные технические вопросы на простом русском языке, не должны участвовать в процессе обсуждения проекта. Они могут создать дополнительные трудности технического и временного характера, начиная детально выяснять несущественные вопросы.

К сожалению, многие программисты не очень хорошо разбираются в окружающем их деловом мире. Их специализация — компьютеры и программы, а не создание кинофильмов или управление госпитальным хозяйством. Возникает вопрос: "Действительно ли необходимо команде разработчиков детально разбираться в делопроизводстве и специфике бизнеса конечных пользователей?" Неопытный программист подумает: "Пользователи — профессионалы в своей области, я — профессионал в своей; если мы начнем обучать друг друга нашим профессиям, понадобимся ли мы друг другу в конце концов?"

Неверно. Профессиональные знания в той или иной области не приобретаются в процессе совместного обсуждения какого-либо проекта. Не приобретаются они и в процессе написания программы по заданной тематике. Профессиональные знания часто приобретаются в процессе многих лет обучения, следующих за не менее длительным периодом проб и ошибок.

Когда пользователи пытаются описать, что они хотят от отдельных частей программы, не надо сразу переводить их пожелания в код. Необходимо понять, что хочет пользователь, а затем постараться сделать это наиболее оптимальным способом.

Оптимальный вариант, когда пользователь имеет представление о технической стороне обсуждаемой задачи, а команда программистов имеет опыт в сфере деятельности пользователя. Когда сочетаются такие качества пользователя и разработчика, примерно половина вопросов сразу снимается с обсуждения за ненадобностью.

12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

Одно подключение к процессу разработки требуемых лиц с обеих сторон не приведет к созданию полноценного документа, описывающего задачу. Важно сохранить простоту процесса анализа требований и избегать обдумывания, как будет реализована та или иная функция или процедура. Необходимо помнить, что анализ требований заказчика может продлиться от двух часов до нескольких недель, в зависимости от сложности поставленной задачи.

Может существовать большое количество способов начать и проводить анализ требований, но все они должны приводить к одному и тому же результату — составлению документа, описывающего все требования и пожелания пользователя.

Простейший способ — начать обследование сверху вниз. Что является главной целью системы? Определение основных компонент системы может быть полезным для введения пользователя в нужное русло обсуждения проблемы. Почти все системы требуют ввода некоей информации и вывода каких-то отчетных форм (в виде отчетов и запросов), некоторого вида конфигурации, возможности импорта и экспорта данных, архивирования и, возможно, сервисный раздел. Исходя из этих данных, можете получить информацию о том, что должно находиться в главном меню программы, и обдумать некоторые детали разработки еще до полного определения проекта.

Независимо от принятого подхода к рассмотрению требований пользователя результатом анализа должно быть ясное понимание того, что требует пользователь и что он хочет. Тонкое различие между этими двумя понятиями немаловажно. Требования пользователя ограничиваются его представлением о предлагаемой им задаче. Эти требования пользователь явно обговаривает в процессе дискуссии. Пожелания же пользователя нередко остаются за кадром не потому, что пользователь не обговаривает их специально, а потому, что он подсознательно считает некоторые требования естественными и не требующими специального выделения.

Главная цель этого этапа — удостовериться в том, что вы понимаете потребности пользователя и приоритеты направлений разработки.

Далее следует функциональная спецификация — это мост между начальным обзором требований и технической спецификацией, разрабатываемой позже. Документ должен состоять из логических разделов типа краткого обзора системы, сопровождаемого кратким описанием главных фрагментов или функциональных объектов. Демонстрация планируемых экранных форм должна показывать основные направления действий с главными функциональными объектами и модулями программы. Раздел описания отчетов должен содержать все отчетные формы, которые вы планируете создавать. В больших системах основные модули могут быть разбиты на более простые с описанием того, что эти, более простые модули, будут делать.

Планируйте данный документ таким образом, чтобы пользователь, который не заинтересован в рассмотрении детальных особенностей системы, мог бы прочитать только первую часть документа с описанием основных функций, выполняемых системой. Пользователи, заинтересованные в рассмотрении более подробных деталей, могут продолжать читать документ дальше.

12.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ

Ваши спецификации должны отвечать всем требованиям пользователей. Убедитесь, обратившись опять к начальному анализу перед завершением спецификации, что учтены все требования и запросы пользователей. Если требование пользователя не может быть удовлетворено, объясните, почему, а не просто исключите его из спецификации.

Вы также должны обсудить с пользователем ограниченные ресурсы, которые имеются у пользователя. Девяносто девять процентов проблем, возникающих при программировании, могут быть решены путем использования специфических внешних устройств, драйверов и сторонних программ.

Предположим, функциональная спецификация разработана, подписана и положена на полку. Но она может оказаться полностью бесполезной по ряду причин. При неправильном отношении к разработке функциональной спецификации она может быть плохо написана, плохо организована или, что наиболее вероятно, обременена томами описания ненужных технических подробностей. Говоря другими словами, работать с таким документом будет невозможно.

Одной из наиболее опасных болезней разработки программ является синдром "ползущего проекта", или "оползня". Он проявляется, когда функциональная спецификация неполно рассматривает отдельные аспекты проекта. В этом случае, по мере создания системы, пользователи, рассматривая отдельные готовые модули, будут просить внести некоторые усовершенствования, ссылаясь на неясные описания данного модуля в функциональной спецификации. Постепенно система будет приобретать вид огромного динозавра в заплатках, поскольку глобальные изменения разработанных структур программы производить уже нельзя, а изменения и усовершенствования необходимо вносить. Это может привести к перерасходу временного лимита на создание отдельных модулей и нестабильности работы системы из-за выпадания отдельных функциональных кусков программы из строгой общей схемы всей системы.

Быстрое макетирование — метод проектирования, разработки и изменения интерфейсов пользователя "на лету". Конечные пользователи должны активно включаться в данный процесс, поскольку разработка интерфейса вместе с пользователем происходит значительно быстрее, нежели без него. Совместная разработка дает возможность "подогнать" интерфейс под пользователя за несколько коротких сессий. Для этого существуют специальные средства, в частности CASE-средства. С мощными CASE-средствами процесс разработки приложений заметно упрощается. Проектировщик использует программные средства для создания и компоновки словарей данных, потоков данных и диаграмм объектов, а в некоторых случаях прототипов процессов обработки данных и функционального кода.

Однако использование CASE-средств разработки приложений не очень распространено в сфере разработки промышленных приложений. Это происходит по двум причинам. Во-первых, это ограниченность возможностей CASE-систем. Во-вторых, если CASE-система достаточно мощна и многофункциональна, то она требует больших временных затрат на ее освоение.

В конце данного этапа, если была написана хорошая, легко понимаемая, неперегруженная и непустая функциональная спецификация, системный аналитик или техническая группа сможет перейти к следующему этапу — созданию технической спецификации, — основываясь на информации, полученной на всех предыдущих этапах.

12.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

Техническое проектирование — это мост между функциональной спецификацией и фактической стадией кодирования. Часто команда разработчиков пытается сократить и объединить стадию разработки функциональной спецификации и техническое проектирование и разработать один документ. Это ошибка.

Во-первых, пользователь будет читать документ с большим количеством непонятных ему технических подробностей. В данном случае пользователь отбросит ваш документ, что может привести к недостаточной законченности упомянутого документа.

Во-вторых, если функциональная спецификация концентрирует внимание на требованиях и пожеланиях пользователя, то техническое проектирование должно ориентироваться на создание методов реализации данных требований. Только после того как обе эти фазы завершены и акценты расставлены, программист может приступать к непосредственному кодированию.

Когда обе эти стадии объединены, разработчик не может сконцентрироваться на каком-либо одном направлении мышления и в результате этого получается неясный и плохо отработанный документ. Или, что еще хуже, программист начинает реализовывать идею, которая еще не определена до конца пользователем.

Среда разработки позволяет всем членам команды знать размещение всех файлов проекта, библиотек, документов и другой связанной с проектом информации. Она должна быть создана таким образом, чтобы все члены команды разработчиков с минимальными затратами времени могли обратиться к любой информации, относящейся к проекту.

Создание временной диаграммы проекта является важнейшим этапом работ, на котором необходимо составить детальное расписание сроков начала и окончания разработки каждого модуля, частей проекта и всего проекта в целом. Необходимо учитывать время, затрачиваемое на дополнительные контакты с заказчиком, разработку специфических инструментальных средств, а также возможные проблемы, связанные с непредвиденными обстоятельствами (например, болезнь сотрудника или частичная потеря данных вследствие сбоев аппаратного обеспечения).

12.10. РЕАЛИЗАЦИЯ

Обычно на этапе кодирования всплывают все неприятные проблемы, которые только можно себе представить. Чем больше проект, тем больше проблем. Вот почему первые три шага так важны.

Если все из вышеописанных шагов полностью пройдены, то реализация программы значительно упрощается. В идеале все потенциальные узлы и ловушки должны быть предусмотрены и обойдены. Техническая спецификация может и должна быть передана команде программистов, выполняющих непосредственное кодирование, чтобы они могли записывать код, согласно детализированному проекту задачи. Любые проблемы, возникающие на этом этапе, должны отслеживаться программистами и помещаться в относящиеся к проблеме документы, чтобы отражать все возникающие изменения.

Обзор кода делается программистами — кодировщиками программ на специальной сессии (встрече). Как и на этапе обзора проекта, при обзоре кода "отлавливается" большое количество неточностей и ошибок, выявляются неоптимальные участки программы. Обзор кода позволяет также увидеть различным членам группы разработчиков фактический код, выполненный коллегами по проекту. Поскольку программирование является творческим процессом, то каждый член команды представляет видение одной и той же проблемы по-разному. Кто-то решает данный конкретный вопрос лучше, кто-то хуже. Обзор кода позволяет выявить хуже написанные участки программы и при необходимости переписать их, воспользовавшись советом более опытного члена команды. Также рассмотрение различных приемов, технологий и подходов к программированию позволяет воспользоваться ими для решения предстоящих проблем в последующих проектах. Особенно это полезно для новичков команды, хотя, как известно, "даже старую собаку можно научить новым трюкам".

12.11. СИСТЕМНОЕ ТЕСТИРОВАНИЕ

Стадия тестирования системы начинается, после того как большинство модулей системы уже завершены. Тестирование может состоять из трех отдельных фаз:

— системный тест, или лабораторные испытания;

— опытная эксплуатация;

— приемочный тест.

Альфа-тест (лабораторные испытания). Данная фаза тестирования преследует две цели. Во-первых, этот тест должен подтвердить, что все фрагменты правильно интегрированы в систему. Это позволяет группе тестирования начать полное тестирование всей системы. Обычно используется некоторая однородная технология тестирования для всех компонент системы, позволяющая определить соответствие всех частей определенным, заранее предусмотренным параметрам. Один из путей создания сценариев тестирования — создавать методы тестирования в процессе непосредственного кодирования.

Лабораторное тестирование — последняя возможность разработчиков исправить все обнаруженные ошибки, прежде чем система будет передана конечным пользователям. Бета-тестирование — не та стадия, на которой программисты хотели бы выявлять серьезные сбои разработанной системы, поэтому лабораторное тестирование должно проходить максимально полно. Если альфа-тестирование проведено некачественно, общий процесс тестирования может занять продолжительное время, так как исправление ошибок, выявленных на последующих стадиях тестирования, занимает значительно больше времени из-за невозможности исправления их "на лету". Любые обнаруженные проблемы должны протоколироваться, чтобы хронология проблем и их устранения была доступна при возникновении последующих вопросов о ранее существовавших проблемах.

Желательно, чтобы программное обеспечение не передавалось для опытной эксплуатации, пока все известные проблемы не будут решены. В действительности программное обеспечение часто выпускается для бета-тестирования с уже найденными, но еще не разрешенными проблемами в связи с нехваткой времени и окончанием сроков разработки проекта. Данное упущение приводит к значительным непредвиденным задержкам, связанным с трудностью последующего тестирования из-за наличия каких-либо ошибок или неточностей.

Бета-тестирование — это следующая фаза общего тестирования, при которой программное обеспечение поставляется ограниченному кругу конечных пользователей для более жесткого тестирования. Хорошо известно, что пользователи иногда используют программное обеспечение не совсем для тех целей, для которых оно предназначалось. Поэтому они часто могут находить ошибки в тех местах программы, над которыми в течение данного времени проводились лабораторные испытания, не нашедшие никаких нарушений. Это необходимо ожидать и не отрицать возможности возврата к предыдущей фазе — лабораторному тестированию. В данных случаях часто помогают протоколы обнаруженных и фиксированных ошибок.

12.12. ПРИЕМОЧНЫЙ ТЕСТ

Приемочный тест. Приемочный тест становится простой формальностью, если предыдущие стадии тестирования успешно завершены. Используя информацию о том, что все обнаруженные ошибки уже исправлены, приемочный тест просто подтверждает, что никаких новых проблем не обнаружено и программное обеспечение готово для выпуска. Очевидно, что чем больше существует реальных или потенциальных пользователей вашего продукта, тем более важным является приемочный тест. Когда производится промышленное тиражирование и рассылка более трех сотен тысяч дисков, хочется вдвойне удостовериться, что программа написана без ошибок и все явные и неявные проблемы были решены. Конечно, если предыдущие стадии не прошли успешно, то приемочный тест является единственной возможностью предотвратить затраты на изменение и дополнение поставляемого продукта.

12.13. ПОСЛЕРЕАЛИЗАЦИОННЫЙ ОБЗОР

Данный этап — наилучшая возможность осуществить обзор созданного программного обеспечения, прежде чем будет начат новый проект. Типичные вопросы, возникающие после сдачи программного проекта пользователю-заказчику:

• Что мы делали правильно?

• Что мы делали неправильно?

• Какие этапы были наиболее полезными, а какие ненужными?

• Отсутствовало ли что-нибудь на каком-либо этапе разработки, что бы помогло усовершенствовать программный продукт?

12.14. СОПРОВОЖДЕНИЕ ПРОГРАММ

Сопровождение программ — "ложка дегтя" для каждого программиста. Это всегда помеха при начале разработки какого-либо нового проекта, заставляющая отвлекаться от разработки проекта и возвращаться к старым программам и старым проблемам. Ничто не делает сопровождение настолько непривлекательным, как плохо документированный код, недостаточно полное начальное проектирование и отсутствие внешней документации.

Если большинство шагов разработки выполнено правильно, то сопровождение не будет вызывать серьезных проблем, а будет элементарной технической поддержкой и модификацией программного обеспечения.

ВЫВОДЫ

• Разработка программных систем — сложное мероприятие. Можно выделить следующие общие процессы по управлению разработкой ПО: составление плана-проспекта по разработке ПО — планирование и составление расписаний по разработке ПО; управление издержками по разработке ПО; текущий контроль и документирование деятельности коллектива по разработке ПО; подбор и оценка персонала коллектива разработчиков ПО.

• Обычно в организации одновременно разрабатывается несколько программных проектов. Для оптимального качества и скорости работы необходимо верно структурировать управление организацией.

• Каждая разработка проекта собирает вокруг себя команду специалистов (команду проекта), состоящую из конечного пользователя; разработчиков; начальника отдела; начальника отдела информационных систем; ответственного за гарантию качества; группы, ответственной за бета-тестирование.

• Необходимо соблюдать методологию управления проектом, которая делится на составляющие: предварительный анализ; четкую формулировку цели; составленные модели данных и словари; выходные формы; безопасность системы и данных; платформу и окружение; контингент будущих пользователей.

• Разница между понятиями "желание заказчика" и "конечный продукт" обычно очень велика. Мостом для их соединения должен быть первичный этап обследования проекта и составление технического задания на данный проект. Эта задача делится на три стадии: изучение требований заказчика, уточнение функциональной специфики задачи и техническое проектирование задачи. Если говорить о требованиях пользователя, то их необходимо соблюдать неукоснительно.

• Техническое проектирование — своего рода мост между функциональной спецификацией и фактической стадией кодирования. Это крайне важная стадия и халатно к ней относиться нельзя.

• Системное тестирование может состоять из трех отдельных фаз: системный тест или лабораторные испытания; опытная эксплуатация; приемочный тест.

• Сопровождение — нелюбимая программистами, но необходимая часть, дающая возможность для усовершенствования продукта.

Контрольные вопросы

1. Что такое программный проект?

2. Что включает в себя составление плана-проспекта по разработке ПО?

3. Назовите основные источники издержек при разработке ПО.

4. Перечислите обязанности членов ядра бригады программистов.

5. Чем занимаются независимые консультанты?

6. Назовите составляющие методологии разработки.

7. В чем состоит анализ требований и пожеланий заказчика?

8. Что такое быстрое макетирование?

9. В чем заключается техническое проектирование?

10. Назовите три фазы системного тестирования. И. Зачем нужен приемочный тест?

12. Назовите фактор, усложняющий сопровождение в наибольшей степени.

Приложение 1

СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102-77

Данный текст не заменяет сам стандарт, который может измениться, и приводится здесь лишь для пояснения порядка работы с этим и другими стандартами.

Таблица 1

Стадии разработки, этапы и содержание работ

Стадии разработки

Этапы работ

Содержание работ

1. Техническое задание

Обоснование необходимости разработки программы

Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ.

Научно-исследовательские работы

Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи.

Разработка и утверждение технического задания

Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания.

2. Эскизный проект

Разработка эскизного проекта

Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования.

Утверждение эскизного проекта

Разработка пояснительной записки. Согласование и утверждение эскизного проекта.

3. Технический проект

Разработка технического проекта

Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств.

Утверждение технического проекта

Разработка пояснительной записки. Согласование и утверждение эскизного проекта.

4. Рабочий проект

Разработка программы

Программирование и отладка программы

Разработка программной документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77

Испытания программы

Разработка, согласование и утверждение порядка и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний.

5. Внедрение

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ.

Примечания:

1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях — вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.

2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

Приложение 2

ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОГО ТЕХНИЧЕСКОГО ЗАДАНИЯ

1. ВВЕДЕНИЕ

1.1. Наименование программного изделия

Полное наименование программы — "Простейший редактор текстовых файлов MS DOS". Краткое наименование программы — редактор.

1.2. Область применения

Редактор предназначен для корректировки уже имеющихся и создания новых текстовых файлов в диалоговом режиме работы. Редактор может применяться для работы с короткими текстовыми файлами MS DOS при написании исходных текстов программ.

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

2.1. Документ, на основании которого ведется разработка

Разработка ведется на основании задания на курсовое проектирование по дисциплине "Технология программирования".

2.2. Организация, утвердившая этот документ, и дата его утверждения

Задание утверждено на заседании кафедры САПР и ПК 04.01.98 и выдано преподавателем кафедры Петровым В.В.

2.3. Наименование темы разработки Наименование темы разработки — EDIT.

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

Разработка является аттестационной при подготовке бакалавра.

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Требования к функциональным характеристикам

4.1.1. Состав выполняемых функций

4.1.1.1. Редактор должен обеспечить корректировку уже имеющихся на диске и создание новых текстовых файлов MS DOS в диалоговом режиме работы.

4.1.1.2. Внешний вид программы должен соответствовать макетам экранов и сценарию работы, представленным в ПРИЛОЖЕНИИ 1.

4.1.1.3. Список управляющих клавиш программы редактора и кодов символов, заносимых в текстовый файл, должен соответствовать ПРИЛОЖЕНИЮ 2.

4.1.1.4. При запуске редактора командой MS DOS EDIT.EXE с указанием через символ пробела имени редактируемого файла программа редактора должна обеспечить загрузку редактируемого файла. Программа редактора должна запускаться командой MS DOS EDIT.EXE и без указания имени редактируемого файла.

4.1.1.5. В любой момент работы программы при нажатии клавиши <F1> должны выводиться тексты помощи со списком всех возможных команд редактора на данный момент.

4.1.1.6. Программа должна обеспечить вывод на принтер содержимого текстового файла стандартными символами принтера с числом строк на странице, заданным пользователем.

4.1.2. Организация входных и выходных данных

Организация входных и выходных файлов редактора должна соответствовать Приложению 3. Размер редактируемого файла не должен превышать 64 Кбайт. Число символов в строке не должно превышать 255.

В процессе работы редактора входной информацией для программы должны являться коды клавиш, нажимаемых пользователем на клавиатуре ЭВМ, согласно режимов, определяемых выходной экранной информацией.

4.1.3. Временные характеристики и размер занимаемой памяти

Время реакции программы на нажатие любой из клавиш не должно превышать 0,25 с, за исключением реакций на чтение и запись входных и выходных файлов. Объем занимаемой оперативной памяти не должен превышать 200 Кбайт.

4.2. Требования к надежности

4.2.1. Требования к надежному функционированию

Программа должна нормально функционировать при бесперебойной работе ЭВМ. При возникновении сбоя в работе аппаратуры восстановление нормальной работы программы должно производиться после:

1) перезагрузки операционной системы;

2) запуска исполняемого файла программы; повторного выполнения действий, потерянных до последнего сохранения информации в файл на магнитном диске.

Уровень надежности программы должен соответствовать технологии программирования, предусматривающей:

1) инспекцию исходных текстов программы;

2) автономное тестирование модулей (методов) программы;

3) тестирование сопряжений модулей (методов) программы;

4) комплексное тестирование программы.

4.2.2. Контроль входной и выходной информации

Программа должна контролировать выбор пользователем пункта меню "Выход" и предупреждать его о потере "несохраненных изменений".

4.2.3. Время восстановления после отказа

Время восстановления после отказа должно состоять из:

1) времени перезапуска пользователем операционной системы;

2) времени запуска пользователем исполняемого файла программы;

3) времени повторного ввода потерянных данных.

4.3. Условия эксплуатации

Программа должна храниться в виде двух маркированных дискетных копий — эталонной и рабочей. Периодическая перезапись информации должна осуществляться согласно нанесенной маркировке. Условия хранения дискет должны соответствовать нанесенной на них маркировке.

4.4. Требования к составу и параметрам технических средств

Программа должна корректно работать на следующем или совместимом с ним оборудовании:

1) ПЭВМ IBM PC модели 300 GL;

2) принтере Epson Stylus 800+ модели Р780В.

4.5. Требования к информационной и программной совместимости

4.5.1. Требования к информационным структурам на входе и выходе

Требования к информационным структурам на входе и выходе определены в пункте (см. п. 4.1.2.).

4.5.3. Требования к методам решения

Требования к методам решения определены в подпункте (см. пп. 4.1.1.2). Внутренний буфер редактора должен помещать самый длинный редактируемый файл целиком. Выбор остальных методов решения осуществляется разработчиком без согласования с заказчиком.

4.5.4. Требования к языкам программирования

Язык программирования должен выбираться разработчиком без согласования с заказчиком.

4.5.5. Требования к программным средствам, используемым программой

Для работы программы необходима операционная система MS DOS версии 6.22.

4.6. Требования к маркировке и упаковке

Дискеты с эталонным и рабочими экземплярами программы должны иметь маркировку, состоящую из надписи EDIT, надписи "эталон" или "рабочая", даты последней перезаписи программы. Упаковка должна соответствовать условиям хранения дискеты. На упаковке должны быть указаны условия транспортирования и хранения дискеты.

4.7. Требования к транспортированию и хранению

Условия транспортирования и хранения дискеты должны соответствовать подразделу (см. подраздел 4.6.).

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

Состав программной документации должен включать следующие документы:

1) технический проект программы по ГОСТ 19.404—79 в машинописном исполнении;

2) описание программы по ГОСТ 19.402—78 на машинном носителе;

3) текст программы по ГОСТ 19.401—78 на машинном носителе;

4) руководство программиста по ГОСТ 19.504—79 на машинном носителе в виде файла README.TXT.

Пояснительная записка "технический проект программы" должна содержать следующие разделы:

1) Раздел "ВХОДНЫЕ ДАННЫЕ" (Характер, организация и предварительная подготовка входных данных);

2) Раздел "ВЫХОДНЫЕ ДАННЫЕ" (Характер и организация выходных данных);

3) Раздел "ОПИСАНИЕ ЛОГИЧЕСКОЙ СТРУКТУРЫ";

4) Раздел "ИСПОЛЬЗУЕМЫЕ ТЕХНИЧЕСКИЕ СРЕДСТВА" (Типы ЭВМ, на которых возможно выполнение программы; устройства ЭВМ, используемые при выполнении программы);

5) Раздел "ВЫЗОВ И ЗАГРУЗКА" (Виды носителей программы, их используемый объем; способы вызова программы с соответствующих носителей данных; входные точки в программу — запуск программы);

6) Раздел "ПЛАН МЕРОПРИЯТИЙ ПО РАЗРАБОТКЕ И ВНЕДРЕНИЮ ПРОГРАММЫ" (План мероприятий разрабатывается для реализации программы коллективом программистов — два человека. Планом должны быть предусмотрены контрольные временные точки реализации, например, через каждые десять дней или неделю, в течение которых происходит интеграция разработанных модулей и тестирование уже разработанной части программы. Приводится состав тестов и принципы их подготовки для тестирования уже созданного фрагмента программы для каждой из контрольных точек).

Раздел "ОПИСАНИЕ ЛОГИЧЕСКОЙ СТРУКТУРЫ" при технологии структурного программирования должен включать следующие материалы:

1) описание связей программы с другими программами;

2) описание внутренних массивов и переменных, которые используются в межмодульном обмене данными;

3) схема иерархии программы (приводится рисунок или рисунки);

4) расшифровка наименований модулей (приводится таблица с перечнем наименований модулей в алфавитном порядке с указанием выполняемой каждым модулем функции);

5) описание функционирования программы с учетом ее модульного деления (приводится словесное описание выполнения программы с учетом вызовов модулей);

6) описание модулей программы (подраздел заполняется на основе паспортов модулей).

6. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ

Технико-экономические показатели должны определяться заказчиком без участия исполнителя.

7. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ

Разработка программы должна выполняться по следующим этапам:

1) разработка, согласование и утверждение технического проекта программы с пояснительной запиской — 5 недель;

2) разработка рабочего проекта программы с комплексным тестированием — 6 недель;

3) приемка-сдача с исправлением обнаруженных недостатков в программе и программной документации — 2 недели;

4) внедрение.

8. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

8.1. Виды испытаний

Испытания программы и верификация документации должны проводиться в организации заказчика с привлечением сторонних экспертов. Проверочные тесты должны готовиться заказчиком.

8.2. Общие требования к приемке

Приемка программы должна осуществляться заказчиком. Программа должна считаться годной, если она удовлетворяет всем пунктам данного технического задания.

Приложение 3

ФОНД ЭВРИСТИЧЕСКИХ ПРИЕМОВ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1. ВЫБОР СТРАТЕГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1. Заменить восходящий способ проектирования программ нисходящим.

1.2. Инверсия приема.

1.3. Использовать комбинированный (восходяще-нисходящий) способ проектирования. В данном случае главная часть программы разрабатывается нисходящим способом, а отдельные модули и подсистемы — восходящим.

1.4. Использовать способ проектирования методом расширения ядра системы. В данном случае вначале создается оболочка, реализующая минимальный набор функций проектируемой системы, затем к данной оболочке (ядру) системы последовательно добавляются новые модули, расширяющие набор реализуемых функций.

2. ВЫБОР ПОДХОДА В ПРОГРАММИРОВАНИИ (методологии проектирования)

2.1. Заменить методологию, ориентированную на обработку (модульное программирование; функциональная декомпозиция; проектирование с использованием потока данных; структурное проектирование; технология структурного анализа проекта SADT; проектирование, основанное на использовании структур данных; методология Джексона; методология Уорнера и др.), на методологию, ориентированную на данные (абстракции данных Дейкстры, объектно-ориентированная методология; методология, ориентированная на проектирование концептуальных баз данных и др.).

2.2. Инверсия приема.

3. ВЫБОР ЯЗЫКА

3.1. Выбрать более "любимый" язык программирования.

3.2. Выбрать язык программирования, специально предназначенный для решения конкретной проблемы.

3.3. Заменить проблемно-ориентированный язык на объектно-ориентированный.

3.4. Инверсия приема.

3.5. Заменить язык высокого уровня языком низкого уровня.

3.6. Инверсия приема.

3.7. Использовать в проекте два и более языков программирования.

3.8. Подключать объектный код (откомпилированный с помощью компилятора другого языка программирования или ассемблер) с помощью директивы компилятора.

3.9. Использовать встроенный ассемблер системы программирования.

4. ПРЕОБРАЗОВАНИЕ АРХИТЕКТУРЫ, ИЛИ СТРУКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

4.1. Увеличить число модулей системы.

4.2. Инверсия приема.

4.3. Заменить глобальную переменную фактическим параметром, передаваемым модулю в качестве аргумента. Данным приемом исключается возможность непредвиденных изменений глобальных переменных.

4.4. Инверсия приема.

4.5. Заменить глобальные переменные локальными переменными.

4.6. Инверсия приема.

4.7. Произвести декомпозицию модуля на несколько. Данный прием позволяет распределить выполняемые функции между отдельными функциями.

4.8. Объединить несколько модулей в один. Данный прием дает возможность сэкономить время на производство вычислений; дает особый эффект, когда позволяет исключить дублирование одних и тех же процессов в разных модулях.

4.9. Оформить модули, связанные между собой единой логикой, в библиотеку.

4.10. Использовать в проектировании системы стандартные модули системы программирования.

4.11. Использовать библиотечные модули, разработанные другими программистами.

5. ПРЕОБРАЗОВАНИЕ СТРУКТУРЫ МОДУЛЯ

5.1. Заменить линейную структуру команд циклической. (Повышает компактность кода программы.)

5.2. Инверсия приема.

5.3. Заменить ветвящуюся структуру циклической.

5.4. Инверсия приема.

5.5. Заменить ветвящуюся структуру if — then — else вариантом оператора case.

5.6. Заменить ветвящуюся структуру case цепочкой операторов if — then.

5.7. Инверсия приема.

5.8. Заменить цикл repeat — until циклом while.

5.9. Инверсия приема.

5.10. Заменить цикл repeat— until циклом for.

5.11. Инверсия приема.

5.12. Заменить цикл while циклом for.

5.13. Инверсия приема.

5.14. Выделить тело цикла в отдельную подпрограмму. Данный прием повышает читабельность программы, но его следует использовать только тогда, когда это не нарушает внутренней логики цикла.

5.15. Использовать рекурсию.

5.16. Заменить подпрограмму-процедуру подпрограммой-функцией. Данный прием позволяет получить дополнительный параметр, выдаваемый подпрограммой (например, код ошибки).

5.17. Инверсия приема. Позволяет избежать резервирования места под переменную, воспринимающую значение подпрограммы-функции.

5.18. Полностью исключить или минимизировать использование оператора goto. Улучшает структуру программы, ее читабельность и логику.

5.19. Использовать оператор goto для быстрой передачи управления. Позволяет быстро без привлечения дополнительных средств передавать управление другому процессу. Следует применять только в тех случаях, когда переход является наиболее лаконичным, простым и ясным средством.

5.20. Использовать процедуру exit для выхода из подпрограммы. Позволяет обходиться без оператора goto и без усложнения логики подпрограммы.

5.21. Использовать директиву компилятора для безболезненного использования процедур в качестве функций и функций в качестве процедур.

5.22. Использовать процедурный тип данных.

5.23. Использовать указатели на процедуры и функции.

5.24. Увеличить размерность массива.

5.25. Инверсия приема.

5.26. Использовать тип данных множество set вместо массивов.

5.27. Инверсия приема.

5.28. Замена записи фиксированной длины записью с вариантом.

5.29. Инверсия приема.

5.30. Заменить обычные строки (тип String) строками с нулевым окончанием.

5.31. Инверсия приема.

5.32. Использовать оператор with для упрощения работы с записями.

5.33. Использовать преобразование типов данных.

5.34. Использовать типизированные константы.

5.35. Давать переменным, константам и типам данных содержательные обозначения.

5.36. Широко использовать комментарии для пояснения вычислительных алгоритмов.

6. ОРГАНИЗАЦИЯ И ХРАНЕНИЕ ДАННЫХ

6.1. Заменить типизированный файл нетипизированным файлом.

6.2. Инверсия приема.

6.3. Заменить типизированный файл текстовым файлом.

6.4. Инверсия приема.

6.5. Заменить нетипизированный файл текстовым файлом.

6.6. Инверсия приема.

6.7. Заменить носитель данных.

6.8. Проводить сортировку данных с целью облегчения поиска.

6.9. Использовать индексированные массивы данных для организации поиска по вторичным ключам.

6.10. Исключить избыточность данных.

6.11. Декомпозировать данные на несколько файлов.

6.12. Объединить данные в один файл данных.

7. ЭКОНОМИЯ РЕСУРСОВ ПРОГРАММЫ

7.1. Использовать inline-процедуры и inline-директивы. Позволяет экономить память компьютера и увеличивает быстродействие алгоритма, так как реализация такого же алгоритма с помощью операторов языка высокого уровня после компиляции приводит к увеличению объектного кода и усложнению алгоритма за счет добавления различных операторов контроля границ и т. п. В процедурах inline осуществляется непосредственный ввод текста в машинных кодах, и вся ответственность по организации процесса лежит на программисте.

7.2. Использовать директивы встроенного ассемблера.

7.3. Использовать абсолютную адресацию данных через директиву absolute и стандартные массивы Mem, MemW, MemL.

7.4. Использовать непосредственное обращение к портам через стандартные массивы Port, PortW, PortL.

7.5. Использовать систему прерываний через функции модуля DOS — Intr и MS DOS.

7.6. Использовать профилировку кода программ с помощью программ-профилировщиков.

7.7. Заменить статические переменные и массивы динамическими.

7.8. Использовать оверлейную организацию программ.

7.9. Объединить оверлейные файлы в один исполняемый файл типа *.ЕХЕ.

7.10. Разбить программу на резидентную часть (TSR) и подгружаемые части.

7.11. Использовать дополнительную память компьютера (expanded memory).

7.12. Использовать расширенную память компьютера (extended memory).

7.13. Использовать защищенный режим работы процессора (protected mode).

7.14. Использовать режим виртуального процессора 8086.

8. ОФОРМЛЕНИЕ ВАРИАНТА (ВЕРСИИ) ПРОГРАММЫ

8.1. Размножение окрестности (копирование старого варианта в отдельный файл). Крайне неэффективный метод из-за загромождения дискового пространства.

8.2. Замена вызова старой процедуры на вызов новой также неэффективна, так как старые процедуры также подключаются к объектному коду программы, что приводит к загромождению программы.

8.3. Использовать оператор выбора. Те же ограничения.

8.4. Комментирование измененного кода программы.

8.5. Использование директив компилятора {$IFDEF <условие>} и {$IFOPT <опция>}.

9. ТЕСТИРОВАНИЕ ПРОГРАММ

9.1. Заменить восходящее проектирование тестов нисходящим.

9.2. Инверсия приема.

9.3. Использовать метод большого скачка.

9.4. Использовать метод "сандвича".

9.5. Организовать входные данные для тестирования во внешнем файле. Это исключит повторный ввод данных при каждом тестировании, что позволит сэкономить время.

9.6. Использовать генератор входных данных.

10. ОТЛАДКА ПРОГРАММ

10.1. Использовать встроенный отладчик системы (трассировка программы).

10.2. Использовать директивы компилятора {$D} и {$L} при компиляции модулей с целью иметь непосредственный доступ к переменным и процедурам модуля.

10.3. Использовать отладочную печать. Выводить значения отдельных ключевых переменных и массивов непосредственно на экран или во внешний файл на диске.

10.4. Вставить "заглушки" на те модули программы, которые не подвергаются в настоящий момент отладке.

10.5. Использовать процедуру halt в случае исключительной ситуации.

10.6. Использовать возвращение функцией или процедурой специального значения в случае исключительной ситуации.

10.7. Использовать код возврата в виде отдельной глобальной переменной.

11. ОРГАНИЗАЦИЯ ДИАЛОГА С ПОЛЬЗОВАТЕЛЕМ

11.1. Заменить горизонтальное меню вертикальными меню.

11.2. Инверсия приема.

11.3. Использовать скроллинг меню.

11.4. Заменить выпадающее меню всплывающим меню.

11.5. Инверсия приема.

11.6. Организовать меню, активизирующееся по горячим клавишам.

11.7. Использовать кнопки и панели диалога.

11.8. Организовывать громоздкие экранные формы в виде многостраничных форм.

11.9. Использовать скроллинг экранных форм.

11.10. Использовать всплывающие экранные формы.

11.11. Использовать гипертекстовую систему в качестве системы помощи.

Приложение 4

ЭЛЕМЕНТЫ ЯЗЫКА OBJECT PASCAL

1. МОДУЛЬ В OBJECT PASCAL

Язык объектно-ориентированного программирования Object Pascal применяется при работе в среде визуального программирования Delphi. Язык Object Pascal в основном включает "старый" язык Borland Pascal.

Программы на языке Object Pascal состоят из нескольких файлов: файла проекта (Delphi Project) с расширением *.dpr, одного или нескольких файлов модулей (Unit) с расширением *.pas и файлов дизайнера экранных форм с расширением *.dfm.

Файл проекта содержит текст основной программы Program, с которой начинается выполнение всей программы. Тексты вызываемых подпрограмм и используемых объектов находятся в файлах модулей.

Рассмотрим организацию исходного текста модуля:

unit MyUnit1;

interface

uses

Unit1, Unit2, Unit3;

const

Pi = 3.14;

type

MyType =. .;

var

var1: MyType;

procedure Proc1;

function Func: MyType;

implementation

uses

Unit4, Unit5, Unit6;

const

…;

type

…;

var

…;

procedure Proc1;

begin

{ Операторы}

…

end;

function Func: MyType;

begin

{Операторы}

…

end;

initialization

{Операторы}

…

finalization

{Операторы}

…

end.

Модуль начинается с описательного оператора заголовка модуля:

unit MyUnit1;

Имена файлов MyUnit1.pas, MyUnit1.dfm должны совпадать с именем, описанным в заголовке модуля MyUnit1. Наличие файла MyUnit1.dfm не является обязательным.

Между зарезервированными словами interface и implementation находятся описательные операторы секции интерфейса. В интерфейсной части объявляются константы, типы, переменные, прототипы процедур и функций (только оператор заголовка без исполняемых операторов), которые должны быть доступны для использования в других модулях. Описания подключений других модулей осуществляются при помощи оператора uses, который может располагаться строго за оператором interface. Имена подключаемых модулей должны быть расположены в таком порядке, чтобы обеспечить последовательное описание всех нужных типов в данной интерфейсной секции и интерфейсных секций подключаемых модулей.

За зарезервированным словом implementation находятся описательные операторы секции реализации. В отличие от описаний секции интерфейса описания из секции реализации недоступны для других модулей, но доступ к ним возможен из данного модуля. Как и в секции интерфейса, может следовать оператор uses, а за ним объявления констант, типов, переменных. В отличие от секции интерфейса процедуры и функции описываются вместе с их выполняемыми операторами. В секции должны быть определены как процедуры и функции из секции реализации, так и процедуры и функции, прототипы которых были объявлены в секции интерфейса. Код процедур и функций модуля, описанный в секции implementation, подключается (линкуется или связывается) к основной программе или к точкам вызова подпрограмм и функций в других модулях (через механизм линкера, работа которого определяется uses).

В необязательном разделе initialization размещаются операторы, которые выполняются сразу после запуска программы.

Раздел finalization не является обязательным, более того, он может присутствовать только в том случае, если в модуле присутствовала секция initialization. В секции размещаются операторы, которые выполняются непосредственно перед завершением программы.

2. ОБЪЕКТЫ И КЛАССЫ В ЯЗЫКЕ OBJECT PASCAL

В обычном языке Pascal существует тип-запись:

type

TmyRecord = record

MyField1: String;

MyField2: Integer;

end;

Тип-запись позволяет описывать структурированные переменные, содержащие несколько значений как одного, так и разных типов. В приведенном примере запись TmyRecord содержит поля MyField1 и MyField2, которые соответственно имеют типы String и Integer.

Тип-класс в Object Pascal по виду близок к записи, но отличается от записи возможностью наследования от других классов, а также возможностью описания методов класса. Классом в Object Pascal называется особый тип записи, который может иметь в своем составе поля, методы и свойства. Такой тип также будем называть объектным типом:

type

TMyObject = class(TObject)

MyField: Integer;

Procedure MyMethod1 (X: Real; var Y: Real);

function MyMethod2: Integer;

end;

В примере описан класс TMyObject, который наследуется от класса Tobject. Понятие "наследования классов" и понятие "свойства" будут подробно рассмотрены далее. Пока можно определить понятие свойства как поле, которое доступно не напрямую, а через посылку сообщений особым методам.

Класс TMyObject имеет поле MyField и методы MyMethod1 и MyMethod2. Нужно заострить внимание на том, что классы могут быть описаны либо в секции интерфейса модуля Interface (под модулем здесь понимается файл с исходным кодом вида Unit), либо на верхнем уровне вложенности секции реализации Implementation. He допускается описание классов внутри процедур и других блоков кода.

В случае если класс включает в себя поле с типом другого класса, разрешено опережающее объявление класса как в следующем примере:

type

TFirstObject = class;

TSecondObject = class (TObject)

Fist: TFirstObject;

{…}

end;

TFirstObject = class(TObject)

{…}

end;

Код методов описывается ниже по тексту объявлений классов, например:

Procedure TMyObject.MyMethod1(X: Real; var Y: Real);

begin

у:= 5.0 * sin(X);

end;

function TMyObject.MyMethod2: Integer;

begin

{…}

MyMethod2:= MyField + 3;

end;

Для того чтобы использовать новый тип в программе, нужно, как минимум, объявить переменную этого типа, которая называется или переменной объектного типа, или экземпляром класса, или объектом:

var

AMyObject: TMyObject;

Согласно обычному языку Borland Pascal, переменная AMyObject должна содержать в себе весь экземпляр объекта типа TMyObject (код и данные вместе) — статический объект. Но в Delphi все объекты динамические, поэтому, не вдаваясь в подробности, выполним оператор:

{действие по созданию экземпляра объекта}

AMyObject:= TMyObject.Create;

Теперь другие объекты программы могут посылать сообщения данному объекту. Посылка сообщений заключается в вызове методов нужного объекта, например:

var

К: Integer;

{…}

AMyObject.MyMethod1(2.3, Z);

К:= 6 + AMyObject.MyMethod2;

Методы — это процедуры и функции, описанные внутри класса. Как видно, посылка сообщений в Object Pascal близка к вызову процедур языка Pascal, но имени вызываемой процедуры или процедуры-функции предшествует имя конкретного объекта, например: AMyObject.

Опишем два объекта AMyObject, BMyObject одного класса TMyObject:

var

AMyObject,

BMyObject: TmyObject;

При проектировании программисты считают, что каждый объект (экземпляр класса) имеет свой внутренний код методов и индивидуальную память, где размещаются свои поля.

На самом деле методы у разных объектов одного класса общие. Другими словами, они реализуются общим кодом, расположенным только в одном месте памяти. Это экономит память. В приведенном примере вызов методов:

AMyObject.MyMethod1(2.3, Z);

BMyObject.MyMethod1(0.7, Q)

на самом деле приведет к исполнению одного и того же кода при моделируемой для программиста видимости принадлежности своего индивидуального кода разным объектам. Это сближает методы с процедурами и процедурами-функциями языка Pascal. Напомним, что указатель — это переменная, содержащая в памяти адрес (номер ячейки) другой переменной, процедуры или объекта. В состав класса входит указатель на специальную таблицу, где содержится вся информация, нужная для вызова методов. От обычных процедур и функций методы отличаются тем, что им при вызове передается (неявно) указатель на тот объект, который их вызвал. Внутри методов он доступен под зарезервированным именем Self.

Засылка и извлечение значений в поля, согласно нерекомендуемому в Object Pascal прямому доступу, практически не отличается от использования полей записи обычного языка Pascal:

AMyObject.MyField:= 3;

I:= AMyObject.MyField + 5.

В отличие от методов поля объекта — это данные, уникальные для каждого объекта, являющегося экземпляром даже одного класса. Поля AMyObject.MyField и BMyObject.MyField. являются совершенно разными полями, поскольку они располагаются в разных объектах.

3. ОБЛАСТИ ВИДИМОСТИ

При описании нового класса важен разумный компромисс. С одной стороны, требуется скрыть методы и поля, представляющие собой внутреннее устройство класса. Маловажные детали на других уровнях будут бесполезны и только помешают целостности восприятия. Доступ к важным деталям нужно организовать через систему проверок.

В языке Object Pascal введен механизм доступа к составным частям объекта, определяющий области, где ими можно пользоваться (т. е. области видимости). Поля и методы могут относиться к четырем группам, отличающимся областями сокрытия информации:

public — общие;

private — личные;

protected— защищенные;

published — опубликованные.

Деление на составные части работает на уровне файлов модулей (Unit в смысле языка Pascal). Если вы нуждаетесь в специальной защите объекта или его части, то для этого необходимо поместить его в отдельный модуль, в котором есть собственные секции interface и implementation.

Поля, свойства и методы, находящиеся в секции public, не имеют ограничений на видимость. Они доступны из других функций и методов объектов как в данном модуле, так и во всех прочих, ссылающихся на него. Обычно методы данной секции образуют интерфейс между объектного обмена сообщениями в период выполнения программы (run-time).

Поля, свойства и методы, находящиеся в секции private, доступны только в методах класса и функциях, содержащихся в том же модуле, что и описываемый класс. Такая директива позволяет скрыть детали внутренней реализации класса от всех. Элементы из секции private можно изменять, и это не будет сказываться на программах, работающих с объектами этого класса. Единственный способ для кого-то другого — обратиться к ним — переписать заново созданный вами модуль.

Раздел protected комбинирует функциональную нагрузку разделов private и public таким образом, что если вы хотите скрыть внутренние механизмы вашего объекта от конечного пользователя, этот пользователь не сможет в run-time использовать ни одно из объявлений объекта из его protected-области. Но это не помешает разработчику новых компонент использовать эти механизмы в других наследуемых классах, т. е. protected-объявления доступны у любого из наследников вашего класса.

Раздел published оказался необходимым при введении в Object Pascal возможности установки свойств и поведения компонент еще на этапе конструирования форм и самого приложения (design-time) в среде визуальной разработки программ Delphi. Именно published-объявления доступны через Object Inspector, будь это ссылки на свойства или обработчики событий. Во время исполнения приложения раздел объекта published полностью аналогичен public.

Следует отметить тот факт, что при порождении нового класса путем наследования возможен перенос объявлений из одного раздела в другой с единственным ограничением: если вы производите скрытие объявления за счет его переноса в раздел private, в дальнейшем его "вытаскивание" у наследника в более доступный раздел в другом модуле будет уже невозможен. Такое ограничение, к счастью, не распространяется на динамические методы-обработчики сообщений Windows.

Пример описания класса с заданными областями видимости приведен ниже.

4. ИНКАПСУЛЯЦИЯ

Классическое правило объектно-ориентированного программирования утверждает, что для обеспечения надежности нежелателен прямой доступ из других объектов к полям объекта: чтение и обновление их содержимого должно производиться посредством вызова соответствующих методов. Это правило и называется инкапсуляцией. До сих пор идея инкапсуляции внедрялась в программирование только посредством призывов и примеров в документации, но в языке же Object Pascal появилась соответствующая конструкция. В объектах Object Pascal пользователь объекта может быть полностью отгорожен от его полей при помощи свойств.

Работу со свойствами рассмотрим на следующем примере. Пусть мы создали при помощи дизайнера форм Delphi экранную форму Forml с двумя элементами визуальных компонент: Button 1 и Label 1 (рис. 1).

Рис. 1. Экранная форма примера

Кликнем кнопку Button1 и отредактируем исходный текст модуля до следующего текста:

unit testir;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;

type

TForm1 = class(TForm)

Button1: TButton;

Label1: TLabel;

procedure Button1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

type

TSomeType = String;

type

TAnObject = class(TObject)

private

FValue: TSomeType;

function GetAProperty: TSomeType;

procedure SetAProperty (ANewValue: TSomeType);

public

property AProperty: TSomeType

read GetAProperty

write SetAProperty;

end;

var

Form1: TForm1;

AnObject: TAnObject;

implementation

{$R *.DFM}

procedure TForm1.ButtonlClick(Sender: TObject);

begin

AnObject:= TAnObject.Create;

AnObject.AProperty:= 'Привет!';

Label1.Caption:= AnObject.AProperty;

end;

procedure TAnObject.SetAProperty(

ANewValue: TSomeType);

begin

FValue:= ANewValue; {Засылка значения в поле}

end;

function TAnObject.GetAProperty: TSomeType;

begin

GetAProperty:= FValue; {Чтение значения из поля}

end;

end.

Сохраним проект (Save Project As). При сохранении проекта укажем новое имя модуля — testir и новое имя проекта — PrTestir. Рассмотрим текст получившегося файла проекта (пункты меню View и далее Project Source):

program PrTestir;

uses

Forms,

testir in 'testir.pas' {Form1};

{$R *.RES}

begin

Application.Initialize;

Application.CreateForm(TForm1, Form1);

Application.Run;

end.

Данный файл содержит текст основной программы PrTestir. К основной программе подключаются модуль Forms (для работы с формой) и исходный код модуля testir. Три исполняемых оператора основной программы последовательно организуют новый вычислительный процесс выполнения написанной программы PrTestir, создадут объект формы Form1, осуществят запуск программы на выполнение (Run).

В набранном примере текст модуля содержит сгенерированный текст объявления объектного типа Tform1. В типе содержатся указания на агрегацию в данном классе объекта кнопки Button1: Tbutton и объекта Label1: Tlabel. Благодаря агрегации экземпляры объектов кнопки и надписи будут создаваться одновременно с созданием экземпляра объекта формы, в результате чего как бы получится совместно работающий с кнопкой и надписью объект формы. В типе Tform1 Delphi по двойному щелчку мыши по кнопке <Button1> сгенерировала прототип вызова метода:

procedure Button1Click(Sender: TObject).

Также Delphi автоматически сгенерировала переменную объектного типа

var

Form1: TForm1;

и в секции реализации вставила текст "пустой" процедуры Button1Click отработки действий по нажатию кнопки Button1.

Рассмотрим элементы, добавленные нами в текст модуля по реализации инкапсуляции. Итак, нами был набран текст описания класса TAnObject и переменная данного объектного типа AnObject:

type

TAnObject = class(TObject) private

FValue: TSomeType;

function GetAProperty: TSomeType;

procedure SetAProperty (ANewValue: TSomeType);

public

property AProperty: TSomeType

read GetAProperty

write SetAProperty;

end;

var

AnObject: TanObject.

Обычно свойство (property) определяется тремя своими элементами: полем и двумя методами, которые осуществляют его запись/чтение:

private

FValue: TSomeType;

function GetAProperty: TSomeType;

procedure SetAProperty (ANewValue: TSomeType);

public

property AProperty: TSomeType

read GetAProperty

write SetAProperty;

…

procedure TAnObject.SetAProperty(ANewValue: TSomeType);

begin

FValue:= ANewValue; {Засылка значения в поле}

end;

function TAnObject.GetAProperty: TSomeType;

begin

GetAProperty:= FValue; {Чтение значения из поля}

end;

В данном примере свойство Aproperty выполняет такую же функцию, какую в предшествующем примере выполняло поле MyField. Доступ к значению свойства Aproperty осуществляется через вызовы методов GetAProperty и SetAProperty. Однако в обращении к этим методам в явном виде нет необходимости (в рассматриваемом примере они даже защищены — protected), достаточно написать:

AnObject.AProperty:=…;

…:= AnObject.Aproperty;

и компилятор оттранслирует эти операторы в вызовы методов.

Рассмотрим три оператора, вписанные в текст "пустой" процедуры (метод) Button1Click:

AnObject:= TAnObject.Create;

AnObject.AProperty:= 'Привет!';

Label1.Caption:= AnObject.AProperty;

Первый оператор создает экземпляр объекта. Второй оператор в недоступное по интерфейсу (protected) поле Fvalue засылает при помощи недоступной по интерфейсу (protected) процедуры AnObject.SetAProperty текст "Привет!". Третий оператор при помощи недоступной по интерфейсу (protected) процедуры АпОЬject.GetAProperty считывает данные из недоступного по интерфейсу поля Fvalue и засылает их в свойство Caption объекта надписи Label1.

Само свойство AProperty описано как общедоступное по интерфейсу (public), т. е. внешне свойство выглядит в точности, как доступ к обычному полю, но за всяким обращением к свойству могут стоять нужные программисту действия. Например, если у нас есть объект, представляющий собой квадрат на экране, и мы его свойству "цвет" присваиваем значение "белый", то произойдет немедленная перерисовка, приводящая реальный цвет на экране в соответствие значению свойства.

В методах, входящих в состав свойств, может осуществляться проверка устанавливаемой величины на попадание в допустимый диапазон значений и вызов других процедур, зависящих от вносимых изменений. Если же потребности в специальных процедурах чтения и/или записи нет, то возможно вместо имен методов применять имена полей.

Рассмотрим следующую конструкцию:

type

TPropObject = class(TObject)

FValue: TSomeType;

procedure DoSomething;

procedure Correct(AValue: Integer);

procedure SetValue(NewValue: Integer);

procedure AValue: Integer read Fvalue

write SetValue;

end;

…

procedure TPropObject.SetValue(NewValue: Integer);

begin

if (NewValue <> FValue) and Correct (NewValue)

then

FValue:= NewValue; {Засылка значения в поле}

DoSomething;

end;

В этом примере чтение значения свойства AValue означает просто чтение поля FValue. Зато при присвоении ему значения внутри метода SetValue вызывается сразу два метода.

Если свойство должно только читаться или только записываться, то в его описании может присутствовать только соответствующий метод:

type

TAnObject = class(TObject)

property AProperty: TSomeType read GetValue;

end;

В этом примере вне объекта значение свойства можно лишь прочитать. Попытка присвоить значение Aproperty вызовет ошибку компиляции.

5. ОБЪЕКТЫ И ИХ ЖИЗНЕННЫЙ ЦИКЛ

Как создаются и уничтожаются объекты? В Object Pascal экземпляры объектов могут быть только динамическими! Это означает, что в приведенном в начале раздела фрагменте переменная AMyObject хотя и выглядит как статическая переменная языка Pascal, на самом деле является указателем, содержащим адрес объекта. Любая переменная объектного типа и есть указатель (указатель — переменная, содержащая значение адреса оперативной памяти).

Память под конкретные объекты (динамические экземпляры классов) выделяется диспетчером памяти в периоде выполнения программы в особой heap-области, где должно еще быть свободное место для размещения новых объектов. Heap — "куча мусора". Диспетчер памяти может как размещать в heap-области новые объекты, так и удалять уже ненужные, освобождая память под все новые объекты. Как раз при размещении объекта в памяти инициализируется значение переменной объектного типа адресом объекта. При удалении объекта переменная объектного типа инициализируется значением nil (пустой указатель) — нет объекта в памяти. При размещении нового объекта в памяти может оказаться, что общая свободная память имеет большой объем, но любой из освободившихся участков памяти, занимаемых уже удаленными объектами, оказывается меньше объема нового большого объекта. Для избежания такой ситуации при использовании объектных программ устанавливают в ЭВМ оперативную память заведомо большого объема. Новый экземпляр объекта создается особым методом — конструктором, а уничтожается специальным методом — деструктором:

AMyObject:= TMyObject.Create; {действия с созданным объектом}

…

AMyObject.Destroy; {уничтожение объекта}

В Object Pascal конструкторов у класса может быть несколько. Общепринято называть конструктор Create. Типичное название деструктора — Destroy. Рекомендуется использовать для уничтожения экземпляра объекта метод Free, который первоначально проверяет указатель (не равен ли он nil) и затем уж вызывают Destroy.

Для того чтобы правильно проинициализировать в создаваемом объекте поля, относящиеся к классу-предку, нужно сразу же при входе в конструктор вызвать конструктор предка:

constructor TmyObject.Create;

begin

inherited Create;

…

end;

Метод Create объекта MyObject типа TMyObject унаследован от класса предка TObject.

Взяв любой из примеров, поставляемых вместе с Delphi, мы обнаружим, что там почти нет вызовов конструкторов и деструкторов. Дело в том, что любой компонент, попавший при визуальном проектировании в приложение из Палитры компонентов, включается в определенную иерархию. Иерархия эта замыкается на форме (TForm): для всех ее составных частей конструкторы и деструкторы вызываются автоматически, незримо для программиста.

Кто создает и уничтожает формы? Это делает приложение (глобальный объект с именем Application). В файле проекта (.DPR) можно увидеть вызов функции CreateForm, предназначенный для этой цели. Что же касается объектов, создаваемых динамически (во время выполнения приложения), то здесь нужен явный вызов конструктора.

6. НАСЛЕДОВАНИЕ

Вторым "столпом" ООП, помимо инкапсуляции, является наследование. Этот простой принцип означает, что если нужно создать новый класс, лишь немного отличающийся от старого, то совершенно нет необходимости в переписывании заново уже существующих полей и методов. Новый класс

TNewObject = class(TOldObject);

является потомком, или дочерним классом старого класса, называемого предком, или родительским классом. Добавляются к нему лишь новые поля, методы и свойства.

В Object Pascal все классы являются потомками класса TObject. Поэтому если строится дочерний класс прямо от TObject, то в определении TOject можно не упоминать. Следующие два выражения одинаково верны:

TMyObject = class(TObject);

TMyObject = class;

Использование последнего выражения оправдано, если разработчик хочет показать, что, согласно его замыслу, проектируемый класс как бы не имеет предков.

Приведем объявление базового для всех объектных типов класса TObject:

TObject = class

constructor Create;

destructor Destroy; virtual;

procedure Free;

class function Newlnstance: TObject; virtual;

procedure Freelnstance; virtual;

class procedure Initlnstance(Instance: Pointer):

TObject;

function ClassType: TClass;

class function ClassName: string;

class function ClassParent: TClass;

class function ClassInfo: Pointer;

class function InstanceSize: Word;

class function InheritsFrom(AClass: TClass):

Boolean;

procedure DefaultHandler(var Message); virtual;

procedure Dispatch(var Message);

class function MethodAddress(const Name: string):

Pointer;

class function MethodName(Address: Pointer):

string;

function FieldAddress(const Name: string):

Pointer;

end;

Такая архитектура возможна только при наличии механизма поддержки информации о типах — RTTI (RunTime Type Information). Основой такого механизма является внутренняя структура классов и, в частности, возможность доступа к ней за счет использования методов классов, описываемых конструкцией class function…

Унаследованные от предка поля и методы доступны в дочернем классе; если имеет место совпадение имен методов, то эти методы перекрываются.

По тому, какие действия происходят при вызове, методы делятся на группы:

• статические (static);

• виртуальные (virtual);

• динамические (dynamic);

• абстрактные (abstract).

Статические методы, а также поля в объектах-потомках ведут себя одинаково: можно без ограничений перекрывать старые имена и при этом изменять тип методов:

type

T1stObj = class

I: Real;

procedure SetData(Avalue: Real);

end;

T2ndObj = class(T1stObj)

I: Integer;

procedure SetData(Avalue: Integer);

end;

…

procedure T1stObj.SetData;

begin

i: = v;

end;

procedure T2nd0bj.SetData;

begin

i:= 0;

inherited SetData(0.99);

end;

В этом примере разные методы с именем SetData присваивают значения разным полям с именем i. Перекрытое поле предка недоступно в потомке. В отличие от поля внутри других методов перекрытый метод доступен при указании зарезервированного слова inherited. Методы объектов по умолчанию являются статическими — их адрес определяется еще на стадии компиляции проекта. Они вызываются быстрее всего.

Язык C++ позволяет так называемое множественное наследование. В этом случае новый класс может наследовать часть своих элементов от одного родительского класса, а часть — от другого, это наряду с удобствами зачастую приводит к проблемам.

В Object Pascal понятие множественного наследования отсутствует. Если необходимо, чтобы новый класс объединял свойства нескольких, можно породить классы-предки один от другого или включить в класс несколько полей, соответствующих этим желаемым классам.

Принципиально отличаются от статических методов виртуальные и динамические методы. Они могут быть объявлены путем добавления соответствующей директивы virtual или dynamic. Адрес таких методов определяется во время выполнения программы по специальной таблице. С точки зрения наследования методы этих двух видов одинаковы: они могут быть перекрыты в дочернем классе только одноименными методами, имеющими тот же тип.

Общим для них является то, что при их вызове адрес определяется не во время компиляции, а во время выполнения путем поиска в специальных таблицах. Такой способ еще называется поздним связыванием. Разница между методами заключается в особенности поиска адреса.

Когда компилятор встречает обращение к виртуальному методу, он подставляет вместо обращения к конкретному адресу код, который обращается к специальной таблице и извлекает оттуда нужный адрес. Эта таблица называется таблицей виртуальных методов (Virtual Method Table, VMT), и она есть для каждого объектного типа. В ней хранятся адреса всех виртуальных методов класса независимо от того, унаследованы ли они от предка или перекрыты. Отсюда и достоинства, и недостатки виртуальных методов: они вызываются сравнительно быстро (но медленнее статических), однако для хранения указателей на них требуется большое количество памяти.

Динамические методы вызываются медленнее, но позволяют более экономно расходовать память. Каждому динамическому методу системой присваивается уникальный индекс. В таблице динамических методов (Dynamic Method Table, DMT) класса хранятся индексы и адреса только тех динамических методов, которые описаны в данном классе (базовая информация по обработке динамических методов содержится в модуле x: \delphi\source\rtl\sys\dmth.asm). При вызове динамического метода происходит поиск в этой таблице. В случае неудачи просматриваются все классы-предки в порядке иерархии и, наконец, TObject, где имеется стандартный обработчик вызова динамических методов. Экономия памяти налицо.

Для перекрытия и виртуальных, и динамических методов служит новая директива override, с помощью которой (и только с ней!) можно переопределять оба этих типа методов:

type

TFirstClass = class

FMyField1: Integer;

FMyField2: Longlnt;

procedure StatMethod1;

procedure VirtMethod1; virtual;

procedure VirtMethod2; virtual;

procedure DynaMethod1; dynamic;

procedure DynaMethod2; dynamic;

end;

TSecondClass = class(TFirstClass)

procedure StatMethod;

procedure VirtMethod; override;

procedure StatMethod; override;

end;

var

Obj2: TFirstClass;

Obj1: TSecondClass;

Первый из методов в примере создается заново, остальные два — перекрываются. Попытка применить override к статическому методу вызовет ошибку компиляции.

В Object Pascal абстрактными называются методы, которые определены в классе, но не содержат никаких действий, никогда не вызываются и должны быть переопределены в потомках класса. Абстрактными могут быть только виртуальные и динамические методы. Для этого используется директива abstract, указываемая при описании метода:

procedure NeverCallMe; virtual; abstract;

При этом никакого кода для этого метода писать не нужно. Как и ранее, вызов метода NeverCallMe приведет к ошибке времени выполнения.

7. ПОЛИМОРФИЗМ

Рассмотрим пример, которой поясняет, для чего нужно использование абстрактных методов. Пусть у нас имеются некое обобщенное поле для хранения данных — класс TField и три его потомка — для хранения строк, целых и вещественных чисел. В данном случае класс Tfield не используется сам по себе; его основное предназначение — быть родоначальником иерархии конкретных классов — "полей" и дать возможность абстрагироваться от частностей. Хотя параметр у ShowData и описан как TField, но если поместить туда объект этого класса, произойдет ошибка вызова абстрактного метода:

type

TField = class

function GetData: string; virtual; abstract;

end;

TStringField = class(TField)

Data: string;

function GetData: string; override;

end;

TIntegerField = class(TField)

Data: Integer;

function GetData: string; override;

end;

TExtendedField = class(TField)

Data: Integer;

function GetData: string; override;

end;

function TStringField.GetData;

begin

GetData:= Data;

end;

function TIntegerField.GetData;

begin

GetData:= IntToStr(Data);

end;

function TExtendedField.GetData;

begin

GetData:= IntToStrF(Data, ffFixed, 7, 2);

end;

…

procedure ShowData(AField: TField);

begin

Form1.Label1.Caption:= AField.GetData;

end;

В этом примере классы содержат разнотипные данные, которые "умеют" только сообщить о значении этих данных текстовой строкой (при помощи метода GetData). Внешняя по отношению к ним процедура ShowData получает объект в виде параметра и показывает эту строку.

Правила контроля соответствия типов (typecasting) языка Pascal говорят о том, что объекту как указателю на экземпляр объектного типа может быть присвоен адрес любого экземпляра любого из дочерних типов. В процедуре ShowData параметр описан как TField. Это значит, что в нее можно передавать объекты классов и TStringField, и TIntegerField, и TExtendedField, и любого другого потомка TField.

Но какой (точнее, чей) метод GetData при этом будет вызван? Тот, который соответствует классу фактически переданного объекта. Этот принцип называется полиморфизмом, и он, пожалуй, представляет собой наиболее важный "козырь" ООП. Допустим, имеется дело с некоторой совокупностью явлений или процессов. Чтобы смоделировать их средствами ООП, нужно выделить их самые общие, типовые черты. Те из них, которые не изменяют своего содержания, должны быть реализованы в виде статических методов. Те же, которые варьируют при переходе от общего к частному, лучше облечь в форму виртуальных методов. Основные "родовые" черты (методы) нужно описать в классе-предке и затем перекрыть их в классах-потомках. В предыдущем примере программисту, пишущему процедуру вроде ShowData, важно лишь одно: то, что любой объект, переданный в нее, является потомком TField, и он умеет сообщить о значении своих данных (выполнив метод GetData).

Если такую процедуру скомпилировать и поместить в динамическую библиотеку, то эту библиотеку можно будет раз и навсегда использовать без изменений, хотя будут появляться и новые, неизвестные в момент ее создания классы-потомки TField!

Наглядный пример использования полиморфизма дает сама Delphi. В ней имеется класс TComponent, на уровне которого сосредоточены определенные "правила" того, как взаимодействовать со средой разработки и с другими компонентами. Следуя этим правилам, можно порождать от TComponent свои компоненты, настраивая Delphi на решение специальных задач.

8. ОБРАБОТКА СООБЩЕНИЙ

Потребность в динамических методах особенно ощутима при разработке объектов, соответствующих элементам интерфейса Windows, когда каждый из большой иерархии объектов содержит обработчики десятков разнообразных сообщений.

Методы, предназначенные специально дня обработки сообщений Windows, составляют подмножество динамических методов и объявляются директивой message, за которой следует индекс — идентификатор сообщения. Они должны быть обязательно описаны как процедуры, имеющие один var-параметр, который может быть описан произвольно, например:

type

TMyControl = class(TWinControl)

procedure WMSize(var Message: TWMSize);

message WM_SIZE;

end;

type

TMyOtherControl = class(TMyControl)

procedure Resize(var Info);

message WM_SIZE;

end;

Для перекрытия методов-обработчиков сообщений директива override не используется. В этом случае нужно сохранить в описании директиву message с индексом метода.

Необходимости изобретать собственные структуры, по-своему интерпретирующие содержание того или иного сообщения, нет: для большинства сообщений Windows типы уже описаны в модуле MESSAGES.

В обработчиках сообщений (и только в них) можно вызвать метод-предок, просто указав ключевое слово inherited, без указания его имени и преобразования типа параметров: предок будет найден по индексу. Следует напомнить, что система обработки сообщений встроена в Object Pascal на уровне модели объектов, и самый общий обработчик — метод DefaultHandler — описан в классе TObject.

9. СОБЫТИЯ И ДЕЛЕГИРОВАНИЕ

Работать с большим количеством сообщений, даже имея под рукой справочник, нелегко, поэтому одним из больших достижений Delphi является то, что программист избавлен от необходимости работать с сообщениями Windows (хотя такая возможность у него есть). Стандартных событий в Delphi не более двух десятков, и все они имеют простую интерпретацию, не требующую глубоких знаний среды.

Рассмотрим, как реализованы события на уровне языка Object Pascal. События — это свойства процедурного типа, предназначенные для создания пользовательской реакции на те или иные входные воздействия:

property OnMyEvent: TMyEvent read FonMyEvent

write FonMyEvent;

Присвоить такому свойству значение — это означает указать объекту адрес метода, который будет вызываться в момент наступления события. Такие методы назовем обработчиками событий. Например:

Application.OnActive:= MyActivatingMethod;

Это означает, что при каждой активизации Application (так называется объект, соответствующий работающему приложению) будет вызван метод-обработчик MyActivatingMethod.

Внутри библиотеки времени выполнения Delphi вызовы обработчиков событий находятся в методах, обрабатывающих сообщения Windows. Выполнив принципиально необходимые действия, этот метод проверяет, известен ли адрес обработчика, и, если это так, вызывает его:

if Assigned(FonMyEvent)

then

FonMyEvent(Self);

В зависимости от происхождения и предназначения события имеют разные типы. Общим для всех является параметр Sender, указывающий на объект-источник события. Самый простой тип — TNotifyEvent — не имеет других параметров:

TNotifyEvent = procedure(Sender: TObject) of object;

Тип метода, предназначенный для извещения о нажатии клавиши, предусматривает передачу программисту кода этой клавиши, а передвижение мыши — ее координат и т. п.

Все события в Delphi принято именовать с "On": OnCreate, OnMouseMove, OnPaint и т. д. Щелкнув в Инспекторе объектов на странице Events в поле любого события, автоматически получается заготовка метода нужного типа. При этом его имя будет состоять из имени текущего компонента и имени события (без "On"), а относиться он будет к текущей форме. Пусть, например, на форме Form1 есть текст Label1. Тогда для обработки щелчка мышью на нем (событие OnClick) будет создан метод Tform1. Label1Click.

Поскольку события — это свойства объекта, их значения можно изменять во время выполнения программы. Такая замечательная возможность называется делегированием. Можно в любой момент взять способы реакции на события у одного объекта и делегировать их другому:

Object.OnMouseMove:= Object2.OnMouseMove;

Но какой механизм позволяет подменять обработчики, ведь это не просто процедуры, а методы? Здесь как нельзя кстати приходится введенное в Object Pascal понятие указателя на метод. Помимо явно описанных параметров методу передается еще и указатель на вызвавший его экземпляр (Self). Вы можете описать тип процедуры, которая будет совместима по присваиванию с методом (т. е. предусматривать получение Self). Для этого в ее описание нужно добавить зарезервированные слова of Object. Указатель на метод — это указатель на такую процедуру:

type

TmyEvent = procedure(Sender: TObject;

var Avalue: Integer) of object;

T1stObject = class;

FOnMyEvent: TMyEvent;

property OnMyEvent: TMyEvent read FonMyEvent

write FonMyEvent;

end;

T2ndObject = class;

procedure SetValue1(Sender: TObject;

var Avalue: Integer);

procedure SetValue2(Sender: TObject;

var Avalue: Integer);

end;

…

var

Obj1: T1stObject;

Obj2: T2ndObject;

begin

Obj1:= T1stObject.Create;

Obj2:= T2ndtObject.Create;

Obj1.OnMyEvent:= Obj2.SetValue1;

Obj2.OnMyEvent:= Obj2.SetValue2;

…

end;

Как в этом примере, так и повсюду в Delphi за свойствами-событиями стоят поля, являющиеся указателями на метод. Таким образом, при делегировании можно присваивать методы других классов. Здесь обработчиком события OnMyEvent объекта Obj1 по очереди выступают методы SetValue1 и SetValue2 объекта Obj2.

10. ФУНКЦИИ КЛАССА

В Object Pascal имеется возможность определения полей процедурного типа. Очевидно, что в теле функций, привязываемых к этим полям, разработчику необходим доступ к другим полям объекта, методам и т. п. Возможность такого доступа базируется на передаче в эти функции неявного, но доступного в их коде параметра, автоматически принимающего значение поля объекта Self. Такие функции называются функциями классов. Для объявления функций классов необходимо использовать специальную конструкцию function … of object.

11. ПРИВЕДЕНИЕ ТИПОВ

На операции с переменной определенного типа компилятор обычно налагает ограничения, разрешая выполнение только тех операций, которые характерны для указанного типа данных. Иногда компилятор осуществляет автоматическое приведение типа, например, при присвоении целого значения действительной переменной.

В языке Pascal имеется механизм явного приведения типов.

В операции is определяется, принадлежит ли данный объект указанному типу или одному из его потомков.

Выражение, представленное в следующем примере, возвращает True, если переменная AnObject ссылается на образец объектного типа TMyClass или одного из его потомков.

AnObject is TmyClass

Сама по себе операция is не является операцией задания типа. В ней лишь проверяется совместимость объектных типов. Для корректного приведения типа объекта применяется операция as:

With AnObject as TmyClass do…

Возможен и такой способ приведения типа без явного указания as.

With TMyClass(AnObject)do…

В программах перед операцией as проверяют совместимость типов с помощью операции is. Если типы несовместимы, запускается обработчик исключительной ситуации EinvalidCast.

Таким образом, в конструкции as операция явного приведения типа оказывается заключенной в безопасную оболочку:

If AnObject is TobjectType then

with TobjectType(AnObject) do …

else

raise EinvalidCast.Create('Неправильное приведение типа');

12. ОБЪЕКТНАЯ ССЫЛКА

Delphi позволяет создать специальный описатель объектного типа (именно на тип, а не на экземпляр!), известный как object reference — объектная ссылка.

Объектные ссылки используются в следующих случаях:

— тип создаваемого объекта не известен на этапе компиляции;

— необходим вызов метода класса, чей тип не известен на этапе компиляции;

— в качестве правого операнда в операциях проверки и приведения типов с использованием is и as.

Объектная ссылка определяется с использованием конструкции class of… Приведем пример объявления и использования class reference:

type

TMyObject = class (TObject)

MyField: TMyObject;

constructor Create;

end;

TObjectRef = class of TObject;

…

var

ObjectRef: TObjectRef;

s: string;

begin

ObjectRef:=TMyObject; {присваиваем тип, а не экземпляр!}

s:=ObjectRef.ClassName; {строка s содержит 'TMyObject'}

end;

Таким образом, в Delphi определена специальная ссылка TClass, совместимая по присваиванию с любым наследником TObject. Аналогично объявлены классы: TPersistentClass и ТСотроnentClass.

13. СТРУКТУРНАЯ ОБРАБОТКА ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ

Под исключительной ситуацией (raise) здесь понимается ситуация, которая не позволяет без особых дополнительных мер продолжить выполнение программы, например деления на ноль, переполнения разрядной сетки, извлечения квадратного корня из отрицательного числа и т. д.

При традиционной обработке ошибок, ошибки, обнаруженные в процедуре, обычно передаются наружу (в вызывавшую процедуру) в виде возвращаемого значения функции, параметров или глобальных переменных (флагов). Каждая вызывающая процедура должна проверять результат вызова на наличие ошибки и выполнять соответствующие действия. Часто это просто выход в более верхнюю вызывающую процедуру и т. д.

Структурная обработка исключительных ситуаций — это программный механизм, позволяющий программисту при возникновении ошибки (исключительной ситуации — exception) связаться с кодом программы, подготовленным для обработки такой ошибки. В Delphi система называется структурной, поскольку обработка ошибок определяется областью "защищенного" кода. Такие области могут быть вложенными. Выполнение программы не может перейти на произвольный участок кода. Выполнение программы может перейти только на обработчик исключительной ситуации активной программы.

Модель исключительных ситуаций в Object Pascal является не-возобновляемой (non-resumable). При возникновении исключительной ситуации вы уже не сможете вернуться в точку, где она возникла, для продолжения выполнения программы (это позволяет сделать лишь возобновляемая (resumable) модель).

Для обработки исключительных ситуаций в язык Object Pascal добавлено новое ключевое слово "try", которое используется для обозначения первой части защищенного участка кода. Существуют два типа защищенных участков:

1) try..except;

2) try..finally.

Первый тип используется для обработки исключительных ситуаций. Его синтаксис:

try

Statement1;

Statement2;

…

except

on Exception1 do Statement;

on Exception2 do Statement;

…

else

Statements; {default exception-handler}

end;

Для уверенности в том, что ресурсы, занятые вашим приложением, освободятся в любом случае, можете использовать конструкцию второго типа. Код, расположенный в части finally, выполняется в любом случае, даже если возникает исключительная ситуация. Соответствующий синтаксис:

try

Statement1;

Statement2;

finally

Statements; {These statements always execute}

end;

Приложение 5

ОСНОВНЫЕ ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

Абстрагирование от проблемы — игнорирование ряда подробностей с тем, чтобы свести задачу к более простой задаче.

Абстрактная машина Дейкстры — применяется в проектировании архитектуры системы, самый нижний уровень абстракции — это уровень аппаратуры. Каждый уровень реализует абстрактную машину с все большими возможностями.

Абстрактный родительский класс — родительский класс, не имеющий экземпляров объектов.

Абстракция — мысленное отвлечение, обособление от тех или иных сторон, свойств или связей предметов и явлений для выявления существенных их признаков.

Абстракция сущности — произвольная абстракция. Объект представляет собой полезную модель некой сущности в предметной области.

Автоматизированная система (АС) — организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях, система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Автономное тестирование (тестирование модуля) (module testing) — контроль отдельного модуля в изолированной среде (например, с помощью ведущей программы), инспекция текста модуля на сессии программистов, которая иногда дополняется математическим доказательством правильности модуля.

Агрегированный объект — объект, составленный из подобъектов. Подобъекты называются частями агрегата, и агрегат отвечает за них.

Алгоритм — строго однозначно определенная для исполнителя последовательность действий, приводящих к решению задачи.

Альфа-тестирование (системное тестирование, лабораторные испытания) — фаза тестирования, выполняемая разработчиками для подтверждения, что все фрагменты правильно интегрированы в систему, а сама система работает надежно.

Анализ (от греч. analysis — разложение, расчленение) — прием умственной деятельности, связанный с мысленным (или реальным) расчленением на части предмета, явления или процесса. В теории проектирования анализ — это процесс определения функционирования по заданному описанию системы.

Артефакт реализации — нечто, что нельзя обнаружить в постановке решаемой задачи, но необходимое для составления программы.

Архитектура системы — структура объединения нескольких программных средств в одно целое.

АС — см. автоматизированная система.

Аттестация (certification) — авторитетное подтверждение правильности программы.

Бета-тестирование — это фаза общего тестирования, при которой программное изделие поставляется ограниченному кругу конечных пользователей для более жесткого тестирования.

Блочно-иерархический подход — частный эвроритм системного подхода, при котором процесс проектирования и представления о самом объекте расчленяется на иерархические уровни. На высшем уровне используется наименее детализированное представление, отражающее самые общие черты и особенности проектируемой системы. На каждом новом последовательном уровне разработки степень подробности рассмотрения возрастает, при этом система рассматривается не в целом, а отдельными блоками..

Визуальное моделирование — процесс графического представления модели с помощью некоторого стандартного набора графических элементов.

Внедрение — стадия, по завершении которой программная документация размножена в нужном количестве, программа установлена и сопровождается, пользователи обучены.

Восстанавливаемость программного обеспечения — свойство, характеризующее возможность приспосабливаться к обнаружению ошибок и их устранению.

Генетический анализ — исследование объекта на его соответствие законам развития программных систем. В процессе анализа изучается история развития (генезис) исследуемого объекта: конструкции аналогов и возможных частей, технологии изготовления, объемы тиражирования, языки программирования и т. д.

ГОСТ— государственный стандарт.

Деструктор — особый метод самого объекта, обеспечивающий уничтожение данного объекта.

Диаграмма вариантов использования — диаграмма, которая отображает взаимодействие между вариантами использования, представляющими функции системы, и действующими лицами, представляющими людей или системы, получающие или передающие информацию в данную систему.

Диаграмма классов — диаграмма, отражающая взаимодействие между классами системы.

Диаграмма компонент — диаграмма, показывающая, как выглядит модель на физическом уровне. На ней изображаются компоненты (файлы) программы и связи между ними.

Диаграмма кооперативная — диаграмма, отражающая ту же самую информацию, что и диаграммы последовательности, но связь со временем отсутствует.

Диаграмма последовательности — диаграмма, отражающая поток событий, происходящих в рамках варианта использования.

Диаграмма потоков данных (ДПД) — диаграмма, описывающая порядок изменения данных от их источников через преобразующие их процессы к их потребителям.

Диаграмма размещения — диаграмма, показывающая физическое расположение различных компонентов программной системы в сети.

Диаграмма состояний — диаграмма, предназначенная для моделирования различных состояний, в которых может находиться объект. В то время как диаграмма классов показывает статическую картину классов и их связей, диаграмма состояний применяется при описании динамики поведения системы.

Динамическая переменная — это как бы статическая переменная, но размещаемая в особой области памяти вне кода программы. В любой момент времени память для размещения динамических переменных может как выделяться, так и освобождаться.

Динамические структуры данных являются связными. Связность — особое продуманное логическое устройство сохранения целостности структуры данных, элементы которой могут находиться в произвольных, несмежных, неконтролируемых по адресации участках динамически распределяемой памяти вне кода программы.

Динамическое связывание — ассоциация запроса с объектом и одной из его операций во время выполнения.

Доказательство (proof) — попытки найти в программе ошибки путем доказательств на основе математических теорем о правильности программы, безотносительно к внешней программной среде.

Документ — документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение.

ДПД — Диаграмма потоков данных.

Единая система программной документации (ЕСПД) — комплекс государственных стандартов, устанавливающий взаимоувязанные правила разработки, оформления и обращения программ и программной документации.

ЕСПД — Единая система программной документации.

Жизненный цикл — совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования к ней исходных требований до окончания ее эксплуатации или потребления.

Заглушка — макет еще не реализованного модуля, необходимый при нисходящей реализации, представляет собой простейшую подпрограмму либо без действий, либо с действиями вывода входных данных, либо возвращающую в вышестоящие модули тестовые данные (которые обычно присваиваются внутри заглушки), либо содержащий комбинацию этих действий.

Иерархия — подчиненность.

Изменчивость структуры данных — изменение числа элементов и (или) связей между элементами структуры. В определении изменчивости структуры не отражен факт изменения значений элементов данных, поскольку в этом случае все структуры данных имели бы свойство изменчивости. По признаку изменчивости различают структуры: на статические структуры данных и динамические структуры данных.

Инженер (от лат. ingenium — природный ум, изобретательность) — специалист по созданию искусственных систем.

Инженерия программирования (англ. software engineering, в терминах автоматизированных систем — разработка программного обеспечения) — инженерное дело, творческая техническая деятельность. Инженерия опирается на специфические методы и методики, в том числе эвристические. Инженерия изучает различные методы и инструментальные средства с точки зрения определенных целей, то есть имеет очевидную практическую направленность. Основная идея инженерии программирования в том, что разработка программного обеспечения является формальным процессом, который можно изучать, выражать в методиках и совершенствовать. Главное различие между технологией программирования и программной инженерией заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки программ (технологических процессов) в порядке их прохождения — методы и инструментальные средства разработки программ используются в этих процессах (их применение и образуют технологические процессы). В программной инженерии изучаются, прежде всего, методы и инструментальные средства разработки программ с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Как эти методы и средства образуют технологические процессы — вопрос второстепенный.

Инженерный технологический подход определяется спецификой комбинации стадий разработки, этапов и видов работ, ориентированной на разные классы программного обеспечения и на особенности коллектива разработчиков.

Инженер-программист — наименование должности согласно квалификационному справочнику должностей руководителей, специалистов и других служащих, специалист по созданию и эксплуатации программ.

Инженер-системотехник — наименование должности согласно квалификационному справочнику должностей руководителей, специалистов и других служащих, инженер инженеров, специалист по решению проектных задач создания таких особо сложных искусственных систем, как автоматизированные системы.

Инкапсуляция — это механизм совмещения в классе полей данных с методами, которые манипулируют защищенными полями данных.

Интегрирование структуры данных — структуры данных, составными частями которых являются другие структуры данных — простые или в свою очередь интегрированные. Интегрированные структуры данных конструируются программистом с использованием средств интеграции данных, предоставляемых языками программирования.

Интерфейс — это набор форматов допустимых сообщений. Для исключения возможных, но недопустимых сообщений используется механизм сокрытия информации.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной программной среде.

Каркасные инженерные подходы представляют собой каркас для видов работ и включают их огромное количество. Ярким представителем каркасного подхода является рациональный унифицированный подход к выполнению работ (rational unified process). Весомое преимущество данного подхода состоит в созданном инструментарии его автоматизированной поддержки — программного продукта Rational Rose фирмы Rational Software Corporation.

Каскадные инженерные технологические подходы задают некоторую последовательность выполнения видов работ, обычно изображаемую в виде каскада. Эти подходы также иногда называют подходами на основе модели водопада.

Кодирование-исправление (code and fix) — инженерно-технологический подход, упрощенно может быть описан следующим образом. Разработчик начинает кодирование системы с самого первого дня, не занимаясь сколь-либо серьезным проектированием.

Кодировщик программ — программист, пишущий и автономно тестирующий код компонент программ.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания при выполнении в реальной среде.

Композиция объектов — это реализация составного объекта, состоящего из нескольких совместно работающих объектов и образующих единое целое с новой, более сложной функциональностью.

Компонентный анализ — рассмотрение объекта, включающего в себя составные элементы и входящего, в свою очередь, в систему более высокого ранга.

Конструктор — особый метод класса, предназначенный для создания экземпляра объекта.

Контейнер-менеджер, или контейнер, — класс, позволяющий объединять (агрегировать) в себе самые разные классы объектов, в том числе и другие контейнеры.

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой или моделируемой среде.

Корректность программного обеспечения — свойство безошибочной реализации требуемого алгоритма при отсутствии таких мешающих факторов, как ошибки входных данных, ошибки операторов ЭВМ (людей), сбоев и отказов ЭВМ.

Критерий — показатель качества.

Логическая структура данных — рассмотрение структуры данных без учета ее представления в машинной памяти.

ЛПР — лицо, принимающее решение.

Метод — способ практического осуществления чего-нибудь.

Методика — совокупность методов практического выполнения чего-нибудь.

Методология (от греч. metnhodos и logos — слово, учение о методах) — система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе.

Методология программирования изучает методы с точки зрения основ построения. Это объединенная единым философским подходом совокупность методов, применяемых в процессе разработки программных продуктов. Любая методология создается на основе уже накопленных в предметной области эмпирических фактов и практических результатов.

Метод мозгового штурма — метод синтеза вариантов систем, использующий взаимную стимуляцию мышления в группе.

Метод морфологических таблиц — согласно данному методу, для интересующего нас объекта формируется набор отличительных признаков: наиболее характерных подсистем, свойств или функций. Затем для каждого из них определяются альтернативные варианты реализации. Комбинируя альтернативные варианты, можно получить множество различных решений. Анализируя их, выделяют предпочтительные варианты.

Метод проб и ошибок — метод синтеза вариантов систем, основанный на последовательном выдвижении и рассмотрении идей.

Метод эвристических приемов — метод синтеза вариантов систем, базирующийся на выделении базовых приемов, найденных при анализе лучших программных изделий.

Методы объекта (methods, member functions) — подпрограммы, реализующие действия (выполнение алгоритмов) в ответ на их вызов в виде переданного сообщения.

Механизм сокрытия информации — механизм, используемый для исключения возможных, но недопустимых сообщений объектам.

Множественное наследование классов — наследование, при котором каждый класс может, в принципе, порождаться от одного или сразу от нескольких родительских классов, наследуя поведение всех своих предков.

Модель — один объект или система может выступать в роли модели другого объекта или системы, если между ними установлено сходство в каком-то смысле.

Модуль — фундаментальное понятие и функциональный элемент технологии структурного программирования, подпрограмма, но оформленная в соответствии с особыми правилами.

Модуль — в технологии объектно-ориентированного программирования это файл (unit) с описаниями родственных классов.

Модульность программ — основной принцип технологии структурного программирования, характеризуется тем, что вся программа состоит из модулей.

Наследование — определение класса и затем использование его для построения иерархии классов-потомков, причем каждый потомок наследует доступ к коду и данным всех своих классов прародителей.

Научно-исследовательская работа (НИР) — самостоятельный этап, проводимый для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.

НИР — научно-исследовательская работа.

Нисходящее проектирование — один из главных принципов технологии структурного программирования, согласно которому при разработке иерархии модулей программ выделяются первоначально модули самого верхнего уровня иерархии, а затем подчиненные модули.

Нисходящая реализация программы — в технологии структурного программирования первичная реализация группы модулей верхних уровней, которые называются ядром программы, и далее постепенно, в соответствии с планом, реализуются модули нижних уровней. Необходимые для линковки программы, недостающие модули имитируются заглушками.

Обобщение — выявление в группе классов общих свойств и вынесение их в общий базовый класс.

Объект — логическая единица, содержащая всю информацию о некотором физическом предмете или реализуемом в программе понятии, структурированная переменная типа класс, которая содержит поля данных и методы с кодом алгоритма.

Объектная модель — модель, описывающая структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы.

Объектно-ориентированное программирование (ООПр) (object-oriented programming) — это процесс реализации программ, основанный на представлении программы в виде совокупности объектов.

Объектно-ориентированное проектирование (ООП) (object-oriented design, OOD) — методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.

Объектно-ориентированный анализ (ООА) (object-oriented analysis) — методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, прагматически выявленных в предметной области.

Операции над структурами данных — над всеми структурами данных могут выполняться пять операций: создание, уничтожение, выбор (доступ), обновление, копирование.

Операционный подход к составлению алгоритмов — согласно этому подходу, операции (алгоритмические действия) выделяются последовательно по ходу пути вычислений при каких-то наборах данных.

Оптимизация разработки программ — нахождение разумного компромисса между достигаемой целью и затрачиваемыми на это ресурсами.

Организованность данных — продуманное устройство с целью рационального использованию по назначению.

ОС — операционная система.

Отладка (debugging) не является разновидностью тестирования, а является средством установления точной природы ошибок.

Параметрический анализ — установление качественных пределов развития объекта: физических, экономических, экологических и др. Применительно к программам параметрами могут быть: время выполнения какого-нибудь алгоритма, размер занимаемой памяти и т. д.

Паспорт модуля — внутренний документ проекта, который обычно представляет собой конверт с именем модуля. Внутри конверта содержатся описания прототипа вызова самого модуля и модулей, вызываемых данным модулем; расшифровка входных и выходных переменных модуля; описание функции, выполняемой модулем; принципы реализации алгоритма модуля с описанием основных структур данных.

Паттерн проектирования — это образец, типовое решение какого-либо механизма объектно-ориентированной программы.

Планирование на всех стадиях проекта — основополагающий принцип проектирования, позволяет первоначально спланировать как состав стадий, так и продолжительность всех этапов работ. Такое планирование позволяет завершить разработку в заданный срок при заданных затратах на разработку. Далее планируется порядок и время интеграции модулей во все расширяющееся ядро. Планируются мероприятия по тестированию программы от ранних до заключительных этапов.

ПО — программное обеспечение автоматизированных систем.

Повторное использование — это использование в программе класса для создания экземпляров или в качестве базового для создания нового класса, наследующего часть или все характеристики родителя. Повторное использование сокращает объем кода, который необходимо написать и оттестировать при реализации программы, что сокращает объемы труда.

Подпрограмма — некоторая последовательность инструкций, которая может вызываться в нескольких местах программы; программная единица, компилируемая независимо от остальных частей программы. В объектно-ориентированном программировании соответствует методу.

Позднее связывание — связи между объектами определяются динамически во время выполнения программы, сам процесс связывания заключается в замене адресов памяти виртуальных функций.

Показатели качества (критерии) — величины, свойства, понятия, характеризующие систему с точки зрения субъекта, позволяющие оценить степень удовлетворения его потребностей.

Поле объекта (data members) — порция данных объекта, значения которых определяют текущее состояние объекта.

Полиморфизм — это средство для придания различных значений одному и тому же событию в зависимости от типа обрабатываемых данных, т. е. полиморфизм определяет различные формы реализации одноименного действия.

Порт — программный механизм накопления и верификации как входных, так и выходных данных в соответствующих очередях.

Потомок — класс, используемый характеристики другого класса посредством наследования.

Предок — это класс, предоставляющий свои возможности и характеристики другим классам.

Программная документация — единая система программной документации (ЕСПД).

Программный документ — документ, содержащий сведения, необходимые для разработки, изготовления, эксплуатации и сопровождения программного изделия.

Программный продукт — программа, которую можно запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в едином стиле, тщательно оттестирована до требуемого уровня надежности, сопровождена подробной документацией и подготовлена для тиражирования. Стандартный термин — программное изделие.

Программное изделие — программа на носителе данных, являющаяся продуктом промышленного производства.

Программное обеспечение автоматизированных систем (ПО) — совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности автоматизированных систем.

Проект (от лат. projectus — брошенный вперед) — совокупность проектных документов в соответствии с установленным перечнем, которая представляет результат проектирования.

Проектирование — это разработка проекта, процесс создания спецификации, необходимой для построения в заданных условиях еще несуществующего объекта на основе первичного описания этого объекта. Результатом проектирования является проектное решение или совокупность проектных решений, удовлетворяющих заданным требованиям. Заданные требования обязательно должны включать форму представления решения.

Проектная задача (англ. engineering Task) — характеризуется неопределенностью априори информации: что требуется получить, что задано. Более того, способ решения задачи является объектом проектирования. И наконец, решение проектной задачи должно быть найдено в рамках ограничений внешней среды: доступных денежных средств, заранее заданных сроков, возможностями технических средств и инструментария программирования, научных знаний программных заделов и т. д.

Проектная операция — действие или формализованная совокупность действий, составляющих часть проектной процедуры, алгоритм которых остается неизменным для ряда проектных процедур, например вычерчивание схемы, дифференцирование функции.

Проектная процедура (методика), составления функциональных описаний — методика разработки описаний функционирования систем, отличающаяся использованием особого структурирования. Инструкция пользования каким-либо устройством, инструкция вообще или алгоритм программы являются описаниями функционирования.

Проектная ситуация — реальность (ситуация), в которой ведется проектирование.

Проектное решение — описание в заданной форме объекта проектирования или его части, необходимое и достаточное для определения дальнейшего направления проектирования.

Проектный документ — документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение. В программировании проектные решения оформляются в виде программной документации. Различают внешнюю программную документацию, которая согласуется с заказчиком, и внутреннюю промежуточную документацию проекта, которая необходима самим программистам для их работы.

Простое наследование классов — наследование, при котором определенный пользователем класс имеет только одного родителя. Схема иерархии классов в этом случае представляет собой ряд одиночно стоящих деревьев (hierarchical classification).

Простые структуры данных не могут быть расчленены на составные части, большие, чем биты и байты. С точки зрения физической структуры важным является то обстоятельство, что в данной машинной архитектуре, в данной системе программирования мы всегда можем заранее сказать, каков будет размер данного простого типа и какова структура его размещения в памяти. С логической точки зрения простые данные являются неделимыми единицами. В языках программирования простые структуры описываются простыми (базовыми) типами. Простые структуры данных служат основой для построения более сложных интегрированных структур.

Профессиональный программист — это специалист, который обладает интегральной личностной характеристикой человека: добивается мастерства в программировании, следует профессиональной ценностной ориентации, соблюдает профессиональную этику, владеет искусством общения с людьми, стремится и умеет вызвать интерес общества к результатам своей профессиональной деятельности.

Рабочий проект (РП) — наименование стадии и программный документ, содержащий описание реализованного изделия.

Раннее связывание — связи между объектами определяются статически во время компиляции.

Резидентная программа — не удаляемая ОС программа, постоянно находящаяся в оперативной памяти ЭВМ.

Родитель — непосредственный класс-предок, стоящий у корня схемы иерархии, и от которого порождаются первые потомки, а от потомков еще потомки.

Родительский класс — начальный класс, от которого наследуются классы-потомки.

РП — рабочий проект.

САПР — система автоматизированного проектирования.

Свойства (property) — это особым образом оформленные методы, предназначенные как для чтения и контролируемого изменения внутренних данных объекта (полей), так и выполнения действий, связанных с поведением объекта.

Сессия программистов — встреча кодировщиков для проведения взаимной инспекции текстов программ и набора использованных тестов.

Синтез (от греч. synthesis — соединение, сочетание, составление) — метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое. В теории проектирования синтез — это процесс построения описания системы по заданному функционированию.

Система — множество элементов, находящихся в отношениях и связях друг с другом, которое образует определенную целостность, единство.

Системный аналитик — программист, разрабатывающий проект от требований до внутренней структуры программы и участвующий в тестировании как при интеграции компонентов в ядро, так и в комплексном тестировании ПО.

Системный подход — общенаучный обобщенный эвроритм, предусматривающий всестороннее исследование сложного объекта с использованием компонентного, структурного, функционального, параметрического и генетического видов анализа.

Сквозной структурный контроль — использование на многих этапах проекта контроля корректности спецификации связей частей программы.

Слияние — объединение нескольких небольших, но тесно взаимодействующих классов в один.

Сопровождение — деятельность по оказанию услуг, необходимых для обеспечения устойчивого функционирования или развития программного изделия, включает анализ функционирования, развитие и совершенствование программы, а также внесение изменений в нее с целью устранения ошибок.

Спецификация — в сфере проектной деятельности это какое-либо описание в точных терминах.

Стадия проекта — одна из частей процесса создания программы, установленная нормативными документами и заканчивающаяся выпуском проектной документации, содержащей описание полной, в рамках заданных требований модели программы на заданном для данной стадии уровне, или изготовлением программ. По достижении стадии заказчик имеет возможность рассмотреть состояние проекта и принять решение по дальнейшему продолжению проектных работ.

Стратегия (от греч. stratos — войско и ago — веду) — наука, искусство генерации наиболее существенных общих долгосрочных целей и наиболее общего плана достижения преимущества, курса действий и распределения ресурсов еще до выполнения реальных действий. Стратегия охватывает теорию и практику подготовки к выполнению проекта, а также наиболее общее планирование тактик ведения проектов. Стратегия определяет, куда, в каком направлении двигаться, куда держать курс еще до начала проекта. А тактика определяет, как, каким способом двигаться, какие конкретные действия предпринимать при затруднениях в ходе выполнения проекта.

Структура программы — искусственно выделенные программистом взаимодействующие части программы.

Структура данных программы — множество элементов данных, множество связей между ними, а также характер их организованности.

Структурное кодирование модулей программ — основной принцип технологии структурного программирования, воспринятый технологией объектно-ориентированного программирования, который заключается в особом оформлении текстов модулей (методов). У модуля должен быть легко различимый заголовок с комментарием, поясняющим функциональное назначение модуля. Имена переменных должны быть мнемоническими. Суть переменных и порядок размещения в них информации должны быть пояснены комментариями, а код закодирован с использованием типовых алгоритмических структур.

Структурный анализ — выявление элементов объекта и связей между ними.

Структурный подход — набор принципов, характеризующий технологию структурного программирования: модульность программ; структурное кодирование модулей программ; нисходящее проектирование рациональной иерархии модулей программ; нисходящая реализация программы с использованием заглушек; осуществление планирования на всех стадиях проекта; сквозной структурный контроль программных комплексов в целом и составляющих их модулей.

СУБД — система управления базами данных.

Схема иерархии программы — используется в технологии структурного программирования, отражает только подчиненность модулей (подпрограмм), но не порядок их вызова или функционирование программы.

Сценарий — последовательность событий, которая может иметь место при конкретном выполнении системы.

Сценарий диалога программы — последовательность ввода и вывода информации в диалоговом режиме работы программы.

Тактика (от греч. taktika — искусство приводить в порядок) — фиксированная в своей последовательности совокупность средств и приемов для достижения намеченной цели и искусство ее применения, способы действия, ориентированные на достижение конкретных целей, являющиеся звеньями реализации стратегических целей. Целью применения способа действия является совершение оптимальных действий в заранее не предсказанных стратегическим планом ситуациях уже в процессе выполнения реальных действий.

Тестирование (testing) — процесс выполнения программы с намерением найти ошибки; может осуществляться как с ЭВМ, так и без ЭВМ.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование сопряжений (integration testing) — контроль сопряжений между частями системы как между компонентами в комплексе, так и между модулями отдельного компонента (например, у заглушки).

Тестировщик — программист, готовящий наборы тестов для отладки разрабатываемого программного изделия.

Технический проект (ТП) — комплект проектных документов на программу, разрабатываемый на стадии "Технический проект", утвержденный в установленном порядке, содержащий основные проектные решения по программе в целом, ее функциям и достаточный для разработки рабочего проекта.

Техническое задание (ТЗ) — документ, оформленный в установленном порядке и определяющий цели создания программы, требования к программе и основные исходные данные, необходимые для ее разработки, а также план-график создания программы.

Технология (от греч. techne — искусство, мастерство, умение и logos — слово, учение) — совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства, совокупность приемов, применяемых в каком-либо деле, мастерстве, искусстве. Современная методология проектирования позволила довести методы проектирования до технологий с набором методик.

Технология визуального программирования — популярная инженерия программирования, состоящая в автоматизированной разработке программ с использованием особой диалоговой оболочки.

Технология объектно-ориентированного программирования — технология, ориентированная на получение программ, состоящих из объектов.

Технология программирования как наука изучает технологические процессы и порядок их прохождения (с использованием знаний, методов и средств). Технологический процесс — последовательность направленных на создание заданного объекта действий (технологических процедур и операций), каждое из которых основано на каких-либо естественных процессах и человеческой деятельности. Обратим внимание на то, что знания, методы и средства могут использоваться в разных процессах и, следовательно, в технологиях. Технология программирования для инженера — это научная и практически апробированная стратегия создания программ, содержащая описание совокупности методов и средств разработки программ, а также порядок применения этих методов и средств.

Технология программирования Дейкстры, основанная на абстракции данных — в данной технологии во главе ставятся данные; сначала очень тщательно специфицируется выход, вход, промежуточные данные; большое внимание уделяется типизации данных с использованием структур для объединения близкой по смыслу информации в единые данные.

Технология структурного программирования — технология, основанная на структурном подходе.

Типизация — это способ защититься от использования объектов одного класса вместо другого или, по крайней мере, управлять таким использованием. Типизация заставляет нас выражать наши абстракции так, чтобы язык программирования, используемый в реализации, поддерживал соблюдение принятых проектных решений.

ТП — технический проект.

Управление разработкой программных систем (software management) — деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков программного обеспечения, планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПО, выполнения сроков и бюджета разработки ПО.

Устойчивость программного обеспечения — свойство осуществлять требуемое преобразование информации при сохранении выходных решений программы в пределах допусков, установленных спецификацией при воздействии на программы таких факторов неустойчивости, как ошибки операторов ЭВМ, а также не выявленных ошибок программы.

Физическая структура данных — способ физического представления данных в памяти машины и называется еще структурой хранения, внутренней структурой, структурой памяти, или дампом.

Форма — визуальный компонент, обладающий свойством окна Windows.

Функция системы — совокупность действий системы, направленная на достижение определенной цели.

Функциональный анализ — рассмотрение объекта как комплекса выполняемых им функций.

Эвристика — наука, раскрывающая природу мыслительных операций человека при решении конкретных задач независимо от их конкретного содержания. В более узком смысле, эвристика — это догадки, основанные на опыте решения родственных задач.

Эвроритм — порядок действия человека при выполнении какой-то деятельности. В отличие от алгоритма может изменяться в процессе исполнения благодаря разумности исполнителя.

Экземпляр класса — объект.

Эксплуатационная документация — часть рабочей документации на программу, предназначенная для использования при эксплуатации программы и определяющая правила действия персонала и пользователей программы при ее функционировании, проверке и обеспечении ее работоспособности.

Экстремальное программирование (extreme programming) (XP) — адаптивный инженерный подход, рациональное объединение известных методов и их совокупное использование дает существенные результаты и успешно выполненные проекты при разработке небольших систем, требования к которым четко не определены и вполне могут измениться.

Эскизный проект (ЭЛ) — комплект проектных документов на программу, разрабатываемый на стадии "Эскизный проект", утвержденный в установленном порядке, содержащий описание нескольких альтернативных вариантов реализации будущего изделия и уточненные требования на основе их анализа. Степень проработки при этом должна быть достаточной лишь для достижения возможности сравнения вариантов.

ЭТ — электронная таблица.

Этап проекта — часть стадии проекта, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей.

Ядро — всеувеличивающаяся уже реализованная часть программы.

CASE-средства — это программные средства, поддерживающие процессы создания и сопровождения программных продуктов, включая анализ и формулировку требований, проектирование продукта и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки программных систем.

CASE-технология (Computer Aided Software Engineering) — технология, представляющая собой методологию проектирования АС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения программных систем и разрабатывать приложения в соответствии с информационными потребностями пользователей.

СОМ — Component Object Model.

Component Object Model (модель компонентных объектов) — спецификация метода создания компонент и построения из них программ.

CRC-карточка (Component, Responsibility, Collaborator — объект, обязанности, сотрудники) — промежуточный документ проекта, необходимый для специфицирования объектов.

DFD — ДПД (Data Flow diagramm).

RDD-проектирование (Responsibility-Driven-Design) — технология проектирования на основе обязанностей, предложенная Т. Бадтом. Данная технология по способу мышления аналогична разработке структуры служб какой-то организации: директора, заместителей директора, служб и подразделений.

ЛИТЕРАТУРА

1. Автоматизация поискового конструирования (искусственный интеллект в машинном проектировании) / А.И. Половинкин. — М.: Радио и связь, 1981. — 344 с.

2. Бадд Т. Введение в объектно-ориентированное программирование (Addison-Wesley, СПб).

3. Боггс У., Боггс М. UML и Rational Rose / Пер. с англ. И. Афанасьева; Под ред. А. Вендрова. — М.: Лори, 2001. — 580 с.

4. Брукс Ф.П. Как проектируются и создаются программные комплексы: Мифический человеко-месяц. Очерки по систем, программир. / Ф.П. Брукс; Пер. с англ. Н.А. Черемых; Под ред. А.П. Ершова. — М.: Наука, 1979. — 151 с.

5. Буч Г. Объектно-ориентированное проектирование с примерами применения / Г. Буч; Пер. с англ. — М.: Конкорд, 1992, — 519 с.

6. Буч Г., Рамбо Д, Джекобсон A. UML руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон; Пер. с англ. — М.: ДМК Пресс, 2001. — 432 с.

7. ГОСТ-19. Единая система программной документации. УДК 651.7/.78:681.3.06:002:006.354. Группа Т55 СССР.

8. ГОСТ-34. Автоматизированные системы УДК 668.012.011.56:066.354. Группа П87 СССР.

9. Дал У., Дейкстра Э., Хоор К. Структурное программирование / У. Дал, Э. Дейкстра, К. Хоор; Пер. с англ. — М.: Мир, 1975. — 247 с.

10. Дарахвелидзе П.Г., Марков Е.П. Delphi среда визуального программирования. — СПб.:ВНУ-Санкт-Петербург, 1996, — 352 с.

11. Йодан Э. Структурное проектирование и конструирование программ / Э. Йодан; Пер. с англ. В.В. Фролова, Л.А. Теплицкого; Под ред. Л.Н. Королева. — М.: Мир, 1979. — 360 с.

12. Пойа Д. Математическое открытие. — М.: Наука, 1976. — 389 с.

13. Роджерсон Д. Основы СОМ / Пер. с англ. — М.: Изд. отдел "Русская редакция" ТОО "Channel Trading Ltd.", 1997. — 376 с.

14. Хьюз Дж., Мичтом Дж. Структурный подход к программированию / Дж. Хьюз, Дж. Мичтом; Пер. с англ. Э.М. Киуру и А.Л. Александрова; Под ред. В.Ш. Кауфмана. — М.: Мир, 1980. — 278 с.

Литература второго издания

15. Бабий А.А. О некоторых характеристиках личной производительности труда программистов. // УСИМ, 1985, № 6, с. 17–19.

16. Жоголев Е.А. Технология программирования / Е.А. Жоголев. — М.: Научный мир, 2004. — 216 с.

17. Д. Кнут. Искусство программирования / Кнут Дональд. — М: Вильямс. 3-е издание. 2000.

Том 1. Основные алгоритмы. 720 с.

Том 2. Получисленные алгоритмы. 832 с.

Том 3. Сортировка и поиск. 832 с.

18. Костин Е.Е., Шанъгин В.Ф. Организация и обработка структур данных в вычислительных системах. — М.: Высш. школа, 1987. — 242 с.

19. Модели и структуры данных. Учеб. пособие / В.Д. Далека, А.С. Деревянко, О.Г. Кравец, Л.Е. Тимановская. — Харьков: ХГПУ, 2000.

20. Одинцов И.О. Профессиональное программирование. Системный подход / И.О. Одинцов. — СПб: BHV-СПб., 2002. — 512 с.

21. Трофимова И.П. Системы обработки и хранения информации. — М.: Высш. школа, 1989. — 191 с.

22. Химмельблау Д. Прикладное нелинейное программирование / Д. Химмельблау; Пер. с англ. И.Н. Быховской и Б.Т. Вавилова; Под ред. М.Л. Быховского. — М.: Мир, 1975. — 534 с.

23. www.popoff.donetsk.ua — Соглашения об именах.

Content

КАМАЕВ В.А., КОСТЕРИН В.В
ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ

ПРЕДИСЛОВИЕ

ВВЕДЕНИЕ

Глава 1 МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1. ОБЩИЕ ПОЛОЖЕНИЯ ТЕОРИИ ПРОЕКТИРОВАНИЯ

1.2. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММ

1.3. СИСТЕМНЫЙ ПОДХОД И ПРОГРАММИРОВАНИЕ

1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

1.5. ОСОБЕННОСТИ ПРОГРАММНЫХ РАЗРАБОТОК

1.6. СТАНДАРТЫ И ПРОГРАММИРОВАНИЕ

1.7. ОПИСАНИЕ ЦИКЛА ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ

1.9. ТИПОВЫЕ ОШИБКИ ОБУЧАЕМЫХ ПРИ СОСТАВЛЕНИИ ТЕХНИЧЕСКОГО ЗАДАНИЯ

1.10. МОДЕЛИРОВАНИЕ И ПРОГРАММИРОВАНИЕ. ПОНЯТИЕ СПЕЦИФИКАЦИЙ

1.11. МНЕМОНИКА ИМЕН В ПРОГРАММАХ

1.12. ПРОБЛЕМА ТИПОВЫХ ЭЛЕМЕНТОВ В ПРОГРАММИРОВАНИИ

Глава 2 ОПТИМИЗАЦИЯ ПРОГРАММНЫХ РАЗРАБОТОК

2.1. ВЫБОР ОПТИМАЛЬНОГО ВАРИАНТА ПРОЕКТНОГО РЕШЕНИЯ

2.2. ПРИМЕР ВЫБОРА ОПТИМАЛЬНОГО ВАРИАНТА ПРОГРАММНОГО РЕШЕНИЯ

2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ

2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ

2.5. ПРОЕКТНАЯ ПРОЦЕДУРА ПОСТАНОВКИ ЗАДАЧИ РАЗРАБОТКИ ПРОГРАММЫ

2.6. ПСИХОФИЗИОЛОГИЧЕСКИЕ ОСОБЕННОСТИ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И ЭВМ

2.7. КЛАССИФИКАЦИЯ ТИПОВ ДИАЛОГА ПРОГРАММ

Глава 3 ОСНОВНЫЕ ИНЖЕНЕРНЫЕ ПОДХОДЫ К СОЗДАНИЮ ПРОГРАММ

3.1. ОСНОВНЫЕ СВЕДЕНИЯ

3.2. РАННИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

3.6. ПОДХОДЫ НА ОСНОВЕ ФОРМАЛЬНЫХ ПРЕОБРАЗОВАНИЙ

3.7. РАННИЕ ПОДХОДЫ БЫСТРОЙ РАЗРАБОТКИ

3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ

Глава 4 СТРУКТУРА ДАННЫХ ПРОГРАММ

4.1. ПОНЯТИЕ СТРУКТУРЫ ДАННЫХ ПРОГРАММ

4.2. ОПЕРАЦИИ НАД СТРУКТУРАМИ ДАННЫХ

4.3. ОБЩАЯ КЛАССИФИКАЦИЯ ЛОГИЧЕСКИХ СТРУКТУР ДАННЫХ

4.4. КЛАССИФИКАЦИЯ ВИДОВ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ ПО ИХ ЛОГИЧЕСКОМУ УСТРОЙСТВУ

4.5. ПРОЕКТИРОВАНИЕ И ДОКУМЕНТИРОВАНИЕ ОПЕРАТИВНЫХ СТРУКТУР ДАННЫХ

4.6. ФАЙЛОВЫЕ СТРУКТУРЫ

Глава 5 ПРОЕКТНАЯ ПРОЦЕДУРА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ ОПИСАНИЙ

5.1. ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТНОЙ ПРОЦЕДУРЕ

5.2. ИСТОРИЯ ВОЗНИКНОВЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ

5.3. ОБЩЕЕ ОПИСАНИЕ ПРОЕКТНОЙ ПРОЦЕДУРЫ

5.4. РЕКОМЕНДАЦИИ НАЧИНАЮЩИМ ПО СОСТАВЛЕНИЮ ОПИСАНИЙ АЛГОРИТМОВ И ЭВРОРИТМОВ

5.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССА "КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ"

5.6. ПРИМЕР ОПИСАНИЯ ПРОГРАММЫ "РЕДАКТОР ТЕКСТОВ"

5.7. РЕФАКТОРИНГ АЛГОРИТМОВ И ЭВРОРИТМОВ

5.8. КОДИРОВАНИЕ ТИПОВЫХ СТРУКТУР НА ЯЗЫКАХ ПРОГРАММИРОВАНИЯ

5.9. МЕТОДИКА РАЗРАБОТКИ АЛГОРИТМОВ ПРОГРАММ

5.10. ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОЙ РАБОТЫ "РАЗРАБОТКА АЛГОРИТМА УМНОЖЕНИЯ"

5.11. ПРИМЕР ПРИМЕНЕНИЯ ПРОЕКТНОЙ ПРОЦЕДУРЫ ДЛЯ КОДИРОВАНИЯ ПРОГРАММЫ ПЕЧАТИ КАЛЕНДАРЯ НА ПРИНТЕРЕ

Глава 6 АРХИТЕКТУРА ПРОГРАММНЫХ СИСТЕМ

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ

6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ

6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ

6.5. ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ

6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ

Глава 7 ТЕХНОЛОГИЯ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

7.1. ПОНЯТИЕ СТРУКТУРЫ ПРОГРАММЫ

7.2. МОДУЛЬ И ОСНОВНЫЕ ПРИНЦИПЫ СТРУКТУРНОГО ПОДХОДА

7.3. РЕТРОСПЕКТИВНОЕ ПРОЕКТИРОВАНИЕ ДЕМОНСТРАЦИОННОЙ ПРОГРАММЫ MCALC ФИРМЫ "BORLAND INC."

Глава 8 ТЕХНОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

8.1. ИСТОРИЯ СОЗДАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

8.2. ВВЕДЕНИЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММ

8.3. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ

8.4. ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ

8.5. ОСНОВНЫЕ ПОНЯТИЯ, ИСПОЛЬЗУЕМЫЕ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ЯЗЫКАХ

8.6. ЭТАПЫ И МОДЕЛИ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ ТЕХНОЛОГИИ

8.7. КАКИМИ БЫВАЮТ ОБЪЕКТЫ ПО УСТРОЙСТВУ

8.8. ПРОЕКТНАЯ ПРОЦЕДУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ПО Б. СТРАУСТРУПУ

8.9. ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ОБЯЗАННОСТЕЙ

8.10. ПРИМЕР РЕТРОСПЕКТИВНОЙ РАЗРАБОТКИ ИЕРАРХИИ КЛАССОВ БИБЛИОТЕКИ ВИЗУАЛЬНЫХ КОМПОНЕНТ DELPHI И C++ BUILDER

8.11. АЛЬТЕРНАТИВНЫЙ ПРОЕКТ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА

8.12. ПРОЕКТ АСУ ПРЕДПРИЯТИЯ

8.13. ОБЗОР ОСОБЕННОСТЕЙ ПРОЕКТОВ ПРИКЛАДНЫХ СИСТЕМ

8.14. ГИБРИДНЫЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

Глава 9 ВИЗУАЛЬНОЕ ПРОГРАММИРОВАНИЕ

9.1. ОБЩЕЕ ПОНЯТИЕ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ

9.2. ТЕХНОЛОГИЯ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ

Глава 10 CASE-СРЕДСТВА И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ

10.1. ПРЕДПОСЫЛКИ ПОЯВЛЕНИЯ CASE-СРЕДСТВ

10.2. ОБЗОР CASE-СИСТЕМ

10.3. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ В RATIONAL ROSE

10.4. ДИАГРАММЫ UML

10.5. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ И ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

10.6. РАБОТА НАД ПРОЕКТОМ В СРЕДЕ RATIONAL ROSE

Глава 11 ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

11.1. ОСНОВНЫЕ СВЕДЕНИЯ

11.2. СВОЙСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

11.3. СВЯЗЬ ПРОЦЕССОВ ТЕСТИРОВАНИЯ С ПРОЦЕССОМ ПРОЕКТИРОВАНИЯ

11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ

11.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ

11.6. КРИТЕРИИ ВЫБОРА НАИЛУЧШЕЙ СТРАТЕГИИ РЕАЛИЗАЦИИ

11.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ

11.8. ПРОЕКТИРОВАНИЕ КОМПЛЕКСНОГО ТЕСТА

11.9. СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Глава 12 МЕНЕДЖМЕНТ ПРОГРАММНЫХ РАЗРАБОТОК

12.1. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ СИСТЕМ

12.2. СТРУКТУРА УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ СРЕДСТВ

12.3. ПОДБОР КОМАНДЫ

12.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ

12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ

12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА

12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

12.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ

12.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

12.10. РЕАЛИЗАЦИЯ

12.11. СИСТЕМНОЕ ТЕСТИРОВАНИЕ

12.12. ПРИЕМОЧНЫЙ ТЕСТ

12.13. ПОСЛЕРЕАЛИЗАЦИОННЫЙ ОБЗОР

12.14. СОПРОВОЖДЕНИЕ ПРОГРАММ

Приложение 1 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102-77

Приложение 2 ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОГО ТЕХНИЧЕСКОГО ЗАДАНИЯ

Приложение 3 ФОНД ЭВРИСТИЧЕСКИХ ПРИЕМОВ ПРОЕКТИРОВАНИЯ ПРОГРАММ

Приложение 4 ЭЛЕМЕНТЫ ЯЗЫКА OBJECT PASCAL

Приложение 5 ОСНОВНЫЕ ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

ЛИТЕРАТУРА