Всё для программиста

Unified Modeling Language - Унифицированный Язык Моделирования
Индекс материала
Unified Modeling Language - Унифицированный Язык Моделирования
История UML
Все страницы

Unified Modeling Language - Унифицированный Язык Моделирования. Многие софтверные компании, принимая на работу программистов интересуются его знаниями UML (и отсутствие таковых явно не является плюсом). А уж про аналитиков и нечего говорить. Без знания и умения работать с диаграммами UML, аналитикам просто указывают на дверь.

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

UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose 98i.

Визуальное моделирование

Итак, что же такое UML, и почему этому языку моделирования уделяется в последнее время столь большое внимание? Нужно ли его изучать? Как его использовать при разработке программных проектов?

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

    • компонентную технологию разработки моделей ИС,
    • визуальное программирование (RAD средства),
    • использование образцов (patterns) при проектировании ИС,
    • визуальное представление различных аспектов проекта (визуальное моделирование, CASE - средства)

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

Построение модели корпоративной ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования "хороших" методов моделирования ИС. Язык моделирования, как правило, включает в себя:

  • элементы модели - фундаментальные концепции моделирования и их семантику;
  • нотацию - визуальное предоставление элементов моделирования;
  • принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.

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

Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Шутка о том, что "заказчик что-то хочет, но точно не знает, чего именно", с завидным постоянством часто оказывается былью. А если на начальном этапе работы над проектом ИС заказчик думает, что точно знает, что хочет, то, как правило, и об этом свидетельствует богатый опыт, его требования изменяются ("плывут") в ходе выполнения проекта. С одной стороны, аппетит приходит во время еды, а с другой, высокая динамика бизнеса объективно заставляет менять требования к разрабатываемой (или поддерживаемой) ИС.

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

  • повышение качества программного продукта,
  • сокращение стоимости проекта,
  • поставка системы в запланированные сроки.

Каждая диаграмма предназначена для отражения определенной информации. Значки на диаграммах и их связи также имеют строго оговоренное назначение, и должны применяться определенным образом. Единообразное применение диаграмм и гарантирует то, что каждый участник проекта будет понимать то, что что хотел сказать автор диаграммы.

В составлении диаграмм - нет единого решения. Одну и ту же диаграмму можно нарисовать по разному. Здесь невозможно 100% сделать одинаковые диаграммы. Каждый аналитик нарисует диаграммы по своему, и хорошо, если он соблюдает хотя бы нотации UML.

Если вам скажут "нарисуйте дом", то какой дом вы нарисуете? У каждого человека свой взгляд на вещи. Если вы хотите изучить рисование дома и прочтете книгу о том, как рисовать дома, то как хорошо вы сможете их рисовать? Вот тоже самое и здесь. Вы прочли книгу об UML и что?

Чтобы научиться плавать - нужно плавать. Чтобы научиться применять UML нужно его применять. Возникает вопрос: как это сделать. Можно взять пример из книги, для которого уже создана диаграмма и, перед тем как читать, попытаться создать такую диаграмму самому. Можно найти в Интернете уже созданные диаграммы, но здесь та же проблема. Мы опять будем читать о том, как кто-то где-то и когда-то тем или иным образом "рисовал дом".

Лучше всего учиться рисовать диаграммы самому на простых задачах. Как обучают только что пришедших на работу аналитиков? Дают им простое задание, они его выполняют, задание проверяют, исправляют ошибки и дают новое. И, постепенно, аналитик начинает не просто понимать как нужно отображать тот или иной случай на диаграмме, он начинает сам, своими руками рисовать диаграммы без дополнительных вопросов. Просто чтение - не дает результата. Только практика поможет научиться применять UML в работе.