Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Основные инструменты ООП и понятийный аппарат).pdf
Добавлен: 13.05.2023
Просмотров: 336
Скачиваний: 2
СОДЕРЖАНИЕ
Глава 1. Теоретические основы объектно-ориентированного подхода
1.1. Основные инструменты ООП и понятийный аппарат
1.2. Отличие объектно-ориентированного стиля от процедурного
1.3. История развития объектно-ориентированного программирования
Глава 2. Практические аспекты проектирования информационных систем на ООП
2.1. Методология объектно-ориентированного анализа и проектирования
2.2. Унифицированный алгоритм действий при разработке информационных систем
2.3. Проектирование информационной бизнес-системы “Предприятие”
2.4. Проектирование систем управления базами данных с помощью ООП
2.5. Пример кода для проектирования датчиковой информационной системы в тепличном хозяйстве
В частности, рост популярности графических систем стал немаловажным стимулом перехода методологии на объектно-ориентированный подход.
Благодаря техникам ООП появилось и популяризовалось событийно-ориентированное программирование. Объектно-ориентированный стиль некоторое время считался самым актуальным и востребованным и только позже, в конце 90-х годов, началась разработка языков, поддерживающих и объектно-ориентированный подход, и процедурно-ориентированный.
Реализация некоторых задач, особенно в связи с усложнением MIT-среды, потребовала внедрения комбинированных технологий.
Коммерчески-успешными первопроходцами считаются Basic и Java.
В настоящее время ООП активно применяется при разработке огромного множества программ.
1.4. Основные недостатки ООП
Среди недостатков объектно-ориентированно подхода можно выделить, прежде всего, необходимость понимания достаточно абстрактных базовых концепций. Программисты, знакомые с азами модулирования, без труда освоят понятие классов, динамической коммуникации и наследования, однако для людей, впервые открывших консоль, инструментарий ООП может показаться слишком непривычным.
Кроме того, использование объектно-ориентированного инструментария на регулярной основе потребует от специалиста тесного знакомства с объёмными хранилищами классов (библиотеками), и по факту это окажется более трудоёмким поцессом, чем освоение нового языка.
Библиотека — это, фактически, отдельный виртуальный язык, содержащий в себе огромное количество типов операций и инструментов для их реализации.
Самая сложная задача, однако, это именно проектирования эти классов. Процесс проектирования полностью интерактивный, плюс классы — достаточно абстрактные категории, которые сложно взять “с наскока”.
На практике оказывается, что даже при хорошем понимании структуры ООП-языка серьёзную сложность может составлять процесс документирования классов.
Необходимо составить дерево контекстов, дающих информацию о перераспределении каждого метода. Это связано с тем, что переопределённые методы вызываются каркасом приложения, а не пользователем. Из-за мощной инкапсуляции нужно наизусть знать условия, выполняемые при вызове конкретного метода.
В развёрнутых, многоуровневых иерархических системах классов методы вместе с полями наследуются одновременно с разных уровней. Нужна качественная система навигации для ориентирования в системе классов. Сложно проследить, какие методы и поля изменяются при изменении класса, зачастую приходится внимательно изучать весь массив кода.
Действительно, лаконичность метода по сравнению с процедурным алгоритмом — безусловный плюс. Однако количество методов может быть огромным! Код для обработки оказывается распределён по большому количеству разных маленьких методов.
Из-за абстрагирования данных и инкапсуляции интерактиковность в среде пользователь-программа сильно ограничена. Клиент не имеет неограниченного доступа к данным, он способен действовать в рамках предоставленного классам набора операций.
Практические проблемы вызывает механизм расширения класса при инкапсулировании, сокрытии данных в недрах. Иногда специалисты заявляют, что объектно-ориентированный язык малоэффективен из-за чрезмерной универсализации, но это не единственный недостаток рассматриваемого стиля.
Постараемся выделить группы этих неэффективностей, проанализировав каждую:
- Неэффективность на этапе выполнения. В языках типа Smalltalk сообщения интерпретируются во время выполнения программы путем осуществления поиска их в одной или нескольких таблицах и за счет выбора подходящего метода. Конечно, это медленный процесс. И даже при использовании наилучших методов оптимизации Smalltalk-программы в десять раз медленнее оптимизированных C-программ [Cha92].
- В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит лишь к вызову через указатель процедурной переменной. На некоторых машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И поскольку сообщения встречаются в программе гораздо реже других операций, их воздействие на время выполнения влияния практически не оказывает.
- Однако, существует другой фактор, который затрагивает время выполнения: это абстракция данных. Абстракция запрещает непосредственный доступ к полям класса и требует, чтобы каждая операция над данными выполнялась через методы. Такая схема приводит к необходимости выполнения процедурного вызова при каждом доступе к данным. Однако, когда абстракция используется только там, где она необходима (т.е. не из одной лишь прихоти), то замедление вполне приемлемое.
- Неэффективность в смысле распределения памяти. Динамическое связывание и проверка типа на этапе выполнения требуют по ходу работы информации о типе объекта. Такая информация хранится в дескрипторе типа, и он выделяется один на класс. Каждый объект имеет невидимый указатель на дескриптор типа для своего класса. Таким образом, в объектно-ориентированных программах требуемая дополнительная память выражается в одном указателе для объекта и в одном дескрипторе типа для класса.[10]
- Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода. Одно из возможных решений — строить базовый класс с минимальным числом методов, а затем уже реализовывать различные расширения этого класса, которые позволят нарастить функциональность.
Другой подход — дать возможность компоновщику удалять лишние методы. Такие интеллектуальные компоновщики уже доступны для различных языков и операционных систем. Oberon избрал третий путь избавления от излишней универсальности.
Программные части могут добавляться на этапе выполнения. Таким образом, нет надобности загружать всю программу целиком, а можно обойтись лишь теми ее частями, которые в данный момент необходимы. Как показала практика, это экономит гораздо больше кода, чем можно добиться при удалении лишних методов. Таким образом, нельзя утверждать, что ООП вообще неэффективно.
Если классы используются лишь там, где это действительно необходимо, то потеря эффективности и на этапе выполнения и в смысле памяти сводится практически на нет.[11]
Глава 2. Практические аспекты проектирования информационных систем на ООП
2.1. Методология объектно-ориентированного анализа и проектирования
Термин информационная система (ИС) используется как в широком, так и в узком смысле. В широком смысле информационная система есть совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать надлежащих людей надлежащей информацией.
Также в достаточно широком смысле трактует понятие информационной системы Федеральный закон РФ от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: «информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств».[12]
Одно из наиболее широких определений ИС дал М. Р. Когаловский: «информационной системой называется комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей».[13]
Стандарт ISO/IEC 2382-1 дает следующее определение: «Информационная система — система обработки информации, работающая совместно с организационными ресурсами, такими как люди, технические средства и финансовые ресурсы, которые обеспечивают и распределяют информацию».[14]
Российский ГОСТ РВ 51987 определяет информационную систему как «автоматизированную систему, результатом функционирования которой является представление выходной информации для последующего использования».
В узком смысле информационной системой называют только подмножество компонентов ИС в широком смысле, включающее базы данных, СУБД и специализированные прикладные программы.
В методике ООП до момента написания приложения необходимо масштабно проанализировать предметную область. Создаётся БД (база данных) и СУБД (система управления базами данных). Процесс создания БД значительно рознится с процессом реализации программного кода в процедурном стиле.
Необходимо создать некую концептуальную модель, отображающую принятый способ организации информации и взаимосвязь этой организации с предметной области.
Предметная область или domain включает в себя классы и объекты, а также совокупность связей и программных коммуникаций между ними, которые требуются для реализации поставленной перед программистом задачи.
Главная сложность на данном этапе вызвана нетривиальным подходом к объединению объектов в предметную область. Принцип абстрагирования, при всей схожести методов, каждым отдельным специалистом может быть реализован по-разному. Имеются некие неформальные требования к границам инкапсуляции, однако инкапсилуемый объём данных вариабелен в зависимости от субъективной оценки каждого отдельно взятого специалиста.[15]
Для разработки многих информационных систем принципы группировки информации и границы инкапсуляции должны определять не разработчики, а скорее заказчики. Чтобы избежать лишних сложностей в разработке, в частности, корпоративных информационных систем, появилась концептуально новая методология.
Речь идёт об ООАП, методологии объектно-ориентированного анализа и проектирования. Сущность ООАП неразрывно связана с подходам ООП, так как на стадии группировки предметная область сама представляется в виде объектов, иерархически связанных с отдельными классами.
2.2. Унифицированный алгоритм действий при разработке информационных систем
В двух следующих параграфах мы предложим конкретные практические решения для проектирования информационных систем. Существует унифицированный алгоритм, разработанный в середине 90-х годов и актуальный до сих пор, как для математиков актуальны открытые столетия назад теоремы.
Что происходит при решении задачи с помощью объектно-ориентированного программирования?
- Создаётся концептуальная модель данных с помощью объектно-ориентированного анализа. На данном этапе уточняются требования к разрабатываемому софту, модель существует в состоянии так называемого “информационного стазиса” — она не связана с конкретным способом реализации.
- Производится логическое конструирование. На этом этапе генерируемая модель уже пригодна для реализации. Специалист просчитывает ограничения по типам данных, необходимому набору главных операций, намечаются объекты и классы.
- Завершающий этап — физическое конструирование. Во внешней памяти создаётся модель, она кластеризуется (физически разбивается на классы, объекты, методы), индексируется и тестируется.
Объектно-ориентированная модель должна нивелировать ограничения, классическим образом возникающие при перехода одного этапа к другому. В качестве примера можно назвать несоответствие структуры БД придуманной модели данных.
Безусловно, ООП даёт более совершенные, естественные инструменты для решения таких проблем. Какие же?
Во-первых, классификация. Схожие свойства относят объекты к одному классу, каждый уникальный объект теперь изучается и изменяется как отдельный экземпляр некоего общего множества или подмножества.
Во-вторых, частные экземпляры образуют подклассы и, поднимаясь выше — суперклассы. Строгое подчинение классов позволяет мгновенно редактировать методы и добавлять новый инструментарий, не изменяя каждую отдельную процедуру. Благодаря наследованию атрибутов поведения, суперклассы мобильны и легко изменяемы.
В конце концов, объектно-ориентированный подход позволяет агрегировать множество объектов, установить логические связи между ними по типу “часть-целое”. Отдельный элемент предметной области рассматривается не в стазисе, а в динамике — специалист может проследить эволюцию каждого метода, проследить его видоизменение в развитии и синергии с другими частями системы.[16]