Skip to content
WonderTruffle edited this page Jul 19, 2020 · 3 revisions

Лабораторная №2. Подготовка диаграмм DFD курсового проекта.

Примечание: освежите в памяти, что такое DFD (Data flow diagrams, или Диаграмма потоков данных)

  • Определение основных средств автоматизации

    • Определение конфигурации технических средств (рабочие станции, серверы, другое оборудование)
    • Определение конфигурации программных средств (одноуровневые, многоуровневые, встроенные, распределенные)
    • Определение допустимых видов хранилищ и их размещения
    • Добавление текста в файл readme.md
  • Разработка диаграмм в RAMUS

    • Декомпозиция всех автоматизируемых блоков в DFD
    • Определение типа каждого блока в DFD (экранная форма, печатная форма, модуль обработки)
    • Определение типа каждого хранилища в DFD (файл, таблица БД, структура в памяти, внешний сервис)
    • Открытие проекта в веб-браузере, получение и сохранение модели в развернутом виде
    • Загрузка модели в репозиторий личного проекта
    • Добавление ссылок в файл readme.md

Примечание: Более подробно разберем каждый из пунктов, начиная с верхушки списка.

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

Определение конфигурации технических средств. Конфигурация = взаимосвязанные функциональные и физические характеристики продукции, в применении к техническим средствам информационной системы это перечень необходимых (допустимых, планируемых) средств вычислительной техники, обеспечивающих при полном развертывании будущей системы запуск на них всех необходимых программных компонентов. Говоря простыми словами, это архитектура будущей системы. То, как система будет выглядеть в конечном счете, из каких компонентов будет состоять, и каким образом эти компоненты будут взаимодействовать между собой. Главное, описывая компоненты, указать, входные/выходные потоки. Компоненты(хранилища) выступают обработчиком потока. По сути, рабочие станции - те же стационарные ПК, ноуты. Сервера - то место, где лежит ваше приложение, БД, какой-то скоуп данных. Под другим оборудованием понимается то оборудывание, с которых необходимо передавать потоки данных. Например, у вас есть какие-то счетчики, с которых нужно передавать данные в систему потоком для их обработки.

Определение конфигурации программных средств. Подготавливая ответ на этот пункт, вы должны четко понимать, из каких программных средств ваша система состоит.

  • Под одноуровневыми программными средствами понимается ПО, которое изолировано от других средств и не взаимодействует(интегрируется), с ними. Пример - SPA (single page application или, в простонародье, "одностраничник").
  • Стандартный пример многоуровневого ПО - клиент-серверное приложение.
  • Пример встроенных программных средств - операционные системы, на которых работают ваши устройства, компьютеры, телефоны и тд. То, что установлено по дефолту, надсистема, примеры можно посмотреть во втором семинаре
  • Распределенные системы. Возможно, ваша работа связана с Газопроводами, Электросетями или другими распределенными системами. Хорошая статья здесь

Определение допустимых видов хранилищ и их размещения. Довольно простой, но в то же время сложный кейс.

  • Необходимо определиться, в каком виде в системе будут храниться данные. Простой пример - реляционная БД(SQL - Oracle, MySQL, PostgreSQL и др.) или нереляционные(NoSQL - MongoDB, Cassandra и др.). Постарайтесь ответственно подойти к выбору хранилища, вспомните про APDEX - индекс производительности приложений. Также посоветую прочитать статью с habr'a, в которой в общем виде изложены +/- использования SQL/NoSQL БД.
  • Говоря о размещении, важно помнить про масштабирование системы. Если ваша система довольно сложная, то советую использовать несколько БД + несколько серверов, где будете разворачивать свои БД. На тот случай, если допустим, нужен бэкап.

Добавление текста в файл readme.md.Думаю, что с этим пунктом проблем не возникает =)

Декомпозиция всех автоматизируемых блоков в DFD. Декомпозиция - разбиение на уровни. То есть, если понимаете, что внутри какого-то обработчика с входным потоком информации происходят операции, которые не отобразать на текущем уровне, и существуют вложенные обработчики потоков, значит необходима декомпозиция и большая детализация работы с потоком. Отличный пример. Хранилище - Система Управления Ремонтами оборудования. Мы понимаем, что обработчик информационных потоков, прежде чем выдать обработанные потоки, работает с ними у себя "под капотом", следовательно, данное хранилище является верхнеуровневым для других и его необходимо декомпозировать до тех пор, пока не будет найден конечный обработчик информационных потоков.

Определение типа каждого блока в DFD (экранная форма, печатная форма, модуль обработки). Тут комментарии излишни, необходимо постараться логически выстроить каждый блок и понимать, к какому типу он принадлежит.

Определение типа каждого хранилища в DFD (файл, таблица БД, структура в памяти, внешний сервис). Здесь аналогично пункту выше, понимать, в каком виде(формате, разрешении) приходят данные, в зависимости от этого выбирать, какой тип хранилища подойдет для данных.

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

Загрузка модели в репозиторий личного проекта. Закинуть в репозиторий на гитхабе файл проекта, импортированного из RAMUS.

Добавление ссылок в вики-страницу курсового проекта. Сложностей быть не может.

Clone this wiki locally