Нельзя же вечно быть любезным и обходительным. Не успеваешь, просто не успеваешь...
последние 10 вопросов
50. Диаграмма классов.
Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.
Графически в самом общем виде класс представляется в виде прямоугольника с четырьмя секциями. Любая из секций, кроме секции имени класса, может отсутствовать. В этом случае она не изображается либо оставляется пустой. Как правило, на начальном этапе проектирования разработчик располагает только общими представлениями о будущей структуре системы. В дальнейшем, по мере разработки, уточняются роли, свойства каждого класса, что находит отражение на соответствующих диаграммах классов.
Свойства класса определяют состояние экземпляров класса. В общем виде формат записи свойства можно представить в виде строки:
видимость имя_свойства [кратность]: тип_свойства = значение_по_умолчанию
Отсутствие указания на категорию доступа означает, что видимость не указывается.
Методы класса служат для обработки свойств класса и характеризуют поведение экземпляров класса.
Формат записи метода выглядит так:
видимость имя_метода (список параметров): тип_значения {строка-свойство}
51. Диаграмма объектов
Диаграммы объектов позволяют моделировать экземпляры сущностей, которые содержатся в диаграммах классов. На диаграмме объектов показано множество объектов и отношений между ними в некоторый момент времени.
Диаграммы объектов применяют при моделировании статических видов системы с точки зрения проектирования и процессов. При этом моделируется "снимок" системы в данный момент времени и изображается множество объектов, их состояний и отношений между ними.
Диаграммы объектов важны не только для визуализации, специфицирования и документирования структурных моделей, но и для конструирования статических аспектов системы с помощью прямого и обратного проектирования.
Диаграммой объектов (Object diagram) называется диаграмма, на которой показаны объекты и их отношения в некоторый момент времени. Графически диаграмму объектов представляют в виде графа, состоящего из вершин и ребер.
Диаграмма объектов - это частный случай диаграммы, она имеет те же общие свойства, что и прочие диаграммы, а именно название и графическое содержание, являющееся проекцией модели. От остальных диаграмму объектов отличает ее
Диаграммы объектов, как правило, содержат:
• объекты
• связи
Диаграммы объектов, как и все прочие диаграммы, могут включать в себя примечания и ограничения.
Они могут содержать также пакеты и подсистемы , используемые для группирования элементов модели в более крупные блоки. Иногда в них помещают и классы, особенно если надо визуализировать классы, стоящие за каждым экземпляром.
52. Диаграмма компонентов.
Информационные системы на уровне программного кода могут состоять из множества приложений, справочных файлов, исходных текстов, веб-документов, динамических библиотек. То, как именно будут распределены классы и их экземпляры по файлам, а также взаимосвязи между файлами позволяют отобразить диаграммы компонентов.
Иногда перед именем компонента указывается его спецификация:
• library – библиотека;
• table – база данных, отдельная таблица;
• file – исходный текст программ;
• document – документ;
• executable – исполняемый файл.
53. Диаграмма вариантов использования = Диаграмма прецедентов.
Диаграмма прецедентов служит для выявления и формального представления требований заказчика к проектируемой системе, то есть она описывает, какие возможности будет представлять система конечному пользователю, какая информация необходима для обработки запроса пользователя. При этом механизм функционирования системы от пользователя скрыт и на диаграмме прецедентов не показывается.
Между компонентами диаграммы прецедентов могут существовать различные отношения. Отношения могут быть между пользователями и прецедентами, между несколькими пользователями. Пользователь может взаимодействовать с несколькими прецедентами.
• Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом .
• Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать.
• Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента..
• Отношение включения (include relationship) указывает на включение прецедента в другой прецедент в качестве его составной части. Один и тот же прецедент может быть включен в несколько более крупных прецедентов.
На диаграммах прецедентов не указывается, в какой последовательности выполняются операции. Данная информация может содержаться на диаграммах активности, взаимодействия и состояний.
54. Диаграмма последовательности.
Идеология объектно-ориентированного программирования заключается в описании поставленной задачи образами некоторых самостоятельных сущностей (объектов), которые в процессе функционирования системы обмениваются сообщениями. Диаграммы последовательности служат инструментом отображения такого обмена.
Основными компонентами диаграмм последовательности являются пользователь, объект, линия жизни объекта (object lifeline), сообщение (message) и фокус управления (focus of control). Объект графически изображается, как и на других UML-диаграммах, прямоугольником с подчеркнутым именем, линия жизни объекта – вертикальной пунктирной линией, сообщение – горизонтальной стрелкой, фокус управления – прямоугольником на линии жизни объекта.
Сообщения на диаграммах последовательности могут быть помечены идентификаторами, поясняющими их смысловую нагрузку (стереотипы):
• «call» – вызов объектом другого объекта;
• «return» – возврат значения вызвавшему объекту;
• «create» – создание объекта;
• «destroy» – уничтожение объекта, которому передается это сообщение;
• «send» – посылка асинхронного сигнала.
55. Диаграмма взаимодействия.
Диаграмма сотрудничества, как и диаграмма последовательности, является разновидностью диаграмм взаимодействия. Современные программные средства построения диаграмм обеспечивают автоматическое преобразование диаграмм данных видов друг в друга.
Если диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия, то диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность-связь.
Диаграммы сотрудничества бывают двух видов.
• Диаграммы сотрудничества уровня спецификаций оперируют классами, пользователями, кооперациями и ролями, которые играют пользователи и классы.
• Диаграммы сотрудничества уровня примеров оперируют экземплярами классов (объектами), связями между ними и сообщениями, которыми обмениваются объекты.
56. Диаграмма состояний.
В процессе функционирования информационной системы свойства объектов системы будут принимать различные значения, а объекты системы – различные состояния. Состояния объектов, переходы объектов из одного состояния в другое, сообщения, которыми обмениваются объекты, составляют динамическую составляющую информационной системы.
Диаграмма состояний описывает процесс изменения одного класса, а точнее – одного экземпляра класса. На диаграмме отражаются состояния и переходы между состояниями объекта под воздействием внешних факторов.
Состояния (states) на диаграмме состояний показываются прямоугольниками с закругленными вершинами. В каждом таком прямоугольнике может быть одна (обязательная) секция, в которой записывается имя состояния (для имени рекомендуется использовать глаголы, причастия и деепричастия), и несколько других секций, обозначающих действия объекта в этом состоянии.
Начальное состояние изображается черным кружком, конечное – черным кружком в белом кольце. На диаграмме, показанной на рис. 3.20, объект из начального состояния переходит в некоторое другое состояние, в котором выполняется действие 1, а затем – в конечное состояние.
Начальное и конечное состояния могут отсутствовать. Примером отсутствия конечного состояния может служить система, которая запускается один раз, а дальше функционирует в непрерывном режиме. Примером отсутствия начального состояния может служить функционирующая система, неизвестно когда возникшая. Примером отсутствия как конечного, так и начального состояний могут служить циклические изменения какого-либо объекта.
57. Диаграмма деятельности = Диаграмма активности.
Диаграммы активности позволяют показать движения потоков данных в проектируемой системе.
Диаграммы активности напоминают хорошо знакомые многим алгоритмы, только несколько модифицированные.
Действие может содержать несколько поддействий. Если на диаграмме их показывать нецелесообразно, используют обозначение вложенности действий. Так, в приведенном примере действие Удовлетворение заявки включает в себя несколько поддействий, среди которых могут быть оценка достоверности данных о клиенте, оценка правильности расчетов, непосредственно принятие решения.
Движение данных (переходы) изображается сплошными стрелками. Возле стрелок может быть указано сторожевое условие. Если движение данных предусматривает ветвление, то указание условия обязательно (в примере на рис. 3.28 оно не показано). Символ ветвления графически изображается ромбом, из которого выходят две или более стрелки. Разделение потока данных и слияние параллельных потоков данных изображается сплошной жирной чертой, связывающей стрелки движения потоков данных.
Диаграммы активности позволяют показать разделение ответственности различных субъектов за выполнение операций путем введения дорожек (swimlanes). В приведенном примере таких дорожек четыре: Регистратор, Специалист по финансовым рискам, Управляющий, Служба безопасности.
Передаваемые данные могут быть указаны на диаграммах активности в явном виде.
Вектор времени на диаграммах активности в явном виде не воспроизводится.
58. Диаграммы размещения (deployment diagrams) = Диаграмма развертывания.
Диаграммы развертывания служат для иллюстрации физического размещения информационной системы на серверах, компьютерах пользователей, искусственных спутниках земли, поездах, морских судах, внутри ЭВМ, отображения физических каналов передачи информации между компонентами информационной системы.
Основным обозначением, используемым на диаграммах данного вида, является узел (node), который графически изображается аксонометрической проекцией куба. Внутри обозначения узла указывается его имя (например, Сервер) и развертываемые на нем компоненты, изображаемые так же, как на диаграмме компонентов.
Между узлами сплошными линиями показывают соединения, которые могут содержать пояснения относительно характера реализации связи между компонентами.
59. Пакеты.
Для сложных систем возникает необходимость разбиения их на несколько составляющих, причем таким образом, чтобы это разбиение отражалось в обозначении компонентов. Для этих целей в языке UML служат пакеты (рис. 3.7).
Рис. 3.7. Графическое изображение пакета.
Компоненты, относящиеся к определенному пакету, могут быть доступны вне пакета, если указать имя компонента и его принадлежность определенному пакету через двойное двоеточие, например:
Имя_Пакета::Имя_Компонента
Эта запись означает, что пакет образует собственное пространство имен.
Как правило, элементы модели, входящие в пакет, логически связаны между собой.
Если количество классов в системе достаточно велико, иногда прибегают к построению диаграмм пакетов, разбивая систему на части на более высоком уровне, чем диаграммы классов.
60. Диаграмма артефактов.
Артефакт – это физическая часть системы, которая существует на уровне платформы реализации.
Виды артефактов:
- артефакты размещения ( необходимы для формирования выполняемой системы);
- артефакты рабочих продуктов (представляют собой результат процесса разработки);
- артефакты исполнения ( создаются в результате работы системы).
Моделирование артефактов помогает визуализировать, специализировать, конструировать и документировать принятые решения относительно ее физической реализации. Еще более важно моделирование артефактов, если требуется контролировать версии и управлять конфигурацией частей системы.
50. Диаграмма классов.
Под классом в языке UML понимается множество объектов, обладающих одинаковой структурой, свойствами, отношениями с другими объектами.
Графически в самом общем виде класс представляется в виде прямоугольника с четырьмя секциями. Любая из секций, кроме секции имени класса, может отсутствовать. В этом случае она не изображается либо оставляется пустой. Как правило, на начальном этапе проектирования разработчик располагает только общими представлениями о будущей структуре системы. В дальнейшем, по мере разработки, уточняются роли, свойства каждого класса, что находит отражение на соответствующих диаграммах классов.
Свойства класса определяют состояние экземпляров класса. В общем виде формат записи свойства можно представить в виде строки:
видимость имя_свойства [кратность]: тип_свойства = значение_по_умолчанию
Отсутствие указания на категорию доступа означает, что видимость не указывается.
Методы класса служат для обработки свойств класса и характеризуют поведение экземпляров класса.
Формат записи метода выглядит так:
видимость имя_метода (список параметров): тип_значения {строка-свойство}
51. Диаграмма объектов
Диаграммы объектов позволяют моделировать экземпляры сущностей, которые содержатся в диаграммах классов. На диаграмме объектов показано множество объектов и отношений между ними в некоторый момент времени.
Диаграммы объектов применяют при моделировании статических видов системы с точки зрения проектирования и процессов. При этом моделируется "снимок" системы в данный момент времени и изображается множество объектов, их состояний и отношений между ними.
Диаграммы объектов важны не только для визуализации, специфицирования и документирования структурных моделей, но и для конструирования статических аспектов системы с помощью прямого и обратного проектирования.
Диаграммой объектов (Object diagram) называется диаграмма, на которой показаны объекты и их отношения в некоторый момент времени. Графически диаграмму объектов представляют в виде графа, состоящего из вершин и ребер.
Диаграмма объектов - это частный случай диаграммы, она имеет те же общие свойства, что и прочие диаграммы, а именно название и графическое содержание, являющееся проекцией модели. От остальных диаграмму объектов отличает ее
Диаграммы объектов, как правило, содержат:
• объекты
• связи
Диаграммы объектов, как и все прочие диаграммы, могут включать в себя примечания и ограничения.
Они могут содержать также пакеты и подсистемы , используемые для группирования элементов модели в более крупные блоки. Иногда в них помещают и классы, особенно если надо визуализировать классы, стоящие за каждым экземпляром.
52. Диаграмма компонентов.
Информационные системы на уровне программного кода могут состоять из множества приложений, справочных файлов, исходных текстов, веб-документов, динамических библиотек. То, как именно будут распределены классы и их экземпляры по файлам, а также взаимосвязи между файлами позволяют отобразить диаграммы компонентов.
Иногда перед именем компонента указывается его спецификация:
• library – библиотека;
• table – база данных, отдельная таблица;
• file – исходный текст программ;
• document – документ;
• executable – исполняемый файл.
53. Диаграмма вариантов использования = Диаграмма прецедентов.
Диаграмма прецедентов служит для выявления и формального представления требований заказчика к проектируемой системе, то есть она описывает, какие возможности будет представлять система конечному пользователю, какая информация необходима для обработки запроса пользователя. При этом механизм функционирования системы от пользователя скрыт и на диаграмме прецедентов не показывается.
Между компонентами диаграммы прецедентов могут существовать различные отношения. Отношения могут быть между пользователями и прецедентами, между несколькими пользователями. Пользователь может взаимодействовать с несколькими прецедентами.
• Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом .
• Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать.
• Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента..
• Отношение включения (include relationship) указывает на включение прецедента в другой прецедент в качестве его составной части. Один и тот же прецедент может быть включен в несколько более крупных прецедентов.
На диаграммах прецедентов не указывается, в какой последовательности выполняются операции. Данная информация может содержаться на диаграммах активности, взаимодействия и состояний.
54. Диаграмма последовательности.
Идеология объектно-ориентированного программирования заключается в описании поставленной задачи образами некоторых самостоятельных сущностей (объектов), которые в процессе функционирования системы обмениваются сообщениями. Диаграммы последовательности служат инструментом отображения такого обмена.
Основными компонентами диаграмм последовательности являются пользователь, объект, линия жизни объекта (object lifeline), сообщение (message) и фокус управления (focus of control). Объект графически изображается, как и на других UML-диаграммах, прямоугольником с подчеркнутым именем, линия жизни объекта – вертикальной пунктирной линией, сообщение – горизонтальной стрелкой, фокус управления – прямоугольником на линии жизни объекта.
Сообщения на диаграммах последовательности могут быть помечены идентификаторами, поясняющими их смысловую нагрузку (стереотипы):
• «call» – вызов объектом другого объекта;
• «return» – возврат значения вызвавшему объекту;
• «create» – создание объекта;
• «destroy» – уничтожение объекта, которому передается это сообщение;
• «send» – посылка асинхронного сигнала.
55. Диаграмма взаимодействия.
Диаграмма сотрудничества, как и диаграмма последовательности, является разновидностью диаграмм взаимодействия. Современные программные средства построения диаграмм обеспечивают автоматическое преобразование диаграмм данных видов друг в друга.
Если диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия, то диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность-связь.
Диаграммы сотрудничества бывают двух видов.
• Диаграммы сотрудничества уровня спецификаций оперируют классами, пользователями, кооперациями и ролями, которые играют пользователи и классы.
• Диаграммы сотрудничества уровня примеров оперируют экземплярами классов (объектами), связями между ними и сообщениями, которыми обмениваются объекты.
56. Диаграмма состояний.
В процессе функционирования информационной системы свойства объектов системы будут принимать различные значения, а объекты системы – различные состояния. Состояния объектов, переходы объектов из одного состояния в другое, сообщения, которыми обмениваются объекты, составляют динамическую составляющую информационной системы.
Диаграмма состояний описывает процесс изменения одного класса, а точнее – одного экземпляра класса. На диаграмме отражаются состояния и переходы между состояниями объекта под воздействием внешних факторов.
Состояния (states) на диаграмме состояний показываются прямоугольниками с закругленными вершинами. В каждом таком прямоугольнике может быть одна (обязательная) секция, в которой записывается имя состояния (для имени рекомендуется использовать глаголы, причастия и деепричастия), и несколько других секций, обозначающих действия объекта в этом состоянии.
Начальное состояние изображается черным кружком, конечное – черным кружком в белом кольце. На диаграмме, показанной на рис. 3.20, объект из начального состояния переходит в некоторое другое состояние, в котором выполняется действие 1, а затем – в конечное состояние.
Начальное и конечное состояния могут отсутствовать. Примером отсутствия конечного состояния может служить система, которая запускается один раз, а дальше функционирует в непрерывном режиме. Примером отсутствия начального состояния может служить функционирующая система, неизвестно когда возникшая. Примером отсутствия как конечного, так и начального состояний могут служить циклические изменения какого-либо объекта.
57. Диаграмма деятельности = Диаграмма активности.
Диаграммы активности позволяют показать движения потоков данных в проектируемой системе.
Диаграммы активности напоминают хорошо знакомые многим алгоритмы, только несколько модифицированные.
Действие может содержать несколько поддействий. Если на диаграмме их показывать нецелесообразно, используют обозначение вложенности действий. Так, в приведенном примере действие Удовлетворение заявки включает в себя несколько поддействий, среди которых могут быть оценка достоверности данных о клиенте, оценка правильности расчетов, непосредственно принятие решения.
Движение данных (переходы) изображается сплошными стрелками. Возле стрелок может быть указано сторожевое условие. Если движение данных предусматривает ветвление, то указание условия обязательно (в примере на рис. 3.28 оно не показано). Символ ветвления графически изображается ромбом, из которого выходят две или более стрелки. Разделение потока данных и слияние параллельных потоков данных изображается сплошной жирной чертой, связывающей стрелки движения потоков данных.
Диаграммы активности позволяют показать разделение ответственности различных субъектов за выполнение операций путем введения дорожек (swimlanes). В приведенном примере таких дорожек четыре: Регистратор, Специалист по финансовым рискам, Управляющий, Служба безопасности.
Передаваемые данные могут быть указаны на диаграммах активности в явном виде.
Вектор времени на диаграммах активности в явном виде не воспроизводится.
58. Диаграммы размещения (deployment diagrams) = Диаграмма развертывания.
Диаграммы развертывания служат для иллюстрации физического размещения информационной системы на серверах, компьютерах пользователей, искусственных спутниках земли, поездах, морских судах, внутри ЭВМ, отображения физических каналов передачи информации между компонентами информационной системы.
Основным обозначением, используемым на диаграммах данного вида, является узел (node), который графически изображается аксонометрической проекцией куба. Внутри обозначения узла указывается его имя (например, Сервер) и развертываемые на нем компоненты, изображаемые так же, как на диаграмме компонентов.
Между узлами сплошными линиями показывают соединения, которые могут содержать пояснения относительно характера реализации связи между компонентами.
59. Пакеты.
Для сложных систем возникает необходимость разбиения их на несколько составляющих, причем таким образом, чтобы это разбиение отражалось в обозначении компонентов. Для этих целей в языке UML служат пакеты (рис. 3.7).
Рис. 3.7. Графическое изображение пакета.
Компоненты, относящиеся к определенному пакету, могут быть доступны вне пакета, если указать имя компонента и его принадлежность определенному пакету через двойное двоеточие, например:
Имя_Пакета::Имя_Компонента
Эта запись означает, что пакет образует собственное пространство имен.
Как правило, элементы модели, входящие в пакет, логически связаны между собой.
Если количество классов в системе достаточно велико, иногда прибегают к построению диаграмм пакетов, разбивая систему на части на более высоком уровне, чем диаграммы классов.
60. Диаграмма артефактов.
Артефакт – это физическая часть системы, которая существует на уровне платформы реализации.
Виды артефактов:
- артефакты размещения ( необходимы для формирования выполняемой системы);
- артефакты рабочих продуктов (представляют собой результат процесса разработки);
- артефакты исполнения ( создаются в результате работы системы).
Моделирование артефактов помогает визуализировать, специализировать, конструировать и документировать принятые решения относительно ее физической реализации. Еще более важно моделирование артефактов, если требуется контролировать версии и управлять конфигурацией частей системы.