Объектно-ориентированная методология 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Объектно-ориентированная методология



Концептуальной основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность, наследование) и понятия (класс, интерфейс, объект, атрибут сообщение) сформулированы Гради Бучем в его фундаментальной книге и последующих работах.

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

 

Язык UML

Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. Структуру UML составляет стандартный набор диаграмм и нотаций.

Главными в разработке UML были следующие цели:

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

• предусмотреть механизмы расширяемости базовых концепций языка;

• обеспечить независимость от конкретных языков программирования и процессов разработки.

• интегрировать лучший практический опыт.

В настоящее время UML находится в процессе стандартизации, проводимом организацией по стандартизации в области объектно-ориентированных методов и технологий (OMG - Object Management Group).

Язык UML имеет три основных разновидности понятий: сущности (или предметы), отношения, диаграммы (слайд 9).

Сущности (предметы) – это абстракции, которые являются основными элементами UML-модели. В UML определено четыре разновидности сущностей:

• структурные – представляют статические части моделей (понятийные или физические элементы);

• поведенческие – динамические части моделей, представляющие поведения во времени и пространстве;

• группирующие – организационные части моделей (ящики, по которым может быть разложена модель);

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

Отношения – основные связующие строительные блоки при построении UML-модели. Четыре базовых отношения, их графические представления и описания приведены в таблице (слайд 10).

10.2.2. Диаграммы UML

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

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

Рассмотрим нотации вершин и ребер графа диаграммы классов для простого случая, когда диаграмма показывает классы и отношения между ними.

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

Ребра графа диаграммы – ассоциация, агрегация, обобщение и зависимость.

Необязательное имя ассоциации может описывать природу отношений. Имени можно придать направление (►), заданное для чтения имени. Класс, участвующий в ассоциации, играет в ней определенную роль. Роли классов могут быть указаны на концах ассоциации. Мощность ассоциации определяет количество объектов, соединяемых с каждым объектом на другом конце ассоциации, например:

• * - неограниченное количество;

• 1..* - один или более;

• 0..* - ноль или более;

• 1..10 – заданный диапазон;

• 7 – точное количество.

Агрегация (разновидность ассоциации) - определяет отношение «часть – целое». При этом агрегирующая сущность содержит только указатели на части.

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

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

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

Диаграмма прецедентов (слайд 1 2). Диаграмма прецедентов (Use Case, диаграмма вариантов использования) определяет поведение системы и отражает функциональные требования к системе с точки зрения пользователя. Цель построения диаграмм прецедентов - документирование функциональных требований к системе в самом общем виде. Диаграмма должна быть удобна для общения пользователей с разработчиками.

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

Вершинами графа диаграммы являются актеры и прецеденты.

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

Прецедент (элемент Use Case)– описание последовательности действий, которые выполняются системой и производят для актера видимый результат. Каждый прецедент задает определенный способ использования системы. Совокупность всех прецедентов определяет полный набор функциональных возможностей системы.

Ребра графа диаграммы – ассоциация, обобщение, включение, расширение.

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

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

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

Расширение – отношение между прецедентами, означающее, что базовый прецедент неявно включает поведение включаемого прецедента. Базовый прецедент может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого прецедента (но только в заданных точках – точках расширения.

 


Лекция 11 (DB _ l 11. ppt).



Поделиться:


Последнее изменение этой страницы: 2021-12-07; просмотров: 42; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.216.239.46 (0.01 с.)