Занятие 4. Начальное проектирование

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

Имеющаяся литература по программированию отличается своего рода академическим подходом. Ученику подробно преподносятся синтаксис и лексика языка, в лучшем случае даются описания некоторых приемов работы с теми или иными средствами разработки. Но мало где описывается, как и в каком порядке следует создавать приложение. Если для других языков (C++, Java) еще можно отыскать руководства, поясняющие процесс создания программ, то для VBA таких учебников нет. В свою очередь, книги, посвященные процессу создания программных продуктов, как правило, написаны очень своеобразным тяжелым языком, и для начинающих малодоступны.

Понятие о процессе создания приложения. Итеративный процесс

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

Описание процесса создания приложения

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

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

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

Формулировка требований

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

Анализ

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

Затем определяются взаимозависимости между объектами. Зависимости могут быть, к примеру, такими:

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

Подобные схемы облегчают наглядность описаний, и, более того, выступают обязательными элементами проектной документации. Существуют несколько нотаций-языков, принятых как стандарты изображения элементов схем. Наиболее известный, мощный – и общепринятый язык – UML, Unified Modeling Language – Унифицированный Язык Моделирования. При составлении схем данного учебника применялся именно этот язык.

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

Выявленная объектная область служит основой следующего этапа – проектирования приложения.

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

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

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

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

На таких схемах стрелками поясняется последовательность.

Составление последовательностей действий завершает этап проектирования.

Реализация

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

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

Реализация начинается с определения оптимальной платформы для приложения. В общем случае разработчик начинает с выбора типа компьютера и операционной системы, затем – языка программирования и объектных библиотек. Очевидно, это подразумевает довольно глубокое знание предмета. Приложения, предназначенные для «обычного» пользователя, как правило, создаются для операционной системы MS Windows различных версий, что, в свою очередь, предопределяет выбор типа компьютера – IBM PC-совместимый. В нашем случае выбор еще меньше – учебник посвящен языку VBA, который является составной частью пакета MS Office.

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

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

Отладка

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

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

Развертывание

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

Сопровождение

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

Недостатки последовательного процесса

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

Итеративный процесс

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

Именно итеративный процесс и будет показан в этой книге.

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

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

Требования

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

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

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

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

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

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

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

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

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

Наиболее распространенная ошибка начинающих – попытка создания пользовательского интерфейса на ранних стадиях проекта.

Анализ

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

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

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

• виды деятельности, то есть то, что будет делать приложение,
• объектную область – то есть абстрактные сущности, составляющие приложение и участвующие в деятельности приложения.

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

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

Выделение видов деятельности

Выделим виды деятельности, которые будет осуществлять будущее приложение.

Это:

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

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

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

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

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

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

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

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

• Нарисуйте схему, подобную этой:

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

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

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

Выделение объектов

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

Составим список:

• вопрос
• ответ
• сводка

Выделим не указанные явно, но подразумеваемые объекты, необходимые для осуществления имеющихся видов деятельности:

• «выводитель» вопросов
• «выводитель» ответов
• «выбиратель» ответа
• «учетчик» ответов
• «выводитель» сводки
• хранилище ответов

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

И еще объекты, не указанные, но, очевидно, подразумеваемые:

• набор вопросов
• набор ответов на один вопрос
• набор наборов ответов

Обратите внимание: виды деятельности соответствуют глаголам текста требования, объекты – существительным.

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

Подсказка. Первый список объектов взят из требования. Это – основной список.

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

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

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

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

На ранних этапах анализа и проектирования не надо выделять объекты, которые будут характеризовать компоненты будущей программы – например, не следует включать в список объектов «лист Excel». Мы пока описываем абстрактную сущность  «хранилище ответов», не указывая, каким образом она будет реализована.

Дополнение наборов видов деятельности и объектов

Исходя из третьего списка объектов, выделим еще несколько видов деятельности:

• переход по списку вопросов.

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

• обновление отображения вопроса на экране
• обновление списка ответов, относящихся к этому вопросу.

Очевидно, появится дополнительный объект:

• «переходитель» от вопроса к вопросу.

• Самостоятельно создайте новые схемы видов деятельности и объектов с учетом появившихся только что изменений.

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

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

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

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

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

Итог занятия

Составляем конспект.

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

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

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

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