В конкретной организации и конкретном проекте вырабатывается стандарт анализа и проектирования (это особенно актуально при коллективной разработке ПО большим количеством групп специалистов).
Стандарт должен устанавливать:
- набор необходимых моделей (диаграмм) на стадиях анализа и проектирования и степень их детализации;
- правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм (включая требования к форме и размерам объектов) и т. д.;
- требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств и т. д.;
- механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т. д.), правила анализа проектных решений на непротиворечивость и т. д.
Под моделью понимается полное описание ПО (любой системы) с определенной точки зрения. Модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. Моделирование является центральным звеном всей деятельности по созданию качественного ПО.
Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.
Очевидно, что конечная цель разработки ПО — это не моделирование, а получение работающих приложений (кода). Диаграммы в конечном счете — это всего лишь наглядные изображения.
Уточним цели анализа и формирования требований к ПО.
Анализ является первым этапом создания ПО, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?".
Именно стадия анализа и формирования требований к ПО определяет успех всего проекта. Необходимо на более ранних стадиях разработки понять, что будет представлять собой создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость разработки.
Целью анализа является преобразование общих, расплывчатых знаний об исходной предметной области в точные определения и спецификации, а также генерация функционального описания системы.
В случае создания ПО для информационной системы (ИС) управления предприятием (ИС — совокупность средств, методов и персонала для обработки, хранения и выдачи информации) структурный анализ начинается с исследования того, как организована система управления предприятием, с обследования функциональной и информационной структуры системы управления.
По результатам обследования аналитик строит модель "как есть": обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется.
Далее создают модель "как надо": усовершенствованную обобщенную логическую модель, отображающую реорганизованную предметную область или ее часть, которая подлежит автоматизации. Эта стадия анализа содержит элементы проектиро-вания.
На практике стадия планирования реорганизованной деятельности предприятия применяется крайне редко. Такую работу могут выполнить для заказчиков лишь крупные, специализированные консалтинговые фирмы, способные подключить к работе специалистов-экспертов в той области деятельности, которая подлежит автоматизации.
В большинстве случаев модель "как есть" улучшается системным аналитиком за счет устранения очевидных несоответствий и узких мест, а полученный таким образом вариант модели рассматривается в дальнейшем в качестве модели "как надо".
На этапе анализа и формирования требований к ПО необходимо задокументировать выдвинутые предложения, т.к. если проектные требования не зафиксированы и не сделаны доступными для участников разработки, то они вроде бы и не существуют вовсе. При этом язык, на котором формулируются результаты анализа, должен быть достаточно прост и понятен заказчику. Поэтому модели создаются в соответствии с общеупотребительными стандартами.
Результаты отражаются в "Техническом задании" на проект (разработку) в соответствии с ГОСТ 34.602-89. Информационная технология. Техническое задание на создание АС. "Техническое задание" содержит общие сведения, назначение и цель создания, требования к системе в целом, к информационному, программному, техническому обеспечению, т.д.
Прежде чем подробно рассматривать каждый из основных методов структурного анализа, необходимо обсудить их в общем виде и продемонстрировать их взаимосвязи.
Для моделирования систем вообще, и в структурном анализе в частности, используются три группы методов, иллюстрирующих:
- функции, которые система должна выполнять;
- отношения между данными;
- зависящее от времени поведение системы (аспекты реального времени).
Среди множества методов решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяются:
- FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;
- DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов (или миниспецификациями);
- ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь";
- STD (State Transition Diagrams) - диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования: первые — для удобства демонстрирования основных компонент модели, вторые — для обеспечения точного определения ее компонент и связей.
Построение CASE-моделей целесообразно выполнять в следующем порядке (рис. 7.1): I — этап "Обследование объекта и обоснование необходимости создания АС", II — этап "Разработка и утверждение технического задания на создание АС".
Рис. 7.1. Временная шкала построения моделей
1) По результатам обследования предметной области строится модель функциональной декомпозиции (FDD) объекта.
Примеры объектов: любой объект автоматизации (работа библиотеки, работа склада, чья-то профессиональная деятельность) в случае разработки ПО для автоматизации какой-либо работы, чьей-либо деятельности, рабочих мест; система управления предприятием в случае создания ПО для ИС.
На этом уровне определяются все функции, которые выполняет объект, и процессы, протекающие в объекте (например, подразделениях предприятия) для выполнения функций, определяются связи между функциями, между процессами.
Функция - преобразование входных потоков в выходные, осуществляемое в соответствии с некоторыми внутренними правилами. Выполнение функции обеспечивает процесс.
Процесс - совокупность взаимосвязанных действий (работ), преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Для представления результатов моделирования может использоваться нотация IDEF0 (Function Modeling Method — функциональное моделирование), разработаная на основе методологии структурного анализа и разработки SADT (Structured Analysis and Design Technique), и нотация IDEF3 (Process Flow and Object Stale Description Capture Method — моделирование деятельности), которая позволяет проследить логику взаимодействия процессов (действий, работ).
IDEF — Icam Definition — методология моделирования программы ICAM. ICAM — Integrated Computer Aided Manufacturing — интегрированная компьютеризация производства. IDEF0 является основной частью программы ICAM, проводимой по инициативе ВВС США.
На этапе разработки технического задания приводится текстовое описание назначения системы в документе "Техническое задание", в разделе "Назначение и цели создания системы", подразделе "Назначение системы".
Текстовое описание предметной области и смешанная модель в нотациях IDEF0 и IDEF3 приводятся в документе "Техническое задание", в разделе "Характеристика объекта автоматизации".
Эта же информация приводится на этапе формирования требований к ПО в документе "Тактико-техническое задание".
Функциональные диаграммы модели являются предварительным этапом для построения диаграмм потоков данных (DFD) и позволяют получить общее представление о распределении функций и процессов.
2) По функциональной модели (FDD) предметной области строится совокупность (иерархия) диаграмм потоков данных (DFD).
Диаграммы потоков данных, используя функции, описанные на уровне функциональной модели (FDD), позволяют детализировать описание предметной области за счет введения накопителей, потоков данных и внешних сущностей.
Накопитель (хранилище) данных — приспособление для хранения информации, обладающее возможностью записи и извлечения данных. Способы доступа и хранения данных в накопителях в ходе анализа не уточняются. Хранилища являются прообразами файлов или баз данных.
Поток данных — канал передачи данных от источника к приемнику. В качестве источников и приемников данных для потоков могут выступать внешние сущности, накопители, процессы (действия, работы).
Внешняя сущность — объект, являющийся поставщиком и/или получателем информации. Например, "Пользователь", "Заказчик", "Банк" и т.д. Внешние сущности обозначают источники и приемники, которые не представляют для анализа интерес в данный момент и служат для ограничения моделируемой части предметной области. Они отражают взаимодействие системы с внешним миром.
В описательном смысле переход к диаграммам потоков данных соответствует добавлению к функциональной структуре объекта предметной области данных, полученных при обследовании объекта (например, документооборота в случае создания ПО для ИС).
3) Создается словарь данных (Data Dictionary), в котором хранится и анализируется состав потоков и накопителей данных, взаимосвязь отдельных элементов потоков и накопителей данных. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.
4) Каждая логическая функция (процесс, действие, работа) может быть детализирована с помощью диаграмм потоков данных нижнего уровня, возможно с переходом на нотацию IDEF3. Когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции (процесса, действия, работы) при помощи спецификации процесса — миниспецификации.
Миниспецификация — это алгоритм описания задачи, выполняемой процессом, т.е. алгоритм преобразования входных потоков данных в выходные.
Для каждого процесса нижнего уровня должна существовать одна и только одна миниспецификация. Множество всех миниспецификаций является полной спецификацией системы. Миниспецификации являются базой для кодогенерации.
Решение о завершении детализации процесса с помощью диаграмм потоков данных и использовании миниспецификации принимается аналитиком исходя из следующих критериев:
- процесс имеет относительно небольшое количество входных и выходных потоков данных (2-3 потока);
- процесс выполняет единственную логическую функцию преобразования входной информации в выходную;
- возможно описать логику процесса при помощи миниспецификации небольшого объема (не более 20-30 строк, т.е. до одной страницы текста).
Миниспецификация содержит:
- списки входных и выходных данных;
- номер и/или имя процесса;
- тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.
Набор конструкций для построения спецификации должен быть простым и стандартным. Известно большое число разнообразных методов задания тела процесса.
Соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.
Диаграммы потоков данных (DFD) моделируют функции, которые система должна выполнять, но ничего (или почти ничего) не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени — для этих целей используются специальные диаграммы.
5) Хранимые в словаре данных (в репозитории) описания каждого накопителя данных используются для перехода к построению модели данных в виде диаграмм "сущность-связь" (ERD).
В отличие от функциональных диаграмм (FDD) и диаграмм потоков данных (DFD) диаграммы "сущность-связь" (ERD) описывают информационное пространство, в рамках которого реализуются процессы объекта предметной области.
Выявляются и определяются элементы базы данных, в которых будут храниться данные системы. Выявляются и определяются их атрибуты и отношения.
Модель данных должна быть привязана к функциональной модели: элементы модели данных и их атрибуты должны соответствовать накопителям данных.
Этот процесс требует высокой квалификации и значительных интеллектуальных затрат, но является необходимой стадией в структурном анализе системы. Может использоваться, например, нотация IDEF1Х (Information and Data Modeling Method — информационное моделирование) и CASE-средство ERwin фирмы Computer Associates Inc.
6) В случае наличия реального времени диаграммы потоков данных (DFD) дополняются управляющими компонентами и спецификациями управления, например в виде диаграмм переходов состояний (STD).
Событийная (поведенческая) модель описывает динамику функционирования, в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий.
Кроме диаграмм переходов состояний могут использоваться таблицы и матрицы переходов состояний.
Перечисленные методы дают полное описание системы независимо от того, является ли она существующей или вновь разрабатываемой.
Так строится модель требований, или логическая модель — подробное описание того, что должна делать система, освобожденное, насколько это возможно, от рассмотрения путей реализации. Это дает проектировщику четкое представление о конечных результатах, которых следует достигать.
Связи диаграмм модели требований показаны на рис. 7.2. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Рис. 7.2. Компоненты модели требований
Модель требований в документе "Техническое задание" приводится в разделе "Требования к системе". В частности: в подразделах "Требования к системе в целом" и "Требования к функциям (задачам), выполняемым системой" приводятся диаграммы потоков данных (DFD) совместно со словарем данных и событийной моделью; в подразделе "Требования к видам обеспечения " в пункте "Требования к информационному обеспечению" приводится модель данных (ERD).
Проектирование ПО — это следующий этап ЖЦ ПО, на котором вырабатывается, как реализуются требования пользователя, которые порождены и зафиксированы на этапе анализа.
На этапе проектирования ПО рассмотренные модели расширяются, уточняются и дополняются диаграммами, отражающими структуру ПО.
Осуществляется построение физической модели проектируемой прикладной системы (без технических подробностей).
Компоненты физической модели:
- диаграммы потоков данных;
- модель данных (определение в ER-диаграммах всех необходимых параметров для приложений);
- модель пользовательского интерфейса (иерархия диаграмм последовательности экранных форм);
- структурные схемы программ (модели межмодульных и внутримодульных взаимодействий с использованием техники структурных карт).
Модель пользовательского интерфейса определяется следующим образом.
На диаграммах потоков данных среди процессов нижнего уровня (т.е. тех которые не имеют детализации в виде диаграмм) выделяются интерактивные (диалоговые) и не- интерактивные процессы, например, в виде списка. После этого строят диаграммы последовательности форм (FSD — Form Sequence Diagrams).
FSD показывает, какие формы появляются в приложении и в каком порядке, т.е. фиксируются набор и структура вызовов экранных форм.
Диаграммы последовательности форм образуют иерархию, на вершине которой находится главная форма приложения, реализующего систему/подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня на диаграммах потоков данных.
Показывается взаимосвязь между каждой формой и определенным процессом, взаимосвязь между каждой формой и одной или более сущностями в ER-диаграммах.
Описание экранных форм и отчетов должно содержать:
- описание назначения формы (что делает);
- данные навигации (откуда вызвана, что может вызвать сама);
- список ошибок, которые генерируются в процессе обработки формы и реакция на них;
- ограничения доступа к форме (каковы привилегии, разрешающие действия над формой и ее элементами, каковы привилегии, запрещающие эти действия).
По сути, получается прототип экранов, отчетов, диалогов.
Поэтому до начала этапов проектирования и реализации необходимо определиться со стандартом интерфейса пользователя, который будет использоваться одинаково во всех частях ПО.
Он должен устанавливать:
- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
- правила использования клавиатуры и мыши;
- правила оформления текстов помощи;
- перечень стандартных сообщений;
- правила обработки реакции пользователя.
Описание интерфейса пользователя включается в "Техническое задание".
Пример иерархии диаграмм экранных форм для модели ПО "Графический редактор (Paint)" приведен на рис. 7.3 — 7.9. Номера процессов соответствуют модели в нотации DFD, показанной на рис. 10.5 — 10.7.
Правильность интерфейса должен проверять и утверждать только реальный пользователь каждого рабочего места организации-заказчика.
На практике реализация интерфейса пользователя является наиболее часто изменяемой частью исходного кода.
Много проблем в интерфейсах пользователей создают сами проектировщики, если они неправильно выбирают макет и не учитывают разницы поведения системы на макете и на реальных данных.
Рис. 7.3. Иерархия форм
Рис. 7.4. Форма 1 — "Главный вид"
Рис. 7.5. Форма 2 — Меню "Файл"
Рис. 7.6. Форма 3 — Меню "Рисунок"
Рис. 7.7. Форма 4 — Пункт "Атрибуты" меню "Рисунок"
Рис. 7.8. Форма 5 — Меню "Правка"
Рис. 7.9. Форма 6 — Меню "Вид"
Распространенная ошибка проектирования интерфейса — обработка длительных процессов, когда пользователь должен ждать ответа на запрос. Большинство проектировщиков не предусматривают единого вызова функции — обработчика события ожидания ответа. На макете запрос может проходить мгновенно, а в случае реальных данных это может составлять несколько минут. Если обработка ожидания ответа не предусмотрена (хотя бы в виде элементарного сообщения "Подождите, идет обработка данных"), то пользователь думает, что приложение "зависло".
Вопросы проверки корректности ввода информации часто решаются проектировщиками неоднозначно. Как правило, пользователь настаивает на более деталь- ном анализе ошибки ввода данных. Если вводимые значения выбираются из справочника, то здесь проблем меньше. Если они вводятся вручную, то возникает проблема предотвращения попадания в систему некорректных данных, например, элементарных опечаток.
В структурных схемах программ определяются главные модули, маршруты связи по данным и маршруты связи по управлению между модулями, основные подпрограммы внутри каждого модуля, состав и взаимосвязь элементов данных (структуры данных), спецификации форматов входных и выходных файлов.
Наиболее часто применяются две техники: структурные карты Константайна (Constantine), предназначенные для описания отношений между модулями, и структурные карты Джексона (Jackson), предназначенные для описания внутренней структуры модулей.
Структурные карты позволяют развить модель требований до модели реализации. Фактически структурное проектирование является мостом между структурным анализом и реализацией.
Результаты этапа проектирования ПО отображаются в документации технического проекта, состав которой определен ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем.
Успех следующего этапа ЖЦ ПО — реализации — полностью зависит от качества выполнения этапов анализа требований и проектирования, так как их результаты являются основой для реализации.
Построение модели реализации включает в себя действия:
- генерация SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности), т.е. физическая реализация БД;
- уточнение структурных схем программ и диаграмм последовательности экранных форм (FSD);
- генерация кода приложений;
- разработка программных документов в соответствии с ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов или с ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем.