Разбор задачи из реальной практики

Фича для мобилки, которая должна работать на более ранних версиях. Как подойти к реализации и преодолеть ограничения?

https://habr.com/ru/articles/940858/

#rest #интеграции #анализ #собеседование #системный_аналитик #бизнес_аналитик #проектирование_по #решение_задач #архитектура

Разбор задачи с реального собеседования: e-commerce, брокер и резервы склада

Условия задачи Сценарий: У нас есть e-commerce платформа, состоящая из: • веб-приложения, • брокера сообщений, • бэкенда. Клиенты могут заказывать товары, а складская система проверяет наличие товаров на складе. Каждый раз, когда клиент делает заказ, система отправляет запрос через брокер для проверки доступности товара на складе и блокирует его на время обработки заказа . Проблема: Клиенты могут: • добавлять несколько товаров в корзину одновременно, • отправлять несколько заказов. Это приводит к тому, что резервируется больше товара, чем есть на складе . Из-за этого возможны ситуации, когда товар отображается как доступный, но при попытке завершить заказ оказывается, что он уже заблокирован другим клиентом. Необходимо: • Выявить процессы , которые происходят, • На основе этих процессов отобразить схему (sequence diagram) взаимодействия, • Предложить 2 способа оптимизации , чтобы избавиться от текущих проблем. Переходим к решению ⬇️

https://habr.com/ru/articles/934170/

#системный_аналитик #бизнес_аналитик #решение_задач #собеседование #микросервисы #проектирование_по #интеграции #rest

Разработка браузерного расширения: путь от идеи до публикации в web store

Разработка браузерного расширения началась с простой идеи: упростить поиск по закладкам и открытым вкладкам, а также попробовать свои силы в создании проекта с элементами монетизации. В этой статье я расскажу, как за две недели прошёл путь от прототипа до публикации в Chrome Web Store и Firefox Add-ons, какие технологии использовал и с какими трудностями столкнулся. Надеюсь, мой опыт вдохновит других разработчиков попробовать свои силы в создании подобных проектов. Полный код проекта доступен на GitHub .

https://habr.com/ru/companies/ntechlab/articles/930732/

#python #typescript #расширение #разработка_приложений #разработка_программного_обеспечения #chrome_extension #google_chrome #проектирование #проектирование_по #анализ_и_проектирование_систем

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Моделирование процессов управления

Разбирая в теоретической части к данному разделу свойство системы «Открытость», мы отметили, что благодаря постоянному потоку входящей и исходящей информации система осуществляет рациональное взаимодействие с окружающей средой. Посредством ее она управляет другими системами или управляется ими. При этом очевидно, что информация все больше переходит из разряда ресурса для производства, в ресурс для управления. Напомню один из основных принципов кибернетики: Информация рассматривается кибернетикой как средство управления. Для того чтобы управлять объектом, необходимо иметь:

https://habr.com/ru/articles/920838/

#проектирование_систем_управления #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #управление_продуктом #управляемые_сервисы

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

SharedLogic. Общий игровой код для Unity-клиента и .NET-сервера, который экономит ваши силы

Я хочу поделиться практическим подходом, который позволяет переиспользовать ваш игровой код на C# из Unity на .NET-бэкенде — это даёт возможность верифицировать действия игрока, защищает от читерства и обеспечивает мгновенный отклик без лагов. Я использую такую архитектуру в продакшене уже более 10 лет, и она отлично зарекомендовала себя как надёжное и эффективное решение. В этой системе один и тот же код выполняется и на клиенте (для мгновенной обратной связи), и на сервере (для авторитетной проверки). Как это работает: • Команды игрока мгновенно выполняются на клиенте. • Та же команда вместе с хэшем состояния отправляется на сервер и повторно выполняется для верификации. • Любые попытки изменить код или память клиента будут обнаружены и отклонены сервером. • Игровая логика вынесена в .dll-плагин, который используется и в Unity-клиенте, и на .NET-бэкенде. В статье есть полноценный пример на Unity («Connect Four»), открытый исходный код и подробное описание архитектуры. Читать статью

https://habr.com/ru/articles/918220/

#SharedLogic #игровой_сервер #backendпрограммирование #server #античит #паттерны_проектирования #проектирование_по #aspnet #mongodb

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.1. UML Class diagram

