Исследование технологий проектирования АИС

Введение

 

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

Вот только некоторые из преимуществ, которые дает использование вычислительной техники при работе организации:

• возможность оперативного контроля за достоверностью информации;
• уменьшение числа возможных ошибок при генерировании производных данных;
• возможность быстрого доступа к любым данным;
• возможность быстрого формирования отчетов;
• экономия трудозатрат и затрат времени на обработку информации.

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

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

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

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

Таким образом тема курсовой актуальна и в соответствии с ней поставлена цель курсовой работы – спроектировать автоматизированную информационную систему экономического объекта с использованием RAD-технологий.

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

1. изучение видов технологий проектирования;
2. обоснование выбора использования технологии проектирования;
3. описание предметной области;
4. разработка инфологической модели «сущность-связь»  
   АИС «Студенческий»
5. проектирование АИС «Студенческий» в программной среде Microsoft Access.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Теоретическое исследование технологий проектирования АИС

 

1.1 Автоматизированные  информационные системы

Автоматизированная информационная система (АИС) – это совокупность организационных, технических, программных  и информационных средств, собранных  в единую систему с целью сбора, хранения, обработки и выдачи необходимой  информации, предназначенной для  выполнения функций управления (рисунок.1) [9,1].

Рисунок 1 – Схема автоматизированной информационной системы

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 2 – Классификация технологий проектирования АИС

 

1.2 Каноническое проектирование

Каноническое проектирование АИС  отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать  выполнение элементарных операций. Как  правило, каноническое проектирование применяется для небольших локальных АИС. [48,1]

В основе канонического проектирования лежит каскадная модель жизненного цикла АИС. Процесс каскадного проектирования в жизненном цикле АИС в  соответствии с применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные системы стадий создания» делится на следующие семь стадий:

- исследование и обоснование создания системы;

- разработка технического задания (ТЗ);

- создание эскизного проекта;

- техническое проектирование;

- рабочее проектирование;

- ввод в действие;

- функционирование, сопровождение, модернизация.

 

1.3 Автоматизированное  проектирование (CASE-технология)

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

Наибольшая потребность в использовании  CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к  АИС.

CASE-технологии включают методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. Архитектура CASE-средства (рис. 3):

Рисунок 3 – Архитектура  CASE-средства

 

1.3.1 Функционально-ориентированное  проектирование

Основной идеей функционально-ориентированного проектирования на основе CASE-технологии является идея структурного анализа. Она заключается в следующем:

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

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

-  BFD (Business Function Diagram) – диаграмма бизнес-функций или функциональных спецификаций позволяет представить общую структуру информационной системы, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов.

- DFD (Data Flowing Diagram) – диаграмма потоков данных – жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. Также DFD-диаграмма показывает внешние по отношению к системе источники данных и адресатов, которые принимают информацию от системы, а также идентифицируют хранилища данных (накопители данных), к которым осуществляется доступ системы.

- STD (State Transition Diagram) – диаграмма переходов состояний (матрицы переходных ссылок) моделирует поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью STD-диаграмм можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний.

- ERD (Entity Relationship Diagram) – ER-модель данных предметной области (информационно-логические модели «сущность-связь») ориентированы на разработку базы данных, структура которой не зависит от конкретных информационных потребностей и позволяет выполнить любые запросы пользователей. ERD-диаграмма «сущность-связь» представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявленных данных, которые в дальнейшем используются функциями проектируемой системы.

- SSD (System Structure Diagram) – диаграмма структуры программного приложения задает взаимосвязь функций и программных модулей, которые их реализуют (меню, формы, отчеты и т.д.). SSD-диаграмма представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС, также служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах (BFD, DFD STD, ERD), к реализации информационной системы.

 

1.3.2 Объектно-ориентированное  проектирование АИС

Структурная декомпозиция АИС на основе объектно-ориентированного подхода  отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы  в зависимости от возникающих  событий. В этом плане модель предметной области рассматривается как  совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется  в виде последовательности взаимодействия объектов. Одна операция обработки  данных может рассматриваться как  результат одного взаимодействия объектов.

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

В настоящее время для объектно-ориентированного моделирования предметной области  широко используется унифицированный  язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) и фактически является стандартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами-производителями программного обеспечения в рамках CASE-технологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др.

Система объектно-ориентированных  моделей в соответствии с нотациями  UML включает в себя следующие диаграммы:

-Диаграмма прецедентов использования (Use-case diagram), которая отображает функциональность АИС в виде совокупности выполняющихся последовательностей транзакций.

- Диаграмма классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода.

- Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий.

- Диаграммы взаимодействия объектов (Interaction Diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования.

- Диаграммы деятельностей (Activity Diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более глубокие диаграммы).

- Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более глубокие диаграммы).

- Диаграмма компонентов (Component diagram), которая отображает физические модули программного кода.

- Диаграмма размещения (Deployment Diagram), которая отображает распределение объектов по узлам вычислительной сети.

 

1.2.3 Прототипное проектирование АИС (RAD-технология)

С появлением корпоративных АИС, базирующихся на архитектуре «клиент-сервер», появляется естественная возможность ускорения  разработки приложений за счет параллельного  создания клиентской и серверной  частей. Однако реально использовать преимущества такой архитектуры  оказалось очень непросто из-за резко  возросшей сложности создания приложений в гетерогенной среде. Кроме естественной сложности создания приложений в неоднородной среде существует тенденция к усложнению приложений с течением времени. В этих условиях процесс разработки информационных систем традиционным каскадным методом может затянуться на длительное время, а соответствие результата потребностям заказчика не гарантируется.

Основное желание заказчика  АИС – получить готовое приложение высокого качества быстро при минимальных  затратах на его разработку. Кроме  того вкладывая значительные средства на создание системы, заказчики желают контролировать процесс разработки. Критерием качества должно быть наиболее полное удовлетворение требований заказчиков на момент введения системы в эксплуатацию.

Одним из условий обеспечения высокого качества создаваемых АИС является активное вовлечение конечных пользователей  в процесс разработки предназначенных  для них интерактивных систем, что нашло отражение в методологии  прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD (Rapid Application Development).

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

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

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

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

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

Такие инструментальные средства можно  условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД – класс  DEVELOPER и интегрированные инструменты быстрой разработки приложений – класс BUILDER.

К инструментам этих классов можно  отнести средства 4GL (генераторы компонентов приложений):

- генераторы таблиц базы данных;

- генераторы форм ввода-вывода;

      - генераторы запросов;

      - генераторы отчетов;

      - генераторы меню.

Такие генераторы существуют почти  во всех СУБД, как персональных Access, FoxPro, Paradox, так и в окружении промышленных серверов БД (Oracle, Informix, Adabas D и др.).

Рассмотрим инструментальную среду  быстрой разработки приложений СУБД Access, которая включает ряд мастеров (конструкторов).

-Мастер (конструктор) таблиц предназначен для быстрого создания структуры таблиц БД и их взаимосвязей.

-Мастер (конструктор) форм ввода-вывода позволяет быстро создать экраны ввода информации в БД различного типа (ленточные, в столбец, матричные).

-Мастер (конструктор) запросов позволяет создавать запросы различной сложности.

-Мастер (конструктор) отчетов позволяет создавать отчеты на базе нескольких таблиц или запросов.

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

 

 

1.4 Типовое  проектирование

Методы типового проектирования АИС  предполагают создание системы из готовых  покупных типовых элементов (типовых  проектных решений). Для этого  проектируемая АИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных  модулей и т.д.), для которых  подбираются и закупаются имеющиеся  на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные  продукты настраиваются на особенности  конкретного предприятия или  дорабатываются в соответствии с  требованиями проблемной области.

Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая  программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может  выступать реализация как отдельных  компонентов АИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, АИС в целом). [386,1]

 

1.4.1 Параметрически-ориентированное проектирование

При проектировании АИС на основе параметрической настройки пакета прикладных программ (ППП), последний  рассматривается как «черный  ящик». На вход ППП подаются параметрический  и информационный потоки, а выходом  служит результат работы пакета.

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

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

Результаты работы пакета – отчеты, графики, электронные документы, которые  могут накапливаться или направляться во внешнюю среду.

ППП состоит из:

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

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

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

Сущность применения метода типового проектирования АИС на основе параметрической  настройки ППП заключается в  определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее – собственно настройке параметров и возможной доработке закупленного ППП.

 

Критерии оценки ППП:

1. Назначение и возможности пакета;
2. Оптимальные признаки и свойства пакета;
3. Требования к техническим и программным средствам;
4. Документация пакета;
5. Факторы финансового порядка;
6. Особенности установки;
7. Особенности;
8. Помощь поставщика по внедрению и поддержанию пакета;
9. Оценка качества пакета и опыт его использования;
10. Перспективы развития пакета. [390,1]

 

1.4.2 Модельно-ориентированное  проектирование

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

Ядром типовой АИС является постоянно  развиваемая модель предметной области, поддерживаемая в специальной базе метаинформации – репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация АИС сводятся прежде всего к построению модели предметной области и ее периодической корректировке.

Репозиторий корпоративной АИС содержит метаинформацию базовой модели функциональности типовой системы, типовых моделей определенных классов АИС и модели предприятий, получаемой на основе базовой или типовых моделей.

Базовая модель репозитория содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, организационной структуры, которые используются в программных модулях типовой АИС.

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

Модель предприятия (предметной области) строится либо путем привязки фрагментов основной или типовой модели в  соответствии со специфическими особенностями  предприятия, либо в результате просмотра  этих моделей и экспертного опроса.

Построенная модель предприятия в  виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация информационной системы, в ходе которой выполняется семантический контроль по бизнес-правилам. [404,1]

 

1.5 Обоснование  технологии проектирования для  проекта АИС «Студенческий»

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

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

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

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

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

-  Низкие материальные затраты за счет использования стандартного программного пакета Microsoft;

- Легкость и доступность любой информации, касающейся предприятия;

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

Технологическая сеть проектирования на основе прототипного проектирования (RAD-технология) представлена на рис.4.

 

Рисунок 4 - ТСП  прототипного проектирования (RAD-технология),

где Д1 – техническое задание на разработку; Д2 – описание предметной области; U1 – универсум средств быстрой разработки приложений; G1 – приложение-прототип; Д4 – результаты работы приложения-прототипа; Д5 – замечания и уточненные требования к АИС; G2 – доработанный прототип; Д6 – новые спецификации-требования; G3 – готовое приложение.

2 Проектирование АИС «Студенческий» для торгового предприятия

 

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

Магазин «Студенческий» – предприятие, занимающееся розничной торговлей бытовой химии, канцелярскими товарами.

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

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

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

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

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

• Затрудняется поиск нужной информации из-за огромного количества документов;
• Данные об учете дублируются несколько раз, что приводит к возникновению логических ошибок;
• Неточный контроль потока денежных средств.

Организационная структура магазина «Студенческий» представлена на рисунок.5.

 

 

 

 

 

 

 

Рисунок 5 – Организационная структура

 

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

В инструментальной среде пакета BPWin разработана модель функционирования экономического объекта «Студенческий». Контекстная диаграмма в нотации IDEF0 представлена на рис.12.