Вопрос 3. Архитектура программной системы.

Выделяют как минимум три архитектурных слоя, каждый из которых, как правило, реализуется в виде отдельных библиотек (сборок на примере .NET Framework):

-  слой представления;

-  слой модели;

-  слой интерфейса данных.

‍

Рисунок 1 – Архитектурные слои программной системы верхнего уровня АСУТП

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

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

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

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

Вопрос 4. Tdd (Test Driven Development)

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

Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.

«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:

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

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

• Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них.

• Разработчику приятнее писать такой код.

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

• Пишем новый код только тогда, когда автоматический код не сработал.

• Удаляем дублирование.

Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

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

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

• Наша среда разработки должна быстро реагировать на небольшие модификации кода.

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

Два упомянутых правила TDD определяют порядок этапов программирования: