2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 70
Текст из файла (страница 70)
25.2. Моделирование реактивных объектовВ данном случае автомат предназначен для разбора потока символов, соответствующих синтаксисуmessage : ‘<’ string ‘>’ string ‘;’364Событияобсуждаютсяв главе 21.Диаграммы состоянийПервая строка представляет тег, вторая – тело сообщения. Из полученного потока символов принимаются только сообщения с правильным синтаксисом.Как показано на рисунке, у автомата есть только три стабильных состояния: Waiting (Ожидание), GettingToken (ПолучениеСлова)и GettingBody (ПолучениеТела).
Состояние спроектировано в видемашины Мили – с действиями, присоединенными к переходам.Фактически есть только одно событие, которое может нас интересовать при рассмотрении этого автомата – вызов put с параметромc (символом). В состоянии Waiting автомат отбрасывает любой символ, который не означает начало слова (что объявлено в защитномусловии).
Как только встречается начало слова, состояние объектаизменяется на GettingToken. Находясь в этом состоянии, автомат сохраняет каждый символ, который не является окончанием слова.Когда приходит символ окончания слова, состояние объекта изменяется на GettingBody. Находясь в этом состоянии, автомат сохраняеткаждый символ, который не означает окончания тела сообщения(что объявлено в защитном условии). Как только поступает окончание сообщения, состояние объекта изменяется на Waiting и возвращается значение, указывающее на то, что сообщение было разобрано и автомат готов получать следующее.Отметим, что последнее состояние специфицирует автомат, который работает непрерывно, – конечного состояния не существует.Прямое и обратное проектированиеПрямое проектирование (создание кода из модели) возможнодля диаграммы состояний, особенно если контекстом таковой является класс. Например, используя диаграмму состояний, показанную на рис. 25.2, инструмент прямого проектирования можетсгенерировать следующий JavaFкод для класса MessageParser (АнализаторСообщений):class MessageParser {publicboolean put(char c) {switch (state) {case Waiting:if (c == ‘<’) {state = GettingToken;token = new StringBuffer();body = new StringBuffer();}break;Типичные приемы моделирования365case GettingToken :if (c == ‘>’)state = GettingBody;elsetoken.append(c);break;case GettingBody :if (c == ‘;’)state = Waiting;elsebody.append(c);return true;}return false;}StringBuffer getToken() {return token;}StringBuffer getBody() {return body;}privatefinal static int Waiting = 0;final static int GettingToken = 1;final static int GettingBody = 2;int state = Waiting;StringBuffer token, body;}Анализ такого кода требует небольшого напряжения ума.
Инструмент прямого проектирования должен генерировать необходимые закрытые атрибуты и конечные статические константы.Обратное проектирование (создание модели из кода) теоретически возможно, но практически не очень полезно. Выбор того,что составляет осмысленное состояние объекта, зависит от взглядапроектировщика. Инструменты обратного проектирования не обладают способностью к абстрагированию, а потому не могут генерировать осмысленные диаграммы состояний. Более интересной,чем обратное проектирование модели из кода, может оказатьсяанимация модели на основе работы реальной системы.
Например,если взять диаграмму с рис. 25.2, инструментальное средство могло бы анимировать состояния автомата на ней по мере того, как ихпринимала бы работающая система. Аналогичным образом можноанимировать выполнение переходов, показывая момент получения события и результат выполнения действия. Под управлениемДиаграммы состояний366отладчика вы могли бы контролировать скорость выполнения,устанавливать точки прерывания для приостановки работы в интересные моменты времени, чтобы проверить значения атрибутовотдельных объектов.Советы и подсказкиСоздавая диаграмму состояний в UML, следует помнить, чтоона представляет собой всего лишь проекцию одной модели динамических аспектов системы. Отдельно взятая диаграмма состоянийможет охватить семантику одного реактивного объекта, но семантику непростой системы не в состоянии передать.Хорошо структурированная диаграмма состояний обладает следующими характеристиками: сосредоточена на передаче одного аспекта динамики системы; содержит только те элементы, которые существенны для понимания данного аспекта; детализирована адекватно своему уровню абстракции (раскрывает только те сущности, которые важны для понимания); применяет сбалансированное сочетание машин Мили и Мура.Когда вы рисуете диаграмму состояний, пользуйтесь следующими рекомендациями: присваивайте диаграмме имя, отражающее ее назначение; начинайте с моделирования стабильных состояний объекта,затем моделируйте допустимые переходы между состояниями.
Показывайте ветвление, параллелизм и потоки объектовво вторую очередь – возможно, на отдельных диаграммах; располагайте элементы так, чтобы свести к минимуму пересечение линий; при создании объемных диаграмм состояний рассмотритевозможность применения расширенных средств – таких каквложенные автоматы, которые включены в полную спецификацию UML.Часть VIМоделированиеархитектурыГлава 26. АртефактыГлава 27. РазмещениеГлава 28.
КооперацииГлава 29. Образцы и каркасыГлава 30. ДиаграммыартефактовГлава 31. Диаграммы размещенияГлава 32. Системы и моделиБазовые понятияГлава 26. АртефактыВ этой главе:Артефакты, классы и их материализацияМоделирование исполняемых программ и библиотекМоделирование таблиц, файлов и документовМоделирование исходного кодаАртефакты живут в материальном мире битов и потому являютсяважнейшими строительными блоками при моделировании физических аспектов системы. Артефакт – это физическая и заменяемаячасть системы.Артефакты используются для моделирования таких физических сущностей, которые могут располагаться на узле, – например,исполняемых программ, библиотек, таблиц, файлов и документов.Обычно артефакт представляет собой физическую группировку таких логических элементов, как классы, интерфейсы и кооперации.369Аналогичным образом обстоит дело и с программными системами. Вы осуществляете логическое моделирование для визуализации,специфицирования и документирования решений относительно словаря предметной области, а также структурных и поведенческих способов кооперации сущностей.
Физическое же моделирование требуется для построения исполняемой системы. Если логические сущности«живут» в концептуальном мире, то физические пребывают в миребитов, то есть в конечном счете располагаются на физических узлахи могут быть исполнены непосредственно либо какимFто косвеннымобразом участвовать в работе исполняемой системы.В UML все физические сущности моделируются как артефакты.
Артефакт – это физическая сущность на уровне платформы реализации.Многие операционные системы и языки программирования непосредственно поддерживают концепцию артефакта. Объектные библиотеки, исполняемые программы, компоненты .NETи Enterprise JavaBeans, – все это примеры артефактов, которые могут быть представлены на UML. Но артефакты могут быть использованы и для представления других сущностей, которые принимают участие в работеисполняемых программ, – таких, как таблицы, файлы и документы.СтереотипыВ UML артефакты изображаются так, как показано на рис.
26.1.обсуждают- Эта каноническая нотация позволяет визуализировать артефактся в главе 6.независимо от операционной системы и языка программирования.Используя стереотипы – один из механизмов расширения UML,можно приспособить эту нотацию для представления специфических разновидностей артефактов.ВведениеКонечный результат работы строительной компании – зданиев его материальном воплощении. Для визуализации, специфицирования и документирования устройства жилого дома (расположения стен, дверей и окон, размещения систем электроснабженияи водопровода и т.д.), а также общего архитектурного стиля вы строите логические модели. Во время строительства стены, двери, окнаи другие концептуальные сущности, данные вам в абстракциях,превращаются в реальные, физические объекты.Все эти предварительные представления крайне необходимы.Разницамежду стро- Если вы строите здание, стоимость разрушения и переделки котоительством рого практически равна нулю (например, собачью будку), то, вероятно, можете сразу приступить к физическому строительству, мисобачьейновав этап логического моделирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
