В чем проектировать программу

Богданенко, Д. А. Подходы к архитектурному проектированию веб-приложений / Д. А. Богданенко. — Текст : непосредственный // Молодой ученый. — 2018. — № 9 (195). — С. 24-29. — URL: https://moluch.ru/archive/195/48609/ (дата обращения: 03.07.2023).

Ключевые слова: веб, приложение, архитектура, веб-приложение.

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

В начале своей истории все программы строились без каких-либо архитектурных принципов, программа состояла из множества следующих друг за другом строк: без классовых зависимостей, наследований и других современных возможностей языков программирования. Однако, стремление к упрощению разработки, а также к структуризации как кода, так и всего приложения могло являться предпосылкой к появлению такого понятия как «архитектура ПО».

В рамках данной статьи рассматриваются три подхода к архитектурному проектированию веб-приложений:

С чего начать разработку проекта? — Вопросы и Ответы #10

1. Монолитный подход
2. Модульный подход
3. SOA[1] или Сервис-ориентированный подход

Монолитный подход является самой старой моделью проектирования ПО поскольку именно с неё и началась разработка всего программного обеспечения. В рамках данного подхода сложной структуры веб-приложения как таковой может не быть: сервер хранит всю бизнес-логику, а база данных — данные необходимые серверу для работы.

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

Проблемы с поддержкой монолитного приложения можно объяснить и тем, что рано или поздно небольшой список функционала в системе пополняется новыми требованиями и идеями, которые требую внесения изменений в уже существующий код, что уже отражается в последнем предложении предыдущего абзаца. Кроме того, в рамках веб-приложения одной из проблем «монолита» является масштабируемость. Все составляющие системы расположены в одной точке, а потому мощность самой точки должна быть соответствующей для поддержки сервера и базы данных в рабочем состоянии.

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

Проект дома своими руками в SketchUp. Проектирование домов для новичков.

Рис. 1. Структура обычного веб-приложения

На рисунке 1 приведён пример структуры простого веб-приложения, состоящего из сервера, базы данных, а также межсетевого экрана, обычно за защиту отвечает хостинг, но если создавать нечто своё, то и защищаться придётся самому.

Далее приведён пример кода простого приложения с монолитной архитектурой, который располагается на сервере, который выводит ту или иную страницу в зависимости от пришедшего на сервер запроса.

Данное приложение написано на языке PHP. Входной точкой в приложение служит файл index.php, который и обрабатывает все входящие запросы. При входе в веб-приложение PHP включает метод get_server_params из одноимённого файла, который расположен в папке utils и в последствии использует его для получения значения содержавшегося в свойстве “REQUEST_URI” пришедших вместе с запросом на сервер.

Приведённое приложение является чисто показательным. В действительности, приложения даже в случае монолитной архитектуры будут выглядеть более структурированно и слаженно, а также иметь более продуманную систему маршрутов, в данной статье за это отвечает обычный switch-case. Разработать подобное приложение может каждый, но поддерживать его долго и включать в него всё новый функционал с определённого момент времени будет сложнее, если только не прибегнуть к рефакторингу[2] приложения, однако наступление этого момента отчасти зависит от профессионализма разработчика.

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

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

Стоит отметить, что при изменении одного модуля, другие модули затронуты не будут, а потому упрощается задача debug’а[3]. Всё, что потребуется, это подстроить остальные модули, использующие функционал изменённого модуля под новые возможности и требования последнего, если изменения в нём могут привести к сбою в работе приложения.

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

Примером могут выступать современные PHP фреймворки применяемые для быстрой разработки веб-приложений. В данных фреймворках каждый созданный класс-модуль обладает функционалом конкретной направленности и никак не взаимодействует напрямую с той частью приложения, для которой не был предназначен.

Примером модуля может выступать класс Router, который бы использовался для определения обрабатываемых в приложении маршрутов. Любые не указанные маршруты приводили бы пользователя на страницу с кодом ошибки 404.

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

Рис. 2. Модульное приложения состоящее из клиентской (Frontend) и серверной (Backend) части

На картинке выше приведён пример структуры модульного приложения, которое, предположим также располагается на сервере из рисунка 1, и которое состоит из двух модулей: клиентской части и серверной части. Каждая часть реализует свой функционал: клиентская часть отвечает за вывод пользовательского интерфейса, а серверная часть за всю оставшуюся бизнес-логику приложения, выполняя все требовательные вычисления на стороне сервера, в том числе работу с базой данных.

Клиентская часть, как указано на картинке, использует библиотеку React для вывода получаемых от серверной части данных. Последняя в свою очередь использует PHP в качестве языка программирования и отдаёт данные по запросу от клиентской части, а также включает в себя всю основную бизнес-логику приложения, поскольку клиент должен оставаться как можно более легким в плане размера итогового файла.

По факту не является критичным что конкретно используется на клиентской и серверной части. Клиентом может быть и Vue.js, и Angular, и «чистый» JS, а серверная часть может быть написана на Java, NET, C#, C++ и других языках.

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

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

