
- •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. Технология использования шаблонов проектирования
67. Шаблон функционального дизайна
Шаблон функционального дизайна (англ. Functional design) — это шаблон проектирования использующийся для упрощения проектирования ПО. Функциональный дизайн гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы. Функционально разработанные модули имеют очень маленькое сцепление.
Преимущества
Системы с функционально-спроектированными частями легче модифицировать, потому что каждая часть делает только то, для чего она предназначена. Так как поддержка программы занимает больше 3/4 жизни успешной системы, эта особенность является решающим преимуществом. Это также делает систему лёгкой для понимания и документирования, что также упрощает обучение. Результатом является то, что практическое время жизни функциональной системы больше.
Преимуществом для реализации является то, что если программный модуль имеет единственное предназначение, он будет проще и тем самым — легче и менее дорогостоящим для проектирования и реализации.
В программных системах, функциональный модуль будет легче использовать многократно потому что он менее вероятно будет иметь побочные эффекты, которые проявятся в других частях системы.
Методика
Стандартный способ обеспечения функционального дизайна — это обзор описания модуля. Если описание включает связи, такие как «и» или «или», тогда дизайн имеет более, чем одно предназначение, и соответственно возможно будет иметь побочные эффекты. Предназначения должны быть разделены в отдельные модули для того, чтобы функциональный дизайн был бы достижим.
Критика и ограничения
Каждая компьютерная система имеет части, которые не могут быть функционально чисты, потому что они существуют для распределения тактов процессора или других ресурсов различным модулям. Например, большинство систем имеют раздел «инициализации», который запускает модули. Другие хорошо известные примеры включают в себя таблицу векторов прерываний и главный цикл.
Некоторые функции в сущности имеют смешанную семантику. Например, функция «вывести автомобиль из гаража» по сути имеет побочный эффект изменения «положения автомобиля». В некоторых случаях, смешанная семантика может быть расширена на большое топологическое дерево или граф связанных понятий. В этих необычных случаях, некоторые авторитеты не рекомендуют использовать функциональный дизайн. Вместо этого попробуйте полиморфизм и наследование.
Применение к 3D моделированию и симуляции
Последнее время некоторые софтверные компании вводят Функциональный дизайн как концепцию описания Parametric feature based modeler для 3D моделирования и симуляции. В этом смысле, они имеют в виду параметрическую модель (parametric model) объекта, параметры которого связаны с настоящими параметрами дизайна. Например, ось, изменяющая диаметр в зависимости от прочности материала и величины силы, приложенной к ней в симуляции. Считается, что таким образом будет увеличена производительность в процессе проектирования для механических и даже возможно архитектурных/структурных сборок путем внедрения результата анализа методом конечных элементов непосредственно в поведение индивидуальных объектов.