
- •СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ……………………………….
- •1.1. Средства описания архитектуры предприятия
- •Система разработки архитектуры предприятия
- •1.2. CASE-средства. Общая характеристика и классификация
- •Начало создания модели в AllFusion ERwin DM
- •Уровни модели данных
- •Сущности
- •Связи
- •Связи идентифицирующие и неидентифицирующие
- •Связь «многие ко многим»
- •Типы зависимых сущностей
- •Иерархия категорий (иерархия наследования)
- •Ключи
- •1.7. ARIS-средства описания бизнес-процессов
- •1.8. Средства моделирования бизнес-процессов, приложений и данных
- •Отличительные возможности и функции CA ERwin Modeling Suite 7.3
- •Новые функции CA ERwin Data Modeler 7.3 (ERwin)
- •Функциональные возможности CA ERwin Data Modeler 7.3 (ERwin)
- •Поддерживаемые СУБД:
- •Интеграция с другими продуктами
- •CA ERwin Data Model Validator 7.3 (ERwin Examiner)
- •Характеристика Power Designer 16.0
- •2.1. Информационная система «Телефонная служба приема заявок»
- •Диаграммы вариантов использования (use case diagrams)
- •Диаграммы активностей (activity diagrams)
- •Диаграммы развертывания (deployment diagrams)
- •Диаграммы компонент (component diagrams)
- •Диаграммы коммуникаций (communication diagrams)
- •Диаграммы последовательностей (sequence diagrams)
- •Временные диаграммы (timing diagrams)
- •Диаграммы классов (class diagrams)
- •Диаграммы пакетов (package diagrams)
- •Диаграммы объектов (object diagrams)
- •Кооперации (collaborations)
- •Диаграммы конечных автоматов (statechart diagrams)
- •Описание процесса деятельности
- •Состав функций, комплексов задач реализуемых системой (подсистемой)
- •Решения по комплексу технических средств, его размещению на объекте
- •Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам
- •Основные технические решения
- •Решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы
- •20. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML [Электронный ресурс] / А.В.Леоненков. Режим доступа: www.intuit.ru.
- •38. Фаулер, М. Архитектура корпоративных программных приложений / М. Фаулер. М.: Вильямс, 2004. 544 с.
- •53.UML спецификация. – www.omg.com.

|
Panel |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
locked |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Panel |
door |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
access_prcessor |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
open |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
processor |
|
|
|
|
|
|
|
|
|
|
0 |
|
|
|
|
|
|
|
|
|
access |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
door |
verifying |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Default |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
enabled |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0 |
5 |
10 |
15 |
20 |
25 |
30 |
35 |
40 |
45 |
50 |
55 |
60 |
65 |
70 |
75 |
80 |
85 |
90 |
95100 |
|
|
|
|
|
Рис. 2.9. Временная диаграмма |
|
|
|
|
|
|
Видно, что на временных диаграммах, так же как на диаграммах последовательностей и коммуникаций, показываются только главные ветви алгоритмов, а ветвления отсутствуют. Компоненты и их состояния откладываются по оси ординат, время – по оси абсцисс. Время градуировано в какой-либо шкале измерений. В приведенном примере каждое деление соответствует пяти секундам.
Диаграммная область каждой компоненты – это прямоугольник, отделенный от другого, соседнего (представляющего другую компоненту), прямой линией, параллельной оси абсцисс. Компоненты могут обмениваться сообщениями, с помощью которых происходит синхронизация их поведения. Сообщения изображаются вертикальными линиями со стрелками (вверх или вниз).
Диаграммы классов (class diagrams)
Этот тип диаграмм является основным при разработке объектноориентированной системы, так как позволяет наглядно изобразить структуру классов приложения. Такие диаграммы полезны как при предварительном проектировании, так и при рефакторинге, сопровождении и исправлении ошибок, а также при изучении ПО. С их помощью легко генерировать программный код, они легко восстанавливаются по уже существующему программному коду. Кроме того, диаграммы классов используются при описании самих языков визуального моделирования.
113

