Управление моделями в UML

Сентябрь 3, 2022

Главная
Алгебра
Управление моделями в UML

Содержание

2. Управление моделями В UML определены несколько понятий, которые имеют особое для значение при определении как структуры
3. Управление моделями При моделировании наше внимание сосредоточено на описании некоторой части реального мира. Например, при моделировании
4. Управление моделями Одна и та же физическая система может быть описана с различных точек зрения. Описание
5. Управление моделями Если физическая система сложна и велика (а именно так обычно и бывает), то ее
6. Управление моделями Например, информационная система отдела кадров конкретной организации, как физическая система, состоит из некоторого количества
7. Управление моделями Когда модель достаточно велика, реально возникает проблема управления моделями. Если модель достаточно велика, ее
8. Свойства пакета в UML • Отношение владения. Говорят, что пакет владеет объявленными в нем элементами модели,
9. Свойства пакета в UML • Пространство имен. Каждый пакет в модели образует пространство имен, т. е.
10. Управление моделями Отношение владения Внутри основного прямоугольника фигуры пакета можно помещать любые элементы модели — тем
11. Управление моделями Модели нуждаются в структуре, в противном случае они не отвечают своему основному назначению —
12. Управление моделями Если диаграмма в модели не помещается на экран так, чтобы тексты и значки оставались
13. Управление моделями Модель имеет хорошую, удобную для работы структуру, если выполняются следующие три количественных критерия. -
14. Управление моделями - Ширина ветвления в дереве вложенности пакетов с учетом диаграмм примерно постоянна и равна
15. Управление моделями - Число использующих вхождений элементов модели должно быть ограничено сверху значением 7±3, при этом
16. Управление моделями Приведенные критерии характеризуют форму модели, но никак не затрагивают ее содержание. Способы структурирования модели
17. Управление моделями Авторы языка рекомендуют структурировать модель по представлениям. Вслед за ними разработчики большинства инструментов пытаются
18. Управление моделями Допустим, что выбрана принципиальная структура пакетов в модели. Пакеты могут находиться в следующих отношениях:
19. Управление моделями Вложенность пакетов влечет вложенность пространств имен. Всякий элемент модели, определенный в данном пространстве имен,
20. Управление моделями Индуцированное отношение — это отношение между пакетами, которое просто отражает наличие такого же отношения
21. Управление моделями Существуют два специальных стандартных стереотипа отношения зависимости — «access» и «import», которые имеют сходное
22. Управление моделями Хотя пакеты не являются классификаторами, тем не менее для них можно указать отношение обобщения.
23. Управление моделями Например, на рисунке. представлена одна из возможных структур пакетов информационной системы отдела кадров, касающаяся
24. Управление моделями Спецификация UML предусматривает довольно большое число стандартных стереотипов для пакетов, «facade» Пакет, который содержит
25. Управление моделями UML позволяет придать описанию модели любую структуру — моделирующий субъект должен приложить определенные мыслительные
26. Управление моделями UML позволяет придать описанию модели любую структуру — моделирующий субъект должен приложить определенные мыслительные
27. Применение UML Технологию программирования целесообразно рассматривать в трех аспектах. • Модель процесса, т. е. порядок проведения
28. Применение UML • Модель команды, т. е. отношения между людьми в процессе разработки. Сюда относятся определение
29. Применение UML • Дисциплина программирования, т. е. методы создания конкретных артефактов, входящих в состав программного обеспечения.
30. Применение UML Задачей технологии программирования является исследование и улучшение процессов разработки программного обеспечения. При этом можно
31. Применение UML Приведем несколько примеров задач, исследуемых и решаемых технологией программирования. • Повышение надежности программного обеспечения.
32. Применение UML Применение UML оказывает положительное влияние на продуктивность процесса разработки программного обеспечения. Причина влияния заключается
33. Применение UML Применение элементов UML Первый вопрос, который надлежит поставить перед собой, приступая к применению UML:
34. Концептуальное моделирование В этом варианте целью моделирования является достижение понимания моделируемой физической системы (приложения, бизнес-процесса…), ее
35. Применение UML Для концептуального моделирования полные диаграммы использования обязательны, а также желательны и полезны диаграммы классов
36. Спецификация требований Основной целью моделирования является получение артефакта, который мог бы послужить техническим заданием на разработку.
37. Спецификация требований Реализация вариантов использования в форме диаграмм взаимодействия обязательна — это основа для построения набора
38. Спецификация требований В спецификации требований диаграмма компонентов не просто желательна, а обязательна — техническое задание должно
39. Циклы продуктивности С основным циклом последовательного выполнения фаз процесса разработки сопряжены два внешних цикла движения определенных
40. Циклы продуктивности UML унифицирует представления артефактов в циклах повышения продуктивности. Унификация обеспечивает ускорение прохождения циклов, повышение
41. Циклы продуктивности
42. Циклы продуктивности Применение UML оказывает положительное влияние на продуктивность процесса разработки программного обеспечения. Причина влияния заключается
43. Применение UML "Единственно правильной" модели нет и не может быть. Если программирование — это искусство, то
44. Выводы 7 ± 3 сущности на одной диаграмме. Диаграмма должна охватываться «одним взглядом». Управление моделями –
45. Л.р. 4 Отчёт должен содержать тему и её краткое описание Отчёт должен содержать 10 диаграмм, описывающих
47. Скачать презентацию

Слайд 2

Управление моделями
В UML определены несколько понятий, которые имеют особое для значение

при определении как структуры модели, так и структуры моделируемого приложения: модели,
системы и подсистемы,
а также синтаксические средства их выражения в UML.

Слайд 3

Управление моделями
При моделировании наше внимание сосредоточено на описании некоторой части реального

мира. Например, при моделировании приложения рассматривается его программная реализация, аппаратура, на которой исполняются программы, и пользователи, взаимодействующие с приложением.
Все это вместе называется физической системой.

Слайд 4

Управление моделями
Одна и та же физическая система может быть описана с

различных точек зрения. Описание физической системы называется моделью. Каждая модель описывает всю физическую систему в целом, но модели могут сильно отличаться степенью детальности, используемыми средствами и расстановкой акцентов. Это определяется целью, с которой составляется модель. Например, мы можем различать концептуальную модель, логическую модель и модель реализации для одной и той же физической системы.

Слайд 5

Управление моделями
Если физическая система сложна и велика (а именно так обычно

и бывает), то ее целесообразно мысленно разбить на части, называемые подсистемами и рассматривать отдельно и детально каждую подсистему.

Слайд 6

Управление моделями
Например, информационная система отдела кадров конкретной организации, как физическая система,

состоит из некоторого количества компьютеров, программных компонентов, составляющих приложение и развернутых на этих компьютерах, а также служащих отдела кадров, которым вменено в обязанность использовать приложение в повседневной работе.
С точки зрения выполняемых функций в этой физической системе можно выделить две подсистемы: подсистему работы с персоналом и подсистему работы со штатным расписанием.
Можно разделить все описание на несколько моделей, чтобы описать систему в целом с различных точек зрения, а можно разделить систему на части и описать их по отдельности как подсистемы. Более того, можно комбинировать эти структуры произвольным образом: разбить модель на несколько подсистем, каждую из которых описать с помощью нескольких моделей и т. д.

Слайд 7

Управление моделями
Когда модель достаточно велика, реально возникает проблема управления моделями.
Если

модель достаточно велика, ее нужно разделить на части обозримого размера и рассматривать их по отдельности. Для этой цели в UML используется одно универсальное средство — пакет.
Пакет — это группирующая сущность в UML.
На диаграммах пакет изображается в виде фигуры — прямоугольник с закладкой.
Если внутри пакета ничего не изображено, то имя пакета пишется в основном прямоугольнике, в противном случае — в закладке.

Слайд 8

Свойства пакета в UML
• Отношение владения.
Говорят, что пакет владеет объявленными

в нем элементами модели, а элементы принадлежат владеющему ими пакету. Пакет может владеть любыми элементами модели, в частности, пакетами. Отношение владения является строгой композицией, т. е. каждый элемент модели принадлежит ровно одному пакету. Всегда имеется корневой пакет (с именем по умолчанию). Таким образом, структура пакетов по отношению владения (или вложенности) образует в модели строгую иерархию, подобную иерархии папок и файлов в файловой системе.

Слайд 9

Свойства пакета в UML
• Пространство имен.
Каждый пакет в модели образует

пространство имен, т. е. область определения и использования имен.
Пространства имен вложены друг в друга. Пространства имен пакетов вложены в соответствии с иерархией отношения владения, пространства имен прочих элементов вложены в соответствии со специфической иерархией элементов. В частности, каждое составное состояние машины состояний образует вложенное пространство имен. Таким образом, пространства имен также образуют строгую иерархию.

Слайд 10

Управление моделями
Отношение владения
Внутри основного прямоугольника фигуры пакета можно помещать

любые элементы модели — тем самым моделируется отношение владения: пакет владеет элементом, помещенным внутрь его фигуры.

Слайд 11

Управление моделями
Модели нуждаются в структуре, в противном случае они не отвечают

своему основному назначению — служить средством визуализации, спецификации, проектирования и документирования.

Слайд 12

Управление моделями
Если диаграмма в модели не помещается на экран так, чтобы

тексты и значки оставались читаемыми, от модели мало проку. Если имена элементов модели состоят из десятков непонятных слов, модель трудно использовать. Если для понимания какой-то характеристики приложения нужно одновременно рассматривать десяток диаграмм, модель не отвечает своему назначению. Если для поиска ответа на конкретный вопрос нужно просмотреть всю модель подряд, она никуда не годится.

Слайд 13

Управление моделями
Модель имеет хорошую, удобную для работы структуру, если выполняются следующие

три количественных критерия.
- Количество сущностей, изображенных на всех диаграммах, примерно одинаково и равно 7±3.
Если сущностей на диаграмме три или меньше, то диаграмма недостаточно информативна, чтобы включать ее в модель отдельно. Такую диаграмму либо не стоит включать в модель, либо можно объединить с другой однородной диаграммой.
Если на диаграмме больше десяти сущностей, то она, как правило, слишком трудна для понимания с одного взгляда. Такую диаграмму целесообразно разбить на несколько диаграмм.

Слайд 14

Управление моделями
- Ширина ветвления в дереве вложенности пакетов с учетом диаграмм

примерно постоянна и равна 7±3.
Другими словами, пакету должны принадлежать от трех до десяти пакетов или диаграмм. Если их меньше, то не понятно, нужен ли такой малосодержательный пакет как отдельная сущность. Если больше, то в деталях пакета можно "утонуть".

Слайд 15

Управление моделями
- Число использующих вхождений элементов модели должно быть ограничено сверху

значением 7±3, при этом больше половины элементов модели должно присутствовать на диаграммах.
Любой данный элемент модели может присутствовать на некотором количестве диаграмм: 0, 1 или больше. Если на диаграммах нарисовано меньше половины существующих в модели элементов, то это не модель, а "вещь в себе", о назначении которой трудно догадаться.
Если один и тот же элемент повторяется в разных местах больше десяти раз, то это "масло масляное".

Слайд 16

Управление моделями
Приведенные критерии характеризуют форму модели, но никак не затрагивают ее

содержание.
Способы структурирования модели по содержанию:
- По структуре приложения.
В основу структуры пакетов кладется одна из реальных структур приложения, например, компонентная структура.
Вся система разбивается на пакеты, соответствующие компонентам (или подсистемам), они, если нужно, разбиваются на более мелкие части и т. д.
- По фазам процесса разработки.
Модель делится на пакеты в соответствии с фазами ее создания (набор которых зависит от принятой дисциплины моделирования). Например, пакет для диаграмм концептуального уровня, пакет диаграмм детального проектирования, пакет диаграмм реализации и развертывания и т. д.
- По представлениям.
Модель делится на пакеты по представлениям. Например, представление использования, логическое представление, представление реализации и т. д.

Слайд 17

Управление моделями
Авторы языка рекомендуют структурировать модель по представлениям. Вслед за ними

разработчики большинства инструментов пытаются навязать пользователю структуру модели.
Только в сравнительно простых моделях можно обойтись каким-то одним принципом структуризации.
В более сложных моделях приходится определять достаточно много пакетов (особенно если придерживаться наших критериев локального ограничения сложности).
Поэтому исходить нужно из потребностей модели, руководствуясь опытом и здравым смыслом — указанные принципы структуризации полезны, но все равно требуют размышлений при применении.

Слайд 18

Управление моделями
Допустим, что выбрана принципиальная структура пакетов в модели.
Пакеты могут находиться

в следующих отношениях:
• отношения владения (вложенности);
• индуцированные отношения;
• стереотипные зависимости;
• обобщение.

Слайд 19

Управление моделями
Вложенность пакетов влечет вложенность пространств имен. Всякий элемент модели, определенный

в данном пространстве имен, видит все элементы, определенные в этом же пространстве имен и во всех объемлющих пространствах имен. Имена в "параллельных" и вложенных пространствах имен не видимы для данного элемента. Если в цепочке вложенных пространств имен определены несколько разных элементов с одним именем, то для данного элемента видимым является ближайший при просмотре изнутри наружу.

Слайд 20

Управление моделями
Индуцированное отношение — это отношение между пакетами, которое просто отражает

наличие такого же отношения между некоторыми элементами данных пакетов.
Например, если указано, что пакет X зависит от пакета Y, то это означает, что один или несколько элементов модели, которыми владеет пакет X, зависят от одного или нескольких элементов модели, которыми владеет пакет Y. При этом вовсе не подразумевается, что все элементы пакетов находятся в данном отношении — достаточно наличия одной пары.

Слайд 21

Управление моделями
Существуют два специальных стандартных стереотипа отношения зависимости — «access» и

«import», которые имеют сходное назначение, но различаются в некоторых деталях.
В обоих случаях это отношение зависимости между пакетами, которое указывает на то, что зависимый пакет имеет доступ к открытым элементам независимого пакета (т. е. зависимый пакет "видит" открытое содержимое независимого пакета).
Различие между ними в том, что использование зависимости «access» не влияет на пространство имен зависимого пакета — для доступа к элементу независимого пакета нужно указывать составное имя, а при использовании зависимости «import» происходит расширение пространства имен зависимого пакета пространством имен независимого пакета.

Слайд 22

Управление моделями
Хотя пакеты не являются классификаторами, тем не менее для них

можно указать отношение обобщения.
Обычно отношение обобщения для пакетов применяется в следующей ситуации. Допустим, что имеется несколько однородных в некотором смысле пакетов, например, несколько альтернативных вариантов реализации одной и той же функциональности. В таком случае можно определить в модели абстрактный пакет, который обобщает конкретные варианты.

Слайд 23

Управление моделями
Например, на рисунке. представлена одна из возможных структур пакетов информационной

системы отдела кадров, касающаяся управления данными.
Пакеты Personnel Management и Staff Management зависят от абстрактного пакета Data Management, который является обобщением пакетов Database Management и Files Management.

Слайд 24

Управление моделями
Спецификация UML предусматривает довольно большое число стандартных стереотипов для пакетов,
«facade»

Пакет, который содержит только ссылки на элементы, определенные в других пакетах. Используется для описания "внешнего вида" других пакетов.
«framework»
Пакет, содержащий образцы и шаблоны. Используется для описания повторно используемых архитектурных решений.
«metamodel»
Модель, которая описывает другую модель. Например, метамодель UML.
«modelLibrary»
Пакет, содержащий определения элементов моделирования, предназначенных для использования в других пакетах.
«profile»
Пакет, содержащий определения элементов моделирования, предназначенных для моделирования в определенной предметной области.
«systemModel»
Модель, содержащая несколько моделей одной физической системы.
«topLevel»
Пакет, который является конем иерархии вложенности пакетов.

