Проектирование программного продукта

    От того насколько правильно будет спроектирована архитектура программного продукта, зависят очень многие качества проекта. Так в тесной зависимости от архитектуры БД находиться способ реализации программного кода, время работы над проектом, и от этого будет зависеть выбор модели жизненного цикла [6].

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

    2.1 Выбор модели жизненного цикла

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

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

    Основными моделями ЖЦ, к настоящему времени получившими наибольшее распространение, являются каскадная и спиральная модели ЖЦ.

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

    Каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема. Ниже перечислены эти преимущества:

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

· упорядоченная и отлично справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы;

· весьма доступна для понимания, так как преследуется простая цель - выполнить необходимые действия;

· проста и удобна в применении, так как процесс разработки выполняется поэтапно;

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

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

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

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

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

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

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

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

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

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

· спиральная модель разрешает пользователям «увидеть» систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;

· обеспечивается определение непреодолимых рисков без особых дополнительных затрат;

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

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

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

· когда создание прототипа представляет собой подходящий тип разработки продукта;

· когда организация обладает навыками, требуемыми для адаптации модели;

· для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

· когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции;

· когда пользователи не уверены в своих потребностях;

· когда требования слишком сложные;

· при разработке новой функции или новой серии продуктов;

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

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

· при разработке систем, требующих большого объема вычислений, таких как систем, обеспечивающих принятие решений;

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

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

    2.2 Построение концептуальной модели системы

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

    Работа пользователя состоит из 2-х этапов: ввод исходных данных, просмотр и вывод отчетов на печать.

    Ввод данных состоит из следующих шагов:

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

· просмотр отчетов должен производиться через соответствующие этим отчетам формы.

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

Рисунок 2.1 - Диаграмма вариантов использования

    Разработка диаграммы преследует следующие цели:

· определить общие границы и контекст моделируемой предметной области;

· сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

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

    В нашем случае актерами является директор дизайнерской студии, проводящий работу с данными.

    2.3 Проектирование диаграммы потоков данных

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

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

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

    Рассмотрим диаграмму потоков данных (рис. 2.2) для приложения, подробнее остановимся на всех подсистемах и рассмотрим работу каждой.

Рисунок 2.2 - DFD – диаграмма

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

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

    2.4 Проектирование базы данных

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

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

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

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

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

· Сотрудники – сотрудники предприятия;

· Клиенты – клиенты предприятия;

· Заказ – заказы предприятия;

И одиннадцать второстепенных таблиц:

· Адрес_сотр – адреса сотрудников предприятия;

· Документы_кл – документы клиентов предприятия;

· Документы_сотр – документы сотрудников предприятия;

· Заказ_сотр – сотрудники работающие над заказом;

· Пол – пол;

· Прием_на_должность – прием на должность сотрудника;

· Реквизиты – реквизиты клиента;

· Связь_клиент – связь с клиентом;

· Связь_сотр – связь с сотрудником;

· Т_ср_связи – тип средства связи;

· Тип_документов – тип документов;

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

    В таблице 2.1 приведена логическая структура таблиц базы данных.

Таблица 2.1 -Логическая структура таблиц базы данных

Название таблицы	Имя поля	Тип данных	Сущность
Сотрудники	ID_Сотрудника	Счетчик	Уникальное значение (Первичный ключ)
	ФИО	Короткий текст	ФИО сотрудника
	Дата_рождения	Дата и время	Дата рождения сотрудника
	Пол	Текстовый	Определяет пол сотрудника
Адрес_сотр	ID_адрес_сотр	Счетчик	Уникальное значение (Первичный ключ)
	id_сотр	Числовой	Связь с таблицей «Сотрудники»
	Город	Текстовый	Город сотрудника
	Адрес	Текстовый	Адрес сотрудника
Связ_сотр	ID_св_сотр	Счетчик	Уникальное значение (Первичный ключ)
	Id_сотрудника	Числовой	Связь с таблицей «Сотрудники»
	Т_ср_связи	Текстовый	Тип средства связи
	Номер	Текстовый	Номер сотрудника
		Продолжение таблицы 2.1
