49650

Разработка программного продукта АИС «Название отдела (рабочего места)»

Курсовая

Информатика, кибернетика и программирование

Проектирование информационно-логической модели БД Этапы создания информационной системы базы данных Типовой жизненный цикл информационной системы любого класса представляет собой последовательность этапов: анализа предметной области проектирования системы разработки и реализации системы тестирования и отладки сопровождения системы. Этап анализа предметной области включает: Формулировку требований к функциональности будущей системы; Определение объемов и структуры...

Русский

2014-01-05

573.5 KB

59 чел.

Тема курсового проектирования  4П1:

Разработка программного продукта АИС «Название отдела (рабочего места)»

СОДЕРЖАНИЕ

Введение

1. Теоретический раздел

        1.1. Основы разработки ПО АИС

1.2. Обоснование выбора СУБД и языка программирования

1.3. Технические средства реализации проекта

2. Раздел проектирования АИС

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

2.2. Проектирование информационно-логической модели БД

 2.2.1. Проектирование концептуальной модели

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

 2.2.3. Проектирование физической модели

2.3. Проектирование интерфейса пользователя

3. Экспериментальный раздел

3.1. Тестирование программы

3.2. Характеристика программы

4. Эффективность создания программного продукта

Заключение

Список литературы

Список сокращений

Приложение А. Диаграммы

Приложение Б. Инструкция пользователя

Приложение В. Текст программы (листинг)

Примерная структура пояснительной записки

ВВЕДЕНИЕ

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

Мы предлагаем решение поставленной задачи в рамках разработки ПП АИС «…».

В качестве среды разработки мы использовали интегрированную среду разработки Delphi и СУБД ACCESS, что позволило получить первичные навыки работы в современной и широко используемой на практике среде разработки приложений.

Проектирование программного обеспечения является сложным процессом, который может выполняться как «вручную», так и с использованием развитых автоматизированных средств и различных нотаций – схем, ER-, UML-, DFD-диаграмм и др. Обычно при разработке ПП проектированию подлежит:

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

Цель курсового  проекта по дисциплине «…» состоит в закреплении и углублении знаний и навыков, полученных при изучении дисциплины.

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

И т.д. и т.п.

Во введении (1-2 страницы) отражаются следующие моменты:

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

степень разработанности выбранной темы;

определение предмета (объекта) исследования;

определение основной цели работы;

формулирование задач для раскрытия темы КР (КП);

определение теоретических основ исследования;

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

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

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

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

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

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

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

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

В конце введения следует отметить элементы научной новизны и практическое значимости полученных результатов КР (КП) для конкретной предметной области.       

1. ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ

1.1. Основы разработки ПО АИС

1.2. Обоснование выбора СУБД и языка программирования

1.3. Описание операционной системы

2. РАЗДЕЛ ПРОЕКТИРОВАНИЯ АИС

 

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

Разработка информационной системы для АИС «…» обусловлена необходимостью автоматизации …. Сформулируем требования к проекту информационной системы «…».

Информационная система «….»  предназначена для ввода, хранения и обработки данных  ………. .

Описание предметной области

(например, описывается АИС Склад)

Склад предназначен для хранения товаров определенных категорий (типов).

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

- Для каждого наименования товара следует знать размер минимального запаса, определенного для этого вида товара.

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

- Информационная система должна включать сведения о типе (категории) товара, наименовании товара, номерах партий поставляемого товара.

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

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

Партии товаров поступают на склад в стандартных упаковках, под размеры которых сконструированы полки склада.

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

- Полки спроектированы под определенные типы товаров.

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

- Необходимо хранить сведения о покупателях: их реквизиты и телефоны для связи.

- Следует предусмотреть оформление заказа на покупку партий товаров с указанием цены продажи каждой партии, количества партий, условий оплаты (формы оплаты и наличие оплаты), дату заказа.

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

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

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

- Отчетов об имеющихся на складе партиях товаров;

- Отчетов об объемах продаж по различным группам товаров;

- Вычислений полученной прибыли за указанный период.

Для увеличения объема продаж предполагается создание электронного каталога с публикацией его в сети Internet.

- Каталог должен позволять выполнять просмотр всех товаров, представленных на складе.

2.2. Проектирование информационно-логической модели БД

Этапы создания информационной системы базы данных

Типовой жизненный цикл информационной системы любого класса представляет собой последовательность этапов:

- анализа предметной области,

- проектирования системы,

- разработки и реализации системы,

- тестирования и отладки,

