Протоколирование и инструментирование

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

 

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

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

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

 Сделайте свои приемники журнала, или слушатели трассировки, настраиваемыми, чтобы обеспечить возможность их изменения во время выполнения соответственно требованиям инфраструктуры развертывания. В реализации протоколирования и инструментирования в приложении очень помогут такие библиотеки, как Enterprise Library группы patterns & practices. Среди популярных библиотек можно также упомянуть NLog и log4net (больше информации по этому вопросу можно найти в разделе Дополнительные источники в конце данной главы)

 

Более подробно протоколирование и инструментирование рассматриваются в разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

 

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

Управление состоянием – это вопросы, связанные с хранением данных, представляющих состояние компонента, операции или этапа процесса. Для хранения данных состояния могут использоваться разные форматы и хранилища. Механизм управления состоянием может оказывать влияние на производительность приложения; сохранение даже небольших объемов данных состояния может неблагоприятно сказываться на производительности приложения и его способности масштабироваться. Сохраняться должны только необходимые данные, и вы должны понимать, какие варианты управления состоянием допустимы. При проектировании стратегии управления состоянием руководствуйтесь следующими рекомендациями:

 Сохраняйте минимальный объем данных состояния.

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

 Правильно выбирайте хранилище состояния. Хранение состояния в процессе или в памяти обеспечит наилучшую производительность, но эта техника может использоваться, только если состояние не должно сохраняться между повторными запусками процесса или системы. Если хотите, чтобы данные состояния были доступны после перезапуска процесса или системы, сохраняйте их на локальном диске или локальном SQL Server. Если состояние является критически важным аспектом приложения, или если данные состояния должны использоваться совместно несколькими компьютерами, храните состояние централизованно, например, на выделенном SQL Server.

 

Валидация

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

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

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

 Если необходимо обеспечить повторное использование подхода к валидации, реализуйте его централизованно, вынося функциональность валидации в отдельные компоненты, или обратитесь к библиотекам сторонних производителей, таким как Enterprise Library Validation Block (Блок валидации Enterprise Library) группы patterns & practices. Это позволит создать единый механизм валидации для всех слоев и уровней приложения.

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

 

 

Стандартные архитектуры по

Архитектурный стиль/парадигма	Описание
Клиент/сервер	Система разделяется на два приложения, где клиент выполняет запросы к серверу. Во многих случаях в роли сервера выступает база данных, а логика приложения представлена процедурами хранения.
Компонентная архитектура	Дизайн приложения разлагается на функциональные или логические компоненты с возможностью повторного использования, предоставляющие тщательно проработанные интерфейсы связи.
Дизайн на основе предметной области4	Объектно-ориентированный архитектурный стиль, ориентированный на моделирование сферы деловой активности и определяющий бизнес-объекты на основании сущностей этой сферы.
Многослойная архитектура	Функциональные области приложения разделяются на многослойные группы (уровни).
Шина сообщений	Архитектурный стиль, предписывающий использование
программной системы, которая может принимать и отправлять сообщения по одному или более каналам связи, так что приложения получают возможность взаимодействовать, не располагая конкретными сведениями друг о друге.
N-уровневая / 3-уровневая	Функциональность выделяется в отдельные сегменты, во многом аналогично многослойному стилю, но в данном случае сегменты физически располагаются на разных компьютерах.
Объектно-ориентированная	Парадигма проектирования, основанная на распределении ответственности приложения или системы между отдельными многократно используемыми и самостоятельными объектами, содержащими данные и поведение.
Сервисно-оринетрированная архитектура (SOA)	Описывает приложения, предоставляющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений.

Основные вопросы при разработке архитектуры по:

· Как пользователь будет использовать приложение?

· Как приложение будет развертываться и обслуживаться при эксплуатации?

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

· Как спроектировать приложение, чтобы оно оставалось гибким и удобным в обслуживании в течение долгого времени?

· Основные архитектурные направления, которые могут оказывать влияние на приложение сейчас или после его развертывания?

 

Основные проблемы

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

 

 

Параметры качества

 

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

 

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

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

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

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

 Пользовательские качества. Удобство и простота использования системы.

 

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

 

Сквозная функциональность

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

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

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

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

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

 

· Управление исключениями. Как обрабатывать и протоколировать исключения и обеспечивать уведомления в случае необходимости.

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

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

 

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

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

 Четко определяйте ввод и вывод слоев и компонентов приложения уже на этапе проектирования.

 Используйте для слоя представления шаблоны отделения представления, такие как MVC или MVP. Это обеспечит возможность модульного тестирования логики представления.

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

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

 Выработайте эффективную стратегию протоколирования и трассировки, что позволит выявлять или диагностировать ошибки, которые в противном случае было бы сложно найти. Обеспечьте данные протоколирования и трассировки, которые могут использоваться средствами мониторинга или управления. Это поможет обнаруживать дефектный код при возникновении ошибок. Файлы журнала должны содержать сведения, которые можно использовать для воссоздания проблемы.

 

 

