Министерство образования республики Беларусь Учреждение образования «БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ» Институт информационных технологий
Специальность Информационные системы и технологии
КОНТРОЛЬНАЯ РАБОТА
По курсу Современные информационные технологии
Вариант № 14
Минск, 2012
Содержание
1. Шаблоны (образцы) проектирования: структура и методы применения шаблонов. 3 2. Модели, выполненные в стандарте IDEF0. 9 3. Модели, выполненные в стандарте UML. 15 Список использованной литературы. 22
1. Шаблоны (образцы) проектирования: структура и методы применения шаблонов.
В разработке программного обеспечения, шаблон проектирования или паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. «Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные. На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы. Алгоритмы по своей сути также являются шаблонами, но не проектирования, а вычисления, так как решают вычислительные задачи. История В 1970-е годы архитектор Кристофер Александр составил набор шаблонов проектирования. В области архитектуры эта идея не получила такого развития, как позже в области программной разработки. В 1987 году Кент Бэк (Kent Beck) и Вард Каннигем (Ward Cunningham) взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk. В 1988 году Эрих Гамма (Erich Gamma) начал писать докторскую диссертацию при цюрихском университете об общей переносимости этой методики на разработку программ. В 1989—1991 годах Джеймс Коплин (James Coplien) трудился над разработкой идиом для программирования на C++ и опубликовал в 1991 году книгу Advanced C++ Idioms. В этом же году Эрих Гамма заканчивает свою докторскую диссертацию и переезжает в США, где в сотрудничестве с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидсом (John Vlissides) публикует книгу Design Patterns — Elements of Reusable Object-Oriented Software. В этой книге описаны 23 шаблона проектирования. Также команда авторов этой книги известна общественности под названием «Банда четырёх» (англ. Gang of Four, часто сокращается доGoF). Именно эта книга стала причиной роста популярности шаблонов проектирования. Польза Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация терминологии, названий модулей и элементов проекта. Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. Критика Иногда шаблоны консервируют громоздкую и малоэффективную систему понятий, разработанную узкой группой. Когда количество шаблонов возрастает, превышая критическую сложность, исполнители начинают игнорировать шаблоны и всю систему, с ними связанную. Нередко шаблонами заменяется отсутствие или недостаточность документации в сложной программной среде. Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механической подстановкой шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов необходимо тогда, когда программист «дорос» до них в профессиональном плане — и не раньше. Хороший критерий нужной степени профессионализма — выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов «по справочнику». Шаблоны могут пропагандировать плохие стили разработки приложений, и зачастую слепо применяются. Для преодоления этих недостатков используется рефакторинг.
Типы шаблонов проектирования Название Оригинальное название Описание Основные шаблоны (Fundamental) Шаблон делегирования Delegation pattern Объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту Шаблон функционального дизайна Functional design Гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы Неизменяемый объект Immutable Объект, который не может быть изменён после своего создания Интерфейс Interface Общий метод для структурирования компьютерных программ для того, чтобы их было проще понять Хранитель свойств Property Container Функция данного шаблона - обеспечить динамическую расширяемость уже готового приложения. Порождающие шаблоны (Creational) — шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту. Абстрактная фабрика Abstract factory Класс, который представляет собой интерфейс для создания компонентов системы. Строитель Builder Класс, который представляет собой интерфейс для создания сложного объекта Фабричный метод Factory method Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанциировать Отложенная инициализация Lazy initialization Объект, инициализируемый во время первого обращения к нему Пул одиночек Multiton Гарантирует, что класс имеет поименованные экземпляры объекта и обеспечивает глобальную точку доступа к ним Объектный пул Object pool Класс, который представляет собой интерфейс для работы с набором инициализированных и готовых к использованию объектов Прототип Prototype Определяет интерфейс создания объекта через клонирование другого объекта вместо создания через конструктор Получение ресурса есть инициализация Resource acquisition is initialization (RAII) Получение некоторого ресурса совмещается с инициализацией, а освобождение — с уничтожением объекта Одиночка Singleton Класс, который может иметь только один экземпляр. Структурные шаблоны (Structural) определяют различные сложные структуры, которые изменяют интерфейс уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу.
Адаптер Adapter / Wrapper Объект, обеспечивающий взаимодействие двух других объектов, один из которых использует, а другой предоставляет несовместимый с первым интерфейс Мост Bridge Структура, позволяющая изменять интерфейс обращения и интерфейс реализации класса независимо Компоновщик Composite Объект, который объединяет в себе объекты, подобные ему самому Декоратор или Wrapper / Обёртка Decorator Класс, расширяющий функциональность другого класса без использования наследования Фасад Facade Объект, который абстрагирует работу с несколькими классами, объединяя их в единое целое Единая точка входа Front Controller Обеспечивает унифицированный интерфейс для интерфейсов в подсистеме. Front Controller определяет высокоуровневый интерфейс, упрощающий использование подсистемы Приспособленец Flyweight Это объект, представляющий себя как уникальный экземпляр в разных местах программы, но по факту не являющийся таковым Заместитель Proxy Объект, который является посредником между двумя другими объектами, и который реализовывает/ограничивает доступ к объекту, к которому обращаются через него Поведенческие шаблоны (Behavioral) определяют взаимодействие между объектами, увеличивая таким образом его гибкость. Цепочка ответственности Chain of responsibility Предназначен для организации в системе уровней ответственности Команда, Action, Transaction Command Представляет действие. Объект команды заключает в себе само действие и его параметры Интерпретатор Interpreter, Cursor Решает часто встречающуюся, но подверженную изменениям, задачу Итератор Iterator Представляет собой объект, позволяющий получить последовательный доступ к элементам объекта-агрегата без использования описаний каждого из объектов, входящий в состав агрегации Посредник Mediator Обеспечивает взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга Хранитель, Token Memento Позволяет не нарушая инкапсуляцию зафиксировать и сохранить внутреннее состояния объекта так, чтобы позднее восстановить его в этом состоянии Null object Предотвращает нулевые указатели, предоставляя объект «по умолчанию» Наблюдатель, Dependents, Publish-Subscribe, Listener Observer илиPublish/subscribe Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии Servant Слуга Используется для обеспечения общей функциональности группе классов Спецификация Specification Служит для связывания бизнес-логики Objects for States, State Состояние Используется в тех случаях, когда во время выполнения программы объект должен менять свое поведение в зависимости от своего состояния Стратегия Strategy Предназначен для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости Шаблонный метод Template method Определяет основу алгоритма и позволяет наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом. Посетитель Visitor Описывает операцию, которая выполняется над объектами других классов. При изменении класса Visitor нет необходимости изменять обслуживаемые классы. Единственный посетитель Single-serving visitor Оптимизирует реализацию шаблона посетитель, который инициализируется, единожды используется, и затем удаляется Иерархический посетитель Hierarchical visitor Предоставляет способ обхода всех вершин иерархической структуры данных (напр. древовидной)
2. МОДЕЛИ, ВЫПОЛНЕННЫМ В СТАНДАРТЕ IDEF0
Моделирование сложных систем (какими являются современные промышленные системы) было начато в программе интегрированной автоматизации производства (ICAM - (Integrated Computer Aided Manufacturing) Министерства обороны США в которой была признана полезность методологии SADT (Structured Analysis and Design Technique - Технология структурного анализа и проектирования) введенной в 1973 году Россом, что привело к стандартизации и публикации ее части, называемой IDEF0 (IDEF=ICAM DEFinition или Integration Definition for Function Modeling). C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 году – IDEF0 был принят в качестве стандарта в Российской Федерации. IDEF0 - методология функционального моделирования. С помощью простого и гармоничного графического языка IDEF0, моделирования система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функциональных блоков.
1. Функциональный блок (Activity Box). Функциональный блок графически изображается в виде прямоугольника и представляет собой некоторую конкретную функцию в моделируемой системы. Название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: Верхняя сторона имеет значение “Управление” (Control); Левая сторона имеет значение “Вход” (Input); Правая сторона имеет значение “Выход” (Output); Нижняя сторона имеет значение “Ресурсы” (Mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
2. Интерфейсная стрелка - интерфейсная дуга, поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Интерфейсная стрелка «вход» (Input). Интерфейсные стрелки «вход» характеризуют собой сырье, материалы или информацию, которые преобразуются функциональным блоком для создания выхода (продукта действия). Интерфейсная стрелка «вход» расположена в левой части прямоугольника действия и направлена на прямоугольник. Интерфейсная стрелка «вход» необязательна. Интерфейсная стрелка «управление» (Control). Интерфейсная стрелка «управление» управляет преобразованием входа в выход. Каждый функциональный блок должен иметь по крайней мере одну управляющую интерфейсную стрелку. Интерфейсная стрелка «управление» изображается вверху прямоугольника действия и направлена на него. «Управление» осуществляется в форме регламентов, стандартов, процедур или технической документации. Интерфейсная стрелка «ресурс» (Mechanism) Интерфейсная стрелка «Ресурсы» – обозначает те ресурсы, которые требуются для преобразования входа в выход. Ресурсами могут являться, например, люди, машины и оборудование. Интерфейсная стрелка «ресурс» не является обязательной. Интерфейсная стрелка «выход» (Output) Выход – это материалы или информация, производимая функциональным блоком из входа. Каждое действие должно иметь, по крайней мере одну интерфейсную стрелку «выход». Интерфейсные стрелки ссылки (Call Arrow). Интерфейсные стрелки ссылки используются для указания на другие модели или диаграммы внутри модели, которые могут помочь изучающему лучше понять существующую модель. Интерфейсная стрелка ссылки может ссылаться на другую диаграмму внутри самой модели и может также ссылаться к специфическому дочернему действию другой модели. Это способ, в котором функциональное дублирование может быть удобнее задокументировано в модели. Обязательное наличие управляющих интерфейсных стрелок является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
3. Декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет представить модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”. Цель Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы: • почему был смоделирован представленный процесс; • что эта модель собирается показать; • что с ней могут сделать читающие ее. Формулировка цели позволяет команде экспертов придерживаться ее на протяжении всего процесса моделирования. Без формулировки цели моделирование может зайти в тупик. Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом: • каковы основные задачи сотрудника; • кто отвечает за произведенную продукцию; • кто управляет начальной стадией производства; • какой требуется инструмент для каждого этапа. Точка зрения (Viewpoint). Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев). Эти диаграммы используются только в качестве материалов для презентаций. Точка зрения должна формулироваться с особенной внимательностью, отталкиваясь от цели. При построении модели важно придерживаться одной точки зрения. Точка зрения должна содержать наименование должности, структурного подразделения или описание должностных обязанностей работника. Модели могут содержать разнообразные точки зрения с целью детальной фиксации всех действий (функций). В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).
При декомпозиции функционального блока все стрелки, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует. Туннели (Tunnels). Связывание интерфейсных стрелок используется в моделях для определения уровня детализации в диаграмме. В случае, когда интерфейсная стрелка не возникает на базовой диаграмме, но и не связана с другими интерфейсными стрелками, туннель используется для указания того, что интерфейсная стрелка входит или выходит из системы. Туннель используется, чтобы не загромождать базовую диаграмму. В других случаях туннель может быть использован в интерфейсной стрелке, ведущей в (или из) базового действия. Это указывает на то, что взаимоотношения интерфейсной стрелки с дочерними действиями не определены.
4. Глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных стрелок существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Он дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Рассмотрим процесс моделирования в методологии IDEF0 на примере контекстной диаграммы разработанной модели. Цель модели – оплатить больничные листы. Точка зрения модели – бухгалтерия. Входы модели – больничные листы. Регламентация процесса учета – законодательство, руководство. Выход процесса – выплаты по больничным листам.
Рисунок 2.1. Оплатить больничные листы. Уровень А-0
Рисунок 2.2. Оплатить больничные листы. Уровень А0
Рисунок 2.3. Изучение листов. Уровень А1
Рисунок 2.4. Расчет выплат. Уровень А2
Рисунок 2.5. Начисление выплат. Уровень А3
3. МОДЕЛИ, ВЫПОЛНЕННЫЕ В СТАНДАРТЕ UML
Основная цель создания любой программной системы - создание такого программного продукта, который помогает пользователю выполнять свои повседневные задачи. Для создания таких программ первым делом определяются требования, которым должна удовлетворять система. Однако если дать пользователям написать эти требования на бумаге, то часто можно получить список функций, по которому трудно судить будет ли будущая система выполнять свое назначение и сможет ли она облегчить пользователю выполнение его работы вообще. Непонятно какие из выполняемых функций более важны и для кого. Для того, чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.
Рисунок 3.1. Диаграмма прецедентов
Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия. Диаграммы состояний чаще всего используются для описания поведения отдельных объектов, но также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы. Диаграмма состояний является графом специального вида, который представляет некоторый автомат. Вершинами графа являются возможные состояния автомата, изображаемые соответствующими графическими символами, а дуги обозначают его переходы из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели.
Рисунок 3.2. Диаграмма состояний
Удобное средство для обозначения очередности следования друг за другом различных стимулов (сообщений), с помощью которых объекты взаимодействуют между собой. Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы. Главный акцент - порядок и динамика поведения, т.е. как и в каком порядке происходят события. Отличие от диаграммы классов: Диаграмма классов дает статическую картинку, т.е. описание которое не меняется во время выполнения программы. Отличие от диаграммы коммуникаций (или как она раньше называлась colaboration): Диаграмма последовательности фокусирует наше внимание на очередности выполнения по времени, а диаграмма коммуникаций - на составляющих элементах. Обычно нормальные люди стараются описывать одной диаграммой только один определенный кейс (UseCase, вариант использования), например: "оставить коммент к сообщению в блоге", "стать постоянным читателем" и т.д.
Рисунок 3.3. Диаграмма взаимодействия
Полный проект программной системы представляет собой совокупность моделей логического и физического уровней, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя диаграмму компонентов и диаграмму развертывания. Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей: • визуализации общей структуры исходного кода программной системы; • спецификации исполняемого варианта программной системы; • обеспечения многократного использования отдельных фрагментов программного кода; • представления концептуальной и физической схем баз данных. В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.
Рисунок 3.4. Диаграмма компонентов
Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Если разрабатывается программа, выполняющаяся локально на компьютере пользователя и не использующая периферийных устройств и ресурсов, то в разработке дополнительных диаграмм нет необходимости. При разработке же корпоративных приложений наличие таких диаграмм может быть крайне полезным для решения задач рационального размещения компонентов в целях эффективного использования распределенных вычислительных и коммуникационных ресурсов сети, обеспечения безопасности и других. Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы развертывания. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Разработка диаграммы развертывания, как правило, является последним этапом спецификации модели программной системы. При разработке диаграммы развертывания преследуют следующие цели: • определить распределение компонентов системы по ее физическим узлам; • показать физические связи между всеми узлами реализации системы на этапе ее исполнения; • выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности. Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.
Рисунок 3.5. Диаграмма поставки
Диаграмма классов, Class diagram — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения: • концептуальная точка зрения - диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов; • точка зрения спецификации - диаграмма классов применяется при проектировании информационных систем; • точка зрения реализации - диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Рисунок 3.6. Диаграмма классов
Список использованной литературы
1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес — Приемы объектно-ориентированного проектирования. Паттерны проектирования. 2. А. Шаллоуей, Дж. Тротт — Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию. 3. Розенберг Д., Скотт К. Применение объективного моделирования с использованием UML и анализ прецедентов. ДМК Пресс, 2002 г. 4. Ларман К. Применение UML и шаблонов проектирования. Вильямс, 2004 г.
