Мастер (конструктор) кнопочных форм позволяет разрабатывать управляющие интерфейсные объекты, которые используются для управления работой приложения. [c.378]
Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели. Обычно различают следующие типы объектов объекты-сущности, управляющие объекты и интерфейсные объекты. Все классы объектов будем изображать в виде треугольников с добавлением букв внутри треугольника (см. рис.5.3) и - интерфейсные, у - управляющие. [c.136]
Интерфейсные объекты представляют в бизнесе операции, каждая из которых должна выполняться одним и тем же ресурсом. Эта задача включает взаимодействие с окружением бизнеса. Следовательно, к коммуникабельности людей, выполняющих эту задачу, предъявляются определенные требования. [c.137]
Интерфейсный объект может участвовать в нескольких прецедентах. Часто объекты этого типа несут ответственность за координацию процесса в той его части, которая касается непосредственного контакта с клиентами. Каждый конкретный клиент должен иметь как можно меньше контактов с компанией. Это, впрочем, не противоречит бизнес-теориям, которые рекомендуют работникам компании быть ближе к клиенту, а просто означает, что в интересах клиента его контакты с компанией должны быть как можно проще и реже. [c.137]
Можно сказать, что часть бизнеса, имеющая непосредственный контакт с внешним миром, видима как интерфейсные объекты, в то время как объекты-сущности и управляющие объекты более независимы от окружения. [c.137]
Управляющие объекты, как и интерфейсные объекты, представляют операции в бизнесе. Различие заключается в том, что эти операции не имеют непосредственного контакта с окружением бизнеса. Название "управляющий объект" используется потому, что эти объекты активны, они управляют или принимают участие в потоке управления при обработке продукции. Следовательно, экземпляр управляющего объекта часто имеет то же время жизни, что и экземпляр прецедента, в котором он участвует. Типичные примеры управляющих объектов в компании - это Разработчик Продукции и Менеджер Проекта. [c.137]
Обе модели используют три типа объектов интерфейсные объекты, управляющие объекты и объекты-сущности. При работе над идеальной моделью за основу берут прецеденты, а при разработке реальной модели за основу берется идеальная модель. Таким образом, процедуры определения объектов в этих моделях различны. [c.186]
Описание поведения, напрямую связанного с задачами, требующими контакта с субъектами. За этот тип поведения отвечают интерфейсные объекты. [c.189]
Ориентированный на процессы способ мышления имеет целью добиться того, чтобы один ресурс мог выполнить как можно большую часть процесса. Следовательно, в идеале вся работа, связанная с прецедентом, должна выполняться интерфейсным объектом (или если этот прецедент общается с несколькими субъектами, то несколькими интерфейсными объектами). Если задачи в прецеденте разделены на несколько объектов, то есть риск, что при реализации прецедента потребуются разные виды ресурсов. Это будет означать передачу работы между ресурсами (исполнителями), что увеличит время выполнения прецедента. [c.189]
Рассмотрим, как можно с помощью объектов описать два варианта процесса Продаж Продажа Готового Продукта и Продажа Заказного Продукта. В обоих случаях сразу видно, что для поддержки контакта с клиентом требуется интерфейсный объект Продавец. При определении объектов прецедента Продажа Готового Продукта нет причины разделять работу на несколько ресурсов. Интерфейсный объект Продавец проверяет наличие продукта и получение заказов клиентами. Если продукцию надо послать по почте, то заказ на поставку можно рассматривать как отдельную рабочую задачу. В этом случае появится дополнительный интерфейсный объект, Отправитель Продукта (рис. 7.4). В приведенном примере продукт моделируется как объект-сущность. Этот объект нужен для хранения информации о продукте, такой, как модель, цвет, цена и комплектация. [c.190]
Интерфейсные объекты (ИО) поддерживают взаимодействие информационной системы с ее окружением, обеспечивая преобразование и трансляцию данных и событий из внутрисистемных форм представления во внешние и наоборот. Эти объекты позволяют явно выделить зависимую от окружения составляющую модели информационной системы, в то время как управляющие объекты и объекты-сущности не зависят от окружения. Обычно к интерфейсным объектам относят экраны (окна), протоколы связи, интерфейсы с датчиками и устройствами вывода на печать. [c.207]
Причина, по которой введены три типа объектов, состоит в стремлении обеспечить гибкую структуру модели, допускающую ее модификацию и развитие. В ходе эксплуатации информационной системы неизбежны текущие изменения известно, что даже стабильные системы время от времени требуют локальных модификаций. Чаще всего проводится модификация пользовательских интерфейсов, а также тех или иных функциональных возможностей информационной системы, при этом изменения затрагивают только интерфейсные объекты ИСП. Изменения потока событий в прецеденте влияет на поведение управляющих объектов в информационной системе, а изменения объектов-сущностей в модели бизнеса отражаются на объектах-сущностях ИСП. Поскольку последнее случается относительно редко, объекты-сущности оказываются самыми стабильными элементами модели информационной системы. [c.208]
Интервьюер", занимающийся сбором требований, является абстрактным интерфейсным объектом бизнес-системы. Он наследуется всеми интерфейсными объектами модели бизнес-системы, которые тем или иным образом взаимодействуют с клиентами этой системы. "Ответственный за бета-тестирование" взаимодействует с субъектом "Бета-пользователь", представляющим ключевых пользователей разрабатываемого продукта, являющихся, по сути, активными участниками разработки этого продукта. [c.211]
Объекты бизнес-системы, описывающие сбор требований, изображены на рис. 8.3 (стрелки обозначают коммуникации). Интерфейсный объект Интервьюер - абстрактный объект, наследуемый [c.211]
В прецеденте Кредитование присутствуют два субъекта Клиент и Информационное Бюро Банка. Им соответствуют интерфейсные объекты Обработчик Кредитов (Обслуживающий клерк) и Информационное Бюро Банка. Обработчик Кредитов имеет обязательство по управлению потоком со- [c.228]
Рассуждая подобным образом, выделяем интерфейсный объект Обработчик Инвестиций для прецедента Инвестирование. Объектами-сущностями здесь являются Инвестиционный План, Клиент, Счет и Знания-о-Рынке. Можно выделить управляющий объект Аналитик-Рынка для сбора долговременных Знаний-о-Рынке. Для прецедента Управление Счетом можно выделить интерфейсный объект Обработчик Счета и объекты-сущности План Сбережений, Клиент и Счет. [c.229]
Многие банки предпочитают использовать один и тот же тип ресурса для Обработчика Кредитов, Обработчика Инвестирования и Обработчика Счета. Поэтому в окончательном варианте модели будем работать с одним интерфейсным объектом под названием Обслуживающий Клерк, позволяющим выполнять три различные задания (рис. 8.16). [c.229]
Интерфейсный объект Обслуживающий Клерк принимает участие в трех прецедентах (см. рис. 8.16), т.е. он имеет по крайней мере три обязательства (ответственности). Для того чтобы кредитовать или инвестировать, банк должен проанализировать различные альтернативы, оценить безопасность, риск и т.п. Следовательно, в ИСП целесообразно ввести субъект Обслуживающий Клерк и два прецедента Приложение кредитования и План инвестиций. Управляющий объект бизнес-системы Аналитик Рынка приводит к введению в ИСП субъекта Аналитик Рынка и прецедента Анализ-Знаний-о-Рынке. [c.230]
На рис. 8.17 изображена взаимосвязь между моделями бизнес-системы и информационной системы. С помощью пунктирных линий отслеживается наличие отношений между объектами разных моделей. Интерфейсный объект бизнес-системы Обслуживающий Клерк имеет два обязательства, что [c.230]
Для Обслуживающего Клерка необходима следующая поддержка интерфейсный объект должен контролировать количество денег на счетах клиента, т.е. снимать деньги со счетов, переводить их с одного счета на другой, запрашивать баланс счета, класть деньги на счет, а также запрашивать информацию о состоянии рынка. [c.231]
Идеальное проектирование 203,204 Иерархия классов 84,277 Индуктивное мышление 44 Инженерия знаний 95,242 Инжиниринг бизнеса 12,16,18 Инкапсуляция 85,86 Инспектор 120 Инспекция 119 Инструмент 258,270 Интерфейсный объект 137,189 Информационная система 43 Информационные технологии 12, 25 Источник данных (сервер данных) 283 Итератор 285 [c.325]
Детализация D - диаграммы классов объектов (преобразователь П22) выполняется путем уточнения классов объектов-сущностей и введения интерфейсных и управляющих классов объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов -координирующим функциям обработки объектов-сущностей. [c.370]
Детализация D -диаграммы пакетов (преобразователь П26) связана с уточнением состава классов объектов-сущностей и появлением интерфейсных и управляющих классов объектов. Например, интерфейсные и управляющие классы объектов могут быть выделены в самостоятельные обеспечивающие пакеты. [c.370]
Интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. С другой стороны, эти задачи выполняются людьми, относящимися к определенной категории ресурсов. В ресторане задача по приготовлению пищи выполняется человеком, обученным готовить (поваром). Часто, однако, несколько задач помещаются вместе в один объект, который реализуется одним конкретным экземпляром ресурса. Например, официант может отвечать как за размещение посетителей за столиками, так и за обслуживание посетителей. [c.136]
С левой стороны диаграммы взаимодействий обычно описывают поведение, выполняемое объектами (пути операций). В столбцах пути операций представляются жирными вертикальными отрезками. Описания путей операций дают основу для идентификации и описания операций объектов. Не всегда практично делать описания всех путей операций, так как структура текста на полях может стать слишком сложной. В нашем примере описаны пути операций только для интерфейсных и управляющих объектов, так как именно в этих объектах обрабатываются стимулы. [c.146]
В этой модели используются объекты трех типов интерфейсные, управляющие и объекты-сущности (см. рис. 5.3). [c.207]
Идеальные объекты бизнес-системы, участвующие в прецеденте Разработка Программного Обеспечения, изображены на рис. 8.2. Здесь для ясности изложения основной идеи приведены только семь типов объектов. На практике полная О-модель бизнес-системы по разработке программного обеспечения включает сотни типов объектов, из которых около 30% относятся к интерфейсным и управляющим, а все остальные - к сущностям. [c.210]
Рнс.8.2. Интерфейсные и управляющие объекты, участвующие в прецеденте Разработка Программного Обеспечения [c.210]
Для каждого прецедента ИСП Проектировщик Идеальной Модели определяет объекты, необходимые для реализации потока событий в нем. Можно начать работы по определению объектов с субъекта, инициирующего прецедент, а затем определить требуемые интерфейсные и управляющие объекты и объекты-сущности. [c.215]
В объектной модели бизнеса используются объекты трех типов интерфейсные, управляющие и объекты-сущности. Каждому из этих типов объектов соответствуют свои сущности в бизнесе. [c.225]
Итак, реинжиниринг информационной системы есть следствие реинжиниринга бизнес-процессов. Прежде всего изменения требуют фрагменты, соответствующие интерфейсным и управляющим объектам в идеальной модели прежней системы. Объекты-сущности оказываются обычно более стабильными. Они соответствуют элементам данных (например, типы данных или записи) и программам (фрагменты процедур или подпрограмм), которые работают с этими элементами. [c.236]
Интерфейсный объект (Interfa e Obje t) - активный объект, форма взаимодействия информационной системы с пользователем (экранная форма, меню, командная строка, кнопка) [c.354]
Компонент в своем составе имеет интерфейсный класс объектов, через который осуществляется доступ к остальным классам объектов компонента. На рис. 3.18 интерфейс обозначен маленьким кружком, присоединенным к пиктограмме компонента. С помощью интерфейса объекты других компонентов обращаются не к конкретным объектам рассматриваемого компонента, а к его интерфейсному объекту. Таким образом упрощается взаимодействие компонентов между собой, когда при доступе к компоненту из других компонентов не требуется знать внутреннюю структуру этого компонента. Компонент, к которому осуществляется обращение, может быть необъектно-ориентированным. Достаточно, чтобы у такого компонента был только один интерфейсный класс объектов, который транслирует запросы к компоненту в вызовы обычных процедур. У компонентов может быть несколько интерфейсов. [c.364]
Большинством своих идей метод похож на другие объектно-ориентированные методы. Фундаментальным отличием метода, как уже упоминалось выше, является использование сценариев или прецедентов (s enarios или use ases). Таким образом, функциональность системы описывается с помощью набора прецедентов для системы - моделью прецедентов. В дальнейшем, модель прецедентов используется для получения модели объектов предметной области. Анализ полученной модели объектов предметной области позволяет классифицировать объекты предметной области трех типов интерфейсные объекты, объекты сущностей и управляющие объекты. Далее объектная модель преобразуется в архитектурную модель, содержащую модули разрабатываемой системы. [c.76]
Когда получен первый список очевидных объектов-сущностей, следует проанализировать прецеденты. Просмотрите описания всех прецедентов и выявите объекты, которые ответственны за ту или иную часть потока событий прецедента. Для каждой пары субъект/прецедент можно назначить интерфейсный объект. Этот объект обслуживает все взаимодействия с субъектом и по возможности ббльшую часть внутреннего потока событий. Если нецелесообразно или невозможно, чтобы интерфейсный объект выполнял внутренний поток событий, то назначается управляющий объект (или несколько). [c.189]
Объекты-сущности представляют такие сущности, как продукция и предметы, которые обрабатываются бизнесом. Объект-сущность участвует не только в одном прецеденте экземпляр может принимать участие во многих событиях в бизнесе. В отличие от интерфейсных и управляющих объектов, объекты-сущности представляют сущности, не являющиеся человеческими или техническими ресурсами. Типичные примеры объектов-сущностей в компании -Продукция, Извещение (Invoi e) и Заказ. [c.137]
Идентифицируя прецеденты информационной системы, исходят из интерфейсных и управляющих объектов О-модели бизнеса. Если уже разработана реальная О-модель бизнеса, то лучше всего использовать именно ее объекты, если нет, можно использовать объекты идеальной модели. Для простоты описания введен понятие "активный объект", которое будет обозначать интерфейсный и управляющий объекты. Активный объект может рассматриваться таким образом, как суперкласс для интерфейсного и управляющего. Будем также говорить об информационной системе в единственном числе, хотя на самом деле в компании может использоваться несколько таких систем. [c.226]
В первую очередь при проведении реинжиниринга исходной информационной системы следует сохранять, насколько это возможно, реализованную в ней модель данных и свести все необходимые изменения к минимуму. Если исходная система спроектирована не совсем плохо, не придется отказываться от всех данных, с которыми она работает. Обычно удается почти полностью сохранить имеющуюся модель данных и, следовательно, ббльшую часть самих данных. Основные изменения лучше всего направить на интерфейсные и управляющие объекты идеальной модели исходной системы. Скорее всего за счет развития и модификации именно этих объектов следует адаптировать информационную систему к новой организации бизнеса, поэтому с них и следует начинать. [c.237]
| Рис. 1. Структура СДУ распределенным объектом. RTU - удаленные контроллеры, установленные на КП, FEP (Front-End Pro essor) - интерфейсное устройство для связи диспетчерского компьютера с RTU. |  |