Модели программного обеспечения и их роль в создании систем

Одна из основных проблем при создании больших и сложных систем, в том числе ПО, – это проблема сложности. Существуют следующие виды сложности:

● техническая сложность;

● сложность управления.

Техническая сложность может быть вызвана:

● структурной сложностью (большим количеством элементов и сложными взаимосвязями между ними);

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

● необходимостью интеграции существующих и вновь разрабатываемых приложений;

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

● высокими требованиями к надежности и производительности.

Сложность управления порождается следующими причинами:

● сильное воздействие внешней среды (политика, экономическая ситуация, контракты, много заинтересованных лиц, противоречивые требования);

● большой коллектив разработчиков, много различных проектов и продуктов;

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

● значительная временная протяженность проекта.

Подход к решению проблемы сложности основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО.

Принципы декомпозиции:

● слабая связанность – low coupling (количество связей между отдельными подсистемами должно быть минимальным);

● сильное сцепление – high cohesion (связность отдельных частей внутри каждой подсистемы должна быть максимальной).

При разбиении системы на подсистемы необходимо выполнить следующие требования:

● каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

● каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами;

● взаимодействия между подсистемами должны укладываться в ограниченные, стандартные рамки (например, по принципу клиент-сервер).

Следование этим правилам увеличивает понятность и модифицируемость создаваемого ПО.

Существует два основных подхода к декомпозиции систем:

● функционально-модульный, основанный на функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и иерархии структур данных;

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

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

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

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

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

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

Архитектура ПО многомерна, поскольку различные специалисты работают с её различными аспектами. Различные представления архитектуры служат различным целям (модель «4+1») (рис. 2.2.):

● представление функциональных возможностей ПО (представление вариантов использования);

● представление логической организации ПО (логическое представление);

● представление физической структуры программных компонент, входящих в состав ПО (представление реализации);

● представление структуры потоков управления и аспектов параллельной работы ПО (представление процессов);

● описание физического размещения компонент ПО по узлам вычислительной системы (представление размещения).

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

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

Рисунок 2.2.. Архитектурные представления системы

Гради Буч:«Моделирование является центральным звеном всей деятельности по созданию качественного ПО. Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.»

Архитектурно значимый элемент – это элемент, значительно влияющий на структуру системы, её функциональность, производительность, надежность, защищенность, возможность развития. Подсистемы, их интерфейсы, процессы и потоки управления являются архитектурно значимыми элементами.

Среди 5-ти представлений особое место занимает представление вариантов использования, поскольку оно используется при управлении разработкой, служит своего рода скелетом проекта.

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

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

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

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

● Графические модели образуют внешнее представление системы и объясняют, что эта система будет делать, тем самым облегчают общение с заказчиком.

● Графические модели облегчают изучение методов проектирования, в частности объектно-ориентированных методов.

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

● модели деятельности организации (или модели бизнес-процессов):

● модели "AS-IS" ("как есть"), отражающие существующее положение;

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-05