- сопровождения системы.

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

1. Этап анализа предметной области включает:

- Формулировку требований к функциональности будущей системы;

- Определение объемов и структуры данных, хранимых и обрабатываемых в системе;

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

- Оценку требуемой надежности системы и др.

2. На этапе проектирования предусматривается выполнение таких работ как:

- Идентификацию объектов предметной области;

- Декомпозицию функций информационной системы;

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

3. На этапе разработки информационной системы выполняется:

- Разработка физической модели базы данных;

- Реализация базы данных в рамках выбранной СУБД;

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

- Разработка текстов программного обеспечения информационной системы.

4. Этапы тестирования и отладки предусматривают, в том числе:

- Объединение подсистем;

- Сопряжение с реальной аппаратурой.

5. Под сопровождение понимают:

- Выпуск документации по системе;

- Исправление ошибок;

- Обобщение опыта эксплуатации;

- Администрирование системы.

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

2.2.1. Проектирование концептуальной модели

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

Целями анализа и моделирования требований являются:

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

Для достижения этих целей используются диаграммы вариантов использования UML (Use case diagrams).

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

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

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

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

Проектирование любой АИС лучше всего начинать с построения диаграммы прецендентов, описывающей внешнюю границу АИС. Такая диаграмма называется главной диаграммой прецендентов. Для разрабатываемой АИС «…» главная диаграмма прецендентов показана на рис.

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

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

Этот фрагмент концептуальной схемы базы данных может быть построен в виде диаграммы классов с помощью программы Rational Rose, основанной на языке UML. Линии, заканчивающиеся стрелкой показывают иерархию наследования для класса "пользователь". Правая линия без стрелки с числовыми метками изображает двунаправленное отношение между классами Учебный курс и Студент. Метки 0..4 и 3..10 означают, что в данном семестре конкретный студент может посещать от 0 до 4-х учебных курсов, а данный курс может читаться нескольким студентам - от 3-х до 10-ти.

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

Модель «сущность-связь» (Entity Relationship – ER-модель) является визуальным средством представления объектов рассматриваемой предметной области, их характеристик (реквизитов) и отношений между объектами.

В качестве программного средства для представления модели будем использовать CASE-инструментарий (Computer Aided Software Engineering) фирмы Sybase Power Designer.

Идентификация объектов предметной области и отношений между ними

Основными информационными объектами системы СКЛАД являются:

ПОКУПАТЕЛЬ, ЗАКАЗ, ТОВАР, ПОСТАВЩИК, ПОЛКА_СКЛАДА (рис. 6). Между ними можно установить следующие логические отношения:

- «ПОКУПАТЕЛЬ» «должен» «ЗАКАЗАТЬ» один или более «ЗАКАЗ».

- «ЗАКАЗ» «должен» «БЫТЬ ЗАКАЗАН» «один и только один» «ПОКУПАТЕЛЬ».

- «ТОВАР» «может быть» «ЗАКАЗАН» «в одном или более» «ЗАКАЗОВ».

- «ЗАКАЗ» «должен» «СОСТОЯТЬ» «из одного или более» «ТОВАРОВ».

- На «ПОЛКЕ» «может» «ХРАНИТЬСЯ» «один или более» «ТОВАРОВ».

- «ТОВАР» «должен» «ХРАНИТЬСЯ» «на одной или нескольких» «ПОЛКАХ».

- «ПОСТАВЩИК» «должен» «ПОСТАВЛЯТЬ» «один или более» «ТОВАРОВ».

- «ТОВАР» «должен быть» «ПОСТАВЛЕН» «одним или более» «ПОСТАВЩИКОМ».

Идентифицированные объекты представлены в виде сущностей и атрибутов в модели на рис.6. Отношения между объектами реализованы в виде логических отношений сущностей (рис.6).

Создание модели «сущность-связь»

Для информационных объектов, идентифицированных в рамках рассматриваемой предметной области СКЛАД, с помощью CASE-инструментария Power Designer создана модель «сущность-связь» (рис.2).

Рис.2. Модель «сущность-склад» для предметной области СКЛАД

Нормализация модели данных

Модель «сущность-связь», представленная на рис.2 не находится в первой нормальной форме, так как в сущностях ПОКУПАТЕЛЬ, ТОВАР и ЗАКАЗ имеются множественные и повторяющиеся атрибуты, которые представляют собой упущенные в модели сущности.

На рис.3 показан результат приведения к 1НФ сущности ПОКУПАТЕЛЬ. Атрибут ТИП_ПОКУПАТЕЛЯ выделен в отдельную сущность и исключен из сущности ПОКУПАТЕЛЬ, как повторяющийся атрибут.

Рис.3. Приведение к 1НФ сущности ПОКУПАТЕЛЬ

На рис.4 показан результат приведения к 1НФ сущности ТОВАР. Группа множественных атрибутов ПАРТИЯ, ДАТА_ПОСТАВКИ, КОЛИЧЕСТВО, НАЛИЧИЕ, ЦЕНА_ПОСТАВКИ являются упущенной сущностью ПАРТИЯ_ТОВАРА, поэтому они были удалены из сущности ТОВАР и вынесены в отдельную сущность ПАРТИЯ_ТОВАРА. Установлена логическая связь между новой сущностью ПАРТИЯ_ТОВАРА и сущностью ПОСТАВЩИК (рис.8).

Повторяющийся атрибут ТИП_ТОВАРА вынесен из сущности ТОВАР в отдельную сущность (рис.4).

Рис.4. Приведение к 1НФ сущности ТОВАР

На рис.5 показан результат приведения к 1НФ сущности ЗАКАЗ. Повторяющийся атрибут ФОРМА_ОПЛАТЫ вынесен в отдельную сущность и исключен из сущности ЗАКАЗ (рис.5).

Группа множественных атрибутов НАИМНОВАНИЕ_ТОВАРА, КОЛИЧЕСТВО, ЦЕНА_РЕАЛИЗАЦИИ вынесена в отдельную сущность ПУНКТ_ЗАКАЗА и исключена из сущности ЗАКАЗ. При установлении логических связей новой сущности ПУНКТ_ЗАКАЗА с сущностью ТОВАР из сущности ПУНКТ_ЗАКАЗА устранена дублирующая информация о товаре (рис.9). Для однозначной идентификации экземпляров сущности ПУНКТ_ЗАКАЗА недостаточно собственного ключевого атрибута НОМЕР_ПОЗИЦИИ, а, следовательно, связи с сущностями ЗАКАЗ и ТОВАР следует сделать ключевыми (рис.5).

Окончательный результат приведения к 1НФ всей модели показан на рис. 5. Между сущностями ПОЛКА и ТИП_ТОВАРА установлена логическая связь, которая следует из анализа предметной области: полки спроектированы под определенные типы товаров, то есть полка характеризуется типом товара, который может быть на ней размещен (рис.5).

Рис.5. Приведенная к 1НФ модель СКЛАД

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

В модели нет сущностей, имеющих составные идентификаторы, таким образом, модель находится во 2НФ.

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

В модели нет сущностей, имеющих транзитивные зависимости атрибутов от атрибутов, не являющихся частью ключа, таким образом, модель находится в 3НФ.

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

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

В модели СКЛАД присутствует связь «многие-ко-многим» между сущностями ПОЛКА и ТОВАР. Устранение этой связи требует создания межсекционной сущности. По смыслу, имя такой межсекционной сущности может быть ПАРТИЯ_ТОВАРА. Так как в модели уже присутствует сущность ПАРТИЯ_ТОВАРА, то в целях устранения избыточности хранения данных, эта сущность может быть использована в качестве межсекционной при устранении связи «многие-ко-многим». Результат устранения множественной связи показан на рис. 6.

Рис.6. Модель СКЛАД после устранения связей «многие-ко-многим»

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

  •  Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
  •  Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС.
  •  Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
  •  Для моделирования логики программных компонент (будет описано в последующих статьях).
  •  Для моделирования логики обработки данных.

2.2.3. Разработка физической модели

На основе модели «сущность-связь» (диаграмма Классов) синтезируется структура базы данных. В соответствии с правилами разработки физической структуры базы данных для АИС СКЛАД были получены следующие таблицы:

(перечислить в виде таблиц, с указанием типа полей и примечаний).

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

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

- объединение информации из самых разных источников (электронных таблиц, текстовых файлов, других баз данных);

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

- интеграция с компонентами Microsoft Office.

Современные тенденции в развитии информационных технологий – интенсивное внедрение Web-технологий Internet, также получили представление в Access. СУБД Access обеспечивает публикацию баз данных в формате, доступном в сетях Internet и intranet. В Microsoft Access 2000 эти средства получили дальнейшее развитие и позволяют конструировать в интерактивном режиме Web-страницы, предназначенные для работы с базами данных.

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

Все эти и многие другие возможности СУБД Access позволяют сделать выбор в пользу Access. Основное назначение базы данных – хранение, поддержание в актуальном состоянии данных больших объемов, необходимых в различных приложениях многих пользователей – полностью реализуется в СУБД Access. Все современные тенденции – по созданию Web-страниц доступа к данным, многопользовательского режима работы, поддержание технологии клиент-сервер, интеграции с другими приложениями, даже средства разработки проектов, которые являются клиентскими приложениями Microsoft SQL Server – всеми этими возможностями обладает СУБД Access.

Средствами выбранной СУБД Access созданы таблицы реляционной базы данных и схема отношений (рис.7).

Рис.7. Схема данных для базы данных СКЛАД

Реализация таблиц для базы данных СКЛАД в Access имела следующие особенности:

1. Поскольку таблица ФОРМА_ОПЛАТЫ содержит только два взаимоисключающих значения: наличный или безналичный расчет, то эти значения можно закодировать числами 0 и 1, и хранить в поле таблицы ЗАКАЗ. А реализацию этого поля в форме ЗАКАЗ (этот объект позволяет заполнять таблицу) выполнить с помощью элемента управления «переключатель». Таким образом, из модели на рис.7 устранена таблица ФОРМА_ОПЛАТЫ.

2. Для ввода данных в поля ТЕЛЕФОН в таблицах ПОКУПАТЕЛЬ и ПОСТАВЩИК применен механизм маски. Реализация этого механизма показана на рис.8.

Рис.8. Использование маски ввода для поля ТЕЛЕФОН

3. Для ввода электронной почты в поле e-mail таблицы ПОСТАВЩИК был использован тип данных гиперссылка (рис.9). Использование этого типа данных позволяет автоматизировать ввод почтовых электронных адресов .

Рис.9. Использование поля ГИПЕРССЫЛКА

2.2.4. Технические средства реализации проекта

Режим автоматизированного создания информационных моделей поддерживается компьютерными продуктами класса CASE (Computer-Aided Software/System Engineering) – инструментарием, позволяющим автоматизировать проектирование информационных систем.

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

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

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

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

При проектировании архитектуры ПО принимаются ключевые проектные решения относительно внутреннего устройства программной системы и её технических интерфейсов. При проектировании архитектуры  в общем случае необходимо:

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

При выполнении курсовой работы реализуем проектирование архитектуры ПО системы путем разработки ее структурной и/или функциональной схемы ПО системы.

На схеме должны быть однозначно отражены:

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

Пример обобщенной структуры некоторой информационной системы приведен на рис. 1.

Рис. 1. Пример обобщенной структуры некоторой информационной системы

2.3. Проектирование интерфейса пользователя

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

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

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

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

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

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

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

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

3) Отсутствие перегруженности (небольшое число объектов на экране – не более 10).

4) Устойчивость (по возможности предотвращение некорректных действий пользователя).

В результате мы предлагаем следующий интерфейс разработанного АИС «…».

Объяснение в тексте,  рисунки можно перенести в Приложение, если объем работы зашкаливает.

На этапе анализа были сформулированы задачи, которые пользователи системы будут выполнять с использованием созданной базы данных. Перечислим задачи пользователя, для решения которых необходимо разработать пользовательский интерфейс разработанной АИС:

1. Оформление заказов покупателей – форма ЗАКАЗ.

2. Прием партий товара от поставщика и размещение партий товаров на полках склада – форма ТОВАР.

3. Заказ поставщику недостающих на складе товаров – форма ПОСТАВЩИК.

4. Извещение покупателей об истечении срока оплаты заказа – запросы ОПЛАТА.

5. Анализ загруженности склада – запросы СКЛАД.

6. Формирование финансовой отчетности о полученной прибыли – отчеты  ПРИБЫЛЬ.

(описать назначение каждой формы, отчета, запроса + снимок разработанного объекта)

3. ЭКСПЕРИМЕНТАЛЬНЫЙ РАЗДЕЛ

3.1. Тестирование программы

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

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

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

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

В общем виде тестирование предусматривает последовательное выполнение следующих этапов:

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

План тестирования должен содержать:

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

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

<действие> > <ожидаемый результат> > <фактический результат>.

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

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

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

В нашей работе мы провели следующие тестовые испытания:

– на входные данные;

– на промежуточный результат;

– на конечный результат.

(Привести код, в какой форме использовался, на каком этапе работы приложения)

3.2. Характеристика программы

Как работает, плюсы и минусы, техническое сопровождение  и т.д.

Дополнительные спецификации обеспечения АИС

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

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

