Диаграммы rose о автосервисе

Содержание

 

Введение………………………………………………………………………….3

1 Техническое задание………………………………………………………….4

2 Обзор и описание предметной области……………………………………..5

2.1Общая характеристика………………………………………………………5

2. Обоснование актуальности разработки объектно-ориентированной модели информационной подсистемы………………………………………………5
3. Формулировка задач проектирования………………………………………5

3 Моделирование программного обеспечения………………………………..7

3.1 Создание диаграммы прецедентов………………………………………...7

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

3.3 Создание диаграммы сотрудничества……………………………………10

3.4 Создание  диаграммы классов……………………………………………..12

3.5 Добавление деталей к описаниям операции и определение атрибутов классов. Добавление связей между классами………………………………..14

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

3.7 Создание  диаграммы размещения………………………………………..18

Заключение……………………………………………………………………..19

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

 

 

Введение

 

Важнейшими характеристиками любой системы являются ее структура и процесс функционирования. Под структурой системы понимают устойчивую во времени совокупность взаимосвязей между ее элементами или компонентами. Именно структура связывает воедино все элементы и препятствует распаду системы на отдельные компоненты. Структура системы может отражать самые различные взаимосвязи, в том числе и вложенность элементов одной системы в другую. В этом случае принято называть более мелкую или вложенную систему подсистемой. Процесс функционирования системы тесно связан с изменением ее свойств или поведения во времени. При этом важной характеристикой системы является ее состояние, под которым понимается совокупность свойств или признаков, которые в каждый момент времени отражают наиболее существенные особенности поведения системы. Общим свойством всех моделей является их подобие оригинальной системе или системе-оригиналу. Важность построения моделей заключается в возможности их использования для получения информации о свойствах или поведении системы-оригинала. При этом процесс построения и последующего применения моделей для получения информации о системе-оригинале получил название моделирование. Рассмотрение особенностей языка UML связано с вопросами логического или информационного моделирования систем. Общая модель системы содержит некоторую важную информацию о функциональных особенностях данной системы, которые дают представление о ее дальнейшем поведении. Целью курсового проекта является разработка объектно-ориентрованной модели информационной подсистемы "Автосервис" с использованием языка UML. Для построения информационной подсистемы была использована система моделирования Rational Rose 2006 Enterprise v.7

 

 

1 Техническое задание

 

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

 

 

2. Обзор и описание предметной области

2.1 Общая характеристика

 

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

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

2.2 Обоснование актуальности разработки объектно-ориентрованной модели информационной подсистемы

 

Для описания структуры подсистемы "Автосервис" используется язык UML (Unified Modeling Language). Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. Язык UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Некоторые особенности системы лучше всего моделировать в виде текста, другие – графически. На самом деле во всех интерфейсных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML – графический язык, это позволяет решить проблему визуализации. Язык UML предназначен, прежде всего, для разработки программных систем. Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы, осуществлять проектирование аппаратных средств.

2.3 Формулировка задач проектирования

 

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

Для построения информационной подсистемы была использована система  моделирования Rational Rose 2006.

Выводы

1. Задача разработки информационной подсистемы для учета заказов заключается в описании стандартными средствами языка UML всех происходящих в отделе процессов, связанных с занесением данных в БД и получением отчетности в информационной подсистеме "Автосервис".
2. Для разработки объектно-ориентированной модели требуемой подсистемы необходимо создать все базовые диаграммы языка UML.

 

 

3 Моделирование программного обеспечения

3.1 Создание диаграммы прецедентов

 

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

Вариант использования  представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой [1, 2]. Действующее лицо – это роль, которую пользователь играет по отношению к системе [1, 2]. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

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

Используя методы Rational Rose 2000, согласно заданию курсового проектирования, была создана диаграмма прецедентов (рисунок 2.1).

 

 

Рисунок 2.1 – Диаграмма прецедентов  "Автосервис"

 

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

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

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

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

Опишем более подробно диаграммe прецедентов (рисунок 2.1).

Действующие лица:

1. Клиент – может быть как физическим, так и юридическим лицом. Осуществляет заказ на ремонт или техническое обслуживание транспортного средства.
2. Менеджер – занимается оформлением заказа, вносит его в базу данных. Также менеджер, на основании заказа клиента, выдаёт задание мастеру-ремонтнику на техническое обслуживание транспортного средства.
3. Мастер-ремонтник – специалист, который занимается ремонтом и техническим обслуживание транспортного средства.
4. Транспортное средство – автомобиль или иное транспортное средство клиента, которое может быть на ремонте или техническом обслуживании.

Базовый вариант использования "Заказ"– этот вариант использования дает возможность зафиксировать в базе данных (БД) информационной подсистемы "Автосервис" все заявки клиентов.

Выводы

1. Изучена предметная область и создана диаграмма прецедентов.
2. Диаграмма прецедентов включает пять вариантов использования и четыре актера.
3. Базовым вариантом использования, наиболее важным для реализации системы, является вариант использования "Заказ".
4. С прецедентом "Заказ" взаимодействуют актеры "Клиент" и "Менеджер". Данные базового варианта использование используются актером "Мастер-ремонтник".

 

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

 

Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования [1 – 4]. Для варианта использования "Заказ клиента" создана диаграмма последовательности (рисунок 3.1).

Данный тип диаграмм позволяет  отразить последовательность передачи сообщений между объектами. Sequence diagram – это диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений [1, 2]. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени – вдоль оси Y.

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

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

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

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

В данной модели для создания диаграммы последовательности был  использован вариант использования "Заказ" взятый из предыдущей диаграммы прецедентов. Диаграмма последовательности для варианта использования "Заказ" приведена на рисунке 3.1.

 

Рисунок 3.1 – Диаграмма последовательности для варианта использования "Заказ"

 

Выводы

1. В рамках варианта  использования "Заказ" сформирован и изучен основной поток событий.

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

На диаграмме последовательностей  представлено действующее лицо "Менеджер" и восемь объектов: три формы, для создания удобного пользовательского интерфейса, а также пять классов и методы:

1. Form_Zakaz {Open_form(), Input_data(), Input_worker(), Input_kind_work() } – класс формы.
2. Form_klient {open_form()} – класс формы.
3. Form_Ysluga {Open_form()} – класс формы.
4. Work_BD{Save()} – класс записи введенной в БД информации.
5. Print_data {Print()} – класс печати.