"UML Distilled" Martin Fowler
1. Введение
- Архитектура, управляемая моделью и исполняемый UML (см. стр 31-32)
- Идея использовать UML как язык программирования
- Диаграммы UML - таблица (см. стр 38-39)
- Процессы итеративные и водопадные (см. стр 46-49)
- Итеративную разработку называют по разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но их различия не миеюи широкого признания и не так важы как противостояние итеративного метода и метода водопада.(см. стр 47)
- Возможен и смешанный подход, когда выполняется анализ и проектирование верхнего уровня в стиле водопада, а затем кодированеи и тестирование разделяется на итерации.
- Очень нежелательно использовать метод водопада в чистом виде.
- Основные симптомы метода водопада, замаскированного под каскадный:(см. стр 48)
- Мы выполняем 1 итерацию анализа а затем 2 итерации проектирования
- Код данной итерации содержит много ошибок, но мы исправим их в конце
- Особенно важно, чтобы каждая итерация завершалась созданием протестированного интегрированного прграмного продукта, который имел бы качество, как можно более близкое к качеству серийной продукции. Процесс тестирования следует организовать таким образом, чтобы любая итерация, не обьявленная в плане как сдаточная, могла бы быть переведена в такой статус без серьезных дополнительных усилий разаботчиков.
- Соблюдение сроков итерации более важно чем реализовать всю функциональность, которая запланирована на итерацию.
- Итеративная разработка недвусмысленно предполагает, что вы будете перерабатывать и удалять существующий код на последней итерации проекта. (см. стр 48-49)
- Некоторые технические приемы способны оказать существенную помощь, чтобы процесс переделки был более эффективен:(см. стр 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)
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)
- Вы рисуете диагаму состояний класса, чтобы показать поведение одного обекта в течении его жизни