Разработка информационной системы организации на примере магазина

Размещено на http://www.allbest.ru/

12

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

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

Целью работы является реализация информационной системы организации на примере магазина. Начальным этапом создания системы является изучение, анализ и моделирование деятельности торговой точки для возможного улучшения и оптимизации методов работы. В курсовой работе используется инструментальные средства для моделирования CA Erwin Process Modeler, AllFusion Process Modeler.

1 АНАЛИЗ СТРУКТУРНЫХ ФУНКЦИОНАЛЬНЫХ МЕТОДОВ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

1.1 SADT-методология

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

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

1) анализ -- определение того, что система будет делать;

2) проектирование -- определение подсистем и их взаимодействие;

3) реализация -- разработка подсистем по отдельности, объединение -- соединение подсистем в единое целое;

4) тестирование -- проверка работы системы;

5) установка -- введение системы в действие;

6) эксплуатация -- использование системы.

В основе методологии SADT лежат два основных принципа.

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

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

Обычно SADT-методология применяется на ранних этапах жизненного цикла информационной системы.

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

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

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

1.2 IDEF0-методология

IDEF0 - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (WorkFlow).

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

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

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

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

Не смотря на то, что в настоящее время появляются десятки новых методологий моделирования деятельности предприятия и взглядов на её архитектуру, IDEF0 сохраняет актуальность для задач усовершенствования предприятий и организаций. Преимущества методологии IDEF0:

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

2) продолжает использоваться и рекомендоваться в качестве стандарта описания деятельности организации и предприятия;

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

4) конкуренция и борьба за качество продукции увеличивает потребности современных предприятий в информатизации, тем самым, поставляя дополнительные задачи для системных аналитиков и проектировщиков;

5) последовательное и постоянное улучшение деятельности, усовершенствование, реорганизация и реинжиниринг предприятия, и т.д., выдвигает ряд системных требований по учёту многих факторов: Люди, Оборудование, Информация, Управление предприятием и Системы управления производственными процессами;

6) успешное моделирование различных аспектов деятельности предприятия позволяет формально выявить и собрать требования к проектируемой системе, а затем вести разработку системы, которая удовлетворяет этим требованиям;

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

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

9) влияние внешней среды предприятия или системы может быть также объектом моделирования и исследования;

10) использование единого языка для представления деятельности предприятия и внешней среды позволяет получать процессные модели, которые отражают точку зрения потребителя;

11) существующие процедуры обсуждения IDEF0-моделей позволяют аналитику и заказчику проектных работ (промышленному потребителю) достичь консенсуса и взаимопонимания.

1.3 IDEF1X-методология

Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:

1) каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

2) каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

3) каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

4) каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

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

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

1.4 DFD-методология

DFD -- общепринятое сокращение от англ. Data Flow Diagrams -- диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) -- один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации -- Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

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

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

Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных.

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

1) определение существующих хранилищ данных (текстовые документы, файлы, система управления базой данных -- СУБД);

2) определение и анализ данных, необходимых для выполнения каждой функции процесса;

3) подготовка к созданию модели структуры данных организации, так называемой ERD-модели (IDEF1X);

4) выделение основных и вспомогательных бизнес-процессов организации.

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

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

2 ФУНКЦИОНАЛЬНЫЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ ОРГАНИЗАЦИИ

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

Помимо самого процесса продаж, к деятельности магазина также относятся:

1) работа с поставщиками;

2) обеспечение безопасности магазина;

3) сервисное обслуживание продаваемой техники.

Диаграмма А0 представлена на рисунке 1. Основной деятельностью является «продажа товара». Входные данные: информация о покупателях, информация о товаре. Управляющей информацией являются закон о правах потребителей и устав магазина, управляющим механизмом - обслуживающий персонал. Выходные данные представляются в виде сопроводительной документации.

Рисунок 1 - Диаграмма А0

Теперь проведем декомпозицию полученной диаграммы.

Деятельность «продажа товара» можно представить как последовательность следующих действий (рисунок 2):

