Лекция№7. Лекция 7. Архитектура в смартпроектах. Архитектура и требования
 Скачать 205.72 Kb.
|
|
Лекция №7. Архитектура в смарт-проектах. Архитектура и требования. Архитектура программного обеспечения системы отображает организацию или структуру системы и дает объяснение того, как она ведет себя. Система представляет собой набор компонентов, выполняющих определенную функцию или набор функций. Другими словами, архитектура программного обеспечения обеспечивает прочную основу, на которой может быть построено программное обеспечение. Ряд архитектурных решений и компромиссов влияют на качество, производительность, ремонтопригодность и общий успех системы. Неспособность учесть общие проблемы и долгосрочные последствия может подвергнуть вашу систему риску. SMART (или умные) проекты — высокотехнологичные решения на страже бизнеса. Это когда технологии выходят за рамки исследовательских институтов и появляются в повседневной жизни людей в виде удобных гаджетов и городских локаций. Это порождает новый облик регионов, когда города преображаются в имиджевые и технологичные мегаполисы, где каждый объект инфраструктуры направлен на комфорт и безопасность жителей. В сущности, SMART проекты — это бизнес для людей, не лишенный инвестиционной привлекательности. Здесь соединяются социальная и коммерческая составляющие и получается выгодный с точки зрения бизнеса, и полезный, с точки зрения социума, проект. Инвестиционная привлекательность. SMART проект — это бизнес-идея, которая несет в себе не только социальную направленность, но и прибыль. Часто предприниматели не хотят связываться со сферой благоустройства в силу того, что это неприбыльные проекты. Но если посмотреть с другой стороны, то окажется, что интерактивные решения для города рождают массу возможностей для инвестирования. Есть разные варианты расшифровки аббревиатуры. Доран в 1981 году сформулировал так: Specific (конкретный), Measurable (измеримый), Assignable (назначаемый), Realistic (реалистичный), Time related (связанный со временем). Версия Мейера выглядит иначе: Specific (конкретный), Measurable (измеримый), Attainable (достижимый), Realistic (реалистичный), Tangible (осязаемый)  Критерии хорошей архитектуры Вообще говоря, не существует общепринятого термина «архитектура программного обеспечения». Тем не менее, когда дело касается практики, то для большинства разработчиков и так понятно какой код является хорошим, а какой плохим. Хорошая архитектура это прежде всего выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным. Программу с хорошей архитектурой легче расширять и изменять, а также тестировать, отлаживать и понимать. То есть, на самом деле можно сформулировать список вполне разумных и универсальных критериев: Эффективность системы. В первую очередь программа, конечно же, должна решать поставленные задачи и хорошо выполнять свои функции, причем в различных условиях. Сюда можно отнести такие характеристики, как надежность, безопасность, производительность, способность справляться с увеличением нагрузки (масштабируемость) и т.п. Гибкость системы. Любое приложение приходится менять со временем — изменяются требования, добавляются новые. Чем быстрее и удобнее можно внести изменения в существующий функционал, чем меньше проблем и ошибок это вызовет — тем гибче и конкурентоспособнее система. Поэтому в процессе разработки старайтесь оценивать то, что получается, на предмет того, как вам это потом, возможно, придется менять. Спросите у себя: «А что будет, если текущее архитектурное решение окажется неверным?», «Какое количество кода подвергнется при этом изменениям?». Изменение одного фрагмента системы не должно влиять на ее другие фрагменты. По возможности, архитектурные решения не должны «вырубаться в камне», и последствия архитектурных ошибок должны быть в разумной степени ограничены. "Хорошая архитектура позволяет ОТКЛАДЫВАТЬ принятие ключевых решений" (Боб Мартин) и минимизирует «цену» ошибок. Расширяемость системы. Возможность добавлять в систему новые сущности и функции, не нарушая ее основной структуры. На начальном этапе в систему имеет смысл закладывать лишь основной и самый необходимый функционал (принцип YAGNI — you ain’t gonna need it, «Вам это не понадобится») Но при этом архитектура должна позволять легко наращивать дополнительный функционал по мере необходимости. Причем так, чтобы внесение наиболее вероятных изменений требовало наименьших усилии. Требование, чтобы архитектура системы обладала гибкостью и расширяемостью (то есть была способна к изменениям и эволюции) является настолько важным, что оно даже сформулировано в виде отдельного принципа — «Принципа открытости/закрытости» (Open-Closed Principle — второй из пяти принципов SOLID): Программные сущности (классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации. Иными словами: Должна быть возможность расширить/изменить поведение системы без изменения/переписывания уже существующих частей системы. Это означает, что приложение следует проектировать так, чтобы изменение его поведения и добавление новой функциональности достигалось бы за счет написания нового кода (расширения), и при этом не приходилось бы менять уже существующий код. В таком случае появление новых требований не повлечет за собой модификацию существующей логики, а сможет быть реализовано прежде всего за счет ее расширения. Именно этот принцип является основой «плагинной архитектуры» (Plugin Architecture). О том, за счет каких техник это может быть достигнуто, будет рассказано дальше. Масштабируемость процесса разработки. Возможность сократить срок разработки за счёт добавления к проекту новых людей. Архитектура должна позволять распараллелить процесс разработки, так чтобы множество людей могли работать над программой одновременно. Тестируемость. Код, который легче тестировать, будет содержать меньше ошибок и надежнее работать. Но тесты не только улучшают качество кода. Многие разработчики приходят к выводу, что требование «хорошей тестируемости» является также направляющей силой, автоматически ведущей к хорошему дизайну, и одновременно одним из важнейших критериев, позволяющих оценить его качество: "Используйте принцип «тестируемости» класса в качестве «лакмусовой бумажки» хорошего дизайна класса. Даже если вы не напишите ни строчки тестового кода, ответ на этот вопрос в 90% случаев поможет понять, насколько все «хорошо» или «плохо» с его дизайном" (Идеальная архитектура). Существует целая методология разработки программ на основе тестов, которая так и называется — Разработка через тестирование (Test-Driven Development, TDD). Возможность повторного использования. Систему желательно проектировать так, чтобы ее фрагменты можно было повторно использовать в других системах. Хорошо структурированный, читаемый и понятный код. Сопровождаемость. Над программой, как правило, работает множество людей — одни уходят, приходят новые. После написания сопровождать программу тоже, как правило, приходится людям, не участвовавшем в ее разработке. Поэтому хорошая архитектура должна давать возможность относительно легко и быстро разобраться в системе новым людям. Проект должен быть хорошо структурирован, не содержать дублирования, иметь хорошо оформленный код и желательно документацию. И по возможности в системе лучше применять стандартные, общепринятые решения привычные для программистов. Чем экзотичнее система, тем сложнее ее понять другим (Принцип наименьшего удивления — Principle of least astonishment. Обычно, он используется в отношении пользовательского интерфейса, но применим и к написанию кода). |