Диаграмма прецедентов (Use case diagram, диаграмма вариантов использования) — диаграмма, на которой отражены отношения, существующие между акторами и прецедентами.

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

     Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.

     Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

     Диаграмма последовательности (Sequence diagram) — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

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

     По  причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

     Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

     Этот  тип диаграмм включает в себя диаграммы  Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

     Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

1.3 Преимущества UML

• UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
• UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• Диаграммы 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 Диаграмма Состояний для класса Заявка

 

Заключение

 

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

 

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

 
 

1. Методические  указания, автор Омарбекова А.С.
2. Интернет ресурс http://citforum.ru/database/articles/umlbases.shtml
3. Интерфейс: новые направления в проектировании компьютерных систем, автор Д.Раскин
4. ASE-технологии. Современные методы и средства проектирования информационных систем, автор неизвестен