Обзор публикаций с анализом предметной области (ранее использованные процессы, технологии, метод и т. д. ) и особенностей функционирования объекта. Указать, кто и как это делал [ссылки на литературу], положительные и отрицательные стороны, что сделано и не сделано.
1. 2 Описание существующих бизнес-процессов
По результатам обзора предметной области и анализа функционирования объекта построить и описать диаграммы существующих бизнес-процессов объекта.
1. 3 Актуальность и цель работы
Сделать выводы из предыдущих разделов об актуальности развития предметной области и модернизации бизнес-процессов объекта. Из актуальности формулируется цель работы. Для достижения цели необходимо решить задачи, например изучить и модифицировать бизнес-процессы, методы, технологи, разработать новую модель, алгоритмы, написать ПО, протестировать, оценить качество, внедрить.
Источник: helpiks.su
«Анализ предметной области». Обучение проектированию программных продуктов. Часть 1. Тренинг 3.
Использование анализа предметной области для моделирования микрослужб
Одной из основных проблем, связанных с микрослужбами, является определение границ отдельных служб. Общее правило заключается в том, что служба должна делать «одну вещь», но для того, чтобы внедрить это правило на практике, требуется тщательное обдумывание. Механического процесса, создающего «правильную» структуру, не существует.
Необходимо подробно рассмотреть предметную отрасль, требования и цели вашего бизнеса. В противном случае можно столкнуться с непродуманной структурой, в которой есть некоторые нежелательные характеристики, такие как скрытые зависимости между службами, тесная взаимозависимость или плохо разработанные интерфейсы. В этой статье описывается подход к проектированию микрослужб на основе предметной области.
В этой статье в качестве примера используется служба доставки с помощью дронов. Дополнительные сведения о сценарии и соответствующей эталонной реализации см. здесь.
Введение
Микрослужбы нужно разрабатывать с учетом бизнес-возможностей, а не горизонтальных слоев, таких как доступ к данным или обмен сообщениями. Кроме того, службы должны иметь слабую взаимозависимость и высокую функциональную слаженность. Микрослужбы имеют слабую взаимозависимость, если можно изменить одну службу без необходимости одновременного обновления других служб.
Микрослужба считается слаженной, если у нее есть одна определенная цель, например управление учетными записями пользователей или отслеживание истории поставок. Служба должна содержать знания о предметной области и отделять эти знания от клиентов. Например, клиент должен иметь возможность запланировать полет дрона, не зная подробностей алгоритма планирования или управления парком дронов.
Предметно-ориентированное проектирование (DDD) предоставляет платформу, которая может помочь в разработке набора хорошо продуманных микрослужб. Этот алгоритм имеет два отдельных этапа: стратегический и тактический. На стратегическом этапе определяется масштабная структура системы. Этот этап помогает гарантировать, что архитектура ориентирована на бизнес-возможности.
Как правильно описать бизнес-процесс?
На тактическом этапе DDD предоставляется набор конструктивных шаблонов, которые можно использовать для создания модели предметной области. Эти шаблоны включают в себя сущности, статистические выражения и службы предметных областей. Эти тактические шаблоны помогают создавать микрослужбы, имеющие слабую взаимозависимость и хорошую слаженность.
В этой и следующей статьях мы рассмотрим следующие действия, применяя их к приложению доставки с помощью дронов:
- Начните с анализа предметной области бизнеса, чтобы разобраться в функциональных требованиях приложения. В результате вы получите неформальное описание предметной области, которое можно разделить на более формальный набор моделей предметных областей.
- Затем определите ограниченные контексты предметной области. Каждый ограниченный контекст содержит модель предметной области, которая представляет определенную подобласть крупного приложения.
- В рамках ограниченного контекста примените тактические шаблоны DDD, чтобы определить сущности, статистические выражения и службы предметных областей.
- На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.
В этой статье рассматриваются первые три шага, которые в первую очередь касаются DDD. В следующей статье мы определим микрослужбы. Важно помнить, что предметно-ориентированное проектирование — это итеративный текущий процесс. Ограничения службы не зафиксированы. По мере развития приложения можно разбить службу на несколько небольших служб.
Эта статья не предназначена для демонстрации полного и исчерпывающего анализа предметной области. Мы намеренно держали пример кратким, чтобы проиллюстрировать основные моменты. Общие сведения о проблемно-ориентированном проектировании можно найти в одноименной книге Эрика Эванса (Eric Evans), в которой был впервые представлен этот термин. Другим хорошим справочником является книга Вона Вернона (Vaughn Vernon) Реализация методов предметно-ориентированного проектирования.
Сценарий: доставка с помощью дронов
Компания Fabrikam запускает службу доставки беспилотными летательными аппаратами. Она управляет парком таких аппаратов. Организации регистрируются с помощью службы, и пользователи могут отправить заявку на использование беспилотного летательного аппарата, чтобы забрать посылки для доставки. Когда клиент планирует отгрузку, серверная система назначает аппарат и сообщает пользователю предполагаемое время доставки. В ходе доставки клиент может отслеживать местоположение аппарата, получая актуальные сведения об ожидаемом времени доставки.
Этот сценарий довольной сложный, так как его этапы включают планирование загруженности беспилотных летательных аппаратов, отслеживание посылок, управление учетными записями пользователей, а также хранение и анализ исторических данных. Кроме того, компания Fabrikam хочет быстро выйти на рынок, а затем быстро повторить этот процесс, добавив новые функции и возможности. Приложение должно работать в масштабе облака с высоким целевым уровнем обслуживания. Компания также ожидает, что в разных частях системы требования к хранению данных и выполнению запросов будут очень отличаться. С учетом всех этих факторов Fabrikam выбрала архитектуру микрослужб для приложения доставки беспилотными летательными аппаратами.
Анализ предметной области
Используя подход DDD, можно создавать микрослужбы так, чтобы каждая форма службы естественным образом совпадала с функциональным бизнес-требованием. Так вы сможете избежать ловушки, когда ограничения организации или технологии будут определять структуру.
Прежде чем написать код, необходимо иметь общее представление о создаваемой системе. DDD начинается с моделирования бизнес-области и создания модели предметной области. Модель предметной области — это абстрактная модель предметной области бизнеса. Она извлекает и организует знания о предметной области, а также предоставляет общий язык для разработчиков и экспертов соответствующей сферы.
Начните с сопоставления схемы всех бизнес-функций и их связей. Эта работа обычно выполняется совместно с привлечением специалистов по предметной области, архитекторов программного обеспечения и других заинтересованных лиц. При этом использовать какой-либо конкретный формальный способ не требуется. Нарисуйте схему на бумаге или доске.
Создавая схему, можно начать определять дискретные подобласти. Какие функции тесно связаны? Какие функции являются основными для бизнеса, а какие предоставляют вспомогательные службы? Что такое схема зависимостей? На начальном этапе технологии и подробности реализации не важны.
Все же следует отметить место, где приложение нужно будет интегрировать с внешними системами, такими как CRM, система обработки оплаты или выставления счетов.
Пример. Приложение доставки с помощью дронов
После первоначального анализа предметной области команда Fabrikam создала приблизительный эскиз, представляющий предметную область «Доставка с помощью дронов».
- Функция Доставка размещается в центре схемы, так как она является основной для бизнеса. Все остальное в схеме предназначено для обеспечения этой функции.
- Управление дронами также является ключевой бизнес-функцией. Функция, которая тесно связана с управлением дронами, включает их ремонт и использование прогнозного анализа для прогнозирования, когда дроны нуждаются в обслуживании.
- Анализ ETA предоставляет оценки времени приема и доставки.
- Транспортировка сторонними лицами позволяет приложению планировать другие способы транспортировки, если груз невозможно полностью отправить с помощью дрона.
- Совместное использование дрона является возможным расширением основной бизнес-функции. В определенные часы у компании может быть избыточное количество дронов, которые можно сдавать в аренду, чтобы они не простаивали. Этой возможности не будет в первоначальной версии.
- Видеонаблюдение является еще одной областью расширения деятельности для компании.
- Учетные записи пользователей, Выставление счетов и Центр обработки вызовов — это подобласти, используемые для поддержки основных бизнес-процессов.
Обратите внимание, что на этом этапе никаких решений о реализации и технологиях не принималось. Некоторые из подсистем могут включать внешние программные системы или сторонние службы. Тем не менее приложению необходимо взаимодействовать с этими системами и службами, поэтому важно включить их в модель предметной области.
Если приложение зависит от внешней системы, есть риск, что может произойти утечка схемы данных внешней системы или API в приложение, что может скомпрометировать архитектурный проект. Это особенно верно в отношении устаревших систем, которые могут не следовать современным рекомендациям и могут использовать сложные схемы данных или устаревшие API. В этом случае важно иметь четко определенную границу между внешними системами и приложением. Для этой цели рассмотрите возможность использования шаблона Strangler Fig или шаблона «Антивредоносный слой «.
Определение ограниченных контекстов
Модель предметной области включает представления реальных вещей — пользователей, дронов, грузов и т. д. Но это не значит, что каждая часть системы должна использовать одни и те же представления для одних и тех же вещей.
Например, подсистемы, которые обрабатывают ремонт дронов и прогнозный анализ, должны представлять множество физических характеристик беспилотных летательных аппаратов, таких как их история обслуживания, пробег, возраст, номер модели, характеристики производительности и т. д. Но при планировании доставки это нам неинтересно. Подсистеме планирования необходимо знать, доступен ли дрон, а также предполагаемое время для приема и доставки (ETA).
Если бы мы попытались создать единую модель для обеих этих подсистем, это было бы излишне сложным. С течением времени модель будет все сложнее видоизменять, так как любые изменения должны будут удовлетворять несколько команд, работающих над отдельными подсистемами. Поэтому зачастую лучше разрабатывать отдельные модели, которые представляют один и тот же объект реального мира (в данном случае дрон) в двух разных контекстах. Каждая модель содержит только те функции и атрибуты, которые имеют отношение к конкретному контексту.
Именно здесь вступает в игру концепция DDD ограниченных контекстов . Ограниченный контекст — это просто граница внутри предметной области, где применяется конкретная модель предметной области. Рассматривая предыдущую схему, можно группировать функции в зависимости от того, будут ли различные функции использовать одну модель предметной области.
Ограниченные контексты не обязательно изолировать друг от друга. На этой схеме сплошные линии, соединяющие ограниченные контексты, представляют места, где взаимодействуют два ограниченных контекста. Например, область «Доставка» зависит от области «Учетные записи пользователей» для получения информации о клиентах и от области «Управление дронами» для планирования полетов отдельных дронов.
В книге Проблемно-ориентированное проектирование Эрик Эванс описывает шаблоны по поддержке целостности модели предметной области при взаимодействии с другим ограниченным контекстом. Одним из основных принципов микрослужб является то, что службы обмениваются данными через четко определенные API.
Этот подход соответствует двум шаблонам, которые Эванс называет открытой службой размещения и опубликованным языком. Идея открытой службы размещения заключается в том, что подсистема определяет формальный протокол (API), через который другие подсистемы могут взаимодействовать с ней. Опубликованный язык расширяет эту идею, публикуя API в форме, которую другие команды могут использовать для написания клиентов. В статье Проектирование API для микрослужб мы обсудим использование спецификации OpenAPI (прежнее название — Swagger) для определения не зависящих от языка описаний интерфейсов REST API, выраженных в формате JSON или YAML.
В оставшейся части этого руководства мы сконцентрируемся на ограниченном контексте доставки.
Дальнейшие действия
После завершения анализа предметной области следующим шагом является применение тактического DDD, чтобы определить модели предметной области с большей точностью.
Связанные ресурсы
- Проектирование архитектуры микрослужб
- Проектирование архитектуры микрослужб
- Определение границ микрослужб
- Выбор варианта вычислений Azure для микрослужб
Источник: learn.microsoft.com
Анализ предметной области и формирование требований к информационной системе
XXI век предоставляет нам возможность взглянуть на возникновение экономики с момента ее зарождения, а также осознанно взглянуть на будущее экономики и человечества.
Используя средства связи можно, не выходя из дома, управлять технологическими линиями на производстве или финансово-коммерческой деятельностью предприятия, вести бухгалтерский учет, учиться дистанционным путем в учебном заведении, читать книги в библиотеке, покупать товары, совершать банковские, биржевые и другие финансовые операции и так далее. Появление в конце XX в. информационных технологий привело к появлению самого прибыльного бизнеса — интерактивного бизнеса.
Можно с полной уверенностью утверждать, что в середине XXI в. лидерами мировой экономики и международной торговли станут те страны, которые будут обладать высокой технологией и наукоемкими производствами. А это означает, что экспорт российской нефти, полезных ископаемых, торговля оружием и изделиями тяжелого машиностроения российскими фирмами займет в международной торговле одно из самых последних мест и уже не будет давать того дохода, который Россия имела в конце XX в.
В условиях рыночной экономики коренным образом меняется подход к управлению, от функционального — к бизнесориентированному, кардинально меняется и роль информационных технологий. Ориентация на управление на основе бизнес-процессов обеспечивает конкурентное преимущество для организации в условиях острейшей конкуренции, а управление на основе бизнес-процессов не может эффективно реализовываться без применения информационных технологий и систем.
Целью работы является рассмотрение автоматизированной информационной системы по расчету заработной платы.
Объект исследования – автоматизированная информационная система, предмет исследования — автоматизированная информационная система по расчету заработной платы.
В процессе достижения цели работы предполагается решение следующих задач:
— исследование теоретические основы работы автоматизированных информационных систем;
— организация автоматизированной информационной системы по расч ету заработной платы.
Глава 1. Анализ предметной области и формирование требований к информационной системе
1.1Описание объекта автоматизации
1.1.1 Экономический анализ деятельности организации
Полное название предприятия: Общество с ограниченной ответственностью
Медико-фармацевтическая фирма «МЕД», созданная в соответствии с Гражданским кодексом Российской Федерации и Федеральным законом Российской Федерации «Об обществах с ограниченной ответственностью».
Юридический адрес: г.Москва, шоссе ЭНТУЗИАСТОВ, д. 56.
Целью деятельности фирмы ЗАО «МЕД» является здравоохранение и предоставление социальных услуг — деятельность лечебных учреждений. Организация является юридическим лицом и строит свою деятельность на основании Устава и действующего Законодательства Российской Федерации. ЗАО «МЕД» находится на двух режимах налогообложения: УСНО и ЕНВД.
Экономическая характеристика организации ЗАО «МЕД»
Таблица 1 – Ресурсы организации
Источник: student-files.ru