Спецификации программного обеспечения при структурном подходе

Моделирование информационных систем с использованием CASE средств

Методические указания по выполнению лабораторной работы

 

                                                         Подготовила: Романова Т.Н.

                                                                                                             доц. кафедры ИУ-7, к.ф.-м. н.

 

                                                             

 

 

.

 

Москва 2011 г.

Содержание

Содержание…………………………………………………………………………………………2

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

Краткие теоретические сведения………………………………………………………………….4

Список литературы………………………………………………………………………………..30

 

Цель работы - знакомство с унифицированным языком моделирования (UML), знакомство с пакетом визуального моделирования Rational Rose в соответствии с методологией Rational

Unified Process и приобретение навыков разработки технического задания в соответствии

с требованиями ЕСПД и навыков моделирования конкретной информационной системы

в CASE системе  Rational Rose 2000.

 

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

 

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

2.  Разработать техническое задание (ТЗ) на информационную систему, которую будете моделировать в лабораторной работе №2  в соответствии со стандартами (Единой системой программной документации).

· В CASE системе спроектировать выбранную ИС:

 

· Поведение разрабатываемой системы, то есть функциональность, обеспечиваемую системой, (функциональную модель) описать с помощью диаграмм прецедентов (use case diagrams).

· Основным средством для представления статической  модели ИС является

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

· Построить динамическую модель ИС с помощью диаграмм схем состояний, и диаграмм последовательности действий.

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

 собой. Промоделировать размещение компонентов.

3. Средствами CASE системы сгенерировать код ИС.

4. Представить отчет о выполнении лабораторной работы №2 по схеме.

· Титульный лист.

· Введение, описание предметной области, необходимость создания ИС.

· Техническое задание по ЕСПД.

· Распечатки всех построенных в CASE системе диаграмм.

· Описание атрибутов и спецификаций.

· Выводы о достоинствах и недостатках CASE системы для моделирования выбранного класса задач.

· Список использованной литературы.

 

 

Краткие теоретические сведения.

АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ

 ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ.

 

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

 

Спецификации программного обеспечения при структурном подходе

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

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

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

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

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

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

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

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

 

                                              

 

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

 

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

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

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

● диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

● диаграмм “сущность-связь” (ERD - Enity Relationhship Diagrams), описывающих базы данных разрабатываемой системы;

● диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

● спецификаций процессов;

● словаря терминов.

 

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

 

 

 

Рис.2. Элементы полной спецификации методологий структурного анализа и проектирования программного обеспечения основанных на потоках данных

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

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

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

● термин;

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

● краткое описание.

 

 

В качестве примера приведем описание одного из терминов системы решения комбинаторно-оптимизационных задач:

    Термин......... Алгоритм

    Категория....... Понятие предметной области

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

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

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

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

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

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

 

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

а - терминальное состояние; б - промежуточное состояние; в - переход

 

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

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

 

 

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

 

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

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

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

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

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