Преподаватель который помогает студентам и школьникам в учёбе.

ПРИМИНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕЕКТИРОВАНИИ ИНФОРМАЦТОННОЙ СИСТЕМЫ

Содержание:

Введение

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

Создание программных систем ставит перед разработчиками много проблем, часть из которых не может эффективно решаться средствами структурного подхода.

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

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

Объектом исследования данной работы является объектно-ориентированный подход к проектированию информационных систем.

Цель данной работы является обзор и анализ основных принципов и особенностей объектно-ориентированного подхода.

Глава 1. Методология и структура объектно-ориентированного проектирования.

Методологии объектно-ориентированного проектирования

Методология Object Modeling Technique (OMT) – поддерживает стадии анализа требований и проектирования. Опирается данная методология на продукт OMTTool, который позволяет разрабатывать модели в интерактивном режиме, с поддержкой многооконного графического редактора. Таким образом, после получения полного набора диаграмм можно предварительно оценить свойства будущей реализации.

Методология Structured Analysis/Structured Design (SA/SD) – содержит варианты обозначений для описания систем. Основу данной методологии составляют диаграммы потоков данных, которые моделируют преобразования данных при их прохождении через систему, диаграммы состояния, которые выполняют такую же роль, что и динамическая модель в методологии OMT и диаграммы зависимости, отражающие зависимости между хранилищами данных. В этой методологии организованы этапы структурного анализа (SA) и структурного конструирования (SD). Является первым хорошо продуманных формальных подходов к разработке систем.

Методология Jackson Structured Development (JSD) - разработана Джексоном в 80-ых годах. Не делает различий между этапами анализа и разработки, объединив в один общий этап разработки спецификаций проектируемой системы. Модели JSD описывают реальный мир в объектах, действиях и их последовательностях. Разработка по данной методологии включает:

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

Методология Object-Oriented System Analysis (OSA) – обеспечивает анализ систем, но не содержит возможностей этапа разработки. Поддерживает следующие представления модели:

Модели зависимостей между объектами – рассматривают объекты, отношения и ограничения.
Модели поведения объектов – представляют диаграммы состояний объектов.
Модели взаимодействия объектов – представляют набор представлений системы, на которых показаны взаимодействия объектов.

Методология Rational Unified Process (RUP) основными принципами которой являются:

Итерационный и наращиваемый подход к созданию ПО
Планирование и управление проектами на основе функциональных требований
Построение систем на базе архитектуры ПО.

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

Методология Oracle – комплекс методов, охватывающий большинство процессов жизненного цикла ПО. В состав методологии входят:

Custom Development Method (CDM) – разработка ПО
Project Management Method (PJM) – управление проектом
Application Implementation Method (AIM) – внедрение ПО
Business Process Reengineering (BPR) – реинжиниринг бизнес процессов
Organizational Change Management (OCM) – управление изменениями

В соответствии с CDM жизненный цикл ПО формируется из этапов:

Определение требований (стратегия)
Формулирование требований к системе (анализ)
Преобразование требований в спецификации системы (проектирование)
Написание приложений (реализация)
Подготовка к началу эксплуатации (внедрение)
Эксплуатация

Компания Computer Associates разработала комплексы инструментальных средств поддержки процессов жизненного цикла ПО:

All Fusion Modeling Suite – комплекс CASE-средств включающий продукты:

BPwin - функциональное моделирование
ERwin - моделирование данных
Paradigm Plus -объектно-ориентированный анализ и проектирование с помощью UML
Model Mart - организация совместной работы разработчиков)
ERwin Examiner - проверка структуры и качества моделей

AllFusion Change Management Suite – средства управления конфигурацией и изменениями
AllFusion Process Management Suite – средства управления процессами и проектами.

Model Mart должен удовлетворять следующим требованиям:

Совместное моделирование – каждый участник должен иметь инструмент поиска и доступа интересующей его модели в любой момент времени. При этом используется три режима:

Незащищенный – пользователи могут работать с общими моделями в любое время
Защищенный – позволяет изменять модель, только одному пользователю, не позволяя, изменять ее другим
Режим просмотра – запрещает любое изменение модели

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

Все эти варианты объектно-ориентированного подхода объединяют основополагающие принципы:

Инкапсуляция
Наследование
Полиморфизм
Абстрагирование
Модульность
Иерархия

Основные принципы и понятия объектно-ориентированного проектирования

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

Объектная модель является Основой объектно-ориентированного подхода и обладает следующими обязательными принципами:

• Абстрагирование – этот способ позволяет выделять характеристики объекта, которые отличают его от других объектов, четко определяя особенности данного объекта. Этот принцип концентрирует внимание на внешних особенностях объекта, позволяя отделять самые важные особенности его поведения от деталей их реализации. Главной задачей объектно-ориентированного проектирования является, выбор набора абстракций для заданной предметной области.

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

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

• Модульность – этот принцип позволяет произвести декомпозицию системы на модули, связанные между собой. Это свойство позволяет уменьшить сложность системы и позволяет детальнее проработать ее отдельные части.

• Иерархия - этот принцип позволяет разложить абстракции по уровням. Различают два основных вида иерархических структур:

структура классов
структура объектов

Так же к объектно-ориентированному проектированию относятся следующие не обязательные принципы:

• Типизация – это ограничение классов объектов, препятствующее взаимозаменяемости различных классов. Позволяет защититься от использования объектов одного класса вместо другого.

• Параллелизм - свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.

• Устойчивость - свойство объекта существовать во времени и в пространстве.

Основные понятия объектно-ориентированного подхода:

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

1. состоянием – характеризующим, перечень всех свойств объекта и их текущих значений.
2. поведением – характеризующее, воздействие объекта на другие объекты, относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, действия объекта полностью определяют его поведение.
3. индивидуальностью - свойство, которое отличает его от других объектов

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

Полиморфизм – способность скрывать множество реализаций под под одним общим именем или интерфейсом. Так же это понятие может быть интерпретировано, как способность класса принадлежать более чем одному типу.

Наследование – позволяет строить новые классы на основе существующих с возможностью добавления и переопределения методов.

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

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

Достоинства Объектно-ориентированного проектирования:

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

Где есть плюсы, там есть и минусы, поэтому стоит выделить и недостатки данного подхода:

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

Архитектура информационных систем

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

Системная архитектура – используется для управления этим точками зрения, тем самым управляя процессами разработки. Архитектура – это набор существенных решений относительно:

Организации системы
Выбора составляющих систему элементов и интерфейсов
Поведения элементов
Объединения элементов и их поведения в более крупные подсистемы
Архитектурного стиля

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

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

С точки зрения проектирования (словарь и функциональность)
С точки зрения реализации (сборка системы, управление конфигурацией)
С точки зрения процессов (производительность, масштабируемость, пропускная способность)
С точки зрения развертывания (топология системы, распределение, поставка, установка)
С точки зрения вариантов использования (поведение)

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

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

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

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

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

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

1.4 Жизненный цикл программного обеспечения информационных систем

Жизненный цикл – это линия жизни программного обеспечения информационной системы длиною от момента принятия решения о создании до полного выхода из эксплуатации. Жизненный цикл базируется на трех группах процессов:

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

Разработка – это все процессы по созданию программного обеспечения, которые обычно включают: анализ, проектирование и реализацию.

Эксплуатация - это внедрение компонентов ПО в эксплуатацию

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

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

Существуют модели, определяющие порядок исполнения этапов и критерии перехода по этапам. Большее распространение получили три вида моделей:

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

Накопление и повторное использование средств
Развитие и модификация ПО в процессе проектирования
Анализ риска в процессе проектирования

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

1.5 Общая характеристика и классификация CASE-средств

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

Основными особенностями CASE-средств являются:

- - Наличие графических средств
  - Интеграция отдельных компонентов
  - Использование хранилища проектных метаданных (репозитория)

Компонентами интегрированного CASE-средства являются:

Репозиторий (основа CASE-средства) – обеспечивает хранение проекта и его компонентов.
Графические средства – используются для создания диаграмм.
Средства разработки
Средства управления требованиями, конфигурацией и проектом
Средства тестирования и документирования

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

Графические средства позволяют:

Создавать иерархические диаграммы
Создавать и редактировать объекты на диаграммах
Создавать, перемещать и выравнивать группы объектов
Сохранять связи между объектами при их перемещении или изменении
Контроль ошибок

Классифицируются CASE-средства по типам и категориям. Классификация по типам отражает функциональную ориентацию на процессы жизненного цикла и включает типы:

Средства и анализ проектирования – служить для построения и анализа моделей. Целью данных средств являются определение системных требований и свойств, с последующим созданием систем, удовлетворяющим этим требованиям.

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

