Санкт-Петербургский государственный университет
Опубликован: 04.12.2007 | Доступ: свободный | Студентов: 2508 / 291 | Оценка: 4.30 / 3.65 | Длительность: 16:28:00
ISBN: 978-5-94774-823-9
Лекция 5:

"Человеческие" аспекты применения визуального моделирования

< Лекция 4 || Лекция 5: 123 || Лекция 6 >

Компоновка и формализация

Итак, это может быть непосредственным началом проектирования, когда создается более-менее типовая система. Компоновка и формализация могут также следовать после творческого проектирования новой системы, после того как искомое решение найдено. Остановимся на последнем случае.

Сложившуюся у проектировщика целостную картину, найденное решение полезно оформить, перевести из разряда интуитивных прозрений, из области воображения, в зримые и осязаемые формы. Оформленное, описанное решение можно обсудить с различными людьми (а не только с "братьями по оружию" и друзьями, понимающими проектировщика с полуслова). Оно может также служить хорошей основой для дальнейшего воплощения системы. Более того, сам процесс оформления часто вскрывает различные неразрешенности и проблемы, которых автор еще не заметил и которые Джонс называл "вторичными противоречиями" найденного решения [5.4].

Занимаясь компоновкой и формализацией, проектировщик меняется. Он может, например, много чертить и писать, активно работать со справочной литературой, часто и подолгу общаться с коллегами. Проектировщик напоминает рыбака, который долго ждал, когда "клюнет", и вот теперь вытаскивает пойманную рыбу на берег. Со стороны может показаться, что вот теперь он, наконец, занят делом.

В этой функции визуальное моделирование очень полезно, так как диаграммы позволяют, в силу своей визуальной природы, наглядно выразить непростые для понимания детали решения, сделать их очевидными и понятными для тех, кто будет воплощать это решение в жизнь. Задача визуальных моделей - "схватить", продемонстрировать, обозначить, пояснить. Однако нужно дозировать применение визуального моделирования, активно используя кроме него также обычные документы, и устные объяснения. К сожалению, в области разработки ПО, в отличие от других инженерных дисциплин (строительства, машиностроения, электротехники и т. д.), не сложилось четких и однозначных рекомендаций по использованию чертежей. Таким образом, здесь вместо формальных критериев приходится использовать интуитивные ориентиры и собственный индивидуальный опыт.

Изучение существующей системы

Человек оказался рядом со сложной системой. Он - новичок, дилетант относительно данной системы, а ему нужно стать профессионалом, то есть досконально во всем разобраться. Цели у этого ученичества могут быть очень разные: необходимость влиться в коллектив создателей системы, освоить ее на уровне пользователя, разобраться в ней для того, чтобы создать техническую документацию и т. д.

Исходная установка ученика заключается в том, что он ничего не знает. Это - определенная внутренняя позиция, особенное состояние его психики. Это состояние можно описать как максимальную пустоту, отсутствие заранее сформулированных ожиданий, концепций, мнений, предпочтений. Если перед началом обучения мы полны всем этим, то нам трудно воспринимать новую информацию.

Ученик тих и внимателен, спокоен перед лицом большого и неизвестного массива информации, он настойчив в изучении, но пассивен в интерпретациях. Он вбирает в себя знания. Он старается максимально их упорядочить, но делает это ненасильственно и лишь до тех пор, пока это легко получается, - а потом он снова обращается к источнику информации. Ученик не боится незнания в любых формах, он готов носить в себе частичные знания, с лакунами и пробелами, не стремясь любой ценой их заполнить, подменять своими домыслами существующее, но непонятное ему пока еще положение вещей. Все происходит естественно, в свое время. Однако ученик наполнен желанием постичь предмет. Процесс обучения может протекать напряженно, страстно, быть подобным бурной горной реке, упрямому водному потоку, пробивающемуся через многометровую толщу скал к поверхности земли.

Постепенно для ученика начинает проясняться общая картина, перед его взором "проступает" логика системы. Его знания о системе становятся все более целостными, он все увереннее чувствует себя в потоке данной информации.

Интенсивность обучения достигается за счет активности ученика, а не его учителей. Эксперты и авторы системы, как правило, пассивны и заняты своей собственной работой. Часто они в состоянии лишь отвечать на вопросы ученика, расширяют, дополняют то, что он сам нашел, ставят перед ним следующие задачи, когда он освоил предыдущие. Ошибочно ожидать от учителей чрезмерной активности, чрезмерной заинтересованности в обучении. Ученик - самый активный человек в этом процессе.

Что можно изучать, участвуя в IT-проектах, так сказать, в "боевых условиях"? Часто ли такая задача вообще возникает в индустрии?

В области IT что-то изучать приходится почти постоянно, например:

  • приступая к созданию новой программной системы, программисты изучают соответствующую предметную область;
  • тестировщик изучает создаваемую или уже созданную систему, чтобы знать, что тестировать, знать, как система должна, а как не должна работать;
  • технический писатель, создавая руководство пользователя к программной системе, изучает эту систему, чтобы правильно ее описать;
  • программисты, которым поручили сопровождать уже работающую систему, должны в начале как следует ее изучить.

При этом мы становимся учениками со всеми вытекающими отсюда последствиями. У нас появляются учителя - "живые носители информации":

  • специалисты в предметной области, для которой создается система;
  • авторы системы, которую надо тестировать, документировать, сопровождать.

Могут, разумеется, использоваться книги, документы, видеозаписи и другие носители записанной информации.

При изучении какой-либо области знаний визуальное моделирование полезно как средство структурирования информации. Однако его ценность многократно возрастает, если у ученика есть "живой учитель". В этом случае визуальные модели могут служить хорошим средством для того, чтобы, просмотрев их, учитель легко увидел ошибки и упущения ученика, а также отслеживал его прогресс в обучении. Таким образом, диаграммы могут быть осью работы ученика с учителем. Важно, конечно, чтобы учитель мог легко понимать чертежи ученика. Этого можно добиваться многими путями, например:

  • не использовать непонятных и неочевидных для учителя графических нотаций;
  • если учитель готов учиться (то есть хочет и имеет на это время), то его можно научить, "приучить" к тем или иным диаграммам; но тут важно проявлять ненасильственность, не забывая, что знания нужны ученику, а задача повышения образования учителя вторична и уместна лишь при согласии последнего;
  • если учитель понимает и любит какие-либо виды диаграмм, то целесообразно использовать именно их;
  • от встречи к встрече одни и те же диаграммы детализируются и уточняются, новые диаграммы появляются нечасто и очень обоснованно. Учитель привыкает к моделям, глядя на знакомые диаграммы, ему легче "вынырнуть" из контекста своей работы и, улучив минутку свободного времени, вспомнить то, о чем они говорили с учеником в прошлый раз, ответить на его новые вопросы; обратная ситуация - когда к каждой встрече не в меру ретивый ученик создает все новые и новые диаграммы, и учитель вынужден вникать в них каждый раз "с нуля".

Например, диаграммы случаев использования родились именно из потребности работать с экспертами из не IT-сфер, возможно, вовсе не имеющих инженерной подготовки: продавцами магазинов, медиками, работниками музеев и пр. - различными будущими пользователями создаваемых программных систем. Было установлено, что эти диаграммы легко понимаются неспециалистами.

Целесообразно использовать структурные диаграммы (классов, компонент, размещений) как основной способ фиксации полученных знаний, описывая с их помощью структуру системы. Поведенческие диаграммы (последовательностей, коопераций, состояний и переходов и пр.) можно применять для моделирования отдельных фрагментов поведения системы, таким образом выявляя недостающую информацию о ее структуре. Полученная информация позволяет уточнить структурные модели и так далее. В итоге получается цикл - структурные модели/поведенческие модели. C построения каких именно моделей лучше начинать - структурных или поведенческих - зависит от области знания, от начальной компетенции ученика, от предпочтений эксперта и т. д.

Равнозначность и цикличность в использовании структурных и поведенческих визуальных моделей, конечно, является лишь общим принципом. Конкретная доля тех или иных видов диаграмм в процессе изучения какой-либо области знания будет разной. Возможны и крайние случаи. Например, при изучении каких-либо сложных алгоритмов из области телекоммуникации, обработки звука, шифрации и т. д. предпочтение будет отдано поведенческим моделей. А при разработке классификации видов жуков очевидно предпочтение структурных моделям4Нужно отметить, что если систему изучает программист для того, чтобы принять участие в дальнейшей разработке, то использование диаграмм UML достаточно ограничено. Главным источником информации о системе для такого человека является программный код. Если же систему изучают непрограммисты, то, как правило, они не исследуют ее кода. В этом случае роль диаграмм UML существенно повышается..

< Лекция 4 || Лекция 5: 123 || Лекция 6 >
Анна Митюрёва
Анна Митюрёва

http://www.intuit.ru/studies/courses/1041/218/info

С мобильного приложения доступ есть, а через сайт не отображается. Печально =(