Categorie: Tutti - проектирование - программирование - интерфейс

da Мальцев Евгений mancano 6 anni

516

МиСПИСиТ-Тема3

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

МиСПИСиТ-Тема3

Проектирование ИС. Основные подходы и модели

Введение в UML

Что нового в UML

Цели UC D:

  1. Определить границы и контекст моделируемой предметной области на начальных этапах проектирования системы
  2. Сформулировать общие требования к функционированию проектируемой системы
  3. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей Подготовить начальную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. 
  1. Служит для представления и документирования статической структуры модели системы
  2. Отражает взаимосвязи между отдельными сущностями предметной области, такими как классы и подсистемы, а также описывает их внутреннюю структуру и типы отношений
  3. Не указывает информацию о динамике функционирования системы.

Является экземпляром диаграммы классов

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


Диаграмма реализации

Диаграммы реализации (implementation diagrams)


Диаграмма развертывания (deployment diagram)

Предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime)

Представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками

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

Цели диаграммы развертывания

Узел (node) 

Отношения между узлами

физические соединения между узлами и зависимости между узлами и компонентами

Соединения 

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

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

Зависимости

Это - альтернатива вложенному изображению компонентов внутри символа узла, что не всегда удобно

Диаграмма компонентов (component diagram)

Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления 

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

Цели диаграммы компонентов:

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

Во многих средах разработки модуль или компонент соответствует файлу

Основные графические элементы диаграммы компонентов – компоненты, интерфейсы и зависимости между ними. 

Компонент (component).

Виды компонентов

 1. Компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций:

– (а)динамически подключаемые библиотеки (dll)

– (б) web-страницы (html),

– (в) файлы справки (hlp).

2. (г) Компоненты-рабочие продукты. Как правило - это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++

3. Компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе. Они обозначаются обычным образом. 

Зависимости и реализации


Диаграмма поведения

-Диаграмма последовательности (sequence diagram)

-Диаграмма кооперации (collaboration diagram)

Диаграммы взаимодействия (interaction diagrams)

Диаграмма кооперации (collaboration diagram)

Кооперация - одно из фундаментальных понятий UML.

Предназначена для спецификации структурных аспектов взаимодействия.

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

Цель кооперации – специфицировать особенности реализации отдельных наиболее значимых операций в системе.

Уровни представления кооперации

Диаграмма кооперации уровня спецификации

Диаграмма кооперации уровня примеров


Диаграмма последовательности (sequence diagram)

Фокус управления

Сообщения

Внутреннее поведение (диаграммы состояний и деятельности)

Список основных действий включает следующие значения: 

Диаграмма состояний (statechart diagram)

State chart Diagram (ScD)

Основные компоненты описания системы:

Состояние 

Событие

Переход

SCD - Составное состояние

-между подчинёнными состояниями,

-между подчинённым и внешним состояниями и

-переходы между составным и внешним состоянием.

Диаграмма деятельности (activity diagram)

Activity Diagram


Структура последовательного выполнения

Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности.

Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями.


Структура параллельного выполнения


Использование дорожек.

UML предлагает вариант с «плавательными дорожками». Это удобно, когда в варианте использования участвуют несколько акторов.

Диаграмма объектов UML
Диаграмма вариантов использования

Диаграмма вариантов использования (Use Case Diagram)

Цели UCD

Цели UCD (Use Case Diagram):

SWEBOK. Область знаний «Проектирование ПО»

Типовые решения в проектировании ПО

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

В связи с тем, что контексты, в которых данная проблема решалась, могут различаются

– (другой тип приложения, другая платформа или другой язык программирования),

– все обычно заканчивается повторением проектирования и реализации данного решения,

– тем самым возникает ситуация «повторного изобретения колеса».

Преимущества "Расслоения"
Эталонная трехслойная модель
Иерархия типовых решений

1. Архитектурные стили (шаблоны архитектуры) - п. 3.2 в Swebook

– Описывают фундаментальные способы структурирования программных систем.

– Относятся к уровню систем и подсистем, а не классов

2. Шаблоны проектирования - п. 3.3 в Swebook

– Описывают структуру программных систем в терминах классов и объектов

3. Идиомы, специфичные для конкретного языка программирования.

Зачем нужны шаблоны:

Опредение

Шаблон – это описание хорошо проверенной, обобщенной схемы решения некоторой часто повторяющейся проблемы (задачи) разработки ПО, которая возникает в некоторых специфических условиях (контексте) 

Схема решения проблемы задается путем:

– определения используемых (составляющих) компонент;

– их ответственностей;

– способов их взаимодействия.

Паттерны

Паттерн проектирования ПО – это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте [GoF]

Следует отличать паттерны проектирования от идиом.

– Паттерны проектирования не зависят от выбора языка (хотя их реализации, зачастую, зависимы от языка программирования).

– Идиомы — это паттерны, описывающие типичные решения на конкретном языке программирования.


В общем случае каждый паттерн состоит из таких составляющих:

  1. Имя является уникальным идентификатором паттерна. Имена паттернов проектирования, описанных в [GoF], являются общепринятыми.
  2. Задача описывает ситуацию, в которой можно применять паттерн.
  3. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними.
  4. Результаты представляют следствия применения паттерна. 

Классификация шаблонов Gamma и др

Критерии классификации

Паттерны проектирования различаются степенью детализации и уровнем абстракции

Паттерны можно классифицировать по двум критериям :

– Цель -- отражает назначение паттерна.

– Уровень -- говорит о том, к чему обычно применяется паттерн.

Классификация архитектурных стилей Show&Garlan

Классификация архитектурных стилей Show&Garlan

– Последовательные пакеты

– Каналы и фильтры

Обрабатывающие модули ждут данных, чтобы начать свою работу

–Каждый процесс обработки данных проектируется независимо

–Данные поступают, обрабатываются и передаются.

Состоит из компонент, работающих независимо и обменивающихся между собой информацией

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

– Клиент-серверные системы

– Системы, управляемые событиями.


Классификация по целям и уровням паттернов проектирования

Классификация паттернов по целям:

  1. Порождающие паттерны (Creational Patterns). – Определяют способы создания объектов в системе.
  2. Структурные паттерны (Structural Patterns). – Описывают способы построение сложных структур из классов и объектов.
  3. Поведенческие паттерны (Behavioral Patterns). – Описывают способы взаимодействия между объектами.

Классификация паттернов по уровням:

уровень - говорит о том, к чему обычно применяется паттерн:

– уровень классов - описывают отношения между классами и их подклассами.

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

 

Появление паттернов

Идея паттернов проектирования первоначально возникла в архитектуре. 

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

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

В 1987 году Кент Бэк (Kent Beck) и Вард Каннигем (Ward Cunningham) разработали шаблоны разработки ПО для графических оболочек на языке Smalltalk

В 1991 году Эрих Гамма совместно с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидсом (John Vlissides) публикует книгу «Design Patterns — Elements of Reusable Object-Oriented Software» [GoF91]. 

– Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования.» - СПб: Питер, 2001. - 386 с.

В этой книге описаны 23 паттерна проектирования. 

Мэри Шоу (Mary Shaw), Дэвид Гарлан (David Garlan), 1996 Опубликовали книгу «Архитектура программного обеспечения» – классификация архитектурных стилей; 

Мартин Фаулер (Martin Fowler) опубликовал книгу «Архитектура корпоративных программных приложений» - типовые решения при разработке КИС, – Например, работа с базами данных, транзакциями и т.п.;

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

После начала активного использования модульного тестирования (Unit Testing) программного кода все паттерны при этом были переосмыслены с позиций тестируемости.

Шаблоны проектирования

Шаблоны проектирования это шаблоны среднего уровня.

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

Применение шаблонов проектирования не влияет на базовую структуру ПС, но может оказать сильное влияние на архитектуру подсистем.

Шаблоны Архитектуры ПО

Влияют на:

– коммуникацию и взаимодействие между разными частями системы;

– их последующее расширение.

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

– Например, адаптируемости пользовательского интерфейса.


Примеры архитектурных шаблонов

  1. Layers (Уровни),
  2. Pipes and Filters (каналы и фильтры),
  3. Blackboard (информационная "доска"),
  4. Broker (брокер),
  5. Model-View-Controller (Модель- Представление-Контроллер), Presentation-Abstraction-Control (Представление-Абстракция-Контроллер),
  6. Microkernel (микроядро),
  7. Reflection (отражение).

Шаблоны для архитектур

Клиент-серверная архитектура

Архитектура параллельно взаимодействующих процессов

Репозиторные архитектуры 

– Базы данных

