
- •Объектно–ориентированное проектирование.
- •Компонентный подход к проектированию
- •Аспектно–ориентированное программирование (аоп).
- •Генерирующее (порождающее) программирование
- •Агентное программирование.
- •Семейство систем Borland alm, дополняющее .Net Framework
- •Ответы на 14/15/16/17
- •Преимущества использования компонентной архитектуры:
- •Основные понятия com-технологии
- •Структура компонентов com
- •Традиционные методы доступа к сервисам приложений
- •Доступ к сервисам приложений с использованием com.
- •Серверы com.
- •Клиенты com
- •Использование технологии com.
- •Библиотека com
- •Расширения com
- •Общие сведения о семействе методологий ideFx
Общие сведения о семействе методологий ideFx
Одними из первых важность наличия семантических моделей представления информации осознали руководители BBC США еще в середине семидесятых годов минувшего столетия. В тот период американские BBC осуществляли реализацию программы ICAM (программы интегрированной компьютеризации производства). Целью данной программы являлось повышение продуктивности производства посредством систематического внедрения компьютерных технологий. Повышение продуктивности производства в рамках программы ICAM потребовало совершенствования способов анализа и передачи информации. В результате был разработан ряд методов информационного моделирования, известных ныне как IDEF-методология (ICAM DEFinition).
Семейство методов информационного моделирования производственных систем IDEF состоит из трех методологий, основанных на графическом представлении моделируемых объектов:
Методология IDEF0 - используется для создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции;
Методология IDEF1 - применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды;
Методология IDEF2 - позволяет построить динамическую модель меняющегося во времени поведения функций, информации и ресурсов производственной системы или среды.
Каждая из этих трех моделей или любое их сочетание позволяет сформировать "архитектуру" среды моделируемой системы.
Назначение модели, определенной как "архитектура", заключается в том, что она графически представляет основные взаимоотношения в среде моделируемой системы: функциональные связи, идентификацию информационных потоков (общих, разделяемых и дискретных), а также динамическое взаимодействие ресурсов.
IDEF является методологией, "архитектура" является содержанием, а повышение производительности - целью, ради которой в американской аэрокосмической промышленности была инициирована программа ICAM.
Следует отметить, что все вышеописанные методологии уже достаточно долгое время активно используются большинством развитых стран в передовых наукоемких отраслях промышленности, а также в финансовой и банковской сферах для интенсификации промышленных и финансовых процессов. Они широко применяются в этих сферах для моделирования соответствующих им систем и объектов с целью их дальнейшего совершенствования.
Ответы на 39/40/41/42
43/////////////////////////////////////////////////////43////////////////////////////////////////////////////////////////////43//////////////////////////////////////////////////////////////////////////////43
Целью программы ICAM также явилась и разработка "основных подсистем общего назначения", которые могут использоваться большим числом компаний для достижения значительного прогресса в промышленности. Эти "подсистемы" обеспечивают выполнение общих производственных функций. Такая крупномасштабная цель нуждалась в некотором связующем базисе, вокруг которого осуществлялось бы планирование, разработка и внедрение подсистем в отдельных аэрокосмических компаниях. Этот базис был назван "архитектурой производства". Для разработки "архитектуры производства" нужен был язык, с помощью которого можно описывать функционирование современной аэрокосмической промышленности. В качестве выразительного языка был выбран "метод блочного моделирования" (в котором "блок" определен как производственная ячейка или функциональная единица). Для своего успешного применения любой подобный язык должен удовлетворять следующим описанным ниже критериям.
Так как целью архитектуры является описание производства, язык должен быть в состоянии выражать производственные операции естественным и несложным образом. Поскольку моделируемый субъект является весьма обширным и сложным, язык должен быть кратким и обеспечивать простой и быстрый поиск интересующих деталей. Так как язык используется широкой аудиторией, он должен обеспечивать взаимодействие как системных аналитиков, так и конечных пользователей. Язык должен служить базой для планирования общих подсистем, их разработки и внедрения, поэтому он обязан обеспечивать достаточную строгость и точность, чтобы избежать получения неверных результатов. Поскольку предпочтительным является представление некоторой отрасли промышленности в целом, а не какой-либо отдельной компании или промышленного подразделения, методология должна включать средства отделения "организационной" структуры от "функций". Это означает, что общие соглашения могут быть достигнуты только в том случае, когда различия в организационных структурах отдельных компаний не принимаются в расчет, а рассматриваются только общие функциональные связи.
44///////////////////////////////////////////////////////////////////////////////////////4///4///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////44
Именно для моделирования функций производственной системы или среды и служит методология IDEF0. Рассмотрим подробнее некторые из основополагающих черт логики ее построения.
Во-первых, это графическое представление блочного моделирования. Графика "блоков и дуг" IDEF0-диаграммы отображает производственную операцию в виде блока, а интерфейсы входа/выхода "в/из операции" представляются дугами, соответственно входящими в блок и выходящими из него. Для того, чтобы иметь возможность описывать производственные операции, существующие в реальности, было предложено описывать взаимодействие блоков друг с другом посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом операции выполняются и управляются.
Во-вторых, это краткость. Документация архитектуры производственной системы для полноценного охвата материала должна быть
точной. Многочисленные характеристики обычных языковых текстов не удовлетворяют данному требованию. Двумерная же форма графического языка имеет требуемую точность без потери возможности выразить такие взаимоотношения, как интерфейс, обратная связь, ошибочные пути.
В-третьих, это улучшенная передача информации. В IDEF существует ряд средств, разработанных специально для улучшения передачи информации:
· диаграммы, основанные на очень простой графике блоков и дуг;
· метки на естественном языке для описания блоков и дуг, а также глоссарий и сопроводительный текст для определения точного значения элементов диаграммы;
· постепенное представление деталей, при котором на верхнем уровне иерархии показаны основные функции, а на следующих уровнях происходит их более подробное уточнение;
· схема узлов в иерархии диаграмм, обеспечивающая возможность легко составить перечень (индекс) размещенных на них деталей;
· ограничение каждой диаграммы шестью подфункциями для облегчения чтения.
В-четвертых, это строгость и точность. Выполнение правил IDEF0 требует достаточной строгости и точности в работе, чтобы удовлетворить принципам архитектуры ICAM, не накладывая в то же время чрезмерных ограничений на аналитика.
В-пятых, это соблюдение методологии моделирования. Пошаговые процедуры обеспечивают моделирование, рецензирование и решение задач итерации. Существуют и соответствующие курсы для обучения персонала аэрокосмической промышленности этим методам.
В-шестых, это отделение понятия "организация" от "функций", ею
выполняемых. Отделение организации от функций включено в цель модели и осуществляется с помощью отбора имен функций и связей в процессе разработки модели. Это положение лежит в основе IDEF0-методологии, а постоянное рецензирование в ходе создания модели помогает избежать точки зрения, навязанной организацией.
Методология IDEF0 может использоваться для моделирования круга систем, где под системой понимается любая комбинация средств аппаратного и программного обеспечения, а также людей. Результатом применения методологии IDEF0 является модель. Модель состоит из диаграмм, фрагментов текста и глоссария, которые имеют ссылки друг на друга. Причем диаграммы - главные компоненты модели. На диаграммах все функции производственной системы и интерфейсы представлены как блоки (функции) и дуги (интерфейсы). Место соединения дуги с блоком определяет тип интерфейса. Управляющие производством данные входят в блок сверху, в то время как материалы или информация, которые подвергаются производственной операции, показаны с левой стороны блока; результаты выхода показаны с правой стороны. Механизм (человек
или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
45////////////////////////////////////////////////////////////////////////////////////////////45/////////////////////////////////////////////////////////////////////////////////////////////////////////////45
Основу методологии IDEF0 составляет графический язык описания бизнес- процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес - процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес - процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма (например "Изготовление детали", "Прием заказа" и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ"). В IDEF0 различают пять типов стрелок:
Вход (Input) - материал или информация, которая используется или преобразовывается работой.
Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.
Выход (Output) - материал или информация, которая производится работой. Каждая работа должна иметь хотя бы одну стрелку выхода.
Механизм (Mechanism)- ресурсы, которые выполняют работу, например, персонал предприятия станки, механизмы и т.д.
Вызов - специальная стрелка, указывающая на другую модель работы.
Каждый тип стрелок подходит или выходит к определенной стороне прямоугольника, изображающего работу. К левой стороне подходят стрелки входов, к верхней - стрелки управления, к нижней - механизмов реализации выполняемой функции, а из правой - выходят стрелки выходов. Такое соглашение предполагает, что используя управляющую информацию и реализующий ее механизм, функция преобразует свои входы в соответствующие выходы.
Разработка модели начинается с создания контекстной диаграммы с единственной работой, изображающей систему в целом (рис. 3.2). Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.
После создания контекстной диаграммы можно приступить к декомпозиции. Она заключается в разработке набора диаграмм более низкого уровня, детализирующих исследуемый процесс. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3-х до 6-ти блоков на одной диаграмме (рис. 3.3). Работы обычно располагаются в так называемом порядке доминирования (по степени важности или в порядке очередности выполнения), начиная с левого верхнего угла и кончая нижним правым углом, что значительно облегчает в дальнейшем чтение диаграммы.
Ответы на 43/44/45
46/////////////////////////////////////////////////////////////////////////46/////////////////////////////////////////////////////////////////46//////////////////////////////////////////////////////////46/////////////////
Для моделирования информационных процессов производственной системы или среды применяется IDEF1-методология, созданная компаниями Hugbes Aircraft и D. Appleton Company (DACOM). Она опирается как на собственные разработки обеих компаний, так и на реляционную теорию Т.Кодда и диаграммы "сущности-отношения" П.Ченна. Кроме того, разработана и активно применяется расширенная версия IDEF1 (называемая IDEF1X). В ней учтены требования и опыт проекта IISS (IISS-подход заключается в создании и использовании единого семантического определения данных как ресурса, получившего название "концептуальной схемы" и основанного на применении IDEF1-методологии моделирования), а также практика ее применения в промышленности. Улучшение методологии заключается в повышении качества графического представления, развитии семантики и упрощении процедур разработки модели. Этот усовершенствованный вариант разработан и проверен компанией DACOM в процессе реализации военно-воздушных и частных проектов как совместно с ведущими аэрокосмическими корпорациями (General Dynamics, McDonnell Douglas, Rockwell International, General Electric), так и с финансовыми корпорациями (ARCO, Security Pacific National Bank, ScheringPlough).
Необходимость определения данных с концептуальной точки зрения привела к разработке методологии моделирования данных, основанной на семантике, то есть к трактовке данных в контексте их взаимосвязей с другими данными.
Реальный мир в терминах ресурсов, идей, событий и т.п. можно символически представить в рамках физического хранения данных. Семантическая модель данных является абстрактной схемой, показывающей, как хранящиеся символы соотносятся с реальным миром. То есть такая модель в принципе должна быть верным отражением реального мира.
IDEF1Х - это методология семантического моделирования данных. Основными конструкциями IDEF1Х-модели являются:
Предметы, к которым относятся данные, то есть люди, места, идеи, события и т.д. Они изображаются блоками.
Отношения между этими предметами, изображаемые соединяющими блоки линиями.
Характеристики этих предметов, изображаемые именами атрибутов внутри блоков
47/////////////////////////////////////////////////////////////////////////////////////////////////////////////////47//////////////////////////////////////////////////////////////////////////////////////////////////////////47
Методология разработана с учетом следующих требований:
- Поддержка разработки концептуальных схем. Синтаксис IDEF1Х поддерживает семантические конструкции, необходимые для разработки концептуальной схемы. Ей присущи непротиворечивость, расширяемость и адаптивность.
- Обеспечение ясного языка. IDEF1Х имеет простую, ясную, непротиворечивую структуру и четкие семантические понятия. Синтаксис и семантика IDEF1Х сравнительно легки для понимания, хотя и являются достаточно мощным средством.
- Простота для изучения. Семантическое моделирование данных - новое понятие для многих пользователей IDEF1. Проблема обучаемости этому языку является важным фактором. Язык рассчитан на понимание и использование как профессиональными бизнесменами и системными аналитиками, так и администраторами данных и разработчиками баз данных. Он может служить эффективным средством коммуникации в коллективах, состоящих из различных специалистов.
- Большой опыт применения на практике. IDEF1Х базируется на многолетнем опыте предшествующих методологий и тщательно проверена как в проектах ВВС, так и в промышленности.
- Возможность автоматизации. IDEF1Х-диаграммы могут создаваться большим числом графических программных пакетов. ВВС США на основе концептуальной схемы разработали активный трехсхемный словарь для построения прикладных программ и обработки запросов в распределенной неоднородной среде. Существует также коммерческое программное обеспечение, поддерживающее детализацию, анализ и управление конфигурацией IDEF1Х-моделей.
Методология IDEF1Х может применяться в различных целях, например, в таких, как планирование ресурсов данных, построение совместно используемых баз данных, оценка покупаемого программного обеспечения, объединение существующих баз данных и т.п.
48////////////////////////////////////////////////////////////////////////////////////////////48/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////48
IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) мы называем описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
- Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса.
- Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
- Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.
- Содействовать принятию оптимальных решений при реорганизации технологических процессов.
- Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."
в стандарте IDEF3 cуществуют два типа диаграмм, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN).
Диаграммы потоков данных (Data flow diagramming, DFD).
Ответы на 46/47/48
49////////////////////////////////////////////////////////////////////////////////////////////////////49/////////////////////////////////////////////////////////////////////////////////////////////////////////////49
диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN).
Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.
На рис.3.5 изображена диаграмма PFDD, являющаяся графическим
отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:
Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.
Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB
Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.
Классификация возможных типов перекрестков приведена в таблице 3.1.
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".
Сценарий, отображаемый на диаграмме, можно описать в следующем виде:
“Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.”
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 3.5, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурирова-но описывать процессы с любым требуемым уровнем детализации.
Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.3.6 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы.
Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
50////////////////////////////////////////////////////////////////50//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////50
Использование диаграмм потоков данных (DFD)
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывают функции обработки информации (работы), документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние ссылки, external references) и таблицы для хранения документов (хранилище данных, data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление или механизм и неважно, в какую грань работы входит или из какой грани выходят стрелки. В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона. Для того, чтобы дополнить модель IDEF0 диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count кликнуть по радиокнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
- добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;
- добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде чем использовать в работах.
- ссылка на другую страницу. В отличие от IDEF0 инструмент off- page reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако, для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.
Ответы на 49/50