Ооп, введение в uml
Для любой простой программы можно построить функционально эквивалентную ей структурную программу, т.е. программу, сформированную на основе фиксированного базисного множества, включающего:
Недостатки структурного подхода -Данные не защищены от неправильного использования. -Расширение функциональных требований приводит
-Требование уникальности имен приводит
|
Основная идея: разбиваем сложную задачу на подзадачи, каждую из них при необходимости разбиваем снова и т.д. Получаем простые задачи, их решаем, объединяем. Модульное П/П – специфичный для задачи базис из модулей.
Недостатки модульного программирования Модули вынуждены модифицировать данные за пределами своей области видимости, что приводит к зависимости модулей (coupling) и сложности тестирования и сопровождения.
|
-Дальнейшая борьба со сложностью. -Технология работает, начиная с этапа анализа. -Анализ – Проектирование – Программирование. -В основе – объектная модель и объектная декомпозиция.
|
Модель есть упрощение исходного объекта Абстракция = выделение необходимых свойств объекта Необходимость набора свойств определяется решаемой задачей Однотипные объекты, обладающие одинаковыми наборами характеристик, объединяются в группы В ООП такие группы называются Классами Объект = экземпляр класса
|
А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение. Отделение внешних обязательств объекта от его реализации. Б) Сокрытие внутренней структуры данных и реализации методов объекта от остальной программы. Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие
|
Объект - этоэкземпляркласса. В качестве экземпляра класса объект обладает всеми характеристиками своего класса Наследовать могут не только объекты, но и классы. Наследование – уточнение задаваемого множества объектов. Более общий класс – «базовый» класс или «суперкласс». Более частный класс – наследник. Агрегация. имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности
|
«Один интерфейс – много реализаций» Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса. Виды полиморфизма:
Переопределение методов (override): в унаследованном классе можно переопределить метод базового класса. Перегрузка методов (overload): один и тот же класс может иметь методы с одинаковыми именами, но разными сигнатурами. -Перегрузку методов следует использовать, когда методы выполняющие подобные действия, могут принимать различные аргументы.
|
Компонентный подход – развитие объектно-ориентированной идеологии. Введен следующий уровень абстракции – классы объединяются в компоненты. Основной принцип компонентного подхода: сборка приложения из готовых компонент, в общем случае написанных на разных языках
|
(унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
|
Логические диаграммы, графический аппарат математической логики. Отношения между классами (объёмами понятий) с тех пор принято изображать с помощью систем взаимно пересекающихся кругов (или любых других односвязных областей); объединению классов соответствует при этом объединение изображающих их областей, пересечению — пересечение, дополнению (до универсального класса) — дополнение до некоторой "стандартной" объемлющей области. Отношению включения между изображаемыми классами при этом соответствует одноимённое отношение между их изображениями (причём случаи, когда объемлющий класс совпадает с объемлемым и когда он существенно шире последнего, здесь не различаются).
|
Служит для представления статической структуры модели системы Отражает взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений Не указывает информацию о динамике функционирования системы.
|
Внешний вид класса, объекта или модуля, выделяющий его существенные черты и не показывающий внутреннего устройства и внутренних механизмов поведения
|
-ассоциация (именованная связь) -зависимость (изменения в одном классе приводят к изменениям в другом) -обобщение / генерализация (родовидовое отношение) -агрегация (отношение «часть-целое») -композиция (отношение «часть-целое» », однозначно регламентирующее количество и состав частей целого)
|
Диаграммы пакетов унифицированного языка моделирования(UML) отображают зависимости между пакетами, составляющими модель. Диаграммы пакетов могут использовать пакеты, содержащие прецеденты для иллюстрации функциональности программного обеспечения системы. Диаграммы могут использовать пакеты, которые представляют различные слои программного комплекса для иллюстрации его слоистой архитектуры. Зависимости между этими пакетами могут быть снабжены метками / стереотипами, чтобы указать механизм связи между слоями. Диаграмма пакетов показывает пакеты и зависимости между ними. |
Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) — диаграмма, на которой отраженыотношения, существующие между акторами и прецедентами. Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю иразработчику совместно обсуждать функциональность и поведение системы. При работе с вариантами использования важно помнить несколько простых правил:
|
Основныекомпоненты описания системы: -Функции (действия) -Символы «старт» и «стоп» -Потоки управления -Разветвители -Линейки синхронизации Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности. Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями.
|
Основные компоненты описания системы: -Простые состояния, -Составные состояния, -Символы «старт» и «стоп», -Переходы, -Линейки синхронизации. Диаграмма состояний позволяет описать систему в более, чем одном варианте использования. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта. Событие
Переход
|
В первом случае взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности (sequencediagram). |
диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.Кооперация может быть представлена на двух уровнях:
Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во взаимодействии элементы. Кооперация на уровне спецификации изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации.
|
|
Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей:
|
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Она содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, ДР едина для системы в целом, поскольку должна всецело отражать особенности ее реализации. Цели, преследуемые при разработке диаграммы развертывания:
|