- •1. Назначение языка
- •2. Способы использования языка
- •3. Нотация языка uml
- •Виды диаграмм uml
- •5. Диаграмма прецедентов (use case diagram)
- •6. Диаграмма классов (class diagram)
- •7. Диаграмма объектов (object diagram)
- •8. Диаграмма последовательностей (sequence diagram)
- •9. Диаграмма взаимодействия (кооперации, collaboration diagram)
- •10. Диаграмма состояний (statechart diagram)
- •11. Диаграмма активности (деятельности, activity diagram)
- •12. Диаграмма развертывания (deployment diagram)
- •13. Ооп и последовательность построения диаграмм
- •14. Отображение класса и его элементов на диаграмме uml
- •15. Способы использования объектов класса
- •16. Моделирование наследования в uml
- •17. Отношения между классами
- •18. Отношение зависимости между классами
- •19. Отношение ассоциации между классами
- •20. Композиция и агрегация классов
- •21. Сравнение диаграмм активностей и блок-схем
- •22. Моделирование процессов диаграммами активности
- •23. Моделирование операций диаграммами активности
- •24. Правила построения диаграммам активности
- •Составление перечня деятельностей в системе
- •Принятие решения о необходимости построения диаграммы деятельностей
- •25. Диаграмма кооперации
- •26. Диаграмма последовательностей как диаграмма взаимодействия
- •27. Диаграмма кооперации как альтернатива диаграмм последовательностей
- •28. Диаграмма кооперации как диаграмма взаимодействий объектов
- •29. Типы сообщений: синхронные, асинхронные и ответные, потерянные и найденные.
- •30. Уровни экземпляров и спецификации в диаграммах кооперации
- •31. Мультиобъекты, композитные и активные объекты в диаграммах кооперации.
- •32. Диаграммы взаимодействия с разветвленным потоком управления
- •33. Нефункциональные требования и их отображение на диаграммах прецедентов
- •34. Понятие эктора и отношения между экторами
- •35. Отношения включения и расширения между экторами
- •36. Причины использования прецедентов.
- •37. Прецеденты в прямом и обратном проектировании
- •38. Обзор case-средств для построения диаграмм uml
- •Visio поддерживает множество локальных языков
- •39. Критерии выделения прецедентов
- •40. Понятие шаблона проектирования
- •41. Основные шаблоны grasp
- •Information Expert (Информационный эксперт)
- •Indirection (Посредник)
- •42. Описание шаблонов проектирования GoF
- •43. Классификация шаблонов проектирования GoF
- •44. Структурные шаблоны проектирования
- •56. Понятие рефакторинга программ
- •57. Анти-шаблоны управления разработкой программ
- •Раздувание по (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов
- •58. Анти-шаблоны разработки программ
- •59. Анти-шаблоны в объектно-ориентированном программировании
- •60. Анти-шаблоны в программировании
- •61. Методологические анти-шаблоны
- •62. Анти-шаблоны управления конфигурацией
- •63. Примеры организационных анти-шаблонов
- •64. Социальные анти-шаблоны
- •Шаблоны параллельного программирования (Concurrency)
- •Другие типы шаблонов
- •66. Шаблон делегирования
- •Простой пример
- •67. Шаблон функционального дизайна
- •68. Неизменяемый объект (шаблон проектирования)
- •69. Интерфейс (шаблон проектирования)
- •70. Порождающие шаблоны проектирования
- •71. Абстрактная фабрика (шаблон проектирования)
- •72. Строитель (шаблон проектирования)
- •73. Фабричный метод (шаблон проектирования)
- •74. Отложенная инициализация (шаблон проектирования)
- •75. Объектный пул (шаблон проектирования)
- •76. Прототип (шаблон проектирования)
- •77. Получение ресурса есть инициализация (шаблон проектирования)
- •78. Одиночка (шаблон проектирования)
- •79. Структурные шаблоны
- •80. Адаптер (шаблон проектирования)
- •81. Мост (шаблон проектирования)
- •82. Компоновщик (шаблон проектирования)
- •83. Декоратор (шаблон проектирования)
- •84. Фасад (шаблон проектирования)
- •85. Приспособленец (шаблон проектирования)
- •86. Заместитель (шаблон проектирования)
- •87. Поведенческие шаблоны
- •88. Цепочка ответственности (шаблон проектирования)
- •89. Команда (шаблон проектирования)
- •90. Интерпретатор (шаблон проектирования)
- •91. Итератор (шаблон проектирования)
- •92. Посредник (шаблон проектирования)
- •93. Хранитель (шаблон проектирования)
- •94. Наблюдатель (шаблон проектирования)
- •95. Состояние (шаблон проектирования)
- •96. Стратегия (шаблон проектирования)
- •97. Шаблоны параллельного программирования Шаблоны параллельного программирования (Concurrency)
- •Пример реализации Пример c#
- •Следствия
- •98. Модель-представление-контроллер (шаблон проектирования)
- •99. Технология использования шаблонов проектирования
61. Методологические анти-шаблоны
Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений
Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией
Золотой молоток (Golden hammer): Сильная уверенность в том, что любимое решение универсально применимо. Название происходит от поговорки «когда в руках молоток, все проблемы кажутся гвоздями»
Фактор невероятности (Improbability factor): Предположение о невозможности того, что сработает известная ошибка
Преждевременная оптимизация (Premature optimization): Оптимизация на основе недостаточной информации
Изобретение колеса (Reinventing the wheel): Ошибка адаптации существующего решения
Изобретение квадратного колеса (Reinventing the square wheel): Создание плохого решения, когда существует хорошее
62. Анти-шаблоны управления конфигурацией
Ад зависимостей (Dependency hell): Проблемы с версиями требующихся продуктов, особенно в системах UNIX/GNU/Linux
DLL-ад (DLL hell): Проблемы с версиями, доступностью и увеличением количества DLL, особенно в Microsoft Windows
DLL hell (DLL-кошмар, буквально: DLL-ад) — тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows.
Аналогичная проблема в средах Unix (Linux и пр.) носит название Dependency hell. Однако там она встречается только в случае пренебрежения пользователем встроенной в ОС системой управления пакетами.
Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. DLL hell — пример плохой концепции программирования, которая, подобно скрытой мине, приводит к резкому возрастанию трудностей при усложнении и совершенствовании системы.
Описание проблемы
По исходному замыслу, DLL должны быть совместимыми от версии к версии и взаимозаменяемыми в обе стороны..
Реализация механизма DLL, однако, такова, что несовместимость и невзаимозаменяемость становится скорее правилом, чем исключением, что приводит к большому количеству проблем.
Отсутствие стандартов на имена, версии и положение DLL в файловой структуре приводит к тому, что несовместимые DLL легко замещают друг друга или отключают друг друга
Отсутствие стандарта на процедуру установки приводит к тому, что установка новых программ приводит к замещению работающих DLL на несовместимые версии
Отсутствие поддержки DLL со стороны линкеров и механизмов защиты приводит к тому, что несовместимые DLL могут иметь одно и то же имя и одну и ту же версию
Отсутствуют стандартные инструменты идентификации и управления системой DLL пользователями и администраторами
Использование отдельных DLL для обеспечения связи между задачами приводит к нестабильности сложных приложений
Для избежания конфликтов обычно используют множество избыточных копий DLL для каждого приложения, что сводит на нет исходную идею получения преимущества от DLL как стандартных модулей, хранящихся один раз в памяти и разделяемых многими задачами. Кроме того, при таком опыте после исправления ошибок в DLL или восстановления системы из архива количество различных DLL, носящих одно и то же имя и выполняющих те же функции, возрастает, а автоматическое обновление версии или исправление ошибок становится невозможным.
История проблемы
Эта проблема возникла в ранних версиях Microsoft Windows.
С подобными же проблемами сталкивались ранние версии Mac OS X, но с использованием других технологий. Не избегают подобных проблем дистрибуторы библиотек Open Source.
Поэтому, когда речь идёт о не-майкрософтовской среде, эту ситуацию называют dependency hell (кошмар зависимостей).
Проблема постоянно повторяется, когда программу пытаются запустить не с той DLL, c которой она тестировалась, что показывает изначальную порочность общей концепции, позволяющей произвольную замену версий модулей.
Меры против DLL hell
Данные меры рекомендуют предпринимать одновременно для получения наилучшего результата:
подсчитать контрольную сумму кода функции вызываемой из DLL - сравнить с контрольной суммой функции используемой при написании программы.
Операционная система должна поставляться совместно с менеджером пакетов, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование менеджера пакетов должно поощряться, а индивидуальная инсталляция DLL — по возможности отвергаться.
Распространение библиотек
должнообязано происходить централизованно.
Допустить возможность параллельного использования нескольких версий одной и той же DLL [1].
При модификации программного обеспечения для частного использования поставлять также модифицированные версии DLL.
Во время проектирования DLL должна тщательно продумываться концепция функций и версий. DLL не должны использоваться без необходимости, а библиотеки, связанные только с одним приложением, должны подключаться статически (в EXE-файл).
DLL hell как мотивация проекта .NET
В 2001 фирма Майкрософт определила подсистему .NET Framework для разработки пакетов (assemblies: см. здесь). Эта подсистема стала поддерживать общую библиотеку времени исполнения, присоединяя DLL к основному исполняемому классу.