– Гипертекстовые системы

– Доски объявлений 

Уровневые архитектуры 


Свойства шаблонов

Свойства:

  1. Описывают решения для часто повторяющихся задач проектирования, которая возникают в некоторых специфических ситуациях
  2. Документируют накопленный, хорошо зарекомендовавший себя опыт проектирования
  3. Определяют абстракции, которые находятся на более высоком уровне, чем уровень отдельных классов и экземпляров или компонентов
  4. Предоставляют общий словарь терминов и общее понимание принципов проектирования. 
Причины возникновения типовых решений в проектировании ПО

В конце 80-х годов XX века в области разработки ПО (в частности, ОО проектировании) накопилось много различных похожих по своей сути решений.

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

Такое упорядочение знаний в ОО проектировании позволило бы повторно использовать готовые и уже проверенные решения.

Решение данной проблемы взяли на себя шаблоны (паттерны) проектирования.

Стиль мышления эксперта

Действия эксперта:

– вспоминают аналогичную проблему, которую они уже решали,

– стараются повторно используют суть ранее принятого решения для решения новой проблемы.

– архитектура;

– экономика;

– программная инженерия.

Кристофер Александер:

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


Дополнительные области SWEBOK
  1. Конфигурационное управление

1.1. Управление процессами

1.2. Идентификация конфигураций

1.3. Контроль конфигураций

1.4. Отчетность по статусу конфигураций

1.5. Конфигурационные аудит

1.6 Конфигурационный аудит

1.7. Управление выпуском ПО и развертывание

2. Управление инженерной деятельностью

2.1. Инициирование и определение содержания

2.2. Планирование проектов

2.3. Проектные работы (реализация плана)

2.4. Обзор и оценка

2.5. Закрытие (работ)

2.6. Количественная оценка инженерной деятельности

3. Процессы инженерной деятельности

3.1. Реализация и изменение процессов

3.2. Определение процессов

3.3. Оценка процессов

3.4. Измерение процессов и продуктов

4.Инженерные инструменты и методы

4.1. Программные инструменты

4.1.1. Управление требованиями

4.1.2. Проектирование

4.1.3. Конструирование

4.1.4. Тестирование

4.1.5. Сопровождение

4.1.6. Конфигурационное управление

4.1.7. Управление инженерной деятельностю

4.1.8. Поддержка инженерных процессов

4.1.9. Обеспечением качества

4.1.10. Другие инструменты

4.2. Методы программной инженерии

4.2.1. Эвристические методы

4.2.2. Формальные методы

4.2.3. Методы прототипирования

5. Качество

5.1. Основы качества

5.2. Процессы управления качеством

5.3. Практические соображения

Основные области SWEBOK
  1. Требования

1.1. Основы требований

1.2. Процесс

1.3.Извлечение требований

1.4. Анализ требований

1.5. Спецификация требований

1.6. Утверждение требований

1.7. Практические требования

2. Проектирование

2.1. Основы проектирования

2.2. Ключевые вопросы проектирования

2.3. Структура и архитектура

2.4. Анализ качества и оценка дизайна

2.5. Нотации дизайна

2.6. Стратегии и методы проектирования

3. Конструирование

3.1. Основы конструирования

3.2. Управление конструированием

3.3. Практические соображения

4. Тестирование

4.1. Основы тестирования

4.2. Уровни тестирования

4.3. Техники тестирования

4.4. Метрики, связанные с тестированием

4.5. Процесс тестирования

5. Поддержка и эксплуатация

5.1. Основы поддержки и эксплуатации

5.2. Ключевые вопросы поддержки и эксплуатации

5.3. Процесс

5.4. Техники

Проектирование ПО

1. Основы проектирования

1.1. Общие концепции проектирования

1.2. Контекст проектирования ПО

1.3. Процесс проектирования ПО

1.4. Принципы проектирования ПО

2. Ключевые вопросы проектирования

3. Структура и архитектура ПО

4. Анализ качества и оценка результатов проектирования

5. Нотации проектирования ПО

6. Стратегии и методы проектирования ПО

Артефакты проектирования

Свойства класса проектирования

  1. Язык
  2. Видимость
  3. Семантика отношений, отображение на атрибуты
  4. Методы, отображение на методы
  5. Отложенные решения: требования к реализации класса
  6. Класс может быть реализован в виде интерфейса ЯП
  7. Класс может быть активным