Функциональные возможности. Система должна обеспечивать многопользовательский режим работы. (что это обозначает)

Удобство использования. Пользовательский интерфейс должен быть Windows ХР-совместимым.

Надёжность. Система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя - не более 10%.

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

Безопасность. Система не должна позволять что? Что должна позволять и т.д.

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

Глоссария проекта

Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы.

Ниже приведены термины и их значения.

Термин

Значение

Любой клиент

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

Услуга

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

Диспетчер

Работни, ведущий учет записи клиентов и предоставленных услугах

Автоматизированная информационная система

Система обработки информации о предоставленных услугах и проведенных оплатах

Служащий

Работник предприятия, предоставляемый конкретные услуги

Подразделение

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

И т.д.

Заключение

По имеющимся результатам создания информационной системы СКЛАД, основанной на реляционной базе данных, можно сделать следующие выводы:

- все требования по хранению информационных объектов и их реквизитов, описанных в разделе анализа предметной области, выполнены.

- все требования по управлению данными (добавление, редактирование, удаление, вычисление), описанные в разделе анализа и постановки задачи, выполнены.

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

- воздан электронный каталог товаров, реализуемых со склада.

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


 

А также другие работы, которые могут Вас заинтересовать

79687. Деятельность кадрового подразделения организации 246.5 KB
  Любая организация существует только тогда, когда есть работающие в ней люди. Открытие какой угодно фирмы, предприятия, учреждения, организации начинается с подбора и оформления работников. Поэтому наличие службы кадров или специально выделенного сотрудника, занимающегося оформлением кадров, обязательно для организации не только любого масштаба, но и любой организационно-правовой формы.
79688. Обучение персонала как фактор повышения эффективности работы организации 785.5 KB
  Исследовать пути создания конкурентных преимуществ организации в рыночных условиях хозяйствования; обосновать важность человеческого ресурса как главного ресурса в организации; рассмотреть понятие кадрового потенциала и пути его повышения; рассмотреть порядок организации работы по обучению персонала и систематизировать методы обучения...
79689. Планирование кадров предприятия и их подбор 233.5 KB
  Любая организация создается для выполнения каких-либо целей и нуждается в управлении, а от того насколько эффективно ею управляют, и зависит достижение поставленных задач. Найти правильные методы налаживания связей между целями организации и людьми, которые их выполняют должен руководитель
79690. Презентационные и коммуникативные навыки тренинг-менеджера 177 KB
  Обычно выделяют четыре основные цели презентации в отношении других людей: сообщить информацию; научить; создать мотивацию; развлечь. Сообщить информацию значит дать другим людям полное представление о том что является предметом презентации.
79691. Причины конфликтных ситуаций, программа оптимизации социально-психологического климата в коллективе 304 KB
  Конфликты в организации непосредственно связаны с социально - психологическими явлениями в группе: лидерство, микрогруппа, стили управления, морально - психологический климат и другие. Знание этих явлений является необходимым условием успешного управления конфликтами в организации.
79692. Психологические аспекты адаптации персонала во время испытательного срока 524 KB
  Внедрение грамотно разработанной адаптационной программы (схемы, системы) позволяет получить профессионально состоявшихся, мотивированных сотрудников, способных значительно повысить эффективность работы всей организации.
79693. Система материального стимулирования сотрудника для повышения эффективности работы предприятия 292.5 KB
  Истинные причины, побуждающие работника максимально прикладывать усилия в работе определить нелегко. Этими условиями являются его желание, возможности, квалификация и, конечно же, мотивация - то есть побуждение
79694. Історична панорама розвитку математики 82.22 KB
  Паралельно розвивалися уявлення про число Число́ одне з найголовніших понять математики яке в багатьох випадках може виступати як міра кількості чогось. Математика найдавніших цивілізацій Найдавніші відомості про використання математики господарські задачі в Стародавньому Єгипті Старода́вній Єги́пет одна з найдавніших держав на Землі і колиска цивілізації Середземноморя. Папірус Рінда Московський папірус Шкіряний сувій єгипетської математики та Вавилонії Вавило́нія давня держава в південній частині Месопотамії територія...
79695. Математика Християнського середньовіччя та епохи Відродження 485.53 KB
  Опанувавши елементарні знання, кращі учні монастирських і соборних шкіл вивчали «сім вільних мистецтв», які поділялися на дві частини: тривіум (граматика, риторика, діалектика) і квадривіум (арифметика, геометрія, астрономія, музика)