CASE-средства объектно-ориентированного моделирования.
Rational Rose— CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов является в настоящее время общепринятым стандартом в области объектно-ориентированного анализа и проектирования.
Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
ERwin Process Modeler (ранее называвшийся AllFusion Process Modeler, ещё ранее BPwin) — программный продукт в области реализации средств CASE-технологий. Позволяет проводить описание, анализ и моделирование бизнес-процессов. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти методологии по-своему уникальны. Каждая из них может быть выполнена отдельно с помощью BPwin, но их совокупность заключённая в модель даёт аналитику полную картину предметной области клиента.
|
|
|
48. Технология RUP.
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. В основе RUP лежат следующие основные принципы:
· Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
· Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
· Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
· Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
· Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
· Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Жизненный цикл разработки
RUP использует итеративную модель разработки. Полный жизненный цикл разработки продукта состоит из четырех фаз:
Начало (Inception)
|
|
|
· Формируются видение и границы проекта.
· Создается экономическое обоснование (business case).
· Определяются основные требования, ограничения и ключевая функциональность продукта.
· Создается базовая версия модели прецедентов.
· Оцениваются риски.
Проектирование (Elaboration)
· Документирование требований (включая детальное описание для большинства прецедентов).
· Спроектированную, реализованную и оттестированную исполняемую архитектуру.
· Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
· Сниженные основные риски.
Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта.
Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта.
49. Технология RAD.
Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
· небольшую команду программистов (от 2 до 10 человек);
· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
· повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
|
|
|
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
· фаза анализа и планирования требований;
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности.
· фаза проектирования;
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений.
· фаза построения;
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера.
· фаза внедрения.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой).
|
|
|
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
50. Основные принципы экстремального программирования.
Экстремальное программирование – упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований.
Кэнт Бэк предложил 12 практик:
1. Игра в планирование – Planning Game.
2. Тестирование.
3. Программирование парами.
4. Рефакторинг - методика изменения кода без изменения его функциональности.
5. Простой дизайн – simple design
6. Коллективное владение кодом
7. постоянная интеграция – несколько раз в день
8. Наличие заказчика в команде
9. Частые выпуски версий
10. 40 часовая рабочая неделя
11. Стандарт кодирования
12. метафора системы
51. Моделирование бизнес-процессов (BPM)
BPM - Business process modeling
Дата добавления: 2018-02-15; просмотров: 821; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!