19. Моделирование взаимодействий в объектно-ориентированном проектировании.
Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:
в форме диаграммы последовательностей (sequence diagram), показывающей последовательность взаимодействий на графе;
в форме кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме.
В диаграмме последовательностей взаимодействие объектов отображается в виде стрелки между объектами, которая соответствует событию или сообщению от одного объекта к другому, вызывающему выполнение метода, реагирующего на событие (сообщение) объекта. Номер стрелки соответствует номеру события в последовательности. Пример диаграммы последовательностей представлен на рис. 13.13.
Рис. 13.13. Диаграмма последовательностей для прецедента Выполнение заказа клиент.
Диаграмма кооперативного поведения представляется в табличном виде по следующим правилам.
В столбцах таблицы указываются объекты всех типов, участвующие в реализации прецедента использования. Порядок расположения активных и пассивных объектов произволен и должен быть удобен для понимания модели. Актеры прецедента использования отображаются на правой и левой границах таблицы.
По горизонтали проводятся поименованные стрелки, отражающие взаимодействие (коммуникацию) объектов в рамках одной операции. Эта стрелка означает, что первый объект в рамках выполняемой операции посылает сообщение второму объекту о необходимости выполнения действия. При получении сообщения второй объект выполняет действие.
На пересечении строк и столбца вертикально отображается условный отрезок времени, в течение которого выполняется то или иное действие над объектом.
Пример кооперативной диаграммы представлен на рис. 13.14.
Рис. 13.14. Диаграмма кооперативного поведения для основного потока событий прецедента использования Выполнить заказ
20. Общая характеристика case-средств. Архитектура case-средства.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл.
В настоящее время под термином CASE (Computer Aided Software Engineering) понимают автоматизированный процесс проектирования ИС.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для разных аппаратных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Выделим преимущества CASE технологии по сравнению с традиционной технологией проектирования:
– улучшение качества разрабатываемой ИС за счет средств автоматического контроля и генерации;
– возможность повторного использования компонентов разработки;
– поддержание адаптивности и сопровождения ИС;
– снижение времени создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его;
– освобождение разработчиков от рутинной работы по документированию проекта, т.к. при этом используется встроенный документатор;
– возможность коллективной разработки ИС в режиме реального времени.
Любое CASE-средство состоит из репозитория, графических средств моделирования, верификатора диаграмм, документатора проекта, администратора проекта и сервиса.
Ядром системы является репозиторий проекта. Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации репозитория. В репозитории хранятся описания следующих объектов: самих проектировщиков и их прав доступа к различным компонентам системы; организационных структур; диаграмм; компонентов диаграмм; связей между диаграммами; структур данных; программных модулей; процедур и т.д.
Графические средства моделирования предметной области позволяют разработчикам ИС в наглядном виде изучать существующие прототип, перестраивать его в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в интерактивном режиме, вводятся в репозиторий, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений.
Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ИС.
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например, по времени, по автору, по элементам диаграмм, по диаграмме или по проекту в целом.
Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций: инициализации проекта, задания начальных параметров проекта, назначения и изменения прав доступа к элементам проекта, мониторинга выполнения проекта.
Сервис представляет собой набор системных утилит по обслуживанию репозитория. Эти утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория.
21. Классификация CASE-средств. Аспекты CASE-средств. ( если САПР=CASE)
Современные CASE-системы классифицируются по следующим признакам:
1) по поддерживаемым методологиям проектирования: функционально-ориентированные, объектно-ориентированные и комплексно-ориентированные;
2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) по степени интегрированности: tools – отдельные локальные средства; toolkit – набор неинтегрированных средств, охватывающих большинство этапов разработки ИС; workbench – полностью интегрированные средства, связанные репозиторием;
4) по типу и архитектуре вычислительной техники: ориентированные на локальное рабочее место; ориентированные на локальную вычислительную сеть; ориентированные на глобальную вычислительную сеть;
5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку; ориентированные на режим реального времени разработки проекта; ориентированные на режим объединения подпроектов;
6) по типу операционных систем и аппаратных платформ: работающие только в одной операционной системе; работающие в нескольких операционных системах, но на одной аппаратной платформе; работающие на разных аппаратных платформах.
по этапам процесса проектирования ИС: выделяют системы поддерживающие
7.1 Анализ и проектирование (BPWin, Rational Rose, Silverrun);
7.2 Проектирование БД и файлов (ERWin, Silverrun - ERX, PowerDesigner);
7.3 Программирование;
7.4 Сопровождение и реинжиниринг(ИС);
7.5 Окружение (платформа);
7.6 Управление проектом (MS Project);
7.7 Реинжиниринг бизнес процессов (BPWin).
Аспекты, которые необходимо учитывать при выборе САПР:
Наличие базы проектных данных, архива и репозитория. СУБД или репозиторий обеспечивают высокую степень интеграции данных и предоставляют широкие возможности доя централизированного сбора, хранения и распространения проектной информации между различными этапами проекта и выполняемыми операциями.
В процессе проектирования ИС могут использоваться разные методологии, поэтому важно, чтоб используемые САПР предоставляли возможности для эффективного использования методологий. При этом должна быть учтена терминологическая совместимость методологий.
Возможность экспорта – импорта. Спецификации, полученные на этапе анализа, проектирования и кодирования для одной ИС могут быть использованы для проектирования другой ИС.
Повторные проектирование и кодирование могут быть осуществлены в другую САПР, поэтому необходимо осуществить экспорт и импорт спецификаций между различными САПР.
Многопользовательский режим. Развитые САПР должны обладать возможностью разделения полномочий разработчиков и объединения отдельных работ в общий проект.
Открытая архитектура. Вся возможная информация об используемых форматах файлов и интерфейсов должна позволять адекватно переходить от одной системы к другой.
Расширение системы. САПР должна обладать возможностью обновления с учетом появления новых требований.
Наличие графических средства поддержки методологии проектирования. Графические элементы структурных диаграмм должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.
Обеспечение качества проектной документации. Относится к возможностям систем автоматизированного проектирования. Анализировать и проверять описание и документацию на полноту и непротиворечивость, а также на соответствие принятых в данной методологии стандартам и правилам.
Автоматическая генерация отчетов о проектных решениях. Т.е., спецификации, созданные в процессе проектирования служат источником документации систнмы.
Генерация подпрограмм. САПР с жесткой ориентацией на конкретную СУБД должна обеспечивать возможность генерации программ в среде этих СУБД.
Планирование и управление проектом. Использование САПР не исключает потребности в эффективном управлении проектом. Многие развитые САПР имеют в своем составе средства планирования и управления проектом, спецификации которых используются этими средствами, представляют собой опорные точки управления, позволяющие определить сроки разработки.