Диссертация (1148239), страница 4
Текст из файла (страница 4)
ПО для работы с даннымиОдна из областей, в которых человек активно использует ПО — это работа сданными. Более того, обработка больших объемов данных исторически была одной18из первых задач, для которых стали применяться компьютеры. В эру мейнфреймовподобные вычислительные устройства могли себе позволить лишь большиекомпании, университеты или крупные государственные учреждения, и наличиебольшого хранилища данных и информационной системы для работы с ним для всехних было ключевым моментом.Типичный процесс разработки информационной системы состоит из следующихэтапов [89] — анализ требований, проектирование базы данных (БД), разработкапользовательского интерфейса к данным, средств создания отчетов и прочихинструментов системы. При этом проектирование адекватной структуры хранимыхданных является одним из самых критичных мест разработки, посколькунеэффективная структура БД повлечет за собой неоправданный рост либо хранимыхданных, либо времени их обработки, либо и того, и другого сразу.Приразработкеприложенийдляработысданнымимоделированиеосуществляется на нескольких уровнях [59].●Концептуальный уровень описывает предметную область в терминах,понятных и знакомых людям.
Модели на этом уровне (называемыеконцептуальными схемами) описывают структуру предметной области: какиетипы объектов там присутствуют, какие роли играют, какие на нихнакладываются ограничения и т.п.●На логическом уровне происходит выбор подходящей логической моделиданных(реляционная,объектно-ориентированнаяит.п.),послечегоконцептуальные схемы превращаются в логические схемы, выражаемые втерминах абстрактных структур данных и операций, поддерживаемыхвыбранной моделью данных. Например, в реляционной схеме факты хранятсяв таблицах, а ограничения выражены с использованием первичных и внешнихключей.●На физическом уровне логическая схема может быть представлена физической19схемой в выбранной системе управления базами данных (СУБД).
Например,реляционная схема может быть реализована в MS SQL Server или IBM DB2.Физическая схема включает в себя детали описания физического хранилищаданных, структур его внутренней организации и т.п. (например, индексы,кластеризация файлов и т.д.). Для каждой СУБД обычно этот выбор можетбыть сделан по-разному, к тому же даже в рамках одной СУБД возможноиспользование различных средств. Таким образом, для одной логическойсхемы могут быть выбраны разные физические схемы.Также часто выделяют еще внешний уровень, на котором описываетсяпредметная область в том виде, как она представляется различным группампользователей (для разных групп пользователей могут создаваться разныеинтерфейсы к создаваемым моделям относительно набора отображаемых данных,прав доступа к ним и т.п.).Модели, создаваемые на концептуальном уровне, чаще всего представляютсявизуально.
Наглядное и понятное для всех участников процесса описание структурыпредметной области значит очень много на начальном этапе разработки — от того,насколько удачно данная модель будет отражать картину реального мира, частозависит, насколько удобным в работе станет данное приложение, и сколько ресурсовуйдет на его разработку.
Дальнейшие переходы к логическому и физическомууровню чаще всего обеспечиваются настройками самой СУБД и/или средств,предоставляемых разработчиками СУБД для создания приложений для работы с ней.В области разработки ПО для работы с данными моделирование диаграммамистало применяться более 30 лет, многие из этих методов в том или ином видеиспользуютсяисейчас.Рассмотримнесколькопопулярныхподходовкконцептуальному моделированию данных [89].1.3.1. Модель “Сущность-связь” (Entity-Relationship Model)Данный подход был предложен в 1976 году Питером Ченом [73] и до сих пор20является одним из самых распространенных подходов к моделированию данных.
Онотображает реальный мир в виде сущностей, у которых есть атрибуты и которыеучаствуют в некоторых отношениях. Например, факт, что у человека есть деньрождения, отражается тем, что у сущности “человек” есть атрибут “дата рождения”,а то, что некий работник работает в некоем отделе — связью между сущностями“работник” и “отдел”. Такой подход довольно интуитивен, и даже несмотря напопулярность других подходов, ER все еще самый популярный для моделированияприложений, работающих с БД. Со временем появилось много разных версийданного подхода [61, 64, 85, 97], так что в настоящее время нет одной стандартнойER-нотации.1.3.2.
Семантическое моделированиеПри семантическом моделировании модели строятся, основываясь на фактах(fact-oriented), а не на сущностях предметной области. Факты при этомпредставляются в виде бинарного отношения между элементами модели, а самиэлементы характеризуются ролями, которые они в этих отношениях играют. Факты опредметной области составляются в виде предложений на естественном языке,которые потом формализуются в виде отношений, предоставляемых выбраннойнотацией.Вотличиеотмоделейтипа“Сущность-связь”,присемантическоммоделировании практически не используются атрибуты сущностей. Все фактыпредставляются в терминах объектов и их ролей. Несмотря на то, что это частоприводит к большим по объёму диаграммам, этот подход имеет свои преимуществадля концептуального анализа, которые выражаются в большей простоте инаглядности для непрофессионалов, стабильности и простоте валидации получаемыхмоделей.Основная нотация — ORM [131].211.3.3.
Объектно-ориентированное моделированиеНесмотря на то, что объектно-ориентированное моделирование создавалось дляпроектирования программных систем, для моделирования данных оно тоже можетбыть использовано. Существует много подходов объектно-ориентированногомоделирования,наиболееизвестнымизкоторыхявляетсяUML—унифицированный язык моделирования, предложенный консорциумом OMG [127].В текущую на данный момент версию UML 2.5 входит целый набор типов диаграмм,одним из которых являются диаграммы классов, описывающие статическиеструктуры данных.
Диаграммы классов способны задавать как операции, так инизкоуровневые решения из области реализации (например, видимость атрибутовили направленность ассоциаций). Абстрагировавшись от подобных элементов,относящихся к реализации, можно считать диаграммы классов UML расширениемER-нотации.Достоинством использования UML для моделирования данных является то, чтов эту нотацию возможно заложить более подробную информацию о предметнойобласти и создаваемой системе, которую в дальнейшем можно использовать будетне только при разработке схемы БД, но и самого приложения. Также в UML 2.5помимо диаграммы классов входят и другие диаграммы (например, диаграммыдеятельностиилидиаграммымашинсостояний),которыемогутпомочьвизуализировать поведенческий аспект предметной области.1.4.
Модельно-ориентированная архитектураМодельно-ориентированная архитектура (Model-driven architecture, MDA) —подход к разработке программных систем, продвигаемый консорциумом OMG.MDA определяет несколько типов моделей и фиксирует поэтапный процессразработки ПО, состоящий в последовательном продвижении от одной моделисистемы к другой. При этом последующие модели получаются на основе22предыдущихкакавтоматическимпреобразованиемсоответствующегоинструментария,такпроектировщиков.Последовательностьи“ручным”преобразованийсиспользованиемдополнениеммоделейсиламизавершаетсягенерацией кода готовой системы для выбранной платформы.
Под платформой вMDAпонимаетсясовокупностьтехнологийиподсистемснаборомфункциональности, которым любое приложение, работающее на этой платформеможет использовать безотносительно того, как эта функциональность платформыреализована [117].Стоит отметить, что методология MDA фиксирует процесс и состав каждогоэтапа, при этом никак не ограничивая класс создаваемых с ее помощью приложений,т.е. может быть использована при разработке произвольных программных систем.Рассмотрим виды моделей, которые определяет MDA [117].●Независимая от вычислений модель (Computation Independent Model, CIM)используетсядляописанияобщихтребованийксистеме,словаряиспользуемых терминов предметной области, а также окружения системы. Вданную модель должны включаться только те сущности, которые будутдетализироваться и использоваться в последующих моделях. CIM не должнараскрыватькаких-либодеталейвнутреннегоустройствасистемыипредназначена для формирования общего видения системы экспертамипредметной области и техническими специалистами.
Часто эти моделиназывают моделями предметной области или бизнес-моделями. Модели CIMпредставляют собой общее концептуальное описание системы, а поэтому принеобходимости могут быть опущены при создании небольших систем.●Независимая от платформы модель (Platform Independent Model, PIM)описывает структуру и бизнес-логику разрабатываемой системы. Модели наэтом уровне могут содержать сколь угодно подробные сведения о поведении,архитектуре приложения или пользовательском интерфейсе, однако они не23должны касаться вопросов реализации на конкретных платформах. МодельPIM строится на основе модели CIM, если последняя была создана напредыдущем этапе.●Зависимая от платформы модель (Platform Specific Model, PSM) дополняетописания PIM деталями, специфицирующими способ реализации системы дляконкретной платформы. Для каждой платформы, на которой планируетсяфункционирование разрабатываемой системы, создается отдельная модельPSM.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
