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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 19.06.2023

Просмотров: 69

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ВВЕДЕНИЕ

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

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

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

Аналитические исследования ведущих зарубежных аналитиков показывали не очень приятные результаты. Так в 1995 году, компания Standish Group провела анализ работы 364 американских корпораций и итоги выполнения 23 000 проектов в области разработки ПО, и пришла к следующим выводам: 16,2 % проектов выполнены в заданный срок, 52,7 % проектов были выполнены с опозданием, 31,1 % проектов были аннулированы до завершения. Все это конечно оказало большое влияние на бюджет.

В качестве причин данных неудач выступали:

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

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

В соответствии с данной темой, в данной работе были поставлены следующие цели и задачи:

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

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

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

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

СТРУКТУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

Структурный подход предполагает декомпозицию системы, т.е. разбиение системы на автоматизированные функции. Вся система разбивается на функциональные подсистемы, а те в свою очередь разбиваются на подфункции и т.д. вплоть до определенных процедур. В итоге можно сделать ввод, что проектирование системы происходит «сверху вниз». Нужно заметить, что, сама автоматизированная система сохраняет целостное представление, где все компоненты, входящие в эту систему остаются взаимосвязаны[1][1]. Как правило, в дальнейшем, при проектировании системы «снизу вверх» начиная от отдельных задач и заканчивая всей системой, целостность утрачивается, и появляются проблемы при информационной стыковке отдельных компонентов данной системы. Данная проблема очень сильно усложняет процесс модификации системы. Какие либо преобразования, внесённые на каком либо уровне системы, с огромной вероятностью приведут к потоку каскадных негативных изменений на вышестоящих уровнях.

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

Понятия объект и класс являются главными в объектно-ориентированном подходе[3][3].

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

Класс – это множество рассматриваемых объектов с общей структурой и поведением[5][5].

История

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


В 1967 г сотрудниками Норвежского Вычислительно Центра Оле-Йохансоном и Кристеном Нюгордом был, разработал первый мире объектно-ориентированный язык программирования (ЯП) Simula 67[6][6]. Во время своего рождения данный язык предлагал революционные идеи: объекты, классы, виртуальные методы и т.д., но все это не было воспринято современниками как что то новое. Но, тем не менее, в дальнейшем большинство данных концепций были развиты Аланом Кэйем и Дэном Ингаллосом.

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

Главные понятия и разновидности

Структура данных «класс», которая представляет собой объектный тип данных, внешне похожа на типы данных процедурно-ориентированных языков, такие как структура в языки C или запись в Pascal или QuickBasic. При всем этом элементы данной структуры могут быть не только данными, но и методами. Данное объединение называется «инкапсуляцией»[7][7].

Наличие инкапсуляции вполне достаточно для «объектности» ЯП, но это еще не значит что он объектно-ориентированный - для этого требуется наличие «наследования»[8][8].

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

Основные понятия

Абстракция (Abstraction) – это придание объекту характеристик, четко определяющих его концептуальные границы, отличая от других объектов. Главная суть состоит в том, чтобы отделить способ использования составных объектов данный от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функций и деталей ее реализации в терминах более примитивных функций, в итоге, данные обрабатываются функцией высокого уровня при помощи вызова функции низкого уровня. Абстракция является основой ООП и допускает работу с объектами, не вдаваясь в особенности их реализации[9][9].

Инкапсуляция (Encapsulation) – это свойство ЯП, которое позволяет объединить данные и код в объект и скрыть реализацию объект от пользователя. Пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только с помощью данного интерфейса[10][10].


Сокрытие данных – это важная часть ООП, которая управляет областями видимости. Является логическим продолжением инкапсуляции. Задачей сокрытия является неспособность пользователя узнать и повредить внутренне состояние объекта[11][11].

Наследование (Inheritance) – это способность описать новый класс от другого, при этом сохраняются все свойства и методы класса-предка и при необходимости добавляются новые. Набор классов, которые связанны наследованием и отношением, называют иерархией.

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

Определение ООП

По мнению Алана Кея, создателя ЯП Smalltalk, которого считают одним из отцов-основателей ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов[12][12]:

  • все является объектом;
  • вычисления производятся через взаимодействия между объектами, при котором один объект требует, чтобы другой выполнил определенное действие. Объекты взаимодействуют путем отправления и получения сообщений. Сообщение – это запрос на выполнение действия, дополненный набором аргументов, которые могут быть необходим при выполнении действия[13][13].
  • каждый объект обладает независимой памятью состоящей из других объектов;
  • каждый объект является представителем класса, выражающий общие свойства объектов;
  • в классе задается поведение объекта. Таким образом, все объекты являющиеся экземплярами одного класса способны выполнять одни и те же действия;
  • классы организованны в единую древовидную структуру с общим корнем, называемую иерархией наследования. Поведение и память, которые связанны с экземплярами конкретного класса, автоматически доступны любому классу, расположенному ниже в древовидной иерархии[14][14].

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


Управляемость и устойчивость системы обеспечивается благодаря разделению ответственности объектов, т.е. за каждое действие отвечает конкретный объект, однозначного определения интерфейсов межобъектного взаимодействия и полной внутренней структуры объекта от внешней среды[16][16].

ООП основывается на описании поведения и структуры разрабатываемой системы, т.е. отвечает на два главных вопроса:

  • из каких частей состоит система;
  • в чем состоит ответственность каждой из этих частей.

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

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

ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ UML

2.1 Унифицированный язык объектно-ориентированного моделирования

На данный момент существует огромное число разнообразных инструментальных средств, использующихся для реализации заданного проекта ИС начиная от этапа анализа и заканчивая этапом создания программного кода. Различают отдельно так называемые upper CASE tools (CASE-средства верхнего уровня) и lower CASE tools (CASE-средства нижнего уровня)[17][17].

Среди главных проблем использования upper CASE tools выделают проблемы их адаптации под определенные проекты, по причине того, что они очень серьезно регламентируют процесс разработки и не позволяют организовать работу на уровне отдельных элементов проекта[18][18]. Другим вариантом возможно использование lower CASE tools, но их использование влечет за собой определенные проблемы, такие как: трудности при организации взаимодействия между командами, работающими над определенными элементами проекта[19][19].