ВВЕДЕНИЕ 21. АНАЛИТИЧЕСКАЯ ЧАСТЬ 31.1. ПОСТАНОВКА ЗАДАЧИ 31.2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 41.3. АНАЛИЗ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ 81.4. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ 162. ПРОЕКТНАЯ ЧАСТЬ 192.1. ПРОЕКТИРОВАНИЕ МОДЕЛИ IDEF0 193.ОЦЕНКА ЭКОНОМИЧЕСКОГО ЭФФЕКТА 28ЗАКЛЮЧЕНИЕ 31СПИСОК ЛИТЕРАТУРЫ 32ПРИЛОЖЕНИЕ А. ДИАГРАММЫ IDEF0 33ПРИЛОЖЕНИЕ Б. ДИАГРАММА DFD 39ПРИЛОЖЕНИЕ В. ДИАГРАММА ERD 42 ВВЕДЕНИЕ Современный рынок диктует все более и более жесткие условия для функционирования малых предприятий. В связи с этим, все больше и больше руководителей торговых предприятий задумывается над организацией бизнес-процессов, происходящими внутри их фирм. Как организовать закупки? Как организовать продажи и хранение товаров? Вот лишь некоторые вопросы, которые встают перед директорами. Как видно, на первый план выходит организация бизнеса, чем лучше продумана структура торгового предприятия и процесс его функционирования, тем больше будет будущая прибыль. Данная работа как раз и направлена на то, чтобы изучить бизнес-процессы происходящие внутри торгового предприятия, выявить, так называемые, «узкие» места в структуре построения, функционирования фирмы и указать на них. Предметом детального анализа был выбран «Склад», так как работа этого подразделения организации влияет на всю деятельность предприятия. Цель данной работы – спроектировать деятельность торгового предприятия для повышения качества и прозрачности управления бизнес-процессами. Данная работа направлена на закрепление базовых знаний и навыков в области проектирования экономических информационных систем.^ 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ 1.1. ПОСТАНОВКА ЗАДАЧИ Целью данной курсовой работы является проектирование информационной системы «Торговое предприятие», уменьшить время, затрачиваемое на обработку информации, путем автоматизации процессов ввода, хранения и вывода информации. Для достижения поставленной цели необходимо решить следующие задачи: Исследовать предметную область; Обосновать выбор инструментальных средств; Формализовать бизнес-процессы (диаграммы IDEF-0), на базе полученных материалов обследования; Формализовать потоки данных (диаграммы DFD), на базе выявленных бизнес-процессов; Построить модель данных; Сгенерировать модель данных в целевую СУБД; Разработать прототип приложения; Оценить экономический эффект;^ 1.2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ В качестве объекта исследования было выбрано типовое торговое предприятие «Кубанский опт», занимающееся продажей канцелярских товаров, и содержащее в своем составе следующие отделы: «Отдел продаж», «Отдел закупок», «Склад» и «Бухгалтерия». Структура предприятия представлена на рисунке 1. Рисунок 1 – Структура предприятия Рассмотрим отдельно состав работников и функции, выполняемые каждым из отделов. Бухгалтерия – отдел представляют два человека: бухгалтер и директор. Данный отдел отвечает за исполнение следующих операций: Обработка первичной документации; Анализ поступающей информации от отделов продаж и закупок; Ведение взаиморасчетов с поставщиками и клиентами; Ведение налогового учета; Формирование документов на отгрузку товаров со склада; Формирование заявок на закупку товара. Отдел закупок – ответственен за контакты с поставщиками. Главная задача отдела сводится к тому, чтобы путем постоянного мониторинга состояния товарных запасов на складе, вовремя осуществлять заказы товаров у поставщиков и передавать документы на оплату заказанных товаров в бухгалтерию. В отделе числится два человека. Процедура взаимодействия с поставщиками выглядит следующим образом: сотрудник отдела закупок, анализирует остатки конкретной номенклатурной позиции на складе и принимает решение о необходимости заказа определенного количества товара у поставщика. По результатам анализа формируется заказ, который отправляется по электронной почте или по факсу поставщику, также формируется документ «Счет на оплату поставщику», который направляется в бухгалтерию для оплаты заказанных товаров. Отдел продаж – занимается непосредственной продажей товаров клиентам, количественно состоит из двух человек. Основными задачами, возлагаемыми на отдел, являются: осуществление контактов с покупателями, формирование документов вида «Счет на оплату покупателю», формирование отчетов о продажах товара для бухгалтерии. Процесс продажи организован следующим образом. Покупатель производит заказ товара, пользуясь предоставленным ему каталогом или путем непосредственного выбора товара с помощью менеджера отдела продаж. Представитель фирмы выписывает счет на выбранные товары и одновременно с этим фиксирует факт продажи данного товара для бухгалтерии. Получив счет, клиент направляется в бухгалтерию, где оплачивает заказанный товар и, получив документы, подтверждающие оплату, и документы на выдачу товара, направляется на склад для получения товара. Работа склада, заключается в том, чтобы своевременно осуществлять приемку и отгрузку товара, следить за сохранностью и количественных остатках номенклатурных единиц товара. Отдел состоит из двух человек – кладовщик и грузчик. В функции кладовщика вменяется контроль за поступающими и отгружаемыми товарами (соответствие фактического товара и данных о товаре по документам), информирование отдела закупок и отдела продаж о количественных остатках товара, а также выдача документов отражающих факт приемки или отгрузки товара. Резюмируя высказанное, функции, выполняемые отделами предприятия можно представить в виде матрицы организационных проекций. Матрица организационных проекций представлена в таблице 1. Таблица 1 – Матрица организационных проекций ФункцияОтдел Продажа товара Отгрузка товара Поиск клиентов Заказы к поставщикам Ведение бухгалтерского учета Контроль за сохранностью товара Бухгалтерия Х Х Х Х Отдел продаж Х Х Отдел закупок Х Склад Х Х Анализируя полученную таблицу можно сделать вывод, что отдел закупок выполняет относительно небольшой объем функций. Поэтому целесообразным было бы объединение бухгалтерии с отделом закупок, ввиду того, что количество поставщиков, с которыми работает отдел закупок не велико (порядка 10-15 фирм) и закупки товара производятся не ежедневно. Объединение позволит ускорить процесс закупки товара и сократить расходы.^ 1.3. АНАЛИЗ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ Процесс проектирования необходимо организовать средствами автоматизированного проектирования. Современные СП могут быть разделены на две большие категории. Первую составляют CASE- системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие проектирование БД и приложений в комплексе с интегрированными средствами разработки приложений "клиент-сервер" (например, Westmount I-CASE+Uniface.Designer/2000+Developer/2000). Их основное достоинство заключается в том. что они позволяют разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой категории, как правило, обладают существенной сложностью, широкой сферой применения и высокой гибкостью. Вторую категорию составляют собственно средства проектирования БД, реализующие ту или иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в комплексе со средствами разработки приложений. К средствам этой категории можно отнести такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др. Помимо указанных категорий, СП можно классифицировать по следующим признакам: степени интегрированности: (отдельные локальные средства, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, связанные общей базой проектных данных - репозиторием); применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; степени открытости; доступным платформам. На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:Vantage Team Builder (Westmount I-CASE); Uniface (Compuware); ERwin+BPwin. Westmount I-CASE представляет собой интегрированный программный продукт, обеспечивающий выполнение следующих функций: графическое проектирование архитектуры системы (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент- сервер", анализ использования мониторов транзакций и особенностей функционирования систем в реальном времени); проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм; генерация кода программ на 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур; программирование на языке С со встроенным SQL; управление версиями и конфигурацией проекта; генерация проектной документации по стандартным и индивидуальным шаблонам; экспорт и импорт данных проекта в формате CDIF. Westmount I-CASE можно использовать в конфигурации "клиент-сервер", при этом база проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть клиентами. Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres. Uniface (Compuware). Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер" и имеет следующую компонентную архитектуру: Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС. Application Model Manager поддерживает прикладные модели, каждая из которых представляет собой подмножество общей схемы БД с точки зрения данного приложения. Rapid Application Builder - средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических систем - MS Windows (включая VBX), Motif, OS/2. Developer Services (службы разработчика) – используются для поддержки крупных проектов и реализуют контроль версий, права доступа, глобальные модификации и т.д. Это обеспечивает разработчиков средствами параллельного проектирования, входного и выходного контроля, поиска, просмотра, поддержки и выдачи отчетов по данным системы контроля версий. Deployment Manager (управление распространением приложений) - средства, позволяющие подготовить созданное приложение для распространения, установить и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления базами данных. Uniface поддерживает интерфейс практически со всеми известными программно-аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами и менеджерами транзакций. Personal Series (персональные средства) - используются для создания сложных запросов и отчетов в графической форме, а также для переноса данных в такие системы, как Word и Excel. ERwin – CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания. ERwin предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. ERwin позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий. ERwin позволяет наглядно отображать сложные структуры данных. Ключевые характеристики ERwin: Синхронизация моделей/баз данных Автоматизированное создание структуры базы данных и обратное проектирование Публикация моделей Поддержка нотаций: IDEF1x, IE, Dimensional Документирование структур баз данных Перенос структур баз данных (но не самих данных) из одного типа СУБД в другой Функциональные возможности ERwin: Архитектура уровня проектирования. имеет достаточную гибкость для разработки архитектуры связных моделей данных, полностью удовлетворяющей потребностям организации. Наряду с комбинированной логической/физической моделью поддерживаются раздельные логические и физические модели. Благодаря накоплению знаний об отношениях между компонентами связанных моделей и ведению журнала проектных решений пользователи могут быстро определять влияние изменений одного уровня проектирования на другой. Технология трансформации. Физическая структура базы данных редко совпадает с исходной логической структурой. В целях повышения производительности бизнес-приложений часто требуется проводить денормализацию данных на физическом уровне модели. ERwin позволяет автоматизировать процесс трансформации модели, сохраняя в целости исходный проект. Определение стандартов. Определение и поддержка стандартов обеспечивается с помощью словаря доменов Domain Dictionary, редактора стандартов именования Naming Standards Editor и редактора стандартов типов данных Datatype Standards Editor. Словарь доменов содержит многократно используемые атрибуты и обеспечивает непротиворечивость имен и определений в рамках модели. Редактор стандартов именования позволяет пользователям создавать словари разрешенных терминов, аббревиатур и правил именования, которые могут использоваться повторно в рамках модели. Редактор стандартов типов данных позволяет определять собственные правила соответствия между типами данных разных СУБД. Поддержка нескольких нотаций моделирования. Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM). Управление большими моделями. ERwin облегчает управление большими корпоративными моделями за счет использования предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области позволяют конкретным проектировщикам фокусировать внимание, разделяя модель на более мелкие, и за счет этого легче управляемые подмодели. Хранимые отображения предоставляют разные варианты графического представления модели или ее предметных областей, облегчая обмен информацией между специализированными группами пользователей. Генерация структуры базы данных. ERwin позволяет автоматически сгенерировать структуру базы данных из модели. Входящие в продукт оптимизированные шаблоны триггеров ссылочной целостности и богатый макроязык, совместимый с различными типами баз данных, позволяют пользователю настроить триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают генерацию законченной физической структуры базы данных и полных определений (для соответствующей целевой базы данных). Графические объекты. С помощью графических объектов ERwin обеспечивает наглядное представление бизнес-правил. Графические объекты, например линии, эллипсы и другие, легко редактируются. Разработчики моделей могут также настраивать параметры шрифта и цвета объектов. Создание отчетов и печать. Ключевым элементом, обеспечивающим коммуникацию и совместную работу пользователей в процессе моделирования, является способность визуализации и публикации данных. ERwin предоставляет гибкие, настраиваемые возможности создания отчетов и печати. Поддерживаемые СУБД Oracle DB2/UDB (включая iSeries)SQL ServerTeradataODBCSybaseInformixIngresProgressAccess Поддерживаемые ОС Windows 2000Windows XP Windows 2003 Server В качестве примера можно привести результаты предварительного анализа перечисленных выше СП, которые сведены в краткую таблицу характеристик, приведенную ниже. Таблица 2 – Таблица характеристик СП West-mount I-CASE+Uniface Designer/2000+Developer/2000 ERwin/ERX+ PowerBuilder Поддержка полного жизненного цикла ИС + + + Обеспечение целостности проекта + + - Независимость от платформы + (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы) - (целевая СУБД - только ORACLE) + (ORACLE, Informix, Sybase, поддержка ODBC) Одновременная групповая разработка БД и приложений + - - Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс Westmount I-CASE+Uniface наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Westmount-Uniface Bridge. Следует отметить, что каждый из двух продуктов сам по себе является одним из наиболее мощных в своем классе. Таким образом, наиболее развитыми средствами разработки крупномасштабных ИС на сегодняшний день является, по моему мнению, комплекс Westmount I-CASE+Uniface. С другой стороны, его применение не исключает использования в том же самом проекте таких средств, как PowerBuilder, для разработки сравнительно небольших прикладных систем в среде MS Windows.^ 1.4. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ В результате анализа для данной курсовой работы были выбраны следующие приложения: BPwin – как средство проектирования процессов для модели ERWIN. Данное приложение предлагает удобные средства для разработки диаграмм бизнес-процессов. BPwin применялся в ходе учебного процесса, возможности данного продукта хорошо изучены. При выборе СУБД стоит руководствоваться требованиями, предъявляемыми к разрабатываемому проекту. При анализе наиболее популярных СУБД было отобрано три основных кандидата: Microsoft SQL Server; MySQL; Firebird. Microsoft SQL Server – система управления реляционными базами данных, разработанная корпорацией Microsoft. Обычно используется для работы с базами данных большого размера. Лицензирование осуществляется на платной основе. MySQL – свободная система управления базами данных. MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. MySQL, является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. MySQL – получил широкое распространение благодаря повсеместному использованию данной СУБД при создании веб-сайтов. Ссылка на литру. Firebird (FirebirdSQL) – компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах. В качестве преимуществ Firebird можно отметить многоверсионную архитектуру, обеспечивающую параллельную обработку оперативных и аналитических запросов (это возможно потому, что читающие пользователи не блокируют пишущих), компактность (дистрибутив 5Mb), высокую эффективность и мощную языковую поддержку для хранимых процедур и триггеров. Firebird используется в различных промышленных системах (складские и хозяйственные, финансовый и государственный сектора). Это коммерчески независимый проект программистов, технических советников и разработчиков мультиплатформенных систем управления базами данных, основанный на исходном коде, выпущенном корпорацией «Borland» 25 июля 2000 года в виде свободной версии Interbase 6.0. В результате анализа, в качестве целевой СУБД был выбран Firebird. Так как эта СУБД является бесплатной, поддерживает работу в трехзвенном приложении, а также обеспечивает необходимый уровень защиты данных. Для разработки приложения был выбран – Borland Delphi 7. Выбор этого средства разработки неслучаен. Разрабатываемое приложение будет работать под управлением операционной системы Windows. Раннее Borland Delphi 7 использовался в учебном процессе и прекрасно себя зарекомендовал как средство быстрой разработки приложений. Требования, предъявляемые к информационной системе: Эксплуатационные требования Система должна обеспечить регистрацию порядка 75-100 операций в день (продажи товара, закупки, регистрация отгрузки и т.д.) с учетом ее срока эксплуатации 5 лет (моральный износ) и с учетом перспектив развития и некоторого запаса. Требования к надежности Система должна восстанавливаться после сбоя (например, отключение питания) В программу должны быть встроены средства контроля ошибок: Контроль ссылочной целостности при попытках удаления записей; Анализ вводимой информации (запрет ввода текстовой информации в числовые поля) Требования к интерфейсам Программа должна быть сделана с использованием СУБД Firebird Программа должна иметь стандартный интерфейс с пользователем в среде Windows (многооконность, подсказки, статусная строка) Другие требования Программа должна поддерживать работу по сети нескольких пользователей Программа должна быть пригодной к сопровождению (модульность, понятность кода).^ 2. ПРОЕКТНАЯ ЧАСТЬ 2.1. ПРОЕКТИРОВАНИЕ МОДЕЛИ IDEF0 Моделируя деятельность предприятия, мы можем выделить как входную и выходную информацию, так же стоит еще учесть и другие факторы, влияющие на деятельность предприятия – это законодательство, устав компании, техническое обеспечение и другие факторы. При анализе деятельности торгового предприятия было выделено три основных работы отделов, входящих в состав предприятия. Рисунок 2 – Деятельность торгового предприятия Это отдел CRM, занимающийся продажей товаров и отвечающий за связь с клиентами, отдел консолидированной бухгалтерии, в ведении которого находится финансовые вопросы и заказ товаров, и склад, организующий поступление, хранение, и выдачу товара. Предметом моего исследования деятельности торгового предприятия является склад. Для того чтобы лучше понять его логику работы склада, мною было принято решение декомпозировать работу склада на три подработы: приемка товара, хранение и отгрузка товара. Рисунок 3 – Декомпозиция «Работа склада» Из диаграммы следует, что склад выполняет несколько функций. Прежде всего, это приемка товара. Она заключается в том, чтобы, получив товар передать его на хранение до момента его последующей перепродажи. Приемка товара осуществляется с обязательным контролем данных «Сопроводительных документов на товар» и фактического присутствия и качества товара. Другой не менее важной функцией является отгрузка товара покупателям. Основанием для выдачи того или иного товара со склада является «Документ на выдачу товара со склада» именно он содержит список и количество товаров, которые необходимо выдать. Факт выдачи товара клиенту отражается документально путем формирования документов вида «Складские документы». («Расходная накладная»)^ 2.2. ПОСТРОЕНИЕ МОДЕЛИ ПОТОКОВ ДАННЫХ Для того чтобы выделить бизнес-процесс необходимо построить диаграмму DFD. При построении диаграммы мною были выделены две основные сущности – поставщики и клиенты. Рисунок 4 – Диаграмма DFD. Деятельность торгового предприятия. Предприятие ведет торговую деятельность и повседневно контактирует с поставщиками и клиентами, поэтому информация о клиентах и поставщиках, их адресах нахождения, контактных лицах должна быть постоянно под рукой. Клиенты работают с отделом CRM, который осуществляет продажу товара и формирование заявок на отгрузку товара клиентам. Поставщики же напрямую контактируют с бухгалтерией, предоставляя свои данные. Вся работа торгового предприятия напрямую связана с документами – первичная документация, в данную категорию относятся счета на оплату от поставщиков, акты сверок с поставщиками и покупателями. Отдельное внимание стоит уделить поступающей и уходящей информации склада. Рисунок 4 – Диаграмма DFD. Работа склада. Склад осуществляет приемку и отгрузку товара, т.е. постоянно контактирует как с покупателями, так и с поставщиками. Обязательным условием приемки товара является наличие сопроводительных документов на товар – накладных на товар, в которых указывается наименование поставщика и получателя, а также список приходуемых товаров, с указанием количества и цены за единицу. Так же предусмотрены возвраты товара поставщику (в случае обнаружения брака). Выдача товара со склада также производится с обязательным документальным сопровождением проводимых операций. После того, как покупатель оплатил свою покупку, он получает товар и документ «Расходная накладная», в котором отражается наименование покупателя дата продажи и список проданных товаров.^ 2.3. РАЗРАБОТКА СХЕМЫ БАЗЫ ДАННЫХ Схема системы базы данных (от англ. Database scheme) – ее структура, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД). В реляционных базах данных схема определяет таблицы, поля в каждой таблице, а также отношения между полями и таблицами. После того как была построена модель потоков данных, можно приступить к созданию схемы данных. Анализируя данные диаграммы (Рисунок 3) можно выделить две сущности – поставщики и клиенты. Эти сущности послужат каркасом схемы базы данных, информация о данных сущностях будет храниться в соответствующих таблицах («Postavshiki», «Clients»). Помимо информации о поставщиках и клиентах необходимо следить за продажей, закупкой и количественными остатками товаров. Следовательно, необходимы еще как минимум три сущности, способных хранить необходимую информацию. В результате проведенного анализа создана модель сущность-связь.Рисунок 5 – Модель сущность-связь Полученная схема данных позволяет хранить всю необходимую информацию для нормального функционирования предприятия. ^ 2.4. ГЕНЕРАЦИЯ БАЗЫ ДАННЫХ Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. В своей курсовой работе в качестве CASE-средства был выбран программный продукт ERwin. ERwin обеспечивает генерацию схемы данных сущность-связь в физическую базу данных. Взаимодействие Case-средства и, в нашем случае, СУБД Firebird осуществляется по средствам использования драйвера ODBC («Open Database Connectivity»). Для корректной генерации схемы данных необходимо внести изменения в тексты шаблонов, используемые ERwin при создании таблиц и триггеров в целевой БД, а именно заменить двойные кавычки на одинарные в текстах используемых шаблонов. После того, как файлы шаблонов и сама схема БД готовы, необходимо воспользоваться методом «Forward Engineer\Schema Generation» - именно этот метод и осуществляет генерацию схемы данных в физическую существующую базу данных. ^ 2.5. РАЗРАБОТКА ПРИЛОЖЕНИЯ Как быть, если необходимо создать приложение, которое может с одинаковым успехом работать как в локальной сети, так и на удаленном компьютере. Очевидно, что в этом случае модель доступа к данным должна быть расширена, т.к. наличие большого числа удаленных клиентов делает традиционные схемы создания приложений БД малоэффективными. В этом разделе будет рассмотрена модель распределенного приложения БД, которая называется многозвенной (multitiered), и, в частности, ее наиболее простой вариант – трехзвенное распределенное приложение. Тремя частями такого приложения являются: собственно сервер базы данных; сервер приложений (серверная часть приложения); клиентская часть приложения. Все они объединены в единое целое единым механизмом взаимодействия (транспортный уровень) и обработки данных (уровень бизнес-логики). Компоненты и объекты Delphi, обеспечивающие разработку многозвенных приложений, объединены общим названием DataSnap. Многозвенная архитектура приложений баз данных вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от большого числа клиентов. Казалось бы, с этой задачей вполне могут справиться и приложения клиент/сервер. Однако в этом случае при большом числе клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает довольно скудным набором средств для реализации сложной бизнес-логики (хранимые процедуры, триггеры, просмотры и т.д.). И разработчики вынуждены существенно усложнять программный код клиентского ПО, а это крайне нежелательно при наличии большого числа клиентских компьютеров. Ведь с усложнением клиентского программного обеспечения возрастает вероятность ошибок и усложняется его обслуживание. Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки. Теперь рассмотрим составные части трехзвенного распределенного приложения в Delphi. Части трехзвенных приложений разрабатываются с использованием компонентов DataSnap, а также некоторых других специализированных компонентов, в основном обеспечивающих функционирование клиента. Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента. Клиентское приложение в трехзвенной модели должно обладать лишь минимально необходимым набором функций, делегируя большинство операций по обработке данных серверу приложений. В первую очередь удаленное клиентское приложение должно обеспечить соединение с сервером приложений. Для этого используются компоненты соединений DataSnap – TSocketconnection, использующий сокеты Windows; Компонент TSocketConnection обеспечивает соединение клиента с сервером приложений за счет использования сокетов TCP/IP. Для успешного открытия соединения на стороне сервера должен работать сокет-сервер Компоненты соединения DataSnap предоставляют интерфейс IAppServer, используемый компонентами-провайдерами на стороне сервера и компонентами TClientDataSet на стороне клиента для передачи пакетов данных. Для работы с наборами данных используются компоненты TClientDataSet, работающие в режиме кэширования данных. Компонент-провайдер TDataSetProvider представляет собой мост между набором данных сервера приложений и клиентским набором данных. Он обеспечивает формирование и передачу пакетов данных клиентскому приложению и прием от него сделанных изменений. Все необходимые операции компонент выполняет автоматически. Разработчику необходимо лишь разместить компонент TDataSetProvider и связать его с набором данных сервера приложений. Перейдем к рассмотрению программного интерфейса клиента и сервера. На форме сервера расположено текстовое поле, в котором отображается число подключенных в настоящий момент пользователей, ip-адрес и время подключения каждого из них. С точки зрения насыщенности компонентами, форма клиентского приложения намного превосходит форму сервера. Детально проработаны был интерфейс и функции, выполняемые пользователем с учетной записью «Склад». В верхней части окна приведен список всех товаров, которые хранятся на складе, с возможностью фильтрации выводимых записей по одному из установленных критериев. В левом нижнем углу расположена таблица с записями продаж товаров с помощью, которой пользователь может отслеживать динамику продаж товаров. Немного ниже расположена кнопка «Выдать», при нажатии на которую на экране появляется форма, в которой при необходимости можно выбрать документ продажи и распечатать документ «Расходная накладная». Правый нижний угол занимает блок «Закупки товаров», работа с блоком строится аналогично работе с блоком продажи товаров. Особое внимание стоит уделить кнопке «Update». Данная кнопка является неактивной до тех пор, пока не произошло изменений в записях таблиц БД. Как только что-то изменилось (Например: бухгалтер изменил цену товара), кнопка нач