Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 8
Описание файла
PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 8 страницы из PDF
Модель – это хранилище всех сущностей и отношений, созданных дляописания требуемого поведения проектируемой программной системы.Диаграммы – это своего рода картины, или представления модели.Диаграмма это не модель! На самом деле, различие между диаграммойи моделью является очень важным для понимания, поскольку сущность или отношение могут быть удалены с диаграммы, или даже совсех диаграмм, но попрежнему они продолжают существовать в модели. Они будут оставаться в модели до тех пор, пока не будут явно удалены из нее.
Общая ошибка новичков в UMLмоделировании состоитв том, что они удаляют сущности с диаграмм, не удаляя их из модели.Существует тринадцать различных типов UMLдиаграмм, все они приведены на рис. 1.6. На рисунке каждый прямоугольник представляетопределенный тип диаграммы, при этом курсивом выделяются абстрактные категории типов диаграмм.
Например, существует шесть разных типов Диаграмм структуры. Обычный текст указывает на конкретную диаграмму, которую можно реально создать. Заштрихованныеблоки обозначают типы диаграмм, впервые появившиеся в UML 2.34Глава 1. Что такое UML?ДиаграммаДиаграммаструктурыДиаграммаклассовДиаграммаповеденияДиаграмма ДиаграммаДиаграммаДиаграмма Диаграммасоставных компонентов развертывания объектовпакетовструктурДиаграммадеятель!ностиДиаграммавзаимо!действияДиаграмма Диаграммапреце!состоянийдентов(конечныхавтоматов)ДиаграммаКоммуникационнаяДиаграммапоследовательностидиаграммаобзора взаимодействийВременнаядиаграммаРис. 1.6.
Типы UML+диаграммЭти диаграммы можно разделить на те, которые моделируют статическую структуру системы (статическую модель), и те, которые моделируют динамическую структуру системы (динамическую модель). Статическая модель фиксирует сущности и структурные отношения между ними; динамическая модель отображает, как сущности взаимодействуютдля генерирования требуемого поведения программной системы. Статическая и динамическая модели рассматриваются начиная с части 2.Определенного порядка создания UMLдиаграмм не существует, хотяобычно начинают с диаграммы прецедентов для определения предметной области системы. Как правило, работа идет одновременно над несколькими диаграммами, каждая из которых уточняется по мере выявления более подробной информации о разрабатываемой программнойсистеме.
Таким образом, диаграммы являются как представлением модели, так и основным механизмом введения информации в модель.В UML 2 представлен новый синтаксис диаграмм, изображенный нарис. 1.7. У каждой диаграммы может быть рамка, область заголовкаи область содержимого.
Область заголовка – это неправильный пятиугольник, содержащий тип (не обязательно), имя и параметры (не обязательно) диаграммы.рамказаголовокобласть содержимогосинтаксис заголовка: <тип> <имя> <параметры>особое внимание: <тип> и <параметры> необязательныРис. 1.7. Синтаксис UML+диаграмм351.9. Общие механизмы UMLусловная рамкаРис. 1.8. Пример диаграммы<Тип> указывает тип данной диаграммы и должен быть одним из типов, перечисленных на рис. 1.6. Спецификация UML определяет, что<тип> может быть сокращен, но не предоставляет списка стандартныхсокращений.
Явное задание <типа> требуется редко, потому что егообычно легко определить из визуального синтаксиса.<Имя> должно описывать семантику диаграммы (например, CourseRegistration (регистрация курса)). <Параметры> предоставляют информацию,необходимую элементам модели, представленным на диаграмме.
Примеры использования <параметров> будут приведены позже.У диаграммы может быть (не обязательно) условная рамка, ограничивающая область в инструменте моделирования, внутри которой находится диаграмма. Пример условной рамки приведен на рис. 1.8.1.9. Общие механизмы UMLВ UML существует четыре общих механизма, последовательно применяемых ко всему языку моделирования. Они описывают четыре стратегии подхода к моделированию объектов, которые в разных контекстах многократно применяются в UML. Это еще раз убеждает нас в простоте и элегантности структуры UML (рис.
1.9).36Глава 1. Что такое UML?Общие механизмыПринятыеделенияСпецификацииДополненияМеханизмырасширенияРис. 1.9. Общие механизмы UML1.9.1. СпецификацииСпецификации – это суть UMLмодели. Они обеспечивают семантический задний план модели.Модели UML имеют, по крайней мере, два измерения: графическое,позволяющее визуализировать модель с помощью диаграмм и пиктограмм, и текстовое, состоящее из спецификаций различных элементовмодели.
Спецификации – это текстовые описания семантики элемента.Класс, например BankAccount (банковский счет), можно изобразить в виде прямоугольника с ячейками (рис. 1.10), но это представление ничего не сообщает о бизнессемантике этого класса. Семантика элементовмодели фиксируется в спецификациях; без них можно только догадываться, что на самом деле представляет собой элемент.Набор спецификаций – это суть модели. Спецификации формируют се+мантический задний план (semantic backplane), который объединяетмодель и наполняет ее смыслом. Различные диаграммы – это простопредставления или визуальные проекции этого плана.BankAccountпиктограммаили элементмоделиaccountNumberownerbalanceСемантический задний планСпецификация классаwithdraw()calculateInterest()deposit()DepositСпецификация прецедентовСпецификация зависимостейРис. 1.10.
Семантический задний план1.9. Общие механизмы UML37Семантический задний план обычно сопровождается инструментоммоделирования UML, предоставляющим доступ, просмотр и изменение спецификаций каждого элемента модели.Диаграммы обеспечивают представления семантического заднего плана.UML обеспечивает большую гибкость при создании моделей. В частности, модели могут быть:•сокращенными – некоторые элементы присутствуют в заднем плане,но скрыты в той или иной диаграмме для упрощения представления;•неполными – некоторые элементы модели могут быть полностьюпропущены;•несогласованными – модель может содержать противоречия.Здесь важен сам факт ослабления требований к полноте и согласованности, поскольку, как вы заметите, со временем модель эволюционирует и неоднократно подвергается изменениям.
Однако развитие всегда происходит по направлению к согласованным моделям, достаточ+но полным для создания программной системы.Разработку моделей с помощью UML, как правило, начинают с графической модели, которая позволяет визуализировать систему, а затемпо мере ее развития добавляют в задний план все больше и больше семантики. Однако модель можно считать полезной или полной, толькоесли семантика модели присутствует в семантическом заднем плане.В противном случае модели не существует, есть просто бессмысленный набор блоков и пятен, соединенных линиями! Кстати, общуюошибку, совершаемую новичками в разработке моделей, можно назвать «смерть от диаграмм»: модель переполнена диаграммами, но недоопределена.1.9.2.
ДополненияВ UML каждый элемент модели обозначается простым символом, к которому можно добавлять ряд дополнений, визуализирующих аспектыспецификации элемента. С помощью этого механизма видимая на диаграмме информация может быть представлена в соответствиис конкретными требованиями.Мы дополняем элементы модели на UMLдиаграммах, чтобы подчеркнуть важные детали.Начинать можно с создания высокоуровневой диаграммы, использующей только основные символы с одним или двумя дополнениями.Со временем диаграмма уточняется путем добавления все большегои большего количества дополнений до тех пор, пока не станет достаточно подробной.38Глава 1.
Что такое UML?Важно помнить, что любая UMLдиаграмма – это только представлениемодели, и поэтому необходимо показывать лишь те дополнения, которые подчеркивают важные характеристики модели и делают диаграмму более понятной и удобочитаемой. Обычно нет необходимости показывать на диаграмме все до мельчайших подробностей. Важнее то,чтобы диаграмма была понятной, иллюстрировала именно те аспекты,которые требуется, и была легкой для восприятия.На рис. 1.11 показано, что минимальным представлением класса является прямоугольник с именем класса. Однако различные детали базовой модели могут быть раскрыты в виде дополнений, расширяющихэто минимальное представление. Возможные необязательные дополнения выделены на рисунке серым цветом.Window{author = Jim, status = tested}Windowэлемент без дополнений+size : Area=(100,100)# visibility : Boolean = false+ defaultSize : Rectangle#maximumSize : Rectangle!xptr : XWindow*+create()+hide()+display( location : Point )!attachXWindow(xwin : XWindow*)элемент с дополнениямиРис.