21. Табличная модель Хантера совмещения фаз жцп.

Табличная модель

иногда возникает проблема неравномерной загрузки... на разных этапах

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

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

фазы:

*исследование

*

*конструирование

*программирование

*оценка

*использование

большое влияние на эту модель имеют ... задачи

по этому ... задачи можно разделить на:

*несколько нерешенные

*существует частичное решение задачи

*несколько решений и хорошо изучена (клас. модель)

*практические решения есть, но хорошего обоснования нет(каскадная модель)

(программа может работать хоть и на большом, но на ограниченном интервале данных)

21. Итерационные эффекты в развитии программы.

22. Полный жизненный цикл программ (ПЖЦП). Подходы к прогнозированию трудоемкости программ.

если работа увеличивается в 2^n раз то количество человек, нужное для этого, увеличивается в 3^n раз.

для лучшего изучения задачи нужно сделать несколько попыток её решения.

1 попытка: попытка решить задачи

2 попытка: оценка границ, на которых задача решается

3 попытка: реализация ... программы

Остальные попытки нужны для выполнения каких-либо других условий.

21. Обоснование постановок задач и достоверность отчетов.

22. Уровень изученности решаемой задачи и технологичность.

23. Многократно используемые системы и компоненты программ.

24. Тестирование. Методы «черного» и «белого» ящика.

25. Конструирование систем тестов. Критерии полноты тестирования.

26. UML. Методы разработки программ и ИС в рамках OOP-технологий на базе стандартных языков программирования. Общая классификация.

27. UML. Основные виды диаграмм на уровне постановки задачи

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

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

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

диаграммы классов;

диаграммы объектов;

диаграммы компонентов;

диаграммы развертывания.

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

диаграммы прецедентов;

диаграммы последовательности;

диаграммы кооперации;

диаграммы состояний;

диаграммы деятельности.

Всего в языке UML определено девять типов диаграмм.

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

На Названия структурных диаграмм UML соответствуют названиям основных групп сущностей, используемых при моделировании системы:

диаграммы классов - классам, интерфейсам и кооперациям;

диаграммы объектов - объектам;

диаграммы компонентов - компонентам;

диаграммы развертывания - узлам.

Диаграммы поведения

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

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

диаграммы прецедентов описывают организацию поведения системы; D диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;

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

диаграммы состояний описывают изменение состояния системы в ответ на события;

диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.