22. Создание логической и физической модели ис с помощью Data eRwin Modeler.

(Выдержка из курсача)

ERwin - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования такихаспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

В ERwin существуют два уровня представления и моделирования - логический и физический.

Логическая модель. Логическое проектирование - построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

• описание объектов предметной области и связей между ними;

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

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

Таким образом, задача логической модели данных заключается в описании объектов данных предметной области и взаимосвязей между ними. Разработку логической модели реляционной базы данных можно представить как определение отношений, отображающих понятия предметной области, и приведение их к третьей нормальной форме (3НФ).

Отношение находится в 3НФ, если оно находится во 2НФ и каждый непервичный атрибут находится в нетранзитивной (то есть прямой) зависимости от первичного ключа. Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа.

Отношение находится в 1НФ, если все атрибуты всех отношений имеют и всегда будут иметь атомарные значения.

Физическая модель данных отличается от логической тем, что она полностью зависит от выбранной базы данных. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Связь в физической модели отображает логическую зависимость одной сущности от другой. Различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.

При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей. Для того чтобы однозначно идентифицировать экземпляр сущности используется первичный ключ (атрибут или группа атрибутов). Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).

23. Диаграммы инфологических моделей «сущность–связь». Моделирование данных в Data Process Modeler (ERwin).

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen)[1], американским профессором компьютерных наук в университете штата Луизиана

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

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

Модель данных. (из презентации Путькиной) – внешний вид ER-диаграммы

24. Унифицированный язык моделирования UML.

UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. Это  - набор правил, который можно назвать стандартом, составления диаграмм, необходимых в ходе разработки и внедрения программного обеспечения и описания бизнес-процессов. Это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования программных систем. Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML не является языком программирования.

Преимущества UML

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

2. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

3. UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели. Структурные сущности - это имена существительные в моделях на языке UML.

Класс (Class) - это описание совокупности объектов с общими атрибутами.

Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом

Кооперация (Collaboration) определяет взаимодействие; представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых

Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера.

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, диаграмм. Диаграмма — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика. Нотация канонических диаграмм - основное средство разработки моделей на языке UML.

В анотации языка UML определены следующие виды канонических диаграмм:

- вариантов использования (use case diagram)

- классов (class diagram)

- кооперации (collaboration diagram)

- последовательности (sequence diagram)

- состояний (statechart diagram)

- деятельности (activity diagram)

- компонентов (component diagram)

- развертывания (deployment diagram)

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

Диаграмма прецедентов использования выявляет основные бизнес - процессы как последовательности транзакций, которые должны выполняться целиком, когда выполнение обособленного подмножества действий не имеет значения без выполнения всей последовательности. Прецеденты использования инициируются из внешней среды пользователями ЭИС, называемыми актерами. На этом уровне моделирования не раскрывается механизм реализации процессов.

Актер инициирует выполнение прецедента использования и получает от него результаты. Взаимодействие (ассоциация) актера с прецедентом использования осуществляется в результате события, которое обозначается поименованной стрелкой (рис. 13.9). Один актер может участвовать в нескольких прецедентах использования, а в одном прецеденте использования может быть занято несколько актеров.

В реализации прецедента использования возможно выделение нескольких потоков событий:

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

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

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

Диаграммы классов являются одной из форм статического описания системы с точки зрения ее проектирования, показывая ее структуру. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.

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

  Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет. Объектов одного класса в программе может быть сколь угодно много, все они имеют одинаковый набор атрибутов, описанный в классе, но значения атрибутов у каждого объекта свои и могут изменяться в ходе выполнения программы.

Отношения.На диаграммах классов обычно показываются ассоциации и обобщения (см. предыдущую статью).

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

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

I.Диаграммы состояний являются средством описа­ния поведения систем. Они определяют все возможные состояния, в кото­рых может находиться конкретный, а также процесс смены состояний объекта в результате влияния некоторых событий. Например диаграмма состояний UML, отражающая поведение отчета в системе управления проектами. На диаграмме изображены различные состояния, в которых может находиться отчет.

II.Диаграмма взаимодействий. К диаграммам взаимодействия относятся диаграммы кооперации и диаграммы последовательности.

a)Понятие кооперации является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель кооперации - специфицировать особенности реализации отдельных наиболее значимых операций в системе.         Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.

b)Диаграммы последовательности. Используются для моделирования взаимодействия объектов во времени. На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии. Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени.

       III. Диаграмма деятельностей. Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. Например:

27. Прототипное проектирование ИС. Понятие RAD-технологии.

Rapid Application Development (RAD) можно рассматривать как высокоскоростную адаптацию каскадной модели, опирающуюся на компонентно-ориентированное проектирование.

