А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 19

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

2.3).100Таблица 2.3Весовые коэффициенты вариантов использованияТип вариантаиспользованияПростойСреднийСложныйОписание3 или менее транзакцийОт 4 до 7 транзакцийБолее 7 транзакцийВесовойкоэффициент51015Другой способ определения сложности вариантов использованиязаключается в подсчете количества классов анализа, участвующих в ихреализации (табл.

2.4).Таблица 2.4Весовые коэффициенты вариантов использованияТип вариантаиспользованияПростойСреднийСложныйОписаниеМенее 5 классовОт 5 до 10 классовБолее 10 классовВесовойкоэффициент51015Для системы регистрации сложность вариантов использованияопределяется следующим образом:Таблица 2.5Сложность вариантов использованияВариант использованияВойти в системуЗарегистрироваться на курсыПросмотреть табель успеваемостиВыбрать курсы для преподаванияПроставить оценкиВести информацию о профессорахВести информацию о студентахЗакрыть регистрациюТипПростойСреднийПростойСреднийПростойПростойПростойСреднийТаким образом, общий весовой показатель равен:UCР = 5*5 +10*3 = 45В результате получаем показатель UUCP (unadjusted use case points):UUCP = A + UC = 561012.6.3.

Определение технической сложности проектаТехническая сложность проекта (TCF - technical complexity factor)вычисляется с учетом показателей технической сложности (табл. 2.6):Таблица 2.6Показатели технической сложностиПоказательТ1Т2Т3Т4Т5Т6Т7Т8Т9Т10Т11Т12Т13ОписаниеРаспределенная системаВысокая производительность (пропускнаяспособность)Работа конечных пользователей в режиме он-лайнСложная обработка данныхПовторное использование кодаПростота установкиПростота использованияПереносимостьПростота внесения измененийПараллелизмСпециальные требования к безопасностиНепосредственный доступ к системе со сторонывнешних пользователейСпециальные требования к обучению пользователейВес211110,50,5211111Каждому показателю присваивается значение в диапазоне от 0 до 5 (0означает отсутствие значимости показателя для данного проекта, 5 высокую значимость).

Значение TCF вычисляется по следующей формуле:TCF = 0,6 + (0,01 * (Σ Ti * Весi))Вычислим TCF для системы регистрации:Таблица 2.7Показатели технической сложности системы регистрацииПоказательТ1Т2Т3Т4Т5Вес21111Значение43510102Значение с учетом веса83510ПоказательТ6Т7Т8Т9Т10Т11Т12Т13ΣВес0,50,5211111Значение55045351Значение с учетом веса2,52,504535140TCF = 0,6 + (0,01 * 40) = 1,02.6.4. Определение уровня квалификации разработчиковУровень квалификации разработчиков (EF - environmental factor)вычисляется с учетом следующих показателей (табл. 2.8).Таблица 2.8Показатели уровня квалификации разработчиковПоказательF1F2F3F4F5F6F7F8ОписаниеЗнакомство с технологиейОпыт разработки приложенийОпыт использования объектно-ориентированногоподходаНаличие ведущего аналитикаМотивацияСтабильность требованийЧастичная занятостьСложные языки программированияВес1,50,510,512-1-1Каждому показателю присваивается значение в диапазоне от 0 до 5.Для показателей F1 - F4 0 означает отсутствие, 3 - средний уровень, 5 высокий уровень.

Для показателя F5 0 означает отсутствие мотивации, 3 средний уровень, 5 - высокий уровень мотивации. Для F6 0 означаетвысокую нестабильность требований, 3 - среднюю, 5 - стабильныетребования. Для F7 0 означает отсутствие специалистов с частичнойзанятостью, 3 - средний уровень, 5 - все специалисты с частичнойзанятостью. Для показателя F8 0 означает простой языкпрограммирования, 3 - среднюю сложность, 5 - высокую сложность.Значение ЕF вычисляется по следующей формуле:103ЕF = 1,4 + (- 0,03 * (Σ Fi * Весi))Вычислим ЕF для системы регистрации:Таблица 2.9Показатели уровня квалификации разработчиков системы регистрацииПоказательF1F2F3F4F5F6F7F8ΣВес1,50,510,512-1-1Значение11145303Значение с учетом веса1,50,512560-313ЕF = 1,4 + (- 0,03 * 13) = 1,01В результате получаем окончательное значение UCP (use case points):UCP = UUCP * TCF * EF = 56*1,0*1,01 = 56,562.6.5. Оценка трудоемкости проектаВ качестве начального значения предлагается использовать 20человеко-часов на одну UCP.

Эта величина может уточняться с учетомопыта разработчиков. Пример возможного уточнения:Рассмотрим показатели F1 - F8 и определим, сколько показателей F1 F6 имеют значение меньше 3 и сколько показателей F7 - F8 имеютзначение больше 3. Если общее количество меньше или равно 2, следуетиспользовать 20 человеко-часов на одну UCP, если 3 или 4 - 28. Еслиобщее количество равно 5 или более, следует внести изменения в сампроект, в противном случае риск провала слишком высок.Для системы регистрации получаем 28 одну UCP, таким образом,общее количество человеко-часов на весь проект равно 56,56*28 = 1583,68,что составляет 40 недель при 40-часовой рабочей неделе.

