1. Поощрять развитие рынка объектных инструментальных средств.

    Более 800 ведущих производителей программных  и аппаратных средств, усилия которых  сосредоточены в рамках OMG, видят  перспективы развития современных  информационных технологий и основу своего коммерческого успеха в широком  продвижении на рынок инструментальных средств, поддерживающих объектные  технологии. Говоря же об объектных  технологиях, разработчики из OMG имеют  в виду, прежде всего, совокупность технологических решений CORBA и UML. С  этой точки зрения языку UML отводится  роль базового средства для описания и документирования различных объектных  компонентов CORBA.

1. Способствовать распространению объектных технологий и соответствующих понятий объектно-ориентированного анализа и проектирования.

    Эта задача тесно связана с предыдущей и имеет с ней много общего. Если исключить из рассмотрения рекламные  заявления разработчиков об исключительной гибкости и мощности языка UML, а попытаться составить объективную картину  возможностей этого языка, то можно  прийти к следующему заключению. Следует признать, что усилия достаточно большой группы разработчиков были направлены на интеграцию в рамках языка UML многих известных техник визуального моделирования, которые успешно зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению языка UML по сравнению с известными нотациями структурного системного анализа, платой за сложность являются действительно высокая гибкость и изобразительные возможности уже первых версий языка UML. В свою очередь, использование языка UML для решения всевозможных практических задач будет только способствовать его дальнейшему совершенствованию, а значит и дальнейшему развитию объектных технологий и практики объектно-ориентированного анализа и проектирования.

1. Интегрировать в себя новейшие и наилучшие достижения практики объектно-ориентированного анализа и проектирования.

    Язык UML непрерывно совершенствуется разработчиками, и основой этой работы является его  дальнейшая интеграция с современными модельными технологиями. При этом различные методы системного моделирования  получают свое прикладное осмысление в рамках объектно-ориентированного анализа и проектирования. В последующем эти методы могут быть включены в состав языка UML в форме дополнительных базовых понятий, наиболее адекватно и полно отражающие наилучшие достижения практики объектно-ориентированного анализа и проектирования.

    Чтобы решить указанные выше задачи, за свою недолгую историю язык UML претерпел  определенную эволюцию. В результате описание самого языка UML стало нетривиальным, поскольку семантика базовых  понятий включает в себя целый  ряд перекрестных связей с другими  понятиями и конструкциями языка. В связи с этим так называемое линейное или последовательное рассмотрение основных конструкций языка UML стало  практически невозможным, т. к. одни и те же понятия могут использоваться при построении различных диаграмм или представлений. В то же время  каждое из представлений модели обладает собственными семантическими особенностями, которые накладывают отпечаток  на семантику базовых понятий  языка в целом.

    Отмечая сложность описания языка UML, следует  отметить присущую всем формальным языкам сложность их строгого задания, которая  вытекает из необходимости в той  или иной степени использовать естественный язык для спецификации базовых примитивов. В этом случае естественный язык выступает в роли метаязыка, т. е. языка для описания формального языка. Поскольку естественный язык не является формальным, то и его применение для описания формальных языков в той или иной степени страдает неточностью. Хотя в задачи языка UML не входит анализ соответствующих логико-лингвистических деталей, однако эти особенности отразились на структуре описания языка UML, в частности, делая стиль описания всех его основных понятий полуформальным.

    Учитывая  эти особенности, принятая в книге  последовательность изучения языка UML основывается на рассмотрении основных графических средств моделирования, а именно - канонических диаграмм. Все  нужные для построения диаграмм понятия  вводятся по мере необходимости. Тем  не менее в этой главе следует  остановиться на общих особенностях языка UML, которые в той или  иной степени влияют на понимание  его базовых конструкций. 

     6. Пример использования объектно-ориентированного подхода

    Рис.5 Начальная диаграмма вариантов использования 

    В качестве предметной области рассматривается  работа подразделения учета налогоплательщиков-организаций.

    На  начальной стадии (или стадии формирования требований) строится начальная диаграмма  вариантов использования (рис.4).

    При построении диаграммы вариантов  использования в первую Очередь  составляется список всех основных действующих  лиц (физических лиц или внешних  систем, которые будут взаимодействовать  с создаваемой системой). Их можно  идентифицировать, задавая следующие  вопросы:

    • Кто использует систему непосредственно?

    • Кто отвечает за эксплуатацию системы?

    • Какое внешнее оборудование используется системой?

    • Какие другие системы взаимодействуют  с данной системой?

    Варианты  использования идентифицируются исходя из следующих соображений: каждый вариант  использования представляет собой  некоторую функцию, выполняемую  системой в ответ на воздействие  действующего лица, и характеризует  конкретный способ применения системы, диалог между действующим лицом  и системой. Нужно также иметь  в виду, что впоследствии варианты использования будут служить  для описания требований к системе, общения с конечными пользователями и экспериментами предметной области, а также для тестирования системы.

    На  стадии проектирования уточняется диаграмма  вариантов использования и строится архитектура системы, основой которой  являются диаграммы классов. В данном примере ограничимся построением  диаграммы классов и диаграммы  взаимодействия. Диаграммы взаимодействия строятся для уточнения диаграммы  вариантов использования и перехода к диаграммам классов. Так, диаграмма  последовательности (рис.5) иллюстрирует один из возможных сценариев развития событий в рамках варианта использования "Зарегистрировать налогоплательщика". Предполагается, что налогоплательщик ставится на учет впервые и все  его документы в полном порядке.

    Структура программной системы описывается  с помощью нескольких диаграмм классов, главная из которых представляет собой диаграмму пакетов, а остальные  диаграммы раскрывают содержимое каждого  из пакетов. При построении диаграммы  классов предметной области выделение  этих классов (классов-сущностей) может  быть аналогично выделению сущностей  в процессе моделирования данных. Данные классы должны иметь концептуальный характер и отвечать на вопрос "что?", а не "как?". Начальный список может быть составлен следующим  образом:

    • в описании исходных данных выделяются кандидаты в классы-существительные, которые потенциально могут соответствовать  классам (при этом следует помнить, что существительные могут также  относиться к объектам, ассоциациям  или атрибутам классов);

    • анализируются роли кандидатов в  системе. Каждый класс должен выполнять  некоторые действия и взаимодействовать  с другими классами. Каждый класс  должен иметь уникальное имя, отражающее характер абстракции, представляемой данным классом. Если классу трудно придумать  краткое и содержательное имя, то это является характерным признаком  неудачного выделения класса. Рассматривается  каждая возможная пара классов и  устанавливается существование  ассоциации между ними (по аналогии с установлением связей между  сущностями в процессе моделирования  данных). Присваиваются наименования ролям ассоциаций, и определяется их множественность. 

    Рис.6 Диаграмма последовательности для варианта использования "Зарегистрировать налогоплательщика" 

    Далее составляется список атрибутов каждого  класса (по аналогии с определением атрибутов сущностей при моделировании  данных). Процесс определения атрибутов  должен быть непродолжительным, поскольку  существенные атрибуты могут быть добавлены впоследствии. При этом следует убедиться, что не пропущены существенные характеристики, представленные в исходных данных. 

    Рис.7 Диаграмма классов предметной области 

    Определяются  действия (операции), выполняемые каждым классом. При определении операций нужно учитывать следующие рекомендации:

    • каждая операция должна выполнять одну простую функцию;

    • название операции должно отражать результат  функции, а не то, как она выполняется.

    Примерами простых операций могут быть: получить значение атрибута, установить значение атрибута, добавить или исключить  связь с другим объектом, удалить  данный объект.

