Файл: Применение ООП при проектировании информационной системы.pdf

ВВЕДЕНИЕ

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

Мы знаем, что не все программные системы сложны. Нас интересует разработка того, что мы будем называть промышленными программными продуктами.

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

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

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

В этой работе будет рассмотрен один из возможных подходов к проектированию сложной информационной системы – объектно-ориентированный подход.

Как он предлагает решать проблемы проектирования таких систем? На каких принципах он строиться? Какие у него преимущества?

1. Глава 1. Определение и основные принципы ООП

---

Что есть объектно-ориентированный подход при проектировании информационной системы? В первую очередь надо определиться с понятием объектно-ориентированный – что это значит?

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

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

Термины «экземпляр класса» и «объект» взаимозаменяемы.

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

• абстрагирование
• иерархия
• инкапсуляция
• модульность

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

• типизация
• параллелизм
• устойчивость

Далее рассмотрим подробно каждый из них.

1. 1.1. Абстрагирование

Абстрагирование — это выделение значимой информации и исключение из рассмотрения не значимой. В ООП рассматривают лишь абстракцию данных (нередко называя её просто «абстракцией»), подразумевая набор наиболее значимых характеристик объекта, доступных остальной программе.

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

---

1. 1.2. Иерархия

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

• • • 1. 1.3. Инкапсуляция

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

Для лучшего понимания, приведу пример инкапсуляции в жизни:

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

1. 1.4. Модульность

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

---

1. 1.5. Типизация

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

1. 1.6. Параллелизм

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

1. 1.7. Устойчивость

Устойчивость - свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

Мы определились с понятием объектно-ориентированный, на каких принципах строиться этот подход, далее стоит раскрыть смысл проектирования в целом.

1. Глава 2. Микропроцесс проектирования

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

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

В микропроцессе традиционные фазы анализа и проектирования умышленно перемешаны, а управление осуществляется "по возможности". Различные фазы программного проекта, такие, как проектирование, программирование и тестирование, неотделимы друг от друга.

Микропроцесс обычно состоит из следующих видов деятельности:

• выявление классов и объектов на данном уровне абстракции
• выяснение семантики этих классов и объектов
• выявление связей между этими классами и объектами
• спецификация интерфейса и реализация этих классов и объектов.

Далее рассмотрим каждый из этих видов деятельности подробно.

---

1. 2.1. Выявление классов и объектов

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

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

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

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

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

Создание словаря данных на этом шаге дает три существенных выигрыша.

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

---