Моделирование программ и его необходимость

Моделирование программ и его необходимость

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

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

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

Итак, что же такое модель? Модель - это чертеж системы: в нее мо­жет входить как детальный план, так и более абстрактное представление системы. Хорошая модель всегда включает элементы, существенно влияющие на результат, и не включает те, которые малозначимы на данном уровне абстракции.

Моделирование позволяет решить четыре различных задачи:

1. Визуализация системы в ее текущем или желаемом состоянии;

2. Определение структуры и поведения системы;

3. Получение шаблона, по которому в дальнейшем будет сконструирована система;

4. Документирование системы по получившейся модели.

UML как результат развития методов разработки больших объектно-ориентированных программных систем

UML (Unified Modeling Language) с 1997 года является стандартом в области визуального объектно-ориентированного моделирования и широко используется на практике для проектирования программных систем и бизнес-моделей.

В середине 90-х существовало более 50 различных объектно- ориентированных языков моделирования. И разработчики, и заказчики ис­пытывали беспокойство при выборе метода проектирования ИС.

Разработка UML была начата в октябре 1994 Грэди Бучем (Grady Booch) и Джимом Рамбо (Jim Rumbaugh) в Rational Software Corporation как унификация двух методов: Booch'93 и ОМТ. Первая версия Унифици­рованного Метода (Unified Method 0.8) была опубликована в октябре 1995. Осенью 1995 к работе присоединился Айвер Якобсон (Ivar Jacobson), включив в процесс унификации свой метод OOSE. Таким образом, на пер­вом концептуальном этапе UML имел трех авторов: Буча, Рамбо и Якобсо­на, каждый их которых являлся идеологом своего ОО метода визуального моделирования.

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

Rational Software под своей эгидой создала организацию "Консорциум UML партнеров" для выработки формального определения стандарта UML 1.0. В результате в январе 1997 г. был представлен вариант UML 1.0.

В это же время независимо от "UML Partners consortium" некоторые компании по разработке программных систем представили свой вариант стандарта UML 1.0. Для объединения предложений по двум пред­ставленным проектам UML эти компании также присоединились к "UML Partners consortium" и в результате был подготовлен вариант UML 1.1. Именно этот вариант в ноябре 1997 года был утвержден как стандарт.

 

Назначение и состав UML

UML – это язык визуализации, специфицирования, конструирования и документирования программных систем.

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

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

Некоторые особенности системы лучше всего моделировать в виде текста, другие – графически, используя UML. Модель, написанная одним разработчиком (которая воспринимается визуально, через диаграммы), может быть однозначно интерпретирована другим - или даже инструментальной программой.

Конструирование: UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации. Однако решение обратной задачи потребует непосредственного вмешательства человека.

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

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

Имеется 4 типа сущностей: структурные, поведенческие, группирующие, аннотационные. Структурные сущности – это имена существительные в моделях на языке UML. Существует 7 разновидностей сущностей: Класс – описание совокупности объектов с общими характеристиками, операциями и отношениями. Графически класс обозначается как прямоугольник в котором описаны его имя, свойства и реализуемые методы. Интерфейс – совокупность операций, которые определяют набор методов, предоставляемый классам для реализации. Графически интерфейс обозначается как не закрашенный круг, под которым пишется его имя. Кооперация определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая совместно выполняют некоторую сложную(-ые) операцию(-и). Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в которой заключается имя кооперации. Прецедент – последовательность действий, которая производит наблюдаемый результат, значимый для определенного актера. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса с именем. Активный класс – класс, который принимает участие в работе непосредственно процесса или процессов и оказывает управляющее воздействие. Графически активный класс обозначается так же как и обычный, с тем лишь отличием, что прямоугольник его рисуется жирной линией. Компонент – это физически заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Графически компонент изображается в виде прямоугольника с вкладками, в котором содержится имя. Узел – это элемент реальной системы, который представляет собой вычислительный ресурс, обладающий некоторыми характеристиками. Графически обозначается в виде куба, содержащего имя и иногда характеристики.

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

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

Аннотационные сущности – пояснительные части модели UML. Комментарий присоединяется к элементу или группе элементов и поясняет, например, его конкретное назначение. Графически обозначается в виде прямоугольника с «загнутым» краем.

