 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Документация конструкторского бюро
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 лет | |
| 2Инв | HP 6677 | Принтер | 2Пост | 12.11.07 | 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Инв | 20.01.08 | |
| 2Зв | 2Предп | 2Сотр | 2Пост | 2Инв | 24.01.08 |
3. РС конструкторского отдела - содержит в себе сопутствующую документацию, возникающую в ходе выполнения проектного задания.
Проект
| ID_проекта | ID_клиента | ID_ведущего_специалиста |
| 1Пр | 1Кл | 6Сотр |
| 2Пр | 2Кл | 7Сотр |
Остальные документы:
Список сотрудников
| ID_сотрудника | № паспорта | ФИО | Номер зарплатной карточки | Стаж | Размер з/п | Кол-во отпускных дней | Адрес | Телефон |
| 9Сотр | МВ577685 | Иванов Иван Иванович | ПРЕ347534 | 10 лет | 2000 у.е | ул. Добрая 14/24 | 987-88-85 | |
| 10Сотр | МВ4567889 | Петров Кирилл Олегович | АПК3537355 | 4 года | 1000 у.е | ул. Злая 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. Каждый пакет владеет всеми своими элементами, т. е. теми элементами, которые включены в него. Про соответствующие элементы пакета говорят, что они принадлежат пакету или входят в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие пакеты. В этом случае первые называются подпакетами, поскольку все элементы подпакета будут принадлежать более общему пакету. Тем самым для элементов модели задается отношение вложенности пакетов, которое представляет собой иерархию.
Поиск по сайту: