Специфицирование программного обеспечения

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Разработка технического задания

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

2.1 Дерево диаграмм

2.2 Структура SADT-модели

2.3 Диаграмма «сущность-связь»

3. Разработка пользовательского интерфейса

3.1 Разработка сценария диалога на основе меню

3.2 Разработка сценария диалога на основе экранных форм

Заключение

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

Приложения

Введение

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

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

1. Разработка технического задания

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

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

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содержать следующие разделы:

- введение;

- основания для разработки;

- назначение разработки;

- требования к программе или программному изделию;

- требования к программной документации;

- технико-экономические показатели;

- стадии и этапы разработки;

- порядок контроля и приемки.

Далее будет представлено техническое задание по разработке автоматизированной системы «Учет ставок».

1. Введение

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

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

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

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

2. Основание для разработки

Система разрабатывается на основании договора между владельцем букмекерской конторы Ивановым В.В. и компанией по разработке программного обеспечения ООО «Вектор» № 666 от 3.10.2011.

3. Назначение

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

4. Требования к программе или программному изделию

4.1.Требования к функциональным характеристикам

4.1.1. Система должна обеспечивать возможность выполнения следующих) функций:

- инициализацию системы (ввод сделанных ставок на каждое соревнование в соответствии с данными игрока, такими как полное имя игрока, его адрес, телефон, коэффициенты выигрыша для каждого возможного исхода соревнования);

- хранение информации о сделанных ставках в течение всего времени с момента принятия ставки до окончания соревнования;

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

- расчет выигрыша каждого игрока;

- расчет прибыли букмекера по окончании соревнования;

4.1.2. Исходные данные:

- количество возможных исходов соревнования;

- коэффициенты выигрыша для каждого возможного исхода соревнования;

- данные о сделанных ставках и в соответствии с ними личные данные игроков;

-прогноз исхода для каждого соревнования

4.1.3. Результаты:

- выигрыши игроков;

- прибыль букмекера;

- мониторинг сделанных ставок для каждого соревнования непосредственно в процессе принятия ставок;

- расчет вероятности (в процентах) исхода каждого соревнования на основе наибольшего количества ставок;

- расчет вероятности (в процентах) каждого возможного исхода соревнования на основе относительного сравнения ставок;

4.2. Требования к надежности:

4.2.1. Предусмотреть контроль вводимой информации.

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

4.2.3. Обеспечить целостность хранимой информации.

4.3. Требования к составу и параметрам технических средств

4.3.1. Система должна работать на IBM совместимых персональных компьютерах.

4.3.2. Минимальная конфигурация:

- тип процессора - Pentium и выше;

- объем оперативного запоминающего устройства 32 Мб и более.

4.4. Требования к информационной и программной совместимости:

Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT и т.п.).

5. Требования к программной документации

5.1. Разрабатываемые программные модули должны быть самодокументированы, т. е. тексты программ должны содержать все необходимые комментарии.

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

5.3. В состав сопровождающей документации должны входить:

5.3.1. Пояснительная записка, содержащая описание разработки.

5.3.2. Руководство системного программиста.

5.3.3. Руководство пользователя.

5.3.4. Графическая часть:

5.3.4.1. Функциональная схема программной системы.

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

5.3.4.3. Формы интерфейса пользователя.

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

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

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

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

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

Методологии структурного анализа и проектирования обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей: функциональные диаграммы, диаграммы потоков данных, диаграммы отношений компонентов данных. В рамках данной курсовой работы разработаны дерево диаграмм, структура SADT-модели и диаграмма «сущность-связь» [1].

2.1 Дерево диаграмм

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

На рис. 1 представлено дерево диаграмм для автоматизированной системы «Учет ставок». Система включает две основные функции: инициализация системы и проведение расчетов. Каждая из этих функций декомпозируется на составляющие.

Рис. 1. Дерево диаграмм

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

2.2 Структура SADT-модели

Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого ПО. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделирования SADT (Structured Analysis and Design Technique - технология структурного анализа и проектирования).

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

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

На рис.2 представлена диаграмма первого уровня, в которой определены: исходные данные, результаты, управляющая информация и механизмы ее осуществления. Исходными данными являются заявки игроков, коэффициенты ставок на игры и результаты игры. Выходные данные - идентификационный номер игрока, данные о ставках, вероятности исхода соревнования, прибыль букмекера, выигрыш игрока. Управляющая информация - внутренние инструкции системы, и механизм осуществления - букмекер, использующий систему и сама система.

Рис. 2. Диаграмма первого уровня

На рис.3 представлена декомпозиция блока А0. Для функции «Инициализировать систему» исходными данными являются заявки игроков и коэффициенты ставок. Выходные данные этой функции о сделанных ставках и заявленных букмекером коэффициентов ставок являются входными данными для функции «Проведение расчетов». Также для расчетов фукнции «Проведение расчетов» требуются данные о результатах игры, на исход которой делаются ставки.