Классификация по категориям включает

Отдельные локальные средства – решают небольшие задачи
Частично интегрированные средства – охватывают большинство процессов жизненного цикла
Полностью интегрированные средства – охватывают весь жизненный цикл (связаны с репозиторием)

По методам анализа и проектирования CASE-средства можно разделить на:

Структурным
Объектно-ориентированным

Глава 2. Унифицированный язык моделирования UML

2.1 История и основные понятия объектно-ориентированного языка UML

Унифицированный язык моделирования UML (Unified Modeling Language) – это графический язык визуализации, спецификации, конструирования и документирования систем. Этот язык предназначен для разработки информационных систем. С помощью данного языка можно разрабатывать детальный план создаваемой системы, отражающий концептуальные элементы и особенности реализации.

Объектно-ориентированные языки проектирования появились в 70-ых – 80-ых годах. Тогда появились следующие языки моделирования:

Booch – разработанный Грейди Бучем
OOSE (Object-Oriented Software Engineering) – разработанный Айваром Джекобсоном
OMT (Object Modeling Technique) – автором которого стал Джеймс Рамбо
Fusion - разработанный Шлаер-Меллором и Коад-Йордоном

В 90-ых годах при формировании новых идей Буч, Джекобсон и Рабмо, попытались объединить свои методы и попытались создать новый унифицированный язык моделирования, руководствуясь соображениями:

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

Создавая единый унифицированный объектно-ориентированный язык, они поставили цели:

предоставить пользователям выразительный язык визуального моделирования
предусмотреть механизмы расширяемости
обеспечить независимость языка от других
обеспечить основу для понимания этого языка

Результатом их коалиционной работы стал язык UML, взявший в основу концептуальную модель, включающую следующие составляющие:

- 1. Основные блоки, которые подразделяются на:

Сущности – это абстракции (основные элементы модели), в UML их четыре типа:

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

Интерфейс – операции предоставляющие сервис, какому-либо классу. Графически изображается в виде круга с именем

Кооперация – определяет взаимодействия. Графически изображается в виде пунктирного эллипса с именем.

Прецедент – описание последовательности действий. Изображается в виде эллипса.

Активные классы, компоненты и узлы – подобны классам, описывают с общими атрибутами.
Поведенческие – динамические составляющие модели, описывающие поведение модели во времени и пространстве. Существует два типа таких сущностей:
Взаимодействие – поведение обмена сообщениями между объектами. Наглядно оно отображается в виде стрелки с именем операции.

Автомат – это алгоритм поведение объекта или взаимодействия на протяжении всего жизненного цикла. Изображается в виде прямоугольника с закругленными углами и именем состояния.

Группирующие – составляют организующую часть модели. В этот тип сущностей входит «ПАКЕТ», представляющий универсальный механизм группировки элементов в группы. Изображается как папка с закладкой, содержащая имя (иногда содержимое).

Аннотационные – пояснительные сущности, предоставляющие дополнительное описание к любому элементу модели. Графически выглядит, как прямоугольник с загнутым краем, содержащий комментарий.

Отношения – связывают сущности, Подразделяются на четыре типа:

Зависимость – семантическое отношение между сущностями, при котором изменение независимой, повлияет на семантику зависимой. Изображается в виде пунктирной стрелки.
Ассоциации – структурное отношение, предназначенное для описания связей. Изображается в виде прямой линии (иногда со стрелкой), рядом с которой размещаются дополнительные обозначения
Обобщение – это отношение элемента «потомка» к элементу «родитель». Графически этот элемент выглядит как стрелка с не закрашенным наконечником, указывающим на «родителя».
Реализация – показывает семантическое отношение классификаторов. На диаграммах рисуется в виде пунктирной стрелки с прозрачным наконечником.

Диаграммы – группируют сущности. Основными в языке UML являются диаграммы:

Диаграмма классов – этот тип диаграмм используется при проектировании чаще всего, показывает классы, интерфейсы, объекты, кооперации и отношения между ними. Соответствует статическому виду системы с точки зрения проектирования.
Диаграмма объектов – показывает объекты и отношения между ними. Так же как и диаграммы классов относятся к статическому виду систем с точки зрения проектирования.
Диаграммы прецедентов – показаны прецеденты и актеры, а так же отношения между ними. Относятся к статическому виду систем с точки зрения прецедентов использования. Полезны для моделирования поведения систем.
Диаграммы взаимодействия отражают связи, между объектами охватывая сообщения, которыми объекты обмениваются. Являются динамическим видом систем.
Диаграмма последовательности - отражает временную упорядоченность сообщений.
Диаграммы кооперации - показывает структурную организацию объектов обменивающихся сообщениями.

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

Диаграмма состояний – представляет собой автомат, состоящий из состояния, переходов, событий и видов действий. Относятся к динамическому виду систем. Этот тип диаграмм важен при моделировании поведения интерфейса, класса или кооперации.
Диаграмма деятельности – отражает переходы потока управления от одной деятельности к другой внутри системы. Относится к динамическому виду систем. Эти диаграммы наиболее важны при моделировании функционирования системы и отражают поток управления между объектами.
Диаграмма компонентов – представляет организацию компонентов и зависимости между ними. Относятся к статическому виду системы с точки зрения реализации.
Диаграмма развертывания представляет конфигурацию обрабатывающих узлов системы и размещенных в них компонентов. Относятся к статическому виду архитектуры системы с точки зрения развертывания.
- 1. Правила сочетания
  2. Некоторые общие механизмы

В языке UML имеется набор правил, называемый семантическим, который корректно определяет:

Имена сущностей
Область действия
Видимость
Целостность
Выполнение

Основные составляющие диаграмм UML

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

Атрибут – это свойство класса, включающее в себя множество значений. Количество атрибутов для класса не ограниченно, так же не допускается их полное отсутствие. Атрибуты вписываются в следующий отсек прямоугольника под именем класса, при этом записываются только имена атрибутов. Описывая атрибуты, можно указывать их класс и тип. Пример отображения имени и атрибутов на диаграммах приведен на рисунке ниже.

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

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

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

Тип – это стереотип класса, который используется для определения области значений объектов вместе с их операциями

Роль - это поведение сущности в данном контексте.

Графически интерфейс изображается в виде кружочка с именем данного интерфейса.

Для того чтобы отличить интерфейс от класса, в начало его имени добавляют «I», тоже самое делают и с типами добавляя в начало «T».

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

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

+ (плюс) - открытый элемент (все открытые элементы составляют интерфейс пакета)

# - защищенный элемент

- (минус) – закрытый элемент

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

Состояние объекта – совокупность свойств и текущих значений. В свойства входят: атрибуты объекта все его агрегированные части.

Диаграммы объектов

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

Диаграммы объектов содержат множество экземпляров сущностей, представленных на диаграммах классов. Эти диаграммы выражают статическую составляющую взаимодействия и состоят из работающих вместе объектов, однако сообщения, передающиеся от объекта к объекту, не показываются.

Графически диаграмма объектов – это граф, состоящий из вершин и ребер. Имеет такие же свойства, как и диаграммы других типов, а именно название и графическое содержание (проекцию модели). Отличает диаграмму объектов от других, ее содержание, потому как они содержат:

Объекты
Связи

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

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

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

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

Кооперация – это сообщество с определенными ролями объектов, совместное поведение которых более значимо, чем сумма его слагаемых.

Роли – это прототипы классов, компонентов, интерфейсов, прецедентов и узлов, аспекты которых визуализируются, конструируются, специфицируются и документируются в виде потоков управления.

Взаимодействия моделируются двумя методами:

Концентрируясь на временной упорядоченности сообщений
Концентрируясь на последовательность сообщений в контексте структуре объекта.

Статические аспекты системы в UML моделируются с помощью диаграмм классов и объектов, а динамические аспекты с помощью взаимодействий и автоматов.

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

Взаимодействия анализируют потоки по двум критериям:

Сосредотачиваясь на последовательности сообщений
Сосредотачивая внимание на структурных отношениях между связанными объектами.

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

Сообщение – это действие обмена данными, при котором передается информация, в ответ на которую должны последовать определенные действия.

Связь - это семантическое соединение между объектами, представляет экземпляр ассоциации. Для подробной спецификации связей используют стандартные стереотипы:

Association – объект видим для ассоциации
Self – объект видим, так как является диспетчером для ассоциации
Global – объект видим глобально
Local – объект видим локально
Parameter – объект виден, потому что является параметром

Действия, являющиеся результатом сообщения – это исполняемое предложение, которое может привести к изменению состояния объекта.

UML позволяет выполнять несколько видов действий:

Call – вызвать

Return – вернуть

Send – послать

Create – создать

Destroy – уничтожить

При посылке сообщения от объекта к объекту возникает последовательность, которая имеет начала в некотором процессе и продолжается, пока владеющий ей процесс существует

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

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

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

Сообщения и объекты во взаимодействии визуализируются двумя способами:

Концентрируя внимания на временном порядке сообщений (называется диаграммой последовательности)
Акцентируя внимание на структурной организации объектов присылающих и отправляющих сообщения (является разновидностью диаграмм коопераций)

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

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

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

Системы взаимодействуют с актерами (люди, программы) – которые используют ее в своих целях.

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

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

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

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

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

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

Для реализации прецедента необходимо создать сообщество классов и других элементов. Такое сообщество в UML называется кооперацией.

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

2.4 Диаграммы прецедентов

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

Диаграммы прецедентов, имеют стандартные свойства присущие любой диаграмме – имя, графическое содержание. Отличает диаграмму прецедентов конкретное содержание и обычно включают:

Прецеденты
Актеры
Отношения

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

для моделирования контекста системы
для моделирования требований к системе

Требования – это особенности проекта, свойства или поведения. Система должна полностью выполнять все требования, делая это предсказуемо и надежно. При этом внимание надо концентрировать не на том, как именно система выполняет задачи, а только на том, что она будет делать.

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

1. Диаграмма взаимодействий

К диаграммам взаимодействия относятся пять видов диаграмм: последовательности, кооперации, деятельности, состояния и прецедентов.

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

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

Объекты
Связи
Сообщения

Диаграммы последовательностей отличаются от диаграмм коопераций особенностями:

Линией жизни объекта (линия отражающая существование объекта во времени)
Фокус управления (промежуток времени, в который объект выполняет действия).

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

1. Инструменты для создания диаграмм

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

Использовать предопределенные фигуры Visio Professional, которые позволяют быстро и просто создавать информационные диаграммы

Включать внешние источники данных и хранилищ
Легко рисовать диаграммы сетевых ресурсов
Документировать структуру веб-сайтов
Создавать отчеты
Сохранять диаграммы как веб-страницы

По словам разработчиков, причинами для использования данной программы являются:

Документирование и анализ бизнес-процессов
Отслеживание комментариев членов команды
Поддержка Tabble PC
Инструменты для мозгового штурма
Создание календарей
Поддержка множества языков
Простое создание и редактирование диаграмм
Интеграция с другими приложениями MS

Другим распространенным средством создания диаграмм является программный продукт Rational Rose, в котором модели могут представляться с четырех точек зрения:

Use case View – описывает, как проект выглядит с точки зрения его использования. Показывает, кто и куда вводит данные, что после этого делает программа и кому передается результат.
Logical View - описывает логику программы (классы, свойства и отношения между ними).
Component View – показывает компоненты проекта и их содержимое. Проектируются модули и зависимости, переходы от главной программы к подпрограммам
Deployment View – помогает продумывать расположение физических устройств и связей между ними.

На ранних этапах проектирования Rational Rose может существенно облегчить взаимопонимания заказчика и проектировщика, так как продукт является довольно комплексным многогранным, а четка и аккуратная диаграмма облегчает восприятие заказчика.

Третьей по популярности программой для создания диаграмм является продукт StarUML, достоинствами которой являются:

Совместимость с метамоделью и диаграммами стандарта UML 2.х
Поддержка диаграмм привязки сущностей, потоков данных и диаграмм блок-схем
Кросс платформенная поддержка
Все диаграммы, тексты и значки являются четкими и могут экспортироваться в изображения высокого разрешения
Легко обнаруживает и устанавливает сторонние расширения
Поддерживает быстрое моделирование, благодаря сокращениям в Quick Edit
Поддерживает разработку кода на языках программирования, таких как JAVA, C++, C# и др.
Поддерживает экспорт диаграмм в формат PDF для вывода их на печать

Заключение

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

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

Список литературы

Г. Буч, Д. Рамбо, И. Якобсон. Язык UML. Руководство пользователя – М: ДМК Пресс, 2006. 496 стр.

А.М. Вендров, CASE-технологии. Современные методы и средства проектирования информационных систем. – М: финансы и статистика, 1998 год, 98 стр.

Интернет