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

ВВЕДЕНИЕ

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

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

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

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

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

Целью работы считается построение модели информационной системы на примере магазина.

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Наименование и область применения

Наименование программного продукта – информационный ресурс для магазина «Электрик».

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

Технические требования

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

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

2 ВЫБОР МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ

2.1 Методология SADT

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

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

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

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

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

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

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных);

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

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

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

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

2.2 Диаграммы потоков данных DFD (Data Flow Diagrams)

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

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

Основные  символы и определения DFD:

- потоки данных; 

- процесс;

- хранилище (накопитель) данных;

- внешняя сущность (или терминатор). 

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

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

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

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

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

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

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

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

Методология объектного проектирования и анализа на языке UML

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

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

В UML применяются следующие  виды диаграмм: 

1) структурные диаграммы: 

- диаграмма классов;

- диаграмма компонентов;

- диаграмма композитной/составной структуры; 9

- диаграмма кооперации (UML 2.0);

- диаграмма развёртывания;

- диаграмма объектов;

- диаграмма пакетов;

- диаграмма профилей (UML 2.2). 

2) диаграммы поведения: 

- диаграмма деятельности; 

- диаграмма состояний;

- диаграмма разновидностей использования. 

3) диаграммы взаимодействия: 

- диаграмма коммуникации (UML 2.0);

- диаграмма обзора взаимодействия (UML 2.0);

- диаграмма последовательности;

- диаграмма синхронизации (UML 2.0). 

Приемущества UML: 

1) UML объектно-ориентирован, в итоге, способы описания результатов анализа и проектирования семантически близки к способам программирования на современных объектно-ориентированных языках;

2) UML разрешает описать систему буквально со всех вероятных точек зрения и различные нюансы поведения системы; 

3) диаграммы UML относительно несложны для чтения впоследствии довольно быстрого ознакомления с его синтаксисом;

4) UML разрешает вводить личные текстовые и графические стандарты, а еще используется сфере программной инженерии.

3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ ВЫБРАННОЙ МЕТОДОЛОГИИ
3.1 Построение диаграммы вариантов использования (прецедентов)

В данном курсовом проекте была применена методология объектного
проектирования на языке UML для создания таких диаграмм, как:

- диаграмма разновидностей использования;

- диаграмма состояний;

- диаграмма компонентов;

- диаграмма размещения.

Для создания  нового окна в IBM Rational Rose при запуске программыы
диалоговое окно появляется автоматчески  или же при поддержке вкладок «File –New», как показано на рисунке 1.

Рисунок 1 – Окно создания новой модели

Для создания действующего лица применяется кнопка Actor, изображённая на рисунке 2.

Рисунок 2 – Создание действующего лица

Двойным щелчком левой кнопки мыши по изображению действующего
лица открывается меню «Спецификация», в котором в поле «Name»
прибавляется название актера, как показано на рисунке 3.

Рисунок 3 – Присвоение имени действующему лицу

Для создания варианта применения используется кнопка «Use Case», как показано на рисунке 4.

Рисунок 4 – Создание прецедента

Двойным щелчком левой кнопки мыши по изображению прецедента при открытии меню «Спецификация», заполняем информацию во вкладках: 

- general – тут задаются совместные качества варианта применения: имя (Name), стереотип (Stereotype), приоритет (Rank), считается ли прецедент абстрактным (Abstract) и текстовое описание прецедента (Documentation); 

- diagrams – тут показываются всевозможные диаграммы, имеющие этот прецедент; 

- relations – тут показываются все связи, в которых этот прецедент участвует; 

- files – добавление файлов, содержащих вспомогательную информацию о классе. 

С помощью кнопки Unidirectional Association (однонаправленная ассоциация) панели инструментов формируется ассоциация (связь) между актером и прецеденто, как показано на рисунке 5.

Рисунок 5 – Создание связи между актером и прецедентом

Для работы системы информационного ресурса магазина «Электрик» на диаграмме вариантов применения были выделены надлежащие актёры:

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

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

