Источник: www.omg.org | Электронная библиотека

Обзор UML


Краткий обзор UML
    Унифицированный язык моделирования (UML) - это многоцелевой визуальный язык моделирования, который используется для определения, представления, конструирования и документирования артефактов программной системы. Он охватывает решения и понимание конструируемой системы. Язык используется для понимания, проектирования, просмотра, конфигурирования, поддержки и управления информацией о проектируемой системе. Он предназначен для использования со всеми методами разработки, этапами жизненного цикла, областями применения и носителями. Язык моделирования предназначен для унифицирования опыта о технике моделирования и объединения текущей лучшей практики в едином стандарте. UML включает семантические понятия, нотации и рекомендации. Он имеет статическую, динамическую, контекстную и организационную части. Он предназначен для поддержки нтерактивными инструментами моделирования, которые включают генерацию кода и формирование отчётов. UML спецификация не определяет стандартный процесс, но предназначена для использования в интерактивном процессе разработки. Он предназначен для поддержки большинства имеющихся объектно-ориентированных процессов разработки.
    UML охватывает информацию о статической структуре и динамическом поведении системы. Система моделируется как набор дискретных объектов, которые взаимодействуют, выполняя работу, которая выгодна непосредственно внешнему пользователю. Статическая структура определяет типы необходимых для системы объектов и для её реализации, а также связи между объектами. Динамическое поведение определяет поведение объектов во времени и связи между объектами для достижения поставленных целей. Моделирование системы с нескольких отдельных, но связанных точек зрения позволяет понять различные цели системы.
    UML также содержит организационные конструкции для организации моделей в пакеты, что позволяет разработчикам разбивать крупные системы на части для понимания и управления зависимостями между пакетами и для управления версиями структурных лементов в комплексной среде разработки. Он включает конструкции для представления решений реализации и для организации элементов времени выполнения в компоненты.
    UML - это не язык программирования. Инструменты могут обеспечивать генерацию кода из UML на различных языках программирования и создавать модели вследствие обратного процесса разработки из имеющихся систем. UML не является высоко формализованным языком для доказательства теорем. Имеются подобные языки, но они сложны для понимания или использования для разных целей. UML является многоцелевым языком моделирования. Для специализированных областей, таких как разработка пользовательского интерфейса, VLSI схем или управляемого правилами искусственного интеллекта применяются специальные языки.     UML - это дискретный язык моделирования. Он не применяется для моделирования систем во времени, которые обычно используются в прикладных науках и физике. UML используется для универсального многоцелевого моделирования дискретных систем, таких как программные системы, микропрограммные или цифровая логика.


Методы объектно-ориентированной разработки
    Методы разработки для традиционных языков программирования, таких как Cobol и Fortran, появились в 1970 году и стали широко распространёнными в 80-х. Самыми распространёнными среди них были Структурный анализ и Структурное проектирование и их варианты, такие как Структурное проектирование в реальном времени и другие. Эти методы, первично были разработаны Константином Де Марко, Вардом Меллором, Йордоном и другими и получили небольшое проникновение при разработке больших систем, особенно, для систем по заказам правительства в аэровоздушных и оборонных областях, в которых чиновники настаивали на организованном процессе разработки и хорошем документировании процесса разработки системы и реализации. Результат был не всегда таким, каким его ожидали для большинства автоматизированных систем разработки программного обеспечения (CASE) и генераторы отчётов, которые извлекали проекты после реализации, были закончены, но  методы, включающие хорошие идеи, лишь изредка были эффективны в конструировании больших систем. Коммерческие приложения неохотно применяли большие CASE системы и методы разработки. Большинство бизнес систем разрабатывались для внутреннего использования без конкуренции со стороны потребителей и подрядчиков, что характеризовало большие правительственные проекты. Коммерческие системы воспринимались, как простые вне зависимости были они такими или нет, и не было большой потребности в рецензии со стороны внешних организаций.
    Первый объектно-ориентированный язык Simula-67 был разработан in 1967. Язык не получил широкого применения, но оказал сильное влияние на разработчиков нескольких последующих объектно-ориентированных языков. Объектно-ориентированное движение стало активным с широкого распространения Smalltalk в начале 80х и продолжилось другими объектно-ориентированными языками, такими как Objective C, C++, Eiffel и CLOS. Использование объектно-ориентированных языков было ограничено, но объектно-ориентированный подход завоевал большое внимание. После 5 лет с того времени, как Smalltalk стал популярным, первые объектно-ориентированные методы разработки были опубликованы Шлаэр и Корд Йорданом, которые  следовали книгам Буча, Румбаха и Вирфс Брока. Эти книги были добавлены в ранние книги по разработке программ Робсоном Гольдбергом, Коксом и Мейером (начавших объектно-ориентированную методологию). Первый закончился в конце 1990. Книга “Objectory” Джекобсона была опубликована позднее и базировалась на ранних его работах. Эта книга давала немного отличающийся подход, усиливая внимание на вариантах использования и процессе разработки.
    В последующие 5 лет появился избыток книг об объектно-ориентированном подходе, каждая вводила свои концепции, определения, нотации, терминологию и процесс. Некоторые из предложенных концепций были полезны, но все они были похожи друг на друга. Большинство новых книг описывало один или несколько существующих методов и вводило новые небольшие изменения в них. Авторы постоянно переиздавали свои работы, внедряя новые хорошие идеи других авторов. Появился набор общих концепций, большинство из которых были рассмотрены одним или двумя авторами, но широко не применялись. Даже в основных концепциях были небольшие различия в методах, которые делали детальное сравнение ненадёжным для обычного пользователя.

