- •1. Введение в методологию msf и историческая справка
- •2. Что такое методология?
- •3. Основные концепции методологии msf
- •4. Основные положения msf
- •5. Формирование команды. Модель проектной группы
- •14. Управление выпуском
- •15. Удовлетворение потребителя
- •13. Тестирование
- •6. Основные принципы построения команды
- •16. Управление продуктом
- •12. Разработка
- •10. Управление программой
- •7. Ролевые группы и роли
- •11. Архитектура продукта
- •24. Принципы модели процессов
- •8. Зоны ответственности ролевых групп
- •9. Задачи ролевых групп и взаимодействие с заинтересованными лицами
- •17. Рекомендации по возможному объединению ролей
- •18. Основные сведения о рисках
- •19. Планирование управления рисками
- •20. Процесс управления рисками
- •21. Управление рисками как составная часть жизненного цикла проекта
- •22. Учебный пример. Выделение рисков
- •23. Модель процессов msf
- •25. Взаимодействуйте с “заказчиками”
- •26. Поощряйте свободный обмен информацией в проекте
- •27. Создавайте “единое видение проекта”
- •28. Следите за качеством продукта
- •29. Проявляйте гибкость - будьте готовы к изменениям
- •31. Будьте готовы к внедрению сегодня
- •30. Ставьте "вехи"
- •32. Управление компромиссами
- •33. Треугольник компромиссов
- •34. Матрица компромиссов проекта
- •35. Схема процесса разработки
- •36. Структурные единицы схемы
- •37. Цикличность процесса разработки
- •38. Фазы и вехи процесса разработки
- •39. Фаза выработки концепции
- •40 . Основные задачи фазы
- •41. Задачи ролевых групп на фазе выработки концепции
- •44. Выработка концепции
- •43. Результаты фазы выработки концепции
- •42. Вехи фазы выработки концепции
- •45. Видение проекта
- •46. Концепция решения
- •47. Цели и Задачи
- •48. Предположения и Ограничения
- •49. Пользователи
- •50. Сценарии использования
- •51. Рамки
- •52. Функциональность решения
- •53. За рамками решения
- •54. Планирование проекта. Фаза планирования
- •55. Основные задачи фазы
- •56. Задачи ролевых групп на фазе планирования
- •57. Вехи фазы планирования
- •62. Вехи фазы разработки
- •63. Результаты фазы разработки
- •64. Стабилизация решения. Фаза стабилизации
- •65. Основные задачи фазы
- •67. Вехи фазы стабилизации
- •68. Результаты фазы стабилизации
- •66. Задачи ролевых групп на фазе стабилизации
- •69. Внедрение решения. Фаза внедрения
- •70. Основные задачи фазы
- •71. Задачи ролевых групп на фазе внедрения
- •72. Вехи фазы внедрения
- •73. Результаты фазы внедрения
- •74. Компоненты
- •75. Имя компонента
- •80. Узел
- •76. Виды компонент
- •77. Интерфейсы
- •78. Зависимости
- •79. Рекомендации по построению диаграммы компонентов
- •81. Соединения
- •82. Рекомендации по построению диаграммы развертывания
- •83. Кооперация
- •84. Диаграмма кооперации уровня спецификации
- •85. Объекты
- •86. Мультиобъект
- •87. Активный объект
- •88. Составной объект
- •89. Связи
- •90. Стереотипы связей
- •91. Сообщения
- •92. Формат записи сообщений
- •93. Заключительные рекомендации по построению диаграмм кооперации
- •1. Введение в методологию msf и историческая справка
- •2. Что такое методология?
- •3. Основные концепции методологии msf
80. Узел
Узел представляет собой физически существующий элемент системы, который может обладать вычислительным ресурсом (например, процессоры) или является техническим устройством. В языке UML понятие узла включает в себя не только вычислительные устройства, но и другие механические или электронные устройства, такие как датчики, принтеры, и т. д.
Графически узел на диаграмме развертывания изображается в виде трехмерного куба и имеет имя, которое записывается внутри этого графического символа. Сами узлы могут представляться как на уровне типа, так и на уровне экземпляра. В первом случае, имя узла записывается в виде: <Имя типа узла>. Во втором случае: <Имя узла>:<Имя типа узла>. Пример:
Если есть дополнительная информация, которая относиться к имени узла, то она записывается под этим именем в фигурных скобках. Можно также явно указать компоненты, которые размещаются или выполняются на отдельном узле.
На диаграммах развертывания допускаются специальные условные обозначения для различных физических устройств, которые проясняют назначение или выполняемые функции устройства.
Ресурсоемкий узел (с процессором и памятью) изображается в виде куба с боковыми гранями окрашенными в серый цвет. Устройство, под которым понимается узел без процессора и памяти изображается в форме обычного куба. Соответствующие узлы можно также изображать с помощью обычного символа узла и дополнительного стереотипа <<processor>> или <<device>>.
76. Виды компонент
Поскольку компонент как элемент модели может иметь различную физическую реализацию, то иногда его изображают в виде специального символа. Стали общепринятыми следующие графические стереотипы (не специфицированы в языке UML):
-
Стереотипы для компонентов развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки (DLL), веб-страницы (HTML) и файлы справки (HLP).
-
Стереотипы для компонентов в форме рабочих продуктов. Как правило это файлы с исходными текстами программ. (например с++)
Разработчики могут использовать и самостоятельные обозначения. Другой способ спецификации различных видов компонент - указание текстового стереотипа компонента перед его именем:
-
<<file>> определяет наиболее общую разновидность компонента, который представляется в виде произвольного физического файла.
-
<<executable>> - исполнимый файл.
-
<<document>> - документ произвольного содержания.
-
<<library>> - динамическая или статическая библиотека.
-
<<source>> - файл с исходным текстом программы.
-
<<table>> - таблица БД.
77. Интерфейсы
В общем случае интерфейс обозначается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса рекомендуется начинать с буквы I которая записывается рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.
Другим способом представления интерфейса на диаграмме компонентов является его изображение в виде прямоугольника класса со стереотипом <<Interface>> и возможными секциями для атрибутов объектов и операций. Как правило, этот вариант обозначения используется для внутренней структуры интерфейса.