2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 24
Текст из файла (страница 24)
Диаграммы компонентов и диаграммы размещения похожи на диаграммы классов, за исключением тогочто вместо классов они содержат соответственно компонентыи узлы.Стандартное использованиеВы используете диаграммы классов для моделирования статического представления системы. Это представление, прежде всего,поддерживает ее функциональные требования, то есть описываетуслуги, которые система должна предоставлять ее конечным пользователям.Прорабатывая статическое представление системы, вы обычноМоделироваиспользуете диаграммы классов с одной из трех целей:ние словарясистемы об1. Для моделирования словаря системы.суждаетсяМоделирование словаря системы предполагает решение вопров главе 4.са о том, какие абстракции станут предметом внимания системы,Представления дизайнаобсуждаются в главе 2.Свойствосохраняемости (устойчивости)обсуждаетсяв главе 24, моделированиефизическихбаз данных –в главе 30.123а какие выходят за ее границы.
Вы используете диаграммы классов,чтобы специфицировать эти абстракции и их предназначение.2. Для моделирования простых коопераций.Кооперация – это сообщество классов, интерфейсов и другихэлементов, которые работают в совокупности для формированиянекоторого совместного поведения, которое не может быть обеспечено всеми этими элементами, взятыми в отдельности. Например,когда вы моделируете семантику транзакции в распределенной системе, то, глядя на отдельный класс, не сможете понять, что происходит.
Эта семантика обеспечивается набором классов, работающихвместе. Диаграмма классов позволит визуализировать и специфицировать такой набор классов и их связей.3. Для моделирования логической схемы базы данных.Схему в данном контексте можно рассматривать как проект концептуального дизайна базы данных. Во многих областях требуется сохранять информацию в реляционной или объектноFориентированнойбазе данных. Их схемы удобно моделировать при помощи диаграммклассов.Типичные приемы моделированияМоделирование простых кооперацийНи один класс не существует сам по себе. Каждый из них работает в кооперации с другими, чтобы обозначить некую общуюсемантику, которая недостижима при автономном использованиивсех тех же классов.
Таким образом, наряду со словарем системыМеханизмы, вам понадобится обратить внимание на визуализацию, специфицикак правило, рование и документирование различных способов взаимодействиятесносущностей из этого словаря. Используйте диаграммы классов длясвязаныпредставления таких коопераций.с вариантаЧтобы смоделировать кооперацию, необходимо:ми исполь Идентифицировать механизм, который вы собираетесь мозования (см.делировать. Механизм представляет некоторую функциональглаву 17).ную или поведенческую часть моделируемой системы, полуСценарии –ченную в результате взаимодействия совокупности классов,это потокиинтерфейсов и прочих сущностей.событий Для каждого механизма идентифицировать классы, интерв составефейсы и прочие кооперации, которые участвуют в даннойвариантовкооперации, а также связи между этими сущностями.использова Использовать сценарии для тестирования всех этих сущния, какностей.
На данном этапе выявляются части модели, котообсуждаетрые были пропущены, а также те, которые семантическися в главе 16.неверны.Диаграммы классов124 Убедиться, что все элементы наполнены правильным содержимым. Что касается классов, для начала обеспечьте оптимальный баланс обязанностей. Затем со временем проработайте конкретные атрибуты и операции.На рис. 8.2 в качестве примера показан набор классов, описывающих реализацию автономного робота. Акцент сделан на классы,связанные с механизмом перемещения робота по заданному пути.Вы найдете здесь один абстрактный класс Motor (Мотор) с двумя конкретными потомками – SteeringMotor (МоторПоворотногоМеханизма) и MainMotor (ГлавныйМотор). Оба потомка наследуют от своегородителя Motor пять операций.
И оба они, в свою очередь, представлены как часть другого класса – Driver (Привод). Класс PathAgent(АгентТраектории) имеет ассоциацию «одинFкFодному» с Driverи «одинFкоFмногим» – с CollisionSensor (ДатчикСтолкновений). Никаких атрибутов и операций для PathAgent не показано, хотя его обязанности и заданы.:: LenghtРис. 8.2. Моделирование простой кооперацииВ этой системе участвует много других классов, но диаграмма,которую мы рассматриваем, сосредоточена только на перемещенииробота. В то же время некоторые классы, представленные на ней,можно найти и на других диаграммах.
Например, хотя это здесьи не показано, класс PathAgent кооперируется по меньшей мере сдвумя другими: Environment (Окружение) и GoalAgent (АгентЦели) вТипичные приемы моделирования125механизме более высокого уровня, управляющем разрешениемконфликтных ситуаций, в которых может оказаться робот. КлассыCollisionSensor и Driver, а также их части кооперируются с классомFaultAgent (АгентОтказа) в составе механизма, отвечающего за непрерывную диагностику оборудования робота на предмет разнообразных ошибок.
Фокусируя внимание на каждой из этих коопераций в разных диаграммах, вы создаете понятное представлениео системе с разных точек зрения.Моделирование логической схемы базыданныхМногие системы, которые вам предстоит моделировать, будутиметь в своем составе сохраняемые объекты. Это значит, что онимогут быть помещены в базу данных для последующего извлечения. Чаще всего вы будете использовать для хранения реляционные и объектноFориентированные базы данных либо гибридныеобъектноFреляционные базы. UML хорошо подходит для моделирования как логических, так и физических схем баз данных.Диаграммы классов UML представляют собой надмножество диаграмм «сущностьFсвязь» (entityFrelationship, EFR) – общегоинструмента моделирования, используемого в логическом проектировании баз данных.
В то время как классические EFR диаграммысосредоточены только на данных, диаграммы классов идут на шагвперед, позволяя также моделировать поведение. В физическойбазе данных эти логические операции обычно представлены в видетриггеров и хранимых процедур.Чтобы смоделировать схему, необходимо: Идентифицировать те классы в модели, состояние которыхне должно быть зависимым от времени жизни работающегоприложения.Стереотипы Создать диаграмму классов, содержащую классы, выявленобсуждаютные на первом этапе. Вы можете определить ваш собственся главе 6.ный набор стереотипов и помеченных значений, чтобы представить специфичные для базы данных детали.
Раскрыть структурные подробности этих классов. В основном это означает необходимость подробно специфицироватьих атрибуты, а также ассоциации с указанием множественности, которые связывают данные классы. Выявить общие образцы, которые усложняют физическое проектирование базы данных, например циклические ассоциациии ассоциации «одинFкFодному». При необходимости создатьпромежуточные абстракции для упрощения логической структуры.Моделирование распределенияобъектовобсуждается в главе 24, моделированиефизическойбазы данных – в главе 30.126Диаграммы классовТипичные приемы моделирования127 Рассмотреть поведение классов, отмеченных на первом этапе, раскрыв операции, существенные для доступа к данными обеспечения их целостности.
Вообще, чтобы четче разграничить различные аспекты системы, следует инкапсулировать бизнесFправила, описывающие манипуляции наборамиэтих объектов, в слое, находящемся над данными устойчивыми классами. Там, где возможно, использовать инструментальные средства, которые помогут трансформировать логический дизайнв физический.На заметку. Обсуждение логического проектирования базыданных выходит за рамки данной книги. Здесь мы простопоказываем, как вы можете моделировать схемы при помощиUML.
На практике вы чаще всего будете иметь дело со стереотипами, настроенными под используемую вами базу данных (реляционную или объектноQориентированную).Моделированиепримитивных типовобсуждается главе 4;агрегация –в главах 5и 10.На рис. 8.3 показан набор классов, описывающих информационную систему учебного заведения. Этот рисунок развивает диаграмму классов, которую мы рассматривали ранее (см. рис. 5.9 и 5.11),и показывает детали классов, существенных для конструирования физической схемы базы данных.
Начиная с нижнего левогоугла диаграммы вы найдете классы Student (Студент), Course (Курс)и Instructor (Преподаватель). Существует ассоциация между Studentи Course, указывающая, что студенты посещают курсы. Более того,каждый студент может выбирать неограниченное число курсов;каждый курс может посещать множество студентов.Эта диаграмма раскрывает атрибуты всех шести классов. Отметим, что все атрибуты – примитивных типов. Когда вы моделируетесхему базы, обычно связи с непримитивными типами моделируются в виде явных ассоциаций, а не атрибутов.Два класса – School (Учебное заведение) и Department (Факультет) – включают несколько операций, предназначенных для манипулирования их частями.
Эти операции важны для поддержанияцелостности данных: например, добавление и удаление факультетов может повлечь за собой некоторые недоразумения. Есть много других операций, которые стоит рассмотреть для этих и другихклассов (скажем, запрос определенной информации перед записьюстудента на курс). Такие функции можно трактовать скорее какбизнесFправила, а не операции, призванные обеспечивать целостность данных, поэтому их лучше поместить на более высокий уровень абстракции.Рис. 8.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
