МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В САПР. МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Социальная среда Политическая среда Физическая среда Предприятие ПРЕДПРИЯТИЕ ВНЕШНЯЯ СРЕДА Информационные потоки международные экономические политические конкурентные технологические рыночные социальные Информационные потоки и предприятие Главная проблема любой экономики – преодоление ограниченности ресурсов. Ключевой момент – решение о том, где и как сосредоточить экономические ресурсы. Концентрация ресурсов в нужное время, в нужном месте, для решения главного, приоритетного направления – вот в чем помогает информация при принятии экономических решений. Требуемая информация рассеяна по множеству источников и мест хранения. Информация является одним из основных ресурсов роста производительности предприятия, поскольку она позволяет: - устанавливать стратегические цели и задачи предприятия и использовать открывающиеся возможности; - принимать обоснованные и своевременные управляющие решения; - координировать действия разрозненных подразделений, направляя их усилия на достижение общих поставленных целей.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Процессное управление – основа построения современных информационных систем ОРГАНИЗАЦИОННАЯ СТРУКТУРА ГОРИЗОНТАЛЬНЫЕ ПРОЦЕССЫ ВЕРТИКАЛЬНЫЕ ПРОЦЕССЫ ИНДИВИДУАЛЬНЫЕ ПРОЦЕССЫ Совокупность процессов предприятия Процессы, выполняемые подразделениями предприятий ПРОЦЕСС понимается как совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие. Индивидуальные процессы реализуются отдельно взятыми сотрудниками Функциональные или вертикальные процессы отражают характерные особенности деятельности различных отделов или подразделений организации Горизонтальные процессы пронизывают всю организацию и ориентированы на конечный результат процесса

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Системный принцип, или системный подход, - это всего лишь признание того, что объекты материального мира представляют собой системы, состоящие из частей, взаимодействующих между собой. Система (греч.) – совокупность элементов, находящихся в отношениях и связях друг с другом, которая образует определенную целостность, единство. Основные системные принципы: целостность – принципиальная несводимость свойств системы к сумме свойств составляющих ее элементов и невыводимость из последних свойств целого; зависимость каждого элемента, свойства и отношения системы от его места, функции внутри целого; структурность – возможность описания системы через установление ее структуры; обусловленность поведения системы не столько поведением ее отдельных элементов, сколько свойствами ее структуры; взаимозависимости системы и среды – система формирует и проявляет свои свойства в процессе взаимодействия со средой; иерархичности – каждый компонент системы в свою очередь может рассматриваться как система, а исследуемая в данном случае система представляет собой один из компонентов более широкой системы; множественности описания каждой системы – в силу принципиальной сложности каждой системы ее адекватное описание требует построения множества различных моделей, каждая из которых описывает лишь определенный аспект системы. Модель – это абстракция реального мира, средство отображения реальной системы, позволяющее оценивать отдельные аспекты (стороны) реального объекта СИСТЕМНЫЙ АНАЛИЗ. ОСНОВНЫЕ ПОЛОЖЕНИЯ.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин CASE (Computer Aided Software Engineering) – семейство технологий, используемых для автоматизации разработки программного обеспечения. В настоящее время термин CASE обозначает не только автоматизацию разработки программного обеспечения (ПО), но процесс сопровождения разработки информационной системы (анализ требований, проектирование прикладного ПО, тестирование и документирование ПО, контроль качества, управление проектом и т.п.). Под CASE-технологией понимается методология проектирования информационной системы (ИС) и некоторый набор инструментальных средств, позволяющий проводить анализ, моделирование и разработку ПО на всех этапах жизненного цикла ИС. Типовое CASE-средство имеет в своем составе: репозиторий, обеспечивающий хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации при групповой разработке, контроль данных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие построение моделей ИС; средства разработки приложений; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга. CASE-ТЕХНОЛОГИЯ

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин SADT (Structured Analysis & Design Technique) – методология структурного анализа и проектирования. Методология структурного анализа базируется на предположении, что любую систему можно декомпозировать на множество взаимоувязанных более мелких подсистем (функций) или задач. SADT разработана Дугласом Россом (MIT) в конце 60-х – начале 70-х гг. как механизм, способный облегчить проектирование сложных систем, учитывающий участие людей, использование машин, влияния программных продуктов и использующий такие понятия как управление, обратная связь, ресурсы. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для описания и понимания искусственных систем и основанных на концепции системного моделирования. Система понимается как совокупность взаимодействующих компонент и взаимосвязей между ними. Моделирование понимается как процесс создания точного описания системы. SADT-МЕТОДОЛОГИЯ

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин ICAM (Integrated Computer-Aided Manufacturing) – интеграция компьютерных и промышленных технологий (программа ВВС США); IDEF (ICAM DEFinition) – методы (стандарты) используются при анализе, моделировании, разработке, реинжиниринге или интеграции информационных систем, а также для проведения анализа и моделирования бизнес-процессов, в целях создания интегрированной информационной среды предприятия (организации). IDEF0 – метод (стандарт) функционального моделирования. Данный метод был разработан как строгий механизм описания функций системы через процесс функциональной декомпозиции и классификации связей между этими функциями. IDEF1 – метод информационного моделирования. Данный метод был разработан для описания информационных потоков, которые обращаются в организации. IDEF2 – метод имитационного моделирования. Данный метод первоначально разрабатывался для моделирования интерфейсов пользователя. Однако был переработан в целях моделирования, например, таких задач, как изменение поведения ресурсов в производственной системе с использованием различных математических моделей. IDEF3 – метод описания бизнес-процессов предприятия (организации). IDEF1X – метод (стандарт) моделирования данных. IDEF4 – метод объектно-ориентированного проектирования. IDEF-МЕТОДЫ

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Описание системы с помощью SADT называется моделью. Модель является некоторым толкованием системы и должна четко определять, какой(ие) аспект(ы) системы будет анализироваться и с какой степенью подробности. В SADT-методологии это реализуется с помощью цели модели в виде набора вопросов, на которые должна дать ответ строящаяся модель. Моделируемая система всегда рассматривается как открытая система. На начальной стадии анализа необходимо определить границы модели, т.е. установить, что входит в систему, а что лежит за ее пределами и не подлежит анализу. Модель должна рассматриваться все время с одной и той же позиции. Такая позиция называется «точка зрения» данной модели. Таким образом, на первом этапе построения SADT-модели необходимо определить: границы модели (определяют, что включать в модель, а что нет); точку зрения модели (позволяет осуществить выбор нужной информации о системе) – позиция, с которой описывается система; цель модели (является критерием окончания процесса моделирования) – это набор вопросов, на которые должна ответить модель. Конечным результатом SADT-моделирования является набор описаний, начиная с верхнего уровня системы и кончая подробным описанием операций системы. Каждое из таких описаний называется диаграммой. SADT-модель объединяет и организует SADT-диаграммы в иерархические структуры, в которых диаграммы более высокого уровня менее детализованы, чем диаграммы нижних уровней. SADT. Границы, точка зрения, цель модели

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Составить ежемесячный отчет по нормоконтролю документации Собрать комплект закрытых карточек за месяц Обработать результаты нормоконтроля Оформить сопроводительный документ в КОС Нормоконтролер СТП Комплект закрытых карточек за месяц Обработанн ый комплект карточек за месяц Инструкция по оформлению документов КОС Предварительный отчет нормоконтроля за месяц С1 С2 I1 I2 M1 O1 O2 СТП Инструкция по оформлению документов КОС Нормоконтролер Закрытые карточки Ежемесячный отчет Методические материалы А1 А2 А3

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Конечным результатом SADT-моделирования является набор описаний системы. Каждое из таких описаний называется диаграммой. SADT-модель объединяет и организует SADT-диаграммы в иерархические структуры, в которых диаграммы более высокого уровня менее детализованы, чем диаграммы нижних уровней. Диаграммы – главные компоненты модели; диаграммы содержат блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. На каждой диаграмме пишется стандартная информация: Используется в: - указание на родительскую диаграмму. Автор: - имя создателя диаграммы. Дата: - дата создания диаграммы. Проект: - имя проекта, в рамках которого была создана диаграмма. Пересмотр: - дата последнего редактирования диаграммы. Замечания: - используется при рецензировании диаграммы. Рабочая версия, эскиз, рекомендовано, публикация – стадии создания диаграммы (статусы). Читатель – имя рецензента (эксперта). Дата – дата рецензии (экспертизы). Контекст –схема расположения работ в диаграмме верхнего уровня. Узел – номер узла диаграммы (номер родительской диаграммы). Название – имя диаграммы – имя родительской диаграммы. Номер – С-номер, уникальный номер версии диаграммы. SADT-ДИАГРАММЫ

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин УЗЕЛ: А-0 ФУНКЦИЯ Управление Выход Вход Механизм НАЗВАНИЕ:НОМЕР: Используется в: Автор: Дата: Проект: Пересмотр: Замечания: Контекст: Рабочая версия Читатель Дата Эскиз Рекомендовано Публикация

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Функциональные блоки на диаграммах изображаются прямоугольниками. Так как блок описывает функцию, то названиями блоков служат глаголы или глагольные обороты. Каждая сторона блока имеет однозначное назначение. Левая сторона блока предназначена для входов, правая – для выходов, нижняя – для механизмов (исполнителей), верхняя – для управления. Для облегчения процесса анализа на одной диаграмме должно быть от 3-х до 6-ти блоков. Блоки размещаются по степени важности (с точки зрения автора). Такой порядок называется доминированием, которое принято показывать графически (в виде «ступенчатой» схемы), и с помощью цифр (номера блока), размещаемых в правом нижнем углу блока. Дуги на SADT-диаграммах рисуются одинарными линиями со стрелками на концах. Дуги отображают объекты и обозначаются существительными или существительными с определениями. Входные дуги изображают объекты, используемые и преобразуемые функциями. Выходные дуги изображают объекты, в которые преобразуются входы. Дуги управления отображают информацию, управляющую действиями функций. Дуги механизмов отображают с помощью каких ресурсов (как правило физического характера) выполняются функции. SADT-ДИАГРАММЫ. БЛОКИ. ДУГИ.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин SADT. ДЕКОМПОЗИЦИЯ. Процесс последовательной детализации блоков, выполняемый по определенным формальным правилам, называется декомпозицией.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Для проведения анализа используется только пять типов взаимосвязей между блоками. Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием. Отношение входа возникает тогда, когда выход одного блока становится входом для блока с меньшим доминированием. Обратная связь по управлению и обратная связь по входу представляют итерации или рекурсивность. Обратная связь по управлению возникает тогда, когда выход некоторого блока влияет на блок с большим доминированием. Обратная связь по входу имеет место тогда, когда выход одного блока становится входом другого блока с большим доминированием. Связь типа «выход-механизм» отображает ситуацию, при которой выход одной функции становится ресурсом для выполнения другой функции. SADT. ТИПЫ ВЗАИМОСВЯЗЕЙ. А1 А2 А1 А2 А4 А2А1 А2 А1 А2

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин SADT-методология имеет соглашения, касающиеся представления и описания разветвлений и соединений дуг. Разветвления дуг изображаются в виде расходящихся линий и означают, что весь набор объектов или какая-то его часть появятся в каждом ответвлении дуги. Дуга всегда помечается до разветвления, а каждая ветвь дуги помечается или нет в соответствии со следующими правилами: непомеченные ветви содержат весь набор объектов, указанный до разветвления; ветви, помеченные после разветвления, уточняют, что именно содержит ветвь, и должны содержать весь набор объектов или его часть, указанный до разветвления. Слияния дуг изображаются в виде сходящихся линий и означают, что содержимое каждой ветви идет на формирования нового набора объектов. Дуга всегда помечается после слияния, а каждая ветвь дуги помечается или нет в соответствии со следующими правилами: непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей); помеченные перед слиянием ветви ясно указывают, что именно содержит ветвь и должны содержать весь набор объектов или его часть, указанный после слияния. SADT. ПРЕДСТАВЛЕНИЕ ДУГ.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Толкование Обозначение A B A + B B A A B A A A A A B A A A A A SADT. ПРЕДСТАВЛЕНИЕ ДУГ.

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин SADT. ICOM - КОДЫ Собрать комплект закрытых карточек за месяц Обработать результаты нормоконтроля Оформить сопроводительный документ в КОС Нормоконтролер СТП Комплект закрытых карточек за месяц Обработанн ый комплект карточек за месяц Инструкция по оформлению документов КОС Предварительный отчет нормоконтроля за месяц С1 С2 I1 I2 M1 O1 O2 СТП Инструкция по оформлению документов КОС Нормоконтролер Закрытые карточки Ежемесячный отчет Методические материалы А1 А2 А3 С1 С2 I1 I2 M1 O1 O2

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) © Л. Корякин Процесс построения модели в SADT Собрать материал по задаче Создать модель Рецензи- ровать модель Эксперт План и цель проекта Автор Факты, данные о субъекте модели Диаграммы, отчеты, описания Утвержден- ная модель Знания, инфор- мация А1 А2 А3 Потребность в информации Принять модель Готовая модель А4 Модель с замечаниями Рецензент Модель с замечаниями Комитет контроля