2014-02-02
2488
В последнее десятилетие в компьютерном мире наметилась тенденция моделирования сложных систем визуальными (наглядными) моделями. Причем в новых методах проектирования сложных компьютерных систем, например ООП и ООАП, наглядные модели очень часто связываются с такими зрительными образами как "взгляды", направленные на сложную систему с различных точек зрения. Набор из нескольких наглядных моделей (модельных взглядов) создает в сознании специалистов интегральный образ сложной компьютерной системы, которую они совместно проектируют. Вместе с тем, наглядные модели служат эффективным средством документирования компьютерных систем и их программных обеспечений, а также языком общения между программистами, системными аналитиками и заказчиками систем.
Наиболее известными визуальными моделями, используемыми для проектирования компьютерных систем и их программных обеспечений, являются диаграммы языка UML и стандарта IDEF0, таблицы и диаграммы стандарта IDEF1X. Эти визуальные модели имеют математическую основу в виде теорий графов, множеств и матриц.
Диаграммы и таблицы языка UML и стандартов IDEF0, IDEF1X недостаточно эффективно моделируют веб-системы и их компоненты, поскольку они представляют собой модульные системы, состоящие из взаимосвязанных модулей. Наши исследования показали, что веб-системы и веб-компоненты (например, веб-страницы, веб-документы, веб-курсы) моделируются паттерновыми (модульными) сетями. Паттерновые сети это новый вид семантических сетей. Они обладают четко выраженными модульными свойствами и поэтому эффективно моделируют веб-системы и их компоненты. Мы построим паттерновые сети во второй части Курса. А теперь займемся языком UML.
Возникает естественный вопрос. Почему 300 ведущих компьютерных фирм, объединенных в консорциуме OMG, придают такое большое значение работам по созданию версий языка UML? Чтобы ответить на этот вопрос обратимся к Рис.3.1
Рисунок позволяет понять причины революционных перемен в области технологий программирования, вызванных появлением языка UML. На нем изображены две схемы. Первая из них (Рис.3.1а) изображает ситуацию, существовавшую в области технологий программирования до создания языка UML, вторая (Рис.3.1б) - показывает изменение ситуации после появления UML. На обеих схемах слева показаны программисты и воображаемые ими модели компьютерных программ, а справа изображены коды программ и предметные области, в которых эти программы используются. На второй схеме между предметными областями и программными кодами появились диаграммы языка UML и их математическая основа – теории множеств и графов.
В чем заключаются негативные моменты ситуации, сществовавшей до появления языка UML? Как видно из Рис.3.1а объединение текста программы (ее исходного кода) с характеристиками объекта автоматизации осуществляется только в сознании программиста, а документальная связь между ними отсутствует.
Рассмотрим теперь ситуацию, возникшую после появления языка UML (Рис.3.1б). Диаграммы и спецификации языка UML связали исходный текст программы с характеристиками объекта автоматизации. При этом UML диаграммы опираются на теоретический фундамент в виде теории множеств и теории графов. Наличие теоретической основы позволяет упростить операции преобразования UML диаграмм, нарисованных на экранах дисплеев, в память компьютеров и уменьшить объем памяти, необходимой для хранения диаграмм.
Рисунок также показывает, что UML диаграммы могут преобразовываться в исходный код (прямое преобразование) и наоборот исходный код может преобразовываться в диаграммы (обратное преобразование). В некоторых случаях прямое преобразование может осуществляться автоматически с помощью программ конверторов. В настоящее время группа OMG активно работает над решением проблемы прямого преобразования диаграмм UML. Обратное преобразование может выполнить только человек.
Язык UML помог в решении болезненной для компьютерных фирм проблемы увольнения программистов с работы. Действительно, если программист уволится, то другой программист, пришедший ему на смену, чтобы войти в курс дела должен разобраться во всех тонкостях исходного кода программы. Практика показывает, что если программа сложная, то сделать это трудно, а иногда и невозможно. До появления языка UML увольнение программиста могло повлечь за собой потерю его программ. Сегодня, если программы документированы на языке UML, то после увольнения программиста другой программист, используя UML диаграммы и спецификации, может понять исходный код программы и заменить уволившегося.
Помимо решения проблемы увольнения программистов, документирование исходных кодов программ UML диаграммами и спецификациями создает единый язык общения между программистами, а также между программистами, системными аналитиками и заказчиками автоматизированной системы. Но самое главное, что дал UML - это возможность широкой стандартизации языков программирования. Известно, что в разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и символьные обозначения. Язык UML позволяет стандартизовать как сами операции и методы языков программирования так и их терминологию.
Мы рассмотрели лишь часть проблем, решаемых с помощью языка UML.
Но даже из этого неполного обзора видно насколько важна роль языка UML в совершенствовании технологий программирования и методов разработки автоматизированных систем.
3.2. Структура языка UML
В одной лекции невозможно подробно рассмотреть все особенности и детали языка UML. Для этого вам следует обратиться к литературе, посвященной языку UML, например к книге Г.Буча, Д.Рембо, А. Джекобсона "Руководство пользователя UML". Наша цель - дать общее представление о языке UML. Поэтому мы сосредоточим внимание на структуре, графических элементах и диаграммах языка.
Язык UML имеет сложную иерархическую структуру, показанную на Рис.3.2.
Как видно из рисунка, первый иерархический уровень языка UML составляют сущности, отношения между сущностями и наглядные диаграммы. Рассмотрим последовательно эти три основные понятия языка UML.
Язык UML имеет четыре вида сущностей: структурные, поведенческие, группирующие и аннотационные сущности. Они показаны на втором уровне структурного дерева языка UML, представленного на Рис.3.2.
Далее на третьем уровне дерева показано, что понятие "структурные сущности" является именем семи видов пиктограмм (выразительных рисунков), которые называются классами, интерфейсами, кооперациями, прецедентами, активными классами, компонентами и узлами.
Поведенческие сущности делятся на два вида диаграмм. Диаграммы первого вида называются взаимодействиями, второго вида - автоматами. Группирующие сущности имеют только один вид пиктограмм, называемых пакетами. Аннотационные сущности также имеют один вид пиктограмм, называемых примечаниями.
На Рис.3.3 в качестве примеров показаны пять видов пиктограмм – классы, прецеденты, актеры, пакеты и примечания.
Класс изображается прямоугольником, разделенным на три поля. В первом поле помещается имя класса, однозначно определяющее данный класс среди множества других классов. Во втором поле помещаются атрибуты (общие свойства) класса. В третьем поле располагаются типовые операции, выполняемые объектами, принадлежащими данному классу. Таким образом класс - это совокупность (множество) объектов с общими атрибутами и операциями, а также с общими отношениями и семантикой. Объектами, объединенными в класс, могут быть, например, люди, окна системы Windows, экранные кадры и другие реальные или абстрактные объекты
Вернемся к Рис. 3.3 и рассмотрим более детально, показанные на нем пиктограммы типа "прецеденты" и "актеры". Следует сказать, что термин "прецедент" это не очень удачный перевод на русский язык английского выражения use case (Computer Aided Software Engineering). Прецедент это описание множества последовательных событий, выполняемых компьютерной системой, которые приводят к наблюдаемому актером результату. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только имя прецедента.
Актер – это кто-то (или что-то) внешний по отношению к компьютерной системе, кто взаимодействует с ней. Графически актер изображается в виде пиктограммы, представляющей человека, поскольку актер это человек или группа людей, использующих данные, предоставляемые компьютерной системой. Например, в системе регистрации учебных курсов, которую мы рассмотрим в лекциях 4,5, актером являются студенты, записывающиеся на курсы преподавателей через автоматизированную систему регистрации курсов. Для базы данных федерального бюджета, функционирующей в Минфине Р.Ф., актерами являются чиновники, получающие информацию на рабочих местах базы данных Минфина. На UML диаграммах пиктограммы прецедента и актера обычно располагаются рядом. В совокупности они могут описывать внешнюю границу компьютерной системы.
Показанная на Рис.3.2 пиктограмма "пакет" изображает единственную в языке UML первичная группирующая сущность. В пакет можно поместить структурные и поведенческие сущности и даже другие пакеты. Изображается пакет в виде папки с закладкой. Существуют также вариации пакетов, например, каркасы, модели и подсистемы.
Последняя пиктограмма, показанная на Рис.3.2, называется "примечание". Примечание изображается в виде прямоугольника с загнутым краем. На UML диаграмме примечание присоединяется к одному или нескольким элементам диаграммы. Внутри прямоугольника-примечания помещаются комментарии или ограничения, относящиеся к элементу (или нескольким элементам) диаграммы. Комментарий может быть текстовым или графическим.
Рассмотрим теперь пиктограммы (рисунки) отношений, используемых в UML диаграммах. Отношения составляют вторую ветвь структурного дерева языка UML, представленного на Рис.3.2. Однонаправленные отношения представляются на UML диаграммах стрелками различных видов, а двунаправленное отношение представляется линией (Рис. 3.5).
Показанное на рисунке однонаправленное отношение " зависимость " - это семантическое отношение между двумя сущностями, такое при котором изменение одной (первичной) сущности вызывает изменение семантики другой, зависимой сущности.
Ассоциация – это структурное двунаправленное отношение, описывающее совокупность взаимоотношений между объектами. По сути дела ассоциация является сверткой бинарных отношений между объектами. Эту свертку может мысленно выполнить в своем сознании специалист (например, программист), который видит пиктограмму ассоциации на UML диаграмме.
Пометка единица (1) на левом конце линии ассоциации на Рис.3.5 означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает "единица или больше" (1..*). Если один конец линии ассоциации помечен единицей (1), то пометка на другом конце линий называется кратностью ассоциации. Кратность правого конца ассоциации, показанной на Рис.3.5, равна единице или больше.
На линии ассоциации можно также задать кратность равную единице (1), можно указать диапазон кратности: ноль или единица (0..1), много (0..*). Разрешается также указывать кратность определенным числом (например 5). С помощью списков можно задавать и более сложные кратности. Например, список 0..1, 3..4, 6..* означает "любое число объектов кроме 2 и 5".
Частным случаем ассоциации является отношение типа "часть/целое". Отношение такого типа называется агрегированием. В языке UML оно причислено к отношениям вида "имеет". Агрегирование изображается в виде ассоциации с незакрашенным ромбом со стороны целого, как показано на Рис.3.6
Обобщение (см. Рис.3.5) - это однонаправленное отношение, называемое "потомок/прародитель", в котором объект "потомок" может быть подставлен вместо объекта прародителя (родителя или предка). Потомок наследует структуру и поведение своего родителя. Стрелка всегда указывает на родителя.
Наконец, реализация – это семантическое однонаправленное отношение, которое может устанавливаться, во-первых, между интерфейсами и реализующими их классами или компонентами, во-вторых, между прецедентами и реализующими их кооперациями. Интерфейсы, компоненты и кооперации это еще три вида пиктограмм, относящихся к структурным сущностям (см. Рис.3.2). Пиктограммы интерфейса, кооперации и компонента показаны на Рис.3.7
Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Следовательно интерфейс описывает поведение класса или компонента, видимое извне. Интерфейс определяет только описание (спецификации) операций класса или компонента, но он никогда не определяет физические реализации операций. Графически интерфейс изображается небольшим кружочком под которым пишется его имя, как показано на Рис.3.7.
Кооперация определяет взаимодействие, например классов. Участвуя в кооперации классы совместно производят некоторый кооперативный результат. Один и тот же класс может принимать участие в нескольких кооперациях. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, как показано на Рис.3.6.
Компонент – это физическая часть компьютерной или иной системы. Компонент соответствует некоторому набору интерфейсов и обеспечивает физическую реализацию этого набора. Компоненты могут быть разных видов. Например, одним из видов компонент, используемых для моделирования программного обеспечения компьютерной системы, могут быть файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, как показано на Рис.3.6. Внутри прямоугольника обычно пишется только имя компонента.
Рисунки других видов пиктограмм языка UML, с пояснением их смысла, вы найдете в книге Г. Буча. Пиктограммы - это логические кирпичики из которых составляются UML диаграммы.
3.3. UML диаграммы
С помощью комбинации пиктограмм строятся UML диаграммы. Девять основных видов диаграмм перечисленных в третьей ветви структурного дерева языка UML (см. Рис.3.2). Мы не будем изучать все девять видов UML диаграмм, а рассмотрим только три из них - диаграммы прецедентов, диаграммы классов и диаграммы действий.
Диаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и взаимодействий между ними. В каждой системе обычно есть главная диаграмма прецедентов, которая описывает внешнюю границу системы и основные внешние функции (внешнее поведение) системы. Основная диаграмма прецедентов Автоматизированной системы регистрации учебных курсов будет построена в Лекции 5. А пока, в качестве примера диаграммы прецедентов мы рассмотрим диаграмму, изображающую все прецеденты для одного актера, которым является регистратор учебных курсов. Эта диаграмма показана на Рис.3.8
Диаграммы классов применяются для моделирования объектно-ориентированных систем. На простых диаграммах показываются классы и отношения между классами. На сложных диаграммах показываются классы, интерфейсы, кооперации и отношения между ними. Диаграммы классов дают статический вид системы. Можно также сказать, что диаграммы классов представляют собой взгляды разработчиков на статические состояния проектируемых систем. С помощью диаграмм классов составляется словарь системы. Диаграммы классов являются основой для создания диаграмм компонентов и развертывания. Следует особо подчеркнуть, что диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых кодов систем. На Рис.3.9 приведен пример простой диаграммы классов, моделирующей объекты системы регистрации курсов и отношения между ними.
UML диаграммы классов включают в себя как частный случай диаграммы "сущность-связь" (Entity-relationship diagrams), которые используются для логического проектирования реляционных, объектно-ориентированных и гибридных объектно-реляционных баз данных.
В заключение рассмотрим диаграммы действий. Но прежде познакомимся с пиктограммами "действие", "переход", "выбор" и "линии синхронизации", используемыми в диаграммах действия. Эти пиктограммы представлены на Рис.3.10.
В языке UML действие изображается в виде прямоугольника с закругленными углами, переходы - в виде направленных стрелок, элементы выбора - в виде ромбов, линии синхронизации - в виде горизонтальных и вертикальных линий (Рис.3.10).
На Рис.3.11 приведен пример диаграммы действий моделирующей действия, выполняемые в процессе создания системы регистрации учебных курсов.
