 |
Построение модели потоков данных. Диаграмма DFD
|
|
|
|
Для того чтобы выделить бизнес-процессы необходимо построить диаграмму DFD. При построении диаграммы я выделила основную сущность - клиенты, и хранилища договоров и заявок. (Рисунок 4)
Таким образом, видно, что заявка поступает от клиента, подтверждается согласие на ее выполнение, назначается исполнитель, а далее заключается договор.
Рисунок 4 - Диаграмма DFD. Деятельность предприятия «IT-Сервис»
Потоки данных обслуживающего подразделения при этом выглядят следующим образом (Рисунок 5):
Рисунок 5 - Диаграмма DFD. Деятельность обслуживающего подразделения
Любой процесс взаимодействия предприятия с клиентами отражается в документах. Это происходит с момента поступления заявки до момента исполнения обязательств по договору.
Разработка схемы базы данных
После построения модели потоков данных, приступаем к созданию схемы данных. Для автоматизации документооборота необходимо оперировать как со статичными данными, так и с постоянно обновляемой информацией. Помимо информации о сотрудниках, товарах и услугах, необходимо анализировать поступающие заявки, подтверждать их и формировать на их основе договоры об оказании услуг. Таким образом, логично составить модель «сущность-связь» следующего содержания.
Рисунок 6 - Модель «сущность-связь»
Полученная схема данных позволяет хранить всю необходимую информацию для нормального документооборота предприятия.
Генерация базы данных
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения.
|
|
|
Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В своей курсовой работе в качестве CASE-средства был выбран программный продукт ERwin. ERwin обеспечивает генерацию схемы данных «сущность-связь» в физическую базу данных. Взаимодействие CASE-средства и, в нашем случае, СУБД Firebird осуществляется по средствам использования драйвера ODBC («Open Database Connectivity»). Для корректной генерации схемы данных необходимо внести изменения в тексты шаблонов, используемые ERwin при создании таблиц и триггеров в целевой БД, а именно заменить двойные кавычки на одинарные в текстах используемых шаблонов. После того, как файлы шаблонов и сама схема БД готовы, необходимо воспользоваться методом «Forward Engineer\Schema Generation» - именно этот метод и осуществляет генерацию схемы данных в физическую существующую базу данных.
Разработка приложения
Информационные системы, созданные на основе классической архитектуры клиент/сервер, называемые двухзвенными системами или системами с «толстым» клиентом, состоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных с помощью Delphi, для доступа к источникам данных они используют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД [3]. Эти вызовы осуществляются обычно посредством использования библиотеки Borland Database Engine (BDE), хотя в целом это не является обязательным. Соответственно подобное клиентское приложение требует наличия на компьютере конечного пользователя клиентской части используемой серверной СУБД (и наличия лицензии на ее использование) и присутствия в оперативной памяти набора динамически загружаемых библиотек как из клиентской части, так и из BDE (либо иной заменяющей ее библиотеки), таких, как драйверы баз данных, библиотеки, содержащие функции API клиентских частей, и др. Это усложняет технические требования, предъявляемые к аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом.
|
|
|
Другим фактором, приводящим к удорожанию эксплуатации информационной системы, является необходимость инсталляции и конфигурации BDE и клиентской части серверной СУБД, что нередко является весьма трудоемким процессом, особенно при большом количестве и неоднородном парке рабочих станций.
Выходом из этой ситуации является создание систем с так называемым «тонким» клиентом, в частности, с клиентом, не содержащим в своем составе BDE и клиентскую часть серверной СУБД. В этом случае функциональность, связанная с доступом к данным (а нередко и какая-либо иная функциональность), возлагается на другое приложение, называемое обычно сервером приложений, и являющееся клиентом серверной СУБД. В свою очередь, клиентские приложения обращаются не непосредственно к серверной СУБД посредством вызова функций клиентских API, а к серверу приложений, являющемуся для них источником данных, при этом собственно клиентская часть серверной СУБД и библиотеки типа BDE на рабочей станции, где используется такое клиентское приложение, присутствовать не обязаны. Вместо них используется одна единственная динамически загружаемая библиотека dbclient.dll размером 154 Кб. Таким образом, созданная информационная система становится трехзвенной, а сервер приложений является средним звеном в цепи «тонкий клиент - сервер приложений - сервер баз данных».
|
|
|
Итак, рассмотрим составные части трехзвенного приложения в Borland Delphi 7. Части трехзвенных приложений разрабатываются с использованием компонентов DataSnap, а также некоторых других специализированных компонентов, в основном обеспечивающих функционирование клиента.
Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента.
Клиентское приложение в трехзвенной модели должно обладать лишь минимально необходимым набором функций, делегируя большинство операций по обработке данных серверу приложений.
В первую очередь удаленное клиентское приложение должно обеспечить соединение с сервером приложений. Для этого используются компоненты соединений DataSnap - TSocketConnection обеспечивает соединение клиента с сервером приложений за счет использования сокетов TCP/IP. Для успешного открытия соединения на стороне сервера должен работать сокет-сервер. Компоненты соединения DataSnap предоставляют интерфейс IAppServer, используемый компонентами-провайдерами на стороне сервера и компонентами TClientDataSet на стороне клиента для передачи пакетов данных. Для работы с наборами данных используются компоненты TClientDataSet, работающие в режиме кэширования данных.
Компонент-провайдер TDataSetProvider представляет собой мост между набором данных сервера приложений и клиентским набором данных. Он обеспечивает формирование и передачу пакетов данных клиентскому приложению и прием от него сделанных изменений. Все необходимые операции компонент выполняет автоматически. Разработчику необходимо лишь разместить компонент TDataSetProvider и связать его с набором данных сервера приложений.
|
|
|
