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

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

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

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

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

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

Модификация

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

Причинами выпуска новых версий являются:

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

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

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

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

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

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

Рис. 1.3. Процесс выполнения программы (а) и ее отладки с помощью отладчика (б)

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

Создание программного обеспечения на примере электронной регистратуры

Этапы создания программного обеспечения рассмотрим на примере создания электронной регистратуры.

Формулирование требований к системе. Постановка задачи

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

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

• административного Web-приложения – Back-офиса;
• Web-приложения для пациентов, врачей и регистраторов – Front-офиса.

Средствами Back-офиса администраторы системы решают все задачи, связанные с ее эксплуатацией.

В рамках Front-офиса необходимо реализовать 3 интерфейса:

• интерфейс пациента;
• интерфейс регистратора;
• интерфейс врача.

Каждый из интерфейсов предлагает специализированный набор функций и уровень доступа к информации.

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

1. Обеспечить реализацию всех базовых стадий получения талона на прием к врачу, связанных с оформлением заявки на прием, ее подтверждением и отметкой о явке.
2. Исходя из концепции деления системы на Front-офис и Back-офис, провести разделение проекта на две части: клиентское и администраторское приложение, причем клиентское приложение подразделено на 3 взаимозависимых интерфейса.
3. Предоставить средства для навигации по базе данных на нескольких уровнях доступа (регистратор, врач, пациент и администратор).
4. Реализовать специфические возможности системы.

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

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

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

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

Проектирование системы

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

На основе анализа, проведенного выше, можно предложить следующую архитектуру (рис.2.1).

Рис.2.1. Архитектура приложения

Основные архитектурные принципы:

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

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

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

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

Упрощенно, (первое определение Кодда) СУБД – это система, в которой выполняются, как минимум, два условия:

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

Основным понятием РБД являются сущности.

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

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

Таблица 2.1

Перечень сущностей предметной области