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

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

Оглавление

• ВВЕДЕНИЕ
• 1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
• 2. Основные теоретические положения
• 2.1 Case-средства
• 2.2 Сравнение CASE-средств
• 2.3 Инструментальное средство BPwin
• 3. Разработка модели
• 3.1 Принцип построения модели IDEFO
• 3.2 Принцип построения модели DFD
• 3.3 Принцип построения модели IDEF3
• 4. Модель автосервиса.
• 4.1 Навигатор модели - Model Explorer
• 4.2 Диаграммы функциональной декомпозиции
• 4.2.1 Контекстная диаграмма
• 4.2.2 Диаграмма декомпозиции А0
• 4.2.3 Диаграмма декомпозиции А1
• 4.2.4 Диаграмма декомпозиции А2
• 4.3 Диаграммы потоков данных
• 4.3.1 Диаграмма потоков данных А12
• 4.4 Диаграммы IDEF3
• 4.4.1 Диаграмма А2
• 4.4.2 Диаграмма А23.1
• 4.4.3 Диаграмма А32.1
• 5. Математическая модель системы.
• Вывод по проделанной работе.
• ЛИТЕРАТУРА
• ВВЕДЕНИЕ
• В информационном обществе акцент значимости смещается на информационный ресурс, представляющий собой знания, накопленные людьми для социального использования в обществе.
• Для формализации этих знаний существует необходимость разрабатывать наиболее удобные средства для их представления.
• Для достижения эффективности разрабатываемых систем требуется поддержка гибкости и настраиваемости, которые позволят в случае изменения структуры управления безболезненно перестроиться в нужную конфигурацию. Корректировка системы может производиться с использованием модели, созданной в процессе проектирования. Это существенно упрощает внесение изменений, так как можно промоделировать различные сценарии. Стандартизация моделей повышает способность разбираться в диаграммах не только разработчикам, но и специалистам предметной области.
• Моделирование позволяет «увидеть» проект в процессе разработки и создать предпосылки для анализа поведения системы в зависимости от начальных условий.
• Основными целями моделирования при разработке проектов являются:
• · представление деятельности предприятия и принятых в нем
• технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;
• · формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;
• · упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;
• · выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром;
• · анализ требований и проектирование спецификаций корпоративных информационных систем.
• При моделировании изучается влияние и действие одних элементов на другие и последствия этих взаимодействий.

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

Целью деятельности Автосервиса является непосредственно диагностика и ремонт автомобилей.

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

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

2. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ

2.1 Case-средства

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

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

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

CASE-средства - эффективная поддержка мышления и развития логики. На базе чего возможности аналитиков значительно расширяются. С помощью CASE-средств возможно разработать информационную модель и на ее основе концепцию автоматизации предприятия.

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

Ш локальные, поддерживающие один-два типа моделей и методов;

Ш малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

Ш средние интегрированные средства моделирования, поддерживающие от 4 до 10--15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

Ш крупные интегрированные средства моделирования, поддерживающиеболее 15 типов моделей и методов (ARIS Toolset).

2.2 Сравнение CASE-средств

Чтобы выбрать наилучшее CASE-средство для построения своей модели я провел сравнительный анализ трех CASE-средств методом анализа иерархии (МАИ). К этим средствам относятся:

Ш BPWin

Ш ARIS Toolset

Ш Rational Rose

В список критериев, по которым я сравнил CASE-средства, попали:

· Количество поддерживаемых стандартов

· Удобство работы по созданию моделей

· Ограничение на количество объектов на диаграмме

Известные данные по каждому из средств я свел в таблицу

	BPWin	ARIS Toolset	RationalRose
1.Количество поддерживаемых стандартов	ь IDEF0 ь DFD ь IDEF3	ь Частично DFD ь ERM ь UML ь EPC	ь UML
2. Удобство работы по созданию моделей	Простая панель управления	Сложная панель управления	Относительно простая панель управления
3. Ограничение на количество объектов на диаграмме	2-8	Нет ограничения	Ограничения есть, но они не жесткие

