Главная              Рефераты - Разное

работа - реферат

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Государственное образовательное учреждение высшего профессионального образования

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ»

КУРСОВАЯ РАБОТА
ЗАЩИЩЕНА С ОЦЕНКОЙ

РУКОВОДИТЕЛЬ

Пятлина Е.О.

должность, уч. степень, звание

подпись, дата

инициалы, фамилия

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К КУРСОВОЙ РАБОТЕ

Проектирование информационной системы

«Бассейн»

по дисциплине: Технология программирования

РАБОТУ ВЫПОЛНИЛ

СТУДЕНТ ГР.

4944КС

Королёв А.С.

подпись, дата

инициалы, фамилия

Санкт-Петербург
2011г.

Содержание

Введение. 3

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

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

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

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

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

Заключение. 30

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

Введение

Данный курсовой проект представляет собой проектирование информационной системы «Бассейн» с помощью языка 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 “Бассейн”

Оценка качества диаграммы:

S – оценка диаграммы

SObj – оценка элементов диаграммы

Slink – оценка связей на диаграмме

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

ТObj – число типов объектов

Тlink – число типов связей

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

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

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

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

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

Оценка качества диаграммы

Scls – дополнительная оценка классов с атрибутами к общей формуле

Op – число операций класса

Atr – число атрибутов класса

(Администр-я бассейна) = 1,28

(Клиент) = 2,7

(Рекламное агенство) = 2

(Провайдер) = 2

(Поставщик) = 2

(Банк) = 2,25

(Арендодатель)=1,3

(Коммерч.орг-я)=1,3

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

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

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

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

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

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

  1. Заключение договора:

2. Получение зарплаты:

3. Расчёт зарплаты:

4.Прием на работу :

5. Обработка заказа абонемента:

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

Для каждого класса представлены диаграммы состояний и видов деятельности.

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

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

1. Клиент

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

2.Банк

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

3.Поставщик

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

4.Арендодатель

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

5.Рекламное агентство

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

6.Бассейн

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

7.Провайдер

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

8.Коммерческая организация

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

Диаграмма компонентов

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

Диаграмма компонентов (общий вид).

ё =

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

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "размещения", но термин "топология" точнее отражает сущность этого типа диаграмм.

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

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

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

При разработке диаграммы развертывания преследуют следующие цели:

· определить распределение компонентов системы по ее физическим узлам;

· показать физические связи между всеми узлами реализации системы на этапе ее исполнения;

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

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

Текст программы:

#include "Арендодатель.h"

//##ModelId=4F46355E0138

Арендодатель::Предоставление помещения()

{

}

//##ModelId=4F46356A00FA

Арендодатель::Заключение договора()

{

}

#ifndef АРЕНДОДАТЕЛЬ_H_HEADER_INCLUDED_B0B9977A

#define АРЕНДОДАТЕЛЬ_H_HEADER_INCLUDED_B0B9977A

//##ModelId=4F4635250196

class Арендодатель

{

public:

//##ModelId=4F46355E0138

Предоставление помещения();

//##ModelId=4F46356A00FA

Заключение договора();

private:

//##ModelId=4F4635470203

Название;

//##ModelId=4F46354B01B5

Реквизиты;

//##ModelId=4F4635500000

Адрес;

//##ModelId=4F4635550196

Телефон;

};

#endif /* АРЕНДОДАТЕЛЬ_H_HEADER_INCLUDED_B0B9977A */

#include "Банк.h"

//##ModelId=4D0E33C800DA

Банк::Перевод денег()

{

}

#ifndef БАНК_H_HEADER_INCLUDED_B0B9E4F5

#define БАНК_H_HEADER_INCLUDED_B0B9E4F5

//##ModelId=4D0E33A701C5

class Банк

{

public:

//##ModelId=4D0E33C800DA

Перевод денег();

private:

//##ModelId=4D0E33D000DA

Название;

//##ModelId=4D0E33D70399

Адрес;

//##ModelId=4D0E33DB008C

Телефон;

};

#endif /* БАНК_H_HEADER_INCLUDED_B0B9E4F5 */

#include "Клиент.h"

//##ModelId=4D0E32F101E4

Клиент::Оплата заказа()

{

}

#ifndef КЛИЕНТ_H_HEADER_INCLUDED_B0B9BB85

#define КЛИЕНТ_H_HEADER_INCLUDED_B0B9BB85

//##ModelId=4D0E32EA0196

class Клиент

{

public:

//##ModelId=4D0E32F101E4

Оплата заказа();

private:

//##ModelId=4D0E3303032C

Паспортные данные;

//##ModelId=4D0E330B0000

№ счёта;

};

#endif /* КЛИЕНТ_H_HEADER_INCLUDED_B0B9BB85 */

#include "Коммерческая организация.h"

//##ModelId=4F4634C20399

Коммерческая организация::Привлечение клиентов()

{

}

//##ModelId=4F4634E20242

Коммерческая организация::Заключение договоров()

{

}

#ifndef КОММЕРЧЕСКАЯ_ОРГАНИЗАЦИЯ_H_HEADER_INCLUDED_B0B9CEC2

#define КОММЕРЧЕСКАЯ_ОРГАНИЗАЦИЯ_H_HEADER_INCLUDED_B0B9CEC2

//##ModelId=4F46347D01F4

class Коммерческая организация

{

public:

//##ModelId=4F4634C20399

Привлечение клиентов();

//##ModelId=4F4634E20242

Заключение договоров();

private:

//##ModelId=4F4634A500BB

Название;

//##ModelId=4F46349E0399

Реквизиты;

//##ModelId=4F4634B4034B

Адрес;

//##ModelId=4F4634B9029F

Телефон;

};

#endif /* КОММЕРЧЕСКАЯ_ОРГАНИЗАЦИЯ_H_HEADER_INCLUDED_B0B9CEC2 */

#include "Бассейн.h"

//##ModelId=4D0E31830138

Администрация Бассейна::Принятие заказов()

{

}

//##ModelId=4D0E31AB005D

Администрация Бассейна::Заключение договоров()

{

}

//##ModelId=4D0E31B60280

Администрация Бассейна::Финансовые операции()

{

}

//##ModelId=4F4634580177

Администрация Бассейна::Управление операцией о персонале()

{

}

#ifndef Бассейн_H_HEADER_INCLUDED_B0B9DB86

#define Бассейн_H_HEADER_INCLUDED_B0B9DB86

//##ModelId=4D0E31750177

class Администрация Бассейна

{

public:

//##ModelId=4D0E31830138

Принятие заказов();

//##ModelId=4D0E31AB005D

Заключение договоров();

//##ModelId=4D0E31B60280

Финансовые операции();

//##ModelId=4F4634580177

Управление операцией о персонале();

private:

//##ModelId=4D0E31F6033C

Название;

//##ModelId=4D0E320001E4

Адрес;

//##ModelId=4D0E320403B9

Телефон;

};

#endif /* БАссейн_H_HEADER_INCLUDED_B0B9DB86 */

#include "Поставщик.h"

//##ModelId=4D0E335203C8

Поставщик::Предоставление услуг()

{

}

//##ModelId=4D0E338901E4

Поставщик::Стоимость услуг()

{

}

#ifndef ПОСТАВЩИК_H_HEADER_INCLUDED_B0B98BB3

#define ПОСТАВЩИК_H_HEADER_INCLUDED_B0B98BB3

//##ModelId=4D0E3347032C

class Поставщик

{

public:

//##ModelId=4D0E335203C8

Предоставление услуг();

//##ModelId=4D0E338901E4

Стоимость услуг();

private:

//##ModelId=4D0E339001D4

Название;

//##ModelId=4D0E339600CB

Адрес;

//##ModelId=4D0E339A0213

Телефон;

};

#endif /* ПОСТАВЩИК_H_HEADER_INCLUDED_B0B98BB3 */

#include "Провайдер.h"

//##ModelId=4D0E3324036B

Провайдер::Тарифы()

{

}

//##ModelId=4D0E332D00EA

Провайдер::Услуги()

{

}

#ifndef ПРОВАЙДЕР_H_HEADER_INCLUDED_B0B99BB0

#define ПРОВАЙДЕР_H_HEADER_INCLUDED_B0B99BB0

//##ModelId=4D0E331B02DE

class Провайдер

{

public:

//##ModelId=4D0E3324036B

Тарифы();

//##ModelId=4D0E332D00EA

Услуги();

private:

//##ModelId=4D0E33340128

Название;

//##ModelId=4D0E3338001F

Адрес;

//##ModelId=4D0E333A037A

Телефон;

};

#endif /* ПРОВАЙДЕР_H_HEADER_INCLUDED_B0B99BB0 */

#include "Рекламное агенство.h"

//##ModelId=4D0E33F40242

Рекламное агенство::Предоставление услуг()

{

}

//##ModelId=4D0E34A50271

Рекламное агенство::Заключение договора()

{

}

#ifndef РЕКЛАМНОЕ_АГЕНСТВО_H_HEADER_INCLUDED_B0B9DE8A

#define РЕКЛАМНОЕ_АГЕНСТВО_H_HEADER_INCLUDED_B0B9DE8A

//##ModelId=4D0E33E70261

class Рекламное агенство

{

public:

//##ModelId=4D0E33F40242

Предоставление услуг();

//##ModelId=4D0E34A50271

Заключение договора();

private:

//##ModelId=4D0E34AF0148

Название;

//##ModelId=4D0E34B300CB

Адрес;

//##ModelId=4D0E34B700AB

Телефон;

};

#endif /* РЕКЛАМНОЕ_АГЕНСТВО_H_HEADER_INCLUDED_B0B9DE8A */

Заключение

В результате всей работы была разработана автоматизированная система «Бассейн». В ходе ее разработки мы научились создавать диаграммы входящие в язык моделирования UML. Соответственно, изучили основы языка моделирования UML.

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

Все диаграммы в данной курсовой работе разработаны с помощью системы моделирования Rational Rose. Поэтому мы изучили CASE – инструментарий, в котором моделировали.

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

1. Иванова Г. С. «Технология программирования учебник» – 1998.

2. Коуд П., Норт Д.,Мейфилд М. «Объектные модели. Стратегии, шаблоны и приложения» – 1999.