Файл: Разработка регламента выполнения процесса «Складской учет» (Оценка трудоемкости разработки).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 04.07.2023

Просмотров: 126

Скачиваний: 4

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

программный автоматизированный

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

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

На диаграмме изображены следующие действующие лица (актеры):

  1. поставщик;
  2. зав.складом;
  3. переупаковщик;
  4. грузчики;
  5. тмц;
  6. отдел инвентаризации;
  7. подразделение.

Диаграмма показывает процесс работы склада и передвижение (товарно-материальных ценностей). Весь процесс описывается следующим образом: Актер «Поставщик» поставляет товарно-материальную ценность актеру «Зав.складом», «Подразделение» отправляет заказ на товарно-материальную ценность актеру «Зав.складом», он поставляет товарно-материальную ценность на склад (принимает «Зав.складом»), «Зав.складом» отправляет товарно-материальную ценность на переупаковку актёру «Переупаковщик», но только в том случае если «Переупаковщик» получит «заявку на переупаковку», в противном случае «Зав.складом» отправляет заявку на размещения товарно-материальной ценности «Грузчикам 1-го отдела» которые, в свою очередь, непосредственно размещают товарно-материальную ценность. Далее товарно-материальную ценность перемещают в зону отгрузки, там ее принимают «Грузчики 2-го отдела», и если «Зав.складом» отправляет им заявку от подразделения (заказчика), они привозят и отгружают товар «Подраздлению». Так же «Отдел инвентаризации» может провести инвентаризацию товарно-материальной ценности, но только в том случае если получит соответствующую заявку.

Диаграммы логического представления

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


Логическое представление содержит:

  1. диаграмма использования (рисунок 1);
  2. диаграмму классов (рисунок 2);
  3. диаграммы последовательности и кооперации (рисунок 3, 4);
  4. диаграммы состояний (рисунок 5);
  5. Диаграммы деятельности и компонентов (рисунок 6,7);
  6. Диаграмма развертывания (рисунок 8).

На этой диаграмме показано взаимодействие классов, как и куда происходит перемещение и его учет.

Для лучшей наглядности были созданы следующие классы:

  1. «Подразделение» (подразделение выполняет функцию клиента который заказывает у склада необходимое количество с помощью класса «АИС» (собственно «АИС» – это и есть олицетворение нашей разрабатываемой системы).

В него были включены следующие атрибуты: «Код подразделения» (для того чтобы сотрудники склада ориентировались кому и куда отправлять), «номер» (это номер который требуется заказать у сотрудников склада) и собственно «Телефон» (номер для обратной связи).

Диаграмма классов

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

Диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. [Приложение 1]

Базовыми отношениями между классами в языке UML являются:

  • Отношение зависимости;
  • Отчет – Admin, Пользователь, Товары, Склады
  • База Данных – Admin, Пользователь, Товары, Склады
  • Отношение ассоциации;
  • Admin – Товары, Admin – Склады, Пользователь – Товары, Пользователь – Склады, Товары – Склады
  • Отношение обобщения;
  • Form – Отчет, Авторизация, MainForm, База Данных, Admin, Товары, Склады, Пользователь
  • Отношение реализации.

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

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

События, инициируемые при входе в программу с правами пользователя.

События, инициируемые при входе в программу с правами пользователя. [Приложение 1]

Диаграмма кооперации

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


Диаграммы состояний

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

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

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

Диаграмма характеризует различия в управлении функциональными возможностями складов и магазинов в программе. [Приложение 1]

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

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

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

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

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

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

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

  1. визуализации общей структуры исходного кода программной системы;
  2. спецификации исполняемого варианта программной системы;
  3. обеспечения многократного использования отдельных фрагментов программного кода;
  4. представления концептуальной и физической схем баз данных.

Диаграмма развертывания

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


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

Представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками.

Эта диаграмма завершает процесс ООАП для конкретной программной системы. [Приложение 1]

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

  1. определить распределение компонентов системы по ее физическим узлам;
  2. показать физические связи между всеми узлами реализации системы на этапе ее исполнения;
  3. выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности.

Спроектированная диаграмма говорит о том, что программное обеспечение устанавливает на компьютеры подразделения и на компьютеры склада, а связь с «Облаком»(где хранится БД) и связь между подразделением и складом осущестляется по Локальной/Глобальной сети.

2.1 Моделирование бизнес-процессов

Программа "Учет+" написана на языке Bor1and De1phi 7.0.

В состав проекта "Учет + " входит:

  1. главный файл проекта FirmU.dpr;
  2. 1 модуль с расширением.pas, содержащие процедуры и функции;
  3. 1 файл форма с расширением.dfm,, являющиеся графическим представлением приложения;
  4. файлы с расширением.dcu – скомпилированные модули;
  5. 8 файлов с расширением.dat- содержащие данные:
      • Shops.dat – содержит наименования магазинов;
      • Storages.dat – содержит наименование складов;
      • На Автозаводе. dat – содержит ассортимент данного объекта;
      • На Гая,100. dat – содержит ассортимент данного объекта;
      • На Речпорте. dat – содержит ассортимент данного объекта;
      • На Нариманова,8.dat – содержит ассортимент данного объекта;
      • На Ульяновском,30. dat – содержит ассортимент данного объекта;
      • На Центральном Рынке. dat – - содержит ассортимент данного объекта.
  6. файл Firm.exe – исполняемый файл проекта.

Проект вызывается запуском файла Firm.exe.

Описание главной формы проекта

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

Эта форма является стартовой для всех ролей. На форме расположены элементы управления:

1) Слева расположена панель кнопок.

