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

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

• Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.
• Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и подробной семантики, то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML и OCL противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
• Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
• Только код отражает код. Ещё одно мнение, что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО. UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
• Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
• Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

В заключение описания возможностей UML рассмотрим несколько рекомендаций по его применению.

Очевидно, что относительно простые задачи моделируются с помощью UML без труда. Легко поддаются моделированию и сложные задачи, особенно если вы уже приобрели некоторый опыт использования этого языка.

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

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

По оценке авторов UML [1] 80% всевозможных проектов можно воплотить, используя 20% средств UML.

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

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

Если у вас нет опыта объектно-ориентированной разработки, можно воспользоваться следующими рекомендациями:

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

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

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

Если у вас нет опыта моделирования, поступите так:

1. Возьмите какую-нибудь часть ранее созданной вами системы (желательно, чтобы она была реализована на одном из объектно-ориентированных языков программирования, например C++) и постройте модель использованных в ней классов и отношений между ними.

2. С помощью UML попытайтесь прояснить некоторые детали идиом или механизмов программирования из тех, что были использованы в системе, но не отражены в коде явно, а находятся только в стадии замысла.

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

4. Освоив словарь UML, прежде чем приступать к переводу в код своего следующего проекта, постройте его модель. Сосредоточьтесь на специфицированном поведении и структуре; только после вывода о том, что размер, форма и семантика вас устраивают, начинайте использовать построенную модель как основу для реализации.

Если вы уже знакомы с какой-либо другой объектно-ориентированной методикой, поступите следующим образом:

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

2. Рассмотрите какую-нибудь сложную проблему моделирования, которую вам с трудом удалось или вообще не удалось решить с помощью знакомого языка. Выясните, нет ли среди средств UML таких, которые позволят решить ее проще или изящнее.

Если вы опытный пользователь, вам пригодятся следующие советы:

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

2. Обратите особое внимание на средства UML для моделирования компонентов, параллельности, распределённости и образцов (паттернов). Это вопросы, семантика которых сложна и подлежит тщательному анализу.

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

По адресу [6] можно получить последние версии стандарта UML.

Список литературы

1. Буч Г., РамбоД., Якобсон И. Введение в UML от создателей языка.2‑е изд. – М.: ДМК Пресс, 2011. 496 с.

2. Ларман, Крэг. Применение UML и шаблонов проектирования. 2-е издание.: Пер. с англ. — М.: Издательский дом "Вильямс", 2004. — 624 с.

3. Фаулер М., Скотт К. UML. Основы. – Пер. с англ. – СПб: Символ-Плюс, 2002. -192 с.

4. Боггс У., Боггс М. UML и Rational Rose 2002. Пер. с англ. – М.: Изд. «Лори». 2004. - 510 с.

5. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

6. Спецификация UML: http://www.omg.org/spec/UML/

7. http://msdn.microsoft.com/en-us/library/dd409436.aspx