Архитектурное проектирование

Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия систем.

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

Модели архитектуры могут зависеть от нефункциональных требований к разрабатываемой системе:

Производительность — за критические операции отвечает как можно меньше подсистем — т.е. используется крупномодульная архитектура

Защищённость — многоуровневая архитектура системы, наиболее критические элементы защищены на нижнем уровне

Надёжность — включаются явно излишние компоненты, которые можно изменять не прерывая работу системы

Удобство сопровождения — архитектура из мелких компонентов, которые можно легко адаптировать под требования предметной области

Безопасность — за все операции, влияющие на безопасность, должно отвечать как можно меньше подсистем

Нисходящие проектирование.

Метод разработки проектов, систем, программ, при котором разработка производится сверху вниз.

Метод предполагает последовательное разложение функции обработки данных на простые функциональные элементы ("сверху вниз").

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

§ цели предметной области (цель-подцель);

§ состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;

§ характер взаимодействия приложений с их основными характеристиками;

§ функции обработки данных.

 

Восходящее проектирование

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

Паттерны проектирования

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

При составлении представленного здесь каталога паттернов проектирования активно использовались материалы, указанные в списке литературы. За основу взята классификация GoF-паттернов по типам и видам. В то же время здесь нет прямого повторения материалов, представленных в GoF-каталоге. Также здесь представлены паттерны, встречающиеся в других источниках.

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

· Порождающие паттерны, предназначенные для создания новых объектов в системе.

· Структурные паттерны, решающие задачи компоновки системы на основе классов и объектов.

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

В общем случае описание каждого паттерна (шаблона) проектирования содержит следующие обязательные элементы:

· Название паттерна (оригинальное и русскоязычное). Если паттерн имеет несколько имен, то они также приводятся.

· Назначение паттерна. Здесь указывается решаемая паттерном задача.

· Общее описание паттерна.

· Структура паттерна в виде UML-диаграммы классов.

· Реализация паттерна с примерами кода на C++.

· Последствия применения паттерна.

Пилотного проекта

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

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

- подтвердить достоверность результатов оценки и выбора;

- определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;

- собрать информацию, необходимую для разработки плана практического внедрения;

- приобрести собственный опыт использования CASE-средства.

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

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

Первоначальное использование новой CASE-технологии в пилотном проекте должно тщательно планироваться и контролироваться. Пилотный проект включает следующие шаги (рис. 1).

1. Определение характеристик пилотного проекта

Пилотный проект должен обладать следующими характеристиками:

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

- Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость средства. Цель - получить четкое представление о масштабах проектов, для которых данное средство применимо.

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

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

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

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

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

25. Тести́рование програ́ммного обеспе́че́ния — процесс исследования, испытания программного продукта, имеющий две различные цели:

· продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

· выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации

Тестирование программного обеспечения (Software Testing) - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004] В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

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

1. Функциональные

2. Нефункциональные

3. Связанные с изменениями

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

Нефункциональные виды тестирования. Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.

Связанные с изменениями виды тестирования

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

Методы тестирования

- Тестирование белого ящика

- Тестирование черного ящика

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ (см. открытое программное обеспечение) и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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