- Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

- UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

- UML получил широкое распространение и динамично развивается.

1.4 Критика

Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

- Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.

- Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

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

- Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»).[2][3] В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.

- Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).

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

2. Проектирование информационной системы «Школа»

2.1 Создание диаграммы вариантов использования

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

Рис. 1 Диаграмма вариантов использования задачи о заявке на перевоз груза

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

2.2 Создание диаграммы последовательности

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

Рис.2 Диаграмма последовательности

2.3 Создание Кооперативной диаграммы

В данном разделе я так же раскрыл вариант «Определение качества знаний» с помощью кооперативной диаграммы. Данная диаграмма также как и диаграмма последовательности отражает процесс проверки качества знаний.

Рис.3 Кооперативная диаграмма

2.4 Диаграмма Состояний для класса Заявка

Рис.4 Диаграмма Состояний для класса Заявка

Заключение

Перед мной была поставлена задаче –спроектировать схему процессов работы школы. При решении задачи я пользовался специальной программой для проектирования RationalRoseEnterprise, сам проект выполнен на языке UML. В выполненном проекте были разработаны диаграммы логического представления, тем самым все поставленные цели были достигнуты. Задача решена в полном объеме.

Список используемой литературы

1. Методические указания, автор Омарбекова А.С.

2. Интернет ресурс http://citforum.ru/database/articles/umlbases.shtml

3. Интерфейс: новые направления в проектировании компьютерных систем, автор Д.Раскин

4. ASE-технологии. Современные методы и средства проектирования информационных систем, автор неизвестен