Довольно много времени убил на поиск набора библиотек и заголовочных файлов для подключения библиотеки GLUT. GLUT потребовался для написания курсача, в котором нужна графика. В качестве IDE использую Eclipse CDT, с MinGW в качестве компилятора, для которого пришлось искать соответствующие заголовочные файлы и библиотеки.
Первым рабочим оказалось решение:
http://www.ritgamedev.com/tutorials/glutEclipse/
Еще некоторые полезные ссылки вдовесок:
1. http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html
2. http://www.opengl.org/resources/code/samples/redbook/
Другие варианты использования GLUT с MinGW:
1. http://www.mingw.org/wiki/HOWTO_Use_Mark_J_Kilgards_OpenGL_Utility_Toolkit_GLUT_with_MinGW
2. http://web.cs.wpi.edu/~gogo/courses/mingw/
3. http://www.opengl.org/wiki/MinGW#GLUT_installation
Wednesday, March 17, 2010
Sunday, March 14, 2010
Сценарный подход и BPMN
В данной статье я хотел бы рассмотреть еще один подход к осмыслению требований. Этот подход, как и следует из названия статьи, основан на применении сценариев для моделирования некоторой разрабатываемой нами системы (например, некоторого программного продукта). Под сценарием здесь и далее я буду подразумевать всего лишь множество ролей и множество последовательностей действий этих ролей в контексте некоторой заданной ситуации. В свою очередь ситуацией может быть, например, решение какой-либо задачи, поставленной перед разрабатываемой нами системой.
Рассмотрим на примере. Представим, что мы разрабатываем очередной мобильный телефон. Мы хотим создать что-то работоспособное. Итак, начнем наш сценарий. Первое и самое важное, с чего надо начать, это определение цели и формулирование названия сценария. Название «Мой сценарий 1» не самый лучший вариант, так как из названия, например, не понятно, какая цель преследуется сценарием. Название «Передача SMS-сообщения» уже лучше, так как становится ясно, какую функциональность мобильного телефона мы собираемся моделировать. Далее роли, их может быть бесконечно много, но для простоты ограничимся тремя: пользователь, телефон и сеть. Пользователь: это обычный человек, у которого вдруг появляется мобильный телефон (и мы не должны рассчитывать на то, что он уже ознакомился с документацией к телефону). Телефон: в данном сценарии мы предполагаем, что мы имеем идеальную аппаратную часть, которую может испортить лишь плохое программное обеспечение. По этой причине, под ролью телефона будем полагать его операционную систему. Далее переходим к последовательностям действий.
Попытаемся описать основные действия, это могли бы быть общие действия, такие как: «ввод сообщения», «отправка его в сеть», «получение ответа сети о передаче сообщения». Рассмотрим ввод сообщения, см. фрамент 1.
Фрамент 1. Ввод сообщения.
Думаю, становится видно, что описание множества последовательностей действий становится непростой задачей, особенно, когда нужно предусматривать наличие сбоев и ошибок, а также ветвлений. Сбои и ошибки это нестандартное поведение системы: нельзя предусмотреть все сбои и все ошибки, но самые вероятные и ожидаемые стоит заложить в сценарий, а не рассчитывать, что все будет идти гладко. Таким образом, текстовое описание последовательности действий не совсем удобно для описания сложных сценариев, так как ограничивает многовариантность развития ситуации. Применение графической нотации для моделирования бизнес-процессов (например, BPMN) решает эти проблемы. Рассмотрим основные элементы, используемые для моделирования нашего сценария, см. рис.1. Каждый сценарий начинается элементом «начало», (рис. 1з) и завершается элементом «конец» (рис. 1ж), а иногда завершается элементом «ошибка» (рис. 1и). Пользовательские действия (рис. 1б): это некоторые действия, которые выполняет некоторый человек. Системные действия (рис. 1а): это некоторые действия со стороны системы, в нашем случае это действия системы (мобильного телефона) и действия сети. Действия конечно же интересны, но еще больший интерес представляют их последовательности, по этой причине нам нужен элемент диаграммы, соответствующий переходу (рис. 1г): это прямая стрелка. Переходы объединяют действия в последовательности. В BPMN переходов может быть три: условный, безусловный и по умолчанию. Для моделирования сценариев я предлагаю использовать только условные и безусловные переходы. Условные переходы отличаются от безусловных наличием некоторого условия, по которому переход осуществляется.
Сценарий будет мало интересен, если мы не будем иметь возможности смоделировать разветвление последовательностей действий. Ветвления могут быть следствием двух основных причин: ветвление в зависимости от условия и ветвление, вызванное распараллеливанием последовательности действий. В качестве элемента ветвления можно использовать вентили (рис. 1е и рис. 1д). XOR (рис. 1е) – вентиль аналогичен оператору «если». Из этого элемента диаграммы исходят только условные переходы. Переход будет происходить по первому элементу, в котором выполнилось условие (договоримся, что условия переходов проверяются в порядке, начиная сверху на диаграмме. Т.е. условие на самом верхнем переходе проверяется в первую очередь). Распараллеливанию последовательности действий соответствует AND-вентиль (рис. 1д). Если из этого вентиля исходят несколько переходов, то на всех них будет осуществлен переход и, таким образом, получится распараллеливание последовательности действий на несколько одновременно выполняющихся веток. Рассмотрим еще один значимый элемент диаграммы – ошибку. Ошибки (рис. 1в) на диаграмме нужны для того, чтобы предусмотреть некоторые исключительные ситуации при выполнении действий (в нашем случае, например, если сеть недоступна, мы не можем отправить сообщение с мобильного телефона). Ошибка должна быть прикреплена к тому действию, которое может приводит к возникновению исключительной ситуации (когда что-то идет не так). Нужно различать завершающие и промежуточные ошибки. Завершающая ошибка - это ошибка всего сценария, т.е. когда наш сценарий завершается с ошибкой. Промежуточные ошибки (рис. 1в) мы используем для того, чтобы отобразить ошибки, которые могут возникать при выполнении действий.
Для описания и документирования сценариев необходимо использовать элементы «комментарий» (рис. 1ё). При разработке сценариев я обязательно составляю комментарий, который относится ко всему сценарию в целом. В нем я пишу название сценария, описание используемых ролей и, возможно, описание некоторых начальных условий.
Не так часто используются элементы для оформления действий, связанных логически. Логически связанные действия можно объединять в подсценарии (рис. 1й). Подсценарий представляет собой блок, включающий в себя последовательности действий. Если требуется построить сложный иерархический сценарии, тогда не обойтись без элемента «внешний сценарий» (рис. 1к). Внешний сценарий представляет собой действие, которое выполняет какой-либо другой сценарий, на который это действие ссылается.
Рис. 1. Примеры элементов диаграмм.
Рис. 2. Собирая всё вместе.
Теперь объединим всё вместе (рис.2.). Наш сценарий можно представить в виде диаграммы BPMN. Входная точка в наш сценарий – элемент «начало». Согласно сценарию предполагается, что для отправки сообщения, пользователь должен его сначала ввести. Ввод сообщения должен быть прекращен, после того, как максимальный размер отправляемого сообщения будет превышен. О превышении максимального размера сообщения необходимо сообщить пользователю. Если всё нормально и пользователь нажал кнопку отправить, то телефон транслитирирует сообщение, если включена соответствующая настройка, формирует и передает запрос в сеть. Здесь может возникнуть исключительная ситуация, так как сеть может быть недоступна. Если сеть недоступна, то об этом также следует уведомить пользователя и предложить ему отправить сообщение позже. Далее, если все идет нормально, сеть регистрирует запрос и ставит его в очередь на обработку. Когда очередь подходит, сеть выполняет запрос на отправку сообщения. При выполнении запроса сеть может внезапно обнаружить, что у пользователя нет денег, а потому она не может отправить его сообщение. В этом случае сеть возвращает код, по которому устанавливается причина невозможности отправки сообщения (нехватка денег на балансе). В случае, если денег у пользователя на балансе достаточно сеть шлет подтверждение о том, что сообщение было отправлено. Конец сценария.
В заключение. Не бойтесь максимально документировать создаваемые сценарии. Если что-то не удается вписать в активность, это можно сделать, используя комментарии. Построение сценариев можно делать в любом BPMN - редакторе. Что касается меня, я использую диаграммы для быстрого моделирования use-кейсов и при их формировании, так как с помощью диаграмм у меня получается быстрее построить модель некоторой ситуации (сценарий), а потом уже по этой модели я строю ее текстовое описание.
Для дальнейшего чтения:
BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0, Cody-Cassidy Press (June 1, 2009)
Рассмотрим на примере. Представим, что мы разрабатываем очередной мобильный телефон. Мы хотим создать что-то работоспособное. Итак, начнем наш сценарий. Первое и самое важное, с чего надо начать, это определение цели и формулирование названия сценария. Название «Мой сценарий 1» не самый лучший вариант, так как из названия, например, не понятно, какая цель преследуется сценарием. Название «Передача SMS-сообщения» уже лучше, так как становится ясно, какую функциональность мобильного телефона мы собираемся моделировать. Далее роли, их может быть бесконечно много, но для простоты ограничимся тремя: пользователь, телефон и сеть. Пользователь: это обычный человек, у которого вдруг появляется мобильный телефон (и мы не должны рассчитывать на то, что он уже ознакомился с документацией к телефону). Телефон: в данном сценарии мы предполагаем, что мы имеем идеальную аппаратную часть, которую может испортить лишь плохое программное обеспечение. По этой причине, под ролью телефона будем полагать его операционную систему. Далее переходим к последовательностям действий.
Попытаемся описать основные действия, это могли бы быть общие действия, такие как: «ввод сообщения», «отправка его в сеть», «получение ответа сети о передаче сообщения». Рассмотрим ввод сообщения, см. фрамент 1.
Фрамент 1. Ввод сообщения.
Пользователь: вводит сообщение в телефон, длина сообщения превышает 128 символов.
Телефон: сообщает о превышении сообшения.
Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть недоступна.
Телефон: сообщает о том, что сеть недоступна.
Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть доступна. Включен транслит.
Телефон: конвертирует сообщение в транслит. Формирует сообщение.
Пользователь: вводит сообщение в телефон, длина сообщения меньше 128 символов. Пользователь жмет кнопку отправить. Сеть доступна. Транслит выключен.
Телефон: формирует сообщение.
Думаю, становится видно, что описание множества последовательностей действий становится непростой задачей, особенно, когда нужно предусматривать наличие сбоев и ошибок, а также ветвлений. Сбои и ошибки это нестандартное поведение системы: нельзя предусмотреть все сбои и все ошибки, но самые вероятные и ожидаемые стоит заложить в сценарий, а не рассчитывать, что все будет идти гладко. Таким образом, текстовое описание последовательности действий не совсем удобно для описания сложных сценариев, так как ограничивает многовариантность развития ситуации. Применение графической нотации для моделирования бизнес-процессов (например, BPMN) решает эти проблемы. Рассмотрим основные элементы, используемые для моделирования нашего сценария, см. рис.1. Каждый сценарий начинается элементом «начало», (рис. 1з) и завершается элементом «конец» (рис. 1ж), а иногда завершается элементом «ошибка» (рис. 1и). Пользовательские действия (рис. 1б): это некоторые действия, которые выполняет некоторый человек. Системные действия (рис. 1а): это некоторые действия со стороны системы, в нашем случае это действия системы (мобильного телефона) и действия сети. Действия конечно же интересны, но еще больший интерес представляют их последовательности, по этой причине нам нужен элемент диаграммы, соответствующий переходу (рис. 1г): это прямая стрелка. Переходы объединяют действия в последовательности. В BPMN переходов может быть три: условный, безусловный и по умолчанию. Для моделирования сценариев я предлагаю использовать только условные и безусловные переходы. Условные переходы отличаются от безусловных наличием некоторого условия, по которому переход осуществляется.
Сценарий будет мало интересен, если мы не будем иметь возможности смоделировать разветвление последовательностей действий. Ветвления могут быть следствием двух основных причин: ветвление в зависимости от условия и ветвление, вызванное распараллеливанием последовательности действий. В качестве элемента ветвления можно использовать вентили (рис. 1е и рис. 1д). XOR (рис. 1е) – вентиль аналогичен оператору «если». Из этого элемента диаграммы исходят только условные переходы. Переход будет происходить по первому элементу, в котором выполнилось условие (договоримся, что условия переходов проверяются в порядке, начиная сверху на диаграмме. Т.е. условие на самом верхнем переходе проверяется в первую очередь). Распараллеливанию последовательности действий соответствует AND-вентиль (рис. 1д). Если из этого вентиля исходят несколько переходов, то на всех них будет осуществлен переход и, таким образом, получится распараллеливание последовательности действий на несколько одновременно выполняющихся веток. Рассмотрим еще один значимый элемент диаграммы – ошибку. Ошибки (рис. 1в) на диаграмме нужны для того, чтобы предусмотреть некоторые исключительные ситуации при выполнении действий (в нашем случае, например, если сеть недоступна, мы не можем отправить сообщение с мобильного телефона). Ошибка должна быть прикреплена к тому действию, которое может приводит к возникновению исключительной ситуации (когда что-то идет не так). Нужно различать завершающие и промежуточные ошибки. Завершающая ошибка - это ошибка всего сценария, т.е. когда наш сценарий завершается с ошибкой. Промежуточные ошибки (рис. 1в) мы используем для того, чтобы отобразить ошибки, которые могут возникать при выполнении действий.
Для описания и документирования сценариев необходимо использовать элементы «комментарий» (рис. 1ё). При разработке сценариев я обязательно составляю комментарий, который относится ко всему сценарию в целом. В нем я пишу название сценария, описание используемых ролей и, возможно, описание некоторых начальных условий.
Не так часто используются элементы для оформления действий, связанных логически. Логически связанные действия можно объединять в подсценарии (рис. 1й). Подсценарий представляет собой блок, включающий в себя последовательности действий. Если требуется построить сложный иерархический сценарии, тогда не обойтись без элемента «внешний сценарий» (рис. 1к). Внешний сценарий представляет собой действие, которое выполняет какой-либо другой сценарий, на который это действие ссылается.
Рис. 1. Примеры элементов диаграмм.
Рис. 2. Собирая всё вместе.
Теперь объединим всё вместе (рис.2.). Наш сценарий можно представить в виде диаграммы BPMN. Входная точка в наш сценарий – элемент «начало». Согласно сценарию предполагается, что для отправки сообщения, пользователь должен его сначала ввести. Ввод сообщения должен быть прекращен, после того, как максимальный размер отправляемого сообщения будет превышен. О превышении максимального размера сообщения необходимо сообщить пользователю. Если всё нормально и пользователь нажал кнопку отправить, то телефон транслитирирует сообщение, если включена соответствующая настройка, формирует и передает запрос в сеть. Здесь может возникнуть исключительная ситуация, так как сеть может быть недоступна. Если сеть недоступна, то об этом также следует уведомить пользователя и предложить ему отправить сообщение позже. Далее, если все идет нормально, сеть регистрирует запрос и ставит его в очередь на обработку. Когда очередь подходит, сеть выполняет запрос на отправку сообщения. При выполнении запроса сеть может внезапно обнаружить, что у пользователя нет денег, а потому она не может отправить его сообщение. В этом случае сеть возвращает код, по которому устанавливается причина невозможности отправки сообщения (нехватка денег на балансе). В случае, если денег у пользователя на балансе достаточно сеть шлет подтверждение о том, что сообщение было отправлено. Конец сценария.
В заключение. Не бойтесь максимально документировать создаваемые сценарии. Если что-то не удается вписать в активность, это можно сделать, используя комментарии. Построение сценариев можно делать в любом BPMN - редакторе. Что касается меня, я использую диаграммы для быстрого моделирования use-кейсов и при их формировании, так как с помощью диаграмм у меня получается быстрее построить модель некоторой ситуации (сценарий), а потом уже по этой модели я строю ее текстовое описание.
Для дальнейшего чтения:
BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0, Cody-Cassidy Press (June 1, 2009)
Subscribe to:
Posts (Atom)