Содержание:

Введение

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

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

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

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

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

Цели моделирования:

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

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

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

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

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

Объектом проекта является моделирование информационных систем а также язык моделирования UML.

Предметом курсового проекта является UML-модель.

Целью данного курсового проекта является создание UML-модели прихода и обслуживания посетителей в ресторане.

Задачи проекта:

 Построить диаграмму использования;

 Построить диаграмму последовательности.

графический мультипликативный распределение класс

Глава 1. Теоретическая часть

1.1 Общая характеристика языка UML

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

Краткая история UML

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

По запросу Object Management Group (OMG) - организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов - Г. Бучем, Д. Рамбо и А. Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта. [9]- это язык

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели. [6]

Следует подчеркнуть, что UML - это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях. [10]

Словарь UML

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

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

Ассоциация - это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе - с одной стороны, или для нахождения всех заказов в которых есть данный товар, - с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование - отношение вида «целое» - «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого. [12]

Обобщение - это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью. [7]

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

Диаграммы. В UML предусмотрены следующие диаграммы:

. Диаграммы, описывающие поведение системы:

 Диаграммы состояний (State diagrams),

 Диаграммы деятельностей (Activity diagrams),

 Диаграммы объектов (Object diagrams),

 Диаграммы последовательностей (Sequence diagrams),

 Диаграммы взаимодействия (Collaboration diagrams);

. Диаграммы, описывающие физическую реализацию системы:

 Диаграммы компонент (Component diagrams);

 Диаграммы развертывания (Deployment diagrams).

 Представление управления моделью. Пакеты.

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

Что обеспечивает UML:

 иерархическое описание сложной системы путем выделения пакетов;

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

 детализацию требований к системе путем построения диаграмм деятельностей и сценариев;

 выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;

 выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;

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

 описание поведения объектов в виде диаграмм деятельностей и состояний;

 описание программных компонент и их взаимодействия через интерфейсы;

 описание физической архитектуры системы. [4]

1.2 Моделирование случайной величины с заданным законом распределения

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

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

Определение. Случайная величина Х называется дискретной, если она может принимать дискретное множество значений х1, х2, …, хn.

Формально случайная дискретная величина Х определяется таблицей

(1)

где х₁, х₂, …, х_n - возможные значения величины Х;

р₁, р₂, …, р_n - соответствующие вероятности.

Точнее говоря, вероятность P{X=хi} того, что случайная величина Х примет значение хi, равна:

P{ X= хi } = рi . (2)

Числа х1, х2, …, хn могут быть вообще говоря, любыми. Однако вероятности р1, р2, …, рn должны удовлетворять двум условиям:

(3)

и (4)

Последнее условие означает, что Х обязана в каждом случае принять одно из значений х1, х2, …, хn.

Кроме распределения случайной величины, которая является исчерпывающей характеристикой, вводятся числовые характеристики, основными среди которых являются математическое ожидание и дисперсия. [11]

Получение случайных величин на ЭВМ

Сама постановка вопроса "получение случайных чисел на ЭВМ" иногда вызывает недоумение: ведь все, что делает компьютер, должно быть заранее запрограммировано; откуда же может появиться случайность?

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

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

Обычно различают три способа получения случайных величин:

 из заранее составленных таблиц случайных чисел;

 физические генераторы случайных чисел;

 с помощью формул (генераторов или датчиков) псевдослучайных чисел.

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

Числа, получаемые по какой-либо формуле и имитирующие значения случайной величины X, называются псевдослучайными числами. Под словом "имитирующие" подразумевается, что эти числа удовлетворяют ряду тестов так, как если бы они были значениями этой случайной величины.

Основой или «сырьем» для моделирования случайных величин с заданным законом распределения являются так называемые базовые случайные числа. [8]

Определение

Совокупность {Ri}, i=1,2, … независимых равномерно распределенных на отрезке [0,1] случайных величин называется последовательностью базовых случайных чисел.

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

В настоящее время почти все стандартные библиотечные программы вычисления равномерных случайных чисел основаны на конгруэнтных 1 методах, разработанных Лемером.

Основная формула мультипликативного конгруэнтного метода Лемера имеет вид:

+1 = aRi(mod m), (5)

где а и m - неотрицательные целые числа.

Согласно этому выражению, нужно взять случайное число Ri, умножить его на постоянный коэффициент а и взять модуль полученного числа по m (т.е. разделить на аRi и остаток считать как Ri+1). Поэтому для вычисления (или генерирования) последовательности Ri нам необходимы начальные значения R0, множитель а и модуль m. Выбираются а, R0 и m так, чтобы обеспечить максимальную длину (или, как говорят период) неповторяющейся последовательности Ri и минимальную корреляцию между генерируемыми числами. Базовые случайные числа позволяют генерировать новые случайные последовательности, подчиняющиеся любому закону распределения. [5]

