сновные принципы проектирование приложений

рхитектура приложений.

Создание архитектуры приложения – это процесс формирования структурированного решения, отвечающего всем техническим и операционным требованиям и обеспечивающего оптимальные общие атрибуты качества, такие как производительность, безопасность и управляемость. Он включает принятие ряда решений на основании широкого диапазона факторов. Архитектура приложения должна объединять бизнес-требования и технические требования. Цель архитектуры – выявить требования, оказывающие влияние на структуру приложения. Хорошая архитектура снижает бизнес-риски, связанные с созданием технического решения. Хорошая структура обладает значительной гибкостью, чтобы справляться с естественным развитием технологий, как в области оборудования и ПО, так и пользовательских сценариев и требований. Архитектор должен учитывать общий эффект от принимаемых проектных решений, обязательно присутствующие компромиссы между атрибутами качества (такими как производительность и безопасность) и компромиссы, необходимые для выполнения пользовательских, системных и бизнес-требований.

Необходимо помнить, что архитектура должна:

 Раскрывать структуру системы, но скрывать детали реализации.

 Реализовывать все варианты использования и сценарии.

 По возможности отвечать всем требованиям различных заинтересованных сторон.

 Выполнять требования, как по функциональности, так и по качеству.

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

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

 

Рис. 1 Пользователь, бизнес, система

Необходимо искать компромиссы и находить баланс между конкурирующими требованиями этих трех областей.

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

 

2. Как можно улучшить адаптируемость приложения к будущим требованиям?

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

Рассмотрим следующие основные направления:

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

 Зрелость рынка. Используйте преимущества зрелости рынка, применяя существующие платформы и технологии. Используйте шаблоны, являющиеся богатыми источниками проверенных решений распространенных проблем.

 Гибкий дизайн. Все большую популярность приобретают гибкие дизайны, использующие слабое связывание, что делает возможным повторное использование и упрощает поддержку. Архитектура с возможностью подключения модулей позволяет реализовать расширяемость после развертывания.

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

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

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

 

3) Основные принципы проектирование приложений

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

Рассмотрим основные принципы:

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

 Создавайте модели для анализа и сокращения рисков. Используйте средства проектирования, системы моделирования, такие как Унифицированный язык моделирования и средства визуализации, когда необходимо выявить требования, принять архитектурные и проектные решения и проанализировать их последствия. Тем не менее, не создавайте слишком формализованную модель, она может ограничить возможности для выполнения итераций и адаптации дизайна.

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

 

 Разделение функций. Разделите приложение на отдельные компоненты с, по возможности, минимальным перекрытием функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую связность (highcohesion) и слабую связанность (lowcoupling).

 Принцип единственности ответственности. Каждый отдельно взятый компонент или модуль должен отвечать только за одно конкретное свойство/функцию или совокупность связанных функций.

 Принцип минимального знания (также известный как Закон Деметера (LawofDemeter, LoD)). Компоненту или объекту не должны быть известны внутренние детали других компонентов или объектов.

 Неповторяйтесь (Don’t repeat yourself, DRY). Намерение должно быть обозначено только один раз. В применении к проектированию приложения это означает, что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом компоненте.

 Минимизируйте проектирование наперед. Проектируйте только то, что необходимо. В некоторых случаях, когда стоимость разработки или издержки в случае неудачного дизайна очень высоки, может потребоваться полное предварительное проектирование и тестирование. В других случаях, особенно при гибкой разработке, можно избежать масштабного проектирования наперед (bigdesignupfront, BDUF).

 

сновные принципы проектирование приложений

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

Рассмотрим основные принципы:

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

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

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

 

Разделение функций. Разделите приложение на отдельные компоненты с, по возможности, минимальным перекрытием функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую связность (highcohesion) и слабую связанность (lowcoupling).

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

Принцип минимального знания (также известный как Закон Деметера (LawofDemeter, LoD)). Компоненту или объекту не должны быть известны внутренние детали других компонентов или объектов.

Неповторяйтесь (Don’t repeat yourself, DRY). Намерение должно быть обозначено только один раз. В применении к проектированию приложения это означает, что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом компоненте.

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