Слайд 25

Управление моделями
UML позволяет придать описанию модели любую структуру — моделирующий субъект

должен приложить определенные мыслительные усилия, чтобы выбрать хорошую структуру, подходящую для данного случая.

Слайд 26

Управление моделями
UML позволяет придать описанию модели любую структуру — моделирующий субъект

Слайд 27

Применение UML
Технологию программирования целесообразно рассматривать в трех аспектах.
• Модель процесса, т.

е. порядок проведения типового проекта по разработке программного обеспечения. Сюда относятся понятия жизненного цикла программного обеспечения, определение модели процесса — выделение в нем фаз, вех, потоков работ и других составляющих. Характерным для данного аспекта является рассмотрение на уровне программирующей организации в целом.

Слайд 28

Применение UML
• Модель команды, т. е. отношения между людьми в процессе

разработки. Сюда относятся определение обязанностей работников — участников процесса, регламенты их взаимодействия, рабочие процедуры и т. п. Характерным для данного аспекта является рассмотрение на уровне группы (команды) или проекта.

Слайд 29

Применение UML
• Дисциплина программирования, т. е. методы создания конкретных артефактов, входящих

в состав программного обеспечения. Сюда относятся описание и применение образцов проектирования, стандарты кодирования, методы тестирования и отладки и т. д. Характерным для данного аспекта является рассмотрение на уровне отдельного работника.

Слайд 30

Применение UML
Задачей технологии программирования является исследование и улучшение процессов разработки программного

обеспечения. При этом можно преследовать различные цели, т. е. улучшать процесс в различных направлениях.

Слайд 31

Применение UML
Приведем несколько примеров задач, исследуемых и решаемых технологией программирования.
• Повышение

надежности программного обеспечения.
• Снижение совокупной стоимости владения программным обеспечением.
• Повышение продуктивности программирования.

Слайд 32

Применение UML
Применение UML оказывает положительное влияние на продуктивность процесса разработки программного

обеспечения. Причина влияния заключается в том, что применение UML унифицирует представления информации в циклах повышения продуктивности. Унификация обеспечивает ускорение прохождения циклов, повышение сохранности, облегчение восприятия и повышение надежности принимаемых решений.
Следует подчеркнуть, что названные причины имеют место, только если UML действительно применяется по существу.

Слайд 33

Применение UML
Применение элементов UML
Первый вопрос, который надлежит поставить перед собой, приступая

к применению UML: чего мы хотим достичь?
Концептуальное моделирование.
Спецификация требований.
Детальное проектирование.

Слайд 34

Концептуальное моделирование
В этом варианте целью моделирования является достижение понимания моделируемой физической

системы (приложения, бизнес-процесса…), ее назначения и области применения.
Уровни понимания:
• первый уровень — когда появляется приятное чувство, что все понял;
• второй уровень — когда можешь повторить сказанное;
• третий уровень — когда можешь найти ошибку.
Для понимания системы на первом уровне моделирование на UML не обязательно — достаточно устного объяснения и, может быть, нескольких наглядных слайдов с картинками. Второй уровень легко достигается с помощью связного текста на естественном языке. Применение UML оправдано, когда нужно достичь третьего уровня — не просто познакомиться с идеей системы, но увидеть ее в целом и, может быть, найти пробелы или ошибки.

Слайд 35

Применение UML
Для концептуального моделирования полные диаграммы использования обязательны, а также желательны

и полезны диаграммы классов (с минимумом подробностей) в объеме словаря предметной области, диаграмма компонентов или размещения для перечисления основных артефактов и, может быть, диаграммы взаимодействия или деятельности для типовых сценариев основных вариантов использования. В некоторых случаях (не во всех, а только в тех, когда это существенно для понимания логики работы приложения) оказываются полезны диаграммы состояний. Очень важно не забыть упомянуть в примечаниях те ключевые аспекты, которые не отражены в графической нотации.
Главные требования к концептуальной модели — обозримость и согласованность.
Диаграмм не должно быть много и они не должны быть сложными, но расхождения в обозначениях и названиях крайне нежелательны.

