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 12 2 1

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

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