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

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

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

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

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

Цели анализа и формирования требований к ПО . Анализ является первым этапом создания ПО , на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: « Что должна делать будущая система?». Именно стадия анализа и формирования требований к ПО определяет успех всего проекта. Необходимо на более ранних стадиях разработки понять, что будет представлять собой создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость разработки.

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

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

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

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

Среди множества методов решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяются: FDD ( Functional Decomposition Diagrams ) – диаграммы функциональной декомпозиции; DFD ( Data Flow Diagrams ) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов (или миниспецификациями ); ERD ( Entity - Relationship Diagrams ) - диаграммы "сущность-связь" ; STD ( State Transition Diagrams ) - диаграммы переходов состояний .

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

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

( I - этап "Обследование объекта и обоснование необходимости создания АС"; II - этап "Разработка и утверждение технического задания на создание АС")

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

2. По функциональной модели (FDD) предметной области строится совокупность (иерархия) диаграмм потоков данных ( DFD ). Диаграммы потоков данных, используя функции, описанные на уровне функциональной модели (FDD), позволяют детализировать описание предметной области за счет введения накопителей, потоков данных и внешних сущностей. Накопитель (хранилище) данных - приспособление для хранения информации, обладающее возможностью записи и извлечения данных. Способы доступа и хранения данных в накопителях в ходе анализа не уточняются. Хранилища являются прообразами файлов или баз данных. Поток данных - канал передачи данных от источника к приемнику. В качестве источников и приемников данных для потоков могут выступать внешние сущности, процессы и накопители. Внешняя сущность - объект, являющийся поставщиком и/или получателем информации. Например, «заказчик», «банк» и т.д. Внешние сущности обозначают источники и приемники, которые не представляют для анализа интерес в данный момент и служат для ограничения моделируемой части предметной области. Отражают взаимодействие системы с внешним миром.

3. Создается словарь данных ( Data Dictionary ), в котором хранится и анализируется состав потоков и накопителей данных, взаимосвязь отдельных элементов потоков и накопителей данных. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.

4. Каждая логическая функция (процесс, действие, работа) может быть детализирована с помощью диаграмм потоков данных нижнего уровня, возможно с переходом на нотацию IDEF 3. Когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции (процесса, действия, работы) при помощи спецификации процесса - миниспецификации . Миниспецификация - это алгоритм описания задачи, выполняемой процессом, т.е. алгоритм преобразования входных потоков данных в выходные. Для каждого процесса нижнего уровня должна существовать одна и только одна миниспецификация . Множество всех миниспецификаций является полной спецификацией системы. Миниспецификации являются базой для кодогенерации . Решение о завершении детализации процесса с помощью диаграмм потоков данных и использовании миниспецификации принимается аналитиком исходя из следующих критериев : процесс имеет относительно небольшое количество входных и выходных потоков данных (2-3 потока); процесс выполняет единственную логическую функцию преобразования входной информации в выходную; возможно описать логику процесса при помощи миниспецификации небольшого объема (не более 20-30 строк, т.е. до одной страницы текста).

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

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

5. Хранимые в словаре данных (в репозитории ) описания каждого накопителя (хранилища) данных используются для перехода к построению модели данных в виде диаграмм «сущность-связь» ( ERD ). В отличие от функциональных диаграмм (FDD) и диаграмм потоков данных (DFD) диаграммы « сущность-связь » ( ERD ) описывают информационное пространство , в рамках которого реализуются процессы объекта предметной области. Выявляются и определяются элементы базы данных, в которых будут храниться данные системы. Выявляются и определяются их атрибуты и отношения. Модель данных должна быть привязана к функциональной модели: элементы модели данных и их атрибуты должны соответствовать накопителям данных.

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

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

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

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

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

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

Модель пользовательского интерфейса определяется следующим образом. На диаграммах потоков данных среди процессов нижнего уровня (т.е. тех которые не имеют детализации в виде диаграмм) выделяются интерактивные (диалоговые) и не интерактивные процессы, например, в виде списка. После этого строят диаграммы последовательности форм ( FSD - Form Sequence Diagram s ). FSD показывает, какие формы появляются в приложении и, в каком порядке, т.е. фиксируется набор и структура вызовов экранных форм. Диаграммы последовательности форм образуют иерархию, на вершине которой находится главная форма приложения, реализующего систему/подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня на диаграммах потоков данных. Показывается взаимосвязь между каждой формой и определенным процессом, взаимосвязь между каждой формой и одной или более сущностями в ER-диаграммах. Описание экранных форм и отчетов должно содержать: описание назначения формы (что делает); данные навигации (откуда вызвана, что может вызвать сама); список ошибок, которые генерируются в процессе обработки формы и реакция на них; ограничения доступа к форме (каковы привилегии, разрешающие действия над формой и ее элементами, каковы привилегии, запрещающие эти действия).

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

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

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

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

Успех следующего этапа ЖЦ ПО - реализации - полностью зависит от качества выполнения этапов анализа требований и проектирования, т.к. их результаты являются основой для реализации. Построение модели реализации включает в себя действия: генерация SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности), т.е. физическая реализация БД; уточнение структурных схем программ и диаграмм последовательности экранных форм (FSD); генерация кода приложений; разработка программных документов в соответствии с ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов или ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем.