Студопедия

КАТЕГОРИИ:

АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Диаграмма классов (class diagram)




Содержание

 

Введение

Описание информационной системы

Диаграмма вариантов использования (Use-case diagram)

Диаграмма классов (class diagram)

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

Диаграмма размещения (deployment diagram)

Заключение

Список литературы

 

 

Введение

 

Данный курсовой проект представляет собой проектирование информационной системы «Бассейн» с помощью языка UML.

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования (OOA&D), которые появились в конце 80-х и начале 90-х годов.

Первое упоминание об унифицированном методе (Unified Method) версии 0.8 появилось в 1995 году на конференции OOPSLA ’95. Данный метод был предложен Гради Бучом и Джимом Рамбо. В дальнейшем к ним присоединился Айвар Якобсон и в течение 1996 года Г. Буч, Д. Рамбо, А. Якобсон, получившие широкую известность как «трое друзей» (amigos) продолжали работу над своим методом, который к тому времени получил название унифицированный язык моделирования (UML). Однако помимо данного метода сообществом разработчиком были предложены и другие методы. Для стандартизации этих методов в рамках OMG (Object Management Group) была сформирована инициативная группа. В результате работы группы появилась версия языка UML 1.1. Текущей версией языка UML является версия 1.5, также ведется работа над спецификацией языка UML версии 2.0.

UML включает в себя двенадцать типов диаграмм, разделенных на три категории:

1. Диаграммы, описывающие статическую структуру системы.

ü Диаграмма классов (Class Diagram)

ü Диаграмма объектов (Object Diagram)

ü Диаграмма компонентов (Component Diagram)

ü Диаграмма развертывания (Deployment Diagram)

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

ü Диаграмма вариантов использования (Use Case Diagram)

ü Диаграмма видов деятельности (Activity Diagram)

ü Диаграмма последовательности (Sequence Diagram)

ü Диаграмма кооперации (Collaboration Diagram)

ü Диаграмма состояния (Statechart Diagram)

3. Диаграммы управления моделью включая Пакеты, Подсистемы и Модели

 

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

 

Описание информационной системы.

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

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

 

Описание:

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

 Бассейн сотрудничает с поставщиками оборудования, в том числе и международными. Имеется свой штат сотрудников: директор, бухгалтер, сотрудники отдела кадров, администраторы ,гардеробщики ,уборщики, медсестра, инструкторы и др. Занимается приемом на работу отдел кадров. 

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

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

 

 

Диаграмма вариантов использования (Use-case diagram)

 

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

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

· определить общие границы и контекст моделируемой предметной области;

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

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

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

 

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

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

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

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

 

 

Диаграмма Use-Case “Бассейн”

Диаграмма классов (class diagram)

 

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

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

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

 

Диаграмма классов “ Бассейн”

 










Последнее изменение этой страницы: 2018-04-12; просмотров: 327.

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