Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное государственное автономное

образовательное учреждение

высшего профессионального образования

«СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Хакасский технический институт - филиал СФУ

ФГАОУ ВПО «Сибирский федеральный университет институт

КУРСОВАЯ РАБОТА

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

Крылова А.А.

Руководитель Минеев П.В.

Абакан 2015



ЗАДАНИЕ

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

1. Составить глоссарий проекта.

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

3. Построить диаграмму вариантов использования (с необходимыми комментариями) и при необходимости модифицировать ее.

4. Добавить к вариантам использования связи (Hyperlinks).

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

6. На основе анализа описаний вариантов использования составить в браузере модели список классов модели.

7. Для каждого потока событий составить диаграмму последовательности.

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

9. Сгенерировать новый модуль с представлением в нем созданных классов.

10. Организовать документирование заявленных элементов.

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

Задание выдал________________________ зав. кафедры Минеев П.В.

Задание получил _______________ студент группы 52-1 Крылова А. А.



РЕФЕРАТ

Курсовая работа по теме «Проектирование информационной системы на основе объектно-ориентированного подхода средствами языка моделирования UML» содержит 43 страниц текстового документа, 4 использованных источника, 11 рисунков.

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

Ключевые слова: ИНФОРМАЦИОННАЯ СИСТЕМА, CASE, ИС, ОТЧЕТ, MODELMAKER, UML, ДИАГРАММА, ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ, КЛАСС, ОБЪЕКТ, ДЕЙСТВУЮЩЕЕ ЛИЦО, ОПТОВАЯ БАЗА.

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

Задачи курсовой работы:

Изучить предметную область.

Спроектировать информационную систему с помощью средства ModelMaker.

- Организовать документирование элементов.

Оформить пояснительную записку.

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



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. Описание предметной области информационной системы отповой базы
• 2. Главной диаграмма модели информационной системы отповой базы
• 2.1 Составление списка действующих лиц
• 3. Диаграмма вариантов использования информационной системы отповой базы
• 3.1 Построение диаграммы вариантов использования
• 3.2 Описание вариантов использования
• 4. Архитектурный анализ информационной системы отповой базы
• 4.1 Диаграммы последовательности
• 4.2 Диаграмма классов1
• 4.3 Модуль проекта
• 5. Документирование проекта информационной системы отповой базы1
• ГЛОССАРИЙ
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ



ВВЕДЕНИЕ

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

Задачи курсовой работы:

- закрепить и обобщить знания по проектированию информационных систем;

- изучить предметную область;

- спроектировать информационную систему согласно заданию;

- овладеть практическими навыками работы с инструментальным средством разработки информационных систем ModelMaker.

- оформить пояснительную записку.

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

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



1. Описание предметной области информационной системы оптовая база

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

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

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

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

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



2. Построение диаграммы модели информационной системы оптовой базы

2.1 Составление списка действующих лиц

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

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

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

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

Теперь необходимо создать в ModelMaker главную диаграмму модели и диаграммы действующих лиц (рис. 1).



Рисунок 1 - Перечень действующих лиц в главной диаграмме модели

2.2 Составление перечня вариантов использования

Следующий этап - составление списка вариантов использования.

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

Исходя из потребностей действующих лиц и описания предметной области, были созданы следующие варианты использования:

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

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

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

- Принять заказа покупателя. Администратор утверждает принятие заказа поставщика, система рассылает прайсы покупателям.

- Установить расписание. Система предоставляет администратору форму, в которой он указывает время доставки и адрес в потовую базу.

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

- Сформировать отчет за определенные периоды времени о работе.

- Сформировать отчет по списку оптовых покупателей.

- Сформировать отчет по заявкам на товары.

- Сформировать отчет по анализам продаж.

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

Рисунок 2 - Список вариантов использования информационной системы оптовой базы



3. Диаграмма вариантов использования информационной системы оптовой базы

3.1 Построение диаграммы вариантов использования

Диаграмма вариантов использования описывает функциональные возможности системы и применяется при общении разработчиков с пользователями и заказчиками системы. На диаграмме вариантов использования изображаются внешние субъекты и их связь с аспектами использования системы [2].

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

