"UML Distilled" Martin Fowler

1. Введение

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

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

    • Свойства - В ппервом прибличении - это поля класса
  • Атрибут - Описание свойства в прямоугольнике класса
  • Ассоциации - неприрывная линия между 2-мя классами.
    • Кратность - количество обьектов, которые могут заполнять даное свойство. (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)
    • Не нормативные способы отображения на диаграмме последовательности:
    • ReadOnly и Frozen(не может меняться в течении жизни обьекта) (стр. 100)
  • Множественная динамическая классификация

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

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

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

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

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

6 Диаграмма обектов (стр. 112-113)

  • ДО - это снимок объектов системы в какой-то момент в ремени.
  • ДО можно считать коммуникационной диаграммой

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

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

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

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

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

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

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

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

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

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