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

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

Читайте также:
  1. Документация в СМК
  2. Инвестиционный проект структурно состоит из двух документов: предпроектная документация и проектная документация.
  3. КОНТРОЛЬ КАЧЕСТВА, СТАНДАРТЫ И НОРМАТИВНО-ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ
  4. Медико-социальная экспертиза при терапевтических заболеваниях: общие принципы, документация, виды временной нетрудоспособности.
  5. Нормативно-правовая документация
  6. Нормативно-техническая документация, разрабатываемая на основе Федеральных законов и также используемая в процессе управления БЖД
  7. Организация первичного наблюдения и документация. Инвентаризация имущества и обязательств. Учетные регистры и формы бухгалтерского учета
  8. ОСНАЩЕНИЕ ДИСПЕТЧЕРСКОГО ПУНКТА РЭС И ОПЕРАТИВНАЯ ДОКУМЕНТАЦИЯ ОДГ
  9. Основные формы, методы работы, документация, права и обязанности школьного социального педагога
  10. ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ ПО ПЕДАГОГИЧЕСКОЙ ПРАКТИКЕ
  11. ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ ПО ПРОИЗВОДСТВЕНННОЙ ПРАКТИКЕ

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


1 | 2 | 3 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)