Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки
 Скачать 3.53 Mb.
|
|
значимо- сти объектов следует переводить в ранги путем их ранжирования. В противном случае оценку степени согласованности мнений экспертов проводят по другим критериям. 291 В рассматриваемом здесь примере среднее арифметическое значение ран- гов cp Q равно: 20 7 35 25 7 28 9 15 21 cp Q Сумма квадратов отклонений от среднего арифметического значения ран- гов 630 15 5 13 11 5 1 2 2 2 2 2 2 S Следовательно, коэффициент конкордации в данном случае 9 , 0 8400 7560 7 343 25 630 12 W Повысить точность экспертных оценок показателей качества можно, если произвести двукратное сопоставление и оценивание объектов, т.е. сначала это сделать в одной последовательности, а потом в противоположной. 12.10 .3. Метод экспертного оценивания в баллах При экспертизе качества продукции наиболее часто используют балльные оценки. Балльные оценки даются непосредственно экспертами или получаются в результате формализации процесса оценки. Эта формализация бывает эвристи- ческой или экспериментальной. Непосредственное назначение балльных оценок производится экспертами независимо друг от друга или в процессе обсуждения. Количество баллов в при- нимаемой оценочной шкале может быть разным. Для оценки показателей каче- ства обычно используют пятибалльную, семибалльную или десятибалльную шкалы. Таблица 12.3 Пример пятибалльной шкалы Оценка Число баллов Отличное качество 5 Хорошее качество 4 292 Вполне удовлетворительное ка- чество 3 Удовлетворительное качество 2 Плохое качество 1 293 Таблица 12.4 Пример семибалльной шкалы Оценка Число баллов Качество очень высокое 7 Качество высокое 6 Качество выше среднего 5 Качество среднее 4 Качество ниже среднего 3 Качество низкое 2 Качество очень низкое 1 Обобщенный показатель качества, определяемый экспертным методом по балльной системе исчислений, находят как среднее арифметическое значение оценок, поставленных всеми экспертами, т.е. вычисляют по формуле: a Q K a i i экс 1 , (12.81) где а – количество экспертов; i Q – оценки в баллах, поставленные экспер- тами. Если при экспертизе качества проводят несколько туров оцениваний (оп- росов), то в этом случае значение показателя качества определяют как среднее арифметическое значение оценок, полученных в каждом туре опроса экспертов по выражению: m K K m i экс i экс 1 ' , (12.82) где i экс K – значение показателя качества, полученное в каждом туре; т – число туров опроса. Экспертным методом часто пользуются при выборе техники, представлен- ной несколькими предприятиями на тендерные конкурсы (торги). Эвристическая формализация экспертных оценок заключается в опреде- лении зависимости между значениями параметрических показателей и их оцен- ками в баллах. На основании этого строится график или разрабатывается (пи- 294 шется) математическая формула, которые позволяют выражать балльную оценку показателей качества в натуральных единицах измерений. При экспериментальной формализации устанавливают соотношение зна- чений балльных оценок со значениями показателей, определяемыми в результате эксперимента. Экспертный метод определения значений показателей качества с исполь- зованием способа экспериментальной формализации оценок экспертов является более объективным, чем без такой формализации. Существует еще и так называемый социологический метод оценки качест- ва продукции. Этот метод, как и экспертный, основан на опросах, на мнениях, но не специальных экспертов, а различных потребителей оцениваемой продукции. Поэтому социологический метод относят к разновидности экспертного. Социологический метод определения значений показателей качества про- дукции является, по существу, маркетинговым и осуществляется с помощью не экспертов, а фактических или потенциальных потребителей продукции. Сбор мнений потребителей производится опросом или с помощью распространения и заполнения специальных анкет-вопросников, а также путем организации конфе- ренций, выставок, аукционов, опытно-показательной эксплуатации и т.п. 295 Приложение А. Стандартные элементы UML А.1. Стандартные стереотипы UML В табл. А.1 приведены стереотипы, которые определены в UML как стан- дартные элементы [13, 15]. Таблица А.1 Основные стереотипы UML Стереотип Элемент Назначение стереотипа actor Класс Определяет связанное множество ролей, кото- рые играет пользователь при взаимодействии с объектом системы. access Зависимость Сообщает, что открытое содержание целевого пакета доступно в про- странстве имён исход- ного пакета. association Концевая точка, связи Указывает, что соответ- ствующий объект видим ассоциацией. become Сообщение Целевой объект совпа- дает с исходным, но в более поздний момент времени (при этом, воз- можно, у него будут другие значения, со- стояния или роли). bind Зависимость Исходный класс ин- станцирует целевой шаблон с данными фак- тическими параметрами. call Зависимость Исходная операция вы- зывает целевую. copy Сообщение Точная, но независимая копия исходного объек- та. create Событие, сообщение Целевой объект создан в результате события или сообщения. 296 derive Зависимость Исходный объект может быть вычислен по целе- вому. destroy Событие, сообщение Целевой объект унич- тожен в результате со- бытия или сообщения. document Компонент Компонент представля- ет документ. enumeration Класс Определяет перечис- ляемый тип, включая его возможные значения как набор идентифика- торов. exception Класс Определяет событие, которое может быть вы- звано или перехвачено операцией. executable Компонент Описывает компонент, который может быть выполнен в узле. extend Зависимость Целевой вариант ис- пользования расширяет поведение исходного варианта использования в данной точке расши- рения. facade Пакет Пакет, который является лишь представлением другого пакета. file Компонент Компонент, который представляет документ, содержащий исходный код или данные. framework Пакет Пакет, состоящий в ос- новном из образцов. friend Зависимость Исходный класс имеет специальные права ви- димости. global Концевая точка связи Соответствующий объ- ект видим, поскольку принадлежит объемлю- щей области действия. import Зависимость Открытое содержание целевого пакета стано- 297 вится частью плоского пространства имён ис- ходного пакета, как если бы оно было объявлено непосредственно в нём. implementation Обобщение Потомок наследует реа- лизацию родителя, но не открывает и не поддер- живает его интерфейсов, вследствие чего не мо- жет быть подставлен вместо родителя. implementationClass Класс Реализация класса на некотором языке про- граммирования. include Зависимость Исходный вариант ис- пользования явно вклю- чает поведение другого варианта использования в точке, определяемой исходным вариантом использования. instanceOf Зависимость Исходный объект явля- ется экземпляром целе- вого классификатора. instantiate Зависимость Операции над исходным классом создают экзем- пляры целевого класса. interface Класс Описывает множество операций, определяю- щих, что может делать класс или компонент. invariant Ограничение Ограничение, которое всегда должно выпол- няться для ассоцииро- ванного элемента. library Компонент Статическая или дина- мическая объектная библиотека. local Концевая точка связи Соответствующий объ- ект видим, так как нахо- дится в локальной об- ласти действия. metaclass Классификатор Классификатор, все 298 объекты которого явля- ются классами. model Пакет Описывает семантиче- ски замкнутую абстрак- цию системы. parameter Концевая точка связи Соответствующий объ- ект видим, так как явля- ется параметром. postcondition Ограничение Ограничение, которое должно выполняться после выполнения опе- рации. powertype Класс Классификатор, все объекты которого явля- ются потомками данно- го родителя. precondition Ограничение Ограничение, которое должно выполняться перед выполнением операции. process Класс Классификатор, экземп- ляр которого представ- ляет ресурсоёмкий по- ток управления. refine Зависимость Говорит, что исходный объект является более детальной абстракцией, чем целевой объект. requirement Комментарий Описывает желаемое свойство или поведение системы. responsibility Комментарий Описывает контракт или обязательство класса. send Зависимость Исходная операция по- сылает целевое событие. signal Класс Асинхронный сигнал, который передаётся од- ним экземпляром дру- гому. stereotype Класс Стереотип, который может быть применён к другим элементам. stub Пакет Пакет выступает в роли заместителя для откры- 299 того содержимого дру- гого пакета. Стереотип Элемент Назначение стереотипа subsystem Пакет Описы- вает группирование элементов, ряд которых составляет специфика- цию поведения других элементов. system Пакет Описывает пакет, пред- ставляющий всю моде- лируемую систему. table Компонент Компонент, представ- ляющий таблицу базы данных. thread Класс Классификатор, экземп- ляр которого представ- ляет облегчённый поток управления. trace Зависимость Исторический предок исходного элемента. type Класс Абстрактный класс, ко- торый используется только для специфика- ции структуры и пове- дения (но не реализа- ции) множества объек- тов. use Зависимость Семантика исходного элемента зависит от се- мантики открытого со- держания целевого эле- мента. utility Класс Определяет класс, для которого область дейст- вия всех атрибутов и операций — класс. А.2. Стандартные помеченные значения UML В табл. А.2 приведены помеченные значения, которые определены в UML как стандартные элементы [13, 15]. 300 Таблица А.2 Основные помеченные значения UML Помеченное значение Элемент Назначение помеченно- го значения documentation Все элементы Содержит комментарий, описание или пояснение к элементу. location Большинство элементов Определяет узел или компонент, которому принадлежит элемент. persistence Класс, ассоциация, ат- рибут Определяет, сохраняет- ся ли состояние экземп- ляра после завершения создавшего его процес- са. semantics Класс, операция Описывает назначение класса или операции. А.3. Стандартные ограничения UML В табл. А.3 приведены ограничения, которые определены в UML как стан- дартные элементы [13, 15]. Таблица А.3 Основные ограничения UML Ограничение Элемент Назначение ограниче- ния complete Обобщение В модели специфициро- ваны все потомки в дан- ном обобщении (хотя некоторые могут быть скрыты на диаграммах), и дополнительных по- томков определять не разрешается. destroyed Экземпляр, связь Экземпляр или связь уничтожаются до за- вершения выполнения объемлющего взаимо- действия. 301 disjoint Обобщение Объекты данного роди- теля могут иметь не бо- лее одного заданного потомка в качестве ти- па. implicit Ассоциация Отношение является не явно выраженным, а концептуальным. incomplete Обобщение Специфицированы не все потомки в обобще- нии (учитывая и скры- тые) и разрешается оп- ределять дополнитель- ные потомки. new Экземпляр, связь Экземпляр или связь создаются в процессе выполнения объемлю- щего взаимодействия. or Ассоциация Из множества ассоциа- ций ровно одна является явно выраженной для каждого ассоциирован- ного объекта. overlapping Обобщение Объекты данного роди- теля могут иметь более одного заданного по- томка в качестве типа. transient Экземпляр, связь Экземпляр или связь создаются в процессе выполнения объемлю- щего взаимодействия, но уничтожаются до его завершения. 302 Приложение Б. Реализация BPMN-диаграмм Б.1. Пример реализации диаграммы нотации BPMN на языке BPML В следующем примере показано использование исключений, обработчиков системных ошибок и компенсаций (рис. Б.1). Рис. Б.1. Пример использования исключений, обработчиков системных ошибок и компенсаций Процесс начинается с запроса на получение заказа, определения дополни- тельных данных о заказе и времени его выполнения. Операции синхронизируют- ся и возвращают идентификатор заказа, используемый для корреляции после- дующих сообщений, отправленных или полученных в результате этого процесса. 303 Процесс выполняется в два этапа, ссылаясь на процессы chargeCustomer (смена заказчика) и shipProduct (отгрузка товара), после чего посылает уведом- ление о выполнении. Процесс может быть прерван в любой момент после от- правки запроса на отмену, что приведёт к запуску cancelRequest (запроса на от- мену). Если процесс не завершится в течение оговорённого срока, то он будет прерван. Если происходит ошибка, препятствующая завершению процесса, то про- цесс направляет соответствующее уведомляющее сообщение, прежде чем пре- рвать свою деятельность. Уведомление не требуется, если процесс прервался по запросу на отмену или по истечении заданного времени, поскольку пользователь знает об этих условиях. Поскольку в процессе завершения выполнения действий chargeCustomer (смена заказчика) и/или shipProduct (отгрузка товара) может возникнуть ошибка или исключительная ситуация, то используются компенсации процесса (одна выдаёт возврат, а другая — отменяет отгрузку товара). Как только этот процесс завершён, можно компенсировать этот процесс, направив запрос на отмену. Эта же операция встречается в другом контексте, когда заказ уже отправлен, а про- цесс ждёт соответствующего уведомления. Далее приводится реализация опи- санного выше процесса на языке BPML. 304 portType=”orderService” operation=”cancelRequest” correlate=”tns:orderID”> 305 306 154 Приложение Б. Реализация BPMN-диаграмм Б.2. Пример реализации диаграммы нотации BPMN на языке BPEL Рассмотрим пример «Бронирование путёвки» (рис. Б.2) [14]. Рис. Б.2. Пример BPMN-процесса «Бронирование билетов» Процесс начинается с получения запроса о предоставлении бронирования путёвки. После проверки кредитной карты осуществляется бронирование билета на самолёт, гостиницы и машины. Оформление бронирования автомобиля может быть выполнено не с первой попытки. После подтверждения всех заказов клиен- ту отправляется ответ на запрос. 307 Анализируя эту схему, нужно обратить внимание на то, что она показывает общую логику процесса, передачу запросов и ответов, никак не детализируя функционирование самих удалённых Web-сервисов. На языке BPEL нужно толь- ко описать последовательность обращений и способы обработки получаемой информации. Для написания соответствующей программы можно использовать один из многих BPEL-инструментов, которые на основе такой визуальной диа- граммы автоматически сгенерируют код на языке BPEL. Для создания BPEL-файла необходимо определить параметры процесса. В параметре partnerLink определены элементы, предшествующие опреде- лению процесса, но информация об этих элементах находится из свойств объекта «Задача» BPMN-процесса. Задачи процесса, относящиеся к типу обслуживания и реализованные в виде web-сервиса, определяют участников web-служб. Участ- ники и их свойства будут указывать на элементы partnerLink. myRole=”travelProcessRole” name=”ProcessStarter” partnerLinkType=”wsdl5:travelProcess”/> name=”HotelReservationService” partnerLinkType=”wsdl5:HotelReservationPartnerPLT” partnerRole=”HotelReservationRole”/> Элементы variable также предшествуют определению процесса. Они будут созданы на основе свойств, ассоциированных с процессом BPMN-диаграммы. Элементы variable будут определены в документе BPEL и связаны с элементами message. 308 messageType=”wsdl4:doCreditCardCheckingRequest” name=”checkCreditCardRequest”/> Логика самого бизнес-процесса, который состоит из операций, называемых действиями, заключена внутри тегов 309 Сообщение «Сделать заказ» в BPEL будет выглядеть следующим образом: Операция «Проверить кредитную карту» в BPEL будет выглядеть следую- щим образом: Каждая операция invoke, представленная на диаграмме прямоугольным блоком, описывается простой BPEL-структурой, которая включает элементы, |