33. Понятия модели и системы в языке uml
Система (system), возможно разложенная на ряд подсистем, - это множество элементов, организованных некоторым образом для выполнения определенной цели. Она описывается набором моделей, зачастую с различных точек зрения. Подсистема (subsystem) - это объединение элементов, ряд которых составляет спецификацию поведения, предложенного другими ее элементами. Система и подсистема изображаются в виде пиктограммы стереотипного пакета. Модель (model) - это упрощение реальности, абстракция, которая создается для лучшего восприятия системы. Вид или представление (view) - это модель, рассматриваемая под определенным углом зрения: в ней отражены одни сущности и опущены другие, которые с данной точки зрения не представляют интереса.
Система, собственно, и является той самой сущностью, для которой разрабатываются и строятся модели. Система охватывает все артефакты, составляющие эту сущность, включая модели и элементы этих моделей, такие как классы, интерфейсы, компоненты, узлы и связи между ними. Все, что необходимо для визуализации, специфицирования, конструирования и документирования системы, является ее частью, а все, что для этой цели не требуется, лежит за пределами системы.
Являясь стереотипным пакетом, система владеет некоторыми элементами. Если рассмотреть систему изнутри, то можно увидеть все ее модели и отдельные элементы, в том числе и диаграммы, которые очень часто будут разложены на более мелкие подсистемы. Подсистемы - это образования, которые используются для декомпозиции системы на более простые, слабо зависящие друг от друга составляющие. То, что на одном уровне абстракции выглядит системой, на другом, более высоком, может рассматриваться как подсистема. В UML подсистема изображается в виде пиктограммы стереотипного пакета.
Основное отношение между системами и подсистемами - это агрегирование. Система (целое) может состоять из нуля и более подсистем (частей). Но между системами и подсистемами допускается существование отношения обобщения. С его помощью можно моделировать семейства систем и подсистем, ряд которых представляет общий случай, а другие являют собой специализацию для конкретных условий. Таким образом, система - это сущность самого высокого уровня в данном контексте, а составляющие ее подсистемы, разбивают эту сущность на непересекающиеся части.
Модель, согласно определению, представленному выше, - это упрощение реального мира, реальность в ней описывается в контексте моделируемой системы. Проще говоря, модель - это абстракция системы. В то время как подсистема представляет собой разбиение множества элементов большей системы на независимые части, модель - это разбиение множества абстракций, которые используются для визуализации, специфицирования, конструирования и документирования этой системы. Мы разбиваем систему на подсистемы, чтобы их можно было разрабатывать и развертывать в некоторой степени независимо друг от друга. Абстракции системы и подсистемы мы раскладываем на модели, чтобы лучше понять, что именно нужно разрабатывать и развертывать.
Модель - это разновидность пакета. Явно задавать ее приходится не часто, и поэтому специального графического символа для моделей в рамках UML не предусмотрено. Однако инструментальные средства должны каким-то образом манипулировать моделями, обычно, для этих целей они использую нотацию пакетов. Будучи пакетом, модель владеет некоторыми элементами. Модели, ассоциированные с системой и подсистемой, образуют исчерпывающее разбиение ее элементов. Это означает, что каждый элемент принадлежит одному и только одному пакету. Как правило, артефакты системы и подсистемы организуются в несколько неперекрывающихся моделей.
Модель может содержать так много артефактов, что в большой системе всю их совокупность нельзя охватить сразу. Вид системной архитектуры можно представлять себе как одну из проекций модели. Для каждой модели предусмотрен ряд диаграмм, с помощью которых удобно рассматривать, принадлежащие ей сущности. Представление охватывает подмножество сущностей, входящих в состав модели. Границы моделей представления обычно пересекать не могут.
UML не диктует, какими именно моделями следует пользоваться для визуализации, специфицирования, конструирования и документирования системы, хотя Рациональный Унифицированный Процесс предлагает некоторое множество разумных моделей, проверенное на практике.
Специфицирование отношений между такими важными элементами, как классы, интерфейсы, компоненты и узлы, - это важная структурная составляющая модели. Для управления артефактами процесса разработки сложных систем, многие из которых существуют более чем в одной версии, большую роль играет описание отношений между такими элементами, как документы, диаграммы и пакеты, присутствующие в разных моделях.
В UML концептуальные отношения между элементами, существующими в различных моделях, можно моделировать с помощью отношения трассировки (trace relationship). Трассировку нельзя применять к элементам в рамках одной модели. Трассировка представляется в виде стереотипной зависимости. Часто можно не обращать внимание на направление такой зависимости, хотя обычно стрелка указывает на более ранний или более специфичный элемент. Очень часто отношениями трассировки пользуются для того, чтобы показать путь от требований к реализации, на котором лежат все промежуточные артефакты, а также для отслеживания версий. Как правило вместо явного изображения трассировки удобнее использовать гиперссылки.
Yandex.RTB R-A-252273-3- Разработка и стандартизация программных систем
- 1. Три типа жизненных циклов программных систем.
- Водопадная (каскадная, последовательная) модель
- Итерационная модель
- Спиральная модель
- 3. Стандарт iso серии 9000 при разработке программных систем.
- Iso 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.
- 4. Стандарты Единой системы программной документации (еспд)
- Классификация:
- 5. Стандарты рф (гост р) на документирование пс
- 6. Организация группы проекта при разработке программных систем.
- 7. Три способа определения требований к программной системе.
- 8. Спецификация требований к программной системе.
- 9. Методы контроля спецификации требований.
- 10. Спецификация качества программных систем.
- 11. Функциональная спецификация программных систем.
- 12. Архитектура программных систем
- 13. Основные классы архитектур программных систем.
- 14. Основные модели при разработке программных систем.
- (См. Вопрос 1!)
- 15. Принципы объектно-ориентированного анализа и проектирования пс
- 16. Принципы компонентной архитектуры информационных систем.
- 17. Стандарты семейства idef
- 18. Принципы построения модели idef0
- 19. Принципы разработки моделей as-is и то-ве
- 20. Диаграммы в стандарте idef0
- 21. Понятие работы в стандарте idef0
- 22. Описание взаимодействия работ в стандарте idef0
- 23. Типы связей работ в стандарте idef0
- 24. Стандарт idef1x
- 26. Диаграммы потоков данных.
- 27. Архитектурные виды программной системы.
- 28. Фазы, итерации и циклы разработки программных систем - руп.
- 29. Рабочие процессы создания программных систем - руп.
- 30. Основные артефакты при разработке программных систем.
- 31. Концепция языка uml
- 32. Язык uml как система визуализации, специфицирования, конструирования, документирования
- 33. Понятия модели и системы в языке uml
- 34. Принципы моделирования системной архитектуры в языке uml.
- 35. Принципы представления системы в языке uml.
- 36. Понятие сущностей в языке uml
- 37. Структурные сущности предметной области.
- 38. Отношения в языке uml
- 39. Диаграммы в языке uml
- 40. Правила языка uml.
- 41. Общие механизмы языка uml
- 42. Прецедент как спецификация поведения программных систем.
- 43. Организация прецедентов в языке uml.
- 44. Приемы анализа прецедентов в языке uml
- 45. Диаграммы прецедентов.
- 46. Моделирование требований к системе с помощью диаграмм прецедентов.
- 47. Критерии сравнения инструментальных систем разработки программных систем.
- 48. Технико-экономические показатели разработки программных средств
- 49. Сертификация программных средств
- 50. R-технология программирования