Аналитическая модель включает
•Модель предметной области (domainmodel);
•Модель программной системы (applicationmodel).
Представления аналитической модели
1.Представление классов (LogicalView). Моделируем: сущности предметной области (businessentity), классы анализа (boundary, entity, controll);
2.Представление процессов & состояний (ProсessView).Моделируем: бизнес-процессы, последовательности действий в вариантах использования, алгоритмы операций;
3.Представление прецедентов (UseCaseView).Моделируем: варианты использования (usecase), пользователей (actor), объекты классов анализа, их связи и взаимодействие.
Моделирование предметной области (ПО)
1.Моделирование предметной области является в RUP опциональной и выполняется для самих разработчиков, Заказчик является экспертом предметной области и не нуждается в ее моделировании.
2.Целью моделирования предметной области является выработка точной, четкой, доступной для понимания и, наконец, корректной модели реального мира [2].
3.В зависимости от конкретного проекта по усмотрению бизнес-аналитиков при анализе ПО могут создаваться следующие артефакты: глоссарий терминов предметной области, диаграмма бизнес-сущностей (классов ПО), диаграммы взаимодействия объектов ПО (моделирование связей), диаграммы бизнес-процессов или состояний, диаграммы функционеров (бизнес-актеров) и их функциональные обязанности, модели, описывающие состояния и условия перехода из одного в другое.
|
|
|
Цель:выявление и документирование бизнес-сущностей (классов ПО) и их атрибутов.
Бизнес-сущность— некий объект ПО или концептуальное понятие ПО, характеризуемое набором данных (существенных признаков), прямо или косвенно связанное с проектируемой программной системой.
Бизнес-сущности – это кандидаты в классы и объекты ПС, которые отвечают за ввод, изменение, удаление и хранение данных (атрибутов).
Методика выявления бизнес-сущностей:чтение текста концепции и анализ имен существительных.
Моделирование бизнес-актеров Модель бизнес-актерови их функциональных обязанностей (бизнес-функций) строится в представлении UseCaseView в папке BusinessUseCaseModel (при вызове шаблона rationalunifiedprocess) на диаграмме ВИ.
Цель моделирования:изучение действующих лиц ПО и их функциональных обязанностей для понимания бизнес-процессов, выявления пользователей системы, уточнения высокоуровневых бизнес-целей.
BusinessActor— это штатная единица (действующее лицо, функционер) в предметной области, который взаимодействует с ПС, либо не взаимодействует, но является участником бизнес-процесса. Чаще всего это штатный работник предприятия или должность (генеральный директор, главный инженер, экономист, зам. директора по производству и т.д.), но может быть и обособленной штатной системой, исполняющей определенные функциональные обязанности (например: кран, весы-транспортеры и т.д.).
|
|
|
BusinessUseCase— это функциональные (должностные) обязанности, возложенные на данного функционера. Фиксируются только те из них, которые прямо или косвенно связаны с работой программной системы.
Моделирование бизнес-процессовЕсли проектируемая ПС должна обеспечивать некий бизнес-процесс, то его необходимо изучить и смоделировать.
В RationalRose отсутствует отдельное представление ProсessView, однако, можно присоединить диаграмму деятельности (activitydiagram) к любому элементу в браузере проекта.
Понятие итерации в RUP, преимущества итерационного подхода.
Проект в RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель. Основной единицей планирования итераций является прецедент использования. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к ее завершению.
Итеративная модель, подробно описанная выше, позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.
|
|
|
Процесс итеративной (или инкрементальной) разработки стал эволюционным развитием модели водопада. Процесс состоит из серии повторяющихся итераций (их число зависит от конкретного проекта), каждая из которых фактически является полноценным мини-проектом с фазами определения требований, анализа, дизайна и т.д. В результате очередной итерации продукт приобретает новую функциональность или улучшения в существующей функциональности. Полный набор требований, зафиксированный границами проекта, оказывается реализованным после завершения финальной итерации.
Основываясь на специфике проекта и требованиях заказчика, разработчики могут выбирать, что они хотят получить в результате очередной итерации:
Полноценную систему с ограниченной функциональностью, готовую для промышленной эксплуатации.
Функциональные и архитектурные прототипы, непригодные для промышленной эксплуатации, но позволяющие оценить функциональный дизайн, пользовательский интерфейс, производительность и т.д.
Итеративная разработка обладает рядом преимуществ по сравнению с последовательной моделью.
Реализация наиболее важных функций может быть завершена в ходе нескольких первых итераций. После их завершения (то есть намного раньше окончания всего проекта) заказчик сможет начать использование системы.
|
|
|
Уже в начале проекта пользователи получают возможность оценить фунциональность системы и ее соответствие своим потребностям. Необходимые изменения и дополнения могут быть сделаны в течение следующих итераций.
Основные проектные риски могут (и должны) быть разрешены на первых итерациях. Например, архитектурное решение, приводящее к неприемлемой производительности может быть обнаружено и исправлено уже в первой итерации.
Важно понимать, что все эти преимущества проявляются только при тщательном планировании итераций, в противном случае легко получить ухудшенный вариант модели водопада.
.
Дата добавления: 2018-02-15; просмотров: 457; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!