ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.04.2024
Просмотров: 58
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Для описания действий, выполняемых объектом, используются методы, то есть процедуры и функции, объявленные внутри класса и непосредственно с ним связанные. Методы легко координируются с событиями, происходящими при работе программы. Главное преимущество для разработчика здесь заключается в том, что привязанные к событию методы выполняются автоматически, и у нас даже есть возможность принудительно вызвать какое-то событие. Для каждого класса этот список может меняться как в сторону расширения, так и сужения.
Наследование – это одна из наиболее мощных возможностей объектно-ориентированного программирования. Заново созданный объект может наследовать характеристики (то есть свойства и методы) от предшественника – другого объекта. Хотя объекты могут наследовать характеристики от родительских классов, они также могут и не принимать во внимание наследование. Это позволяет разработчикам построить объекты для использования в конкретных условиях, то есть создать подклассы.
Использование подклассов значительно расширяет возможности как наследования, так и классов. Это означает, что не только заново созданный объект способен наследовать характеристики от родительского класса, но и также заново созданный класс может быть наследником родительского. В дополнение к выгодам наследования, способность создания подклассов для многократного использования с очень маленьким новым кодом или вообще без него. Кроме того, если новые функциональные возможности нужны во всех полученных дочерних классах, разработчик просто реализует эти возможности только в родительском классе, а во всех полученных дочерних классах функциональные возможности будут наследоваться автоматически.
Объектно-ориентированное программирование также позволяет пользователям помещать атрибуты (свойства) и правила поведения (методы) в объекты – метод инкапсуляции. Причем возможно размещение информации об объекте так, чтобы доступ к ней был невозможен. Это позволяет создавать «черные ящики», которые скрывают информацию. Даже если внутренняя реализация объекта и управление им может быть полностью скрыта, объект «знает» все, что ему требуется «знать», чтобы вести себя в соответствии с задуманным алгоритмом.
Полиморфизм полезен, когда специфическая функция должна вести себя по-разному при различных обстоятельствах. Например, произвольный метод Append может быть полиморфен в зависимости от объекта (скажем, различные кнопки пользовательской формы для добавления данных в различные таблицы), который вызвал метод Append. Это динамическое связывание функциональных возможностей позволяет создавать структурные классовые иерархии, где базисные скелеты объектов определены в базовом классе, а специализированный код - в полученных подклассах.
Формы, наборы форм и органы управления – это объекты, которые включаются в приложение. Управление этими объектами осуществляется через их свойства, события и методы. Этот путь позволяет гораздо проще создавать и поддерживать библиотеки с многократно используемым кодом, предоставляя кротчайшие возможности по созданию и фирменного и пользовательского интерфейса, и снимает с программиста массу хлопот, связанных с отыскиванием правильности использования фрагментов кода в приложении.
Классы и объекты хотя и являются очень близкими понятиями, но это не одно и тоже. Класс содержит информацию о том, как объект будет выглядеть и как он будет себя вести. Класс – это прототип или шаблон объекта. Когда вы создаете класс, опишите его свойства и необходимую реакцию на возможные события, с точки зрения пользователя в программе ничего не изменится. Чтобы что-то появилось (кнопка, поле и т. д.), необходимо на основании этого класса создать объект. Естественно, что чем точнее описание свойств класса соответствуют необходимой функциональности объекта, тем меньше работы придется выполнить, чтобы пройти путь от шаблона до реального объекта.
Под термином объект мы будем понимать все, что может быть представлено в базе данных. Объект – это то, о чем необходимо записать информацию.
Кроме основных объектов существуют еще и отношения между ними, которые связывают их вместе.
Отношения могут быть: бинарными (связываются два типа объектов); отношения, связывающие один тип объектов; может быть любое количество отношений (служащие заняты в проекте, служащие управляют проектом).
Следует отметить, что отношение подобно основным объектам является частью данных. Поэтому вместе с основными объектами отношения тоже должны быть представлены в базах данных.
Схему, связывающую объекты между собой, будем называть схемой объект/отношения или диаграммой объект отношения.
Отметим несколько моментов в построении схемы:
-
большинство отношений в схеме связывают два типа объектов (т.е. они являются бинарными). Но возможно связать и три объекта (поставщики, проекты и детали) – тройное отношение. Т.е. определенные поставщики поставляют определенные детали для определенных проектов; -
отношение может связывать один тип объектов. Например, детали. Это отношения означает, что некоторые детали содержат другие компоненты (спецификация материалов); -
в наборе объектов может быть любое количество отношений. Например. Служащие заняты в проектах – один факт, и другой – служащие управляют проектом.
2. CASE-технологии при проектировании БД.
Диаграммы потоков данны (DFD - Data Flow Diagramm) строятся из следующих элементов:
| Элемент | Описание | Обозначение |
| Функция | Действие, выполняемое моделируемой системой |  |
| Поток данных | Объект, над которым выполняется действие. Может быть информационным (логическим) или управляющим. (Управляющие потоки обозначаются пунктирной линией со стрелкой). |  |
| Хранилище данных | Структура для хранения информационных объектов |  |
| Внешняя сущность | Внешний по отношению к системе объект, обменивающийся с нею потоками данных |  |
Такой тип обозначений элементов DFD-диаграммы получил название "нотация Йордона - Де Марко", по именам разработавших его специалистов.
Часто нотацию DFD путают с простым описанием потоков информации между подразделениями. Это далеко не одно и то же. Почему нельзя рассматривать простое описание потоков между подразделениями организации как схему процесса? В каждом большом подразделении (например, отдел сбыта крупного предприятия) выполняются различные бизнес-процессы. Часто у этих процессов существуют различные внутренние и внешние клиенты. Именно поэтому схема потоков информации между подразделениями, описывает только потоки данных, пересекающие границы подразделений, но не содержит всей информации о внешних и внутренних изменениях потока информации. То есть диаграмма DFD содержит шаги модификаций/изменений информации от одного действия к другому. При этом, описание потоков информации между подразделениями является практически важным и широко используемым инструментом.
Пример описания процесса в DFD можно усложнить
, используя понятие «хранилище данных». Под этим понимается любой носитель информации, например, бумажный документ, электронный файл, промышленная база данных на сервере организации и т.д. При построении модели процесса с использованием хранилищ данных, необходимо помнить, что данные (информация) не могут перемещаться между функциями процесса сами по себе. Их можно передавать только через определенных посредников — носителей информации или, что то же самое, хранилищ данных. Ниже представлена модель процесса в нотации DFD, построенная с использованием понятия «хранилище данных».
Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:
-
Функции преобразуют входящие потоки данных в выходящие -
Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов -
Преобразования потоков данных во внешних сущностях игнорируется
Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя, также для него может быть указан тип данных и формат. Именно эта информация является исходной на следующем этапе проектирования - построении модели "сущность-связь". При этом, как правило, информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.
Несмотря на то, что методология IDEF0 получила широкое распространение в российских компаниях, на наш взгляд DFD гораздо больше подходит для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие). Вообще интеграция DFD и ER (entity-relationship, "сущность-связь") моделей не вызывает затруднений. Например, можно определить список атрибутов хранилищ данных, последние на стадии информационного моделирования однозначно отображаются в сущности модели "сущность- связь".
В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (перепроектированием деловых процессов, бизнес - реинжинирингом). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель.
На этом мы закончим рассмотрение способов функционального моделирования предметной области, поскольку эта тема должна быть гораздо полнее освещена в курсе, касающегося проектирования информационных систем.