Название таблицы	Имя поля	Тип данных	Сущность
Пол	Пол	Текстовый	Пол
Документы_сотр	ID_документа	Счетчик	Уникальное значение (Первичный ключ)
	Id_сотрудника	Числовой	Связь с таблицей «Сотрудники»
	Тип_документа	Текстовый	Определяет тип документа сотрудника
	Серия	Числовой	Серия документа
	Номер	Числовой	Номер документа
	Кем_выдан	Текстовый	Кем выдан документ
	Дата	Дата и время	Дат выдачи документа
Прием_на_должность	ID_приема	Счетчик	Уникальное значение (Первичный ключ)
	Id_сотрудника	Числовой	Связь с таблицей «Сотрудники»
	Должность	Текстовый	Должность сотрудника
	Ставка	Текстовый	Ставка сотрудника
	Зар_плата	Денежный	Заработная плата сотрудника
	Дата_с	Дата и время	Дата приема на должность
	Дата_по	Дата и время	Дата увольнения
	Причина_увол	Текстовый	Причина увольнения
Заказ	ID_заказа	Счетчик	Уникальное значение (Первичный ключ)
	Дата_приема	Дата и время	Дата приема заказа
	Дата_сдачи	Дата и время	Дата сдачи заказа
	Причина_обращения	Поле МЕМО	Причина обращения заказа
	Комментарии	Поле МЕМО	Комментарии к заказу
	Отзыв_клиента	Поле МЕМО	Отзыв клиента на заказ
	Id_сотрудника	Числовой	Связь с таблицей «Сотрудники»
	Id_клиента	Числовой	Связь с таблицей «Клиенты»
	Id_реквизита	Числовой	Связь с таблицей «Реквизиты»

 

Продолжение таблицы 2.1

Название таблицы	Имя поля	Тип данных	Сущность
	Адрес	Текстовый	Адрес стройки
	Клиент	Текстовый	Клиент заказа
	Сп_оказ_усл	Поле МЕМО	Список оказанный услуг
	Площадь	Числовой	Площадь стройки
	Стоимость	Числовой	Стоимость заказа
	Оплата совершенна	Числовой	Определяет совершена ли оплата по заказу
Реквизиты	ID_реквизита	Счетчик	Уникальное значение (Первичный ключ)
	Название_банка	Текстовый	Название банка
	Юр_адрес	Текстовый	Юридический адрес банка
	N_счета	Числовой	Номер счета
	Id_заказа	Числовой	Связь с таблицей «Заказ»
Клиенты	ID_клиента	Счетчик	Уникальное значение (Первичный ключ)
	Дата_рождения	Дата и время	Дата рождения клиента
	Пол	Текстовый	Пол клиента
	ФИО	Текстовый	ФИО клиента
Связь_клиент	ID_св_кл	Счетчик	Уникальное значение (Первичный ключ)
	Id_клиента	Числовой	Связь с таблицей «Клиент»
	Т_ср_связи	Текстовый	Тип средства связи
	Номер	Текстовый	Номер клиента
Документы_кл	ID_документа	Счетчик	Уникальное значение (Первичный ключ)
	Id_клиента	Числовой	Связь с таблицей «Клиент»
	Тип документа	Текстовый	Тип документа клиента

 

Продолжение таблицы 2.1

	Серия	Числовой	Серия документа
	Номер	Числовой	Номер документа
	Кем_выдан	Текстовый	Кем выдан документ
	Дата	Дата и время	Дата выдачи документа
Т_ср_связи	Тип_средства_связи	Текстовый	Определяет тип средства связи
Тип_документов	Тип_документов	Текстовый	Определяет тип документов
Заказ_сотр	ID_заказ_сотр	Счетчик	Уникальное значение (Первичный ключ)
	Id_сотр	Числовой	Связь с таблицей «Сотрудники»
	Id_заказ	Числовой	Связь с таблицей «Заказ»

 

Выводы

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

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

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