Попытки унифицирования
    Раньше принимались попытки унифицировать концепции методов,  известен пример, когда  Fusion Колмана и его коллеги , включили концепции  из OMT [Rumbaugh-91], Буча [Booch-91 ] и CRC. Так как они не включали оригинальных авторов, то они были восприняты как новые методы, а не как замена нескольких имеющихся методов. первая удачная попытка объединить и заменить существующие подходы была предпринята, когда Румбах присоединился к Бучу в Rational Software Corporation в 1994. Они начали объединять  концепции из OMT и методы Буча, и первый результат был получен в 1995 году.
    В это время Джекобсон также присоединился к Rational и начал работать с Бучем и Румбахом. Их совместная работа получила название Унифицированный Язык Моделирования (UML). Мгновенная выгода была получена авторами из широко используемых методов, работающих совместно для унификации подходов, сдвинули баланс в объектно-ориентированной методологии, где раньше был небольшой стимул (или, как минимум, маленькая готовность) для методологов отказаться от их собственных концепций для достижения гармонии.
    В 1996 году Группа Управления Объектами (OMG) издала требования предложений по стандартному подходу к объектно-ориентированному моделированию. Авторы UML Буч, Джекобсон и Румбах начали работу с методологами и разработчиками других компаний, чтобы сформировать предложения, выгодные для сообщества OMG и языка моделирования, который будет широко принят создателями инструментов, методологами и разработчики, которые будут возможными его пользователями. Несколько конкурирующих попыток было сделано. В конечном счёте, все предложения были объединены в одно предложение и направлены в OMG в сентябре 1997 года. Конечным продуктом стало сотрудничество многих. Мы сделали попытку создания UML и  внесли несколько хороших идей, но идеи в нём - это идеи многих умов.

Стандартизация
    Унифицированный Язык Моделирования был принят единогласно сообществом OMG как стандарт в ноябре 1997 года [UML-98]. OMG взяла ответственность за дальнейшую разработку стандарта UML. Даже перед последним принятием было опубликовано несколько книг, в которых  выделялись наиболее яркие особенности UML. Многие разработчики программ объявили поддержку UML или планировали поддержку в будущем, некоторые методологи объявили о том, что они будут применять UML нотацию в дальнейшей работе. Появление UML было привлекательным для компьютерной публики, потому, что стандарт объединял опыт многих общепризнанных авторами и мог снизить добровольное несоответствие между программными инструментами. Мы надеемся, что стандартизация будет способствовать широкому распространению объектно-ориентированного моделирования среди разработчиков и прочной базе в поддержке программными инструментами и обучения, сейчас пользователи или производители должны определять сами, какие подходы им использовать и поддерживать.

Задачи UML
    Перед разработкой UML ставилось несколько целей. Первая и самая важная – многоцелевой язык моделирования, который может использоваться всеми разработчиками. Это было базирование на общем согласии компьютерного общества, включение концепций признанных методов, которые могут использоваться как язык моделирования. По меньшей мере, он был предназначен для замещения моделей OMT, Буча и “Objectory”, также как и других участников предложения. Он должен был быть как можно проще; не имело значения, использовали мы нотации из OMT, Буча, “Objectory” или других признанных методов. Это означало поддержку хорошей практики разработки, такой как инкапсуляция, разделение отношений и охватывало смысл построения модели. Оно предназначено для нахождения недостатков в текущем процессе разработки, таких как большие масштабы, распространение, конкуренция, шаблоны и командная разработка.
    UML не предназначен быть полным методом разработки. Он не включает пошаговый процесс разработки. Мы верим, что хороший процесс разработки является ключом к успеху в разработке программ, и мы предлагаем сопутствующую книгу [Jacobson-99]. Важно понять, что UML и процесс использования UML – это две разные вещи. UML предназначен для поддержки всех или наиболее важных  существующих процессов разработки. UML включает все концепции, которые мы верим, необходимы для поддержки современного итеративного процесса, базирующегося на построении мощной архитектуры для соответствия вариантов использования, соответствующих требованиям пользователя.
    Конечная цель UML заключалась в том, чтобы быть как можно проще, сохраняя способность моделирования большого разнообразия практических систем, которые должны быть созданы. UML должен быть достаточно выразительным для внедрения всех концепций, которые возникают в современной системе, таких как конкуренция, распространение и  программных механизмов, таких как инкапсуляция и разделение на компоненты. Он должен быть универсальным языком, как любой другой многоцелевой язык программирования. К сожалению, это означает, что он не может быть простым, если мы хотим работать с вещами серьезнее, чем игрушечные системы. Современные языки и операционные системы сложнее, чем 40 лет назад, потому что возросли требования к ним. UML имеет несколько видов моделей, которые невозможно охватить в один день, они сложнее чем их предки, так, как предназначены, быть более понятными. Нет необходимости в изучении всех моделей сразу, независимо от того проектируете вы операционную систему или пользовательское приложение.