Варианты решений

 

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

 

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

 

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

 

Пилотная архитектура (architectural spike) – это тестовая реализация небольшой части общего дизайна или архитектуры приложения. Ее назначение – анализ технических аспектов конкретной части решения для проверки технических допущений, выбора дизайна из ряда возможных вариантов и стратегий реализации или иногда оценка сроков реализации.

 

Анализ архитектуры приложения – критически важная задача, поскольку позволяет сократить затраты на исправление ошибок, как можно раньше выявить и исправить возможные проблемы. Анализ архитектуры следует выполнять часто: по завершении основных этапов проекта и в ответ на существенные изменения в архитектуре. Создавайте архитектуру, помня об основных вопросах задаваемых при таком анализе, это позволит как улучшить архитектуру, так и сократить время, затрачиваемое на каждый анализ.

 

 

16. Организация проектирования и разработки ПО [J]

№	Билет №	Формулировка ответа	Преподаватель	Кто делает ответ	Состояние
	6.3., 27.3., 40.2.	Организация проектирования и разработки программного обеспечения. Стандартные приемы и шаблоны при проектировании ПО. Распространенные шаблонные архитектурные решения, методы обеспечения сохранения данных (в т.ч. БД), приемы увеличения надежности, приемы увеличения производительности.	Алексеев Пётр Сергеевич	Маша Сергеева	Готовый ответ Маши

 

Готовый ответ Маши

Стандартные приемы и шаблоны при проектировании ПО.

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

Архитектурный стиль/парадигма	Описание
Клиент/сервер	Система разделяется на два приложения, где клиент выполняет запросы к серверу. Во многих случаях в роли сервера выступает база данных, а логика приложения представлена процедурами хранения.
Компонентная архитектура	Дизайн приложения разлагается на функциональные или логические компоненты с возможностью повторного использования, предоставляющие тщательно проработанные интерфейсы связи.
Дизайн на основе предметной области4	Объектно-ориентированный архитектурный стиль, ориентированный на моделирование сферы деловой активности и определяющий бизнес-объекты на основании сущностей этой сферы.
Многослойная архитектура	Функциональные области приложения разделяются на многослойные группы (уровни).
Шина сообщений	Архитектурный стиль, предписывающий использование
программной системы, которая может принимать и отправлять сообщения по одному или более каналам связи, так что приложения получают возможность взаимодействовать, не располагая конкретными сведениями друг о друге.
N-уровневая / 3-уровневая	Функциональность выделяется в отдельные сегменты, во многом аналогично многослойному стилю, но в данном случае сегменты физически располагаются на разных компьютерах.
Объектно-ориентированная	Парадигма проектирования, основанная на распределении ответственности приложения или системы между отдельными многократно используемыми и самостоятельными объектами, содержащими данные и поведение.
Сервисно-оринетрированная архитектура (SOA)	Описывает приложения, предоставляющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений.

 

Приемы увеличения производительности

 

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

рассматривайте их вместе. При проектировании производительности руководствуйтесь следующими рекомендациями:

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

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

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

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

 В случае применения DataReader используйте последовательный поиск, это обеспечит большую производительность.

 

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

 

Приемы увеличения надежности

 

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

 Аутентификация. Кто вы? Аутентификация – это процесс, при котором одна сущность четко и однозначно идентифицирует другую сущность, обычно это делается с помощью таких учетных данных, как имя пользователя и пароль.

 Авторизация. Что вы можете делать? Авторизация определяет, как приложение управляет доступом к ресурсам и операциям.

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

 Шифрование. Как реализована защита секретов (конфиденциальных данных)? Как осуществляется защита от несанкционированного доступа данных и библиотек (целостности)? Как передаются случайные значения, которые должны быть

криптографически стойкими? Шифрование и криптография занимается вопросами реализации конфиденциальности и целостности.

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

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

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

 Управление сеансами. Как приложение обрабатывает и защищает сеансы пользователей?

Сеанс – это ряд взаимосвязанных взаимодействий пользователя и приложения.

 

 

 

Резервное копирование

Резервное копирование выполняется для того, чтобы можно было:

• Восстанавливать отдельные файлы
• Восстанавливать целиком файловые системы.

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

· Резервная копия — это не больше чем снимок копируемых данных. Это отражение данных в определённый момент времени.

· И чем чаще меняются данные, тем чаще следует выполнять их резервное копирование.

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

· Возможности выполнения резервного копирования по расписанию

· Управление размещением, циклами копий и использованием носителей

· Взаимодействие с операторами (и/или автоматическими устройствами смены носителей), когда требуется определённый носитель

· Возможности, облегчающие поиск носителя с определённой копией заданного файла.