Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Основные принципы построения объектной модели).pdf

• проверка соответствия исходного кода программы решениям, принятым на этапах анализа и проектирования;

• перевод исходных кодов программ с одного языка программирования на другой.

Внедрение системы в действие.

• подготовка объекта автоматизации;

• подготовка персонала;

• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

• строительно-монтажные работы;

• пусконаладочные работы;

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

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

• проведение приемочных испытаний.

Сопровождение ИС.

• выполнение работ в соответствии с гарантийными обязательствами

• послегарантийное обслуживание.

​​​​​​​1.3 Основные понятия объектно-ориентированного подхода к проектированию информационных систем

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

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

Структура и поведение схожих объектов определяют общий для них класс.

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

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

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

Результат операции зависит от текущего состояния объекта. Виды операций:

a) Операции реализации– реализуют требуемую функциональность.

b) Операции управления -управляют созданием и уничтожением объектов (конструкторы и деструкторы).

c) Операции доступа – дают доступ к закрытым атрибутам.

d) Вспомогательные операции (как правило закрытые)– служат для реализации операций других видов.

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

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

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

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

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

Между элементами объектной модели существуют различные виды связей.

Соединение (link) – физическая или концептуальная связь между объектами, позволяющая им взаимодействовать.

Виды соединений:

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

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

• Композиция – усиленная агрегация, когда часть не может существовать без целого (пример: человек и голова).

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

• Обобщение – это связь «тип – подтип». Оно реализует механизм наследования, позволяет поддерживать полиморфизм.

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

• Реализация – связь между контрактом (либо интерфейс, либо вариант использования) и его исполнением (классом, подсистемой, компонентой и т. д.).

1.4. Базовые составляющие объектно-ориентированного подхода

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

- Унифицированный процесс;

- Унифицированный язык моделирования;

- шаблоны проектирования.

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

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

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

2. МЕТОДОЛОГИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА

​​​​​​​2.1 Методики объектно-ориентированного анализа

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

Классические подходы. Они основывается на классическом распределении по категориям. Кандидаты для классов и объектов, предлагаемые С. Шлаером и С. Меллолором:

- материальные предметы

- роли (учитель, телезрители, и т. д.)

- события (прерывание, требование)

- взаимодействие (встреча, пересечение).

При моделировании баз данных Р. Росс прелагает свой список:

-люди;

-места;

-предметы;

-организации;

-концепции;

-события;

Коад и Йордан предложили свой список кандидатов:

- структуры;

- другие системы;

- устройства;

- события;

- роли, в которых находятся пользователи;

- местоположение;

- организационные единицы.

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

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

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

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

CRC карточки. (Class – Responsibilities - Collaborators, Класс Ответственность - Участники). Это простой и эффективный способ анализа

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

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

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

- внешние сущности;

- хранилища данных;

- хранилища управляющих сущностей.

Кандидаты для классов:

- потоки данных;

- потоки управления.

Методология ОМТ (Object Modeling Technique) поддерживает две первые стадии разработки программных систем: стадию анализа требований и предварительной разработки и стадию проектирования (конструирования) [3].

Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии ОМТ. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+.

Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.