Допустим, чтокоманда разработчиков состоит из четырех человек, и добавим 3 недели наразличные непредвиденные ситуации, тогда в итоге получим 13 недель навесь проект.104Опытные данные компании RationalПроект среднего размера (приблизительно 10 разработчиков, болеечем 6-8 месяцев) может включать приблизительно 30 вариантовиспользования. Это соответствует тому, что средний вариантиспользования содержит 12 UCP, и каждая UCP требует 20-30 часов.

Этоозначает общую трудоемкость в 240-360 человеко-часов на вариантиспользования. Таким образом, 30 вариантов использования потребуютприблизительно 9000 человеко-часов (10 разработчиков в течение 6месяцев). Однако, прямой пропорции не существует: очень большойпроект со 100 разработчиками и сроком 20 месяцев не начнется с 1000вариантов использования, из-за проблем размерности.Использование описанной выше методики для простых и сложныхсистем хорошо согласуется с опытными данными компании Rational(приблизительно 150-350 часов на один вариант использования). Самаяпростая система (весовой показатель UC = 5, А = 2, UUCP = 7) дает (при 20человеко-часах на UCP) приблизительно 140 человеко-часов.

Сложнаясистема (весовой показатель UC = 15, А = 3, UUCP = 18) даетприблизительно 360 человеко-часов.? Вопросы для самоконтроля:1. Что такое бизнес-процесс и бизнес-модель?2. Что дает построение бизнес-моделей и какие проблемы с нимсвязаны?3. Охарактеризуйте достоинства и область применения методикимоделирования Rational Unified Process.4. Какие проблемы могут возникнуть при спецификации требованийв случае отсутствия бизнес-моделей?105Глава 3.

Анализ и проектирование ПОЦелью объектно-ориентированного анализа является трансформацияфункциональных требований к ПО в предварительный системный проект исоздание стабильной основы архитектуры системы. В процессепроектирования системный проект "погружается" в среду реализации сучетом всех нефункциональных требований.Объектно-ориентированный анализ включает два вида деятельности:• архитектурный анализ;• анализ вариантов использования.Объектно-ориентированноепроектирование,соответственно,включает:• проектирование архитектуры системы;• проектирование элементов системы.Изложение их методики будет сопровождаться примерами из системырегистрации учебного заведения.3.1.

Архитектурный анализАрхитектурный анализ выполняется архитектором системы ивключает в себя:• утверждение общих стандартов (соглашений) моделирования идокументирования системы;• предварительноевыявлениеархитектурныхмеханизмов(механизмов анализа);• формирование набора основных абстракций предметной области(классов анализа);• формирование начального представления архитектурных уровней.Соглашения моделирования определяют:• используемые диаграммы и элементы модели;• правила их применения;• соглашения по именованию элементов модели;• организацию модели (пакеты).Пример набора соглашений моделирования:• Имена вариантов использования должны быть короткимиглагольными фразами.• Именаклассовдолжныбытьсуществительными,соответствующими, по возможности, понятиям предметнойобласти.• Имена классов должны начинаться с заглавной буквы.106• Имена атрибутов и операций должны начинаться со строчнойбуквы.• Составные имена должны быть сплошными, без подчеркиваний,каждое отдельное слово должно начинаться с заглавной буквы.• Все классы и диаграммы, описывающие предварительныйсистемный проект, помещаются в пакет с именем Analysis Model.• Диаграммы классов, реализующих вариант использования, идиаграммы взаимодействия, отражающие взаимодействие объектовв процессе реализации сценариев варианта использования,помещаются в кооперацию с именем данного вариантаиспользования и стереотипом "use-case realization".

Все кооперациипомещаются в пакет с именем Use Case Realizations. Связь междувариантом использования и его реализацией изображается наспециальной диаграмме трассировки (рис. 3.1).Рис. 3.1. Фрагмент диаграммы трассировкиАрхитектурные механизмы отражают нефункциональные требованияк системе (надежность, безопасность, хранение данных в конкретнойсреде, интерфейсы с внешними системами и т.д.) и их реализацию вархитектуре системы. В процессе анализа они только обозначаются,отвлекаясь от особенностей среды реализации, а все детали их реализацииопределяются в процессе проектирования.Архитектурные механизмы, по существу, представляют собой набортиповых решений, или образцов, принятых в качестве стандарта данногопроекта.Идентификацияосновныхабстракцийзаключаетсявпредварительном определении набора классов системы (классов анализа)на основе описания предметной области и спецификации требований ксистеме (в частности, глоссария).

Способы идентификации основных107абстракций аналогичны способам идентификации сущностей в модели«сущность-связь».Так, для системы регистрации идентифицировано пять классованализа:• Student (Студент);• Professor (Профессор);• Schedule (Учебный график);• Course (Курс);• CourseOffering (Конкретный курс).Классы анализа показаны на рис. 3.2.Рис. 3.2.