Смирнов Н.В. Проектирование информационных систем

Подождите немного. Документ загружается.

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

курсового проекта, включаются диаграммы двух типов: диаграммы классов (структурный

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

Разработку диаграмм классов желательно осуществлять с использованием результатов

проектирования модели предметной области. Диаграммы последовательности должны

моделировать последовательность функций системы (т.н. ответственностей) ПО ИС,

которые замещают ручные действия бизнес - акторов и переводят их в категорию

пользователей ИС.

В качестве исходных высказываний для разработки UML – диаграмм

концептуальной модели служат высказывания на естественном языке (предложения) о

функциональных возможностях и структуре ПО ИС. Поэтому перед разработкой UML –

диаграмм необходимо иметь высказывания о функциях и сформулировать высказывания о

структуре ПО ИС.

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

разработке концепции ИС (раздел 5.2.2). Используя эти высказывания можно разработать

UML – диаграмму вариантов использования ИС, которая отражает функциональную

структуру ИС. При разработке концептуальной модели курсового проекта этого можно не

делать, а сосредоточиться на разработке диаграмм последовательности, на которых ИС

моделируется отдельным классом с операциями, которые соответствуют функциям ИС.

На Рис. 6 представлена диаграмма последовательности, моделирующая информационную

поддержку основной функции процесса продаж - расчета за покупку. На Рис. 7

представлена диаграмма последовательности, моделирующая обеспечивающие функции

ИС (аутентификацию и авторизацию). На

Рис. 8 представлена диаграмма

последовательности, моделирующая вспомогательные функции ИС (поиск товара в

каталоге товаров).

Высказывания о структуре ПО ИС формулируются исходя из представлений о

программной архитектуре. Понимание программной архитектуры зависит от контекста

решаемой задачи и может пониматься как архитектура взаимодействия отдельных

приложений в рамках ИС предприятия (архитектура приложений), так и архитектура

программных модулей одного приложения ИС. При решении задач курсового проекта

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

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 21-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

взаимодействия классов, организованных в три слоя (представление, предметная область,

источник данных) в рамках одного приложения. Такое понимание программной

архитектуры на концептуальном уровне сопоставимо с трехсхемной архитектурой,

описанной в ГОСТ 34.320-96.

На практике, как правило, основные высказывания о программной архитектуре

заимствуются из описаний шаблонов архитектуры. Для разработки архитектуры ИС,

рассматриваемой в данном методическом руководстве, выбран шаблон трехслойной

архитектуры, основные высказывания которого приведены в Таблица 3.

Таблица 3 Шаблон трехслойной архитектуры

№ Наименования слоя Необходимые высказывания

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

Предоставляет услуги отображения данных,

обработки событий пользовательского интерфейса

(щелчки мыши, нажатия клавиш).

В общем случае, охватывает все, что имеет

отношение к общению пользователя с ИС.

Предметная область

Выполняет вычисления на основе вводимых и

хранимых данных, проверку всех элементов данных

и обработка команд, поступающих от слоя

представления, а также передачу информации слою

источника данных.

В общем случае, обработка команд и данных,

используемых для поддержки пользователей

(кассира, продавца)

Источник данных

Выполняет обращения к БД, обмен сообщениями,

мониторинг транзакций.

В общем случае, поставка данных из БД для объектов

предметной области, сохранение изменений (ввод) в

БД

Руководствуясь высказываниями шаблона трехслойной архитектуры и принимая во

внимание результаты анализа функциональных требований, разработаем модель

первичной структуры ПО ИС. Результаты разработки представлены в виде диаграммы

классов на Рис. 5, описание назначения классов по слоям в Таблица 4.

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 22-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

Таблица 4 Назначение классов концептуальной модели

№ Наименования класса Назначение класса

с л о й п р е д с т а в л е н и я

ShtrihCod-UI-Cassir

граничный класс, отвечающий за обработку

результатов сканирования штрих-кода

E-UI-Cassir

граничный класс, отвечающий за отображение

формы требования, атрибутов покупки, параметров и

результатов поиска требований оплаты

E-UI-Prodavez

граничный класс, отвечающий за отображение

формы каталога товаров, параметров для поиска и

результатов поиска товаров в каталоге;

класс-родитель для класса E-UI-Samoobslujivania

ControllerMarket

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

управление приложением в целом;

класс-родитель для классов ControllerProdaj и

ControllerSpravok

Pravila

класс хранения, содержащий данные бизнес-правил

приложения

с л о й п р е д м е т н ой о б л а с т и

UdalVizov

граничный класс, отвечающий за взаимодействие с

классами слоя предметной области, размещаемых,

например, на сервере приложений

E-TrebovanieOplati

класс хранения, содержащий ключевые данные

требований на оплату

E-TrebovanieOplatiLineTov

класс хранения, содержащий данные атрибутов

товара в требовании на оплату

10.

E-Tovar

класс хранения, содержащий ключевые данные о

товарах в каталоге

11.

E-TovarSpecification

класс хранения, содержащий характеристики товаров

в каталоге

12.

E-ClassificatziayTovar

класс хранения, содержащий классы товаров в

каталоге

13.

E-Sotrudnik

класс хранения, содержащий данные сотрудников,

которые являются пользователями ИС

14.

E-ListControlayDostupa

класс хранения, содержащий права доступа

пользователей ИС

15.

с л о й и с т о ч н и к а д а н н ы х

16.

DataShluz

граничный класс, отвечающий за поставку данных из

БД для объектов предметной области, сохранение

изменений (ввод) в БД

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 23-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

ListControlayDoctupa (ACL)

DataShluz

E-TovarSpecification

Рис. 5 Диаграмма классов, моделирующая структуру ПО ИС на концептуальном уровне

E-Tovar

harak terisuet

E-TrebovanieOplatiLineTov

ssilaetsa

UserProdavez

Е- sotrudnik

ogranichivaet dostup

E-ClassifikaziayTovar

E-TrebovanieOplati

StateDoc1 = e-trbovanie

StateDoc2 = e-chek

e-podpisivaet

vkluchaetLineTov

Покупатель

спрашивает

Pravila

E-UI-Prodavez

Prosmatrivaet

prosmotr cataloga tovara

vvod atributov -viz

control Login and Parol

poisk -viz

pechat chek a-viz

sozdanie-viz

UdalVizov

E-UI-Cassir

Деньги

платит за покупку

Бумажный чек

получает чек

Сообщение

воспринимает сообщение

vizov1

vizov2

vizov3

ControllerMarket

Vipolnenie

vvoda atributov

sozdanie

poisk

pechat chek a

poisk -tovara

UserCassir

Comanda Pechati chek a

Formiruet E-trebovanie na oplatu

получает за покупку

передает чек

называет сумму

Покупаемый товар

StrihCod-UI-Cassir

vvod strich-coda

Ispolsuet automat schitivanie

schitivaet

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 24-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

Приведем ряд положений, которые поясняют решения, приведенные на Рис. 5 .

Одна из проблем организации бизнес - логики приложений на основе моделирования

предметной области заключается в сложности создания интерфейсов к реляционным базам

данных. Типовым решением, решающим проблему и примененным при организации слоя

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

одному классу на каждую таблицу базы данных, и единственный экземпляр класса содержит

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

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

(например, тем, что в слое классов предметной области смешаны данные и функции).

Для функционирования слоя предметной области на основе модуля таблицы

необходимы данные, поставляемые классами слоя источника данных из (в) БД. Типовым

решением в таких случаях является шлюз таблицы данных, обеспечивающее

посредством SQL взаимодействие с реляционной БД. Шлюз таблицы данных содержит в

себе все команды SQL, необходимые для извлечения, вставки, обновления и удаления

данных из таблицы или представления. Методы этого типового решения используются

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

таблицы базы данных создается собственный шлюз таблицы данных. В наиболее

простых приложениях ограничиваются разработкой одного шлюза таблицы данных,

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

рассматриваемом в данном руководстве (Рис. 5), применен один шлюз таблицы данных,

он же является единственным классом слоя источника данных.

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 25-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

PrintChek(ED1,UserCassir)

Id1 : UserCassir

UserCassir-Id1 :

Информационная система

UserCassir-Id1 :

Информационная система

StartSozdaniaTrbOplati( )

ViewTrb(ED1:E-TrebovanieOplati)

StartSchitatShtrihCod( )

StartPerevodaSost( )

SaveChek(ED1,UserCassir)

PrintChek()

PoiskSpec(ShtrihCod)

StartRaschetaSumPokupki( )

RaschetSumTrb()

StartRaschetaSdachi( )

RaschetSdachi( )

ViewSdachi(SumSdachi)

ViewSumTrb(TotalSum)

ViewTrbOplatiLineTov(T1,ShtrihCod)

ViewSaveChek(ED1,UserCassir )

Рис. 6 Диаграмма последовательности, моделирующая поддержку посредством ИС расчета за покупку

©Балтийский Государственный Технический Университет "ВОЕНМЕХ"\ИИУС\И3\ 26-61

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

Id1 : UserCassirId1 : UserCassir

UserCassir-Id1 :

Информационная система

UserCassir-Id1 :

Информационная система

Start( )

ViewAutentForms(Login, Password )

Input(Login, Password )

Autorisation(Login,Password )

ViewVozmojnosti (ACL)

Рис. 7 Диаграмма последовательности, моделирующая обеспечивающие функции ИС

P1 : UserProdavezP1 : UserProdavez

UserProdavez-P1 :

Информационная система

UserProdavez-P1 :

Информационная система

VivodFormParamPoiska( )

ViewFormParamPoiska( )

VvodParamPoiska( )

StartPoisk( )

ViewParamsPoiska( )

ViewResultatiPoiska ( )

EndPoisk

PoiskTovara( )

Рис. 8 Диаграмма последовательности, моделирующая вспомогательные функции ИС

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

7. Содержание раздела КП «Логическая модель ПО ИС»

В данном разделе должен содержаться набор UML - диаграмм, моделирующих

функциональные возможности и структуру программного обеспечения (ПО) ИС на

логическом уровне. Разработка должна осуществляться согласно схеме обобщенной

модели проектирования, рекомендованной RUP.

Исходными данными для разработки UML- диаграмм логической модели служат

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

концептуальная модель должна содержать основные классы ИС и отношения между ними,

то логическая модель должна содержать решения по взаимодействию объектов этих

классов в рамках выполнения, прежде всего, основных функций ИС. Решения по

взаимодействию выделяются в отдельную модель (можно подмодель), которая называется

моделью поведения. Для разработки модели поведения рекомендуется использовать

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

разработки модели поведения – операции для каждого класса концептуальной модели,

определенные в процессе моделирования функций ИС. Модель структуры ПО ИС,

разрабатывается уже с учетом операций классов и с включением новых классов –

интерфейсов, необходимость применения которых появилась при разработке модели

поведения. Для разработки модели структуры ПО ИС рекомендуется использовать

диаграммы классов.

При разработке логической модели рекомендуется применять шаблоны

проектирования (Expert, MVC, Controller и т.п.)

7.1 Содержание подраздела «Модель поведения»

Модель поведения (модель взаимодействия объектов) рекомендуется разрабатывать

посредством диаграмм последовательности. При необходимости можно использовать и

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

набором диаграмм последовательности. Каждая основная функция ПО ИС, определенная

в концепции ИС, должна быть отражена хотя бы в одной диаграмме последовательности.

На Рис. 9 представлена модель функции, которая называется «формирование

требования оплаты». Взаимодействие объектов на диаграмме моделируют следующие

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

последовательности действий:

1) создание требования на оплату (объект ED1:E-TrebovanieOplati); начинается с

