Конспект лекций, страница 4

МОДЕЛИ ИОБЪЕКТНАЯ МОДЕЛЬИХРОЛЬВСОЗДАНИИСИСТЕМ.Одна из основных проблем при создании больших и сложных систем, в том числеПО, – это проблема сложности. Виды сложности: техническая сложность и сложностьуправления. Техническая сложность может быть вызвана: структурной сложностью (большим количеством элементов и сложнымивзаимосвязями между ними); отсутствием полных аналогов, ограничивающее возможность использования типовыхпроектных решений и прикладных систем; необходимостью интеграции существующих и вновь разрабатываемых приложений; функционированием в неоднородной среде на нескольких аппаратных платформах; высокими требованиями к надежности и производительности.Сложность управления порождается следующими причинами: сильное воздействие внешней среды (политика, экономическая ситуация, контракты,много заинтересованных лиц, противоречивые требования); большой коллектив разработчиков, много различных проектов и продуктов; разобщенность и разнородность отдельных групп разработчиков по уровнюквалификации и традициям использования инструментальных средств; значительная временная протяженность проекта.Подход к решению этой проблемы основан на принципе «разделяй и властвуй»(divide et impera).

Сложная программная система должна быть разделена на небольшиеподсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) отдругих. Декомпозиция является главным способом преодоления сложности разработкиПО. Принципы декомпозиции: количество связей между подсистемами должно быть минимальным(«низкаясвязанность» или «слабое зацепление» – Low Coupling); степень взаимодействия внутри каждой подсистемы должна быть максимальной(«сильная связность» или «высокая прочность» – High Cohesion).При разбиении системы на подсистемы необходимо выполнить следующиетребования: каждая подсистема должна инкапсулировать свое содержимое (скрывать его от другихподсистем); каждая подсистема должна иметь четко определенный интерфейс с другимиподсистемами, устанавливающий стандартные ограничения на взаимодействие.Следование этим правилам увеличивает понятность и модифицируемостьсоздаваемого ПО.Два основных подхода к декомпозиции систем: функционально-модульный,основанный на функциональной декомпозиции, при которой структура системыописывается в терминах иерархии ее функций и иерархии структур данных; объектноориентированный, использующий объектную декомпозицию, при которой структурасистемы описывается в терминах объектов и связей между ними, а поведение системыописывается в терминах обмена сообщениями между объектами.

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

Различные представления архитектуры служат различнымцелям (модель «4+1»): представление функциональных возможностей ПО (представление вариантовиспользования, содержащее сценарии взаимодействия системы с внешней средойи роли, которые играют пользователи ПО и внешние системы); представление логической организации ПО (логическое представление, элементамикоторого являются пакеты, подсистемы, классы, связи между ними); представление физической структуры программных компонент, входящих в состав ПО(представление реализации, элементами которого являются компоненты, связи междуними); представление структуры потоков управления и аспектов параллельной работы ПО(представление процессов, элементы которого: потоки управления, нити, параллелизм,синхронизация); описание физического размещения компонент ПО по узлам вычислительной системы(представление размещения, элементы которого: узлы вычислительной системы,устройства, линии связи, задачи).ЛогическоепредставлениеАналитик, разработчикСтруктураПредставлениепроцессовПредставлениереализацииПредставлениевариантовиспользованияПользовательФункциональностьСистемный интеграторПроизводительностьМасштабируемостьПропускная способностьПрограммистУправление ПОПредставлениеразмещенияСистемный инженерТопология системыВнедрение, инсталляцияКоммуникацияСреди 5-ти представлений особое место занимает представление вариантовиспользования, поскольку оно используется при управлении разработкой, служит своегорода скелетом проекта.Каждое архитектурное представление – это модель системы с определенной точкизрения, в которой отражены лишь существенные аспекты и опущено все, чтонесущественно при данном взгляде на систему.Модель ПО – это формализованное описание системы ПО на определенном уровнеабстракции.

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

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

Графические модели образуют внешнее представление системы и объясняют, что этасистема будет делать, тем самым облегчают общение с заказчиком.3. Графические модели облегчают изучение методов проектирования, в частностиобъектно-ориентированных методов.В процессе создания ПО используются следующие виды моделей: модели деятельности организации (или модели бизнес-процессов):o модели "AS-IS" ("как есть"), отражающие существующее положение;o модели "AS-TO-BE" ("как должно быть"), отражающие представление о новыхпроцессах и технологиях работы организации; модели проектируемого ПО, которые строятся на основе модели "AS-TO-BE",уточняются и детализируются до необходимого уровня.Состав моделей, используемых в каждом конкретном проекте, и степень ихдетальности в общем случае зависят от следующих факторов: сложности проектируемойсистемы; необходимой полноты ее описания; знаний и навыков участников проекта;времени, отведенного на проектирование.Для облегчения труда разработчиков и автоматизированного выполнения некоторыхрутинных действий используются CASE-средства (Computer Aided Software Engineering).В настоящее время CASE-средства обеспечивают поддержку большинства процессовжизненного цикла ПО, что позволяет говорить о CASE-технологиях разработки ПО.CASE-технология – это совокупность методов проектирования ПО и инструментальныхсредств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПОи разработки ПО.Объектная модель является концептуальной базой объектно-ориентированногоподхода (ООП).Проблемы, стимулировавшие развитие ООП: Необходимость повышения производительности разработки за счет многократного(повторного) использования ПО. Необходимость упрощения сопровождения и модификации разработанных систем(локализация вносимых изменений). Облегчение проектирования систем (за счет сокращения семантического разрывамежду структурой решаемых задач и структурой ПО).3Забегая вперед, скажем, какие решения данных проблем дает ООП.