Выбор архитектуры программного обеспечения

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

· уровень представления (интерфейса),

· уровень приложения (бизнес-логики),

· уровень хранения данных (базы данных).

Графически разделение между этими уровнями можно отобразить следующим образом:

 

 

Рис. П.1.34. Трехуровневая архитектура программной системы

 

Как видно на рис. П.1.34, каждый уровень отвечает за свой участок работ. Уровень представления обеспечивает интерфейс с пользователем, обрабатывает воздействия пользователя и информирует уровень приложения

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

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

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

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

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

В соответствии с заданием будущее приложение должно иметь трехуровневую архитектуру: веб-приложение (представление), базу данных (модель хранения данных) и логику на серверной части (бизнес-логика, приложение, контроллеры). Основная цель применения этой концепции состоит в отделении бизнес-логики (модели) от её визуализации (представления, вида). За счёт такого разделения повышается возможность повторного использования кода и возможность легкой адаптации приложения к новым задачам. Наиболее полезно применение данной концепции в тех случаях, когда разные пользователи должны видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения [6].

Используемые инструменты и технологии веб-приложения

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

 

Оформление этапа Создание в расчетно-пояснительной записке

 

Конструкторская часть

1. Техническое задание

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

Техническое задание составляется в соответствии с ГОСТ 19.201-78. Дадим некоторые пояснения по оформлению разделов задания (ниже номера пунктов соответствуют номерам разделов задания по ГОСТу).

1. Техническое задание начинается с титульного листа, который обязателен и занимает отдельную страницу. Подпись «Согласовано» в правом верхнем углу ставят руководители исполнителей и соисполнителей (Для проекта – Заведующий кафедрой). Подпись «Утверждаю» в левом верхнем углу ставят руководители предприятий-заказчиков (Для проекта – Проректор НУК ИУ). Внизу титульного листа справа подписываются руководитель проекта и исполнитель. В центре титульного листа после текста «Техническое задание на разработку» указывается точный вид изделия и его наименование.

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

2. В качестве основания для разработки указывать «Учебный план направления ………, утвержденный Ректором МГТУ ………..

4. В разделе 4.1 «Требования к функциональным характеристикам», сформулированные на этапе Анализа системы.

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

В разделе 4.2 «Требования к надежности» надо перечислить все применяемые в программном продукте методы повышения надежности:

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

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

- защита от несанкционированного доступа;

- защита от внешних воздействий и помех

Результаты расчета времени восстановления информации.

В разделе 4.3 «Условия эксплуатации» необходимо указать:

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

- время непрерывной работы;

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

- требуемые штаты обслуживающего персонала и его квалификация, Рекомендуем не завышать требований, чтобы персоналу не требовалось обучения на специальных курсах. Часто бывает достаточной формулировка «Систему может обслуживать пользователь-непрограммист, знакомый с основными принципами работы в среде операционной системы Windows ME и ниже. Для этого система снабжается дружественным интерфейсом, достаточным числом справок, инструкций, подсказок».

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

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

В разделе 4.6 «Требования к маркировке и упаковке» указать «Нет».

В разделе 4.7 «Требования к транспортировке и хранению» указать, если необходимо, что программный продукт хранится на носителе в виде гибких дисков, CD дисков и др.

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

В части 5 «Технико–экономические показатели» указать ориентировочную экономическую эффективность, предполагаемую годовую потребность. Желательно привести данные из организационно-экономического раздела проекта.

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

Архитектура системы

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

База данных

В этом разделе приводится обоснование выбора СУБД (Системы управления базами данных) на основании анализа современных СУБД и требований к системе, приводится схема базы данных, описание таблиц, описание реализованных ограничений и блок схемы функций и триггеров.

Серверная часть системы

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

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

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

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

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

- повторяющиеся фрагменты программы можно объединить в один модуль;

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

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

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

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

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

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

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

Форма 1

Спецификация на модуль

1. Системное имя модуля.

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

3. Входные данные.

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

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

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

6. Способ вызова модуля (Имя вызывающего модуля, вызывающая команда, кнопка и т.д.).

7. Список вызываемых модулей.

По договоренности с руководителем в проекте приводится спецификация на два – три характерных модуля.

Интерфейс пользователя

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

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

Технологическая часть.

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

Анализ исходных данных

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

Тестирование – это процесс исполнения программы с целью найти все ошибки, которые могли остаться в программе. Подготовка тестирования – это подготовка наборов данных.

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

Надо проверить выполнение всех функций.

Проверяется правильность всех возможных настроек.

Проверяются все требования по надежности и целостности данных.

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

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

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

Результаты исследований этого раздела должны быть подытожены в виде таблицы со столбцами:

· Набор исходных данных.

· Проверяемый режим, функция, алгоритм.