Диаграмма последовательности строительной компании

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

• схема БД – логическая (рисунок 2.7);

• схема БД– физическая (рисунок 2.8);

• логическая диаграмма классов приложения (рисунок 2.9);

• физическая диаграмма классов приложения – физическая (рисунок 2.10).

Рисунок 2.7 – Схема БД – «Логическая»

Рисунок 2.8 – Схема БД – «Физическая»

Рисунок 2.9 – Диаграмма классов приложения – логическая

Рисунок 2.10 – Диаграмма классов приложения – физическая

2.3 Разработка поведенческой модели

После разработанных функциональной и информационной моделей создаются алгоритмы обработки данных и поведения элементов системы. Как достигается требуемая функциональность и какие данные используются для ее обеспечения, показывает поведенческая модель системы. В рамках проектирования поведенческой модели разрабатываются диаграммы последовательности и деятельности.

2.3.1 Разработка диаграмм последовательности

Взаимодействие определенных экземпляров актеров и классов для реализации отдельного варианта использования описывается диаграммами последовательности.

При разработке информационной системы Интернет-магазина строительной компании спроектировано две диаграммы последовательности «Регистрация пользователя» и «Аутентификация пользователя» для одноименных вариантов использования.

На рисунке 2.11 представлена диаграмма последовательности, отображающая процесс регистрации пользователя на сайте. Регистрация пользователя в системе осуществляется администратором сайта посредством формы регистрации.

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

Рисунок 2.11 –Диаграмма последовательности «Регистрация нового пользователя»

Другая диаграмма последовательности «Аутентификация пользователя» изображена на рисунке 2.12. Она отображает процесс входа пользователя в систему. После того, как пользователь вводит логин и пароль проходит проверка, существует ли пользователь. Если пользователь не существует либо данные не верны, выходит сообщение об ошибке.

Рисунок 2.12 – Диаграмма последовательности «Аутентификация пользователя»

Диаграммы коммуникации

В отличие от диаграммы последовательности, на диаграмме коммуникации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. На этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров.

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

Таким образом, цель самой коммуникации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе. Коммуникация определяет структуру поведения системы.

Диаграммы коммуникации могут быть построены на основе диаграмм последовательностей (рисунок 2.13).

Рисунок 2.13 – Диаграмма коммуникации «Аутентификации»

2.3.2 Разработка диаграмм деятельности

При моделировании поведения системы возникает необходимость детализировать особенности алгоритмической или логической реализации, выполняемых системой операций. Для этого предусмотрены диаграммы деятельности.

В рамках данной работы реализовано две диаграммы деятельности «Покупка материалов пользователем» и «Создание учетной записи».

На диаграмме деятельности, представленной на рисунок 2.14, рассмотрены операции, осуществляемые пользователем при добавлении материалов в корзину. При прохождении пользователем авторизации, пользователь заходит в каталог. Все выбранные материалы попадают в корзину учетной записи пользователя, после пользователь ждет, пока менеджер с ним свяжется. Менеджер проверяет наличие материалов на складе. В случае если материалов нет в наличии, то менеджер сообщает о том, что можно купить материалы на заказ. Если клиента устраивает предложение, он производит оплату.

Рисунок 2.14 – Диаграмма деятельности «Покупка материалов»

На рисунке 2.15 изображена диаграмма деятельности «Создание учетной записи». Данная диаграмма показывает процессы, которые используются при «Создании учетной записи». При регистрации пользователь придумывает свой уникальный логин и пароль, после чего система проверяет данные с имеющимися уже в базе данных. Если имеются совпадении логина, то пользователю указывают на ошибку об использовании введенных данных. После того, как логин и пароль пройдут проверку уникальности, система добавляет их в базу данных и пользователю сообщают об успешной регистрации.

Рисунок 2.15 – Диаграмма деятельности «Создание учетной записи »

2.4 Разработка компонентной модели

На заключительной стадии проектирования информационной системы Интернет-магазина строительных материалов устанавливается распределение функций по компонентам и строится их распределение по узлам системы.Для этого предназначены диаграммы компонентов и реализации.

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

Диаграмма компонентов разрабатывается для следующих целей:

• визуализации общей структуры исходного кода программной системы;

• спецификации исполняемого варианта программной системы;

• обеспечения многократного использования отдельных фрагментов программного кода;

• представления концептуальной и физической схем баз данных.

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода.

В языке UML выделяют три вида компонентов:

• развертывания, которые обеспечивают непосредственное выполнение системой своих функций (такими компонентами могут быть динамически подключаемые библиотеки с расширением dll);

• рабочие продукты – это файлы с исходными текстами программ;

• исполнения, представляющие собой исполняемые модули (файлы с расширением ехе).

Другим способом спецификации различных видов компонентов является явное указание его стереотипа перед именем. В языке UML для компонентов определены следующие стереотипы:

• «file» – любой файл, кроме таблицы:

• «executable» – программа (исполняемый файл);

• «library» – статическая или динамическая библиотека;

• «source» – файл с исходным текстом программы;

• «document» – остальные файлы (например, файл справки);

• «table» – таблица базы данных.

На рисунках 2.17 показана диаграмма компонентов для информационной системы «Строительной компании».

Рисунок 2.17 – Диаграмма компонентов

Клиентское приложение построено на взаимодействии форм, соответствующих им классов, представленных стереотипами «form» и «source» соответственно, и подключаемых библиотек. Серверная часть представлена в общем виде как взаимодействие СУБД, в качестве которой используется MS SQL Server 2016 , и непосредственно БД «DBLibrary».Последняя в свою очередь строится на совокупности связанных таблиц.

Диаграмма развертывания

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

Главными элементами диаграммы являются узлы, связанные информационными путями. Узел– это то, что может содержать программное обеспечение. Узлы бывают двух типов:

• устройство – это физическое оборудование: компьютер или устройство, связанное с системой;

• среда выполнения – это программное обеспечение, которое само может включать другое программное обеспечение, например, операционную систему.

Другими словами, диаграмма развертывания отражает топологию связей аппаратных средств и размещения на них компонентов. Структурные аспекты передаются диаграммами развертывания, а поведенческие аспекты ‒ диаграммами взаимодействия, состояний и деятельности.

Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.

На рисунке 2.18 представлена диаграмма развертывания для проектируемой информационной системы.Взаимодействие между клиентской и серверной частью, как показано на рисунке, осуществляется через интерфейс ADO.NET (ActiveXDataObject для .NET) – технологии, предоставляющей доступ к данным для приложений, основанных на Microsoft .NET.

Рисунок 2.14– Диаграмма развертывания

3 Практическая часть

3.1 Выбор программных средств

Приступая к разработке проекта, необходимо выбрать программные средства. Этот этап является очень важным при создании web-приложения. От правильного выбора программного средства во многом зависит не только успех работы приложения, но и самой компании.

Разработка web-приложения для интернет—магазина строительных материалов осуществляется на базе технологии ASP.NETMVCcиспользованием СУБД MSSQLServer 2016. Создание приложение производится в среде разработки Visual Studio 2017.

3.1.1 ASP.NETMVC

ASP.NET (ActiveServerPages) – инфраструктура разработки web-приложений.ASP.NET автоматизирует большую часть процесса разработки сложных web-приложений, включая взаимодействие с web-сервером, начальную обработку запросов и генерацию результирующего HTML.

ASP.NET MVC представляет собой платформу для создания сайтов и web-приложений с использованием паттерна (или шаблона) MVC (Model — View — Controller).

К 2015 г. уже было выпущено пять версий платформы, а сам Framework обрел большую популярность по всему миру благодаря своей гибкости и адаптивности.

Концепция MVC представлена на рисунке 3.1.

Рисунок 3.1 – Концепция технологии ASP.NETMVC

Для чего используется метод проектирования

Изобразить участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

План действий

В разделе «Описание» изучите основной набор символов диаграммы последовательности, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм последовательности.

Замечания (описание)

Здесь представлен основной набор символов диаграммы последовательности, необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы последовательности самостоятельно!

Термин	Изображение	Описание
Найденное сообщение		У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным сообщением (found message).
Сообщение		Команда, отправляемая другому участнику. Может содержать только передаваемые данные.
Линия жизни		Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответству ет времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны, но я считаю их исключительно удобными при пояснении поведения.
Участник		В большинстве случаев можно считать участников диаграммы взаимодействия объектами, как это и было в действительности в UML 1. Но в UML 2 их роль значительно сложнее. Поэтому здесь употребляется термин участники (participants), который формально не входит в спецификацию UML.
Самовызов		Участник отправляет сообщение (команду) самому себе.
Возврат		Передача управления обратно участнику, который до этого инициировал сообщение.
Активация		На изображении это — белый вертикальный прямоугольник. Момент, когда участник начинает действовать в ответ на принятое сообщение.
Создание		В случае создания участника надо нарисовать стрелку сообщения, на правленную к прямоугольнику участника. Если применяется конст руктор, то имя сообщения не обязательно, но можно маркировать его словом «new» в любом случае. Если участник выполняет что- нибудь непосредственно после создания, например команду запроса, то надо начать активацию сразу после прямоугольника участника.
Самоудаление		Удаление участника обозначается большим крестом (X). X в конце линии жизни показывает, что участник удаля ет сам себя.
Удаление из другого объекта		Удаление участника обозначается большим крестом (X). Стрелка сооб щения, идущая в X, означает, что один участник явным образом уда ляет другого.
Фреймы взаимодействия		Общая проблема диаграмм последовательности заключается в том, как отображать циклы и условные конструкции. Прежде всего надо усвоить, что диаграмма последовательности для этого не предназначе на. Подобные управляющие структуры лучше показывать с помощью диаграммы деятельности или собственно кода. Диаграмма последова тельности применяется для визуализации процесса взаимодействия объектов, а не как средство моделирования алгоритма управления. Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия.

Как применять технику креативности

Диаграммы последовательности следует применять тогда, когда требуется посмотреть на поведение нескольких объектов в рамках одного прецедента. Диаграммы последовательности хороши для представления взаимодействия объектов, но не очень подходят для точного определения поведения.

Если вы хотите посмотреть на поведение одного объекта в нескольких прецедентах, то примените диаграмму состояния. Если же надо изучить поведение нескольких объектов в нескольких прецедентах или потоках, не забудьте о диаграмме деятельности.

Если требуется быстро исследовать несколько вариантов взаимодействия, лучше использовать CRC-карточки, поскольку это позволяет избежать непрерывного рисования и стирания. Часто бывает удобно поработать с CRC-карточками для просмотра вариантов взаимодействия, а затем с помощью диаграмм взаимодействий фиксировать те взаимодействия, которые будут применяться позже.

Другим полезным видом диаграмм взаимодействий являются коммуникационные диаграммы, которые показывают соединения, и временные диаграммы, показывающие временные интервалы.

CRC-карточки

Одним из наиболее полезных приемов, соответствующих хорошему стилю ООП, является исследование взаимодействия объектов, поскольку его цель состоит в том, чтобы исследовать работу программы, а не данные. CRC-диаграммы (Class-Responsibility-Collaboration, класс-обязанность-кооперация), придуманные Уордом Каннингемом (Ward Cunningham) в конце 80-х годов, выдержали проверку временем и стали высокоэффективным инструментом решения этой задачи (рис. 4.6). И хотя они не входят в состав UML, все же являются очень популярными среди высококвалифицированных разработчиков в области объектных технологий.

Для использования CRC-карточек вы и ваши коллеги должны собраться за столом. Возьмите различные сценарии и проиграйте их с помощью карточек, поднимая их над столом, в то время когда они активны, и передавая их по кругу в предположении, что они посылают сообщение. Эту технологию почти невозможно описать в книге, но легко продемонстрировать; лучший способ научиться этому состоит в том, чтобы попросить кого-нибудь, кто имеет такой опыт, показать вам это

Важным моментом в CRC-методике является определение ответственностей. Ответственность (responsibility) – это краткое описание того, что объект должен делать: операция, которую выполняет объект, некоторый объем знаний, который объект поддерживает, или какие-либо важные решения, принимаемые объектом. Идея состоит в том, чтобы вы могли взять любой класс и сформулировать его разумно ограниченные обязанности. Такой образ действия поможет вам яснее представить себе архитектуру классов.

Вторая буква «С» (в CRC) означает взаимодействие (collaboration): другие классы, с которыми должен работать рассматриваемый класс. Это дает вам некоторое представление о связях между классами, но все еще на высоком уровне.

Одно из главных преимуществ CRC-карточек состоит в том, что они способствуют живому обсуждению проектов в среде разработчиков. Если в процессе работы над шаблоном поведения вы хотите посмотреть, как классы его реализуют, то вычерчивание диаграмм взаимодействия, описанных в этой главе, может занять слишком много времени. Обычно требуется просмотреть варианты, а рисование и стирание вариантов на диаграммах может быть очень утомительным. С помощью CRC-карточек разработчики моделируют взаимодействие, поднимая карточки и передавая их по кругу. Это позволяет быстро просчитать варианты.

В процессе работы вы создаете представление об ответственностях и записываете их на карточки. Размышления об ответственностях важны, поскольку рассеивают представление о классах как о бессловесных хранителях данных и помогают членам команды лучше понять поведение каждого класса на высшем уровне. Ответственность может соответствовать операции, атрибуту или, что более точно, неограниченной группе атрибутов и операций.

