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

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

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

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

Добавлен: 25.06.2023

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

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

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

Пример. В Object Pascal есть абстракции: переменные объектов, методы объектов; нет: переменных классов, методов классов. Отсутствуют также метаклассы и множественное наследование – эти механизмы исключены, чтобы сделать язык простым для изучения программистам начинающим изучать О.О. методологию. Поэтому Object Pascal иногда называют «обглоданным» О.О. языком[3]

Уже насчитывается около 2000 языков программирования, более 100 – объектных (имеющих механизмы реализации абстрактных данных и классов, например, Ada) и объектно-ориентированных языков (в которых реализован механизм наследования как средство отражения иерархии классов, например, Smalltalk, Object Pascal (в нем есть простое наследование), C++, Clos).

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

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

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

  • Модульность – является элементом конструкции и позволяет осуществлять на её основе проектные решения. В таких языках ( например, Object Pascal, C++, Ada, CLOS, LISP) классы и объекты составляют логическую структуру системы, эти абстракции организуются в модули, образуя физическую структуру системы (особенно когда система состоит из сотен классов).[4]

Иначе говоря, «модульность – это разделение программы на раздельно компилируемые фрагменты (модули) , имеющие между собой средства сообщения».[1]

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

Определение: Модульность - это свойство системы, связанное с возможностью декомпозиции ее на ряд тесно связанных модулей.

  • Иерархия – это ранжированная или упорядоченная последовательность.

Пример иерархии: наследование - такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, простое или множественное наследование).


6.Дополнительные элементы объектно-ориентированного стиля.

  • Типизация. Концепция типизации строится на понятии типов абстрактных данных.

«Тип – это точное определение свойств строения или поведения, которое присуще некоторой совокупности объектов». «Тип» и «Класс» - эквивалентные понятия

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

  • Параллелизм. Реальная параллельность достигается только на многопроцессорных системах (системы с одним процессором имитируют параллельность за счет алгоритмов разделения времени). В то время, как объектно-ориентированное программирование основано на абстракции данных, ограничении доступа и наследовании, параллелизм связан с абстрагированием и синхронизацией процессов.[1]

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

Определение: Параллелизм - это свойство объектов находиться в активном, либо пассивном состоянии.

  • Устойчивость – это свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и (или) в пространстве (перемещение объекта из адресного пространства, в котором он был создан {для многопроцессорных систем})[5]

7.Основные принципы объектно-ориентированного подхода

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

  • Инкапсуляция – объединение в данном элементе и данных, и способов их обработки. Можно определить данные, входящие в классы, и действия, которые могут выполняться над этими данными, как некоторую структуру–объект в системе, работающей согласно набору правил.[1]
  • Наследование – сохранение, перенос атрибутов данных и выполняемых над ними операций от объекта к объекту. С помощью этого принципа строятся различные иерархии классов (простое наследование), а также смешанные классы (множественное наследование), когда некоторый новый класс одновременно наследует атрибуты и выполняемые над ними операции от нескольких базовых классов. При этом имеется возможность модифицировать «поведение» объектов.[3]
  • Полиморфизм означает возможность единообразного обращения к объектам в тексте программы при сохранении уникальности их поведения. Этот принцип позволяет определять целый ряд объектов на основе одного базового класса и обращаться к ним единообразно при сохранении специфического поведения каждого из них. Так, операция сравнения различных объектов возможна только тогда, когда базовый класс определяет метод сравнения.[5]

8. Преимущества объектного подхода

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

  • Объектный подход позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования (их преимущества не всегда очевидны)[4]
  • Использование объектного подхода существенно повышает качество разработки в целом и её фрагментов.
  • Использование объектного подхода приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений и позволяет избегать полной переработки системы в случае существенных изменений исходных требований.[2]
  • Объектный подход ориентирован на человеческое восприятие мира (для многих людей является естественным ООП к системам).
  • Объектный подход уменьшает риск разработки сложных систем потому что:

а) процесс интеграции растягивается во времени жизненного цикла системы;

б) объектный подход включает ряд хорошо продуманных этапов проектирования (что также уменьшает степень риска и повышает степень уверенности в правильности принимаемых решений).[1]

9. Варианты использования

В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне редко документировались. И вар Якобсон впервые ввел понятие "вариант использования" (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.[6]

Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора — "сделать некоторый текст полужирным" и "создать индекс".[2] Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех. функций, которые он хотел бы реализовать.


Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования.

Рис. 1 Диаграмма вариантов использования.

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

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

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

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей (см. рис.1): "использование" (uses) и "расширение" (extends) между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку


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

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

• связь "расширение" следует применять при описании изменений в нормальном поведении системы;[6]

• связь "использование" следует применять для избежания повторов в двух (или более) вариантах использования. Варианты использования являются необ­ходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.[3]

Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей "использование" и "расширение"). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.

Заключение

В связи со своими особенностями объектно-ориентированное программирование имеет ряд преимуществ перед структурным (и др.) программированием. Выделим некоторые из них:

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

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

Особенность ООП

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