Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы и ответы_ Инструментальные средства информационных систем.docx
Скачиваний:
168
Добавлен:
29.05.2017
Размер:
1.16 Mб
Скачать
  1. Uml 2.0. Ментальные карты.

UML 2.0.

  • диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

  • диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;

  • диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

  • диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

  • диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

Поведенческие диаграммы:

  • диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;

  • диаграммы случаев использования(use case diagrams) предназначены для "вытягивания" требований из пользователей, заказчика и экспертов предметной области;

  • диаграммы конечных автоматов (state machine diagrams) применяются для задания поведения реактивных систем;

  • диаграммы взаимодействий (interaction diagrams):

    • диаграммы последовательностей (sequence diagrams) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;

    • диаграммы схем взаимодействия (interaction overview diagrams) служат для организации иерархии диаграмм последовательностей;

    • диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);

    • временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.

Ментальные карты.

Ментальные карты — это способ записи, альтернативный по отношению к тексту, спискам и схемам (например, «деревьям» или диаграммам связей). Главное отличие ментальных карт от других способов визуализации прежде всего тем, что ментальные карты активируют память.

  1. Архитектурный подход к проектированию ис.

Архитектура предприятия — архитектура, в которой системой является целое предприятие, в частности, бизнес-процессы, технологии и информационные системы

Архитектура предприятия становится информационной основой корпоративной структуры компании. Она преследует две цели: во-первых, дать подробное системное описание самой организации для поддержания порядка ее функционирования, а, во-вторых, иметь стратегический план развития компании, учитывающий существующее внешнее окружение компании и ее техническую и технологическую оснащенность.

Архитектура может быть зафиксирована с помощью полного архитектурного описания. Стандарт ISO/IEC/IEEE 42010-2011

В сложных системах АО может разрабатываться не только для системы в целом, но и для компонентов системы. Два разных концептуальных АО могут включать группы описаний, которые будут соответствовать одному и тому же методу описания.

Непосредственно архитектура предприятия не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом, что связано с повышением степени использования и эффективности информационных систем и программных продуктов, стандартизацией и повторным использованием ИТ-ресурсов, а также, снижением рисков инвестиций в ИТ-сфере.

Существует три типа группы описаний архитектуры: функциональные, логические и физические. Каждая из групп предназначена для описания собственных точек зрения и соответствующего им уровня сложности.

Функциональная

Данная группа обеспечивает представление с точки зрения пользователей или операторов, которое включает продукты, относящиеся к фазам, сценариям и потокам задач операционной системы. Информационный поток может быть рассмотрен с пользовательского ракурса, также описываются и пользовательские интерфейсы. Примером продуктов, которые могут быть включены в это описание, будут функциональные данные или графики, сценарное описание (включая использование кейсов), блок-схемы задач, организационные диаграммы и схемы информационных потоков.

Логическая

Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть: контекстные диаграммы, IDEF0-диаграммы

Физическая

Данная группа обеспечивает представление с точки зрения проектировщиков. Включает в себя:

  • продукты, которые определяют физические границы системы;

  • физические компоненты системы и то, как они взаимодействуют и влияют друг на друга;

  • внутренние базы данных и структуры данных;

  • инфраструктуру информационных технологий (ИТ) системы;

  • внешнюю ИТ-инфраструктуру, с которой система взаимодействует;

  • требования, необходимые для развития системы.

Продукт может включать в себя физические блок-схемы на довольно высоком уровне детализации, топологии базы данных, интерфейс управления документами и стандарты.

Все из трёх типов групп должны присутствовать в каждом описании архитектуры.

Архитектурные описания в ходе жизненного цикла могут различно применяться всеми заинтересованными сторонами. Такие применения включают, но не ограничиваются, следующим:

  • анализ альтернативных архитектур

  • деловое планирование перехода от унаследованной архитектуры к новой;

  • коммуникация организаций, участвующих в разработке, производстве, установке, эксплуатации и обслуживании систем;

  • коммуникация между заказчиками и разработчиками как часть подготовки соглашения;

  • критерии для сертификации соответствия реализации данной архитектуре;

  • документирование разработки и обслуживания, включая подготовку материалов для хранилищ с целью повторного использования и учебных материалов;

  • исходные данные для последующих мероприятий по системному проектированию и разработке;

  • исходные материалы для инструментов создания и анализа системы;

  • эксплуатационная и инфраструктурная поддержка; управление конфигурацией и ремонт; перепроектирование и обслуживание систем, подсистем и компонентов;

  • поддержка планирования и финансирования