Рисунок 3 - Диаграмма вариантов использования информационной системы оптовой базы



3.2 Описание вариантов использования

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

- Заполнить форму заявки на покупку.

- Внести данные о продавце и товара.

- Сформировать отчет по заявкам на товары.

Вариант использования «Заполнить форму заявки на товар»

Краткое описание. Данный вариант использования описывает заполнение покупателем формы заявки на покупку товаров.

Основной поток событий

1. Открыть форму заявки на заполнение списка товаров.

2. Внести количество, наименование оптового продукта.

3. Выбрать предполагаемое срок доставки.

4. Сохранить изменения в системе.

5. Оповестить администратора о поступившей заявке (выполняется системой).

Предусловия

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

Постусловия

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



4. Архитектурный анализ информационной системы оптовой базы

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

Как правило, в потоках событий каждого варианта использования выявляются классы трех типов (Category):

Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой.

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

Управляющие классы (Control) - обеспечивают координацию объектов в системе.

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

Первым событием в данном варианте использования является событие «Открыть форму заявки на заказ в базе». Для реализации данного события потребуется сообщение, источник и приемник сообщения. Источником сообщения будет действующее лицо «Покупатель». Сообщение будет адресоваться граничному классу с названием «RequestForm» (Форма заявки на покупку). Данная форма является посредником при взаимодействии покупателя с системой.

Для реализации второго события «Внести количество и наименования продуктов» необходимо добавить в модель управляющий класс «ControllerRecord» (Контролер записей), который будет координировать запись данных в электронную базу. Поскольку система сохраняет данные о покупателе, содержащие список товаров, наименование товаров, контакты, выбранные категорию, можно выделить класс сущности «ListStudents» (Список покупателей) - таблица с данными о покупателях. Анализируя остальные события и рассуждая аналогичным образом, можно выявить остальные классы, которые необходимы для реализации основного потока событий рассматриваемого варианта использования. Результатом работы данного варианта использования будет созданная системой заявка, поскольку сами заявки не хранятся в системе, а только отправляются администратору для последующего анализа, нужно создать граничный класс: «Request» (Заявка). Далее приведен их полный перечень:

1) Граничный класс RequestForm - электронная форма заявки на продукт.

2) Граничный класс Request - заявка на продукт.

3) Управляющий класс ControllerRecordRequest - контролер записей персональных данных о покупателе в электронную базу.

Ниже приведены перечни классов для данных вариантов использования.

Перечень классов для варианта использования «Сформировать отчет по заявкам на товары»:

1) Граничный класс EAReportForm - электронная форма для формирования отчета: внесение данных о продуктах.

2) Управляющий класс ControllerEAReport - контролер событий.

3) Класс-сущность InternalExamResults - таблица с результатами заявок.

Далее нужно создать список классов в ModelMaker. Он представлен на рисунке 5.



Рисунок 5 - Перечень классов модели информационной системы оптовой базы

4.1 Диаграммы последовательности

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

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

Диаграмма последовательности «Заполнить форму заявки на товар»

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

TRequestForm - электронная форма заявки на товар, граничный класс (Boundary).

TRequest - заявка на товар, граничный класс (Boundary).

TControllerRecordRequest - контролер записей персональных данных о покупателе в электронную базу, управляющий класс (Control).

Действующее лицо - Покупатель.

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

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 1. Запрос формы «Заявка».

От граничного класса «TRequestForm» к действующему лицу «Покупатель» передается сообщение: 2. Предоставление формы «Заявка».

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

От действующего лица «Покупатель» к управляющему классу «TControllerRecordRequest» передается сообщение: 4. Сохранить изменения.

От управляющего класса «TControllerRecordRequest» посылается сообщение самоделегирования: 5. Сформировать заявку.

От управляющего класса «TControllerRecordRequest» к граничному классу TRequest посылается сообщение: 6.Отправить заявку.

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 7.Закрытие формы «Заявка»

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 6.



Рисунок 6 - Диаграмма последовательности для варианта использования «Заполнить форму заявки на товар»

Диаграммы последовательности для вариантов использования «Внести данные о назначенном поставщике» и «Сформировать отчет по допуску на экзамен ГИБДД» создаются аналогичным образом.

Диаграмма последовательности «Внести данные о назначенном поставщике»

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

TDataLearnerForm- электронная форма для ввода данных о покупателе, граничный класс (Boundary).

TListCarInstructor - таблица с записями о товарах, класс-сущность (Entity).

TLearner - соответствует действующему лицу «Покупатель», класс-сущность.

TInstructor - соответствует действующему лицу «Поставщик», класс-сущность.

Действующее лицо - Администратор.

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

От действующего лица «Администратор» к граничному классу «TDataLearnerForm» передается сообщение: 1. Запрос формы «Данные о покупателе».

От действующего лица «Администратор» к управляющему классу «TControllerRecordLearner» передается сообщение: 2. Запрос данных.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TListCarInstructor» передается сообщение: 3. Запрос информации о товарах.

От управляющего класса «TControllerRecordLearner» посылается сообщение самоделегирования: 4. Формирование запроса.

От действующего лица «Администратор» посылается сообщение самоделегирования: 5. Определить товар.

От действующего лица «Администратор» к граничному классу «TDataLearnerForm» передается сообщение: 6. Ввод данных.

От действующего лица «Администратор» к управляющему классу «TControllerRecordLearner» передается сообщение: 7. Сохранить изменения в системе.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TLearner» передается сообщение: 8. Отправить сведения покупателю.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TInstructor» передается сообщение: 9. Оповестить поставщика.

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 7.

Рисунок 7 - Диаграмма последовательности для варианта использования «Внести данные о назначенном товаре»

4.2 Диаграмма классов

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

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

Диаграмма классов включает в себя набор классов модели и описание каждого из них.

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

На основе диаграммы последовательности «Внести данные о назначенном товаре» можно добавить в класс «TListCarInstructor» следующие свойства:

- «FullName».

- «Car».

- «QuantityLearner».

Далее нужно указать видимость свойства (Visibility).

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

Private (закрытый). Соответствующий атрибут не виден никаким другим классам.

Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам.

В данном случае, все атрибуты общие (public).

Далее нужно определить операции. Для атрибута «FullName» в группе чтения значения атрибута указывается Method. Система ModelMaker автоматически генерирует название: GetFullName. В группе Write Access так же необходимо выбрать Method. Система создаст название метода SetFullName. В качестве параметра указывается любое имя. В данном случае value. Аналогичным образом создаются методы доступа для других атрибутов данного класса.

Следует подготовить программную реализацию методов (GetFullName, SetFullName). Для этого на странице Implementation нужно прописать следующий программный код по строкам:

Для метода GetFullName: Result:=FFullName.

Для метода SetFullName: FFullName:=value.

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

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

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

AddRecord - добавляет новую запись в класс.

DeleteRecord - удаляет запись из класса.

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

Аналогично задаются атрибуты и методы другим классам.

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

Класс «InternalExamResults»:

- «NameLearner».

- «PracticeResult».

- «TheoryResult».

Класс «TInstructor»:

- «FullName».

- «DOB».

- «PassportData».

- «Address».

- «Education».

- «DrivingExperience».

Для электронных форм можно выделить две операции:

- «OpenForm» (открыть форму).

- «CloseForm» (закрыть форму).

Операции класса ExamAdmissionReport:

- «CreateReport» (Создать отчет).

- «DestroyReport» (Удалить отчет).

- «PrintReport» (Отправить отчет на печать).

Созданная диаграмма классов представлена на рисунке 9.

Рисунок 9 - Диаграмма классов информационной системы оптовой базы

4.3 Модуль проекта

Следующий этап проектирования информационной системы оптовой базы - генерация нового модуля, в котором будут представлены созданные классы модели. Для создания нового модуля нужно перейти на панель Units и воспользоваться функцией Add (Добавить модуль). Необходимо задать местоположение исходного файла (Relative Unit file name), указать подходящие имя файла и путь, а также добавить классы, включаемые в модуль. После окончания диалога появится сгенерированный шаблон будущего модуля.

Для генерации кода модуля необходимо выполнить команду «Unlock», затем «Generation», далее запустить Delphi и создать модуль «Locate In Delphi».

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

Листинг файла modul.pas

unit modul;

interface

uses

SysUtils, Windows, Messages, Classes, Graphics, Controls,

Forms, Dialogs;

type

TRequestForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TRequest = class (TObject)

public

procedure CreateRequest;

procedure SendRequest;

end;

TQueryListCI = class (TObject)

end;

TListCarInstructor = class (TObject)

private

FCar: string;

FFullName: string;

FQuantityLearner: Integer;

public

procedure AddRecord;

procedure DeleteRecord;

function GetCar: string;

function GetFullName: string;

function GetQuantityLearner: Integer;

procedure SetCar(Value: string);

procedure SetFullName(Value: string);

procedure SetQuantityLearner(Value: Integer);

property Car: string read GetCar write SetCar;

property FullName: string read GetFullName write SetFullName;

property QuantityLearner: Integer read GetQuantityLearner write

SetQuantityLearner;

end;

TLearner = class (TObject)

end;

TInternalExamResults = class (TObject)

private

FNameLearner: string;

FPracticeResult: string;

public

procedure AddRecord;

procedure DeleteRecord;

function GetNameLearner: string;

function GetPracticeResult: string;

function GetTheoryResult: string;

procedure SetNameLearner(const Value: string);

procedure SetPracticeResult(Value: string);

procedure SetTheoryResult(Value: string);

property NameLearner: string read GetNameLearner write SetNameLearner;

property PracticeResult: string read GetPracticeResult write

SetPracticeResult;

property TheoryResult: string read GetTheoryResult write SetTheoryResult;

end;

TInstructor = class (TObject)

private

FAddress: string;

FDOB: string;

FDrivingExperience: string;

FEducation: string;

FFullName: string;

FPassportData: TPassportData;

public

function GetAddress: string;

function GetDOB: string;

function GetDrivingExperience: string;

function GetEducation: string;

function GetFullName: string;

function GetPassportData: TPassportData;

procedure SetAddress(Value: string);

procedure SetDOB(Value: string);

procedure SetDrivingExperience(Value: string);

procedure SetEducation(Value: string);

procedure SetFullName(Value: string);

procedure SetPassportData(Value: TPassportData);

property Address: string read GetAddress write SetAddress;

property DOB: string read GetDOB write SetDOB;

property DrivingExperience: string read GetDrivingExperience write

SetDrivingExperience;

property Education: string read GetEducation write SetEducation;

property FullName: string read GetFullName write SetFullName;

property PassportData: TPassportData read GetPassportData write

SetPassportData;

end;

информационный оптовый рascal

TExamAdmissionReport = class (TObject)

public

procedure CreateReport;

procedure DestroyReport;

procedure PrintReport;

end;

TEAReportForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TDataLearnerForm = class (TObject)

public

procedure CloseForm;

procedure OpenForm;

end;

TControllerRecordRequest = class (TObject)

end;

TControllerRecordLearner = class (TObject)

end;

TControllerEAReport = class (TObject)

end;

procedure Register;

implementation

procedure Register;

begin

end;

{

********************************* TRequestForm *********************************

}

procedure TRequestForm.CloseForm;

begin

end;

procedure TRequestForm.OpenForm;

begin

end;

{

*********************************** TRequest ***********************************

}

procedure TRequest.CreateRequest;

begin

end;

procedure TRequest.SendRequest;

begin

end;

{

****************************** TListCarInstructor ******************************

}

procedure TListCarInstructor.AddRecord;

begin

end;

procedure TListCarInstructor.DeleteRecord;

begin

end;

function TListCarInstructor.GetCar: string;

begin

Result:=FCar

end;

function TListCarInstructor.GetFullName: string;

begin

Result:=FFullName

end;

function TListCarInstructor.GetQuantityLearner: Integer;

begin

Result:=FQuantityLearner

end;

procedure TListCarInstructor.SetCar(Value: string);

begin

FCar:=value

end;

procedure TListCarInstructor.SetFullName(Value: string);

begin

FFullName:=value

end;

procedure TListCarInstructor.SetQuantityLearner(Value: Integer);

begin

FQuantityLearner:=value

end;

{

***************************** TInternalExamResults *****************************

}

procedure TInternalExamResults.AddRecord;

begin

end;

procedure TInternalExamResults.DeleteRecord;

begin

end;

function TInternalExamResults.GetNameLearner: string;

begin

end;

function TInternalExamResults.GetPracticeResult: string;

begin

end;

function TInternalExamResults.GetTheoryResult: string;

begin

end;

procedure TInternalExamResults.SetNameLearner(const Value: string);

begin

end;

procedure TInternalExamResults.SetPracticeResult(Value: string);

begin

end;

procedure TInternalExamResults.SetTheoryResult(Value: string);

begin

end;

{

********************************* TInstructor **********************************

}

function TInstructor.GetAddress: string;

begin

end;

function TInstructor.GetDOB: string;

begin

end;

function TInstructor.GetDrivingExperience: string;

begin

end;

function TInstructor.GetEducation: string;

begin

end;

function TInstructor.GetFullName: string;

begin

end;

function TInstructor.GetPassportData: TPassportData;

begin

end;

procedure TInstructor.SetAddress(Value: string);

begin

end;

procedure TInstructor.SetDOB(Value: string);

begin

end;

procedure TInstructor.SetDrivingExperience(Value: string);

begin

end;

procedure TInstructor.SetEducation(Value: string);

begin

end;

procedure TInstructor.SetFullName(Value: string);

begin

end;

procedure TInstructor.SetPassportData(Value: TPassportData);

begin

end;

{

***************************** TExamAdmissionReport *****************************

}

procedure TExamAdmissionReport.CreateReport;

begin

end;

procedure TExamAdmissionReport.DestroyReport;

begin

end;

procedure TExamAdmissionReport.PrintReport;

begin

end;

{

******************************** TEAReportForm *********************************

}

procedure TEAReportForm.CloseForm;

begin

end;

procedure TEAReportForm.OpenForm;

begin

end;

{

******************************* TDataLearnerForm *******************************

}

procedure TDataLearnerForm.CloseForm;

begin

end;

procedure TDataLearnerForm.OpenForm;

begin

end;

end.



5. Документирование проекта информационной системы отповой базы

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

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

Рисунок 10 - Документирование свойства «Address»

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

Далее следует создать файл помощи через команду Help File на панели Documentation. Система сгенерирует файл справки в формате RTF (рис. 11).

Рисунок 11 - Окно файла справки help.rtf



ГЛОССАРИЙ

Глоссарий предназначен для описания терминологии предметной области оптовая база.

Действующее лицо - это что-либо, взаимодействующее с системой и находящееся во внешней среде.

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

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

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

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

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

САSЕ-технология - совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей

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

Диаграмма классов - это графическое моделирование средствами UML статической структуры применяемых в системе классов и связей между ними.

Диаграмма последовательности - это графическое моделирование средствами UML поведения объектов с акцентом на последовательность сообщений в рамках одного варианта использования.

Самоделегирование - сообщение, которое объект посылает самому себе.

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

ModelMaker - это CASE-инструмент объектно-ориентированного проектирования информационных систем.



ЗАКЛЮЧЕНИЕ

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

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

Также был создан предварительный модуль проекта на языке Object Pascal и обеспечен документацией.



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Проектирование информационных систем: Методические указания к выполнению курсовой работы для студентов специальности 351400 «Прикладная информатика в экономике» / Сост. П.В. Минеев. Красноярск, КГТУ, 2004. 36 с.

2. Проектирование информационных систем: учеб. пособие / П. В. Минеев ; Сиб. федер. ун-т, ХТИ - филиал СФУ. - Абакан : РИСектор ХТИ - филиала СФУ, 2012

3. Дубаков А.А. Проектирование информационных систем: Учебное пособие. Томск.: Изд. ТПУ, 2001.

4. CyberForum.ru - форум программистов и системных администраторов. [Электронный ресурс]. - Режим доступа: http://www.cyberforum.ru/.

Размещено на Allbest.ru