Одним из важнейших этапов в проектировании Информационной системы является выявление бизнес-объектов и их детализация на сущности Предметной области. По результатам этих активностей можно спроектировать модель хранилищ данных. Чаще всего такие работы выполняют параллельно с этапом описания бизнес-процессов. Как всегда, объявим цели текущего шага: определить и задокументировать сущности Предметной области и способы их взаимодействия. Спроектировать модель хранилищ данных. Таким образом мы расширяем наш домен решений, добавляя в него – модель данных. Чтобы сложить картинку о бизнес-объектах области автоматизации, необходимо уметь описывать бесконечное разнообразие сущностей мира - конечными фразами. Это можно сделать огрублено, приблизительно, упрощенно. 1) Первый шаг упрощения основан на том, что все объекты различны, но одни отличаются друг от друга «слабо», «мало», «незначительно», другие — «сильно», «существенно». 2) Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся. В итоге бесконечно разнообразный мир описывается конечным множеством отличающихся друг от друга классов. Похожий прием мы уже использовали на каждом этапе, классифицируя рассматриваемы элементы, определяя для них простейшую абстрактную модель разнообразия действительности. Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.). Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

https://habr.com/ru/articles/917654/

#проектирование_систем #проектирование_по #проектирование_баз_данных #анализ_и_проектирование_систем #системный_анализ #бизнесмодель #сущность #инженерия_требований #нормализация_данных

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов 7.2. Применение BPMN. Ресурсоемкость

Один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций. Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код , который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисов, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса и фиксирует прогресс и актуальные состояния в БД.

https://habr.com/ru/articles/916942/

#проектирование_систем #проектирование_по #проектирование #анализ_и_проектирование_систем #системный_анализ #промышленная_автоматизация #bpmn #ресурсное_планирование #предварительные_оценки #оценка_трудозатрат

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity

В качестве следующего шага на пути формирования проектного решения определим процессы, которые должны проистекать внутри разрабатываемой системы и окружать ее из вне. Поддерживая непрерывность процесса проектирования, будем отталкиваться от функций, которые мы выявили на предыдущем этапе. Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта . На текущем этапе проектирования воспользуемся Алгоритмизацией , еще одним приемом дисциплины «Системный Анализ». Рассмотренные нами ранее модели в большей степени отражали статику, ведь в итоге формализованные функции воплощают свойства системы, которые можно использовать. Теперь внесем немного динамики, моделируя действия. Важное отличие алгоритмов от используемых нами ранее диаграмм IDEF0, это возможность организовывать условные переходы, то есть в зависимости от выполнения некоего условия на определенном шаге сценария, предпринимать далее те или иные варианты действий. Концепция инжиниринга бизнес-процессов подразумевает осмысление различных моделей текущего состояния системы и прогнозирования будущих с целью достижения существенных улучшений по ключевым показателям: стоимость, качество, скорость, ресурсоемкость и прочее. В зависимости от актуальных условий может использоваться: 1) Экстраполяционная модель

https://habr.com/ru/articles/916676/

#проектирование_систем #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #промышленная_автоматизация #activity #uml #umlпроектирование

Диаграмма классов (англ. Class diagram)

Каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На этом пути будут поджидать множество сложных вопросов, от решения которых зависит успех. Неверные ответы могут значительно усложнить проект, а правильные сделать эту дорогу легкой. Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования). В качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы. Проектируемая программа не только позволит читать книги, но и делать их конспекты, цитируя и добавляя собственные комментарии. ------------- Текущая статья завершает цикл статей по теме проектирования. Ниже описывается, пожалуй, самый трудный этап. Переход от абстрактных рассуждений к конкретной реализации в виде исходного кода. Сложность заключается, в необходимости иметь значительные знания по теории программирования и опыта разработки программного обеспечения, и эти два пункта тесно связаны между собой. Теоретические основы описывают, как и почему необходимо применять тот или иной приём проектирования, а практические навыки позволяют принимать правильные решения, снижая количество допущенных ошибок. Настоящая статья описывает последовательность действий и разъясняет, почему были приняты те или иные решения. Однако, к сожалению, формат статьи не может вместить всё разнообразие вариантов и подходов к проектированию, и поэтому не является инструкцией. Она скорее послужит небольшим примером, для того чтобы самому попробовать разобраться в этой теме.

https://habr.com/ru/articles/907820/

#проектирование #проектирование_систем #проектирование_по #проектирование_и_рефакторинг