Проектирование информационных систем

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

Содержание

Введение

Цели и задачи выполнения курсовой работы

Структура и содержание основных этапов курсовой работы

Рекомендации по моделированию предметных областей

Требования к оформлению курсовой работы

Защита курсовой работы

Список рекомендуемой литературы

Приложение



Введение

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

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

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

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

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

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

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

Цели и задачи выполнения курсовой работы

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

Разработка темы требует углубленного знания предметной области. В связи с этим основой для работы являются как знания, полученные по курсу «Проектирования информационных систем», так и знания, приобретенные при изучении таких дисциплин, как «Информатика и программирование», «Теоретические основы информационных систем и технологий», «Базы данных», «Информационные системы», «Информационные системы в экономике».

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

Структура и содержание основных этапов курсовой работы

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

пояснительная записка;

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

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

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

Пояснительная записка должна содержать следующие разделы:

Титульный лист

Содержание

Введение (актуальность, цель, задачи, методы, структура работы)

Основная часть (главы, выводы по главам)

Вывод по главе

Заключение

Список литературы

Приложения

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

Проектирование функционального обеспечения комплекса задач предметной области внедрения информационной системы (разработка функциональных моделей с помощью методологий функционального моделирования бизнес-процессов и программного продукта AllFusion Process Modeler (BPwin), MS Visio). Результат - функциональная модель бизнес-процессов предметной области в нотациях IDEF0, IDEF3, DFD.

Проектирование информационных моделей данных (разработка модели данных с помощью методов информационного моделирования программного продукта AllFusion Data Modeler (ERwin), MS Visio). Результат - информационная модель данных предметной области в нотации IDEF1X.

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

Детальное обследование и анализ предметной области (объекта автоматизации)

Описательная характеристика предметной области (объектно-субъектный состав)

Анализ основных процессов предметной области

Анализ информационных объектов предметной области

Технология реализации проекта

Технология реализации проекта

Методы реализации задач

Инструменты реализации задач

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

3.1 Формирование требований к модели

3.2. Реализация модели заданной предметной области

3.3 Анализ построенной модели

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

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

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

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

В п. 3.2 приводится описание результата курсового проектирования - модели заданной предметной области с помощью выбранной методологии и инструментария моделирования.

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

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

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

Рекомендации по моделированию предметных областей

Рекомендации по выполнению курсовой работы по тематике «Разработка функциональных моделей с помощью метода IDEF0»