1 шаг МАИ: Оценка критериев

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

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

	Количество поддерживаемых стандартов	Удобство работы по созданию моделей	Ограничение на количество объектов на диаграмме	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Удобство работы по созданию моделей	1	9	5	3,512	0,904
Количество поддерживаемых стандартов	1/9	1	1/7	0,254	0,065
Ограничение на количество объектов на диаграмме	1/5	7	1	1,117	0,288

Сначала определяем оценки компонент собственного вектора.

Для критерия «Удобство работы по созданию моделей»:

( 9 * 1 * 5) = 45^1/3 = 3,512

Так для критерия " Количество поддерживаемых стандартов" это будет:

(1* 1/9 * 1/7)^1/3 = (0.01573)^1/3 = 0,254

Для последнего критерия «Ограничение на количество объектов на диаграмме» :

(7 * 1/5 * 1)^1/3 = 1,117

Получив сумму оценок собственных векторов ( = 3,883), вычисляем нормализованные оценки вектора приоритета для каждого критерия, разделив значение оценки собственного вектора на эту сумму.

0,254 / 3,883= 0,065 (для критерия «Количество поддерживаемых стандартов»)

3,512 / 3,883= 0,904 (для критерия «Удобство работы по созданию моделей»)

1,117 / 3,883= 0,288 («Ограничение на количество объектов на диаграмме»)

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что наибольшее значение при выборе CASE-средства я придаю критерию "Удобство работы по созданию моделей ".

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

ИС = (л _max - n)/(n - 1)

л_max = (1+9+7)*0.065 + (1.9+1+1.5)*0,904 + (1/7+5+1)*0,288 = 3,06

ИС = (л_max - 3) / 2 = 0,03.

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

OC = 2,6 % < 10%, т.е. пересматривать свои суждения нет нужды.

2 шаг: Оценка альтернатив

Теперь для выбора наилучшего CASE-средства я сравню выбранные мною 3 CASE-средства по каждому критерию.

Критерий: «Количество поддерживаемых стандартов»

	BPWin	ARIS	RationalRose	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
BPWin	1	3	5	2,444	0,6
ARIS	1/3	1	7	1,318	0,323
Rational Rose	1/5	1/7	1	0,309	0,08

Оценки компонент собственного вектора:

BPWin: (1*3*5)^1/3 =2,444

ARIS: (1/3*1*7)^1/3 = 1,318

Rational Rose: (1/5*1/7*1)^1/3 = 0,309

Сумма оценок собственных векторов = 2,444+1,318+0,309 = 4,071

Вычислим нормализованные оценки:

BPWin: 2,444 / 4,071 = 0,6

ARIS: 1,318 / 4,071 = 0,323

Rational Rose: 0,309 / 4,071 = 0,08

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

Критерий «Удобство работы по созданию моделей»

	BPWin	ARIS	RationalRose	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
BPWin	1	9	5	3,512	0,809
ARIS	1/9	1	1/4	0,0275	0,006
Rational Rose	1/5	4	1	0,8	0,184

Оценки компонент собственного вектора:

BPWin: (1*9*5)^1/3 =3,512

ARIS: (1/9*1*1/4)^1/3 = 0,0275

Rational Rose: (1/5*4*1)^1/3 = 0,8

Сумма оценок собственных векторов = 2,444+1,318+0,309 = 4,3395

Вычислим нормализованные оценки:

BPWin: 3,512 / 4,3395 = 0,809

ARIS: 0,0275 / 4,3395 = 0,006

Rational Rose: 0,8 / 4,3395= 0,184

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

Критерий «Ограничение на количество объектов на диаграмме»

	BPWin	ARIS	Rational Rose	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
BPWin	1	1/7	1/5	0,309	0,063
ARIS	7	1	8	3,77	0,764
Rational Rose	5	1/8	1	0,856	0,173

Оценки компонент собственного вектора:

BPWin: (1*1/7*1/5)^1/3 =0,309

ARIS: (7*1*8)^1/3 = 3,77

Rational Rose: (5*1/8*1)^1/3 = 0,856

Сумма оценок собственных векторов = 0,309+3,77+0,856 = 4,935

Нормализованные оценки:

BPWin: 0,309 / 4,935 = 0,063

ARIS: 3,77 / 4,935 = 0,764

Rational Rose: 0,856 / 4,935 = 0,173

Сравнивая по критерию ограниченности объектов на диаграмме, видно, что ARIS является лидером, так как у него нет ограничений на количество объектов на диаграмме.

Однако наиболее важным для меня критерием является прежде всего удобство при создании модели, поэтому для построения своей модели я выбрал инструментальное CASE-средство BPWin.

2.3 Инструментальное средство BPwin

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

BPwin - это CASE-средство верхнего уровня, поддерживающее 3 методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

BPwin автоматизирует задачи, связанные с построением моделей развития, обеспечивая семантическую строгость, необходимую для гарантирования правильности и непротиворечивости результатов. Это достигается применением в BPwin следующих методологий: IDEF0, DFD и IDEF3.

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

В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А3.1, А3.2, АЗ.З, А3.4 и т. д.

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

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

3. Разработка модели

3.1 Принцип построения модели IDEFO

Основу методологии IDEFO составляет графический язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

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

Модель может содержать четыре типа диаграмм:

Ш контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

Ш диаграммы декомпозиции;

Ш диаграммы дерева узлов;

Ш диаграммы только для экспозиции (FEO).

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

Ш верхняя сторона имеет значение "управления";

Ш левая - "входа";

Ш правая - "выхода";

Ш нижняя - "механизма".

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

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

3.2 Принцип построения модели DFD

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

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

Ш внешние сущности;

Ш системы/подсистемы;

Ш процессы;

Ш накопители данных;

Ш потоки данных.

3.3 Принцип построения модели IDEF3

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

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

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

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

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous).

4. Модель автосервиса.

4.1 Навигатор модели - Model Explorer

Иерархия работ смешанной модели изображена в окне Model Explorer. (рисунок 3)

Рисунок 3. Окно Model Explorer

4.2 Диаграммы функциональной декомпозиции

4.2.1 Контекстная диаграмма

На контекстной диаграмме мы видим самое общее описание системы и ее взаимодействие с внешней средой (рисунок 4).



Рисунок 4. Контекстная диаграмма

4.2.2 Диаграмма декомпозиции А0

На данной диаграмме мы видим первый уровень декомпозиции нашей системы, а именно 3 основные функции и их взаимодействие друг с другом и с внешней средой (рисунок 5).



Рисунок 5. Диаграмма декомпозиции А0

4.2.3 Диаграмма декомпозиции А1

Первая функция «Принятие заявки» декомпозируется на 2 более мелкие функции (рисунок 6):

Ш Добавление заявки в Базу Данных

Ш Введение статистики



Рисунок 6. Диаграммма декомпозиции А1

4.2.4 Диаграмма декомпозиции А2

Вторая функция «Обслуживание автомобиля» декомпозируется на 3 более мелкие функции (рисунок 7):

Ш Диагностика автомобиля

Ш Замена масла

Ш Ремонт двигателя



Рисунок 7. Диаграмма декомпозиции А2

4.2.5 Диаграмма декомпозиции А3

Третья функция «Удаление заявки» декомпозируется на 2 более мелкие функции (рисунок 8):

Ш Удаление заявки из БД

Ш Отчет о работе



Рисунок 8. Диаграмма декомпозиции А3

4.3 Диаграммы потоков данных

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

4.3.1 Диаграмма потоков данных А12

Данная диаграмма описывает процесс «Введение статистики» (рисунок 9).



Рисунок 9. Диаграмма потоков данных А12

4.4 Диаграммы IDEF3

Диаграмма А2

Эта диаграмма описывает сценарий бизнес-процесса «Замена масла» (рисунок 11).



Рисунок 11. Диаграмма А2

4.4.1 Диаграмма А23.1

Эта диаграмма описывает сценарий бизнес-процесса «Ремонт двигателя» (рисунок 12)



Рисунок 12. Диаграмма А23.1

4.4.2 Диаграмма А32.1

Эта диаграмма описывает сценарий бизнес-процесса «Составление отчета о работе» (рисунок 13)



Рисунок 13. Диаграмма А32.1

5 Математическая модель системы

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

Реализация с помощью СМО (системы массового обслуживания).

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

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

Основными компонентами СМО любого вида являются:

1. Входной поток поступающих требований

2. Дисциплина очереди

3. Механизм обслуживания

В автомастерской имеется один пост диагностики, два механика по ремонту двигателя автомобиля и один механик по замене масла. В час в автомастерскую поступает 4 автомобиля. Каждый поступивший автомобиль проходит диагностику. Диагностика автомобиля длится 12 минут. После диагностики, 50% автомобилей направляется на ремонт двигателя, 48% - на замену масла, 2% - покидают автосервис. Ремонт двигателя длится 30 минут, замена масла - 20 минут. По окончанию ремонта автомобиль покидает автомастерскую. Максимальное число машин в очереди равно 3. Автомастерская работает 8 часов.

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

5.1 Реализация в среде AnyLogic

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

AnyLogic представляет собой инструмент имитационного моделирования, объединивший методы системной динамики, "процессного" дискретно-событийного и агентного моделирования в одном языке и одной среде разработки моделей.

Рисунок 14. Построение модели в AnyLogic

Запустив AnyLogic, можно наблюдать работу автосервиса.



Рисунок 15. Запуск модели

5.2 Реализация в среде Matlab

MATLAB (сокращение от англ. «Matrix Laboratory») -- термин, относящийся к пакету прикладных программ для решения задач технических вычислений, а также к используемому в этом пакете языку программирования.

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



Рисунок 16. Построение модели в Matlab

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



Рисунок 17. Длина очереди поста диагностики

Рисунок 18. Время ожидания поста диагностики

Решение:

Определение характеристик функционирования автосервиса.

· Исходные значения:

Число поступающих клиентов (интенсивность потока заявок): л=4 авт/час

Количество возможных обслуженных клиентов: n=5 авт/час

Количество окошек автомастерской (постов диагностики): S=1

· Время обслуживания:

· Интенсивность потока обслуживания:

· Относительная пропускная способность автомастерской:

· Абсолютная пропускная способность регистратуры:

· Финальная вероятность:

· Cреднее число автомобилей в очереди:

· Средняя продолжительность пребывания автомобиля в очереди:

Вывод по проделанной работе

информационная система математическая модель

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

В ходе рассмотрения модели, можно сделать вывод, что все пост диагностики загружен максимально, и количество машин в очереди равен 3 (рис. 17). Из это следует, что машины, пришедшие после получают отказ. Чтобы избежать этого и автомастерская работала более рационально, я советую ввести второй пост диагностики, с такой же пропускной способности.

Рисунок 19. Модель автосервиса после реинжиниринга.

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



Рисунок 20. Длина очереди поста диагностики после реинжиниринга.

Рисунок 21. Время ожидания поста диагностики после реинжиниринга.

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

ЛИТЕРАТУРА

1. Рогозов Ю. И., Стукотий Л. Н., Свиридов А. С. Моделирование систем, ТРТУ, 2004.

2. С. В. Маклаков CASE-средства разработки информационных систем. BPwin и Erwin -М.: ДиалогМифи, 2001.

3. Карпов, Ю. Г. Имитационное моделирование систем. Введение в моделирование с AnyLogic 5. -- СПб: БХВ-Петербург, 2006.

4. Материалы сайта www.citforum.ru - классификация CASE-средств и их общая характеристика.

5. Материалы сайта www.citycg.ru - методы описания бизнес-проектов

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