Разработка программных проектов, управляемая моделью (MDD) и унифицированный процесс (UP)
Терминология UP – Unified Process – Унифицированный процесс – один из строгих итеративных подходов к разработке, широко применяемый в контексте объектной методологии разработки ПО. MDD – Model – Driven Development (MDD) – Разработка, управляемая моделью. Подход к разработке, часто исползуемый в Унифицированном процессе (UP) заключается в активном использовании моделей UML в процессе разработки, в достаточно тщательном проектировании классов и их взаимодействий (кооперации). Весь ход разработки и документация сопровождаются UML моделями. Код строится по модели вручную или с помощью CASE-средств. CASE – Computer-Aided Software Engineering – компьютерное обеспечение проектирования ПО (САПР ПО). Специальное ПС для облегчения проектирования ПО и поддержки ЖЦ. Известные CASE-средства для MDD и UP: Rational Rose, UML, Bold for Delphi, Model. Maker …
CASE-средства для MDD и UP Bold for Delphi, Rational Rose UML Model. Maker
Терминология RDD – Requirements Driven-Development – Разработка, управляемая требованиями – принцип разработки, ориентированной на реализацию прецедентов (use-cases - вариантов использования системы или пользовательских историй (в XP)) Артефакт – один из элементов моделируемой на UML системы: исполняемый код, архитектура, тесты, требования к системе и др. Reverse engineering – возвратное проектирование - обновление или построение модели по коду программы вручную или с помощью CASEсредств. Round-trip engineering – циклическое проектирование – поддержание синхронности модели и кода программы вручную или с помощью CASEсредств.
Литература по основам объектного проектирования
Типы диаграмм С помощью набора UML-диаграмм проектировщик разрабатывает модель системы для заданной предметной области. При этом на практике широко применяются следующие типы диаграмм: • • • Диаграммы прецедентов (Use case diagram) Диаграммы Топологии (Deployment diagram ) Диаграммы Состояний(Statechart diagram) Диаграммы Активности (Activity diagram ) Диаграммы взаимодействия(Interaction diagram) Диаграммы последовательностей действий(Sequence diagram) Диаграммы Сотрудничества(Collaboration diagram) Диаграммы Классов(Class diagram) Диаграммы Компонентов(Component diagram)
Диаграммы прецедентов Диаграмма прецедентов позволяет создавать список операций, которые выполняет система. Измерение температуры Датчик температуры Выдача измеренной температуры по запросу Эти диаграммы также называют диаграммами функций, потому что на основе их набора создается общий список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма – это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области. На этих диаграммах отображаются объекты системы и выполняемые ими задачи.
Диаграммы топологии • Процессор • Датчик • Лампа Этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться. Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения. С точки зрения теории конечных автоматов поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: диаграмма состояний и диаграмма активности
Диаграммы состояний Конец работы Начало Ожидание Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения.
Диаграммы активности Начало ? Показатели в норме Настройка Завершение работы Ожидание Диаграммы активности представляют собой дальнейшее развитие диаграммы состояний. Этот тип диаграмм позволяет показать ветвление и даже синхронизацию процессов. Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Диаграммы взаимодействия Включить Контроллер Лампа Этот тип диаграмм включает в себя диаграммы последовательностей действий и диаграммы сотрудничества Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграммы последовательностей действий Контроллер Включить Лампа Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Эти диаграммы не акцентируют внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов.
Диаграммы сотрудничества 1: Включить Контроллер G F Лампа Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
Диаграммы классов В нотации Г. Бучем (Booch) В нотации OMT (Object-Modeling Technique) Контроллер Датчик Лампа Данный тип можно создавать в различных нотациях. В нотации, предложенной Г. Бучем, класс – это лишь шаблон, по которому в дальнейшем будет создан конкретный объект. Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces).
Диаграммы компонентов Package Component Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто эти диаграммы называют диаграммами модулей. При проектировании больших систем, она может оказаться разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей.
Процессы и артефакты MDD в UP 1. Анализ функциональных требований (прецедентов) 2. Анализ прочих требований 3. Диаграммы последовательностей системы 4. Построение модели предметной области 5. Реализация прецедентов и системных операций с помощью диаграмм взаимодействия. Распределение обязанностей. 6. Создание и уточнение программных классов 7. Создание программного кода по описаниям классов и их кооперации. Процессы 5 -7 (или даже 3 -7) повторяются на каждой итерации. Проект архитектуры составляется после анализа и уточняется на каждой итерации фазы развития.
Пример объектного анализа и проектирования – игра в кости (К. Ларман) Определить прецеденты Создать модель Построить предметной диаграммы области взаимодействия Создать диаграммы классов Игра в кости (Dice. Game). Игрок (Player) берет и бросает кости (Die). Если сумма очков составляет 7, игрок считается победителем, в противном случае - проигравшим.
Диаграмма последовательности системы для прецедента (и системной операции) play Player System 1: bool result = play()
Игра в кости – модель предметной области Определить прецеденты Создать модель Построить предметной диаграммы области взаимодействия Player 1 Бросает name Die face. Value 1 Играет 1 Dice. Game 2 Создать диаграммы классов 2 1 Включает face. Value – очки на выпавшей грани
Игра в кости – диаграммы взаимодействия Определить прецеденты Создать модель Построить предметной диаграммы области взаимодействия : Dice. Game play() die 1 : Die roll() Fv 1 : = get. Face. Value() roll() Fv 2 : = get. Face. Value() Создать диаграммы классов die 2 : Die
Игра в кости – диаграммы классов проекта Определить прецеденты Создать модель Построить предметной диаграммы области взаимодействия Dice. Game die 1 : Die die 2 : Die play() Создать диаграммы классов Die 1 2 face. Value : int get. Face. Value() : int roll() Затем по диаграммам классов и взаимодействия создается (вручную или с помощью CASE-средств) код программы
Игра в кости – получение кода public class Die { int face. Value; Die public int get. Face. Value() { face. Value : int } get. Face. Value() : int roll() return face. Value; public void roll() { } } // розыгрыш face. Value // с помощью случайной // величины Random rnd = new Random(); face. Value = rnd. Next(1, 7);
Игра в кости – код интерфейса и ассоциаций класса Dice. Game { Dice. Game die 1 : Die die 2 : Die play() } public class Dice. Game Die die 1; Die die 2; public int play() { //. . . }
На заключительном этапе выполняется создание программного кода по описаниям классов и их кооперации, подготовленных на предыдущих шагах.
Скачать презентацию Разработка программных проектов управляемая моделью MDD и унифицированный
uml1-4 Тыцкий.ppt