Современный мир с каждым днем все более и более зависит от информационных систем. Программы – это основа, «цифровое сердце» повсеместно используемых электронных устройств, транспортных средств, финансовых сервисов, инфраструктурных объектов и пр.
Недавние инновации, которые стали частью нашей жизни и операционной деятельности, теперь воспринимаются как данность. Многих современных организаций просто не существовало бы, если бы программное обеспечение не достигло своего актуального уровня.
Более того, нынешние гиганты различных традиционных и фундаментальных областей деятельности человечества все больше и больше зависят от программного обеспечения и качества его реализации. Трудно отыскать компанию, в которой не применялось бы ни одного программного продукта. В таких условиях только программное обеспечение , отвечающее самым высоким стандартам качества, может гарантировать компаниям мощный базис последующего развития и процветания. Но также важно, чтобы эти системы обладали доступной и обоснованной стоимостью.
Проектирование частного дома, с чего начинать? Основы. Видео №1
Таким образом, становится очевидным, что для достижения необходимых параметров информационные системы должны обладать соответствующей архитектурой, поддерживающей заданные свойства. Для того чтобы достичь нужных характеристик, необходимо оптимальным образом организовать процесс проектирования будущей архитектуры создаваемых информационных систем. Решения, принимаемые на стадии проектирования, во многом являются определяющими для последующего жизненного цикла программного продукта.
Именно поэтому стадия проектирования предопределяет те фундаментальные параметры, которыми будет обладать разрабатываемая система в будущем. Тому, как организовать процесс проектирования, какой инструментарий использовать и как управлять необходимыми атрибутами, будет посвящена эта книга.
Введение
Такие понятия, как архитектура , проектирование и пр., ассоциируются в первую очередь с отраслью строительства, т.е. созданием сооружений. Эти термины используются для того, чтобы, с одной стороны, кратко, а с другой – полно выразить ощущения от восприятия конкретных сооружений: внешний вид, внутренняя обстановка, сочетание с окружающим ландшафтом и пр.
С программным обеспечением дело обстоит примерно так же. Под архитектурой и предваряющей ее стадией проектирования понимаются все те необходимые параметры, которые предопределяют создаваемые программные продукты.
«Для того чтобы уберечь бизнес от дезинтеграции, концепция создания архитектуры информационных систем перестает быть просто одной из возможных опций, а становится настоятельной необходимостью».
Для специалиста в области разработки программного обеспечения стадия проектирования и используемый инструментарий означают намного больше. Профессионал сразу сможет оценить все идеи и наработки, используемые для достижения необходимого результата. Также немаловажным фактором является и личность самого проектировщика.
В архитектуре информационных систем, так же как и в классической архитектуре, состав, структура и назначение компонент информационной системы, ее реальный эффект в том числе определяется субъективными аспектами восприятия со стороны конечных пользователей. Проработанный интерфейс , поддержка и развитие реально используемых функциональных возможностей создадут предпосылки для успеха и обеспечат его организации, эксплуатирующей информационную систему. Устаревшие приложения и архаичные технические средства станут тормозом продуктивной работы. Они должны будут разделить судьбу сооружений, канувших в лету обломков и руин.
С чего начать разработку проекта? — Вопросы и Ответы #10
Современный уровень развития информационных технологий с точки зрения стандартизации и совместимости сейчас, по мнению многих экспертов, соответствует уровню развития процессов урбанизации, промышленного производства примерно 80-х годов XIX века. В это время господствовали мелкие магазины, предлагающие товар , который требовалось подгонять под заказчика, поскольку единых стандартов не существовало. Изделия изготавливались под заказ в мастерских. Эта ситуация начала меняться, когда появилось массовое производство с применением сборочных линий и развитием сети железных дорог. Это привело к бурному росту распространения стандартизированных товаров.
Очевидно, что и в сфере IT предстоит пережить переход к новому уровню развития систем. Новый уровень будет характеризоваться повышением значимости стадии проектирования, увеличением взаимодействия между стандартными компонентами и пр.
Приведенные аналогии являются всего лишь авторским взглядом на затрагиваемый в данной книге предмет исследования. В определенном смысле сравнение со смежными областями, развитие которых занимает более высокий уровень зрелости, полезно – как для изучения возможностей предмета, так и для получения новых знаний.
Понятие архитектуры информационной системы не является чем-то принципиально новым, но в настоящее время наблюдается своеобразный ренессанс – достаточно обратить внимание на число публикаций в прессе и сети Интернет. Для этого должны существовать объективные причины, и главная из них, вероятно, связана с возможностью увеличения эффективности использования информационных технологий для основной деятельности организации.
Перед тем как перейти к процессу проектирования и, как следствие, к разработке оптимальной архитектуры, необходимо сформулировать цели, которых должна достигнуть создаваемая архитектура и способы ее разработки. Это поможет использовать уже имеющийся опыт в данной области и рекомендации отраслевых экспертов.
Одна из задач, которую предстоит решить на данном пути, состоит в том, что не существует простого, однозначного определения понятия IT-архитектуры. Акцент и трактовка данного предмета изменяются в зависимости от автора или издательства, поэтому важность отработанной дисциплины проектирования и ее инструментария выходят на первый план.
Можно утверждать, что дальнейшее развитие различных бизнес-направлений деятельности человечества приведет к соответствующим изменениям в IT-системах, а также целях и задачах их использования.
Высокая зрелость процессов проектирования информационных технологий позволит обеспечить определенный уровень стабильности, возможность «адаптировать» информационные системы под актуальные потребности бизнеса.
Основной принцип системного мышления гласит: «То, что является в меру хорошим для каждой части, обычно является наилучшим для всей системы в целом. Если одна часть изменяется, то это приводит к изменению остальных частей».
Качественная архитектура и зрелый процесс проектирования – компромисс между такими факторами, как:
- бизнес-потребности и ожидания;
- квалификация персонала, задействованного в процессе проектирования;
- технологии, на основе которых предполагается реализовывать проектируемую автоматизацию процессов или функционала;
- инструменты и frameworksпроектирования.
В данной книге предпринята попытка систематизировать информацию о проектировании в целом и применяемых шаблонах в частности. Зачем они нужны? Как они могут помочь в ходе проектирования? Что нужно делать для того, чтобы в компаниях была возможность реализовывать оптимальные для бизнеса программные продукты?
Источник: intuit.ru
Как проектируют приложения: разбираемся в архитектуре
Старший iOS-разработчик из «ВКонтакте» рассказывает, почему архитектура не главное в проекте и как сделать продукт поддерживаемым и масштабируемым.
Евгений Ёлчев
Евгений Ёлчев
об авторе
Ссылки
Я люблю спорить о том, какая архитектура лучше. Может, из-за своего внутреннего перфекциониста или диплома архитектора информационных систем, а может, потому, что мне лень копаться в плохих проектах.
Спойлер: больше всего я люблю архитектуру MVC. Дальше расскажу, как она работает и почему мне не нравятся всякие MVVM, MVP и VIPER. Кстати, недавно я разобрался во Flux и её имплементации Redux и понял, что их я тоже недолюбливаю.
В основе статьи — тред автора в Twitter.
Что такое архитектура MVC
Впервые с архитектурой Model-View-Controller (MVC) я столкнулся в 2009 году, когда изучал веб-фреймворк Zend . В его документации было написано, что Model — это база данных, View — HTML-шаблон, а Controller — логика, которая берёт данные из БД, обрабатывает их, кладёт в шаблон и отдаёт страницу.
Я тогда был студентом, делал курсовые и пет-проекты. У них была сложная вёрстка и непростая структура БД, но максимально простая логика. Код получался простым, но в целом меня такой подход устраивал.
Мне не приходило в голову, что можно делать не так, как написано в документации к инструментам и в примерах на форумах. Я был счастлив и не забивал голову чепухой.
Сомневаться в своём подходе я начал из-за статей на «Хабре», где говорили, что логику нужно закладывать в модель, чтобы контроллер оставался максимально простым. Так я узнал о двух версиях MVC — с тонким и толстым контроллером .
Я пробовал поменять логику в своём проекте — перенёс её из одного файла в другой, но разницы не заметил. По факту ничего и не изменилось, только код теперь лежал в другом файле.
Изучая дискуссии в интернете и рассуждая самостоятельно, я понял, что «толстая» модель мне не нравится. Пусть лучше модель остаётся базой данных, а контроллер и дальше управляет логикой.
Со временем мои проекты становились всё сложнее, а контроллеры пухлее (правда, не как UIViewController в iOS). Я пробовал с этим бороться, выносил логику в сторонние файлы, которые включал в контроллеры, но это мало что меняло: архитектура сохранялась, просто код переносился из одного файла в другой.
Почему MVC не работала в моих проектах
В 2013 году я пересел на Laravel, разобрался с автозагрузкой классов в PHP, начал разбираться с ООП и прочитал «Совершенный код» Стива Макконнелла.
Стало ясно, что не стоит складывать всё в один файл — код и классы должны организовывать структуру, а некоторые фрагменты кода лучше убрать из MVC и выделить в самостоятельные части, которые можно переиспользовать.
С этого момента я начал писать проекты по-другому. В них появились иерархии классов, которые хранили логику, а контроллер сильно похудел — он получал данные от базы, передавал их в разные пакеты, получал от них результат и отправлял на HTML-страницу.
Архитектура проектов не была идеальной, потому что не подошла бы ни для одной сложной системы. Но для моих целей она была крутой и удобной: код получался читабельный, а все элементы проекта оставались довольно независимы.
Как я делал систему управления
VDS-сервером
Следующий качественный скачок случился, когда я отошёл от веб-разработки и углубился в бэкенд. Мне пришлось проектировать и разрабатывать сложную систему управления VDS-сервером . Там были API, плагины, менеджер зависимостей для плагинов, асинхронный код , много режимов работы, связь с операционной системой и разным софтом. Основная задача проекта — чтобы у системы было ядро и самостоятельные плагины, которые бы умели работать вместе.
В сложной системе нельзя передавать все данные через один контроллер, поэтому каждый плагин отдельно реализовывал веб- и API-интерфейсы, доступ к данным и бизнес-логику, вынесенную в пакеты для переиспользования.
Получилось так: HTML ⟷ JavaScript (модели, общение с API) ⟷ API ⟷ переиспользуемые пакеты ⟷ бизнес-логика и доступ к данным. Всё это не было похоже на MVC.
Потом я ушёл в iOS-разработку и временно перестал думать про архитектуру. Изучал UIKit , а компоненты располагал по наитию. HTML и CSS превратились в разные UIView, тонкий контроллер — в UIViewController, бизнес-логика — в сервисы.
Почему архитектура не главное в проекте
C MVC всё работало хорошо, но я читал и про другие архитектуры. Люди рассказывали, как MVVM , MVP или VIPER упростили им жизнь, поэтому я тоже решил их попробовать.
Когда я увидел, как это реализуют в других компаниях, то осознал несколько важных нюансов.
Архитектура не даёт преимуществ. Ни одна продвинутая архитектура не была лучше того, что я делал в самом начале. За всё время я перепробовал разные подходы и поэтому мог оценить их пользу для проекта. Но между MVC и MVP не было разницы — кроме названий классов и правил вроде тех, когда элементы вызывают друг друга.
Компании понимают архитектуру по-разному. Одни говорят, что используют MVVM, у других то же самое называется MVC. Я видел пять MVVM-систем, и все были разными. Исключение — VIPER, у которой благодаря Егору Толстому есть подробная документация и много примеров. Но даже там были отличия.
Популярная архитектура не значит лучшая. Выбирать архитектуру из-за мейнстримности бесполезно. Кто-то решает использовать MVVM, но одни и те же компоненты кладёт в разные части проекта.
Архитектура не спасёт проект. Сама по себе она не решает проблемы и не гарантирует успеха.
Что же такое MVC на самом деле
Я постоянно изучал архитектуры, читал книги и спорил с коллегами, несколько раз пересматривал идею MVC в языке Smalltalk и несколько раз менял к ней отношение.
В итоге я понял, что MVC — это не три файла, и даже не несколько классов для каждого элемента. Модель — не про данные и не про бизнес-логику, а контроллер давно не нужен, и пора использовать MV.
Приложения с бизнес-логикой и доступом к данным были и до MVC, им не хватало только пользовательского интерфейса. Главная задача MVC — связать UI со всем остальным. Единственная рекомендация от создателя — при надобности создавать для каждой View свой фасад для Model и слушать его через паттерн-наблюдатель.
View — это и есть пользовательский интерфейс, Model — остальное приложение. Задача Controller — не быть прослойкой между V и M, а всего лишь принимать информацию от пользователя.
Принцип MVC — не мешать UI с бизнес-логикой, базой данных и другими частями приложения. А как это реализовать, уже пускай думает архитектор. Это не космическая инженерия.
Важно понимать, что MVP, MVVM или VIPER не заменяют MVC, а только дополняют её. Контроллер уже не нужен, потому что за ввод данных отвечает View, это стало его неотъемлемой частью.
Получается, что MVC в Apple, MVVM и другие варианты — это MV, где контроллер убрали за ненадобностью. Из всех современных MV(x) именно MVVM больше всего похожа на каноническую MVC.
Все эти термины усложняют общение. Иногда сложно понять, о чём тебе говорят, хотя задача архитектуры в том, чтобы всё было проще и понятнее.
Как разобраться в любой архитектуре
Может показаться, что все архитектуры одинаковые, и им вообще не стоит уделять внимания. Но это не так. У меня есть несколько правил.
Главное — реализация. Глобальная архитектура не так важна, как её воплощение. Всё зависит от того, как вы называете классы, где храните элементы и как классы общаются между собой. Все из команды должны соблюдать ваш стандарт, и тогда проект будет проще поддерживать.
Model — ваша ответственность. Архитектура MVC не даёт инструкций, как правильно написать основную часть приложения. Ваша ответственность в том, чтобы не устраивать в Model кашу, где половина классов — Service, а вторая половина — Helper.
Нужно разбираться в основах. Не стоит изучать конкретную архитектуру, лучше понять, из чего она логически следует. Тут поможет история, объектно-ориентированное и функциональное программирование, паттерны, SOLID и всё остальное. Обязательно надо прочитать «Совершенный код» Стива Макконнелла.
Когда вы разобрались с основами, можно подходить к архитектуре Flux и библиотеке Redux. Я выделил их, потому что Facebook* сформулировал подробный гайд по Flux, а также выпустил под неё библиотеку. Неожиданно, но это тоже MVC — M и V разделены, и V слушает изменения в M. Правда, тут появились дополнительные ограничения, которые все тоже трактуют по-своему.
Redux — хорошая штука, но и у неё есть проблемы. Я использовал эту библиотеку в проекте, который писал и поддерживал сам. Всем компонентам старался давать правильные названия, завязывал на Store не все View, а только начальную сцену, группировал middleware и редюсеры , даже связывал их со стейтом.
С какого-то момента я начал теряться в проекте. У меня появилась куча сущностей с похожими названиями и похожими данными, я создал миллиард экшенов. В итоге сам запутался, что, как и с чем взаимодействует.
Код был расширяемый и поддерживаемый, но, если я хотел что-то изменить, приходилось править гору файлов. Это очень больно. А если учесть, что проект работал на бойлерплейтном Flutter , то боль усиливалась на порядок.
Redux хороша для больших проектов, ориентированных на офлайн, где одновременно происходит куча асинхронных неблокируемых событий. Там этот бойлерплейт стоит терпеть, потому что он спасёт вам жизнь. Но в обычном тонком клиенте лучше использовать стандартную MV и не париться.
Вывод: что прочитать об архитектуре
Настоящая архитектура — та, которая описывает ваши подходы, она должна быть понятна всей команде. Если я буду делать приложение на SwiftUI , то выберу классическую MV — ту, где View следит за Model (многие называют это MVVM). И вам рекомендую поступать так же.
На «Хабре» есть отличные статьи об MVC — «Охота на мифический MVC. Обзор, возвращение к первоисточникам и про то, как анализировать и выводить шаблоны самому» и «Охота на мифический MVC. Построение пользовательского интерфейса». Обязательно прочитайте их, если интересуетесь архитектурой — автор тщательно и на хороших примерах разобрал, что это такое.
Zend Framework — открытый объектно-ориентированный фреймворк для PHP 5. Переименован в Laminas Project.
Если контроллер тонкий, то логика заложена в модели, а если толстый, то в самом контроллере.
UIViewController — это класс во фреймворке UIKit от Apple. Чтобы собрать UI-приложение, для него нужно создавать подклассы.
VDS-сервер — виртуальный выделенный сервер, то же, что и VPS-сервер. Эмулирует работу физического выделенного сервера. У него есть root-доступ и возможность устанавливать нужные ОС и ПО.
Синхронный код выполняется сразу, асинхронный — только в нужный момент. Например, когда загрузится изображение или ответит удалённый сервер.
UIKit — фреймворк, на основе которого строят фронтенд приложений для iOS и tvOS.
Model-View-ViewModel — один из вариантов архитектуры приложения. View отвечает за интерфейс и пользовательский ввод, ViewModel — посредник между UI и логикой.
Model-View-Presenter — шаблон архитектуры, производный от MVC. Presenter выполняет ту же роль, что и Controller, но также отвечает за пользовательский ввод.
Аббревиатура VIPER обозначает View — Interactor — Presenter — Entity — Router. Архитектура часто используется в iOS-разработке.
Flux — это архитектура, которая используется в проектах на фреймворке React для JavaScript.
Redux — открытая библиотека для JavaScript. Нужна, чтобы управлять состоянием приложения. Помогает писать клиентские и серверные программы.
Middleware — промежуточное ПО, которое помогает приложению и серверу обмениваться запросами. Например, middleware может связать новую программу со старым API.
Редюсер (reducer) — это функция, которая получает состояние (state) и действие (action) и возвращает следующие. Её задача — сделать так, чтобы приложение реагировало, когда пользователь вводит новые данные, кликает по элементу мышью и так далее.
Бойлерплейт — код, который вставляют в приложение почти без изменений. Иногда одни и те же шаблоны кода копируют в разные части приложения.
Flutter — SDK и фреймворк от Google, созданный для разработки нативных мобильных приложений для iOS и Android.
SwiftUI — это комплект инструментов, в которых создают пользовательский интерфейс iOS-приложений.
Источник: skillbox.ru
2. Проектирование программы
Не спешите выходить на машину, тщательное проектирование сокращает общее время разработки! Проектирование программы включает: постановку задачи, внешнее проектирование, проектирование структуры и проектирование модулей. Проектируйте программу сверху вниз (от целого к деталям), не углубляйтесь преждевременно в детали!
2.1. Постановка и анализ задачи
Дайте точную математическую формулировку решаемой задачи, приведя определения всех используемых понятий. Определите перечень входных и выходных величин, единицы их измерения, области изменения и зависимости между ними. Доопределите задачу, включая случаи отсутствия решения. Приведите примеры, иллюстрирующие основные варианты решения задачи. На эти примеры удобно опираться при проектировании и описании программы, а затем они послужат тестами для ее отладки.
Проведите предварительный анализ поставленной задачи, определив основные возникающие проблемы и наметив возможные методы их решения.
2.2. Внешнее проектирование
Внешнее проектирование — это разработка архитектуры программы, т.е. точное описание ее поведения с точки зрения пользователя. Другими словами, внешнее проектирование программы — это проектирование ее внешнего интерфейса (способа взаимодействия с пользователем), включающего все выполняемые для пользователя функции программы и детальное описание ее входных и выходных данных. Архитектура программы представляется в виде ее внешней спецификации, которая служит исходной информацией для проектирования программы и разработки ее эксплуатационной документации.
2.2.1. Методика внешнего проектирования
Внешнее проектирование удобно рассматривать упрощенно как разработку инструкции пользователю по эксплуатации программы. Важно не только достаточно понятно и подробно описать, что делает программа и как ее использовать, но и избежать ненужной для пользователя информации о работе программы. В то же время, иногда пользователю необходимо иметь общее представление о методах решения задачи, если оно помогает грамотно эксплуатировать программу, например, определяет ее преимущества, недостатки и другие особенности по сравнению с подобными программами.
Для правильного подхода к внешнему проектированию необходимо постоянно мысленно ставить себя на место пользователя будущей программы. Пишите так, чтобы было понятно людям, не знакомым с программированием, используя только терминологию той предметной области, к которой относится решаемая задача.
Назначение и функции программы определяются и описываются как указано в разделе 2.1.
Описание входных и выходных данных включает их перечень, структуру и местонахождение. Оно составляется как инструкция для пользователя по вводу исходных данных и использованию результатов программы.
Описание данных приводится в общем виде и иллюстрируется примерами. Удобно использовать примеры из раздела постановки задачи.
При составлении спецификации программы во время внешнего проектирования необходимо доопределить результаты ее работы для всех возможных недопустимых данных. Программа должна проверять правильность входных данных. При обнаружении ошибок программа обычно сообщает о них, а затем, если возможно, исправляет их каким-либо образом и продолжает работу. Худшее, что может сделать программа, — принять неправильные входные данные и выдать бессмысленный, но правдоподобный результат.
При описании выходных данных приведите перечень всех возможных сообщений программы. Отдельно укажите сообщения об ошибках. Желательны также сообщения о начале и конце работы программы, об особых ситуациях при решении задачи, об отсутствии решения, обо всех ситуациях, требующих вмешательства пользователя, и т. п.
Сообщения необходимо пронумеровать, так удобнее на них ссылаться. Формулировки сообщений должны быть единообразными и понятными пользователю. Ему должно быть ясно, что произошло и как поступить. В частности, не следует упоминать в сообщениях неизвестные (и ненужные!) пользователю детали алгоритма или внутренних структур данных программы. Неудачное сообщение: «n > 10. Таблица переполнена» лучше сформулировать, например, так:
«Ошибка: количество вершин > 10. Повторите ввод».
Более подробно выбор внешнего представления данных рассмотрен в разделе 2.2.2.
Программа может иметь входные и выходные файлы, имена которых указываются ей в команде запуска программы из операционной системы. Эти имена передаются программе как параметры функции main (см., например, [27, 29]). Для входного файла vhod и выходного файла rez, в операционной системе MS DOS или UNIX программу можно запустить, например, командой:
где pkrc — имя файла, содержащего исполняемый модуль программы.
Можно не указывать в программе в явном виде имена файлов. В этом случае подразумевается стандартный входной файл, обычно вводимый с клавиатуры, и стандартный выходной файл, обычно выводимый на экран, которые при запуске программы можно переключить на любые файлы с заданными именами с помощью переадресации ввода-вывода [27]. Если, например, исходные данные вместо клавиатуры необходимо взять из файла vhod, а результат вместо экрана должен выводиться в файл rez, программа вызывается следующей командой операционной системы MS DOS или UNIX:
где pkrc — имя файла с исполняемым модулем программы.
Источник: studfile.net