Дальше рассмотрим,какие способности обязана предоставлять система: 

- актёр «Пользователь» использует систему для просмотра информационного материала о данном магазине, а так же для обратной связи; 

- актёр «Администратор» использует систему для авторизации при входе в администраторскую панель, а так же для редактирования в ней всевозможных компонентов, которые присутствуют в интернет-ресурсе. 

На основании вышеизложенного возможно отметить следующие прецеденты: 

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

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

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

- авторизация – запускается администратором системы. Разрешает определённому лицу при верном введении логина и пароля авторизоваться при входе в администраторскую панель;

- редактирование интерфейса вебсайта – запускается администратором системы. Разрешает внести изменения в интерфейс сайта; 

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

- редактирование базы данных (БД) – запускается администратором системы. Разрешает менять содержимое базы данных (БД);  

- добавление и удаление страниц – запускается администратором системы. Разрешает вносить изменения в страницы вебсайта, которые хранится в базе данных (БД). 

Диаграмма вариантов применения изображена на рисунке 6.

Рисунок 6 – Диаграмма вариантов использования, показывающая действия пользователей и администратора при входе на сайт.

3.2 Хранилище данных

Определимся с терминологией и понятиями. Корпоративное хранилище данных (Data Warehouse) – это не система ключевых показателей эффективности (КПЭ, KPI), это не большая база данных, это не аналитический OLAP-инструмент, это не интеллектуальная система, позволяющая добывать новые данные и получать статистические зависимости, это не система единой НСИ – это все не ХД, если говорить о нем в контексте отдельно взятого пункта.

Корпоративное хранилище данных – это специальным образом организованный массив данных предприятия (организации), обрабатываемый и хранящийся в едином аппаратно-программном комплексе, который обеспечивает быстрый доступ к оперативной и исторической информации, многомерный анализ данных (KPI по различным измерениям), получение прогнозов и статистики в разрезах согласованной нормативно-справочной информации (НСИ).

Хранилище данных (Data warehouses) – это предметно-ориентированная информационная база данных или же набор данных, предназначенный для помощи принятия решений. Данные, поступающие в хранилище, как правило, доступны лишь для чтения. 

Хранилище данных информационного ресурса состоит из  таблиц:

- таблица pages – в ней хранится информация о созданных страницах и тексте на сайте; 

- таблица images – в ней хранится информация о всех загруженных иллюстрациях. 

Данные таблицы представлены на рисунках 7 и 8.

Рисунок 7 – Таблица pages

Рисунок 8 – Таблица images

3.3 Построение диаграммы состояний

Диаграммы состояний предусмотрены для моделирования всевозможных состояний, в которых имеет возможность располагаться объект. В то время как диаграмма классов демонстрирует статическую картину классов и их связей, диаграммы состояний используются при описании динамики поведения системы. 
Диаграммы состояний отражают поведение объекта. 
Построение диаграммы состояний в программном продукте IBM Rational Rose выглядит слдующим образом: 

- создание диаграммы состояний с поддержкой команд «New – Statechart Diagram»;

- добавление таких компонентов как: State (состояния), Start State (начало), End State (завершение), State Transition (состояние перехода). 

На диаграмме есть два особых состояния изначальное и конечное. Изначальное положение отмечается черной точкой: оно соответствует состоянию объекта в момент его создания. Конечное положение обозначается черной точкой в белом круге: оно соответствует состоянию объекта именно перед его ликвидированием. На диаграмме состояний может быть одно и лишь одно изначальное положение.

Диаграмма состояний для вариантов применения, связанных с актёром «Администратор», показана на рисунке 9.

Рисунок 9 – Диаграмма состояний для вариантов применения, связанных с актёром «Администратор»

Диаграмма состояний для вариантов применения, связанных с актёром «Пользователь», показана на рисунке 10.

Рисунок 10 – Диаграмма состояний для вариантов использования, связанных с актёром «Пользователь».

3.4 Построение диаграммы компонентов

Диаграмма компонент демонстрирует как выглядит модель на физиологическом уровне. На ней отображаются составляющие программного обеспечения системыи связи между ними.

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

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

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

В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы
данных этих атрибутов.

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

На основании вышеизложенного возможно отметить
следующие компоненты:

- pages – таблица в базе данных, содержащая такие значения, как id, title и
info.

- images – таблица, имеющая id, photos и kind.

- index.php – ключевой компонент информационного ресурса, объединяющий
в себе другие компоненты.

- style.css – компонент, отвечающий за реализацию графического интерфейса
вебсайта.

- dba.php – компонент, отвечающий за реализацию интерфейса с базой
данных.

- message.php – компонент, отвечающий за реализацию формы обратной
связи.

Добавление компонента на диаграмму происходит при помощи
операции главного меню: «Tools – Create – Component» или же с помощью
операции контекстного меню: «New – Component».

При помощи панели инструментов добавляем компоненты на диаграмму, как показано на рисунке 11 и 12.

Рисунок 11 – Описание кнопок панели инструментов диаграммы компонентов в IBM Rational Rose

Рисунок 12 – Диаграмма компонентов после добавления компонента «Главная программа»

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

Диаграмма компонентов информационного ресурса показана на рисунке
13.

Рисунок 13 – Окончательный вид диаграммы компонентов информационного ресурса

Построение диаграммы размещения (развёртывания)

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. 

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

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

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

Главные элементы отображены на рисунке 14.

Рисунок 14 – Основные элементы для построения диаграммы размещения в IBM Rational Rose.

Диаграмма размещения (развёртывания) изображена на рисунке 15. На
ней показано взаимодействие файлов. Файл *.css ведет взаимодействие с клиентом на серверной стороне. Файлы *.php и *.sql так же ведут взаимодействие на серверной стороне, применяя веб-сервер Apache и СУБД PHPMyAdmin в соответствии с этим.

Рисунок 15 – Диаграмма размещения (развёртывания)

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

Итак, перечислим цели, преследуемые при разработке диаграммы развертывания:

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

Проектирование – это деятельность человека или организации по созданию проекта, то есть прототипа, прообраза предполагаемого или возможного объекта, состояния; комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект.

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

СПИСОК ЛИТЕРАТУРЫ

Методические указания к выполнению курсового проекта по дисциплине «Проектирование информационных систем». Изд. СКФУ, 2013 г.

Корпорация Майкрософт (Microsoft Corporation)., Перемещение данных Access в базу данных SQL Server с помощью мастера преобразования в формат SQL Server.

Базиян, Менахем и др. VisualFoxPro 6. Специальное издание: Пер. с англ. – М.: Издательский дом «Вильямс», 1999 – 928 с.

Бекаревич Ю.Б. Microsoft Access версия 7 — Москва: ДМК Пресс, 2003 — 324с.

Бобровский, С.И. Delphi 7. Учебный курс. Санкт — Петербург: Пинтер, 2004г. 736 стр.

Буч Г. Объектно – ориентированный анализ.

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

Вендров.В.М Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2005. – 352 с.

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

Гагарина Л.Г., Киселев Д.В., Федотова Е.Л Разработка и эксплуатация автоматизированных информационных систем. учеб. Пособие. Москва: ИД «Форум»: ИНФРА-М, 2009г. 384 стр.

Галатенко В.А., Основы информационной безопасности. Курс лекций. Учебное пособие. Москва: ИНТУИТ.РУ, 2004 г. 264 стр.

Гвоздева В.А. Основы построения автоматизированных информационных систем: учебник Москва: ИНФРА-М 2007г. 320 стр.

Голицын О.Л., Максимов Н.В., Попов И.И. Информационные системы. учебное пособие. Москва: ФОРУМ: ИНФРА-М, 2007г. 496 стр.

Гофман В. Работа с базами данных в Delphi. С-Пб: БХВ-Петербург 2001

Гребенюк Е. И., Гребенюк Н. А. Технические средства информатизации. Екатеринбург «Академия» 2007 г. 272 стр.

Грегори Р. Основы многопоточного, параллельного и распределенного программирования. Москва: Вильямс 2003г. 512 стр.

Дейт, К.Дж. Введение в системы баз данных – М.: Издательский дом Вильямс, 2009. – 89 с.

Дик, В.В. Информационные системы в экономике– М.

Емельянова, Н.З. Основы построения автоматизированных информационных систем – М. : Форум; Инфра-М, 2006. – 416 с.

Золотов, С.Ю. Проектирование информационных систем – Томск. : ТМЦДО, 2005. – 88 с.

Истомин Е. П., Новиков В. В.. Новикова М.В Высокоуровневые методы информатики и программирования . Москва: Андреевский Издательский дом 2006г. 228 стр.

Йордон Э., Аргила К. Объектно-ориентированный анализ и проектирование систем. Москва: Лори 2007г. 264 стр.

Калянов, Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес процессов – М. : Горячая линия-Телеком, 2010. – 68 с.

Карминский А.М., и др. Информатизация бизнеса. Концепции, технологии, системы, Москва: Астрэль 2004г. 624 стр.

Карпова, П.Т. Базы данных. Модели, разработка, реализация. СПб. : Питер, 2008. – 304 с.

Маклаков, С.В. BPWin и ERWin. CASE-средства разработки информационных систем – М. : ДИАЛОГ-МИФИ, 2006. – 129 с.

Мельников В.В. Безопасность информации в автоматизированных системах, Москва: 2003г. 368 стр.

Мельников В.В. Финансы и статистика, 2002. – 74 с.

Михеева Е.В. Практикум по информационным технологиям в профессиональной деятельности. Учебное пособие. Москва: Academia, 2008г. 256 стр.

Михеев Е.В. Информационные технологии в профессиональной деятельности. Москва: ТК Велби, Проспект, 2007г. 448стр.

Романенко А. Г., Самойлюк О. Ф., Максимович Г. Ю., Информационные системы: Учебное пособие — 2-е издание, дополнительное Учебное пособие — Москва: 2007г.

Сибилев, В.Б. Проектирование баз данных: учебное пособие – Томск. : ТМЦДО, 2007. – 52 с.

Смирнова Г.Н. и др. Проектирование экономических информационных систем: Учебник – М. Финансы и статистка, 2001.

Смирнова, Г.Н. Проектирование экономических информационных систем. – М. : Финансы и статистика, 2001. – 108 с.

Сорокин А.В. Delphi. Разработка баз данных. Санкт — Петербург: Питер, 2005г. 477стр.

Фаронов В. Программирование баз данных в Delphi 7. Учебный курс. С -Пб: Питер 2003

Фаронов, В.В. Системы программирования – СПб. : БХВ-Петербург, 2004. – 912 с.

Фридланд А. Я., Ханамирова Л. С., Фридланд И. А. Информатика и компьютерные технологии. Москва: АСТ, Астрель 2003г. 272 стр.

Фуфаев Э.В. Разработка и эксплуатация удаленных баз данных, Москва: Издательский центр «Академия» 2009г. 256 стр.

Хомоненко А. Д. Delphi 7 Санкт — Петербург: БХВ: Петербург, 2003г. 1216 стр.

Хомоненко, А.Д. Базы данных: учебник для вузов– СПб. : Корона-Принт, 2003. – 672 с.

Хомоненко А.Д., Цыганков В.М, Мальцев М.Г. Базы данных. Учебник для вузов. Санкт — Петербург: КОРОНА принт, 2004г. 736 стр.

Черемных, С.В. Структурный анализ систем. IDEF-технологии – М. : Финансы и статистика, 2004. – 43 с.

Шкрыль А.А. Разработка клиент-серверных приложений в Delphi. Санкт — Петербург: БХВ — Петербург 2006г. 474 стр.

Шлеер.К.М. Технология разработки программного обеспечения.