Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предусловия

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

Постусловия

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

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

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

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

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

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

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

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

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

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

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

Граничный класс RequestF0rm – электронная форма заявки на продукт.
Граничный класс Request – заявка на продукт.
Управляющий класс C0ntr0llerRec0rdRequest – контролер записей персональных данных о п0купателе в электронную базу.

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

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

Граничный класс EARep0rtF0rm – электронная форма для формирования отчета: внесение данных о продуктах.
Управляющий класс C0ntr0llerEARep0rt – контролер событий.
Класс-сущность InternalExamResults – таблица с результатами заявок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– «FullName».

– «Car».

– «QuantityLearner».

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

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

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

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

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

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

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

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

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

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

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

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

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

DeleteRec0rd – удаляет запись из класса.

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

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

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

Класс «InternalExamResults»:

– «NameLearner».

– «PracticeResult».

– «The0ryResult».

Класс «TInstruct0r»:

– «FullName».

– «D0B».

– «Passp0rtData».

– «Address».

– «Educati0n».

– «DrivingExperience».

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

– «0penF0rm» (открыть форму).

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

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

– «CreateRep0rt» (Создать отчет).

– «Destr0yRep0rt» (Удалить отчет).

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

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

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

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

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

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

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

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

unit m0dul;

interface

uses

SysUtils, Wind0ws, Messages, Classes, Graphics, C0ntr0ls,

F0rms, Dial0gs;

type

TRequestF0rm = class (T0bject)

public

pr0cedure Cl0seF0rm;

pr0cedure 0penF0rm;

end;

TRequest = class (T0bject)

public

pr0cedure CreateRequest;

pr0cedure SendRequest;

end;

TQueryListCI = class (T0bject)

end;

TListCarInstruct0r = class (T0bject)

private

FCar: string;

FFullName: string;

FQuantityLearner: Integer;

public

pr0cedure AddRec0rd;

pr0cedure DeleteRec0rd;

functi0n GetCar: string;

functi0n GetFullName: string;

functi0n GetQuantityLearner: Integer;

pr0cedure SetCar(Value: string);

pr0cedure SetFullName(Value: string);

pr0cedure SetQuantityLearner(Value: Integer);

pr0perty Car: string read GetCar write SetCar;

pr0perty FullName: string read GetFullName write SetFullName;

pr0perty QuantityLearner: Integer read GetQuantityLearner write

SetQuantityLearner;

end;

TLearner = class (T0bject)

end;

TInternalExamResults = class (T0bject)

private

FNameLearner: string;

FPracticeResult: string;

public

pr0cedure AddRec0rd;

pr0cedure DeleteRec0rd;

functi0n GetNameLearner: string;

functi0n GetPracticeResult: string;

functi0n GetThe0ryResult: string;

pr0cedure SetNameLearner(c0nst Value: string);

pr0cedure SetPracticeResult(Value: string);

pr0cedure SetThe0ryResult(Value: string);

pr0perty NameLearner: string read GetNameLearner write SetNameLearner;

pr0perty PracticeResult: string read GetPracticeResult write

SetPracticeResult;

pr0perty The0ryResult: string read GetThe0ryResult write SetThe0ryResult;

end;

TInstruct0r = class (T0bject)

private

FAddress: string;

FD0B: string;

FDrivingExperience: string;

FEducati0n: string;

FFullName: string;

FPassp0rtData: TPassp0rtData;

public

functi0n GetAddress: string;

functi0n GetD0B: string;

functi0n GetDrivingExperience: string;

functi0n GetEducati0n: string;

functi0n GetFullName: string;

functi0n GetPassp0rtData: TPassp0rtData;

pr0cedure SetAddress(Value: string);

pr0cedure SetD0B(Value: string);

pr0cedure SetDrivingExperience(Value: string);

pr0cedure SetEducati0n(Value: string);

pr0cedure SetFullName(Value: string);

pr0cedure SetPassp0rtData(Value: TPassp0rtData);

pr0perty Address: string read GetAddress write SetAddress;

pr0perty D0B: string read GetD0B write SetD0B;

pr0perty DrivingExperience: string read GetDrivingExperience write

SetDrivingExperience;

pr0perty Educati0n: string read GetEducati0n write SetEducati0n;

pr0perty FullName: string read GetFullName write SetFullName;

pr0perty Passp0rtData: TPassp0rtData read GetPassp0rtData write

SetPassp0rtData;

end;

TExamAdmissi0nRep0rt = class (T0bject)

public

pr0cedure CreateRep0rt;

pr0cedure Destr0yRep0rt;

pr0cedure PrintRep0rt;

end;

TEARep0rtF0rm = class (T0bject)

public

pr0cedure Cl0seF0rm;

pr0cedure 0penF0rm;

end;

TDataLearnerF0rm = class (T0bject)

public

pr0cedure Cl0seF0rm;

pr0cedure 0penF0rm;

end;

TC0ntr0llerRec0rdRequest = class (T0bject)

end;

TC0ntr0llerRec0rdLearner = class (T0bject)

end;

TC0ntr0llerEARep0rt = class (T0bject)

end;

pr0cedure Register;

implementati0n

pr0cedure Register;

begin

end;

{*********************** TRequestF0rm ***********************}

pr0cedure TRequestF0rm.Cl0seF0rm;

begin

end;

pr0cedure TRequestF0rm. 0penF0rm;

begin

end;

{************************** TRequest *************************}

pr0cedure TRequest.CreateRequest;

begin

end;

pr0cedure TRequest.SendRequest;

begin

end;

{********************* TListCarInstruct0r **********************}

pr0cedure TListCarInstruct0r.AddRec0rd;

begin

end;

pr0cedure TListCarInstruct0r.DeleteRec0rd;

begin

end;

functi0n TListCarInstruct0r.GetCar: string;

begin

Result:=FCar

end;

functi0n TListCarInstruct0r.GetFullName: string;

begin

Result:=FFullName

end;

functi0n TListCarInstruct0r.GetQuantityLearner: Integer;

begin

Result:=FQuantityLearner

end;

pr0cedure TListCarInstruct0r.SetCar(Value: string);

begin

FCar:=value

end;

pr0cedure TListCarInstruct0r.SetFullName(Value: string);

begin

FFullName:=value

end;

pr0cedure TListCarInstruct0r.SetQuantityLearner(Value: Integer);

begin

FQuantityLearner:=value

end;

{******************* TInternalExamResults *********************}

pr0cedure TInternalExamResults.AddRec0rd;

begin

end;

pr0cedure TInternalExamResults.DeleteRec0rd;

begin

end;

functi0n TInternalExamResults.GetNameLearner: string;

begin

end;

functi0n TInternalExamResults.GetPracticeResult: string;

begin

end;

functi0n TInternalExamResults.GetThe0ryResult: string;

begin

end;

pr0cedure TInternalExamResults.SetNameLearner(c0nst Value: string);

begin

end;

pr0cedure TInternalExamResults.SetPracticeResult(Value: string);

begin

end;

pr0cedure TInternalExamResults.SetThe0ryResult(Value: string);

begin

end;

{*********************** TInstruct0r **************************}

functi0n TInstruct0r.GetAddress: string;

begin

end;

functi0n TInstruct0r.GetD0B: string;

begin

end;

functi0n TInstruct0r.GetDrivingExperience: string;

begin

end;

functi0n TInstruct0r.GetEducati0n: string;

begin

end;

functi0n TInstruct0r.GetFullName: string;

begin

end;

functi0n TInstruct0r.GetPassp0rtData: TPassp0rtData;

begin

end;

pr0cedure TInstruct0r.SetAddress(Value: string);

begin

end;

pr0cedure TInstruct0r.SetD0B(Value: string);

begin

end;

pr0cedure TInstruct0r.SetDrivingExperience(Value: string);

begin

end;

pr0cedure TInstruct0r.SetEducati0n(Value: string);

begin

end;

pr0cedure TInstruct0r.SetFullName(Value: string);

begin

end;

pr0cedure TInstruct0r.SetPassp0rtData(Value: TPassp0rtData);

begin

end;

{******************* TExamAdmissi0nRep0rt *******************}

pr0cedure TExamAdmissi0nRep0rt.CreateRep0rt;

begin

end;

pr0cedure TExamAdmissi0nRep0rt.Destr0yRep0rt;

begin

end;

pr0cedure TExamAdmissi0nRep0rt.PrintRep0rt;

begin

end;

{********************** TEARep0rtF0rm ***********************}

pr0cedure TEARep0rtF0rm.Cl0seF0rm;

begin

end;

pr0cedure TEARep0rtF0rm. 0penF0rm;

begin

end;

{********************** TDataLearnerF0rm *********************}

pr0cedure TDataLearnerF0rm.Cl0seF0rm;

begin

end;

pr0cedure TDataLearnerF0rm. 0penF0rm;

begin

end;

end.

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

M0delMaker имеет средства автоматического документирования создаваемого проекта. Можно формировать стандартные комментарии для различных элементов диаграмм, классов и модулей, а также генерировать файлы справки. [24] П0ддержка документирования происходит на странице D0cumentati0n главного окна.

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

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

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

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

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

Заключение

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

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

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

Список использованной литературы

Автоматизация проектирования вычислительных систем. Языки, моделирование и базы данных / ред. М. Брейер. - М.: Мир, 2014. - 463 c.
Воройский, Ф. С. Основы проектирования автоматизированных библиотечно-информационных систем / Ф.С. Воройский. - М.: ФИЗМАТЛИТ, 2012. - 384 c.
Гвоздева, В. А. Основы построения автоматизированных инф0рмаци0нных систем / В.А. Гвоздева, И.Ю. Лаврентьева. - М.: Форум, Инфра-М, 2016. - 320 c.
Герман-Галкин, С. Г. Matlab & Simulink. Проектирование мехатронных систем на ПК / С.Г. Герман-Галкин. - М.: Корона-Век, 2014. - 368 c.
Жуков, К. Г. Модельное проектирование встраиваемых систем в LabVIEW (+ DVD-ROM) / К.Г. Жуков. - М.: ДМК Пресс, 2011. - 688 c.
Зегжда, Д.П. Основы безопасности информационных систем / Д.П. Зегжда, А.М. Ивашко. - М.: Горячая линия - Телеком, 2013. - 452 c.
Ипат0ва, Э. Р. Мет0д0л0гии и техн0л0гии системн0г0 пр0ектир0вания инф0рмаци0нных систем / Э.Р. Ипат0ва, Ю.В. Ипат0в. - М.: Флинта, 2013. - 256 c.
Мидоу, Ч. Анализ информационных систем / Ч. Мидоу. - М.: Прогресс, 2011. - 400 c.
Паттерсон, Д. Архитектура компьютера и проектирование компьютерных систем / Д. Паттерсон, Дж. Хеннесси. - М.: Питер, 2012. - 784 c.
Раскин Интерфейс: новые направления в проектировании компьютерных систем: моногр. / Раскин, Джеф. - М.: Символ-плюс, 2014. - 272 c.
Рафикузаман, М. Микропроцессоры и машинное проектирование микр0пр0цесс0рных систем (комплект из 2 книг) / М. Рафикузаман. - М.: Мир, 2013. - 600 c.
Слепцов, А.И. Автоматизация проектирования управляющих систем гибких автоматизированных производств / А.И. Слепцов, А.А. Юрасов. - М.: Технiка, 2015. - 110 c.
Соловьев, В. В. Логическое проектирование цифровых систем на основе программируемых логических интегральных схем: моногр. / В.В. Соловьев, А. Климович. - М.: Горячая линия - Телеком, 2016. - 376 c.
Филиппов, В. А. Многомерные СУБД при создании корпоративных информационных систем / В.А. Филиппов. - М.: Едиториал УРСС, 2014. - 465 c.
Шастова, Г. А. Выб0р и оптимизация структуры информационных систем / Г.А. Шастова, А.И. Коёкин. - М.: Энергия, 2015. - 256 c.
Шелухин, О. И. Моделирование информационных систем / О.И. Шелухин, А.М. Тенякшев, А.В. Осин. - М.: Радиотехника, 2011. - 368 c.
Шелухин, О. И. Моделирование информационных систем / О.И. Шелухин. - М.: Горячая линия - Телеком, 2011. - 536 c.
Шоу, А. Логическое проектирование операционных систем / А. Шоу. - М.: Мир, 2013. - 360 c.
Юркевич, Е. В. Введение в теорию информационных систем / Е.В. Юркевич. - М.: Группа ИДТ, 2013. - 272 c.
Ярочкин, В. Безопасность информационных систем: моногр. / В. Ярочкин. - М.: Ось-89, 2015. - 320 c.
Проектирование информационных систем: Методические указания к выполнению курсовой работы для студентов специальности 351400 «Прикладная информатика в экономике» / Сост. П.В. Минеев. Красноярск, КГТУ, 2004. 36 с.
Проектирование инф0рмаци0нных систем: учеб. пособие / П. В. Минеев ; Сиб. федер. ун-т, ХТИ – филиал СФУ. – Абакан: РИСектор ХТИ – филиала СФУ, 2012
CyberForum.ru – форум программистов и системных администраторов. [Электронный ресурс]. – Режим доступа: http://www.cyberforum.ru/
http://elar.urfu.ru/bitstream/10995/28812/1/978-5-91128-072-7_2014.pdf
https://studfiles.net/preview/4418090/page:10/