- •Проектирование информационных систем
- •Вопрос 1. Обязанности, методы, взаимодействия
- •Вопрос 2. Шаблоны
- •Information Expert
- •Шаблон Information Expert
- •Шаблон Creator
- •Шаблон Low Coupling
- •Шаблон High Cohesion
- •Шаблон Controller
- •Вопрос 3. Реализация прецедентов
- •Пример: Реализация прецедентов для данной итерации разработки pos системы тт
- •Проектное решение: makeNewSale
- •Выбор класса-контроллера
- •Проектное решение: enterItem
- •Проектное решение: endSale
- •Проектное решение: makePayment
- •Проектное решение: startup
- •Проектное решение: store-create
- •Подключение уровня интерфейса пользователя к уровню предметной области
Федеральное государственное образовательное учреждение
высшего профессионального образования
«Пермская государственная сельскохозяйственная академия
имени академика Д.Н. Прянишникова»
Проектирование информационных систем
специальность 080801 «Прикладная информатика (в экономике)»
Лабораторная работа № 10
Тема: МОДЕЛЬ ПРОЕКТИРОВАНИЯ: РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТОВ НА ОСНОВЕ ШАБЛОНОВ GRASP
Учебные вопросы:
Обязанности, методы, взаимодействия.
Шаблоны.
Реализация прецедентов.
Литература, техническое и программное обеспечение:
Методическая разработка по теме занятия.
Класс ПЭВМ.
Основные задачи
Спроектировать реализации прецедентов.
Применить шаблоны GRASPдля распределения обязанностей между классами.
Использовать обозначения диаграммы кооперации для иллюстрации взаимодействия объектов.
Введение
В этой лабораторной работе рассматривается проектирование взаимодействующих классов, выполняющих определенные обязанности. Особое внимание уделяется применению шаблонов GRASPдля разработки удачного проектного решения. Стоит заметить, что шаблоныGRASPсами по себе не очень важны, они лишь облегчают общение между разработчиками и позволяют методически проектировать объекты.
В этой лабораторной работе на примере POS-системы ТТ обсуждаются принципы, на основе которых разработчик распределяет обязанности между объектами и определяет механизмы их взаимодействия. В процессе разработки объектно-ориентированных систем эти вопросы являются наиболее важными.
Распределение обязанностей и проектирование взаимодействия объектов – наиболее важные "творческие" факторы процесса проектирования. Они чрезвычайно важны как для построения диаграмм, так и для программной реализации.
Вопрос 1. Обязанности, методы, взаимодействия
Процесс объектного проектирования иногда описывают следующим образом:
«Сначала определяются требования, и создается модель предметной области, затем добавляются методы программных классов, описывающие передачу сообщений между объектами для удовлетворения требованиям».
Такое описание мало полезно на практике, поскольку в нем не учтены глубинные принципы и вопросы, лежащие в основе этого процесса. Вопрос определения способов взаимодействия объектов и принадлежности методов чрезвычайно важен и отнюдь не тривиален.
Принципы объектного проектирования отражены в шаблонах проектирования GRASP, изучение и применение которых позволит освоить методический подход к процессу разработки.
Аббревиатура GRASPозначаетGeneral Responsibility Assignment Software Patterns(Общие шаблоны распределения обязанностей в программных системах).
Шаблоны GRASPпозволяют понять основные принципы объектного проектирования и методично применять их. Эти шаблоны называют такжешаблонами распределения обязанностей(patternofassigningresponsibilities).
Обязанности и методы
В UMLобязанность(responsibility) определяется как "контракт или обязательство классификатора". Обязанности описывают поведение объекта. В общем случае можно выделить два типа обязанностей:
Знание (knowing).
Действие (doing).
Обязанности, относящиеся к действиям объекта:
Выполнение некоторых действий самим объектом, например, создание экземпляра или выполнение вычислений.
Инициирование действий других объектов.
Управление действиями других объектов и их координирование.
Обязанности, относящиеся к знаниямобъекта:
Наличие информации о закрытых инкапсулированных данных.
Наличие информации о связанных объектах.
Наличие информации о следствиях или вычисляемых величинах.
Обязанности присваиваются объектам в процессе объектно-ориентированного проектирования. Обязанности, относящиеся к разряду "знаний", зачастую вытекают из модели предметной области, поскольку она иллюстрирует атрибуты и ассоциации.
Например, можно сказать, что объектSaleотвечает за создание экземпляраSalesLineItem(действие) или что объектSaleотвечает за наличие информации о стоимости покупки (знание).
Возможность реализации обязанностей в виде классов и методов зависит от точности их описаний.
Например, реализация обязанности "обеспечения доступа к реляционным базам данных" может потребовать создания десятков классов и сотен методов, а для реализации обязанности "создания экземпляра объектаSale" достаточно одного или нескольких методов.
Между методами и обязанностями нельзя ставить знак равенства, однако можно утверждать, что реализация метода обеспечивает выполнение обязанностей.Обязанности реализуются посредством методов, действующих либо отдельно, либо во взаимодействии с другими методами и объектами.
Например, для классаSaleможно определить один или несколько методов вычисления стоимости (скажем, методgetTotal). Для выполнения этой обязанности объектSaleдолжен взаимодействовать с другими объектами, в том числе передавать сообщенияgetSubtotalкаждому объектуSalesLineItemо необходимости предоставления соответствующей информации этими объектами.
Обязанности и диаграммы взаимодействий
В контексте артефактов UML обязанности (реализованные в виде методов) рассматриваются в процессе создания диаграмм взаимодействия (относящихся к модели проектирования), система обозначений которых рассматривалась в предыдущей лабораторной работе.
Из рис. 1.1 видно, что обязанностью объектов Saleявляется создание экземпляровPayment. Для выполнения этой обязанности передается сообщение, реализуемое посредством методаmakePayment. Более того, для ее выполнения требуется взаимодействие с объектами SalesLineItem и вызов их конструктора.
Рисунок 1.1 – Связь методов и обязанностей
Итак, диаграммы взаимодействий отражают распределение обязанностей между объектами. Распределенные обязанности отображаются в виде сообщений, отправляемых различным классам объектов.