
- •СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ……………………………….
- •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.

Необходимо отметить, что при проектировании приложений с большим количеством классов и пакетов целесообразно создавать диаграммы пакетов. Полезна предварительная оценка структуры проектов приложения. Однако ошибки при проектировании структуры пакетов большого приложения приводят к значительным неудобствам, дополнительным операциям и к потере концептуальной целостности приложения.
Диаграммы объектов (object diagrams)
Этот тип диаграмм предназначен для описания какого-либо фрагмента системы с помощью объектов (objects) – экземпляров классов. Объект является конкретным runtime-экземпляром некоторого класса, имеющим средство уникальной идентификации, позволяющее отличить его от других объектов того же класса, а также конкретные значения атрибутов и связей. Понятно, что все возможные экземпляры всех классов на диаграммах не изобразить, так как их слишком много. Поэтому на диаграммы объектов попадают только те экземпляры, которые реально существуют в каком-либо фрагменте системы в конкретный момент ее работы. Пример такой диаграммы представлен на рис. 2.13.
Здесь изображена следующая конфигурация сервера службы телефонных заявок: один диспетчер (объект: Cdispatcher»), один объект, работающий с PBX («CPBX_Agent») и два оператора – объекты
«Tester1:Coperator» и «Tester2:CsubOperator». Для двух первых объектов не указаны имена, поскольку в системе одновременно может быть только по одному такому объекту. Два других объекта соответствуют тестовым операторам, один из которых является «главным» (Tester2, принадлежащий классу CSubOperator).
CBPX_Agent |
|
CDispatcher |
|
|
|
|
|
|
Tester2: Tester1:COperator
CSubOperator
Рис. 2.13. Диаграмма объектов
Информация об экземплярах классов необходима не для спецификации системы (для этого используются, например, диаграммы классов), а для обсуждения некоторого ее фрагмента. Объект является частным случаем общей концепции экземпляров в UML. Не только классы,
117

но и другие сущности (например, узлы диаграмм развертывания) могут иметь экземпляры.
Общее правило для отображения имен экземпляров таково: <Идентификатор1>: <Идентификатор2>, где <Идентификатор1> –
это имя экземпляра, а <Идентификатор2> – имя его классификатора. Строка с именем должна быть подчеркнута.
У объекта может быть также секция атрибутов, где принято указывать значения для атрибутов его класса.
Объекты соединяются друг с другом связями (links). Так же как объекты – это экземпляры классов, так и связи – это экземпляры соответствующих ассоциаций. Однако в конкретной модели связи могут не иметь ассоциаций, например, в случае если модель объектов требуется для какого-либо документа или обсуждения и т. д. или когда строить большую модель с классами необязательно.
Кооперации (collaborations)
Так в UML называется описание определенной задачи (например, какой-либо пользовательской функции системы или внутренней задачи самого ПО, или же какого-либо алгоритма предметной области) в терминах взаимодействующих элементов. Описывается не поведение, а взаимодействующие стороны и их связи. Кооперации показываются на специальном типе диаграмм – на диаграммах композитных структур
(composite structure diagrams).
Общающиеся стороны задаются ролями, которые описывают некоторую часть функциональности класса, используемого данным контекстом (в данном случае таким контекстом является кооперация). Например, для двух классов – Абонент и Станция – кооперация «Соединение» (рис. 2.14) определяет контекст – процедуру установки соединения между абонентом и станцией, а роли этих классов «берут» из самих классов ту функциональность, которая реализует эту процедуру. Ведь кроме этой функциональности в этих классах может быть и другая.
Соединение
Аб:Абонемент |
Ст:Станция |
Рис. 2.14. Способ задания кооперации
118

Диаграммы конечных автоматов (statechart diagrams)
Пример диаграммы конечных автоматов приведен на рис. 2.15. Она описывает алгоритм поведения объектов класса Coperator системы «Телефонной службы приема заявок», изображенного на рис. 2.10.
Initial
Terminate ExitPoint
Idle
Connection
errors Disconnect TimeoutT12
WaitingForConnection |
Connected |
Connected |
Рис. 2.15. Пример диаграммы конечных автоматов
После инициализации объекта он переходит в состояние Idle и пребывает в нем до тех пор, пока свободен и не участвует в приеме заявки от клиента. Когда приходит запрос от клиента, объект переходит в состояние WaitingForConnection – ожидание установки соединения по локальной сети с соответствующим оператором. После получения сигнала Connected объект переходит в состояние Connected, в котором пребывает на протяжении всей работы оператора с клиентом.
Из состояния WaitingForConnection объект может перейти в состояние Idle, если ожидание соединения с оператором превысит время T12.
При получении сигнала Disconnect, свидетельствующего об окончании обслуживания клиента, объект переходит в состояние Idle, в котором ожидает новый запрос. В этом же состоянии объект может обработать сигнал Terminate – указание завершить всю свою работу и освободить оперативную память.
2.2.Автоматизированная информационная система «Мониторинг деятельности застройщиков и жилищных накопительных кооперативов»
Автоматизированная информационная система (АИС) предназначена для комплексной автоматизации задач мониторинга деятельности застройщиков, привлекающих денежные средства участников долевого строительства. АИС устанавливается в организациях-застройщиках
119