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

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

• совокупность структурных элементов системы и связей между ними;

• поведение элементов системы в процессе их взаимодействия;

• иерархию подсистем, объединяющих структурные элементы;

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

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

• планы этажей;

• вертикальные проекции;

• планы монтажа кабельной проводки;

• чертежи водопроводов, системы центрального отопления и вентиляции;

• вид здания на фоне местности (эскизы).

Архитектура ПО также предусматривает различные представления, служащие разным целям:

• представлению функциональных возможностей системы;

• отображению логической организации системы;

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

• отображению структуры потоков управления и аспектов параллельной работы;

• описанию физического размещения программных компонентов на базовой платформе.

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

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

Язык моделирования включает:

• элементы модели — фундаментальные концепции моделирования и их семантику;

• нотацию (систему обозначений) — визуальное представление элементов моделирования;

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

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

В процессе создания ПО, автоматизирующего деятельность некоторой организации, используются следующие виды моделей:

* модели деятельности организации (или модели бизнес-процессов): модели «AS-IS» («как есть»), отражающие существующее на момент обследования положение дел в организации и позволяющие понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

* модели «AS-TO-BE» («как должно быть»), отражающие представление о новых процессах и технологиях работы организации.

Переход от модели «AS-IS» к модели «AS-TO-BE» может выполняться двумя способами: 1) совершенствованием существующих технологий на основе оценки их эффективности; 2) радикальным изменением технологий и перепроектированием (реинжинирингом) бизнес-процессов.

* модели проектируемого ПО, которые строятся на основе модели «AS-TO-BE», уточняются и детализируются до необходимого уровня.

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

• сложности проектируемой системы;

• необходимой полноты ее описания;

• знаний и навыков участников проекта;

• времени, отведенного на проектирование.

39 Понятие, разновидности и характеристика моделей жизненного цикла программного обеспечения.

ЖЦ ПО определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Выделяют этапы:

-1- возникновение и исследование идеи;

-2- анализ требований и проектирование;

-3- программирование;

-4- тестирование и отладка;

-5- ввод программы в действие;

-6- эксплуатация и сопровождение;

-7- завершение эксплуатации.

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

моделях жизненного цикла:

• Каскадная (водопадная) или последовательная

• Итеративная и инкрементальная – эволюционная (гибридная, смешанная)

• Спиральная (spiral) или модель Боэма

Каскадная модель. Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.

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

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.