Задача по разработке модели процесса с помощью метода моделирования бизнес-процессов IDEF0 реализуется с помощью программного продукта CA ERwin Modeling Suite (CA ERwin Process Modeler (BPwin) в нотации IDEF0. Результатом выполнения задачи является модель соответствующего процесса в нотации IDEF0.

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

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

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

IDEF0-методология основана на следующих концепциях:

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

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

Передача информации. В IDEF0 существует ряд средств, разработанных для улучшения передачи информации:

диаграммы, основанные на очень простой графике блоков и дуг;

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

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

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

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

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

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

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

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

связность структуры данных (ICOM-коды и использование туннельных дуг);

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

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

ограничение на ветвление дуг данных (метки для ограничений потоков данных на ветвях);

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

требования к меткам дуг данных (правила минимальных меток);

минимальное управление для функций (для каждой функции нужна, по крайней мере, одна управляющая дуга;

цель и точка зрения (у каждой модели есть цель и точка зрения).

Методология. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач интеграции.

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

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

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

Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающим функции. При этом каждая сторона блока имеет вполне определенное назначение: левая сторона предназначена для Входов (Input - I), верхняя - для Управления (Control - C), правая - для Выходов (Output - O), нижняя - для Механизмов (Исполнителей) (Mechanism - M).

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

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

Рисунок 1. Пример IDEF0-диаграммы (контекстный блок)

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

Рисунок 2. Декомпозиция диаграммы (контекстного блока)

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

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

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

Дуги в IDEF0 представляют наборы предметов (данных) и маркируются текстами на естественном языке. Данные могут состоять с функциями в четырех возможных отношениях: Вход, Выход, Управление, Механизм.

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

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

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

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

Сбор информации.

Декомпозиция объекта исследования.

Моделирование:

Выбор цели и точки зрения.

Составление списка данных.

Составление списка функций.

Построение и обобщение диаграммы А0(А0 - А-0).

Декомпозиция ограниченного объекта.

Итерационный процесс рецензирования.

Завершение моделирования.

Документирование.

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

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

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

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

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

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

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

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

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

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

Одна из самых важных проблем, возникающих при моделировании, - когда следует завершить построение конкретной модели. IDEF0-модели иерархичны, поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие IDEF0-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.

Рекомендации по выполнению курсовой работы по тематике «Разработка информационных моделей данных с помощью метода IDEF1X»

Задача по разработке информационной модели с помощью метода моделирования IDEF1X реализуется с помощью программного продукта CA ERwin Modeling Suite (CA ERwin Data Modeler (EPwin) в нотации IDEF1X. Результатом выполнения задачи является модель сущность - связь в нотации IDEF1X.

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

IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации.

Построение концептуальной модели базы данных в нотации IDEF1X поддерживает CASE средство ERwin.

Первым шагом при создании логической модели является создание диаграммы зависимостей сущностей (Entity Relationship Diagram, ERD) - модели данных высокого уровня.

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

Рисунок 3. Пример диаграммы зависимостей сущностей

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

Рисунок 4. Пример диаграммы сущность - связь с атрибутами

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

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

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

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

(а) (б)

Рисунок 5. Зависимая (а) и независимая (б) сущность

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

На рис. 5 каждый экземпляр сущности Сотрудник содержит следующую информацию: Id_сотрудика, ФИО_сотрудника, Должность, ИНН, Квалификация. В логической модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связь - является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) Связи играют роль ссылок, соединений и ассоциаций между сущностями.

Простые для понимания правила помогают определять ограничения, накладываемые на данные, а также точно определять атрибуты связей. Примером связи может быть: Отдел <состоит из > Сотрудник.

Рисунок 6. Пример связи между сущностями

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

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

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

Физическая модель в ERwin имеет три основных уровня представлений:

табличное представление (Table view): содержит таблицы с наименованиями и связями;

табличное представление с комментариями (Comments view): дополнительно содержит комментарии к таблицам;

представление колонок таблиц (Column view): содержит таблицы и названия колонок в таблицах.

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

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

Создание логической модели данных:

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

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

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

определение неключевых атрибутов сущностей.

Переход к физическому описанию модели:

назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы;

задание триггеров, хранимых процедур и ограничений.

Генерация базы данных.

Требования к оформлению курсовой работы

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

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

Оформление курсовой работы должно соответствовать определенным требованиям. Курсовая работа должна быть выполнена в редакторе Microsoft Word или аналогичном с учетом следующих требований:

размер листа бумаги - А4;

основной шрифт текста - Times New Roman;

размер шрифта - 14 пунктов;

межстрочный интервал - полуторный;

размер левого поля - 3 см;

размер правого поля - 1 см;

размер верхнего и нижнего полей - 2 см;

нумерация страниц - вверху страницы;

выравнивание текста - по ширине;

объем - от 30 до 40 стр.

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

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

Таблицы и рисунки подписываются строчными буквами, неполужирным шрифтом, 14 пт. Таблицы подписываются сверху по левому краю. Перед названием необходимо указать номер таблицы. Пример: Таблица 1 - Название. Рисунки подписываются снизу по центру. Пример: Рисунок 1 - Название. Точка после названия таблиц и рисунков не ставится.

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

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

Пример описания книги одного автора:

Керимов В. Э. Учет затрат, калькулирование и бюджетирование в отдельных отраслях производственной сферы: учебник / В. Э. Керимов - М.: Дашков и К, 2005. - 484 с.

Пример описания книги двух авторов:

Антонова О. В. Управление кризисным состоянием организацией (предприятия): учебное пособие / О. В. Антонова, В. А. Швандер. - М.: ЮНИТИ-ДАНА, 2004. - 141 с.

Пример описания книги трех авторов:

Куницын А. Р. Настольная книга федерального судьи: судебная практика, комментарии, образцы документов, информационные материалы / А. Р. Куницын, И. К. Пискарев, Н. К. Пискарев. - М.: Норма, 2004. - 880 с.

Пример описания книги под редакцией:

Административное право Российской Федерации: учебник для вузов / под ред. Н. Ю. Хаманеева. - М.: Юристъ, 2004. - 448 с. - (Instituiones).

Описание статьи из журнала:

Анисимов А. П. Земельная политика и право современной России // Право и политика. - 2004. - № 7. С. 38-41.

Пример описания электронных ресурсов:

Большой юридический словарь [Электронный ресурс]. - Электрон. дан. и прогр. - М., 2001. - 1 электрон. опт. диск. (CD-ROM). - (Юридическая библиотека).

Пример описания сайта Интернет:

Концепция модернизации российского образования на период до 2010 г. [Электронный ресурс] // Режим доступа http://www.gnesin.ru/normativy/.

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

Защита курсовой работы

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

Защита курсовой работы проводится в виде собеседования. На защите студент должен показать знание теоретических положений выполненной работы, сделать обоснованные выводы и доказать предложенное решение практической задачи.

Оценка за выполненную курсовую работу ставится дифференцированно. Работа оценивается следующим образом:

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

оценка «хорошо» ставится, когда работа содержит несущественные ошибки или неточности или студент при защите курсовой работы допустил неточности или ошибки;

оценка «удовлетворительно» ставится, когда работа содержит ошибки и студент не может при защите убедительно обосновать сделанный проект;

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

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

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



Список рекомендуемой литературы

1. Основная литература

2. Балдин К. В. Информационные системы в экономике : учебник / К. В. Балдин, В. Б. Уткин. - 3-е изд. - М. : Дашков и К, 2007. - 395 с.

3. Вендров А. М. Проектирование программного обеспечения экономических информационных систем : учебник / А. М. Вендров. - 2-е изд., перераб. и доп. - М. : Финансы и статистика, 2008. - 544 с.

4. Кузнецов С. Базы данных: языки и модели / С. Кузнецов. - М. : Корона - Принт, 2008. - 720 с.

5. Советов Б. Я. Базы данных : теория и практика : учебник для вузов / Б. Я. Советов, В. В. Цехановский, В. Д. Чертовский. - 2-е изд., стереотипное. - М. : Высшая школа, 2007. - 463 с.

6. Дополнительная литература

7. Романов В. П. Проектирование экономических информационных систем: методологии и современные технологии : учебное пособие / В. П. Романов, Н. З. Емельянов, Т. Л. Партыка. - М. : Экзамен, 2005. - 256 с.

8. Советов Б. Я. Моделирование систем : учебник для вузов / Б. Я. Советов, С. А. Яковлев. - М. : Высшая школа, 2005. - 343 с.

9. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем : учебное пособие / А. М. Вендров. - 2-е изд., перераб. и доп. - М. : Финансы и статистика, 2006. - 192 с.

10. Грекул В. И. Проектирование информационных систем / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина / Интернет-университет информационных технологий, ИНТУИТ.ру,М.:, 2005. - 304 с.

11. Дубейковский В. И. Практика функционального моделирования с AllFusion Process Modeller / В. И. Дубейковский. - М. : Диалог - Мифи, 2006. - 464 с.

12. Диго С. Б. Базы данных: проектирование и использование : учебник для вузов / С. Б. Диго. - М. : Финансы и статистика, 2005. - 592 с.

13. Коннолли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика : пер. с англ. / Т. Коннолли, К. Бегг. - 3-е изд. - М. : Издательский дом «Вильяме», 2003.

14. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite / С. В. Маклаков. - М. : Диалог-МИФИ, 2005. - 432 с.

15. Смирнова Г. Н. Проектирование экономических информационных систем : учебник / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. - М. : Финансы и статистика, 2005. - 512 с.

16. Черемных С. В. Моделирование и анализ систем. IDEF - технологии : практикум / С. В. Черемных, И. О. Семенов, В. С. Ручкин. - М. : Финансы и статистика, 2006. - 192 с.

17. Черемных С. В. Структурный анализ систем: IDEF - технологии / С. В. Черемных, И. О. Семенов, В. С. Ручкин. - М. : Финансы и статистика, 2007.



Приложение

Темы курсовых проектов

Разработка функциональной модели бизнес-процесса «Внедрение системы управления проектами» с помощью CASE - средств».

Разработка функциональной модели бизнес-процесса «Внедрение системы автоматизированного проектирования в организации ИТ сферы» с помощью CASE - средств.

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

Моделирование бизнес-процесса «Организация повышения квалификации сотрудников предприятия».

Разработка базы данных учета трудовых договоров в организации.

Проектирование оперативной БД для торгово-закупочного предприятия.

Разработка функциональной модели бизнес - процесса «Обучение студента в ВУЗе».

Проектирование базы данных учета успеваемости студентов вуза.

Проектирование базы данных учета вакансий и безработных.

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

Проектирование хранилища данных для торгово-закупочной организации.

Моделирование бизнес-процесса «Ведение складского учета».

Моделирование бизнес-процессов отдела продаж коммерческой организации.

Разработка функциональной модели бизнес-процесса «Кредитование физических лиц».

Разработка функциональной модели бизнес-процесса «Кредитование юридических лиц».

Организация базы данных по учету кредитных договоров.

Моделирование бизнес-процессов отдела планирования коммерческой организации.

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

Организация базы данных учета выполнения договорных обязательств.

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

Разработка функциональной модели бизнес-процесса «Закупка материалов у поставщика».

Моделирование бизнес-процессов деятельности бухгалтера-материалиста.

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

Моделирование бизнес-процесса «Учет кассовых операций по поступлению наличных денежных средств».

Проектирование базы данных «Учет кассовых операций по поступлению денежных средств».

Моделирование бизнес-процесса «Организация внутрибанковских работ по финансовому мониторингу».

Проектирование информационного обеспечения финансового мониторинга в коммерческом банке.

Разработка функциональной модели бизнес-процесса «Организация финансово-хозяйственной деятельности».

Разработка функциональной модели бизнес-процессов отдела капитального строительства.

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

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

Моделирование бизнес-процесса «Деятельность юриста-консультанта».

Проектирование базы данных учета документов для юриста-консультанта.

Моделирование бизнес-процесса «Оказание электронных банковских услуг».

Разработать функциональную модель бизнес-процесса «Оказание услуги по трудоустройству кадровым агентством».

Разработать функциональную модель бизнес-процесса «Оказание услуги по трудоустройству государственной службой занятости».

Проектирование информационного обеспечения деятельности отдела маркетинга.

Разработать функциональную модель бизнес-процесса «Заключение договоров на оказание услуг связи».

Проектирование информационного обеспечения кредитования юридических лиц.

Проектирование базы данных «Кредитование физических лиц».

Разработать функциональную модель бизнес-процесса «Учет заказов на малом предприятии».

Моделирование бизнес-процесса «Формирование отчетности отдела кадров».

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

Разработка функциональной модели бизнес-процесса «Ведение кредитных историй клиентов».

Разработка информационного обеспечения для страхового агента.

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