Лекция модели и их роль в создании систем. Объектная модель



страница1/10
Дата17.12.2017
Размер3,22 Mb.
  1   2   3   4   5   6   7   8   9   10

Лекция 2. МОДЕЛИ И ИХ РОЛЬ В СОЗДАНИИ СИСТЕМ. ОБЪЕКТНАЯ МОДЕЛЬ


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

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

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

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

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

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

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

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

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

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

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

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

  • количество связей между подсистемами должно быть минимальным («низкая связанность» или «слабое зацепление» – Low Coupling);

  • степень взаимодействия внутри каждой подсистемы должна быть максимальной («сильная связность» или «высокая прочность» – High Cohesion).

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

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

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

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

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



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

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

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

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

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

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

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

  • представление логической организации ПО (логическое представление, элементами которого являются пакеты, подсистемы, классы, связи между ними);

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

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

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

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

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



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

Гради Буч:



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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

Объектная модель является концептуальной базой объектно-ориентированного подхода (ООП).

Проблемы, стимулировавшие развитие ООП:



  • Необходимость повышения производительности разработки за счет многократного (повторного) использования ПО.

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

  • Облегчение проектирования систем (за счет сокращения семантического разрыва между структурой решаемых задач и структурой ПО).

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

Краткая история ООП:



  • 1967: язык Simula – 1ый среди объектно ориентированных;

  • 1970-е: Smalltalk – получил довольно широкое распространение;

  • 1980-е: Теоретические основы, C++, Objective-C;

  • 1990-е: Методы OOA и OOD (Booch, OMT, ....), появился язык Java;

  • 1997: Принят стандарт OMG UML 1.1.

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

О


Поделитесь с Вашими друзьями:
  1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©grazit.ru 2017
обратиться к администрации

    Главная страница