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

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

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

Министерство образования Нижегородской области

Государственное бюджетное образовательное учреждение высшего образования

Нижегородский государственный инженерно-экономический университет (ГБОУ ВО НГИЭУ)

Институт: Информационные технологии и системы связи

Кафедра: Информационные системы и технологии

КОНТРОЛЬНАЯ РАБОТА

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

Аббясов Р.З.

г. Княгинино

2018 г.

Содержание

• Введение
• 1. Что такое концептуальная модель ИС
• 2. Виды связей в концептуальной модели ИС
• 3. Виды концептуальной модели

4. Пример создания концептуальной модели информационной системы

• Заключение
• Список литературы


Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи работы: информационная система связь

- дать определение, что такое концептуальная модель;

- какие виды связей концептуальной модели ИС существуют;

- разобрать виды концептуальной модели;

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

1. Концептуальная модель информационной системы

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

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

Концептуальная модель преследует следующие цели:

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

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

Разработка концептуальной модели

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

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

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

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

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

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

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

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

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

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

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

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

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

Семантическую основу ER-модели составляют следующие предположения:

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

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

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

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

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

2. Виды связей в концептуальной модели ИС

Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.

Существует 4 типа связей:

1. «Один-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

Пример: У любого конкретного ученика может быть только одна характеристика, и эта характеристика относится к единственному ученику.

2. «Один-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.

Пример: Ученику ставят много оценок; поставленная оценка принадлежит только одному ученику.

3. «Многие-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

Суть отношений двух объектов отражается в имени связи.

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

4. «Многие-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

Пример: Ученик Иванов учится у нескольких преподавателей. И каждый преподаватель работает со многими учениками.

3. Виды концептуальной модели

Концептуальная модель может переносится в модель данных, совместимую с выбранной СУБД.

Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели.

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

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

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

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

4. Пример создания концептуальной модели информационной системы

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

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

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

ERWin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях

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

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

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

- выдача книг

- составление отчетов

- возврат книг

- создание актов

Рисунок 1 - Диаграмма вариантов использования ИСУ «Библиотека»

Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения.

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

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

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

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

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

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

Таблица 1 - Связи диаграммы классов

На диаграмме классов представлен пример «Автоматизированное рабочее место библиотекаря» и изображены следующие элементы (таблица 2):

Таблица 2 - Элементы диаграммы классов

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

Рисунок 2 - Диаграмма классов ИСУ «Библиотека»

Заключение

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

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

Список использованной литературы

1. Бойко В.В., Савинков М.В. Проектирование БД информационных систем/ В.В. Бойко, М.В. Савинков - М: «Финансовая статистика», 2014г. - 351с.

2. Гофман В.Э., Хомоненко А.Д. Работа с БД/ В.Э. Гофман, А.Д. Хомоненко - спб.:,БХВ - Петербург,2013. 656с.

3. Диго, С.М. Проектирование и использование БД: Учебник для студентов вузов [Текст]. М.: Финансы и статистика, 2014. - 364 с.

4. Маклаков, С.В. Bpwin и Erwin. CASE- средства разработки информационных систем [Текст]. - М.: "ДИАЛОГ - МИФИ ", 2013. - 256с.

5. Смирнов Г.Н. и др. Проектирование экономических информационных систем./ Г.Н. Смирнов - М.: финансы и статистика,2014.-512с.

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