2) Окно авторизации.

3) Рабочая область.

4) Информация о компании.


Оценки уровня ошибок

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

В данном программном продукте системные ошибки не проверяются.

Оценка качественных характеристик

Характеристики качества:

Мера

Оценка

Надежность

Доступность-готовность

Относительное время работоспособного функционирования

Вероятность

0,99

Эффективность

Временная эффективность

Время отклика – получение результатов на типовое задание

Пропускная способность – число типовых заданий, исполняемых в единицу времени

Секунды

Число в секунду

1

1

Используемость ресурсов

Относительная величина использования ресурсов ЭВМ при нормальном функционировании программного средства

Вероятность

0,2

Практичность

Понятность

Четкость концепции ПС

Демонстрационные возможности

Наглядность и полнота документации

Порядковая

Хорошая

Отличные

Отличная

Простота использования

Простота управления функциями

Комфортность эксплуатации

Среднее время ввода заданий

Среднее время отклика на задание

Порядковая

Порядковая

Секунды

Секунды

Отличная

Хорошая

1

1

Изучаемость

Трудоемкость изучения применения ПС

Продолжительность изучения

Объем эксплутационной документации

Объем электронных учебников

Чел.-часы

Часы

Страницы

Кбайт

1

4

57

0

Привлекательность

Субъективные или экспертные оценки

Порядковая

Хорошая

Сопровождаемость

Анализируемость

Стройность архитектуры программ

Унифицированность интерфейсов

Полнота и корректность документации

Порядковая

Хорошая

Хорошая

Отличная

Изменяемость

Трудоемкость подготовки изменений

Длительность подготовки изменений

Чел.-часы

Часы

3

3

Стабильность

Устойчивость к негативным проявлениям при изменениях

Порядковая

Хорошая

Тестируемость

Трудоемкость тестирования изменений

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

Чел.-часы

Часы

2

2

Мобильность

Адаптируемость

Трудоемкость адаптации

Длительность адаптации

Чел.-часы

Часы

2

1

Простота установки

Трудоемкость инсталляции

Длительность инсталляции

Чел.-часы

Часы

0,05

0,05-0,1

(3-5 минут)

Существование-соответствие

Стандартизация интерфейсов с аппаратной и операционной средой

Порядковая

Хорошая

Замещаемость

Трудоемкость замены компонентов

Длительность замены компонентов

Чел.-часы

Часы

2

2