Файл: Основы проектирования программ. Этапы создания ПО.pdf

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

- каскадная модель (с 1970 по 1985 гг.),

- спиральная модель (с 1986 по 1990 гг.).

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

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

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

Рисунок 2 - Каскадная схема разработки ПО

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

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

Для нашего проекта каскадная модель обладает такими ключевыми преимуществами:

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

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

- отличается доступностью для понимания, ведь в этом случае преследуется лишь одна цель – осуществить все необходимые действия;

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

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

- характеризуется постоянством требований;

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

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

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

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

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

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

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

- отличается достаточно понятными и точно определенными стадиями.

2.2 Выбор технологии, языка и среды программирования

На исходном этапе проектирования удалось принять комплекс фундаментальных решений:

- определена архитектура ПО (в такой ситуации в рассматриваемом электронном пособии была применена однопользовательская архитектура, в соответствии с которой ПО предусмотрено для одного пользователя, который работает за ПК);

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

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

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

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

2. В соответствии со сложившимся мнением версия Object Pascal, которая применяется в среде Delphi, сопровождается специализированными классовыми библиотеками, адаптирующими ведение масштабных разработок, включая те, которые требуют применения информационных баз. Благодаря данным фактам Delphi является достаточно эффективной средой для проектирования программ Windows;

3. У компании-разработчика имеется лицензионная версия Delphi XE 8;

4. Применение хорошо известного языка.

1.2 Анализ и уточнение требований к программному продукту

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

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

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

2.3 Анализ процесса обработки информации и выбор структур данных для ее хранения

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

- терминологичный словарь;

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

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

- диаграммы переходов состояний, которые описывают поведение системы в процессе функционирования;

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

Следовательно, был выбран именно такой подход, поскольку это самое рациональное решение для нашего программного средства. Наше проектируемое ПО - не большое, а значит – для нас нет необходимости в использовании диаграмм, описанных в объектном подходе, к примеру: диаграммы вариантов применения; диаграммы классов. Тогда как третья модель, «Не зависящая от подхода к разработке», - общая, слабо раскрывает особенности программного продукта.

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

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

Рисунок 2- Диаграмма переходов состояний

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

Терминологический словарь:

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

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

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

Чтобы представить диаграммы информационных потоков, как правило, применяются такие типы нотаций:

- нотации Гейна – Сарсона;

- нотации Йордана.

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

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

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

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

Ниже представлена спецификация процесса работы программы.