'

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

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





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


×

HTML:





Ссылка: