Особенности графического изображения диаграмм языка 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. Этапы структурного проектирования