13. Физические диаграммы. [1/2]
Диаграмма размещения. Предназначена для анализа аппаратной части системы. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на которой будет работать отдельные процессы системы и описать их взаимодействие между собой и другими аппаратными устройствами. Этот тип диаграмм так же позволяет анализировать взаимодействие процессов, работающих на разных компьютерных сетях.
Основные элементы:
1. Процессор (processor) – это устройство способное выполнять программы. Процессор обязательно должен иметь свое имя, которое ни как не связано с другими диаграммами модели по причине того, что процессор обозначает не программное обеспечение, а аппаратуру;
2. Устройство (device) – обозначает устройство не способное выполнять программы;
3. Соединение (connection) – данный инструмент позволяет связать между собой устройства и процессоры. Соединение представляет собой некоторый тип кабельного или другого соединения. В отличии от реального соединения на диаграмме не может быть показано направление перемещения информации по средствам соединения и считается что соединение всегда двунаправленное.
Диаграмма компонентов. Диаграмма компонентов позволяет создать физическое отражение текущей модели, показывает организацию и взаимосвязи программы компонентов, представленных в исходном коде двоичных или выполняемых файлов. Связи в данном типе диаграммы представляют зависимости одного компонента от другого и имею специальное отражение через «значок» зависимости. Так же данный тип диаграмм позволяет получить представление о поведении компонентов по предоставляемому им интерфейсу.
Компоненты представляют собой модуль ПО, такой как исходный код, двоичный код, выполняемый файл, библиотеки и т.д. Компоненты так же могут использоваться для показа взаимосвязей модулей на этапе компиляции или выполнения программы, а так же показывают какие классы используются для создания конкретных компонентов. В связи с тем что система может состоять из модулей различного типа, пользователь может использовать стереотипы для определения этих различий, что часто ведет к изменению графического отображения компонента на диаграмме.
*13. Физические диаграммы. [2/2]
В отличии от других диаграмм при создании элементов диаграмм компонента в модель всегда добавляется один тип элементов компонент, который отличается только стереотипом. Для каждого компонента должен быть задан язык программирования.
- - - - - - - - - - - - > Dependency
Этот тип связи показывает, что классы, содержащиеся в контейнере – клиенте наследуются: содержит элементы, используется каким либо другим образом, зависит от класса, который экспортируется из контейнера сервера.
14. История развития, назначение, общая структура языка uml [1/2].
История развития языка UML начинается с 1994 г, когда Crady Booch и James Rumbadr из Rational Software Corporation начали работу по унификации методов Booch и OMT.
Проект унифицированного метода был подготовлен и опубликован в октябре 1995 г. Осенью того же года к ним присоединился Jvar Jacobson – главный технолог из компании Objectory AB с целью интеграции своего метода OOSE с двумя предыдущими. Начиная работу по унификации своих методов Booch, Rumbandr и Jacobson сформировали следующие требования к языку моделирования:
он должен
позволять моделировать не только ПО, но и более широкие планы систем и бизнес-приложений с использованием объектно-оринетированных понятий;
явным образом обеспечивать взаимосвязь между базовыми понятиями для моделей концептуального и физического уровня
обеспечивать масштабируемость моделей, что является важной особенностью сложных систем;
быть понятен аналитикам и программистам, а так же поддерживаться специальными инструментальными средствами, реализованных на различных платформах.
UML – Unified Modeling Language
UML предназначен для решения следующих задач:
Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования.
Снабдить исходное понятие языка UML возможностью расширения и специализации для более точного представления моделей систем конкретной предметной области.
Описание языка UML должно поддерживать такую специализацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств.
Описание языка UML должно включать в себя семантический базис для понимания общих особенностей объектно-ориентированного анализа и проектирования.
*14. История развития, назначение, общая структура языка UML [2/2].
Способствует распространению объектных технологий.
Интегрировать себя новейшие и наилучшие достижения практики объектно-ориентированного анализа и проектирования.
Структура языка UML состоит из 2х взаимосвязанных частей:
Семантика языка.
Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.
Нотация языка UML.
Представляет собой графическую нотацию для визуального представления семантики языка UML.