Программирование

Оглавление

 

Введение 4

Постановка задачи 5

Методы проектирования 6

Этапы создания ПО 10

Выявление требований 12

Описание программы 14

Проектирование инфологической модели 14

Даталогическое проектирование 15

Разграничение доступа 17

Администратор 18

Пациент 25

Тестирование 30

Общие сведения 30

Процесс тестирования 31

Результаты тестирования 35

Заключение 36

Библиографический список 37

ПРИЛОЖЕНИЕ А 38

ПРИЛОЖЕНИЕ Б 41

ПРИЛОЖЕНИЕ В 42

ПРИЛОЖЕНИЕ Г 43

ПРИЛОЖЕНИЕ Д 44

ПРИЛОЖЕНИЕ Е 52

 

 

Введение

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

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

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

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

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

Постановка  задачи

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

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

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

 

Выбор методологии проектирования

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

1. Функциональную структуру системы;
2. Последовательность выполняемых действий;
3. Передачу информации между функциональными процессами;
4. Отношения между данными.

Наиболее  распространенными моделями первых трех групп являются:

• функциональная модель SADT (Structured Analysis and Design Technique);
• модель IDEF3;
• DFD (Data Flow Diagrams) - диаграммы потоков данных.

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

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

Диаграммы потоков данных (Data Flow Diagrams - DFD) [6] представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления - продемонстрировать, как  каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity-Relationship Model - ERМ). Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области.

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

Методы объектно-ориентированного проектирования ПО

Концептуальной  основой объектно-ориентированного проектирования ПО (ООП) является объектная  модель. Ее основные принципы:

• Абстрагирование
• Инкапсуляция
• Модульность
• Иерархия.

К основным понятиям ООП можно отнести объект, класс, атрибут, операция, интерфейс  и др. Большинство современных  методов ООП основаны на использовании  языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой  язык для определения, представления, проектирования и документирования программных систем, организационно-экономических  систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и  нотаций самых разнообразных  видов.

Стандарт UML содержит следующий набор диаграмм:

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

Опишем  особенности диаграмм и причины, по которым будем использовать их в своем приложении – диаграммы вариантов использования (Приложение Б) и диаграммы классов (Приложение В).

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

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

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

Достоинства модели вариантов использования  заключаются в том, что она:

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

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

Этапы создания ПО

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

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

1. Этап проектирования программного комплекса. На этом этапе усилиями заказчика и компании исполнителя создается техническое задание, которое служит основой для разработки программ. Без этого этапа невозможна разработка программ, поэтому он требует времени. Обычно, на него уходит от 1 до 3 недель, в зависимости от сложности проекта и квалификации сотрудников. Кроме того, на этом этапе составляется смета и график работ по созданию программы.
2. Этап разработки программного комплекса. Собственно и является процессом разработки программного обеспечения. На этом этапе, осуществляется создание ПО согласно утвержденному ранее техническому заданию и смете. По окончанию этого этапа, заказчик получает диск с уже готовой программой, а так же всю документацию необходимую для работы с программой. Длительность этого этапа, а так же стоимость написания программы рассчитываются индивидуально, и зависят от сложности проекта и от особенностей указанных в техническом задании.
3. Этап внедрения программного обеспечения. Собственно, на этом этапе разработка программного обеспечения уже закончена, и начинается процесс поддержки пользователя. Обычно, в этот этап включают в себя установку нового ПО на компьютеры в организации, а так же обучение сотрудников организации использованию нового программного обеспечения.
4. И наконец, последний этап – информационная поддержка. В этот этап обычно включается гарантийное обслуживание ПО, выявление и устранение мелких ошибок, а так же внесение изменений, не влекущих за собой изменение программной структуры.

 

Выявление требований

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

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

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