Выводы

    Перспективы дальнейшего развития UML связаны  со становлением и интенсивным развитием  новой парадигмы объектно-ориентированного анализа - компонентной разработки приложений (Component-Based Development - CBD). В этой связи  развернута работа над дополнительной спецификацией языка UML применительно  к технологиям CORBA и СОМ+. Речь идет о разработке так называемых профилей, содержащих нотацию всех необходимых  элементов для представления  в языке UML компонентов соответствующих  технологий. При этом интенсивно используется механизм расширения языка UML за счет добавления новых стереотипов, помеченных значений и ограничений.

    Язык UML уже сейчас находит широкое  применение в качестве неофициального стандарта в процессе разработки программных систем, связанных с  такими областями, как моделирование  бизнеса, управление требованиями, анализ и проектирование, программирование и тестирование. Применительно к  этим процессам в языке UML унифицированы  стандартные обозначения основных элементов соответствующих предметных областей.

    В частности, для моделирования бизнес-процессов  могут быть использованы: применительно  к подсистемам - стереотипы "organization unit" и "work unit", для классов - стереотипы "worker", "case worker", "internal worker". При этом, например, стереотип "worker" служит для обозначения класса, который  представляет абстракцию человека, выполняющего определенную деятельность или работу в бизнес-системе. Работник или сотрудник  взаимодействует с другими сотрудниками подсистемы в процессе выполнения отдельных  операций, образующих бизнес-логику процесса.

    Следует также отметить, что развитие языка UML на основе включения в его нотацию  дополнительных элементов и стереотипов  стимулирует разработку соответствующих  инструментальных CASE-средств. Можно  с уверенностью предположить, что  эта область развития информационных технологий имеет широчайшие перспективы и стратегическое значение не только в качестве языка общения между заказчиками и разработчиками программных систем, но и для документирования проектов в целом. При этом достигается требуемый уровень стандартизации и унификации всех используемых для этой цели обозначений.

    Разработав  модель и специфицировав ее на языке UML, разработчик имеет все основания  быть понятым и по достоинству  оцененным своими коллегами. При  этом могут быть исключены ситуации, когда тот или иной разработчик  применяет свою собственную графическую  нотацию для представления тех  или иных аспектов модели, что практически  исключает ее понимание другими  специалистами в случае нетривиальности  исходной модели.

    Не  менее важный аспект применения языка UML связан с профессиональной подготовкой  соответствующих специалистов. Речь идет о том, что знания различных  научных дисциплин характеризуют  различные аспекты реального  мира. При этом принципы системного анализа позволяют рассматривать  те или иные объекты в качестве систем.

    Последующая разработка модели системы, направленная на решение определенных проблем, может  потребовать привлечения знаний из различных дисциплин. С этой точки  зрения язык UML может быть использован  не только для унификации представлений  этих знаний, но что не менее важно - для их интеграции, направленной на повышение адекватности много-модельных  представлений сложных систем.

    Возможно  со временем язык UML станет тем "эсперанто", на котором смогут общаться математики, системные аналитики, физики, программисты, менеджеры, экономисты и специалисты  других профессий, представляя свои профессиональные знания в унифицированном  виде. Ведь, по существу, каждый из специалистов оперирует модельными представлениями  в своей области знаний. И именно этот модельный аспект может быть специфицирован средствами языка UML.

    В связи с этим значение языка UML существенно  возрастает, поскольку он все более  приобретает черты языка представления  знаний. При этом наличие в языке UML изобразительных средств для  представления структуры и поведения  модели позволяет достичь адекватного  представления декларативных и  процедурных знаний и, что не менее  важно, установить между этими формами  знаний семантическое соответствие. Все эти особенности языка UML позволяют  сделать вывод о том, что он имеет самые серьезные перспективы  уже в ближайшем будущем.