Лабораторная работа N1

Архитектура предприятия

Шологан Артемиос
TI-228
► Тема:Знакомство с CASE-инструментом
«Enterprise Architect» и общий анализ
принципов моделирования на основе языка
моделирования UML. Изучение и описание
функционального назначения подменю/опций в
меню.

► Цельработы: изучить элементы и сущности

средства моделирования Enterprise Architect.

► Задача: создать презентацию PowerPoint из 15-

20 слайдов с описанием основных элементов
Enterprise Architect.
 Стартовая страница
программы Enterprise Architect
Использование стартовой страницы
позволяет нам оперировать данными
софициального сайта, получая доступ к
его ресурсам по авторизации аккаунта,
а так жеманеврировать проектами

1) Открывать файл проекта (Open loacl proiect);

2) Создавать новый проект (Create a New Project);
3) Производить поиск по нашим существующим
проектам
Как создать новый проект в
Enterprise Architect?

Нажимаем на
надпись :
Где вводим имя проекта ?

После создания нового проекта

появляется возможность дать
название новому проекту
Из скольких окон состоит
интерфейс Enterprise
Architect?

Интерфейс Enterprise Architect

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

Модель классов лежит в основе объектно-ориентированной разработки и

проектирования — она выражает как постоянное состояние системы, так и ее
поведение. Класс инкапсулирует состояние (атрибуты) и предлагает услуги для
управления этим состоянием (поведением). Хороший объектно-ориентированный
дизайн ограничивает прямой доступ к атрибутам класса и предлагает службы, которые
манипулируют атрибутами от имени вызывающего объекта. Такое сокрытие данных и
раскрытие сервисов гарантирует, что обновления данных выполняются только в одном
месте и в соответствии с конкретными
правилами — для больших систем
нагрузка на обслуживание кода,
который имеет прямой доступ
к элементам данных во многих
местах, чрезвычайно высока.
► Обратите внимание, что класс состоит из трех
отдельных областей:

► Имя класса (и стереотип, если он применяется)

► Область атрибутов класса (то есть внутренних
элементов данных)
► Поведение - как частное, так и публичное
► Атрибуты и методы могут быть помечены как

► Частный, указывающий, что они не видны вызывающим

абонентам за пределами класса.
► Защищены, они видны только детям этого класса.
► Публичные, они видны всем
 Наследование

Наследование классов показано

ниже: абстрактный класс в
данном случае является
родительским для двух дочерних
классов, каждый из которых
наследует функции базового
класса и расширяет его своим
собственным поведением.
Кооперация (сollaboration) определяет
взаимодействие и представляет собой
совокупность ролей и других элементов,
которые функционируют вместе, обеспечивая
некоторое совместное поведение,
представляющее нечто большее, чем сумма
поведений отдельных
элементов. Кооперации имеют как структурное,
так и поведенческое
измерения. Конкретный класс или объект может
участвовать в нескольких кооперациях.
Последние, таким образом, представляют
собой реализацию образцов (patterns) ,
составляющих систему. Кооперация
изображается в виде эллипса, нарисованного
пунктирной
линией, иногда включающего в себя лишь ее
имя,
► Вариант использования (use case) – это описание
последовательности действий, выполняемых системой
и приносящих значимый результат конкретному
действующему лицу (actor) . Варианты использования
применяются для структурирования поведенческих
сущностей
► модели. Реализуются посредством коопераций.
Графически вариант
► использования представлен эллипсом, нарисованным
сплошной линией
 Модель вариантов использования
► Модель варианта использования описывает
предлагаемую функциональность новой
системы. Вариант использования
представляет собой дискретную единицу
взаимодействия между пользователем
(человеком или машиной) и системой. Это
взаимодействие представляет собой
единую единицу значимой работы, такой
как создание учетной записи или просмотр
сведений об учетной записи.

► Каждый вариант использования описывает

функциональность, которая будет встроена
в предлагаемую систему, которая может
включать в себя функциональность другого
варианта использования или расширять
другой вариант использования своим
собственным поведением.
Описание варианта использования
обычно включает в себя:
► Общие комментарии и примечания, описывающие вариант использования.
► Требования — формальные функциональные требования к вещам, которые вариант использования должен
предоставить конечному пользователю, например <возможность обновления порядка>. Они соответствуют
функциональным спецификациям, присутствующим в структурированных методологиях, и образуют контракт,
согласно которому вариант использования выполняет какое-то действие или обеспечивает некоторую
ценность для системы.
► Ограничения — формальные правила и ограничения, в соответствии с которыми действует вариант
использования, определяющие, что можно, а что нельзя сделать. К ним относятся:
► Предварительные условия, которые должны уже возникнуть или существовать до запуска варианта
использования; например, <создать заказ> должен предшествовать <изменить заказ>
► Постусловия, которые должны быть истинными после завершения варианта использования; например,
<порядок изменен и согласован>
► Инварианты, которые всегда должны быть истинными на протяжении всего времени действия варианта
использования; например, заказ всегда должен иметь номер клиента.
► Сценарии — формальные последовательные описания шагов, предпринятых для реализации варианта
использования, или потока событий, которые происходят во время экземпляра варианта использования. Они
могут включать в себя несколько сценариев, учитывающих исключительные обстоятельства и альтернативные
пути обработки. Обычно они создаются в текстовом виде и соответствуют текстовому представлению
диаграммы последовательности.
► Диаграммы сценариев — диаграммы последовательности для изображения рабочего процесса; аналогично
сценариям, но изображены графически.
► Дополнительные атрибуты, такие как этап реализации, номер версии, рейтинг сложности, стереотип и статус.
 Актеры

► Варианты использования обычно связаны

с «субъектами», то есть людьми или
машинами, которые используют систему
или взаимодействуют с ней для
выполнения части значимой работы,
которая помогает им достичь цели. Набор
вариантов использования, к которым
имеет доступ субъект, определяет его
общую роль в системе и объем его
действий.
 Диаграммы последовательности
► Диаграммы последовательности обеспечивают графическое представление
взаимодействий объектов с течением времени. Обычно они показывают
пользователя или субъекта, а также объекты и компоненты, с которыми они
взаимодействуют при выполнении варианта использования. Одна диаграмма
последовательности обычно представляет собой один «сценарий» варианта
использования или поток событий.

► Диаграммы последовательности — отличный способ документировать сценарии

использования, а также фиксировать необходимые объекты на ранних этапах
анализа и проверять использование объектов на более поздних стадиях
проектирования. Диаграммы показывают поток сообщений от одного объекта к
другому и, как таковые, соответствуют методам и событиям, поддерживаемым
классом/объектом.

► В следующем примере диаграммы последовательности показан пользователь или

действующее лицо слева, инициирующее поток событий и сообщений,
соответствующий сценарию варианта использования. Сообщения, которые
передаются между объектами, в окончательной модели становятся операциями
класса.
 Схема реализации
► Вариант использования — это
формальное описание функциональности,
которую система будет иметь после ее
создания. Диаграмма реализации обычно
связана с вариантом использования,
чтобы документировать, какие элементы
дизайна (например, компоненты и
классы) реализуют функциональность
варианта использования в новой системе.
Это обеспечивает высокий уровень
отслеживания для разработчика системы,
► В приведенном выше примере показано, что
заказчика и команды, которая фактически вариант использования «Вход» реализует
будет создавать систему. Список формальное требование «1.01 Вход на веб-сайт».
вариантов использования, с которыми Он также показывает, что компонент «Бизнес-
логика» и компонент «Страницы ASP» реализуют
связан компонент или класс, некоторые или все функции «Вход в систему».
документирует минимальную Дальнейшее усовершенствование заключается в
функциональность, которая должна быть том, чтобы показать экран «Вход» (веб-страницу)
как реализацию варианта использования «Вход».
реализована компонентом. Эти связи реализации или реализации определяют
прослеживаемость от формальных требований
через варианты использования до компонентов и
экранов.
 Вывод:
► Enterprise Archetict имеет обширные
возможности в своём приложении .На
протяжении курса мы постепенно будет
изучать с помощью этого приложения
возможности использования UML
таблиц .Благодоря этой лабораторной работе
я ознакомился с основными эллементами
Enterprise Architect.