Основное направление проектирования ИС - получить готовое приложение высокого качества быстро при минимальных затратах на его разработку. Это направление нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD (Rapid Application Development).

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

В процессе работы с системой-прототипом пользователь реально осознает возможности будущей системы и определяет наиболее удобный для него режим обработки данных, что значительно повышает качество создаваемых систем. Осуществляются проверка принципиальных проектных решений по составу и структуре ИС и оценка основных ее эксплуатационных характеристик.

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

К числу этих приемов относятся:

1) разработка приложения итерациями; 2) необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем;

3) обязательное вовлечение пользователей в процесс проектирования и построения системы;

4) высокая параллельность работ;

5) повторное использование частей проекта;

6) необходимое применение CASE - средств, обеспечивающих техническую целостность на этапах анализа и проектирования;

7) применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы;

8) использование автоматических генераторов (мастеров);

9) использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;

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

Основная проблема процесса разработки ИС по RAD-технологии заключается в определении момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков с использованием инструментов автоматизации процесса планирования.

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

Такие инструментальные средства можно условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД – класс DEVELOPER и интегрированные инструменты быстрой разработки приложений – класс BUILDER.

27. ERP-система «Галактика» и оптимизация бизнес-процессов

ERP-система — это интегрированная система на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями (бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями. Построенная, как правило, на централизованной базе данных, ERP-система формирует стандартизованное единое информационное пространство предприятия.

Системы класса ERP предназначены для планирования и управления ресурсами компании, отслеживают состояние склада, исполнение поставок, материальные и финансовые потоки между подразделениями предприятия и с внешними контрагентами, обеспечивают объемное планирование производственных ресурсов, позволяют формировать объемно – календарные планы выпуска, производства, снабжения. Также, благодаря использованию специализированного модуля «Техническое обслуживание и ремонт оборудования» становится возможным планировать и контролировать исполнение ремонтов оборудования.

Информационная система «Галактика ERP» предназначена для комплексной автоматизации управления предприятием. Решения системы «Галактика ERP» ориентированы на средние и крупные предприятия численностью от нескольких десятков и сотен сотрудников до нескольких тысяч. 

В состав системы входят модули, решающие задачи:

• Управления производством (планирование, контроль, анализ производственной деятельности для разного характера производства и разной специфики, расчет материальных, трудовых потребностей, потребностей в оборудовании и инструменте)

• Логистики (Снабженческой, сбытовой, складской, транспортной, производственной)

• Управления заказами (регистрация, контроль исполнения заказов клиентов, оценка стоимости заказов)

• Контроль себестоимости продукции (расчет плановой и фактической себестоимости продукции)

• Управления договорами

• Бухгалтерского и налогового учёта

• Управления персоналом и заработной платы

• Управления финансами (Бюджетирование, платёжный календарь, финансовый анализ)

• Специализированные решения (для автотранспорта, строительства и др.)

В системе «Галактика ERP» совместно с широкими функциональными возможностями заложены также готовые управленческие решения, применен комплексный подход к решению управленческих задач. При этом возможно поэтапное освоение системы, с получением результатов на каждом этапе.

29.Создание моделей бизнес-процессов в ERP-системе «Business Studio»

Business Studio - система визуального бизнес-моделирования, основное назначение которой - описание моделей бизнес-процессов предприятия, организационных структур, документооборота с автоматической генерацией регламентов процессов, процедур, положений о подразделениях и должностных инструкций, доступных на каждом рабочем месте в форме html-навигатора или документов Microsoft Word.

Разработка комплексной модели деятельности предприятия:

• модель деятельности предприятия (IDEF0, Basic Flowchart, Cross Functional FlowChart, EPC)

• описания и регламенты бизнес-процессов

• организационная структура и штатное расписание

• положения о подразделениях

• должностные инструкции

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

Методология IDEF0 - это методология моделирования, позволяющая создать функциональную модель, отображающую структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции (на рисунке представлена графическая диаграмма в нотации IDEF0 - пример реализован в системе Business Studio). Бизнес-процессы в нотации IDEF0 представляются в форме прямоугольника, а стрелки отражают связь с другими процессами и внешней средой.

Процедура (Cross Functional Flowchart , функциональная блок-схема, кросс-функциональная схема) – нотация для отображения процесса на нижнем уровне бизнес-модели. Процедура отображает детальный алгоритм выполнения бизнес-процесса, а так же всех участников бизнес-процесса и как они взаимодействуют между собой в рамках Процедуры.

Нотация Basic Flowchart используется для представления алгоритма выполнения процесса (нотация класса workflow). Используются графические элементы: событие, процесс, решение, два типа стрелок – стрелки предшествования и стрелки «Поток объектов». Нотация Процесс поддерживает декомпозицию на подпроцессы.

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