Модели программного обеспечения и их роль в создании систем
Одна из основных проблем при создании больших и сложных систем, в том числе ПО, – это проблема сложности. Существуют следующие виды сложности:
● техническая сложность;
● сложность управления.
Техническая сложность может быть вызвана:
● структурной сложностью (большим количеством элементов и сложными взаимосвязями между ними);
● отсутствием полных аналогов, ограничивающим возможность использования типовых проектных решений и прикладных систем;
● необходимостью интеграции существующих и вновь разрабатываемых приложений;
● функционированием в неоднородной среде на нескольких аппаратных платформах;
● высокими требованиями к надежности и производительности.
Сложность управления порождается следующими причинами:
● сильное воздействие внешней среды (политика, экономическая ситуация, контракты, много заинтересованных лиц, противоречивые требования);
● большой коллектив разработчиков, много различных проектов и продуктов;
● разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и традициям использования инструментальных средств;
● значительная временная протяженность проекта.
Подход к решению проблемы сложности основан на принципе «разделяй и властвуй» (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-технология – это совокупность методов проектирования ПО и инструментальных средств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПО и разработки ПО.