1.1.Повторное использование компонентов

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

• сегменты исходного кода;

• библиотеки кода;

• библиотеки ресурсов;

• интерфейсы объектов;

• объекты, расширяемые объекты и т. д.

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

1.2.Размер приложения

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

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

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

Результаты этого сравнения представлены в табл. 2.1.

Количество строк кода при применении разных языков и средств программирования

Язык программирования Количество строк кода, созданного человеком

Ассемблер 1 000 000

С 400 000

Ada 83 220000

C++или Ada 95 175000

C++ 75 000

1.3. Производительность приложения

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

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

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

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

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