"UML Distilled" Martin Fowler

1. Введение

• Архитектура, управляемая моделью и исполняемый UML (см. стр 31-32)
  • Идея использовать UML как язык программирования
• Диаграммы UML - таблица (см. стр 38-39)
• Процессы итеративные и водопадные (см. стр 46-49)
  • Итеративную разработку называют по разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но их различия не миеюи широкого признания и не так важы как противостояние итеративного метода и метода водопада.(см. стр 47)
  • Возможен и смешанный подход, когда выполняется анализ и проектирование верхнего уровня в стиле водопада, а затем кодированеи и тестирование разделяется на итерации.
  • Очень нежелательно использовать метод водопада в чистом виде.
  • Основные симптомы метода водопада, замаскированного под каскадный:(см. стр 48)
    • Мы выполняем 1 итерацию анализа а затем 2 итерации проектирования
    • Код данной итерации содержит много ошибок, но мы исправим их в конце
• Особенно важно, чтобы каждая итерация завершалась созданием протестированного интегрированного прграмного продукта, который имел бы качество, как можно более близкое к качеству серийной продукции. Процесс тестирования следует организовать таким образом, чтобы любая итерация, не обьявленная в плане как сдаточная, могла бы быть переведена в такой статус без серьезных дополнительных усилий разаботчиков.
• Соблюдение сроков итерации более важно чем реализовать всю функциональность, которая запланирована на итерацию.
• Итеративная разработка недвусмысленно предполагает, что вы будете перерабатывать и удалять существующий код на последней итерации проекта. (см. стр 48-49)
  • Некоторые технические приемы способны оказать существенную помощь, чтобы процесс переделки был более эффективен:(см. стр 49)
    • Автоматизированные регрессивные тесты
      • Хорошим правилом является создание модульных тестов такого же обема как и тестируемая программа
    • Рефакторинг
    • Последовательная итерация. Включает: общий репозиторий, бидл систему, автоматически запускаемые регресивные тесты
• Agile (Гибкие процессы) (см. стр 51-52)
• Настройка процесса под проект
  • Про шаблоны (см. стр 54-55)
• Ратраспективный анализ следует проводить в конце каждой итерации. Собирается команда на свещание, чтобы посмотреть как идут дела и что можно улучшить. При этом хорошо составить список из 3-х категорий:
  • Сохранить: все что работало правильно и вы хотите это продолжить
  • Проблемы: разделы, котрые работали не правильно
  • Испытать: изменения в процессе с целью его улучшения
• Применяйте итератиывные процессы только в тех проектах, которым желаете успеха.
  • Ранее определение рисков
  • Улучшает управляемость процессом разработки
  • Такой подход требует тщательного планирования

3. Диаграма класов - основы. (см пример диаграмы на стр. 63)

• Свойства - В ппервом прибличении - это поля класса
• Атрибут - Описание свойства в прямоугольнике класса
• Ассоциации - неприрывная линия между 2-мя классами.
  • Свойства могут быть отображены в виде атрибутов или асоциаций. (см пример диаграмы на стр. 64)

• Кратность - количество обьектов, которые могут заполнять даное свойство. (0..1, 0..*, более детально на стр. 65)
• Програмная интерпритация свойств может быть разной.
• Двунаправленные асоциации - пара свойств связанных в противоположных направлениях.
• Операции - действия, реализуемые некоторым классом.
  • Не нужно показывать на диаграме операций и атрибутов, которые подразумеваются
• Обобщение - обратная сторона наследования. (см. описание на стр. 72, диаграму на стр. 63)
  • Обобщая корпоративных и частных клиентов мы говорим, что можем работать с каждым из них как с просто клиентом.
  • Наследуя класс, мы говорим, что наследник будет вести себя как класс родитель.
• Примечания и коментарии
  • Могут помещаться отдельно или на любом элементе диаграмы в конце. Во втором случае он обозначается линиями "--" (см. стр. 73)
  • Зависемости - Нужно использовать каждый раз, когда нужно показать, что изменения в одном элементе могут повлиять на другие элементы
    • Если на диаграмме: [presenter] -> [model] , это означает, что интерфейс модели мы можем менять сколько угодно не затрагивая model. Но если мы поменяем model, то presenter прийдется тоже поменять.
    • Если изменяется тлько сам класс, но не его интерфейс, то на этом изменения и заканчиваются.
    • Ключевые слова для зависемостей: (стр. 75)

• Вашим основнным правилом должно быть минимизация зависемостей. Особенно это касается циклических зависемостей.
• Колличество отображенных на диаграме зависемостей должны быть ограничены целесообразностью.
• Чтобы понять и управлять зависемостями лучше всего использовать диаграму пакетов.
• Правила применения диаграм классов:
  • Не пытайтесь задействовать сразу все доступные понятия. Начинайте с самых простых. (см. стр. 77)
  • Концептуальны модели полезны для изучения делового языка. Нужно тольо избегать обсуждения програмного обеспечения и применять очень простые обозначения.
  • Не надо строить модели для всего на свете. Лучше меньее число но актуально обновляемых моделей.
• Проектирование по контракту (стр. 78-79)
  • Предусловие: соответствует ли входной параметр ожиданиям. Тут применяется assert.
  • Пост условие: Соответствует ли состояние обьекта после вызова ожиданиям.
  • Инвариант - это утвержения относительно класса. Они могуть быть неверны во время вызова ф-и, но до и после должны всегда быть истенными.

4. Диагаммы последовательности

• Показывают взаимодействие групп объектов в различных условиях их поведения. (стр. 81-82)
• Централизованное и распределенное управление (стр. 83)

• Создание и удаление участников (стр. 84)

• Цыклы, условия и тому подобное (стр. 85-88)
  • Диаграммы последовательностей для этого не предназначены.
  • Они визуализируют процесс взаимодействия. А для циклов используйте диаграмы деятельности или собственно код.

• Принятые операторы для фреймов взаимодействия (стр. 86)

• Ненормативные обозначения на диаграмме

• Синхронные сообщения обозначаются закрашенными стрелками а асинхронные простые
  • (Ранее асинхронные сообщения обозначались половинными стрелками как на рис 4.5)
  • Когда применять диаграммы последовательности (стр. 89)
  • Требуется посмотреть поведение нескольких обектов в рамках прицендента.
  • Показывают взаимодействие но не очень хороши для повдения.
    • Если нужно показать поведение 1го обекта, применяйте диаграму состояний (глава 10)
    • Если нужно показать поведение нескольких обектов в нескольких потоках, применяйте диаграму деятельности (глава 11)
      • Чтобы быстро исследывать несколько вариантов взаимдействия используйте CRC карточки (стр. 89-91)
    • Взаимодействия можно показать на комуникационных диаграммах
    • Временные диаграммы хорошо показывают временные интервалы.
  • CRC карточки (Class-Responsibility-Collaboration, класс-обязанность-кооперация)
    • Ключевым тут является определение ответственностей. Групировка их из нескольких классов или разбиение класса на 2, если ответственностей слишком много и они разные.

5. Диаграммы класов. Дополнительные понятия.

• Агрегация и Композиция. (стр. 94-95)
  • ,Агрегация - соотношение часть-целое. Автор считает ее использование не вполне осмысленным
  • Композиция - включение объекта А в обьект В так, что объект В не может больше никому пренадлежать.
• Производные свойства обозначабтся знаком "/" впереди (стр. 95-96)

• Интерфейс (стр. 96-100)

• Не нормативные способы отображения на диаграмме последовательности:

• ReadOnly и Frozen(не может меняться в течении жизни обьекта) (стр. 100)
• Множественная динамическая классификация

• Класс-ассоциация

• Шаблон класса

• Перечисления

• Активный класс

• обозначения видимости:
  • + (public – открытый),
  • - (private – закрытый),
  • ~ (package – пакетный),
  • # (protec – защищенный).
  • Отправка сообщений (не нормативная) (стр. 111)

7. Диаграмма пакетов

• Зависемости между пакетами
  • Зачастую более стабильные проекты содежжат больше интерфейсов и абстрактных классов.

• Аспекты пакетов: иногда полезно просмотреть зависемости с разных аспектов (стр. 118)

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

8. Диаграммы развертывания. (стр. 121-122)

Показывает физическое размещение системы и на каком оборудовании размещается какая ее часть.

9. Прецеденты (стр. 123-129)

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

• Общий пример текста прецедента:
• Вы начинаете с выбора одного из сценариев в качестве главного успешного сценария (main success scenario)
• Затем берете другой сценарий и вставляете его в виде расширения (extension)
• Наряду с шагами сценария можно вставить в прецедент дополнительную общую информацию.
  • Предусловие (precondition) описывает действия, обязательно выполняемые системой перед тем, как она разрешит начать работу прецедента. Это полезная информация, позволяющая разработчикам не проверять некоторые условия в их программе.
  • Гарантия (guarantee) описывает обязательные действия системы по окончании работы шаблона ответа. Успешные гарантии выполняются после успешного сценария; минимальные гарантии выполняются после любого сценария.
  • Триггер (trigger) определяет событие, инициирующее выполнение прецедента.
• При рассмотрении дополнительных элементов, относитесь к этому скептически. Лучше сделать слишком мало чем слишком много.
  • Излишняя подробность скорее приведет к провалу
  • Не стоит все записывать. Усное общение бывает очень эффективным.
• Часто детали нужны только вначале немногих ключевых прицендентов, другие можно конкретизировать непосредственно перед реализацией.
• Диаграмы прецедентов (стр. 127)
  • Хтя диаграма является полезной, без нее можно обойтись
  • Лучше состедоточить свои усилия на создании текстового содержания прецедента
• Уровни прецендентов(стр. 127-128) :
  • Уровень моря - это базовое взаимодействие. Как правило это отдельное взаимодействие ведущего актера и системы.
  • Уровень рыб - прецеденты, которы существуют в системе, только если они включены в уровень моря.
  • Уровень воздушного змея - показывает как прецендетны уровня моря настраиваются на более широкое взаимодействие с бизневв процессами.
• Иногда полезно описать возможности(приложения) или поелания(заказчика) и они очень напоминают прецеденты.
• Когда применяются прецеденты:
  • Прецеденты - ценный инструмент для понимания функциональных требований к системе
  • Первый вариант прецидентов должен составлятся на ранней стедии выполнения прокта.
  • Более подробные версии прецедентов должны появлятся непосредственно перед реализацией данного прецедента.
  • Большя опасность прецедентов в том, что разработчики делают их слишком сложными и застревают на них.
    • Обычно чем меньше вы делаете тем меньший вред можете нанести
    • Если у вас не много информации, то получится короткий легко читаемый документ, который явится отправной точкой для вопросов. Если информаци слишком много, то врядли кто-то вообще будет ее читать и пытаться понять.

10. Диаграмы состояний(стр. 130-138)

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