1) предподготовка;

2) оформление;

3) получение;

4) постсервис.

5)

Рисунок 2 - Декомпозиция диаграммы А0

Проведем дальнейшую декомпозицию. Деятельность «предподготовка» включает следующие действия (рисунок 3):

1) консультация;

2) выбор товара;

3) проверка наличия на складе.

Рисунок 3 -Декомпозиция деятельности «предподготовка»

Проведем декомпозицию «оформление». Деятельность «оформление» включает следующие действия (рисунок 4):

1) оплата;

2) заявка на склад;

3) оформление документации.

Рисунок 4 - Декомпозиция деятельности «оформление»

В «получение» входят функции (рисунок 5):

1) передача товара;

2) оформление гарантии;

3) выдача сопроводительной документации.

Рисунок 5 - Декомпозиция деятельности «получение»

В «постсервис» входят функции (рисунок 6):

1) проверка наличия неисправностей;

2) осуществление ремонта;

3) проверка гарантии;

4) выдача товара.

Рисунок 6 - Декомпозиция деятельности «постсервис».

После построения информационной модели сформируем древо целей:

Рисунок 7 - Древо целей информационной системы.

3. РАЗРАБОТКА ЛОГИЧЕСКОЙ И ФИЗИЧЕСКОЙ МОДЕЛЕЙ

Разработка логической и физической модели начинается с проведения процесса системного моделирования для предметной области с помощью инструментальной среды CA Erwin Process Modeler.

Процесс построения информационной модели состоит из следующих шагов:

1) определение сущностей;

2) определение атрибутов сущностей;

3) задание первичных и альтернативных ключей;

4) определение зависимостей между сущностями;

5) приведение модели к требуемому уровню нормальной формы;

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

7) генерация базы данных.

CA Erwin Process Modeler создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако CA Erwin Process Modeler далеко не только инструмент для рисования. CA Erwin Process Modeler автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Основные компоненты диаграммы CA Erwin Process Modeler - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Построение модели данных предполагает определение сущностей и атрибутов.

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

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

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

В модели магазина я выделил следующие сущности и атрибуты:

1) «Информация о товаре» с атрибутами: код товара, стоимость, наименование, характеристики, срок гарантии, комплектация, наличие на складе.

2) «Накладная» с атрибутами: номер накладной, код товара, дата, ФИО кассира, поставщик, количество товара.

3) «Информация о покупателе» с атрибутами: код покупателя, ФИО покупателя, паспортные данные, адрес.

4) «Гарантийный талон» с атрибутами: номер талона, код покупателя, наименование продавца, ФИО покупателя, производитель товара, срок гарантии.

5) «Чек» с атрибутами: номер чека, код товара, количество товара, сумма, дата.

Чтобы создать и физическую и логическую модель, выбираем тип модели logical/physical и создаем сущности (рисунок 8, 9).

Рисунок 8 - Логическая модель ИС магазина.

Рисунок 9 - Физическая модель ИС магазина.

Сгенерируем код программы при помощи панели Access Schema Generation.

Код:

CREATE TABLE Гарантийный_талон

(

Код_товара integer NOT NULL ,

Наименование_продавца char NULL ,

ФИО_покупателя char(18) NULL ,

Производитель_товара char(18) NULL ,

Номер_талона integer NOT NULL ,

Срок_гарантии char(18) NULL ,

Код_покупателя integer NOT NULL

)

go

CREATE UNIQUE CLUSTERED INDEX XPKГарантийный_талон ON Гарантийный_талон

(

Номер_талона ASC,

Код_товара ASC,

Код_покупателя ASC

)

go

CREATE TABLE Информация_о_покупателе

(

ФИО_покупателя char(18) NULL ,

Адрес char(18) NULL ,

Паспортные_данные char(18) NULL ,

Код_покупателя integer NOT NULL

)

go

CREATE UNIQUE CLUSTERED INDEX XPKИнформация_о_покупателе ON Информация_о_покупателе

(

Код_покупателя ASC

)

go

CREATE TABLE Информация_о_товаре

(

Стоимость char(18) NULL ,

Наименование char(18) NULL ,

Характеристики char(18) NULL ,

Срок_гарантии char(18) NULL ,

Комплектация char(18) NULL ,

Наличие_на_складе char(18) NULL ,

Код_товара integer NOT NULL

)

go

CREATE UNIQUE CLUSTERED INDEX XPKИнформация_о_товаре ON Информация_о_товаре

(

Код_товара ASC

)

go

CREATE TABLE Накладная

(

Код_товара integer NOT NULL ,

Дата char(18) NULL ,

ФИО_кассира char(18) NULL ,

Поставщик char(18) NULL ,

Количество_товара char(18) NULL ,

Номер_накладной integer NOT NULL

)

go

CREATE UNIQUE CLUSTERED INDEX XPKНакладная ON Накладная

(

Номер_накладной ASC,

Код_товара ASC

)

go

CREATE TABLE Чек

(

Количество_товара char(18) NULL ,

Сумма char(18) NULL ,

Дата char(18) NULL ,

Номер_чека integer NOT NULL ,

Код_товара integer NOT NULL

)

go

CREATE UNIQUE CLUSTERED INDEX XPKЧек ON Чек

(

Номер_чека ASC,

Код_товара ASC

)

go

ALTER TABLE Гарантийный_талон

ADD CONSTRAINT R_3 FOREIGN KEY (Код_товара) REFERENCES Информация_о_товаре(Код_товара)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Гарантийный_талон

ADD CONSTRAINT R_8 FOREIGN KEY (Код_покупателя) REFERENCES Информация_о_покупателе(Код_покупателя)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Накладная

ADD CONSTRAINT R_4 FOREIGN KEY (Код_товара) REFERENCES Информация_о_товаре(Код_товара)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Чек

ADD CONSTRAINT R_5 FOREIGN KEY (Код_товара) REFERENCES Информация_о_товаре(Код_товара)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

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

ЗАКЛЮЧЕНИЕ

система информационная модель проектирование

В данном курсовом проекте была реализована система организации на примере магазина при использовании инструментальных средств CA Erwin Process Modeler, AllFusion Process Modeler. Разработанная система позволяет осуществлять полноценное функционирование как отдельно взятого магазина бытовой техники, так и целой сети. Разработка информационной системы была разделена на следующие этапы:

1) углубленное изучение предметной области,

2) создание функциональной модели организации,

3) создание логической и физической модели информационной системы.

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

Основное назначение информационной системы - создание современной инфраструктуры для управления предприятием, организацией, или учреждением.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Балабанов И.Т. Современные моделирования./ И.Т. Балабанов - СПб: Питер, 2002. - 120 с.: ил. - (серия “Основы”).

2. Венчковский Л.Б. Разработка сложных программных изделий. - электронный вариант.

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебное пособие. - М.: Финансы и статистика, 2002 электронный вариант

4. Журнал Opensys № 11, 2008 г. - «Управление организацией»

5. Пахчанян А. Обзор информационных систем // Директор информационной службы. - 2001.

6. CA Erwin Process Modeler [Электронный ресурс]:[справочный листок]. - ЕрВин, 2011. - Режим доступа: http://www.erwin-info.ru/

7. CA Erwin Process Modeler [Электронный ресурс]:[справочный листок]. - Информационные Системы, 2011. - Режим доступа: http:// www.v8.1c.ru

8. ITru [Электронный ресурс]:[справочный листок]. - Моделировании ИС, 2011. - Режим доступа: http:// www.it.ru /

9. INTERFACE [Электронный ресурс]:[справочный листок]. - Моделирование бизнеса и архитектура информационной системы, 2011. - Режим доступа: http://www.interface.ru /

10. Optima WorkFlow [Электронный ресурс]:[справочный листок]. - ОПТИМА, 2011. - Режим доступа: http://www.optima.ru/

Размещено на Allbest