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

Основной методологией разработки программного обеспечения АС до начала 90-х годов являлась процедурно-ориентированная методология [Леоненков ]. При этом программный код организовывался в виде множества процедур или алгоритмов.

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

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

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

Фундаментальными понятиями ООП являются понятия класса и объекта.

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

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

Наследование - принцип, в соответствии с которым родительский класс (предок) передает все свои наборы свойств и поведение дочерним классам (потомкам). Дочерние классы называются производными классами (рис.1).

Рис.1. Иерархия классов, полученная операцией обобщения

Фрагмент иерархии классов библиотеки VCL среды программирования Borland Delphi представлен на рис.2.

Рис.2. Фрагмент иерархии классов библиотеки VCL Borland Delphi

Класс является дальнейшим расширением понятий структура (structure) и запись (record).

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

Полиморфизм (много форм) - действия, выполняемые одноимёнными методами, могут отличаться в зависимости от того, к какому из классов относится метод.

Использование объектов заранее подготовленных библиотечных классов с определёнными свойствами и методами позволило решить многие кризисные вопросы создания программного и информационного обеспечения сложных АС.

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

Уже давно стало ясно, что анализ предметной области очень важен для успешного проектирования АС. Прежде, чем непосредственно генерировать структуру БД, необходимо построить концептуальную модель хранения данных в виде ER- или SHM-модели [ ]. Эта работа проводится совместно с экспертами, хорошо знающими предметную область.

Здесь могут помочь так называемые CRC-карточки, предложенные Баддом [ ] (рис.3). (см. Бадд Т. Объектно-ориентированное программирование в действии: Перевод с английского. – Спб: Питер, 1997. – 464с.)

Компонента <название> Описание обязанностей, выполняемых данной компонентой

СПИСОК   <всех взаимодействующих с ней компонент>

Рис.3. CRC-карточка

CRC расшифровывается как Component, Responsibility, Collaborator (компонента, обязанность, взаимодействие ). Под компонентой понимается функционально самостоятельная часть системы, решающая одну или несколько задач (например, отдел маркетинга, прокатный стан, отдельные сотрудники и т. д.). Многие компоненты естественным образом преобразуются в классы и объекты программного и информационного обеспечения.

Выделение компонент предметной области – искусство системного аналитика или архитектора системы.

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

получения результата, а также составом и структурами данных, которые должны поступать

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

.