Лекции - Управление жизненны циклом ИС

Подождите немного. Документ загружается.

15. Основные элементы IDEF0-диаграмм

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат

четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок

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

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

каждого функционального блока должно быть сформулировано в глагольном наклонении (например,

“производить услуги”, а не “производство услуг”).

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также

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

элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние

на функцию, отображенную данным функциональным блоком.

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).

Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его

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

модели.

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

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

усваиваемой.

Модель IDEF0 всегда начинается с представления системы как единого целого – одного

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

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

обозначается идентификатором “А-0”.

IDEF0 сочетает в себе небольшую по объему графическую нотацию (систему обозначений,

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

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

Модель IDEF0 состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг

на друга. Диаграммы - главные компоненты модели, все функции информационной системы и

интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип

интерфейса.

Одной из наиболее важных особенностей методологии IDEF0 является постепенное

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

В основе методологии IDEF0 лежат следующие основные понятия: цель моделирования,

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

Цель моделирования (Purpose). Модель должна строиться при ясном осознании объекта и

целей моделирования. Выбранное определение цели моделирования должно отвечать на

следующие вопросы:

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

что выявит данная модель;

какие результаты может принести применение данной модели.

Границы моделирования. Границы моделирования предназначены для обозначения ширины

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

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

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

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

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

модели.

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

Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации

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

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

что для модели является входом и что - выходом.

Точка зрения (Viewpoint). Под точкой зрения понимается перспектива, с которой наблюдалась

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

границы моделирования и назначение модели. Однажды выбранная точка зрения остается

неизменной для всех элементов модели. При необходимости могут быть созданы другие модели,

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

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

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

наименование должности, подразделения или роли (например, руководитель отдела или менеджер

по продажам). Как и в случае с определением цели моделирования, четкое определение точки

зрения необходимо для обеспечения внутренней целостности модели и предотвращения

постоянного изменения ее структуры.

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

входные параметры (сырье, информацию и т.п.) в выходные. Поскольку модели IDEF0

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

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

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

(Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 1) и

олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По

требованиям стандарта название каждого функционального блока должно быть отглагольным

существительным (например, "производить услуги", а не "производство услуг"). Важно подбирать

имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки

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

своё определенное значение (роль).

Верхняя сторона имеет значение "Управление" (Control) - стрелки сверху, означающие, на

основании чего выполняется данный процесс: законы, стандарты, приказы и т.д.

Левая сторона имеет значение "Вход" (Input) - стрелки слева, означающие данные или

объекты, потребляемые или изменяемые процессом

Правая сторона имеет значение "Выход" (Output) - стрелки справа, означающие основные

результаты деятельности процесса, конечные продукты.

Нижняя сторона имеет значение "Механизм" (Mechanism) -стрелки снизу, означающие,

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

ресурсы, необходимые для процесса.

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь

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

Интерфейсные дуги (Arrow). Интерфейсные дуги также называют потоками или стрелками.

Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая

интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованиям

стандарта наименование должно быть существительным (например, готовое изделие, заказ, сырье).

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

иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это объясняется

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

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

никакого смысла.

16. Основные элементы IDEF3-диаграмм

IDEF3 — методология моделирования и стандарт документирования процессов,

происходящих в системе. Метод документирования технологических процессов предоставляет

механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-

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

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

IDEF3 широко применяется при разработке информационных систем. При этом используется

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

Два типа диаграмм в IDEF3

Система описывается как упорядоченная последовательность событий с одновременным

описанием объектов, имеющих отношение к моделируемому процессу.

IDEF3 состоит из двух методов. Process Flow Description (PFD) - Описание технологических

процессов, с указанием того, что происходит на каждом этапе технологического процесса. Object

State Transition Description (OSTD) - Описание переходов состояний объектов, с указанием того,

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

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

нотации IDEF3 может содержать два типа диаграмм:

 диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams,

PFDD)

 диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN)

[править]

Компоненты диаграммы описания процесса

Диаграмма IDEF3 Process Flow Description может состоять из 5 основных описательных

блоков:

 работы (boxes, activities)

 стрелки или связи (arrows, links)

 перекрёстки (junctions)

 объекты ссылок

17. Основные элементы DFD-диаграммы

DFD – диаграммы потоков данных

В соответствии с DFD (Data Flow Diagram) методологией, модель системы определяется как

иерархия диаграмм потоков данных, описывающих процессы преобразования информации от

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

иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние

входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются

при помощи диаграмм следующих уровней.

Элементы DFD диаграмм

Основными элементами диаграмм потоков данных являются:

 внешние сущности;

 процессы;

 накопители данных;

 потоки данных.

Внешние сущности

Под внешней сущностью (External Entity) понимается материальный объект, являющийся

источником или приемником информации. В качестве внешней сущности наx DFD диаграмме могут

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

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

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

нотациях «Yourdon and Coad Process Notation» и «Gane and Sarson Process Notation».

Рис. 1. Символы внешних сущностей

Определение некоторого объекта в качестве внешней сущности указывает на то, что он

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

Процессы

Процессы представляют собой преобразование входных потоков данных в выходные в

соответствии с определенным алгоритмом. В реальной жизни процесс может выполняться

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

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

логическим устройством и тому подобное.

Процессы на диаграмме потоков данных изображаются, как показано на рисунке 2.

Рис. 2. Символы процессов

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

процесса в виде предложения с глаголом в неопределенной форме (вычислить, рассчитать,

проверить, определить, создать, получить) и поясняющими существительными, например:

«Напечатать адрес получателя», «Акцептовать счет».

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

сотрудник, программа или аппаратное устройство выполняет данный процесс. Если такое поле

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

В отличие от IDEF0 диаграмм, в DFD диаграммах не используются стрелки управления для

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

ресурсов.

Накопители данных

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

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

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

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

символы для их обозначения показаны на рисунке 3.

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

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

точки зрения аналитика, отражающее информационную сущность содержимого, например,

«Поставщики», «Заказчики», «Счета-фактуры», «Накладные». Символы накопителей данных в

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

Потоки данных

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

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

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

имя, отражающее его содержание. Пример типичной потоковой диаграммы показан на рисунке 4.

18. Словарь данных DFD-диаграмм

Поддержка Словаря Данных: Design/IDEF имеет встроенный Словарь Данных, который

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

Словарь дает возможность определять начальную информацию об объектах и предоставляет

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

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

неограниченное число параметров для каждого объекта. В сочетании с высококачественной

печатью на лазерном принтере, это позволяет разработчику создавать документацию проекта,

отвечающую самым высоким требованиям.

Создается словарь данных ( Data Dictionary ), в котором хранится и анализируется состав

потоков и накопителей данных, взаимосвязь отдельных элементов потоков и накопителей данных.

Например, при моделировании документооборота вводятся сведения о структуре и реквизитном

составе документов.

19. Спецификации процессов DFD-диаграмм

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков

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

отношению к системе источники и адресаты данных, логические функции, потоки данных и

хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов

структурного анализа и проектирования информационных систем, существовавших в

"доюмээльную" эпоху. Несмотря на имеющее место в современных условиях смещение акцентов от

структурного к объектно-ориентированному подходу к анализу и проектированию систем,

"старинные" структурные нотации по-прежнему широко и эффективно используются как в бизнес-

анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации -

Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной

ниже иллюстрации использована нотация Гейна-Сарсона.

Информационная система принимает извне потоки данных. Для обозначения элементов

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

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

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

данных, передаваться к внешним сущностям.

Модель DFD, как и большинство других структурных моделей - иереархическая модель.

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

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

диаграмме. Когда достигнута требуемая глубина декомпозиции - процесс нижнего уровня

сопровождается мини-спецификацией (текстовым описанием).

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты

разрабатываемой системы.

Нотация DFD - удобное средство для формирования контекстной диаграммы, т.е. диаграммы,

показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего

уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где

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

при формировании контекстной диаграммы - диаграмма SADT1), диаграмма Диаграмма вариантов

использования.

20. Диаграммы "сущность-связь"

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-

relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы.

Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с

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

данных.

Наиболее распространенным средством моделирования данных являются диаграммы

"сущность-связь" (ERD), нотация которых была впервые введена Питером Ченом в 1976 г . и

получила дальнейшее развитие в работах Ричарда Баркера.

Методология IDEF 1Х была разработана для армии США и широко используется в

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

методологии IDEF 1, но в большей мере ориентирована на автоматизацию и более проста для

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

приведенной к третьей нормальной форме.

Нотация Чена

Связь соединяется с ассоциируемыми сущностями линиями. Возле каждой сущности на

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

Нотация Мартина

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

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

месте соединения с сущностью определяет кардинальность связи

Нотация IDEF1X.

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

составляющие ключ сущности, группируются в верхней части прямоугольника и отделяются

горизонтальной чертой.

Нотация Баркера.

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

Ключевые атрибуты отмечаются символом # (решетка). Связи обозначаются линиями с именами,

место соединения связи и сущности определяет кардинальность связи

Сущность (Entity) - любой объект, событие или концепция, имеющие существенное значение

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

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

(Relationship) - поименованное логическое соотношение между двумя сущностями, значимое для

рассматриваемой предметной области.

Атрибут (Attribute) - любая характеристика сущности, значимая для рассматриваемой

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

количественной характеристики или выражения состояния сущности.

Связи (логические отношения между сущностями) именуются глаголами или глагольными

фразами. Имена связей выражают некоторые ограничения или бизнес-правила и облегчают чтение

диаграмм.

21. Основные принципы структурного программирования.

Структу

рное программи

рование — методология разработки программного обеспечения, в

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

Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.

В соответствии с данной методологией:

 Любая программа представляет собой структуру, построенную из трёх типов

базовых конструкций:

последовательное исполнение — однократное выполнение операций в том порядке, в

котором они записаны в тексте программы;

ветвление — однократное выполнение одной из двух или более операций, в зависимости от

выполнения некоторого заданного условия;

цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое

заданное условие (условие продолжения цикла).

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

но никаких других средств управления последовательностью выполнения операций не

предусматривается.

 Повторяющиеся фрагменты программы (либо не повторяющиеся, но

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

н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо

помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При

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

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

 Разработка программы ведётся пошагово, методом «сверху вниз».

Сначала пишется текст основной программы, в котором, вместо каждого связного логического

фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент.

Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые

ничего не делают. Полученная программа проверяется и отлаживается. После того, как

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

общая структура программы верна), подпрограммы-заглушки последовательно заменяются на

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

основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки»,

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

разработки программист одновременно имеет дело с обозримым и понятным ему множеством

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

верна. При сопровождении и внесении изменений в программу выясняется, в какие именно

процедуры нужно внести изменения, и они вносятся, не затрагивая части программы,

непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и

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

вне зоны внимания программиста.

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

 Структурное программирование позволяет значительно сократить число вариантов

построения программы по одной и той же спецификации, что значительно снижает сложность

программы и, что ещё важнее, облегчает понимание её другими разработчиками.

 В структурированных программах логически связанные операторы находятся визуально

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

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

 Сильно упрощается процесс тестирования и отладки структурированных программ.