Автор работы: Пользователь скрыл имя, 03 Июля 2015 в 14:47, курсовая работа
Целью данной курсовой работы является создание автоматизированной информационной системы, способной автоматизировать большую часть деятельности складского учета.
Данная система предоставит возможность работникам:
Получение заявок от потребителей;
Оформление заказа на отправку;
Отправка груза потребителю.
Деятельность выполняется, только тогда, когда готовы все его «входы», после выполнения, деятельность передает управление и(или) данные на свои «выходы». Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали слева направо или сверху вниз.
Чтобы указать, где именно находится процесс, используется абстрактная точка «маркер» (или «токен»).
Переход маркера осуществляется между узлами. Маркер может не содержать никакой дополнительной информации (пустой маркер) и тогда он называется маркером управления (control flow token) или же может содержать ссылку на объект или структуру данных, и тогда маркер называется маркером данных (data flow token).
Для создания диаграммы деятельности используются следующие узлы:
|
|
|
|
Для отображения расширений сценария на диаграмме деятельности используются, так называемые узлы решения. Узел решения предназначен для определения правила ветвления и различных вариантов дальнейшего развития сценария.
Диаграммы деятельности для информационной системы работника почты выглядят следующим образом:
Рисунок 4.1 – Диаграмма деятельности «Оформление заказа»
Рисунок 4.2 – Диаграмма деятельности «Отправка посылки»
Рисунок 4.3 – Диаграмма деятельности «Отправка на склад»
Рисунок 4.4 – Диаграмма деятельности «Отправка на склад»
Состояние определяется совокупностью текущих значений атрибутов и связей объекта. Например, банк может иметь состояния платежеспособный и неплатежеспособный (когда большая часть банков одновременно оказывается во втором состоянии, наступает банковский кризис).
Состояние определяет реакцию объекта на поступающее в него событие (в том, что реакция различна нетрудно убедиться с помощью банковской карточки: в зависимости от состояния банка обслуживание (реакция банка на предъявление карточки) будет разным). Реакция объекта на событие может включать некоторое действие и/или перевод объекта в новое состояние.
Объект сохраняет свое состояние в течение времени между двумя последовательными событиями, которые он принимает: события представляют моменты времени, состояния - отрезки времени; состояние имеет продолжительность, которая обычно равна отрезку времени между двумя последовательными событиями, принимаемыми объектом, но иногда может быть больше.
При определении состояний мы не рассматриваем тех атрибутов, которые не влияют на поведение объекта, и объединяем в одно состояние все комбинации значений атрибутов и связей, которые дают одинаковые реакции на события.
Диаграммы состояний используются для описания поведения, реализуемого в рамках варианта использования, или поведения экземпляров класса (объектов), компонента, узла или системы в целом. Поведение моделируется через автомат (англ. state machine), описывающий возможные последовательности состояний экземпляра сущности и переходы между ними на протяжении его жизненного цикла, начиная от создания и заканчивая уничтожением.
Диаграмма состояний (автомат) представляет собой связный ориентированный граф, вершинами которого являются состояния, а дуги служат для обозначения переходов из состояния в состояние.
Под состоянием (англ. state) понимается ситуация в ходе жизни экземпляра сущности, когда эта ситуация удовлетворяет некоторому условию, экземпляр выполняет некоторые операции или ждет наступления некоторого события. Например, для объекта его состояние может быть задано в виде набора конкретных значений атрибутов, при этом изменение этих значений будет отражать изменение состояния моделируемого объекта.
В UML различают два вида операций: действие и деятельность. Действие (англ. action) – это атомарная операция, выполнение которой не может быть прервано, приводящая к смене состояния или возвращающая значение. Примерами действий служат операции создания или уничтожения объекта, расчет факториала и т. д. Деятельность (англ. activity) – это составная (неатомарная) операция, реализуемая экземпляром в конкретном состоянии, выполнение которой может быть прервано. В частности, под деятельностью можно понимать процедуры расчета допускаемых скоростей или шифрования данных.
Событие (англ. event) – это спецификация существенного факта, который занимает некоторое положение во времени и в пространстве. В контексте диаграмм состояний событие – это спецификация факта, который может привести к смене состояния. События могут быть внутренними или внешними. Внешние события передаются между системой и актерами (например, нажатие кнопки или посылка сигнала от датчика передвижений).
Внутренние события передаются между объектами внутри системы. В UML можно моделировать четыре вида событий:
· сигналы;
· вызовы;
· истечение промежутка времени;
· изменение состояния.
Сигнал (англ. signal) – спецификация факта посылки асинхронного сообщения между объектами. Исключения, которые поддерживаются в большинстве современных языков программирования, являются наиболее распространенным видом внутренних сигналов.
Вызов (англ. call) – спецификация факта посылки синхронного сообщения между объектами, предписывающего выполнение операции (действия или деятельности) объектом, которому посылается сообщение. Синхронность означает, что после посылки вызова объект-отправитель передает управление объекту-получателю и после выполнения последним операции получает управление обратно. Например, закрасить фигуру красным фоном fill(red) или рассчитать допускаемые скорости calculateVdop().
Событие времени – спецификация факта, обозначающего истечение промежутка времени с момента входа в текущее состояние. В UML данный факт специфицируется с помощью ключевого слова «after» (англ. – после). Например, after(2 seconds).
Событие изменения состояния – спецификация логического (булевского) условия. В контексте диаграмм состояний данное событие приводит к изменению состояния экземпляра сущности. В UML оно специфицируется с помощью ключевого слова «when» (англ. – когда) или сторожевого условия. Например, when(A < B) или [A < B].
Переход (англ. transition) – отношение между двумя состояниями, показывающее возможный путь изменения состояния экземпляра сущности.
Состояние отображается в виде прямоугольника со скругленными углами, внутри которого записывается имя (рис. 13.1). Рекомендуется в качестве имени использовать глаголы в настоящем времени (звенит, печатает, ожидает) или причастия (занято, передано, получено).
Диаграммы состояний для информационной системы работника почты выглядят следующим образом:
Рисунок 5.1 – Диаграмма состояний «Клиент»
Рисунок 5.2 – Диаграмма состояний «Работник»
Рисунок 5.3 – Диаграмма состояний «Заказ»
Компонент (component) — физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
Компонент предназначен для представления физической организации ассоциированных с ним элементов модели. Дополнительно компонент может иметь текстовый стереотип и помеченные значения, а некоторые компоненты – собственное графическое представление. Компонентом может быть исполняемый код отдельного модуля, командные файлы или файлы, содержащие интерпретируемые сценарии.
Компонент служит для общего обозначения элементов физического представления модели и может реализовывать некоторый набор интерфейсов. Для графического представления компонента используется специальный символ – прямоугольник со вставленными слева двумя более мелкими прямоугольниками. Внутри объемлющего прямоугольника записывается имя компонента и, возможно, дополнительная информация. Этот символ является базовым обозначением компонента в языке UML.
Графическое изображение компонента ведет свое происхождение от обозначения модуля программы, применявшегося некоторое время для отображения особенностей инкапсуляции данных и процедур.
Модуль (module) — часть программной системы, требующая памяти для своего хранения и процессора для исполнения.
В этом случае верхний маленький прямоугольник концептуально ассоциировался с данными, которые реализует этот компонент (иногда он изображается в форме овала). Нижний маленький прямоугольник ассоциировался с операциями или методами, реализуемыми компонентом. В простых случаях имена данных и методов записывались явно в маленьких прямоугольниках, однако в языке UML они не указываются.
Имя компонента подчиняется общим правилам именования элементов модели в языке UML и может состоять из любого числа букв, цифр и знаков препинания. Отдельный компонент может быть представлен на уровне типа или экземпляра. И хотя его графическое изображение в обоих случаях одинаково, правила записи имени компонента несколько отличаются.
Если компонент представляется на уровне типа, то записывается только имя типа с заглавной буквы в форме: <Имя типа>. Если же компонент представляется на уровне экземпляра, то его имя записывается в форме: <имя компонента ‘:’ Имя типа>. При этом вся строка имени подчеркивается. Так, в первом случае (часть а на рисунке) для компонента уровня типов указывается имя типа, а во втором (часть б) для компонента уровня экземпляра – собственное имя компонента и имя типа.
Правила именования объектов в языке UML требуют подчеркивания имени отдельных экземпляров, но применительно к компонентам подчеркивание их имени часто опускают. В этом случае запись имени компонента со строчной буквы характеризует компонент уровня примеров.
В качестве собственных имен компонентов принято использовать имена исполняемых файлов, динамических библиотек, Web-страниц, текстовых файлов или файлов справки, файлов баз данных или файлов с исходными текстами программ, файлов сценариев и другие.
В отдельных случаях к простому имени компонента может быть добавлена информация об имени объемлющего пакета и о конкретной версии реализации данного компонента. Необходимо заметить, что в этом случае номер версии записывается как помеченное значение в фигурных скобках. В других случаях символ компонента может быть разделен на секции, чтобы явно указать имена реализованных в нем классов или интерфейсов. Такое обозначение компонента называется расширенным.
Диаграмма компонентов для выбранной информационной системы выглядят следующим образом:
Рисунок 6 – Диаграмма компонентов
Диаграмма развертывания (deployment diagram) - диаграмма, на которой представлены узлы выполнения программных компонентов реального времени, а также процессов и объектов.
Диаграмма развертывания применяется для представления общей конфигурации и топологии распределенной программной системы и содержит изображение размещения компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений - маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы.