Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Объектно-ориентированных подход моделирования информационных систем).pdf
Добавлен: 23.04.2023
Просмотров: 213
Скачиваний: 2
СОДЕРЖАНИЕ
1 Проектирования информационных систем с помощью унифицированного языка моделирования UML
1.1 Объектно-ориентированных подход моделирования информационных систем
1.2 Унифицированный процесс разработки информационных систем
1.3 Структура унифицированного языка моделирования (UML). Основные понятия
2.1 Обзор объекта «Магазина радиоэлектронных товаров»
2.2 Проектирование информационной системы с использованием языка UML
Данные модели формализуют разрабатываемую информационную систему на различных уровнях абстракции. При этом возможно одновременное использование одного и того же элемента в моделях с различной степенью детализации. На рисунке 7 представлено графическое обозначение модели.
Рисунок 7 – Модель
Модели могут входить в состав других моделей. Такая иерархия моделей может быть представлена двумя различными способами (рисунок 8).
Рисунок 8 – Способы иллюстрации вложенности моделей
Множество артефактов, получаемых в унифицированном процессе и как сам технологический процесс можно представить в виде диаграммы.
На рисунке 9 представлен пример диаграммы артефактов «Управления проектом»[13].
Рисунок 9 – Диаграмма артефактов процесса «Управление проектом»
Своевременное и качественное выполнение поставленных задач по проектированию невозможно без применения специальных инструментов и утилит – средств автоматизации. К ним можно отнести инструментальные средства, предназначенные для обеспечения и поддержки жизненного цикла информационной системы. Линейка продуктов компании IBM Rational, является ярким примером объектно-ориентированного подхода к разработке информационных систем:
- IBM Rational Rose[14] – стандарт де-факто в сфере визуального моделирования и генерации объектного кода;
- IBM Rational Requisite Pro – средство управление требованиями к приложениям и системам на всех этапах разработки проекта;
- IBM Rational Clear Case – система управления версиями и конфигурациями;
- IBM Rational Rapid Developer – среда для быстрой разработки на основе моделей;
- IBM Rational Clear Quest – управление изменениями, помогает устранять дефекты, вносить изменения;
- IBM Rational Team Test – межплатформенное решение для тестирования и анализа работы системы.
- IBM Rational SoDA – автоматизированное решение для создания сопроводительной документации;
IBM Rational Rose комплексное решение визуального проектирования информационной системы с использованием широкого круга инструментальных средств и платформ. Его основные функции:
- модельное проектирование – построение модели предметной области в виде диаграмм UML и глоссария;
- генерация кода – автоматическая генерация кода на основе построенной модели;
- генерация скриптов DDL3, схем баз данных Oracle и xml-документов;
- реинжиниринг (обратное проектирование) – построение или восстановление модели на основе представленного кода программы, скрипта, базы данных или xml-документа;
- синхронизация модели с ее физической реализацией для организации итеративного проектирования системы.
IBM Rational Rose позиционируется как универсальный инструмент анализа, разработки и проектирования.
Унифицированный процесс разработки информационной системы позволяет поэтапно решать объемные задачи по проектированию информационных систем. А инструменты автоматизации - повышают качество и уменьшают сроки разработки.
1.3 Структура унифицированного языка моделирования (UML). Основные понятия
Унифицированный язык моделирования UML в настоящее время является основным инструментом документирования результатов объектно-ориентированного проектирования информационных систем.
Общая структура UML представлена на рисунке 10[15].
Семантика – раздел языкознания, который изучает значение языковых единиц.
Синтаксис – правила и способы построения из отдельных слов словосочетаний и предложений.
Можно сказать, что, в случае с UML синтаксис и семантика[16] представляют собой стиль построения моделей, который транслирует (преобразует, переводит) формальное описание естественным языком поведение информационной системы в представление элементов модели, которые более удобно описать программным кодом.
Рисунок 10 – Структура UML
Нотация – графическое представление описания системы с помощью синтаксиса и семантики для более удобного восприятия.
В унифицированном языке UML доступно три типа сущностей:
- структурная – абстракция, которая отражает физический или умозрительный объект;
- группирующая - используется группировки элементов диаграммы, объединённых общим смыслом или выполняемыми функциями ;
- поясняющая – поясняющие ремарки и комментарий к элементам диаграммы.
Для указания вида связей отношений между элементами UML-диаграммы используются следующие обозначения представленные в таблице
Таблица 2 – Отношения между элементами диаграммы UML[17]
|
Название |
Обозначение |
Семантика |
|
Ассоциация |
Прямая тесная связь между двумя и более сущностями. |
|
|
Агрегация |
Подкласс ассоциации, представляющий связь «часть - целое» (ромб), при которой они могут существовать отдельно друг от друга. Отношение агрегация может существовать только между сущностями одного и того же типа. |
|
|
Композиция |
Подкласс агрегации, при котором «части» и «целое» не могут существовать отдельно. |
|
|
Зависимость |
Отношение между двумя сущностями, при котором изменение состояния независимого элемента вызывает изменение состояния зависимого элемента. Независимый элемент указывается со стороны стрелки. |
|
|
Обобщение |
Отношение между родительской обобщенной сущностью (отмечается треугольником) и конкретизированной дочерней сущностью (потомком). Отношение обобщение возможно только между сущностями одного типа. |
|
|
Реализация |
Отношение между сущностями, когда одна из них определяет действие (указывается со стороны стрелки), которое другая должна выполнить. Отношения используются в следующих случаях: между вариантами использования и кооперациями, между интерфейсами и классами. |
Для отношений типа Ассоциация, Агрегация и Композиция можно указывать кратность, которая показывает общее количество экземпляров сущностей, состоящих в отношении. Кратность указывается с каждой стороны отношения возле соответствующей сущности. Способы указания кратности:
- любое число экземпляров (допускается нулевое значение);
- любое целочисленное положительное значение, кратность которого строго фиксирована;
- диапазон положительных целых чисел, допускается нижний предел равный нулю. Например, (0..10);
- диапазон положительных целых чисел с «открытым» конечным значением например (10..*);
- перечисление последовательности целочисленных положительных значений или/и указание диапазона через запятую, например: 0, 5..10.
Значение кратности по умолчанию равно единице. Т.е. если рядом с обозначением отношения нет указания кратности, то и кратность имеет значение равно 1, а не 0. Следует учесть, что для отношений Зависимость, Обобщение и Реализация кратность всегда имеет значение равное единице.
В таблице 3 представлено условное обозначение и описание механизмов расширения, которые применяются для уточнения семантики сущностей и отношений. На схемах они представлены в виде текстовой строки, заключенной в кавычки или скобки.
Таблица 3 – Условные обозначения механизмов расширения UML
|
Название |
Обозначение |
Семантика |
|
Стереотип |
« » |
Уточнение семантики элемента. |
|
Сторожевое условие |
[ ] |
Логическое условие. |
|
Ограничение |
{ } |
Ограничение семантики элемента модели. |
|
Помеченное значение |
{ } |
Задание нового или уточняющего свойства элемента. |
Кроме текстовых стереотипов (представляют собой строку текста в кавычках), на UML-диаграммах так же используются графические стереотипы. На рисунке 11 представлено графическое условное обозначение стандартного и стереотипного отображения класса.
Рисунок 11 – Примеры графического условного обозначения стандартного и стереотипного отображения класса.
Диаграмма – объединение в группу элементов нотации, предназначенное для графического отображения некоторого аспекта проектируемой системы. Принято представление в виде графа, вершины которого являются сущностями, а ребра – отношениями.
При разработке отдельной модели информационной системы в унифицированном процессе строят несколько видов диаграмм, и, чем большую сложность имеет проектируемая система, тем больше диаграмм одного вида требуется построить на этапе моделирования. При этом, некоторые виды диаграмм могут отсутствовать, если в них нет потребности.
В таблице 4 представлены связи моделей системы и диаграмм.
Таблица 4 - Связь моделей и диаграмм
|
Модель |
Диаграмма |
|||||||
|
Вариантов использования |
Состояний |
Классов |
Кооперации |
Последовательности |
Деятельности |
Компонентов |
Развертывания |
|
|
Вариантов использования |
+ |
+ |
+ |
+ |
+ |
|||
|
Анализа |
+ |
+ |
+ |
+ |
+ |
|||
|
Проектирования |
+ |
+ |
+ |
+ |
+ |
|||
|
Реализации |
+ |
+ |
+ |
|||||
В таблице 4 отсутствует модель тестирования, т.к. диаграммы в рамках ее построения не разрабатываются, а тестируются на непротиворечивость и полноту.
После предварительного построения для части диаграмм может потребоваться внесение правок и уточнений в соответствии с техническим процессом.
Унифицированный язык моделирования UML представляет разработчикам возможность графически отображать и описывать предметы и процессы реального мира. При этом сохраняет относительную простоту и читаемость схем. Благодаря этому унифицированный язык моделирования UML получил распространение не только при проектировании информационных систем, но и при проектировании в сферах банковских и финансовых услуг, телекоммуникаций, транспорта, оборонной промышленности, авиации и космонавтики, розничной торговли, а так же науки.
2. Моделирование информационной системы с использованием унифицированного языка моделирования UML на примере магазина радиоэлектронных товаров
2.1 Обзор объекта «Магазина радиоэлектронных товаров»
Рассмотрим применение унифицированного языка моделирования при проектировании системы на примере магазина электроники.
Основным бизнес–процессом магазина электроники является продажа электроники, оптимизация работы отдела продаж и получение прибыли.
Рассмотрим основные процессы, происходящие на этапе заказ-продажа.
1. Менеджер отдела продаж получает заявку от офлайн или онлайн клиента на покупку электроники. Заявка содержит дату покупки, наименование и количество единиц товара, а так же его стоимость. Далее поступившая заявка регистрируется в журнале заявок.
После формирования заявки менеджер отдела продаж выставляет счёт клиенту. Выставленный счет регистрируется в реестре счетов.
Бухгалтер получает и обрабатывает приходные кассовые ордера, а также выписки банка, в которых содержатся сведения о поступлении денежных средств в кассу или на расчётный счёт магазина. В реестре счетов бухгалтер делает отметки об оплате счета.
Если срок оплаты заявки превышает установленные сроки, то в журнале учета счетов менеджером делается отметка, о том, что выставленный счет просрочен. Заявка аннулируется. В журнале заявок делается соответствующая пометка.
Менеджер отправляет оплаченные счёта о покупке продавцу-консультанту. Менеджер делает пометку в журнале заявок.
Продавец-консультант на основе информации об оплате счета выписывает товарную накладную на товар, проверяет качество и комплектацию товара, выписывает гарантийный талон, при необходимости оформляет доставку товара клиенту.
В конце месяца менеджером отдела продаж на основании журнала заявок
В конце каждого месяца на основании журнала заявок менеджером отдела продаж составляется отчет по поступившим/выполненным заявкам на каждое наименование товара.
На рисунках 12-15 представлены основные модели данного бизнес-процесса магазина электроники.
Рисунок 12 – Диаграмма действий бизнес-процесса «Продажа электроники»