Особенности графического изображения диаграмм языка UML

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

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

диаграммы классов;

диаграммы объектов;

диаграммы Use Case (диаграммы прецедентов);

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

диаграммы сотрудничества (кооперации);

диаграммы схем состояний;

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

компонентные диаграммы;

диаграммы размещения (развертывания).

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

особенности графического изображения диаграмм языка UML

В UML имеются четыре разновидности предметов:

структурные предметы;

предметы поведения;

группирующие предметы;

поясняющие предметы.

Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы. Перечислим восемь разновидностей структурных предметов.

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

Рис. 10.1. Классы

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

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

Рис. 10.3. Кооперации

Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой

Рис. 10.4. Актеры

Элемент Use Case (Прецедент) — описание последовательности действий (или нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих видимый для актера результат..

Рис. 10.5. Элементы Use Case

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

Рис. 10.6. Активные классы

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

Рис. 10.7. Компоненты

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

Рис. 10.8. Узлы

24 Порядок разработки программного модуля.

При разработке программного модуля целесообразно придерживаться следующего порядка:

- изучение и проверка спецификации модуля, выбор языка программирования;

- выбор алгоритма и структуры данных;

- программирование (кодирование) модуля;

- шлифовка текста модуля;

- проверка модуля;

- компиляция модуля.

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

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

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

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

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

· формулировка целей (результатов) работы программы;

· образное представление процессы ее работы (образная модель);

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

Попробуем теперь встроить в общую схему процесса проектирования самое трудное направление «движения» при построении программы – от общего к частному. И тогда получим примерно такую картину.

Рис. 33.1. Этапы структурного проектирования