Существует два основных пути преобразования базовых случайных чисел {Ri}, в случайные числа {yi}, распределенные по заданному закону распределения.

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

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

Пусть событие а имеет вероятность р(а), тогда процедура его моделирования с помощью равномерного распределения (0,1) чисел производится следующим образом:

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

 Проверка неравенства Xi≤p(a), устанавливается принадлежность X ε (0,p(a)]. Если неравенство выполнено, то событие а - наступило, в противном случае нет.

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

=(a1,a2,an)(p1,p2,pn)

а1, а2, … - дискретные величины р1, р2, … -вероятность дискретных величин

Разобьем (0,1) на n-интервалов, причем длины интервалов выберем равные вероятностям дискретных величин.

Моделирование сводится к следующему: для получения очередного значения Z, разрабатывается равное значение X_{i ,} при попадании этого числа в j-интервал значение Z=Z_i.

Все разнообразие методов получения случайных величин можно разделить на 2 группы: точные и приближенные методы. [1]

Пусть равномерно-распределенная величина в интервале [0;1] - X, получается из случайной величины Y с помощью неслучайной f-x=η(y), тогда очевидно следующее равенство: P(x<X, x+dx)=P(y<Y, y+dy). Выражая левую и правую часть через соответствующие плотности распределения получают:

=f(y)*dy =>

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

Найдем функцию η(y) совпадающую с интегральным законом: η(y)=F(y)

Для получения очередного значения y_i случайной величины Y рассмотренной в интервале (а,в), с законом распределения -f(y) соответствующему значению x_i, необходимо решить уравнение. .

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

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

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

Глава 2. Проектная часть

1. Диаграмма использования

Диаграммы использования были предложены Иваром Якобсоном в их нынешней графической форме еще в 1986 году. Диаграммы использования являются, безусловно, самым стабильным элементом UML - они не менялись уже двадцать лет с лишним, фактически, приняли законченную форму задолго до появления языка. Одновременно эти диаграммы имеют самую простую нотацию: всего два основных типа сущностей (действующие лица и варианты использования), а также 4 четыре типа отношений, устанавливаемых между ними:

 ассоциация между действующим лицом и вариантом использования;

 обобщение между действующими лицами;

 обобщение между вариантами использования;

 зависимости (различных типов) между вариантами использования. [2]

В данной диаграмме использования показано взаимодействие и функции всех сотрудников.

Актеры (действующие лица) диаграммы:

- «zav_sklad» (заведующий складом), который управляет вариантами использования:

- «oborot_mes» (оборот за месяц);

«reviziya» (ревизия);

«klad» (кладовщик), управляющий следующими вариантами использования:

- «get_tovar» (принять товар);

- «send_tovar» (отправить товар);

- «inventar» (инвентаризация).

Между вариантами использования и действующими лицами используется вязь коммуникации (communication). Направление стрелки позволяет понять, кто инициирует коммуникацию.

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

Рисунок 1 - Диаграмма использования.

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

Диаграммой прецедентов, или использования (use case diagram) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними.

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

Элементы диаграммы:

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

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

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

2. Создание диаграммы последовательности

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

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

В данной модели для создания диаграммы последовательности был использован вариант использования «get_tovar» (принять товар), взятый из предыдущей диаграммы прецедентов (рисунок 3.1).

Рисунок 2 - Диаграмма последовательности «get_tovar» (принять товар)

На данную диаграмму помещены следующие объекты:

- «klad» (кладовщик) - действующее лицо;

- «Add/Select Tovar Form» - содержит форму ввода или выбора товара;

«Add/Select Postav Form» - содержит форму ввода или выбора поставщика товара;

«Card Sklad_Uchet» - форма карты складского учета, которая создается после ввода всех данных и является итоговым документом;

«DataBase» - содержит информацию о поставщиках и товарах, на основании информации этого объекта формируется карта складского учета

Сообщения между объектами на диаграмме:

- «Open» - открыть форму;

- «Cancel» - отмена действия;

«Query to DataBase» - запрос к базе данных на выбор товара;

«Answer from DataBase» - наименование товара;

«Query to DataBase on generation Sklad_Uchet card» - запрос к базе данных на выбор поставщика и генерацию карты складского учета;

«Generate» - карта складского учета.

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

Выводы

1. На диаграмме последовательности «get_tovar» (принять товар), размещены пять объектов и девять сообщений между ними.

2. Каждый объект был соотнесен с классом, а сообщение с операцией.

3. Диаграмма классов

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

Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

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

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

Рис. 4 Диаграмма классов

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

4. Создание диаграммы состояний для классов

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

На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). Процессы, происходящие в тот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

Событие (event) - это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода.

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

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

В данном курсовом проекте диаграмма состояний создается для варианта использования «get_tovar» (принять товар). Она представлена на рисунке 6.1.

Рисунок 5 - Диаграмма состояний для варианта использования «get_tovar» (принять товар)

Выводы

На диаграмме состояний расположены следующие состояния:

- начальное состояние «Start»;

- конечное «exit» состояние;

«Initialization» (инициализация);

«SomeStop» (выполнение приостановлено);

«Cancel» (отменен);

«Get» (выполнен).

Для каждого из состояний созданы следующие действия:

- «StoreDate» (сохранить дату) на входе для состояния «Initialization» (инициализация);

- «Info Tovar» (собрать информацию о товаре и поставщиках);

«Add» (добавить к набору товаров);

«StoreData» (сохранить дату отмены) на выходе;

«Card Ucheta» (карта учета) - на выходе формируется складская карта учета.

Заключение

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

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

Работа состоит из 2 глав:

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

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

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

1. Ларман К. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. - 3-е изд. [Текст] / К. Ларман - М.: Вильямс, 2011. - 736 с.

2. Новиков Ф.А. Анализ и проектирование на UML. [Текст] / Ф.А. Новиков - СПб: СПбГУ ИТМО, 2010. - 448 с.

3. Шеннон Р. Имитационное моделирование систем - искусство и наука. [Текст] / Р. Шеннон - М.: Мир. 2010. - 210 с.

4. Образовательный сайт Exponenta.

5. Свободная интернет - энциклопедия.

6. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-е изд. [Текст] / Г. Буч - М.: Издательство Бином, СПб.: Невский диалект, 2012- 123 стр.

7. Рамбо Дж., Язык UML. Руководство пользователя. [Текст] / Дж. Рамбо, А. Джекобсон- М.: ДМК, 2012. - 621 с.

8. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. [Текст] / А.М. Вендров - М.: Финансы и статистика, 2012. - 65 с.

9. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. [Текст] / А.М. Вендров - М.: Финансы и статистика, 2012. - 234 с.

10. Влиссидес, Дж. Приемы объектно-ориентированного проектирования. [Текст] / Дж. Влиссидес - М.: ДМК, 2010. - 156 с.

11. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений. [Текст] / Х. Гома - М.: ДМК, 2012. - 438с.

12. Коберн А. Современные методы описания функциональных требований к системам. [Текст] / А. Коберн - М.: ЛОРИ, 2011. - 58с.

Коналлен, Д. Разработка Web-приложений с использованием UML: Пер. с англ. [Текст] / Д. Коналлен - М.: Вильямс, 2010. - 150 с.

13. Коуд, П., Норт Д., Мэйфилд М. Объектные модели. Стратегии, шаблоны и приложения. [Текст] / П. Коуд, Д. Норт, М, Мэйфилд- М.: Вильямс, 2013. - 376 с.

14. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2000.- 432 с., ил.

15. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000.- 581 с., ил.

16. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002.- 432 с., ил.

17. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с., ил.

18. Леоненков А. Самоучитель UML.- СПб.: БХВ-Петербург, 2001

Приложения:

Приложение А

Листинг кода приложения на языке С++

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## Module: DataBase%4557238F03A5; Task specification

//## Subsystem: dataBase%45571B6A0339

//## Source file: D:\RR2000\Rose 2000\C++\source\dataBase\DataBase.h

#ifndef DataBase_h

#define DataBase_h 1

//## begin module%4557238F03A5.additionalIncludes preserve=no

//## end module%4557238F03A5.additionalIncludes

//## begin module%4557238F03A5.includes preserve=yes

//## end module%4557238F03A5.includes

// Add/Select Tovar

#include "Form\AddSelect Tovar.h"

// Add/Select Postav

#include "Form\AddSelect Postav.h"

// Card Sklad_Uche

#include "Form\Card Sklad_Uche.h"

//## begin module%4557238F03A5.declarations preserve=no

//## end module%4557238F03A5.declarations

//## begin module%4557238F03A5.additionalDeclarations preserve=yes

//## end module%4557238F03A5.additionalDeclarations

//## begin DataBase%4553764E01EE.preface preserve=yes

//## end DataBase%4553764E01EE.preface

//## Class: DataBase%4553764E01EE

//## Category: DataBase%455718440037

//## Subsystem: dataBase%45571B6A0339

//## Persistence: Transient

//## Cardinality/Multiplicity: nDataBase

{//## begin DataBase%4553764E01EE.initialDeclarations preserve=yes

//## end DataBase%4553764E01EE.initialDeclarations:

//## Constructors (generated)();(const DataBase &right);

//## Destructor (generated)

~DataBase();

//## Other Operations (specified)

//## Operation: Query to DataBase%455376E8004B/Select Tovar Query_to_DataBase ();

//## Operation: Query to DataBase on generation Sklad_Uchet card%455376EF009BSklad_Uchet Query_to_DataBase_on_generation_Sklad_Uchet_card ();

//## Get and Set Operations for Associations (generated)

//## Association: DB-Card%45538D6F01DE

//## Role: DataBase::<the_Card_Sklad_Uchet>%45538D700027UnboundedSetByReference<Card_Sklad_Uchet> get_the_Card_Sklad_Uchet () const;set_the_Card_Sklad_Uchet (UnboundedSetByReference<Card_Sklad_Uchet> value);:

// Additional Protected Declarations

//## begin DataBase%4553764E01EE.protected preserve=yes

//## end DataBase%4553764E01EE.protected:

//## Get and Set Operations for Class Attributes (generated)

//## Attribute: IDCard%45538A53012FInteger get_IDCard () const;set_IDCard (Integer value);

//## Attribute: Tovar%45538A5F028BString get_Tovar () const;set_Tovar (String value);

// Additional Private Declarations

//## begin DataBase%4553764E01EE.private preserve=yes

//## end DataBase%4553764E01EE.private: //## implementation

// Data Members for Class Attributes

//## begin DataBase::IDCard%45538A53012F.attr preserve=no private: Integer {U}IDCard;

//## end DataBase::IDCard%45538A53012F.attr

//## begin DataBase::Tovar%45538A5F028B.attr preserve=no private: String {U}Tovar;

//## end DataBase::Tovar%45538A5F028B.attr

// Data Members for Associations

//## Association: DB-Card%45538D6F01DE

//## begin DataBase::<the_Card_Sklad_Uchet>%45538D700027.role preserve=no public: Card_Sklad_Uchet {0..n -> 1..nRHN}<Card_Sklad_Uchet> the_Card_Sklad_Uchet;

//## end DataBase::<the_Card_Sklad_Uchet>%45538D700027.role

// Additional Implementation Declarations

//## begin DataBase%4553764E01EE.implementation preserve=yes

//## end DataBase%4553764E01EE.implementation

};

//## begin DataBase%4553764E01EE.postscript preserve=yes

//## end DataBase%4553764E01EE.postscript

// Class DataBase

//## Get and Set Operations for Class Attributes (inline)const Integer DataBase::get_IDCard () const

{ //## begin DataBase::get_IDCard%45538A53012F.get preserve=noIDCard;

//## end DataBase::get_IDCard%45538A53012F.get

}void DataBase::set_IDCard (Integer value)

{ //## begin DataBase::set_IDCard%45538A53012F.set preserve=no= value;

//## end DataBase::set_IDCard%45538A53012F.set

}const String DataBase::get_Tovar () const

{

//## begin DataBase::get_Tovar%45538A5F028B.get preserve=noTovar;

//## end DataBase::get_Tovar%45538A5F028B.get

}void DataBase::set_Tovar (String value)

{ //## begin DataBase::set_Tovar%45538A5F028B.set preserve=no= value;

//## end DataBase::set_Tovar%45538A5F028B.set

}

//## Get and Set Operations for Associations (inline)const UnboundedSetByReference<Card_Sklad_Uchet>::get_the_Card_Sklad_Uchet () const

{ //## begin DataBase::get_the_Card_Sklad_Uchet%45538D700027.get preserve=nothe_Card_Sklad_Uchet;

//## end DataBase::get_the_Card_Sklad_Uchet%45538D700027.get

}void DataBase::set_the_Card_Sklad_Uchet

(UnboundedSetByReference<Card_Sklad_Uchet> value)

{ //## begin DataBase::set_the_Card_Sklad_Uchet%45538D700027.set preserve=no_Card_Sklad_Uchet = value;

//## end DataBase::set_the_Card_Sklad_Uchet%45538D700027.set

}

//## begin module%4557238F03A5.epilog preserve=yes

//## end module%4557238F03A5.epilog

#endif