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

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

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

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

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

‍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.
2. Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
3. Рефакторинг – удалите из написанного вами кода любое дублирование.

Пример типичного блочного типа:

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

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

[Test Rollback] // Автоматический откат

// (использование служб без компонентов)

Public void TestUserBCCanSaveUser()

{

// Настройка информации из контекста (входные условия)

UserInfo user = Userinfo(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

// Это еще не тестирование, а уточнение исходного состояния

Assert.IsTrue(user.IsNew);

Assert.AreEqual (New_Object_Id, user.id);

Assert.IsFalse(

IsUserInsertedInDatabase(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

// Входные условия заданны - далее следует выполнение проверяемого метода

UserBC bcUser = new UserBC()

bcUser.SaveUser(user);

// Проверка выходных условий

Assert.IsFalse(user.IsNew);

Assert.IsTrue (user.id!= New_Object_Id,);

Assert.IsTrue(

IsUserInsertedInDatabase(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

Бизнес-компонент UserBC применяет бизнес-объект и сохраняет его в базе данных, поэтому в данном тексте проверяется его поведение, для чего создается бизнес-объект, который передается виде параметра методу SaveUser(), а затем проверяется сохраняемость это бизнес-объекта на информационном складе.

Дата добавления: 2017-01-13