Слайд 36

Спецификация требований
Основной целью моделирования является получение артефакта, который мог бы послужить

техническим заданием на разработку.
Техническое задание должно определять требования к системе и обеспечивать эффективную проверку того, что требования действительно выполнены. Также как и в случае концептуального проектирования, основой спецификации требований являются диаграммы использования, но их детальность и полнота должны быть существенно выше.

Слайд 37

Спецификация требований
Реализация вариантов использования в форме диаграмм взаимодействия обязательна — это

основа для построения набора тестов приемо-сдаточных испытаний.
На диаграммы использования возлагается значительно большая ответственность, поэтому разрабатывать их необходимо намного тщательнее. Например, если на диаграмме не изображен некоторый вариант использования, то это означает, что система не должна иметь соответствующую функциональность.

Слайд 38

Спецификация требований
В спецификации требований диаграмма компонентов не просто желательна, а обязательна

— техническое задание должно определять, хотя бы на уровне названий, что именно должно быть разработано. Между концептуальной моделью и спецификацией требований нет непроходимой границы — довольно часто концептуальная модель за несколько итераций перерастает в спецификацию требований. По нашим наблюдениям, удовлетворительная спецификация требований оказывается в 3–5 раз объемнее концептуальной модели.

Слайд 39

Циклы продуктивности
С основным циклом последовательного выполнения фаз процесса разработки сопряжены два

внешних цикла движения определенных артефактов.
Цикл, в который вовлечен заказчик, отражает выявление несоответствий требованиям и, тем самым, определяет объем внеплановых изменений.
Цикл, в который вовлечен разработчик, отражает преобразование разработанных компонентов в готовые к применению образцы проектирования и, тем самым, определяет объем повторного использования.

Слайд 40

Циклы продуктивности
UML унифицирует представления артефактов в циклах повышения продуктивности. Унификация обеспечивает

ускорение прохождения циклов, повышение сохранности, облегчение восприятия и повышение надежности принимаемых решений.

Слайд 41

Циклы продуктивности

Слайд 42

Циклы продуктивности
Применение UML оказывает положительное влияние на продуктивность процесса разработки программного

обеспечения.
Причина влияния заключается в том, что применение UML унифицирует представления информации в циклах повышения продуктивности.
Унификация обеспечивает ускорение прохождения
циклов, повышение сохранности, облегчение восприятия и повышение надежности
принимаемых решений.

Слайд 43

Применение UML
"Единственно правильной" модели нет и не может быть. Если программирование

— это искусство, то что говорить об архитектурном проектировании и концептуальном моделировании? Это, видимо, элитарное искусство.
Не переоценивайте возможности инструмента.
Не пренебрегайте возможностями инструмента.
Не переоценивайте собственные возможности
Не пренебрегайте собственными возможностями

Слайд 44

Выводы
7 ± 3 сущности на одной диаграмме.
Диаграмма должна охватываться «одним взглядом».
Управление

моделями – для того, кто моделирует, а не для компьютера.
Нет наилучшего процесса для всех типов проектов и всех типов организаций, но для каждого типа проектов и для каждого типа организаций в отдельности — есть.

Слайд 45

Л.р. 4
Отчёт должен содержать тему и её краткое описание
Отчёт должен содержать

10 диаграмм, описывающих использование, структуру и поведение.
Обязательные диаграммы:
вариантов использования с примечаниями,
диаграмма деятельности с дорожками,
диаграмма классов полная (с интерфейсами),
диаграмма состояний,
диаграммы взаимодействия (минимум 2) с указанием состояний объектов,
7 ± 3 сущности на одной диаграмме.
Приветствуется применение паттернов проектирования

Управление моделями в UML

Содержание

