'

Анализ и Проектирование качественных приложений

Понравилась презентация – покажи это...





Слайд 1

Анализ и Проектирование качественных приложений Презентация по книге Крэга Лармана.


Слайд 2

Книга/Семинар Объектно- ориентированный анализ и проектирование Система обозначений языка UML Анализ требований Итеративная разработка в рамках UP Принципы и рекомендации Шаблоны Книга


Слайд 3

OOA/D/P ?? UML АНАЛИЗ (ANALYSES) – выявление объектов в предметной области. ПРОЕКТРОВАНИЕ (DESIGN) – выявление программных объектов и взаимодействий. ПРОГРАММИРОВАНИЕ (PROGRAMMING) – реализация. С одной стороны: С другой стороны (3 способа использование UML) (perspectives): ДЛЯ ЧЕРНОВИКОВ – построение первых моделей, анализ системы (conceptual perspective). ДЛЯ СОЗДАНИЯ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ – использования части диаграмм для написания кода, или восстановление по по коду диаграммы – (specification perspective) КАК ЯЗЫК ПРОГРАММИРОВАНИЯ – полные выполняемые спецификации программных систем на UML. (implementation perspective).


Слайд 4

Унифицированный процесс Гибкость + открытость (XP, Scrum) Итеративность (iterative development) ООА/П (UML)


Слайд 5

Итеративная разработка Требования Проектирование Реализация & Тестирование & Интеграция & Дальнейшее проектирование Окончательная интеграция & Системное тестирование Требования Проектирование Реализация & Тестирование & Интеграция & Дальнейшее проектирование Окончательная интеграция & Системное тестирование Время 3 недели (например) Время …


Слайд 6

Пример использования итеративной разработки 1 день – обсуждение требований, один человек – по коду составляет диаграмму, которые анализируется в дальнейшем. Остальное время – реализация, тестирование, проектирование, планирование следующей итерации Также осуществляет обратная связь с заказчиками.


Слайд 7

Преимущества итеративной разработки Осознание риска ? риск снижается Быстрый прогресс системы Ранняя обратная связь Управляемая сложность Опыт каждой итерации


Слайд 8

Гибкие методы (agile development) МАНИФЕСТ: Люди и взаимодействие – а не процессы и средства Работоспособное ПО, а не исчерпывающая документация Сотрудничество с потребителями, а не обсуждение контракта Реакция на изменения, а не следование плану


Слайд 9

Секрет разработчиков UML – основная цель моделирования – понять, а не документировать


Слайд 10

Дисциплины UP Бизнес-моделирование (business modeling) Требования (requirements) Проектирование (design)


Слайд 11

Бизнес-моделирование Видение Реальный ли проект? Купить или разработать? Сумма? Стоит ли браться? НЕ ОЦЕНКА ТРЕБОВАНИЙ!!!!


Слайд 12

Артефакты business-modeling Видение и финансовые оценки Прецеденты Доп. Спецификация Словарь терминов Перечень рисков и план управления Прототипы и идеи План итерации План на следующую фазу Инструменты


Слайд 13

Требования FURPS+ Функциональность Удобства Надежность Производительность Поддержка + Реализация Интерфейс


Слайд 14

Проектирование Прецеденты Предметная область Диаграмма взаимодействий Диаграмма классов


Слайд 15

Прецеденты Игра в кости. Игрок отправляет запрос на выбрасывание костей. Система представляет результаты игры: если сумма очков составляет 7, игрок считается победителем, в противном случае – проигравшим.


Слайд 16

Модель предметной области Player name Die DiceGame бросает включает играет 1 1 1 2 2 1


Слайд 17

Диаграмма взаимодействия play() roll() roll() fv1= getFaceValue() fv2= getFaceValue() DiceGame d1: Die d2: Die


Слайд 18

Диаграммы классов 1 2 DiceGame DiceGame die1 : Die die2 : Die play() faceValue : int getFaceValue : int roll()


×

HTML:





Ссылка: