Файл: Применение объектно -ориентированного подхода при проектировании информационной системы.pdf

Достоинства модели вариантов использования заключаются в том, что она:

-определяет пользователей и границы системы;

-определяет системный интерфейс;

-удобна для общения пользователей с разработчиками;

-используется для написания тестов;

-является основой для написания пользовательской документации;

-хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

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

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

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

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

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

---

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

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

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

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

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

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком. К его механизмам расширения относятся:

-стереотипы;

-тегированные (именованные) значения;

-ограничения.

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

---

Именованное значение - это пара строк "тег = значение", или "имя = содержимое", в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним и т.п.

Ограничение - это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML.

Общая диаграмма представлена в ПРИЛОЖЕНИИ 12 (рис.12), как они связаны между собой и что от чего отталкиваеться и зависит. В проектирование информацонных систем они играют непосредственную роль в формировании процессов и моделей проектирования.

1.3. Преимущества и недостатки объектно-ориентированного подхода к проектированию

Достоинства ООП:

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

- Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения.

- Эти механизмы разрешают конструировать трудные объекты из сравнимо обычных. В итоге значительно возрастает показатель повторного использования кодов и возникает возможность сотворения библиотек классов для разных применений.

Недостатки ООП обуславливаются следующим:

- Освоение базовых концепций ООП не требует значительных усилий. Однако разработка библиотек классов и их использование требуют существенных трудозатрат.

- Документирование классов – задача более трудная, чем это было в случае процедур и модулей.

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

- Код для обработки сообщения время от времени «размазан» по почти всем способам (по другому говоря, обработка сообщения просит не 1-го, а почти всех способов, которые могут быть описаны в различных классах).

Главной недочет ООП - некое понижение быстродействия за счет более трудной организации программной системы.

---

1.4. Основные принципы построения объектной модели. Основные элементы объектной модели

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

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

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

Преимущества объектной модели:

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

---

1. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных словно программирование. Страуструп отмечает: "Не всегда очевидно, как в полной мере использовать преимущества такого языка, как С++. Существенно повысить эффективность и качество кода можно просто за счет использования С++ в качестве "улучшившего С" с элементами абстракции данных. Однако намного более значительным достижением является введение иерархии классов в процессе проектирования. Именно это называется объектно-ориентированным проектированием и именно здесь преимущества С++ демонстрируются наилучшим образом". Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, С++, CLOS и Аdа, вне объектной модели, их наиболее сильные бока или игнорируются, или применяются неправильно.

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

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

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

5. Объектная модель ориентирована на человеческое восприятие мира, или, по словам Робсона, "много из людей, которые не имеют понятие о том, как работает компьютер, находят полностью естественным объектно-ориентированный подход к системам".

1.5. Объектно-ориентированный подход в проектировании информационных систем.

Объектно-ориентированнный подход в проектировании, как и функционально-ориентированный, предполагает декомпозицию ИС. Если в функционально-ориентированном подходе декомпозиции подлежали процессы обработки, то в объектно-ориентированном подходе декомпозиции подлежат объекты, которые характеризуются определенной структурой данных. Здесь декомпозиция идет от данных. В объектно-ориентированном подходе выделяют классы объектов. Каждый класс содержит однородные объекты. Объектам 1-го класса присуще однообразное огромное количество способов реагирования на наружные сообщения. Иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы– в виде взаимодействия объектов, обменивающихся сообщениями.

---