Управление моделямиВ UML определены несколько понятий, которые имеют особое для значение

Управление моделямиПри моделировании наше внимание сосредоточено на описании некоторой части реального

Управление моделямиОдна и та же физическая система может быть описана с

Управление моделямиЕсли физическая система сложна и велика (а именно так обычно

Управление моделямиНапример, информационная система отдела кадров конкретной организации, как физическая система,

Управление моделямиКогда модель достаточно велика, реально возникает проблема управления моделями. Если

Свойства пакета в UML• Отношение владения. Говорят, что пакет владеет объявленными

Свойства пакета в UML• Пространство имен. Каждый пакет в модели образует

Управление моделями Отношение владения Внутри основного прямоугольника фигуры пакета можно помещать

Управление моделямиМодели нуждаются в структуре, в противном случае они не отвечают

Управление моделямиЕсли диаграмма в модели не помещается на экран так, чтобы

Управление моделямиМодель имеет хорошую, удобную для работы структуру, если выполняются следующие

Управление моделями- Ширина ветвления в дереве вложенности пакетов с учетом диаграмм

Управление моделями- Число использующих вхождений элементов модели должно быть ограничено сверху

Управление моделямиПриведенные критерии характеризуют форму модели, но никак не затрагивают ее

Управление моделямиАвторы языка рекомендуют структурировать модель по представлениям. Вслед за ними

Управление моделямиДопустим, что выбрана принципиальная структура пакетов в модели.Пакеты могут находиться

Управление моделямиВложенность пакетов влечет вложенность пространств имен. Всякий элемент модели, определенный

Управление моделямиИндуцированное отношение — это отношение между пакетами, которое просто отражает

Управление моделямиСуществуют два специальных стандартных стереотипа отношения зависимости — «access» и

Управление моделямиХотя пакеты не являются классификаторами, тем не менее для них

Управление моделямиНапример, на рисунке. представлена одна из возможных структур пакетов информационной

Управление моделямиСпецификация UML предусматривает довольно большое число стандартных стереотипов для пакетов,«facade»

Управление моделямиUML позволяет придать описанию модели любую структуру — моделирующий субъект

Управление моделямиUML позволяет придать описанию модели любую структуру — моделирующий субъект

Применение UMLТехнологию программирования целесообразно рассматривать в трех аспектах.• Модель процесса, т.

Применение UML• Модель команды, т. е. отношения между людьми в процессе

Применение UML• Дисциплина программирования, т. е. методы создания конкретных артефактов, входящих

Применение UMLЗадачей технологии программирования является исследование и улучшение процессов разработки программного

Применение UMLПриведем несколько примеров задач, исследуемых и решаемых технологией программирования.• Повышение

Применение UMLПрименение UML оказывает положительное влияние на продуктивность процесса разработки программного

Применение UMLПрименение элементов UMLПервый вопрос, который надлежит поставить перед собой, приступая

Концептуальное моделированиеВ этом варианте целью моделирования является достижение понимания моделируемой физической

Применение UMLДля концептуального моделирования полные диаграммы использования обязательны, а также желательны

Спецификация требованийОсновной целью моделирования является получение артефакта, который мог бы послужить

Спецификация требованийРеализация вариантов использования в форме диаграмм взаимодействия обязательна — это

Спецификация требованийВ спецификации требований диаграмма компонентов не просто желательна, а обязательна

Циклы продуктивностиС основным циклом последовательного выполнения фаз процесса разработки сопряжены два

Циклы продуктивностиUML унифицирует представления артефактов в циклах повышения продуктивности. Унификация обеспечивает

Циклы продуктивности

Циклы продуктивностиПрименение UML оказывает положительное влияние на продуктивность процесса разработки программного

Применение UML"Единственно правильной" модели нет и не может быть. Если программирование

Выводы7 ± 3 сущности на одной диаграмме.Диаграмма должна охватываться «одним взглядом».Управление

Л.р. 4Отчёт должен содержать тему и её краткое описаниеОтчёт должен содержать

Похожие презентации

Управление моделями
В UML определены несколько понятий, которые имеют особое для значение

Управление моделями
При моделировании наше внимание сосредоточено на описании некоторой части реального

Управление моделями
Одна и та же физическая система может быть описана с

Управление моделями
Если физическая система сложна и велика (а именно так обычно

Управление моделями
Например, информационная система отдела кадров конкретной организации, как физическая система,

Управление моделями
Когда модель достаточно велика, реально возникает проблема управления моделями.
Если

Свойства пакета в UML
• Отношение владения.
Говорят, что пакет владеет объявленными

Свойства пакета в UML
• Пространство имен.
Каждый пакет в модели образует

Управление моделями
Отношение владения
Внутри основного прямоугольника фигуры пакета можно помещать

Управление моделями
Модели нуждаются в структуре, в противном случае они не отвечают

Управление моделями
Если диаграмма в модели не помещается на экран так, чтобы

Управление моделями
Модель имеет хорошую, удобную для работы структуру, если выполняются следующие

Управление моделями
- Ширина ветвления в дереве вложенности пакетов с учетом диаграмм

Управление моделями
- Число использующих вхождений элементов модели должно быть ограничено сверху

Управление моделями
Приведенные критерии характеризуют форму модели, но никак не затрагивают ее

Управление моделями
Авторы языка рекомендуют структурировать модель по представлениям. Вслед за ними

Управление моделями
Допустим, что выбрана принципиальная структура пакетов в модели.
Пакеты могут находиться

Управление моделями
Вложенность пакетов влечет вложенность пространств имен. Всякий элемент модели, определенный

Управление моделями
Индуцированное отношение — это отношение между пакетами, которое просто отражает

Управление моделями
Существуют два специальных стандартных стереотипа отношения зависимости — «access» и

Управление моделями
Хотя пакеты не являются классификаторами, тем не менее для них

Управление моделями
Например, на рисунке. представлена одна из возможных структур пакетов информационной

Управление моделями
Спецификация UML предусматривает довольно большое число стандартных стереотипов для пакетов,
«facade»

Управление моделями
UML позволяет придать описанию модели любую структуру — моделирующий субъект

Управление моделями
UML позволяет придать описанию модели любую структуру — моделирующий субъект

Применение UML
Технологию программирования целесообразно рассматривать в трех аспектах.
• Модель процесса, т.

Применение UML
• Модель команды, т. е. отношения между людьми в процессе

Применение UML
• Дисциплина программирования, т. е. методы создания конкретных артефактов, входящих

Применение UML
Задачей технологии программирования является исследование и улучшение процессов разработки программного

Применение UML
Приведем несколько примеров задач, исследуемых и решаемых технологией программирования.
• Повышение

Применение UML
Применение UML оказывает положительное влияние на продуктивность процесса разработки программного

Применение UML
Применение элементов UML
Первый вопрос, который надлежит поставить перед собой, приступая

Концептуальное моделирование
В этом варианте целью моделирования является достижение понимания моделируемой физической

Применение UML
Для концептуального моделирования полные диаграммы использования обязательны, а также желательны

Спецификация требований
Основной целью моделирования является получение артефакта, который мог бы послужить

Спецификация требований
Реализация вариантов использования в форме диаграмм взаимодействия обязательна — это

Спецификация требований
В спецификации требований диаграмма компонентов не просто желательна, а обязательна

Циклы продуктивности
С основным циклом последовательного выполнения фаз процесса разработки сопряжены два

Циклы продуктивности
UML унифицирует представления артефактов в циклах повышения продуктивности. Унификация обеспечивает

Циклы продуктивности
Применение UML оказывает положительное влияние на продуктивность процесса разработки программного

Применение UML
"Единственно правильной" модели нет и не может быть. Если программирование

Выводы
7 ± 3 сущности на одной диаграмме.
Диаграмма должна охватываться «одним взглядом».
Управление

Л.р. 4
Отчёт должен содержать тему и её краткое описание
Отчёт должен содержать