Форма входа |
---|
Категории раздела | |
---|---|
|
Поиск |
---|
Наш опрос |
---|
Друзья сайта |
---|
|
Статистика |
---|
Главная » Статьи » Опыт моделирования на UML » Повышение производительности аналитика |
Информация для разработчиковВ первой статье цикла представлены мои соображения о роли аналитика в проекте разработки ПО. По сути, аналитик выполняет роль интеллектуального интерфейса между заказчиком и разработчиком программной системы. Заказчик и разработчик по-разному видят будущую систему.
С моей точки зрения, производительность проектной группы в целом при реализации второго подхода существенно выше, хотя бы за счет исключения частичного дублирования действий аналитика и разработчика. Но, в этом случае, аналитик должен обладать некоторыми дополнительными навыками. Модель анализаЭтот подраздел предназначен для читателей, незнакомых с концепцией моделирования анализа при разработке ПО. Анализ – это первый шаг к реализации требований к системе. Назначение модели анализа – описание предварительной структуры и внутреннего поведения системы в терминах "классов анализа". При этом модель не содержит деталей, специфичных для среды разработки: классы анализа представляют скорее понятия реального мира (предметной области), чем программные компоненты. Для моделирования анализа можно использовать профиль UML "RUPAnalysis". Но это не обязательно: вместо стереотипов анализа можно использовать ключевые слова. Класс анализа – это ранняя концептуальная модель "вещи в системе, которая имеет обязанности и поведение". Стереотипы классов анализа: Граничный класс Класс контроллер Моделирует управление поведением, определенным для одного или нескольких прецедентов. Объекты контроллеры (экземпляры класса) управляют другими объектами так, что их поведение имеет тип координирования. Класс
сущность Модель анализа – это одна из моделей набора моделей MDA[1].
В технологии RUP модель анализа может быть временным артефактом или вообще не разрабатываться. Использование модели анализа для представления информации разработчикуАналитики, использующие преимущественно второй подход к документированию требований (см. выше), часто используют для представления детальной информации о процессах и данных заказчика т.н. "раскадровки"[2] Если раскадровка составлена достаточно подробно, разработчик (системный архитектор, проектировщик пользовательского интерфейса, проектировщик базы данных и др.) может использовать ее без обращения к заказчику за дополнительной информацией. Мне кажется, что использование традиционных раскадровок имеет следующие недостатки:
Перечисленные недостатки частично устраняются при использовании модели анализа как средства передачи информации от аналитика к разработчику. Концепция MDA предполагает (см. рисунок выше), что ответственным за создание и поддержку модели анализа является архитектор/проектировщик[3]. Но классы модели анализа не являются прототипами проектных классов. Они только представляют информацию предметной области, необходимую для проектирования. Возложение ответственности за создание начального набора классов анализа на аналитика:
Пример использования модели анализаЯ начинаю работу над проектом с создания типовой структуры модели. Для этого я использую строительные блоки "Бизнес-модель", "Модель прецедентов" и "Модель анализа"[5]. Моделирование выполняется итерационно и инкрементно:
В качестве примера на иллюстрации ниже представлена диаграмма граничных классов, участвующих в реализации прецедента "Прием заявки" (см. предыдущие статьи цикла). Пример описания в окне свойств диаграммы: Примечание 1: Названия модельных элементов, их атрибутов и операций на диаграмме показаны на русском языке (алиасы). Фактические названия можно увидеть непосредственно в модели. Примечание 2: На диаграмме показаны только те операции, которые реализуют средства управления пользовательского интерфейса. Прецедент запускается выбором прецедента из меню главного окна системы. Открывается окно прецедента "Прием заявки. Интерфейс прецедента должен формироваться динамически в ответ на действия пользователя. - Выбор "Новая заявка" открывает форму приема заявки. Строка состояния заполнена служебной информацией. Ниже в форме размещается область информации клиента (общая часть) и информация объекта. Область контактного лица показывается после информации объекта. Последней показывается область приложений. - Выбор "Открыть заявку" отображает список заявок клиентов. После выбора заявки отображается форма регистрации, заполненная текущей информацией заявки. При заполнении полей, имеющих тип данных "Перечисление", ввод может осуществляться с использованием выпадающих списков (см. диаграмму "Перечисления в прецеденте "Прием заявки""). Заполнение информации клиента начинается с выбора категории субъекта. После выбора поля, соответствующие категории, вставляются между полями "Категория субъекта" и "Источник поступления". Выбор "Показать список" отображает список клиентов соответствующей категории. Список может быть ограничен набором начальных символов названия клиента. Пользователь может: - Выбрать клиента из списка. Форма заполняется информацией клиента. - Отобразить полный список всех контрагентов и выбрать клиента из этого списка. - Заполнить поля области контрагента вручную и добавить клиента в справочник. По заявке может быть указано несколько контактных лиц. Область для первого контакта отображается по умолчанию. Для включения дополнительного контакта нужно выбрать "Добавить контакт". Заполнение информации контактного лица выполняется аналогично тому, как это делается для клиента. При выборе управления, принадлежащего непосредственно форме приема заявки, отображается окно "Примечание к событию" со своими средствами управления. Перечисления, используемые в реализации прецедента "Прием заявки"[6]: Примечание 1. Этот же способ моделирования может использоваться и для описания взаимодействия с субъектом-системой. Примечание 2.
Обратите внимание, что граничные классы не могут иметь статических отношений с
классами-сущностями. Ведь экземпляры граничных классов (как и контроллеров)
существуют только во время выполнения! Примечание 3. Поведение граничных классов (создание и разрушение экземпляров, активность полей и средств управления) я первоначально описываю в виде текста в спецификации прецедента. Но один и тот же класс анализа может использоваться в реализации различных прецедентов, и хороший аналитик должен позаботиться о том, чтобы проектировщику не пришлось рыться во множестве документов для восстановления полного поведения класса. Способы представления поведения интерфейса – это "отдельная песня". И как я ее "пою", я могу описать в отдельной статье, если достаточное число читателей проявят к этому интерес. Вместо заключенияНемного статистикиПерефразируя известное выражение, можно сказать: "Аналитик – это не должность. Аналитик – это диагноз!" 14 июля я опубликовал на сайте первую статью цикла "Повышение производительности аналитика". Всего опубликовано 6 выпусков (этот - седьмой). Предыдущий – 25 августа. Пора выполнить анализ![7] В таблице ниже представлена статистика просмотров и скачиваний:
29 августа я обратился к читателям с просьбой ответить на ряд вопросов. Я надеялся, что ответы помогут выявить интересы читателей и скорректировать направление дальнейшей работы над статьями. В опросе приняли участие 8 человек! Только два человека оценили полезность содержащейся в статьях информации. Статистика, надо признать, удручающая! Я не буду описывать свою работу над ошибками. Перейду сразу к результатам: 1. Не оправдавшиеся ожидания. После просмотра первой статьи, только пятая часть читателей, заинтересовавшихся темой, посчитала полезным продолжить чтение последующих статей. 2. Читателей интересует не столько практический опыт, сколько рассуждения об опыте. Только двадцатая часть читателей, просматривавших статьи, захотела посмотреть модели и документы, иллюстрирующие рассуждения и рекомендации, представленные в тексте. Вывод: Продолжение публикации статей цикла "Повышение производительности аналитика" не имеет смысла: они не нашли своего читателя! В заключении цикла хочу еще раз подискутировать с воображаемым собеседником относительно места моделирования в разработке ПО. Язык и технология"Если у вас есть молоток, это еще не значит, что Вы – архитектор." Английская поговорка Авторы учебников по UML, преподаватели курсов (в том числе и я сам) постоянно подчеркивают, что UML – это всего лишь язык, используемый для объектно-ориентированного моделирования. Выучив этот замечательный язык, вы не научитесь создавать объектно-ориентированные системы. Для успешного применения объектно-ориентированного подхода необходимо, прежде всего, освоить его принципы (технологию). Всегда ли это утверждение истинно? Конечно! Но… "Человеческие существа не общаются непосредственно с объективным миром и с обществом в том смысле, как это обычно понимается. Они в значительной мере зависят от того конкретного языка, который стал их средой общения. Это совершенная иллюзия – полагать, что кто-то может согласовать себя с сущностью реальности без использования языка, и что язык – всего лишь случайное средство решения конкретных задач общения и мышления. Суть вопроса в том, что "реальный мир" в значительной степени неосознанно строится на языковых привычках группы людей… Мы видим, слышим и испытываем остальные ощущения так, как мы это делаем, в значительной степени потому, что языковые обычаи нашего общества предрасполагают к определенному выбору способа интерпретации". Эдвард Сапир[8] Цитата подчеркивает, что язык, на котором мы говорим, непосредственно влияет на способ восприятия мира (мышление). Это утверждение тем более справедливо для искусственных языков (для нашей аудитории – языков программирования и моделирования). Размышления в этом направлении приводят к выводу, что язык влияет на технологию и даже, иногда, (крамольная мысль!) на проектные решения.[9] Мой опыт общения с аналитиками (начинающими и уже зрелыми) свидетельствует, что многие из них пренебрегает возможностями мышления на языке моделирования. Т.к. во многих организациях UML является стандартом представления проектной информации, они "переводят" результаты своих изысканий на UML[10]. Для этих людей моделирование – это бесполезная дополнительная нагрузка, или, в крайнем случае, выполняет презентационные функции. Для этих людей UML – это иностранный язык! Увы! Благодарю читателей. Цикл завершен! [1] См. раздел "Модель первична, документ – вторичен" в первой статье цикла. Обратите внимание, что "Бизнес-модель" (полное название: "Модель, независимая от вычислений"), показанная на иллюстрации, заимствованной из документации OMG, представляет три модели RUP: "Модель бизнес-прецедентов", "Модель анализа бизнеса" и "Модель прецедентов". [2] Раскадровка (Storyboard) – это широко известная техника в кино и на телевидении, откуда сообщество разработчиков ПО заимствовало термин. Раскадровка позволяет оживить текстовый сценарий (в частности, прецедента), визуально проиллюстрировав требования. Это м.б. черновой набросок пользовательского интерфейса, позволяющий наглядно описать взаимодействие пользователя с системой. В предыдущих версиях RUP артефакт "раскадровка" рекомендовалось выполнять по шаблону документа "спецификация прецедента" и включать ремарки, содержащие детализацию требований (номенклатура и объем хранимой информации, время отклика на действия пользователя и т.п.). RUP содержал рекомендации по оформлению ремарок для различных типов дополнительной информации. Хотя раскадровки выполняются системным аналитиком, они не рассматриваются как официальные требования заказчика. [3] В RUP за модель анализа отвечает проектировщик. [4] Естественно, что совместная работа над общей моделью требует соблюдения дисциплины при управлении изменениями. [5] О строительных блоках см.
предыдущие выпуски. [6] Это промежуточная рабочая версия диаграммы, содержащая комментарии и, даже, обращения к участникам проекта. [7] Я начал писать это Заключение в начале сентября! [8] Цитировано по книге: Тимоти Бадд, Объектно-ориентированное программирование в действии, СПб, "Питер", 1997. [9] В программировании это не подлежит сомнению! [10] Как я перевожу с английского на русский. Обратно я даже не пытаюсь! | |||||||||||||||||||||||||||||
Просмотров: 2751 | Комментарии: 10 | Рейтинг: 0.0/0 |
Всего комментариев: 7 | ||||
| ||||