Возможность разработки целостного приложения сервис-ориентированным подходом, предоставляет возможность разработки сервисов на разных языках программирования. Простой пример: сервис доставки сообщений может быть написан на NodeJS, где языком программирования используется JavaScript, в то время как основное приложение, использующее этот сервис, может состоять из связки React на клиентской части и PHP на серверной части. Для взаимодействия этих двух частей необходимо только правильно использовать программный интерфейс сервиса в основной части приложения.

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

Рис. 3. Сервис-ориентированная архитектура приложения

На рисунке выше изображена топология сети сервис-ориентированного веб-приложения типа «кольцо». В рамках данного приложения пользователь всегда попадает на сервер приложения с IP-адресом 192.168.0.30 и предоставляет общий интерфейс для работы с пользователем. Предположим, что веб-приложение отправляет почту и уведомления, а соответственно либо этот функционал нужно реализовать на сервере приложений, что является модульным подходом, либо выделить ему отдельный сервер в качестве отдельного сервиса, что и изображено на картинке выше.

Сервер отправки почты и уведомлений обеспечивает работу одноимённого сервиса, расположенного по IP-адресу 192.168.0.31 и основная задача которого — отправка почты и различного типа уведомлений. Сервис также предоставляет интерфейс для взаимодействия с ним другими сервисами и, таким образом, сервер приложения, при необходимости отправки уведомления одному или нескольким пользователям, будет отправлять запрос на соответствующий сервис и, таким образом, облегчая работу себе.

Приведённый выше пример является самым простым, уже сейчас на просторах «всемирной паутины» можно найти достаточное количество сервисов для отправки почты, смс-сообщений и многого другого, и это всё можно считать общедоступными сервисами, которые могут быть использованы многими веб-приложениями.

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

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

«Чем больше сила, тем больше ответственность». Данное выражение отлично подходит к сервис-ориентированным приложения, поскольку данный архитектурный подход не прощает ошибок и любой недочёт может серьёзным образом сказаться на всей работоспособности системы.

Для подтверждения того, что к сервис-ориентированному подходу нужно подходить с особой осторожностью далее приведён пример. В одном финансовом учреждении неисправно отрабатывал сервис оплаты. Клиент оплачивает курсы, сервис, который предоставляет эти курсы, получает сообщение от финансового учреждения — «деньги были переведены», и предоставляет доступ клиенту к курсам, однако, на одном из этапов, один из сервисов, который обрабатывал перевод денег отказал по неизвестной причине, что привело к откату транзакций и деньги возвращаются на счёт программиста, что привело к тому, что клиент получил доступ к курсам, при этом сервис, предоставивший их клиенту, деньги за это не получил.

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

Одним из основных ориентиров в выборе архитектурного подхода является стоимость поддержки приложения при том или ином подходе. На основании всего вышесказанного, можно составить следующий график (см. рисунок 3), который отражает соотношение роста стоимости обслуживания к росту функционала в приложении, построенном на основании каждого архитектурного подхода.

Рис. 4. Диаграмма соотношения роста стоимости обслуживания к росту функциональности приложения при применении различных архитектурных подходов

Как собственно было сказано в начале статьи и как показано на рисунке, монолитный подход предоставляет достаточно быстрый старт и требует меньше всего затрат, однако стоимость обслуживания приложений, разработанных на основе данного подхода растёт достаточно быстро. Модульный подход требует определённых затрат на старте, однако рост стоимости обслуживания не такой резкий, что позволяет поддерживать данные системы намного дольше. Наконец, SOA-подход требует серьёзных затрат на старте, что включает в себя достаточно комплексное планирование того как будет развиваться система.

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

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

1. Микросервисы или монолит: в поисках золотой середины // Корпоративный блог компании Грамант. URL: http://blog.gramant.ru/2017/05/17/microservices-vs-monolith-compromise/ (дата обращения: 1.03.2018).
2. Когда использовать монолиты, а когда микросервисы // Записки программиста. URL: https://eax.me/microservices-vs-monolithic/ (дата обращения: 1.03.2018).

[1] Service Oriented Architecture (англ.) – Сервис-ориентированная архитектура

[2] Процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы (https://ru.wikipedia.org/wiki/Рефакторинг)

[3] Debug – (англ.) – отладка, обычно подразумевает отладку приложения в случае ошибок или запуск приложения в режиме который позволяет отловить различного рода ошибки

Основные термины (генерируются автоматически): PHP, сервис-ориентированный подход, сервис, приложение, клиентская часть, модуль, монолитный подход, серверная часть, архитектурный подход, модульный подход.

Источник: moluch.ru

Какие есть хорошие программы для проектирования структуры программ?

Подскажите программы с помощью которых можно разработать структуру приложений перед приступлением к самой разработки.
К примеру с помощью которых можно строить диаграммы последовательностей, можно набросать интерфейс и т п.

• Вопрос задан более трёх лет назад
• 24205 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 10

Не стыдно не знать, а стыдно не интересоваться.
Ответ написан более трёх лет назад
Нравится 13 2 комментария

Поддерживаю! Для совместной работы — самое то.
Но для офф-лайн режима (или как резерв, аля офис) — см. мой ответ.

Шикарная программа, бесконечное уважение вам)

