Гущин А.Н. Информационные технологии в экономике

Подождите немного. Документ загружается.

"H"(History) в кружке. Для

долговременной истории, где

запоминаются все подчинённые

состояния (во вложенных в данное)

есть обозначение "H*". Событие,

обеспечивающее переход на

диаграмме состояний объекта

получателя называется сигналом.

Сигналы, как и любые классы, можно наследовать. Переход может быть условным

(по событию) или безусловным(по выполнению всех действий). На диаграмме

состояний отображаются все переходы между состояниями одного объекта системы.

Диаграммы дают полную информацию аналитикам о желаемом поведении.

Диаграммы последовательностей.

Диаграмма последовательности состоит из обычных объектов, сообщений(в виде

стрелок), а также вертикальной оси времени. Сообщение может быть простым

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

ответа, продолжает действовать). Пример: 1.Покупатель помещает монету в щель на

лицевой панели автомата. 2.Покупатель выбирает сорт лимонада 3.Монета попадает

в реестр 3.Для рассматриваемого основного сценария считаем, что нужный сорт

лимонада имеется, и реестр даёт команду отсеку доставить лимонад к лицевой

панели автомата. На диаграмме последовальностей возможны следующие элементы:

[переход по условию], *[цикл пока], создание (создать(), '<<'создать'>>'), удаление

объекта(X). Диаграмма последовательностей UML добавляет изменение времени к

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

одной из операций).

Диаграммы кооперации.

Диаграмма кооперации - это ещё один способ представления информации,

которая раньше была изображена на диаграмме последовательности. Эти два типа

диаграмм семантически эквивалентны. Диаграмма последовательностей упорядочена

в соответствии со временем, диаграмма кооперации - в соответствии с

пространственным расположением объектов. На диаграмме кооперации ассоциации

между объектами изображаются в виде сообщений, передаваемых одним объектом

другому. Сообщение: стрелка, порядок. номер, имя. Условия, как и раньше,

отображаются в кв. скобках. Чтобы описать цикл, надо поместить звёздочку перед

условием.

Некоторые операции являются дочерними по отношению к другим. В системе

нумерации сообщений их номера пишутся после десятичной точки от имя предка.

Диаграмма кооперации позволяет моделировать множество объектов получателей.

Можно также изображать активные объекты, управляющие потоком сообщений, а

также синхронизованные сообщения.

Диаграммы видов деятельности.

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

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

какому объекту относится нужный вид деятельности.

Диаграммы развёртывания.

Диаграмма развёртывания UML описывает физическую систему в готовом виде.

Система состоит из узлов, каждый из которых изображается в виде куба. Линия

между двумя кубами, символизирует соединение узлов. Существует два типа узлов:

процессор - это узел, который может выполнить команды компонента. Устройство -

узел, которое это делать не может.

Рекомендации по графическому изображению диаграмм языка UML

При графическом изображении диаграмм следует придерживаться следующих

основных рекомендаций:

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

соответствующего фрагмента моделируемой предметной области. Речь идет о

том, что в процессе разработки диаграммы необходимо учесть все сущности,

важные с точки зрения контекста данной модели и диаграммы. Отсутствие тех

или иных элементов на диаграмме служит признаком неполноты модели и

может потребовать ее последующей доработки.

· Все сущности на диаграмме модели должны быть одного уровня

представления. Здесь имеется в виду согласованность не только имен

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

в друга для достижения полноты представлений. В случае достаточно

сложных моделей систем желательно придерживаться стратегии

последовательного уточнения или детализации отдельных диаграмм.

· Вся информация о сущностях должна быть явно представлена на диаграммах.

В языке UML при отсутствии некоторых символов на диаграмме могут быть

использованы их значения по умолчанию (например, в случае неявного

указания видимости атрибутов и операций классов), тем не менее, необходимо

стремиться к явному указанию свойств всех элементов диаграмм.

· Диаграммы не должны содержать противоречивой информации.

Противоречивость модели может служить причиной серьезных проблем при

ее реализации и последующем использовании на практике. Например,

наличие замкнутых путей при изображении отношений агрегирования или

композиции приводит к ошибкам в программном коде, который будет

реализовывать соответствующие классы. Наличие элементов с одинаковыми

именами и различными атрибутами свойств в одном пространстве имен также

приводит к неоднозначной интерпретации и может быть источником проблем.

· Каждая диаграмма должна быть самодостаточной для правильной

интерпретации всех ее элементов и понимания семантики всех используемых

графических символов. Любые пояснительные тексты, которые не являются

собственными элементами диаграммы (например, комментариями), не

должны приниматься во внимание разработчиками. В то же время общие

фрагменты диаграмм могут уточняться или детализироваться на других

диаграммах этого же типа, образуя вложенные или подчиненные диаграммы.

Таким образом, модель системы на языке UML представляет собой пакет

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

достаточной для последующей генерации программного кода, реализующего

проект соответствующей системы.

· Количество типов диаграмм для конкретной модели приложения строго не

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

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

проекте системы, и это не будет считаться ошибкой разработчика. Например,

модель системы может не содержать диаграмму развертывания для

приложения, выполняемого локально на компьютере пользователя. Важно

понимать, что перечень диаграмм зависит от специфики конкретного проекта

системы.

· Любая модель системы должна содержать только те элементы, которые

определены в нотации языка UML. Имеется в виду требование начинать

разработку проекта, используя только те конструкции, которые уже

определены в метамодели UML. Как показывает практика, этих конструкций

вполне достаточно для представления большинства типовых проектов

программных систем. И только при отсутствии необходимых базовых

элементов языка UML следует использовать механизмы их расширения для

адекватного представления конкретной модели системы. Не допускается

переопределение семантики тех элементов, которые отнесены к базовой

нотации метамодели языка UML.

Самостоятельная зачетная работа. Построение модели процесса на языке UML

диаграмм. (результат – модель в MS Visio)

Тема 3. Базы данных

Историческое развитие.

Последовательные файлы. Представление в виде таблиц. Аномалии хранения,

удаления, обновления.

Реляционное исчисление

Идея Ф. Кодда. Почему реляционное счисление называется реляционным

Нормальные формы баз данных. Системы управления базами данных.

Уровни абстракции баз данных.

Концептуальный уровень. Логический уровень. Физический уровень. Аппаратный

уровень. ГОСТ 34.320-96 «Концепции и терминология для концептуальной схемы и

информационной базы». Диаграммы потоков данных (DFD диаграммы).

Формирование модели данных

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

бизнес-правил для СУБД. Обычно она разрабатывается как часть более крупного

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

физической моделей. В большинстве случаев первой создается логическая модель, а

уже потом модель физическая. Иногда модель данных получается путем

реконструкции из существующей базы данных.

Определение проблемы и функциональных границ

Логическое моделирование данных начинается с определения проблемы. Этот шаг

иногда определяют как формулирование цели или функциональных границ проекта.

Определение проблемы может состоять из одного параграфа или представлять собой

сложный документ, отражающий систему бизнес-целей. Эта операция задает

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

границы частного владения.

Сбор требований к информации

Многие из профессионалов согласны, что наиболее важной задачей проекта

разработки ПО является точное и полное определение требований. В самом деле,

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

отведенного бюджета и существенному срыву срока завершения проекта. Сбор

требований к информации представляет собой процедуру обнаружения и

документирования информации, необходимой для идентификации и определения

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

Существует два хорошо известных метода сбора требований: рабочие сессии и

интервью. Большинство методологий разработки рекомендуют практику рабочих

сессий.

Анализ

Для формирования целостной логической модели, вы должны проанализировать и

исследовать требования к данным и бизнес-правила. В результате проведения

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

атрибутов и отношений. В течение фазы анализа собираются и документируются

метаданные (данные о данных).

Анализ может проводиться как разработчиком модели, так и бизнес-

аналитиком. И тот, и другой работают с пользователями, документируя их намерения

по использованию данных. Эта работа должна привести к формированию

корпоративных бизнес-объектов, необходимых для ведения требований к

информации. Корпоративные бизнес-объекты приводят к коду, ссылкам и

классификации структур данных. Здесь кроется возможность для документирования

кодовых значений, которые будут использоваться. Необходимо тщательно

документировать все производные данные (данные, которые создаются путем

комбинации или манипуляции над одним или более элементами данных) и исходные

элементы данных.

Отображение и трансформация данных

Часто вам необходимо некоторым образом отображать или трансформировать

данные. Отображение значений данных из источника в базу данных является важной

задачей анализа. Важно помнить, что моделирование данных не должно зависеть от

их источника. То есть способ получения данных не должен влиять на подход к их

моделированию.

В таблице приведен пример использования правил трансформации и отображения

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

три отдельных и различимых значения. Кроме того, соответствие определяет бизнес-

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

они представляют.

Пример правил отображения для исходного кода.

Исходный

код

Значение атрибута

1234567890 123 456 7890

0987654321 098 765 4321

12345 123 450 0000

Бизнес-правила, показанные в таблице, включают руководство для отображения

значений исходного кода в его компоненты. Значения исходного кода содержат

атрибут 1, атрибут 2 и атрибут 3. Новые значения исходного кода используются,

начиная с 1-го января 1998, и состоят из 10 цифр, в то время как старые значения

состояли из 5 цифр. Первые три цифры значения исходного кода содержат атрибут 1.

Следующие три цифры составляют атрибут 2. Последние четыре цифры содержат

значение атрибута 3. Для значений из пяти цифр в исходном коде вы используете

ноль (0) в качестве третей цифры атрибута 2 и заполняете нулями значение атрибута

Область определения данных

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

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

России в качестве рабочего дня рассматривается один из следующих: понедельник,

вторник, среда, четверг или пятница. Этот список является областью определения

для значений атрибута с именем День Недели.

Значения по умолчанию

Некоторым атрибутам значения назначаются по умолчанию. Значениями по

умолчанию для атрибутов могут быть значения, которые атрибут имеет в

большинстве случаев. Значения по умолчанию могут устанавливаться для атрибутов,

чтобы избежать неинициализированных значений. Например, значением по

умолчанию для Количества Покрышек должно быть 4, так как большинство

транспортных средств имеет четыре покрышки на колесах. Часто для числовых

полей принимают 0 в качестве значения по умолчанию, так как

неинициализированные значения могут привести к непредвиденным последствиям.

Логическая модель данных

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

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

образом, чтобы они легко воспринимались бизнес-пользователями. Проектирование

логической модели должно быть свободно от требований платформы и языка

реализации или способа дальнейшего использования данных.

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

формирования логической модели данных. Разработчик приводит логическую

модель к третьей нормальной форме и проверяет ее на соответствие корпоративной

модели данных, если она существует. Последующие разделы описывают

формирование логической модели данных, приведение логической модели к третьей

нормальной форме, обзор корпоративной модели и дают некоторые рекомендации по

проверке логической модели на соответствие корпоративной модели. Для

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

совместный анализ с бизнес партнерами и командой разработчиков.

Компоненты логической модели данных

Логическая модель использует сущности, атрибуты и отношения для представления

данных и бизнес-правил. Сущности представляют собой объекты, о которых

корпорация заинтересована хранить данные. Атрибуты - это данные, которые

корпорация заинтересована хранить. Отношения описывают взаимосвязи между

сущностями в терминах бизнес-правил.

Сущности

Сущности представляют собой объекты, данные о

которых корпорация заинтересована сохранять.

Сущностями могут быть вещественные объекты,

такие как персона или книга, но они могут

представлять и абстрактные концепции, такие как

центр затрат или производственная единица.

Сущности для ясности и обеспечения целостности

обозначаются существительными в единственном

числе, например, Потребитель (CUSTOMER) а не Потребители (CUSTOMERS). Вы

должны описать сущность, используя фактографические подробности, которые

уникально ее идентифицируют. Каждый экземпляр сущности должен быть

отдельным и отличным от всех других экземпляров этой сущности. Например,

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

позволяющий отличить одного клиента от другого.

Атрибуты

Атрибуты представляют

данные об объектах, которые

необходимо иметь корпорации.

Атрибуты представляются

именами существительными,

которые описывают

характеристики сущностей. В

качестве атрибутов могут

выступать дата рождения

клиента,

Отношения

Отношения представляют

взаимосвязи между объектами, о

которых корпорация

заинтересована хранить данные.

Отношения выражаются глаголами

или глагольными фразами,

которые описывают взаимосвязь.

На приведено несколько примеров

отношений, представленных в

нотации IE (Information

Engineering - информационная

инженерия) системы MS Visio.

Нормальные формы

Нормальная форма — требование, предъявляемое к структуре таблиц в теории

реляционных баз данных для устранения из базы избыточных функциональных

зависимостей между атрибутами (полями таблиц). Процесс преобразования базы

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

Если один и тот же атрибут присутствует более чем в одной сущности и не

является внешним ключом, то этот атрибут рассматривается как избыточный.

Логическая модель не должна содержать избыточных данных.

Понятие нормальной формы было введено Эдгаром Коддом при создании

реляционной модели БД. Основное назначение нормальных форм — приведение

структуры базы данных к виду, обеспечивающему минимальную избыточность.

Устранение избыточности производится за счёт декомпозиции отношений (таблиц)

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

атрибутами (полями). Понятие функциональной зависимости здесь определяется

следующим образом:

В паре атрибутов одного отношения, X и Y, атрибут Y функционально

зависит от атрибута X, если в данном отношении одному значению X

соответствует в точности одно значение Y.

Полное отсутствие функциональных зависимостей в отношениях невозможно

(да и не нужно), но часть таких зависимостей избыточна, поскольку их можно

вычислить из других зависимостей, имеющихся в БД. Каждая нормальная форма

представляет собой определённое условие, которому должна соответствовать

таблица базы данных. Если таблица не соответствует нормальной форме, она может

быть приведена к ней (нормализована) за счёт декомпозиции, то есть разбиения на

несколько таблиц, связанных между собой. Теоретически, в результате нормализации