Файл: Lektsii_TP.doc

Стандарт интерфейса пользователя должен определять:

• правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и элементов управления;

• правила пользования клавиатурой и мышью;

• правила оформления текстов помощи;

• перечень стандартных сообщений;

• правила обработки реакции пользователя.

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

4. Анализ требований и определение спецификации по при структурном подходе

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

4.1. Спецификации ПО при структурном подходе.

Спецификация – это полное и точное описание функций и ограничений разрабатываемого ПО.

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

Требования применительно к функциональной спецификации:

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

2. Требование точности. Означает, что спецификации должны однозначно восприниматься заказчиком и разработчиком.

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

Формальные модели на этапе определения спецификации делят на 2 группы:

1. модели, зависящие от подхода к разработке (структурного или объектно-ориентированного)

2. модели, не зависящие от него.

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

В рамках структурного подхода на этапе анализа и определения спецификации используют 3 типа моделей:

1. ориентированные на функции,

2. ориентированные на данные,

3. ориентированные на потоки данных.

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

Рис. 4.1. Классификация моделей разрабатываемого ПО на этапе определения спецификации.

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

1. перечень функций и состав обрабатываемых данных.

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

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

1. диаграммы потоков данных DFD(DataFlowDiagrams)

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

2. ERD– диаграммы сущность – связь. Описывают базы данных разрабатываемой системы.

3. STD– диаграммы переходов состояний. Характеризуют поведение системы во времени.

4. спецификация процессов

5. словарь терминов.

Взаимосвязь элементов этой обобщенной модели показана на Рис.1.2.

Рис. 4.2. Методология структурного анализа ПО.

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

Диаграмма переходов состояний

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

На данном этапе эта диаграмма демонстрирует поведение ПО при получении управляющих воздействий. Управляющее воздействие – управление информацией извне. Для построения необходимо определить:

• основные состояния

• управляющие воздействия (условие перехода)

• выполняемые действия

• возможные варианты перехода из одного в другое.

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

Пример диаграмм переходов состояний ПО, активно взаимодействующих с окружающей средой.

Рис. 4.3. Диаграмма переходов состояний ПО, активно взаимодействующих с окружающей средой.

4.2. Функциональные диаграммы

Отражают взаимосвязи функций разрабатываемого ПО. Пример – активностная модель Д. Росса (1973 г.), он предложил ее в составе методологии SADT(технология структурного анализа и проектирования).

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

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

4.3. Диаграмма потоков данных.

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

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

• нотация Йордана,

• нотация Гейна-Сарсона.

Пример:

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

1. декан должен получать:

а). сводку успеваемости по факультету (процент успеваемости групп, курсов и в целом по факультету на текущий или указанный момент времени);

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

2. зам. декана должен получать:

а) сводку успеваемости по курсу (процент успеваемости по группам на текущий или указанный момент)

б) сведения о сдаче экзаменов и зачетов указанной группы

в) текущие сведения об успеваемости студента

г) полные сведения об учебе студента

д) список должников по факультету со списком несданных предметов.

3. сотрудник деканата должен обеспечить

а) ввод списков студентов, зачисленных на первый курс,

б) корректировку списков студентов,

в) ввод учебных планов кафедр,

г) ввод расписаний сессий,

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

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

Рис.4.4. Контекстная диаграмм системы учета успеваемости студентов (нотация Гейна - Сарсона).

Рис.4.5.Детализирующая диаграмма потоков данных второго уровня.

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

4.4. Структуры данных и диаграммы отношений компонентов данных.