37. Язык uml. История создания. Область применения. Виды диаграмм uml для описания системы.
“Унифицированный язык моделирования UML (Unified Modeling Language)—это язык для определения, визуализации, конструирования и документирования артефактов программных систем, а также для моделирования экономических процессов и других не программных систем". UML — это важный фактический и юридический стандарт для ОО моделирования.
CASE-средства, поддерживающие UML (а именно, Rational Rose, Microsoft Visual), являются вспомогательным средством практически на всех этапах анализа и разработки проекта и дают возможность работать со множеством языков программирования, таких как C++, Java, Visual Basic, и других, а также осуществлять генерацию БД на большинстве из существующих SQL-серверов. Модели, разработанные в UML, позволяют значительно упростить процесс кодирования и направить усилия программистов непосредственно на реализацию системы.
UML поддерживает все стадии ЖЦ проекта, его применения достаточно для полной поддержки разработки приложения. Особенность UML в том, что он оптимизирован для применения при разработке программных систем, что дает возможность максимально ускорить разработку программных продуктов и заметно улучшить качество получаемой системы. Описание предметной области с использованием UML хорошо воспринимается экспертам предметной области и не требует от них никакой специальной подготовки для понимания представленных им на рассмотрение моделей.
UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, предлагает следующий набор диаграмм для моделирования:
Диаграмма вариантов использования – для моделирования бизнес-процессов организации (требований к системе);
Диаграмма классов – для моделирования статической структуры классов системы и связей между ними;
Диаграмма поведения системы;
Диаграмма взаимодействия – для моделирования процесса обмена сообщениями между объектами. Существует 2 вида диаграмм взаимодействия:
Диаграмма последовательности;
Кооперативные диаграммы.
Диаграммы состояний – для моделирования поведения объектов системы при переходе из одного состояния в другое;
Диаграмма деятельности – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей;
Диаграмма реализации;
Диаграмма компонентов – для моделирования иерархии компонентов системы;
Диаграмма размещения – для моделирования физической архитектуры системы.
38. Программирование на основе шаблонов (паттернов). Роль шаблонов проектирования в борьбе со сложностью программного обеспечения. Будущее шаблонов.
В ОО технологии проектирования шаблоном называют именованное описание проблемы и ее решение, которые можно применить при разработке других систем. В идеале, шаблон должен содержать советы по поводу его применения в различных ситуациях, а так же описание его преимуществ и недостатков. Шаблон можно назвать новым, если он описывает новую идею. Однако сам термин “шаблон” означает стандартную, повторяющуюся сущность. Шаблоны не предназначены для изучения и выражения новых принципов разработки ПО. Скорее наоборот. Они призваны систематизировать существующие знания, идиомы и принципы. Шаблонам даны имена, чтобы облегчить специалистам их обсуждение. Существует две большие группы шаблонов: GRASP и GoF. GRASP – General Responsibility Assign Patterns:
Information Expert – информационный эксперт;
Creator – создатель;
High Cohesion – высокое зацепление;
Low Coupling – низкая связанность;
Controller – контроллер;
На примере рассмотрим несколько GRASP - шаблонов.
Информационный эксперт: Задача. Каков наиболее общий принцип распределения обязанностей между объектами? Решение. Назначить обязанность информационному эксперту – классу у которого имеется вся информация для выполнения обязанности.
Обычно мы распределяем обязанности между теми служащими, у которых имеется необходимая для выполнения поставленной задачи информация. Например, кто в коммерческом предприятии должен нести ответственность за создание отчета о прибыли и убытках? Тот из служащих, кто имеет доступ ко всей информации, необходимой для создания такого отчета. Программные объекты взаимодействуют между собой и обмениваются информацией так же, как люди. В некоторых ситуациях применение шаблона Expert нежелательно, например, в связи с проблемами со связыванием и зацеплением.
С
Основным назначением шаблона Creator является выявление объекта-создателя, который при возникновении любого события должен быть связан со всеми созданными им объектами. При таком подходе обеспечивается низкая степень связанности.
Контроллер. Задача. Кто должен отвечать за обработку входных системных событий? Решение. Делегировать обязанности по обработке системных сообщений классу, удовлетворяющему одному из следующих условий: 1). класс представляет всю систему в целом, устройство или подсистему (внешний контроллер); 2). класс представляет сценарий некоторого прецедента, в рамках которого выполняется обработка всех системных событий.
Большинство систем получает внешние сообщения. Обычно они связаны с графическим интерфейсом пользователя. Кроме того, системы могут передавать внешние сообщения. В рамках ООПодхода для обработки внешних сообщений применяют шаблон Контроллер, представляющий собой своеобразный интерфейс между уровнями предметной области и представлением пользователя.