- •Теория систем и системный анализ
- •Предисловие
- •Содержание
- •1.1. Структура самостоятельного научного направления
- •1.2. Структура системных исследований
- •1.3. Эволюция системного подхода
- •Вопросы для повторения
- •Резюме по теме
- •Тема 2. Моделирование и анализ систем. Основные подходы
- •2.1. Традиционный системный подход
- •2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа
- •2.1.2. Причины существования проблем традиционного системного подхода и системного анализа
- •2.2. Объектно-ориентированный подход
- •2.2.1. Особенности объектно-ориентированного подхода
- •2.2.2. Необходимость интеграции объектного и системного подходов
- •2.3. Системология – системный подход ноосферного этапа развития науки
- •2.3.1. Основные понятия
- •2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса
- •2.3.3. Системологический и объектно-ориентированный подход
- •Вопросы для повторения
- •Резюме по теме
- •Тема 3. Технологии системного моделирования
- •3.1. Технология системно-структурного моделирования и анализа «3-ViewModeling»
- •3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса
- •Нормативная система
- •Построение модели
- •Словарь данных
- •3 {Болт} 7 – от 3 до 7 итераций
- •1 {Болт} – 1 и более итераций
- •Спецификация процесса
- •3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели
- •Нотация Чена
- •Нотация Баркера
- •Построение модели
- •3.1.3. Диаграммы переходов состояний
- •3.2. Стандарты системного моделирования и анализа серии «IcamDeFinition»
- •3.2.1. Стандарт функционального моделированияIdef0
- •3.2.2. Стандарт информационного моделированияIdef1
- •3.2.3. Стандарт моделирования баз данных idef1x
- •3.2.4. Стандарт моделирования сценариев idef3.
- •3.2.5. Стандарт моделирования онтологий idef5
- •3.3. Case-инструментарий системного моделирования и анализа
- •3.3.1. Назначение и возможности «AllFusionProcessModeler/bPwin»
- •3.3.2. Особенности «bPwin»
- •3.3.3. Недостатки инструментария системного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 4. Технология объектного моделирования и анализа
- •4.1.Uml– язык объектного моделирования
- •4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные
- •Структурные сущности
- •Поведенческие сущности
- •Группирующие сущности
- •Аннотационные сущности
- •4.1.2. Отношения
- •4.1.3. Диаграммы
- •4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства
- •Начальная фаза проекта (Inception)
- •Исследование (Elaboration)
- •Построение (Construction)
- •Внедрение (Transition)
- •Дополнительные средства
- •4.2. Требования к объектному моделированию бизнес-систем
- •4.2.1. Внешняя модель бизнес-системы
- •4.2.2. Внутренняя модель бизнес-системы
- •4.2.3. Пример uml-модели бизнес-системы
- •4.2.4. Пример модели информационного обеспечения бизнеса
- •4.3. Case-инструментарий объектного моделирования и анализа
- •4.3.1. Назначение и возможности «ibm Rational Software Architect»
- •4.3.2. Интерфейс «ibm Rational Software Architect»
- •4.3.3. Представление модели в «ibm Rational Software Architect»: представление вариантов использования; логическое представление; представление компонент; представление размещения
- •Представление вариантов использования
- •Логическое представление
- •Представление компонент
- •Представление размещения
- •4.3.4. Недостатки инструментария объектного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 5. Технология системно-объектного моделирования и анализа
- •5.1. Методология системно-объектного моделирования и анализа
- •5.1.1. Системологический подход «Узел-Функция-Объект»
- •5.1.2. Адаптивная нормативная система уфо-анализа
- •5.1.3. Классификация бизнес-систем
- •5.2. Процедура системно-объектного моделирования и анализа
- •5.2.1 Алгоритм уфо-анализа.
- •5.2.2. Примеры уфо-моделей.
- •5.3. Case-инструментарий системно-объектного моделирования и анализа
- •5.3.1. Назначение и возможности «ufo-toolkit»
- •5.3.2. Особенности функционирования «ufo-toolkit»
- •5.3.3 Технология представление моделей в «ufo-toolkit»
- •Торгово-закупочная деятельность
- •Вопросы для повторения
- •Резюме по теме
- •Вместо заключения
- •Представление dfd-диаграммы с помощью уфо-модели
- •Представление idef0-диаграммы с помощью уфо-модели.
- •Представление bpmn-диаграммы с помощью уфо-модели.
- •Глоссарий
- •Список литературы
Логическое представление
Логическое представление, концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования (прецедентах). Оно дает подробную картину составных частей системы и описывает взаимодействие этих частей. С помощью логического представления разработчики смогут сконструировать детальный проект создаваемой системы.
Логическое представление содержит [82]:
Классы.
Диаграммы классов. Как правило, для описания системы используется несколько диаграмм классов, каждая из которых отображает некоторое подмножество всех классов системы.
Диаграммы взаимодействия, применяемые для отображения классов, участвующих в одном потоке событий варианта использования. Как упоминалось ранее, диаграммы взаимодействия создаются в представлении вариантов использования или в логическом представлении. При этом в первом случае, как правило, на этих диаграммах изображают объекты, а во втором – классы системы.
Диаграммы состояний.
Пакеты, являющиеся группами взаимосвязанных классов. Объединять классы в пакеты не обязательно, но настоятельно рекомендуется. Типичная система может содержать сотню или более классов, и объединение их в пакеты помогает уменьшить сложность вашей модели. Для понимания общей картины системы достаточно просто взглянуть на ее пакеты. Чтобы изучить систему на более детальном уровне, приходится углубляться в пакеты и исследовать классы, находящиеся внутри.
Классы, которые могут появляться на диаграммах взаимодействия в представлении вариантов использования, представляют собой классы анализа. После определения всех классов анализа каждый из них может быть преобразован вкласс проекта. Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. На этапе анализа не важно, на каком языке он будет написан, внимание уделяется только его данным и поведению. Преобразуя его в класс проекта, однако, придется коснуться специфических для языка деталей. Допустим, например, что это будет класс Java. В таком случае для реализации того, что заложено в классе анализа, может понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах взаимодействия логического представления системы.
В этом представлении основное внимание уделяется логической структуре системы. В нем изучаются данные и поведение системы, определяются ее составные части и исследуется взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования. Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимодействия между классами и пакетами, можно определить, какие из них допускают повторное использование. Завершая новые и новые проекты, можно постепенно увеличивать библиотеку повторно используемых классов и пакетов. В результате выполнение будущих проектов будет все более и более становиться процессом сборки целого из имеющихся составных частей, а не разработки этих частей «с чистого листа».
Почти все участники команды, создающей систему, получают пользу от изучения логического представления системы. Взглянув на классы и их диаграммы, аналитики смогут убедиться, что все бизнес-требования будут реализованы в коде. Изучая классы, пакеты и диаграммы классов, специалисты по контролю качества поймут, из каких элементов состоит система и какие нуждаются в тестировании. Из диаграмм состояний они поймут также, как должны вести себя конкретные классы. Менеджер проекта из тех же элементов представления сможет уяснить, хорошо ли структурирована система, а также получить оценку степени ее сложности.
Однако больше всего с этим представлением работают разработчики и архитекторы. Первые смогут понять, какие классы надо создавать, и какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача – добиться того, чтобы архитектура системы была стабильна, но в то же время гибка настолько, чтобы быть адаптируемой к возможным изменениям в требованиях, а также предусмотреть возможность повторного использования.
Определив классы системы на диаграммах, можно приступить к работе с представлением компонентов, имеющим дело с ее физической структурой.