logo search
GOSy_raspredelenie_otvety_10_06_11_v_7-ITOG

2. Объектно-ориентированный подход

Сущность подхода

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

Ответ Милы

+ дополнительно см. вопрос 11.

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

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

Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки программного обеспечения (ПО) и системы в целом. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ:

Задачная модель

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

Общий вывод: достаточно большую эффективную ИС таким способом создать невозможно.

Каскадная модель

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

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

Рис. 1. Каскадная схема разработки

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Спиральная модель

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [1] (рис. 3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 3. Спиральная модель ЖЦ ИС

 

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

Основные принципы методологии RAD:

Последовательность этапов создания ИС на фазе определения требований и анализа:

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Результатами проектирования архитектуры являются:

модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Типовой процесс разработки и внедрения информационной системы включает следующие этапы: (ссылка на подробное описание процесса внедрения)

Основные функции, выполняемые с помощью CASE-средств:

Последовательность разработки информационных систем:

а) каскадная схема; б) спиральная схема; в) макетная схема

Ответ прошлых лет (Ден)

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

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

  1. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

  3. Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.

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

  5. Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

  7. Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.

19. Проектирование ИС []

Билет №

Формулировка ответа

Преподаватель

Кто делает ответ

Состояние

19

11.2.

Проектирование информационных систем. Инфраструктура ИС. Платформы ИС.

Алексеев Пётр Сергеевич

Саша Хохрина

ОПЛ (Ден), готовый ответ Саши Хо

Готовый ответ Саши Хо

Инфраструктура ИС

Определения

Инфраструктура

Определение из Википедии:

Инфраструктура - комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы.

По ГОСТ Р 53114-2008 «Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения»:

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

Информационная инфраструктура

По ГОСТ Р 53114-2008

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

Объект информатизации – совокупность информационных ресурсов, средств и систем обработки информации, используемых в соответствии с заданной информационной технологией, а также средства их обеспечения, помещений или объектов (зданий, сооружений, технических средств), в которых эти средства и системы установлены, или помещений и объектов, предназначенных для ведения конфиденциальных переговоров (по ГОСТ Р 51275-2006 «Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения»)

Информационная инфраструктура:

Из Википедии:

В качестве примеров информационной инфраструктуры можно привести такие общеизвестные сферы нашей жизни как:

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

Science Citation Index – это индекс цитирования, введенный в 1961 году и охвативший на тот момент информацию порядка 600 журналов. Сегодня данный индекс является одним из крупнейшим и охватывает более 16 000 источников информации.

STN (Scientific and Technical Network) – европейская база данных, содержащая более 10 млн документов по самым разным наукам: физика, биофизика, химия, технологии, медицина и др. База является одной из самых крупных в мире.

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

В России большой вклад в развитие информационной инфраструктуры вносят компании из сферы телекоммуникационного бизнеса. Например, оператор связи “МегаФон” инвестирует в развитие сети Центров обработки данных. Этот же оператор приобрел одного из крупнейших операторов фиксированной связи, что позволит создать единую магистральную сеть протяженностью более 100 тыс. км. вместе с обширной спутниковой инфраструктурой.

Инфраструктура ИС

Определение из http://ssofta.narod.ru/bd/ets2.htm

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

Таким образом, к инфраструктуре  следует отнести:

Определение с http://www.sb-serv.ru/itinfrastructure.html (ссылка на сохранённую копию ниже)

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

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

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

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

ИТ-инфраструктура  должна соответствовать трем параметрам: доступности, надежности и безопасности:

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

Основные этапы создания ИТ инфраструктуры (с сайта компании, предоставляющей данные услуги):

Примечание Саши: Как я понимаю, смысл информационной инфраструктуры и инфраструктуры ИС похож, но ИИ глобальна, а ИИС локальна.

Архитектура ИС

По ГОСТ Р ИСО 15704-2006 «Промышленные автоматизированные системы. Требования к стандартным архитектурам и методологиям предприятия»:

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

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

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

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

Архитектура ИС конструктивно обычно определяется как набор ответов на следующие вопросы:

что делает система;

на какие части она разделяется;

как эти части взаимодействуют;

где эти части размещены1.

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

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

Прикладная архитектура включает в себя:

Архитектура данных включает в себя:

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

Сетевая архитектура включает в себя:

Архитектура платформ включает в себя:

Платформа ИС

Определение с сайта Аналитика СЭД

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

Из статьи ERP: ПРОДУКТ ИЛИ ПЛАТФОРМА? (http://www.iteam.ru/publications/it/section_54/article_1843/)

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

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

Задачей этой статьи не является сравнение платформы и продукта и тем более доказательство превосходства одного подхода над другим. Довольно часто предприятия выбирают между двумя-тремя предлагаемыми им ERP-системами, и почти всегда оказывается, что часть из них ближе к продукту, часть - к платформе. Объясняя выбор "продуктовой" системы, представители ИТ-служб предприятий часто прибегают к четырем аргументам, перечисленным ниже:

Тем не менее, "продукт-ориентированные" аргументы не всегда определяют однозначный выбор продукта.

Примерами платформ, для развёртывания ИС могут быть:

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

Представители: зарубежные компании - BusinessObjects (www.businessobjects.com), Cognos (www.cognos.com), MicroStrategy (www.microstrategy.com), Oracle (www.oracle.com), SAS (www.sas.com), Microsoft (www.microsoft.com), Hyperion (www.hyperion.com), а также российские разработчики - фирмы BaseGroup Labs (www.basegroup.ru) с пакетом Deductor и Intersoft Lab (www.iso.ru) с платформой хранилищ данных и аналитической платформой “Контур”. 

Платформы построения ECM-систем и СЭД: платформы и приложения, на базе которых можно строить корпоративные системы (и системы электронного документооборота в частности): SharePoint, офисные пакеты, .NET, Java 2 EE, веб-платформы. Примеры разработчиков таких платформ -  EMC, Oracle, Microsoft,  1С

Платформы построения учётных ИС (ERP)

Сохранённая ссылка:

http://webcache.googleusercontent.com/search?q=cache:7VEtiIbaL0UJ:www.sb-serv.ru/itinfrastructure.html+%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0+%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9+%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B&cd=20&hl=ru&ct=clnk&gl=ru&source=www.google.ru

Ответ прошлых лет (Ден)

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

Информационная инфраструктура:

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

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

Качественная инфраструктура информационных систем – это такая система, которая обеспечивает всего три ключевых момента:

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

Надежность – это понятие несколько шире, чем «у-нас-все-всегда-исправно». Так попросту не бывает: все, что может сломаться – обязательно рано или поздно сломается. Другое дело, что это не должно стать катастрофой для вашего бизнеса. Что бы не случилось, пользователь не должен замечать всех этих проблем – данные не исчезнут, базы данных останутся в работе, обмен сообщениями продолжится.

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

Вопрос по платформам открыт

20. Проектирование ИС []

Билет №

Формулировка ответа

Преподаватель

Кто делает ответ

Состояние

20

2.2., 32.3., 35.3., 38.3.,  42.2.

Проектирование информационных систем. Особенности методологии SADT. Основные виды диаграмм. Требования ГОСТ P 50.1.028 - 2001.

Маятин Александр Владимирович

Аня

Тарасова

ОПЛ (Ден), ОПЛ (Мадина), готовый ответ Милы

Готовый ответ Милы

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом в 1969-1973 годах. Технология изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. SADT - одна из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта - IDEF0 (Icam DEFinition) - часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.

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

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

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

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

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

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

Каждый блок на диаграмме имеет свой номер.

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

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

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

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

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

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

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

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

Различают в IDEF0 пять типов связей работ.

Связь по входу (input-output), когда выход вышестоящей работы направляется на вход следующей работы.

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление следующей работы. Связь показывает доминирование вышестоящей работы.

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Используется для описания циклов.

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

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

Из перечисленных блоков, как из отдельных кирпичиков, строится диаграмма. Пример SADT-диаграммы: