40 Entity Bean. Жизненный цикл.
Entity-бины представляют собой бизнес-правила, оперирующие с (хранящиеся постоянно) данными в базе данных, причем к этим данным в условиях решаемой задачи должны иметь доступ многие пользователи. Так как инфо в Бд являетя постоянной, то Entity bean живут постоянно, выживая после сбоя серверов. Каждому Entity-бину соответствует свой первичный ключ, по которому он может быть однозначно определен клиентом. Также Entity-бин имеет всегда какое-либо состояние (набор величин атрибутов, определяющих данный Entity-бин), которое может быть зафиксировано и сохранено, а затем и восстановлено. Разделяют персистентность, управляемую контейнером (Container-managed persistence) и персистентность, управляемую самим бином (Bean-managed persistence). Отличие состоит в том, кто ответственен за сохранение состояния бина: в первом случае это контейнер EJB, во втором - сам бин. Первое более универсально и требует меньших затрат от разработчика EJB, второе требует написания отдельного кода в бине и используется, очевидно, когда первый способ по каким-либо причинам (скорость, необходимость специальной функциональности при сохранении состояния бина, etc.) разработчика не устраивает.
Жизненный цикл Entity-бина состоит из трех состояний:
а) Бин не существует;
б) Бин находится в "обобщенном" (pooled) режиме, куда сервер приложений по спецификации переводит набор бинов, задавая им метод setEntityContext(). Таким образом, в этом состоянии бин получил кое-какие признаки своего класса, но ещё не идентифицирован с определенным полем в СУБД;
в) Бин находится в "готовом" (ready) режиме, он идентифицирован с конкретными данными в базе данных.
Заметим, что Entity-бинам не страшны такие приятные неожиданности, как сбои в системе или виртуальной Java-машине (JVM). Такие ситуации приведут только к откату (rollback) текущей транзакции и не уничтожат сам бин, который восстановится позднее при включении системы и JVM, и тем более не изменят ссылку, по которой клиент обращается к бину через JNDI.
41 Модели жизненного цикла
Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Модели -Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью: Формирование требований; Проектирование; Реализация; Тестирование; Внедрение; Эксплуатация ,сопровождение.
-Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Прототип — действующий компонент ПО, реализующий отдельные функции и внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней; уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются: риск превышения сроков и стоимости проекта; необходимость выполнения еще одной итерации; степень полноты и точности; понимания требований к системе; целесообразность прекращения проекта.
-Итерационная модель (инкрементая)
Итеративная модель предполагает разбиение жизненного цикла проекта на: последовательность итераций, каждая из которых напоминает "мини-проект", включая все фазы: жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.
42 Методы тестирования программ
Тестирование – это процесс выполнения программы с целью обнаружения ошибок. Существует 2 методики тестирования ПО:
По принципу белого ящика
По принципу черного ящика.
При любом виде тестирования тест должен определять свой набор исходных данных и условия для запуска программы, и набор ожидаемых результатов. Полную проверку программы обеспечивает только исчерпывающее тестирование, которое должно проверить все наборы возможных исходных данных, все варианты их обработки, что влечет за собой разработку большого числа всех вариантов. На практике исчерпывающее тестирование недопустимо из-за временных ограничений.
Хорошим считается тестовый вариант с высокой вероятностью обнаружения еще нераскрытой ошибки.
Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок. Т.о. тестирование должно обеспечивать:
Обнаружение ошибок.
Демонстрацию соответствия требований к характеристикам программ.
Демонстрацию реализаций функций и соответствие их назначению программы.
При
тестировании по
принципу черного ящика
известны функции программы. Тесты по
данному принципу должны демонстрировать,
как выполняются функции программы, как
применяются исходные данные, как
вырабатываются результаты и как
сохраняется целостность внешней
информации. При таком тестировании
игнорируется логическая структура.
Если в программе имеется 10 входных
величин и каждая может принимать по 10
значений, то для проверки потребуется
разработка 10
тестовых вариантов. Поэтому исчерпывающее
тестирование невозможно.
При тестировании по принципу белого ящика известна внутренняя структура программы. При таком тестировании проверяется корректность построения программы, элементы программы и связи. Исчерпывающее тестирование также затруднительно.
Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов графа управления программы. Т.е. тесты должны гарантировать проверки всех зависимых маршрутов программе, прохождение всех ветвей истина-ложь, выполнение всех циклов и анализ внутренней структуры данных.
Количество независимых маршрутов вычисляется по формуле.
n
– количество ветвей, к – количество
раз выполнения.
Тестирование по принципу белого ящика позволяет учесть особенности программных ошибок.
Нисходящее тестипрование.тестирование начинается с главного (или верхнего) модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых из уже протестированных. Одна из основных проблем, возникающих при нисходящем тестировании, -создание заглушек.
Основные достоинства нисходящего тестирования: уже на ранней стадии тестирования есть возможность получить работающий вариант разрабатываемой программы; быстро могут быть выявлены ошибки, связанные с организацией взаимодействие с пользователем.
Восходящее тестирование
При восходящем тестировании проверка программы начинается с терминальных модулей (т.е. тех, которые не вызывают не каких других модулей программы). Эта стратегия во многом противоположна нисходящему тестированию (в частности, преимущества становятся недостатками и наоборот).
Преимущества восходящего тестирования поскольку нет промежуточных модулей, нет проблем, связанных с возможностью или трудностью задания тестов; нет трудностей, вызывающих желание перейти к тестированию следующего модуля, не завершив проверки предыдущего.
Недостатком восходящего тестирования является то , что проверка всей структуры разрабатываемого программного комплекса возможна только на завершающей стадии тестирования.
Черный и белый ящик
"черного ящика" - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия. При этом как именно работает программа считается несущественным.
Белый ящик -Метод тестирования, которые изучают не только внешнее поведение программы, но и ее внутреннее устройство (исходные тексты).