операции StartSozdaniaTrbOplati () и заканчивается операцией ViewTrb();

2) сканирование товарной метки на покупаемом товаре и формирование записи о

товаре в требовании на оплату (объект T1: E-TrebovanieOplatiLineTov);

начинается с операции StartSchitatShtrihCod () и заканчивается операцией

ViewTrbOplatiLineTov().

На Рис. 10 представлена модель функции, которая называется «поддержка расчета за

покупку». Взаимодействие объектов на диаграмме моделируют следующие

последовательности действий:

1) расчет суммы покупки; начинается с операции StartRaschetaSumPokupki () и

заканчивается операцией ViewSumTrb();

2) расчет суммы сдачи; начинается с операции StartRaschetaSdachi () и

заканчивается операцией ViewSdachi()

3) формирование чека; начинается с операции StartPerevodaSost() и заканчивается

операцией ViewSaveChek(); характерной особенностью этой последовательности

является отображение действий, связанных с сохранением e-требования в

состоянии «e-chek» в БД посредством объекта Id1:DataShluz (шлюза таблицы

данных).

На диаграммах не показана последовательность действий по выпуску бумажного

чека, а также не отражены последовательности действий, моделирующие

обеспечивающие (аутентификация и авторизация) и вспомогательные (поиск товара в

каталоге) функции.

\\ Методические рекомендации по курсовому проектированию \ Смирнов Н.В.\ Версия 1.0.0\*.

d1 : UserCassird1 : UserCassir

Id1 : E-UI-CassirId1 : E-UI-Cassir Id1 : StrihCod-UI-CassirId1 : StrihCod-UI-Cassir

Id1 : ControllerProdajId1 : ControllerProdaj

Id1 : PravilaPrdTovId1 : PravilaPrdTov Id1 : UdalViz ovId1 : UdalViz ov

ED1 : E-TrebovanieOplatiED1 : E-TrebovanieOplati

T1 :

Е-TrebovanieOplatiLineTov

T1 :

Е-TrebovanieOplatiLineTov

T1 : E-TovarT1 : E-Tovar T1 : E-TovarSpecificationT1 : E-TovarSpecification

StartSchitatStrihCod( )

ZaprosSozdatTrbOplatiLineTov( )

VizovProc1(constructor, ED1)

Constructor( )

ZaprosSozdanieTrbOplati( )

VizovProc1(constructor, E-trebovanieOplati )

Constructor( )

PoluchitPrvila( )

StartSozdaniaTrbOplati( )

VizovProcData(ED1:E-TrebovanieOplati )

ReadData()

ViewTrb(ED1:E-TrebobanieOplati )

PoiskTov(ShtrihCod )

VizovProcTovSpec(ShtrihCod )

TovSpec(ShtrihCod)

VizovProcData(T1,ED1 )

ReadData( )

ViewTrbOplatiLineTov(T1,ShtrihCod, a1,a2,a3)

PoiskSpec( T1)

Рис. 9 Диаграмма последовательности, моделирующая формирование требования оплаты