Фрагмент диаграммы классов телефонной службы приема заявок представлен на рис. 2.10. Здесь показаны основные классы сервера телефонной системы обработки заявок:
CPBX_Agent – отвечает за работу с PBX (с аппаратурой, занимающейся коммутацией абонентов);
Coperator – содержит описание экземпляров операторов, работающих в call-центре;
CsubOperator – описывает особенного, «главного» оператора (например, начальника над группой операторов);
COperatorList – управляет множеством операторов (добавляет их в список, удаляет и т. д.);
CNetworkConnectionSupport – обеспечивает поддержку соединений сервера через локальную компьютерную сеть с компьютерами операторов; Cdispatсher – отвечает за синхронизацию всех остальных
программных сущностей на сервере.
|
CBPX_Agent |
|
|
|
|
CDispatcher |
|
|
|
|
|
|
||
|
0..1 |
1 |
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|||
- |
Start |
:int |
- |
IncomingCall :int |
|
|
|
|
|
|
||||
|
|
|
|
|
|
- |
ReceiveMessage :int |
1 |
|
|
|
|
||
|
|
|
|
|
1 |
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0..1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
CServerNetworkConnectionSupport |
||||
|
COperator |
|
|
|
|
|
|
|||||||
|
0..1 |
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
- |
FreeConnection |
:int |
||||||
|
|
|
|
|
|
|
|
|||||||
- |
ID :int |
|
|
|
|
|||||||||
|
|
|
|
|
|
|
- |
SetConnection |
:int |
|||||
|
0..1 |
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
- |
SendMesssge :int |
||||
+ |
Get() |
:void |
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
COperatorList |
|
||
|
|
|
|
|
|
|
0..1 |
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
- |
Get |
:int |
|
|||
|
CSubOperator |
|
|
|
|
|
|
|
- |
Free |
:int |
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
+ |
Get() |
:void |
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 2.10. Диаграмма классов
Итак, на диаграммах классов изображаются сами классы с атрибутами, типами атрибутов, методами, а также иерархия наследования классов. И класс, и наследование в UML полностью соответствуют конструкциям объектно-ориентированных языков программирования. Но кроме них на диаграммах классов могут также присутствовать связи между классами – ассоциации. Так, на рис. 2.10 Класс Cdispatcher связан с классами CPBX_Agent, COperator, CServerNetworkConnectionSupport и CoperatorList (см. рис. 2.10).
114
В UML существует конструкция, обобщающая класс – классификатор (classifier). С его помощью задаются элементы в модели, которые могут иметь экземпляры, операции и атрибуты. Например, экземпляры класса – это объекты.
Еще одним примером классификатора является компонента (точнее, тип компоненты). В UML-модели возможны и экземпляры компонент. Кроме класса и компоненты в UML есть и другие классификаторы.
Диаграммы пакетов (package diagrams)
Пакет (package) – это конструкция UML, предназначенная для упорядочения UML-моделей, а также для группировки классов.
Пакет, во-первых, выполняет служебную роль, позволяя организовать порядок в создаваемых UML-моделях, а также распределять различные модельные конструкции и диаграммы по разным «папкам».
Во-вторых, в пакеты традиционно помещают классы системы, особенно если проект большой. При этом пакеты UML могут соответствовать, например, проектам (projects) Microsoft Visual Studio.
Однако пакеты UML могут быть многократно вложены друг в друга как в Enterprise Architect, а у проектов Microsoft Visual Studio такой возможности нет.
В Microsoft Visual Studio есть так называемые рабочие области (solutions), которые содержат в себе проекты. На компьютере каждого разработчика проекта могут быть созданы индивидуальные рабочие области, содержащие нужные проекты, а рабочая область всего приложения, используемая для целостной сборки приложения, может выглядеть по-другому. Таким образом, рабочие области, включающие в себя пакеты-проекты, пакетами не являются.
Пакеты связываются друг с другом специальным отношением – зависимостью (dependence). Это направленное отношение, и идет оно от зависимого пакета к независимому. Это означает, что используемый пакет содержит описание конструкций, которые зависимый пакет импортирует, а не реализует сам. Зависимость не ограничивается только диаграммами пакетов, но может быть использована и для связи других UML-конструкций, например, связывать два случая использования.
Примеры диаграмм пакетов изображены на рис. 2.11. Пакет Client содержит два пакета – ClientGUI, в котором находится описание пользовательского интерфейса, и ClientNetwork, отвечающий за сетевое взаимодействие с сервером. При этом первый пакет зависит от второго.
115

|
ClientGUI |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ClientNetwork |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 2.11. Диаграмма пакетов
Пакет Server содержит все проекты приложения, которые реализуют работу сервера, а ServerBusinessLogic – весь код, реализующий бизнеслогику сервера. ServerNetwork реализует сетевое сообщение с клиентом, RequestDB – примитивы доступа и логику работы с базой данных запросов. Пакет Util является служебным, в нем находятся все вспомогательные типы данных, классы, операции и т. д., которые используются всеми пакетами сервера.
Содержимое пакета ServerBusinessLogic показано редствами
диаграмм классов UML (рис. 2.12).
Рис. 2.12. Содержимое пакета ServerBusinessLogic в терминах диаграмм классов
В данном случае пакеты состоят из небольшого количества классов, поскольку в качестве примера представлена упрощенная модель ПО «Телефонной службы приема заявок». В действительности это приложение содержит около пятидесяти различных пакетов и около тысячи классов.
116