Ответ написан более трёх лет назад
Комментировать
Нравится 5 Комментировать

Сейчас начнут советовать X-Mind, Mindjet MindManager, freemind, ConceptDraw, Microsoft Visio, LibreOffice Draw, Dia. )
Но может и правда есть специально под разработку программ.
Интересно..
(глянь сюда, пока что . — https://en.wikipedia.org/wiki/List_of_concept-_and. )
Если что — вот кстати рисунок в Mindjet MindManager по Этой теме. ))

Рекомендую также присмотреться к sourceforge.net/projects/tuftsvue Visual Understanding Environment (VUE) . vue.tufts.edu
Давно что-то подобное искал. А щас благодаря этой теме нашёл)
Я чаще всего пользуюсь: X-Mind, реже Microsoft Visio, реже Explain1.5.0.0 , реже TheBrain, ещё реже Mindjet MindManager, реже ThinkBuzan iMindMap, реже Dia и LibreOffice Draw. Сейчас вот Visual Understanding Environment (VUE) нашел). Встанет на первое место), или на второе. Но это скорее для других целей.
freemind вообще чего-то не пошёл.

Источник: qna.habr.com

Проектирование

Концептуальное проектирование — процесс проработки верхнеуровневых идей о продукте в структурированный набор документов и артефактов, пригодный для использования в процессе дальнейшей разработки IT-продукта.

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

Когда требуется проектирование

Проработка идеи

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

Управление проектом

Структурирование информации о продукте, декомпозиция требований для дальнейшей постановки задач на разработку, выявление и управление рисками.

Управление разработкой

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

Зачем нужно проектирование

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

Видение продукта

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

Выявление и проработка рисков

В процессе проектирования осуществляется аналитика и проработка возможных рисков в контексте конкретных требований к системе.

Приоритизация и планирование

Проектирование позволяет приоритезировать функции и планировать релизы. Это минимизирует риск «долгостроя» и упрощает управление проектом при разработке.

Документирование

Результат проектирования — набор документов, подробно описывающий IT-продукт. В процессе дальнейшей разработки он актуализируется и дополняется описанием технической реализации и тестовой документацией.

Постановка задач

Спецификация требований является основой для формулирования задач и базой знаний для понимания деталей проекта командой разработки.

Необходимые ресурсы и бюджет

Декомпозированные требований к IT-продукту позволяют заранее определить необходимый состав проектной команды и рассчитать трудозатраты для реализации отдельных функций и проекта в целом.

Ключевые артефакты проектирования

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

Модель предметной области

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

Акторы (пользователи и системы)

Описание акторов, использующих систему. Классификация требований по пользователям, системным акторам и внешним системам.

Компоненты и архитектура

Описание компонентов системы (отдельные приложения и сервисы) и межсистемного взаимодействия. Классификация требований по компонентам.

Функциональные требования

Функции компонентов системы, сценарии использования, взаимосвязь с другими артефактами проекта.

Модель данных

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

Прототипы UI

Экраны пользовательского интерфейса, с которыми взаимодействуют пользователи при работе с системой.

Бизнес-правила

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

Нефункциональные требования

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

Интеграционные требования

Требования, определяющие порядок взаимодействия с внешними системами.

Процесс проектирования

Процесс формирования требований осуществляется итеративно, от меньшей детализации к большей с согласованием промежуточных результатов. Общий срок работ обычно составляет от 4 до 8 недель. Если проект объемный со сложной логикой, может потребоваться больше времени.

Сбор требований

Сбор имеющихся требований к системе:

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

Первичный проект

Минимальная детализация и промежуточное согласование:

• Структура предметной области
• Перечень ролей и компонентов
• Перечень требований
• Перечень
• Прототипы с минимальной детализацией
• Согласование промежуточных результатов

Детализация

• Подробное описание требований
• Подробное описание
• Детализация прототипов
• Согласование промежуточных результатов

Финализация

• Финализация документов
• Согласование
• Презентация результатов
• Передача результатов

Система управления требованиями

Формирование и структурирование требований осуществляется в специализированной системе управлениями требований к ПО, разработанной нашей компанией. Это инструмент, позволяющий удобно работать со множеством связанных документов, описывающих различные требования к системе.

Результат может быть выгружен в виде PDF файла (для использования в качестве подробного технического задания) или экспортирован в Atlassian Confluence.

После завершения работ по проектированию, система используется для технического проектирования, формирования тестовой документации и постановки задач команде разработки.

Примеры требований в системе Duotek ALM

Прототипы пользовательского интерфейса

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

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

Прототипы разрабатываются итеративно, начиная с малой детализации. После промежуточного согласования прототип детализируется.

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

Источник: duotek.ru