Опыт показывает, что распространенной ошибкой разработчиков является создание ими длинных списков низкоуровневых ответственностей. Это приводит к непониманию сути. Ответственности должны свободно помещаться на одной карточке. Спросите себя, следует ли разделить класс или лучше отрегулировать ответственности, переместив их на более высокий уровень операторов.

Многие разработчики подчеркивают важность ролевой игры, когда каждый член команды играет роль одного или нескольких классов.

Как научиться

Здесь мы попытались предоставить как можно более простой способ изучения диаграммы последовательности языка UML.

Как и многие другие языки он использует для описания набор знаков. Смысл этих знаков вы найдете в таблице в разделе «Замечания (описание)». Каждый знак имеет свое наименование (термин) и написание. Также каждый термин снабжен кратким пояснением, чтобы быстро уяснить его основную суть.

Далее мы бы рекомендовали перейти в раздел «Пример», чтобы попробовать свои силы в чтении разных диаграмм. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять нужные диаграммы по назначению.

Пример использования

Для того чтобы начать обсуждение метода «Диаграмма последовательности» UML (ЮМЛ), рассмотрим простой сценарий.

Предположим, что у нас есть заказ, и мы собираемся вызвать команду для определения его стоимости. При этом объекту заказа (Order) необ ходимо просмотреть все позиции заказа (Line Items) и определить их цены, основанные на правилах построения цены продукции в строке заказа (Order Line). Проделав это для всех позиций заказа, объект за каза должен вычислить общую скидку, которая определяется индиви дуально для каждого клиента.
На рис. 4.1 приведена диаграмма, представляющая реализацию дан ного сценария. Диаграммы последовательности показывают взаимо действие, представляя каждого участника вместе с его линией жизни (lifeline), которая идет вертикально вниз и упорядочивает сообщения на странице; сообщения также следует читать сверху вниз.

Одно из преимуществ диаграммы последовательности заключается в том, что почти не придется объяснять ее нотацию. Можно видеть, что экземпляр заказа посылает строке заказа сообщения getQuantity и getProduct. Можно также видеть, как заказ применяет метод к самому себе и как этот метод посылает сообщение getDiscountInfo экземпляру клиента.

Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждой строки заказа, тогда как метод calculateDiscounts вызывается лишь однажды.

На приведенной диаграмме именовали участников, используя стиль anOrder. В большинстве случаев это вполне приемлемо. Вот более полный синтаксис: имя : Класс, где и имя, и класс не обязательны, но если класс используется, то двоеточие должно присутствовать.

Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответствует времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны.

У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным со общением (found message).

Создание и удаление участников

В диаграммах последовательности для создания и удаления участников применяются некоторые дополнительные обозначения (рис. 4.3).

В случае создания участника надо нарисовать стрелку сообщения, направленную к прямоугольнику участника. Если применяется конструктор, то имя сообщения не обязательно, но обычно маркируем его словом «new» в любом случае. Если участник выполняет что -нибудь непосредственно после создания, например команду запроса, то надо
начать активацию сразу после прямоугольника участника.

Удаление участника обозначается большим крестом (X). Стрелка сообщения, идущая в X, означает, что один участник явным образом удаляет другого; X в конце линии жизни показывает, что участник удаляет сам себя.

Диаграмма последовательности: циклы, условия и тому подобное

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

Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия. На рис. 4.4 показан простой алгоритм, основанный на следующем псевдокоде.
foreach (lineitem)
if (product.value > $10K)
careful.dispatch
else
regular.dispatch
end if
end for
if (needsConfirmation) messenger.confirm
end procedure

В основном фреймы состоят из некоторой области диаграммы последовательности, разделенной на несколько фрагментов. Каждый фрейм имеет оператор, а каждый фрагмент может иметь защиту. (В табл. 4.1 перечислены общепринятые операторы для фреймов взаимодействия.)

Для отображения цикла применяется оператор loop с единственным фрагментом, а тело итерации помещается в защиту. Для условной логики можно использовать оператор alt и помещать условие в каждый фрагмент. Будет выполнен только тот фрагмент, защита которого имеет истинное значение. Для единственной области существует оператор opt.

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».

Перейти на страницу курса

Разработка ИС для строительной компании.(Прочитано 11372 раз)

---

---

---

---

---

---

---

---

---

---

---

---

---