Рис. 3. Декомпозиция блока А0

На рис.4 представлена декомпозиция функции «Инициализация системы»: функция включает в себя ввод информации об игроках и ввод коэффициентов ставок. Управляющим механизмом для этих функций является букмекер.

Рис. 4. Декомпозиция функции «Инициализация системы»

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

Рис. 5. Декомпозиция функции «Получение сведений»

2.3 Диаграмма «Сущность-связь»

Целью построения диаграмм «сущность - связь» является обеспечение разработчика концептуальной схемой БД.

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

- нотация П. Чена;

- нотация Р. Баркера;

- нотация IDEF1 (более современный вариант этой нотации - IDEF1X используется в CASE-системах, например в системе ERWin).

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

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

Каждая сущность должна:

- иметь уникальное имя;

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

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

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

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

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

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

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

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

Различают три типа отношений:

- 1*1 - «один-к-одному» - одному экземпляру первой сущности с соответствует один экземпляр второй;

- 1*n - «один-ко-многим» - одному экземпляру первой сущности соответствуют несколько экземпляров второй;

- n*m - «многие-ко-многим» - каждому экземпляру первой сущности может соответствовать несколько экземпляров второй и, наоборот, каждому экземпляру второй сущности может соответствовать несколько экземпляров первой.

На рис.6 и рис.7 представлены логическая и физическая модели соответственно, спроектированные для работы автоматизированной системы «Учет ставок». Сущности «Букмекерская контора» и «Игра» имеют связь «один-ко-многим», так как каждая букмекерская контора проводит множество игр на ставках. Также сущность «Букмекерская контора» имеет связь с сущностью «Игрок» «один-ко-многим»,так как услугами конторы могут пользоваться множество игроков. На каждую игру могут делать ставки много игроков, поэтому сущности «Игра» и «Игрок» имеют связь «один-ко-многим». Также была определена сущность «Касса», которая связана с сущностью «Букмекерская контора» связью «один-к-одному», так как на каждую контору полагается одна касса. В кассе лежат деньги всех игроков, поэтому связь между сущностями «Касса» и «Игрок» - «один-ко-многим».

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

Рис. 6. Логическая модель «Сущность-связь»

Рис. 7. Физическая модель «Сущность-связь»

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

В процессе проектирования БД создаются логические и физические модели разного уровня представления.

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

В процессе проектирования системы разрабатывается физическая модель.

Эти модели обеспечивают:

- разработку документации базы данных;

- разработку ссылочной целостности БД;

- разработку логической модели БД независимой от конкретного типа

СУБД;

Физическая модель позволяет:

- обеспечить администратору БД достаточность информации, чтобы создать эффективную БД;

- создать контекст для процессов определения и записи в словари данных;

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

3. Разработка пользовательского интерфейса

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

Обмен информацией осуществляется передачей сообщений и управляющих сигналов. Сообщение - порция информации, участвующая в диалоговом обмене.

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

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

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

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

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

- фразовую;

- директивную;

- табличную.

3.1 Разработка сценария диалога на основе меню

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

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

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

На рис.8 представлен общий вид автоматизированной системы «Учет ставок».

Рис. 8. Общий вид программы

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

Рис. 9. «Инициализация»

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

Рис. 10. «Расчеты»

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

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

3.2 Разработка сценария диалога на основе экранных форм

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

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

С формами могут работать пользователи любой квалификации. По сравнению со структурой типа «вопрос-ответ» данная структура позволяет повысить скорость ввода данных. По сравнению же с меню допускается более широкий диапазон входных данных.

Графы диалогов для пользователя показаны в приложении Б.

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

Рис. 11. Ввод информации об игроке

На рис. 12 показана экранная форма «Ввод коэффициентов». Пользователь заполняет форму необходимыми для расчетов данными об игре.

Рис. 12. «Ввод коэффициентов»

На рис.13 показана функция «Расчет наибольшего количества ставок». Пользователь может выбрать один из трех вариантов сравнительного анализа сделанных ставок.

Рис. 19. «Расчет наибольшего количества ставок»

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

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

программный диаграмма интерфейс

Заключение

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

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

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

1. Иванова Г.С. Технология программирования: Учебник для вузов.- 2-е изд., стереотип. - М.: МГТУ им. Баумана, 2003. - 320 с.

2. Карамзина А.Г. Методические указания для выполнения курсовой работы по дисциплине «Технология программирования» - Уфа: УГАТУ

Приложения

Приложение А

Функциональная схема ПО

Приложение Б

Графы диалога

Рис. П.Б.1. Граф диалога, управляемый пользователем

Рис. П.Б.2. Граф диалога, управляемый системой.

Размещено на Allbest.ru