Так же в UML определены 4 вида отношений: обобщение, реализация, зависимость, ассоциация. Обобщение – отношение, при котором объект осуществляется связь «предок-потомок», т.е. наследование. Изображается в виде сплошной линии с не закрашенным треугольником на конце. Реализация – отношение при котором один элемент предоставляет рад «услуг», а второй элемент обязуется эти услуги выполнить. Уместен при отношении между интерфейсом и классом, реализующим этот интерфейс. Изображается в виде пунктирной линии с не закрашенным треугольником на конце. Зависимость – выражает отношение, при котором одна сущность, некоторым образом зависит от другой. Чаще всего характеризуется тем, что при изменении одной сущности (независимой) следует изменение другой – зависимой. Графически обозначается, как пунктирная линия с простой стрелкой на конце «>». Ассоциация – выражает некоторое отношение между сущностями. Изображается как сплошная линия без стрелок, с возможными пометками кратности или имени. Включает в себя агрегацию и композицию. Обе части выражают отношения «часть – целое». Агрегация уместна в случае, если часть может существовать без целого и обозначается сплошной линией с не закрашенным ромбом на конце, композиция – если часть не может существовать без целого, обозначается сплошной линией с закрашенным ромбом на конце.

 

4. Диаграмма вариантов использования

Данная диаграмма выражает функциональные возможности системы.

Составными частями данной диаграммы являются: актеры, варианты использования и отношения между ними.

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

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

Диаграмма вариантов может дополняться пояснительным текстом, который раскрывает смысл составляющих ее компонентов. Такой пояснительный текст получил название примечания. Графически примечания обозначаются прямоугольником с "загнутым" верхним правым уголком. Внутри прямоугольника содержится текст примечания. Примечание с элементом соединяется пунктирной линией.

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

Стандартным графическим обозначением актера на диаграммах является фигурка "человечка", под которой записывается его имя.

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

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

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

Отношение обобщения служит для указания, например, того факта, что некоторый актер наследует функции, доступные другому. Графически данное отношение обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на «родительский» элемент.

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

 

Диаграмма классов

Диаграмма классов описывает структуру системы, показывая её классы, их свойства и методы, а также взаимосвязи этих классов.

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

Обязательным элементов обозначения класса является его имя.

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

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

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

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

Отношениями, изображаемыми на диаграмме классов служат:

- Отношение зависимости;

- Отношение ассоциации;

- Отношение обобщения;

- Отношение реализации.

Диаграмма состояний

Диаграмма состояний является графом работы цифрового автомата. Вершинами этого графа являются состояния. Дуги графа служат для обозначения переходов из состояния в состояние.

Формализм обычного автомата основан на выполнении следующих обязательных условий:

- Автомат не запоминает историю перемещения из состояния в состояние.

- В каждый момент времени автомат может находиться в одном и только в одном из своих состояний.

- Количество состояний автомата должно быть обязательно конечным.

- Граф автомата не должен содержать изолированных состояний и переходов.

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

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Имя всегда записывается с заглавной буквы. Рекомендуется в качестве имени использовать глаголы в настоящем времени (звенит, печатает, ожидает) или соответствующие причастия (занят, свободен, передано, получено).

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

Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности, получении объектом сообщения или приемом сигнала. На переходе указывается имя события.

На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние. Каждый переход может помечен строкой текста.

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

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

 

 

Диаграмма деятельности

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

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

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

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

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

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

В языке UML для этой цели используется специальный символ для разделения и слияния параллельных вычислений или потоков управления.

Не менее важная область применения диаграмм деятельности связана с моделированием бизнес-процессов.

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

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

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

 

 

 

 

Диаграмма компонентов

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

Компонент может иметь также свои собственные свойства, такие как атрибуты и операции.

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

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

Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от зависимого элемента к независимому. Применительно к диаграмме компонентов зависимости могут связывать компоненты и интерфейсы, а также компоненты между собой.

В случае если рисуют стрелку от компонента к импортируемому интерфейсу, это означает, что компонент использует его в процессе своего выполнения.

Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов.

Наконец, на диаграмме компонентов могут быть представлены отношения зависимости между компонентами и реализованными в них классами.

 

Диаграмма развертывания

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

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

Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа.

Второй способ разрешает показывать на диаграмме развертывания узлы с вложенными изображениями компонентов.

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

Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок.

Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами.

Моделирование программ и его необходимость

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

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

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

Итак, что же такое модель? Модель - это чертеж системы: в нее мо­жет входить как детальный план, так и более абстрактное представление системы. Хорошая модель всегда включает элементы, существенно влияющие на результат, и не включает те, которые малозначимы на данном уровне абстракции.

Моделирование позволяет решить четыре различных задачи:

1. Визуализация системы в ее текущем или желаемом состоянии;

2. Определение структуры и поведения системы;

3. Получение шаблона, по которому в дальнейшем будет сконструирована система;

4. Документирование системы по получившейся модели.