3131
.pdfМинистерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования
«Воронежский государственный лесотехнический университет имени Г.Ф. Морозова»
АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания к практическим занятиям для студентов по направлению подготовки 27.03.05 Инноватика
Воронеж 2017
2
УДК 004
Новикова, Т.П. Архитектура информационных систем [Текст] : методические указания к практическим занятиям для студентов по направлению подготовки 27.03.05 Инноватика / Т.П. Новикова; М-во образования и науки РФ, ФГБОУ ВО «ВГЛТУ». – Воронеж, 2017. – 23 с.
Печатается по решению учебно-методического совета ФГБОУ ВО «ВГЛТУ» (протокол № ___ от «___» ___________ 2017 г. )
Рецензент: ОАО «НИИЭТ», заведующий лабораторией к.т.н. А.И. Яньков
3
ОГЛАВЛЕНИЕ |
|
Введение………………………………………………………………………... |
4 |
Практическая работа № 1……………………………………………………… |
5 |
Практическая работа № 2……………………………………………………… |
12 |
Практическая работа № 3……………………………………………………… |
15 |
Практическая работа № 4……………………………………………………… |
16 |
Библиографический список…………………………………………………… |
22 |
4
ВВЕДЕНИЕ
Дисциплина «Архитектура информационных систем» относится к факультативной части профессионального цикла основной профессиональной образовательной программы, индекс по учебному плану ФТД.2 составлена в соответствии с Федеральным государственным образовательным стандартом высшего образования по направлению подготовки 27.03.05 Инноватика (уровень бакалавриата), утвержденным приказом Министерства образования и науки Российской Федерации от 11.08.2016 № 1006 и учебным планом направления, утвержденным ректором ВГЛТУ 17.06.2016 г.
Основной целью изучения дисциплины является формирование у студентов знаний и умений использования функциональных возможностей современных информационных систем, моделирования их функционирования и реализации информационных систем в различных предметных областях.
Самостоятельная работа студентов, предусмотренная учебным планом в объеме одной зачѐтной единицы (36 академических часов), способствует развитию следующих общепрофессиональных (ОПК):
- способностью использовать инструментальные средства (пакеты прикладных программ) для решения прикладных инженерно-технических и техникоэкономических задач, планирования и проведения работ по проекту (ОПК-2).
5
Практическая работа № 1 Формализация системы.
Установление требований к разрабатываемой ИС
Целью работы является получение навыков в проведении анализа и сопровождения современных информационных систем.
Теоретический материал
Разработка информационной системы состоит из трех этапов: анализа, проектирования и реализации, в результате итеративного выполнения которых происходит пошаговое «наращивание» системы.
На этапах анализа и проектирования происходит построение архитектуры будущей информационной системы.
Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной.
Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия. В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE-средствами являются Rational Rose, BPwin, Silverrun, Process Analyst.
Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Основными задачами при моделировании предметной области являются следующие описания:
-бизнес-процессов предприятия;
-действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;
-бизнес-сущностей;
-сценариев выполнения бизнес-функций, подлежащих автоматизации;
-состояний бизнес-сущностей;
-бизнес-правил.
Описания бизнес-процессов используются для описания технологии выполнения производственной задачи, подлежащей автоматизации. На основе
6
описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе).
При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи).
При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы.
Итак, подводя итог сказанному об описании предметной области при разработке программных систем, отметим следующее:
1.Описание предметной области должно включать не только описание бизнес-процессов, но и описание структуры автоматизируемого предприятия, его действующих лиц, их автоматизируемых функций, документов, связанных
савтоматизированными функциями, прочих бизнес-сущностей, сценариев реализации бизнес-функций и состояний бизнес-сущностей.
2.Модель бизнес-процессов используется для определения бизнестребований к разрабатываемой системе и выявления всех связей между подразделениями, принимающими участие в решение конкретной задачи.
3.Модель структуры предприятия используется для отражения действующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы.
4.Модели документов, бизнес-сущностей используются при проектировании пользовательского интерфейса, базы данных, формирования альбома выходных форм системы.
5.Модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса.
6.Модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и базы данных системы.
7.Модели бизнес-правил используются при моделировании правил программной системы.
Полное и детальное описание предметной области удобно производить с помощью разнообразных CASE-средств.
Case-средства
Термин CASE - Computer Aided System/Software Engineering используется при автоматизации процесса разработки сложных информационных систем в целом. Появлению CASE-средств предшествовали исследования в области методологии проектирования. Методология определяет этапы и шаги
7
реализации проекта, а также правила использования методов, которыми разрабатывается проект. Метод - это процедура или техника генерации описаний компонентов информационной системы (проектирование потоков и структур данных). Нотация - отображение структуры системы, элементов данных с помощью специальных графических символов. CASE-средства - это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования информационных систем. CASEтехнология, в рамках методологии, включает в себя методы, с помощью которых на основе нотаций строятся диаграммы, поддерживаемые конкретным CASEсредством. CASE-технологии не могут считаться самостоятельными, они только обеспечивают высокую эффективность их применения.
Краткая характеристика
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASEсредства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Архитектура CASE-средств
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения и включающее в себя:
1. Репозиторий, являющийся основой CASE-средства. Он представляет собой специализированную базу данных проекта, предназначенную для отображения состояния проектируемой информационной системы в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. В репозитории хранятся описания следующих объектов: проектировщиков и их прав доступа к различным компонентам
8
системы; организационных структур; диаграмм; компонентов диаграмм; связей между диаграммами; структур данных; программных модулей; процедур.
2.Графический редактор, обеспечивающий создание и редактирование в заданной нотации и в интерактивном (диалоговом) режиме элементов диаграмм, связей между ними, диаграмм. В любой момент времени они могут быть распечатаны и включены в техническую документацию проекта.
3.Верификатор диаграмм (средство тестирования), служащее для контроля правильности построения диаграмм в заданной методологии проектирования. Его функции:
a) диагностика,
b) выдача сообщений об ошибках,
c) выделение на диаграмме ошибочных элементов.
4.Документатор проекта, позволяющий получать информацию о проектах в виде отчетов. Отчеты могут строиться:
a) по времени, b) автору,
c) элементам диаграмм, d) диаграмме,
e) проекту в целом.
5.Администратор проекта, выполняющий следующие функции:
a)инициализация (запуск),
b)задание начальных параметров проекта,
c)назначение и изменение прав доступа к элементам проекта.
6. Сервис, представляющий собой набор системных утилит по обслуживанию репозитория (архивация и восстановление данных, создание нового репозитория).
На рисунке 1 показана архитектура CASE-средства в общем виде.
Рис.1. Архитектура CASE-средства
9
Используемые методологии
При применении CASE-средств используются методологии структурного и объектно-ориентированного проектирования. Структурное проектирование основано на алгоритмической декомпозиции, а объектно - ориентированное проектирование основано на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое внимание объектам или субъектам действия. CASE-средства, поддерживающие объектноориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.
Представления информационной системы на языке UML:
1.Представление использования - основная часть модели описания системы.
2.Логическое представление - описание функциональных возможностей системы.
3.Компонентное представление - описание структуры и взаимосвязей модулей системы.
4.Представление взаимодействия процессов - описание согласованных действий модулей системы.
5.Представление распределения - описание физической архитектуры системы.
Каждое представление состоит из диаграмм, которые строятся из своих нотаций. Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Главным разработчиком методологии был Дуглас Росс. Он разработал язык структурного анализа, используемого для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF. Их использовали в США по предложению ВВС. В настоящее время семейство IDEF включают:
IDEF0 - стандарт функционального моделирования IDEF1X - стандарт моделирования потоков данных IDEF2 - стандарт динамического моделирования систем IDEF3 - стандарт документирования процессов IDEF4 - стандарт построения объектно-ориентированных систем IDEF5 - стандарт онтологического (принципиального, структурного) исследования систем.
Цель данных методических указаний - изучение на практике применения
впроектировании подходов и методов, позволяющих получать успешные архитектуры информационных систем. Методические указания построены по
10
принципу выдачи заданий на лабораторные работы и приведения комментариев и примеров к их выполнению.
1. Установление требований
1.1 Документ описания требований Документ, описывающий требования, является осязаемым результатом
этапа установления требований. Большинство организаций вырабатывает документ описания требований в соответствии с заранее определенным шаблоном. Шаблон определяет структуру (содержание) и стиль документа.
Ядро документа описания требований состоит из формулировок (изложения) требований. Требования могут быть сгруппированы в виде формулировок сервисов (зачастую называемых функциональными требованиями) и формулировок ограничений. Формулировки сути сервисов могут быть затем разделены на требования к функциям (function requirements) и требования к данным (data requirements). (В литературе термин «функциональные требования» (functional requirements) в широком и в узком смысле используется как взаимозаменяемый. При использовании в узком смысле он соответствует тому, что мы называем требованиями к функциям).
Не говоря уже о самих требованиях, документ описания требований должен обращаться к проектным вопросам. Обычно проектные вопросы рассматриваются в начале документа, а затем в конце документа.
Во вводной части документа рассматривается бизнес-контекст проекта, включая цель проекта, участников проекта и основные ограничения. Ближе к заключительной части документа поднимаются другие проектные вопросы, включая план-график выполнения проектных работ, бюджет, риски, документацию и т. д.
1.2Шаблоны документа
Шаблоны для документов описания требований широко доступны. Их можно найти в учебниках, стандартах, выпускаемых такими организациями как ISO, IEEE и т. д., на Web-страницах консалтинговых фирм, программных средствах разработки и т. д. Со временем каждая организация разрабатывает свои собственные стандарты, которые соответствуют принятой в организации практике, корпоративной культуре, кругу читателей, типам разрабатываемых систем и т. д.
Шаблон документа описания требований определяет структуру документа и содержит подробные указания о содержании каждого из разделов документа. Указания могут включать содержание вопросов, мотивацию, примеры и дополнительные соображения.
1.3Предварительные замечания к проекту