Документация конструкторского бюро

1. РС отдела договоров – содержит в себе документацию работы с клиентами конструкторского бюро.

Заявка

ID_заявки	ID_клиента	ID_технического_задания	Дата подачи
1Зв	1Кл	1ТЗ	20.01.08
2Зв	2Кл	2ТЗ	30.01.08

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

ID_технического_задания	Вид технического задания	Дата подачи
1ТЗ	Документация	21.01.08
2ТЗ	Чертежи	02.02.08

Проектный договор

ID_договора	ID_клиента	ID_заявки	ID_специалиста по договорам	Сроки сдачи проекта
1Дог	1Кл	1Зв	1СпД	30.03.08
2Дог	2Кл	2Зв	2СпД	05.04.08

Клиенты (юридическое лицо)

ID_клиента	Название	Адрес	Телефон	Расчетный счет	№ лицензии
1Кл	ООО "Партнерство"	г.Днепропетровск, ул.Набережная Победы44,3	182-73-45	КЛ5678Д433	РНК6773094
2Кл	ООО"Сидоров"	г.Днепропетровск, Литейная…	348-58-25	РП678Л784	ППР6782435

2. РС отдела снабжения - содержит документацию о поставке и использовании оборудования.

Инвентарь

ID_инвентаря	Название	Тип	ID_поставщика	Дата поставки	Кол-во	Срок службы
1Инв	Canon 4588	Ксерокс	1Пост	07.09.07	5	5 лет
2Инв	HP 6677	Принтер	2Пост	12.11.07	4	4 года

Поставщики

ID_поставщика	№ лицензии	Адрес	Телефон	Расчетный счет	Название
1Пост	КПР567749	ул. Комсомольская 14/24	567-08-09	РПИ5675323	"Принтлайф"
2Пост	РЛТ678222	ул. Конная 22, корпус 3, кв.25	764-75-34	ДО764Р5533	ООО "Партнерство"

Заявка на приобретение инвентаря

ID_заявки	ID_предприятия	ID_специалиста по обеспечению	ID_поставщика	ID_инвентаря	Кол-во	Дата подачи
1Зв	1Предп	1Сотр	1Пост	1Инв	7	20.01.08
2Зв	2Предп	2Сотр	2Пост	2Инв	8	24.01.08

3. РС конструкторского отдела - содержит в себе сопутствующую документацию, возникающую в ходе выполнения проектного задания.

Проект

ID_проекта	ID_клиента	ID_ведущего_специалиста
1Пр	1Кл	6Сотр
2Пр	2Кл	7Сотр

Остальные документы:

Список сотрудников

ID_сотрудника	№ паспорта	ФИО	Номер зарплатной карточки	Стаж	Размер з/п	Кол-во отпускных дней	Адрес	Телефон
9Сотр	МВ577685	Иванов Иван Иванович	ПРЕ347534	10 лет	2000 у.е	20	ул. Добрая 14/24	987-88-85
10Сотр	МВ4567889	Петров Кирилл Олегович	АПК3537355	4 года	1000 у.е	20	ул. Злая 14/24	567-34-67

Список отделов

ID_отдела	Название	ID_начальника	Телефон
1Отд	Отдел нефтяной промышленности	31Сотр	555-73-87
2Отд	Отдел энергомашиностроения	15Сотр	567-32-21

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

Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого - представить совокупность требований к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования представляет собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".

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

Актером будем называть внешнюю сущность, которая может взаимодействовать с системой. Актерами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актер – это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Например, в качестве актера «Бухгалтер» может выступать весь наличный штат бухгалтерии. В то же время один конкретный человек может играть несколько ролей по отношению к системе. Главный бухгалтер может выступать как актер с таким же именем, но может использовать систему так же, как актер «бухгалтер» (то есть, выполнять работу обычного бухгалтера).

При взаимодействии актера с системой, последняя выполняет ряд работ, которые образуют вариант использования системы (use case). Каждый актер может использовать систему по-разному, то есть инициировать выполнение разных вариантов использования. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе (которое может быть разбито на несколько более мелких). ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент.

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

• Отношение ассоциации (association relationship) - служит для обозначения специфической роли актера в отдельном варианте использования.

• Отношение расширения (extend relationship) - определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров.

• Отношение обобщения (generalization relationship) - служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В.

• Отношение включения (include relationship) - указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования

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

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