Содержит:

– Диаграммы классов

– Диаграммы взаимодействий

– Текстовое описание потока событий

– Требования к реализации

Стратегии и методы проектирования ПО

  1. Общие стратегии (General Strategies)

2. Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design)

3. Объектно-ориентированное проектирование (Object-Oriented Design)

4. Проектирование на основе структур данных (DataStructure-Centered Design)

5. Компонентное проектирование (Component-Based Design)

Нотации проектирования

  1. Структурные описания, статический взгляд (Structural Descriptions, static view)

2. Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)

Анализ качества и оценка результатов

Анализ качества и оценка результатов проектирования ПО (Software Design Quality Analysis and Evaluation)

  1. Атрибуты качества (Quality Attributes)
  2. Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)
  3. Измерения (Measures).

Атрибуты качества

Анализ качества и техники оценки

Измерения (метрики)

  1. функционально-ориентированные
  2. объектно-ориентированные


Структура и архитектура ПО

1. Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)

2. Архитектурные стили (Architectural Styles)

3. Шаблоны проектирования (Design Patterns)

4. Семейства программ и фреймворков (Families of Programs and Frameworks)


Шаблоны

Шаблон (образец, паттерн) – найденная опытным путем комбинация компонентов (обычно, классов или объектов), решающая общие задачи проектирования

Применяется как на стадии архитектурного, так и детального проектирования.

Архитектурные стили

Архитектурные стили

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

Классификация архитектур

23 базовых шаблона

Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton

Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, façade, flyweight, proxy

Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor

  1. Архитектура потоков данных
  2. Независимые компоненты
  3. Виртуальные машины
  4. Репозиторные архитектуры

Виды репозиторных архитектур:

– Базы данных

– Гипертекстовые системы

– Доски объявлений

Шаблон «Iterator»

5. Уровневые архитектуры.

– Последовательные пакеты – Каналы и фильтры

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

Обрабатывающие модули ждут данных, чтобы начать свою работу

Состоит из компонент, работающих независимо и обменивающихся между собой информацией

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

Параллельный запуск нескольких процессов (потоков, нитей). Шаблон «Observer» (наблюдатель)

– Клиент-серверные системы

Серверы обслуживают клиентов с помощью запросов

Низкое сцепление между компонентами

«Узкий» интерфейс

Шаблон «Facade»

– Системы, управляемые событиями.

Уровень = Слой (Layer)

Видимость «сверху вниз»

Инкапсуляция внутренних слоев

Высокая степень автономности слоев

Количество уровней

Особенности реализации уровней.





Точки зрения

Точки зрения

Любая система может рассматриваться с разных точек зрения – например,


Ключевые вопросы проектирования

  1. Параллелизм (Concurrency)

2. Контроль и обработка событий (Control and Handling of Events)

3. Распределение компонентов (Distribution of Components)

4. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance )

5. Взаимодействие и представление (Interaction and Presentation)

6. Сохраняемость данных (Data Persistence).

Суть вопроса – поиск “долгоживущих” объектов (структур данных) и их отображение на базу данных.

Основы проектирования

Основы проектирования ПО

1.1. Общие концепции проектирования

1.2. Контекст проектирования ПО

1.3. Процесс проектирования ПО

1.4. Принципы проектирования ПО

Принципы проектирования ПО

  1. Абстракция (Abstraction)
  2. Связанность и связанность (Coupling and Cohesion)
  3. Декомпозиция и разбиение на модули (Decomposition and Modularization)
  4. Инкапсуляция/сокрытие информации (Encapsulation/information hiding)
  5. Разделение интерфейса и реализации (Separation of interface and implementation)
  6. Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)


Достаточность, полнота и простота

Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

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

То есть не включают функциональность, отсутствующую в модели.

Данный принципy наиболее ярко представлен в гибких (agile) подходах к разработке ПО через метафору YAGNI

“You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

Разделение интерфейса и реализации

Разделение интерфейса и реализации (Separation of interface and implementation)

Данная техника предполагает определение компонента через специфицирование интерфейса, который: известен (описан) , доступен клиентам (или другим компонентам), независим от непосредственных деталей реализации.

Инкапсуляция/сокрытие информации

Инкапсуляция/сокрытие информации (Encapsulation/information hiding)

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

Декомпозиция и разбиение на модули

Декомпозиция и разбиение на модули (Decomposition and Modularization)


