Шпаргалка по "Корпоративным сетям"

Автор работы: Пользователь скрыл имя, 23 Апреля 2015 в 02:26, шпаргалка

Описание работы

1) Время жизни, жизненный цикл информационной системы. Назначение и особенности применения стандартов жизненного цикла информационной системы (ГОСТ Р ИСО/МЭК 12207- 99, ГОСТ Р ИСО/МЭК 12588 - 2005, ГОСТ 34.601- 90)
Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т. д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

Файлы: 1 файл

Ответы.docx

— 1.30 Мб (Скачать файл)

-     Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

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

-     Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры. 

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

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

2.             Идентификация внешних объектов, с которыми система должна быть связана.

3.             Идентификация основных  видов информации, циркулирующей между   системой и внешними объектами.

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

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

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

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

8.             Проверка основных требований по DFD первого уровня.

9.             Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10.         Проверка основных требований по DFD соответствующего уровня.

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

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

13.         После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.

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

Основные символы

1. Процесс

2.      Поток данных

3.     Хранилище данных

4.      Источник / приемник информации

5.      Сущность

Нет

6.      Чтение /запись

Нет

7.      Группировка (сцепление) потоков

8.      Разгруппировка

9.      Неиспользуемый узел

10.  Узлы-предки (наследование узлов)


 

 

12. Построение функциональной  модели информационной системы  с помощью методики IDEF0

Метод SADT (IDEF0) (Structured Analysis and Design Technique) считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом: 
1. Верхний уровень модели должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.  
2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи. В случае большого их количества некоторые из них можно вынести на третий уровень модели. Но в любом случае под виды деятельности необходимо отводить не более двух уровней модели.  
3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций — совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.  
4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.

Основные элементы этого метода основываются на следующих концепциях: 
• Графическое представление блочного моделирования.

• Строгость и точность.

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

Состав функциональной модели

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

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: 
• Верхняя сторона имеет значение “Управление” (Control); 
• Левая сторона имеет значение “Вход” (Input); 
• Правая сторона имеет значение “Выход” (Output); 
• Нижняя сторона имеет значение “Механизм” (Mechanism).

 
Рисунок 1. Функциональный блок и интерфейсные дуги

Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. 
На Рис. 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме. 
Рисунок 2. Структура SADT-модели. Декомпозиция диаграмм

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

Стратегии декомпозиции 
При построении иерархии диаграмм используются следующие стратегии декомпозиции:

• Функциональная декомпозиция — декомпозиция в соответствии с функциями, которые выполняют люди или организация.

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

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

Опыт показал, что для отдельной модели, которая создается независимо от какой-либо другой модели, декомпозиция одного из ее блоков должна прекращаться, если: 
• Блок содержит достаточно деталей.

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

• Необходимо изменить точку зрения, чтобы детализировать блок.

• Блок очень похож на другой блок той же модели или на блок другой модели.

• Блок представляет тривиальную функцию.

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

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

Существенные взаимодействия между действиями изображаются с помощью связей. Все связи в IDEF3 являются однонаправленными.

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

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

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

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

Соединение (перекрестки) разбивают или соединяют внутренние потоки и используются для изображения, ветвления процесса. Различают разворачивающиеся соединения и сворачивающиеся перекрестки (объединяют потоки). Перекрестки различают по типам:

X – исключающее ИЛИ

О – логический ИЛИ

|&|- логическое И

Перекрестки делятся:

синхронные и асинхронные

Разделение перекрестков типа О (или) , |&|(и) позволяет описать процесс асинхронизации времени активации.

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

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

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

График запуска – это визуальное отображение временной последовательности выполнения функций элементов.

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

14Построение информационной модели информационной системы с помощью методики IDEF1

Методология IDEF1X моделирования данных.

Метод IDEF1X, входящий в семейство стандартов IDEF, использует разновидность модели «сущность-связь» и реализован в ряде распространенных CASE-срсдств (в частности, ERwin).

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

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

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

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

Информация о работе Шпаргалка по "Корпоративным сетям"