Связанность и связанность

Связанность и связанность (Coupling and Cohesion)

Абстракция (Abstraction)

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

Диаграмма классов UML (class diagram)
Именование класса

Основные отношения между классами

Строки-ограничения для отношения обобщения

{complete} - указаны все классы-потомки, и других потомков быть не может.

{incomplete} - противоположный случай

{disjoint} - классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.

{overlapping} - отдельные экземпляры классов- потомков могут принадлежать одновременно нескольким классам

Обобщение (generalization relationship)

между более общим элементом (предком) и более частным или специальным элементом (потомком)

Композиция (composition relationship)

Агрегация (aggregation relationship)

Ассоциация (association relationship)

Исключающая ассоциация

Из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр.

n-арная ассоциация

Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж значений объектов из соответствующих классов

Интерфейс

Внешний вид класса, объекта или модуля, выделяющий его существенные черты и не показывающий внутреннего устройства и внутренних механизмов поведения


А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение.

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


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

Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие

Объекты

Поведение объекта

"Война методов"

1980е – начало 90х – гг.

OOSE – средства представления вариантов использования

ОМТ-2 –анализ процессов обработки данных в информационных системах

Booch'93 – нашел наибольшее применение на этапах проектирования и разработки различных программных систем. 

UML

Unified Modeling Language

Де-факто и де-юре стандартный язык моделирования в современной ИТ-индустрии


Представления сложной системы в UML

Диаграмма вариантов использования (use case diagram) 

–Диаграмма состояний (statechart diagram)

–Диаграмма деятельности (activity diagram)

–Диаграммы взаимодействия (interaction diagrams):

Диаграмма последовательности (sequence diagram)

Диаграмма кооперации (collaboration diagram)

–Диаграмма компонентов (component diagram)

–Диаграмма развертывания (deployment diagram) 

Назначение UML
Диаграмма классов UML

Диаграмма классов UML (class diagram)

Служит для представления статической структуры модели системы

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

Не указывает информацию о динамике функционирования системы.

Именование классов


Основные отношения между классами

Основные отношения между классами:

Отношение зависимости (dependency relationship): Возникает, когда один класс использует другой. Используется, когда изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели

Ассоциация (association relationship)

n-арная ассоциация - Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж значений объектов из соответствующих классов

Исключающая ассоциация - из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. 

Агрегация (aggregation relationship) -имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности

Композиция (composition relationship) - частный случай агрегации. Части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части

Обобщение (generalization relationship) - между более общим элементом (предком) и более частным или специальным элементом (потомком)



Краткая история UML
Объектно-ориентированное программирование (ООП)
Истоки ООП
Технологии Программирования/Проектирования (П/П)
Компонентное П\П

Компонентный подход – развитие объектно- ориентированной идеологии;

Введен следующий уровень абстракции – классы объединяются в компоненты;

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

Компонент:

– программный код в виде самостоятельного модуля

– м.б. использован в неизменном виде

– может допускать настройку

– обладает поведением (функциональностью)

Компонент изолирован от внешнего мира своим интерфейсом – набором методов (их сигнатурами)

Компонентная программа – набор независимых компонент, связанных друг с другом посредством интерфейсов.

Объектно-ориентированное П\П

Основные принципы объектной модели:

– абстракция;

– инкапсуляция;

– иерархичность (наследование, агрегация);

– полиморфизм;

– модульность

Объектная декомпозиция (в отличие от алгоритмической): элементы проекта – классы и объекты (а не алгоритмы). Затем – детализация (данные и алгоритмы).


Инкапсуляция

А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение. Отделение внешних обязательств объекта от его реализации

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

Абстракция

Полиморфизм

«Один интерфейс – много реализаций»

Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса.

Виды полиморфизма:


Наследование

Модульное П\П

Основная идея: разбиваем сложную задачу на подзадачи, каждую из них при необходимости разбиваем снова и т.д.;

Получаем простые задачи, их решаем, объединяем.

Модульное П/П – специфичный для задачи базис из модулей.

– Более высокий уровень абстракции.

– Настройка на конкретную задачу.

– Возможности повторного использования.

– Возможности коллективной разработки – разделение труда.



Структурное программирование

Э. Дэйкстра (60-е годы):

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

Простая программа – ровно один вход и один выход.

Стандартизация и линейность программы – снижение сложности. Некоторые соображения: