Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства проектирования информационных систем и технологий. Курс лекций
.pdf
сущности, и об экземплярах типа связи, устанавливаемых между экземплярами типа
сущности. В обсуждаемом здесь варианте ER–модели эта ассоциация всегда является
бинарной и может существовать между двумя разными типами сущностей или между
типом сущности и им же самим (рекурсивная связь).
В любой связи выделяются два конца (в соответствии с существующей парой
связываемых сущностей), на каждом из которых указываются имя конца связи, степень
конца связи (сколько экземпляров данного типа сущности должно присутствовать в
каждом экземпляре данного типа связи), обязательность связи (т. е. любой ли экзем-
пляр данного типа сущности должен участвовать в некотором экземпляре данного типа
связи). Связь представляется в виде ненаправленной линии, соединяющей две сущно-
сти или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с
сущностью используются:
трехточечный вход в прямоугольник сущности, если для этой сущности в свя-
зи могут (или должны) использоваться много (
одноточечный вход, если в связи может (или должен) участвовать только один
) экземпляров сущности;
many
экземпляр сущности.
Обязательный конец связи изображается сплошной линией, а необязательный —
прерывистой линией.
Связь между сущностями БИЛЕТ и ПАССАЖИР, показанная на рис. 7, связыва-
ет билеты и пассажиров. Конец связи с именем «для» позволяет связывать с одним пас-
сажиром более одного билета, причем каждый билет должен быть связан с каким–либо
пассажиром. Конец связи с именем «имеет» показывает, что каждый билет может при-
надлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один
билет.
Рис. 7 Пример типа связи
Трактовка изображенной диаграммы состоит в следующем:
каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;
каждый ПАССАЖИР может иметь один или более БИЛЕТОВ или не иметь
вовсе.
На следующем примере (рис. 8) изображена рекурсивная связь, связывающая
сущность МУЖЧИНА с ней же самой. Конец связи с именем «сын» определяет тот
41
факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем
«отец» означает, что не у каждого мужчины должны быть сыновья.
Рис. 8 Пример рекурсивного типа связи
Трактовка изображенной диаграммы состоит в следующем:
каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ;
каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.
Атрибутом сущности является любая деталь, которая служит для уточнения,
идентификации, классификации, числовой характеристики или выражения состояния
сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под
именем сущности и изображаются малыми буквами, возможно, с примерами.
Пример типа сущности ЧЕЛОВЕК с указанными атрибутами показан на рис. 9.
С технической точки зрения атрибуты типа сущности в ER–модели похожи на атрибу-
ты отношения в реляционной модели данных. И в том, и в другом случаях введение
именованных атрибутов вводит некоторую типовую структуру данных, имя которой
совпадает с именем типа сущности в случае ER–модели или с именем переменной от-
ношения в случае реляционной модели.
Этой типовой структуре должны следовать все экземпляры типа сущности или
все кортежи отношения. Но имеется и важное отличие. В реляционной модели данных
атрибут определяется как упорядоченная пара <имя_атрибута, имя_домена> (или
<имя_атрибута, имя_базового_типа_данных>, если понятие домена не поддерживает-
ся). Заголовок отношения, определяемый как множество таких пар, представляет собой
полный аналог структурного типа данных в языках программирования.
Рис. 9 Пример типа сущности с атрибутами
При определении атрибутов типа сущности в ER–модели указание домена атри-
бута не является обязательным, хотя это и возможно. Обсудим, чем вызвана эта воз-
42
можность «ослабленного» определения атрибутов. Прежде всего, семантические моде-
ли данных используются для построения концептуальных схем БД, и эти схемы преоб-
разуются в реляционные схемы БД, которые поддерживаются той или иной СУБД.
Несмотря на то, что в настоящее время типовые возможности СУБД в основном
стандартизованы (на основе стандарта языка SQL), детали базового набора типов дан-
ных и средств определения доменов в разных системах могут различаться. Поскольку
производители CASE–средств проектирования реляционных БД стремятся не связы-
вать обеспечиваемые ими возможности семантического моделирования с конкретной
реализацией СУБД, они стимулируют откладывание строгого определения типов атри-
бутов до стадии полного определения реляционной схемы.
Кроме того, при определении атрибута отношения допускается использование
имен атрибутов, совпадающих с именами своих доменов. Поэтому при определении
атрибутов типов сущности можно так подбирать их имена, что они в дальнейшем будут
подсказывать, какие домены у этих атрибутов имеются в виду.
Функциональное моделирование с использованием стандарта IDEF0
Методология IDEF0 является развитием хорошо известного графического языка
описания функциональных систем SADT (Structured Analysis and Design Teqnique).
IDEFO как стандарт был разработан в 1981 г. в рамках обширной программы ав-
томатизации промышленных предприятий Integrated Computer Aided Manufacturing
(ICAM) предложенной департаментом военно-воздушных сил США. Семейство стандартов унаследовало свое обозначение от названия этой программы — ICAM
DEFinition — IDEF.
В процессе практической реализации участники программы ICAM столкнулись с
необходимостью разработки новых методов анализа процессов взаимодействия в про-
мышленных системах. При этом кроме усовершенствованного набора функций для
описания бизнес-процессов, одним из требований к новому стандарту было наличие
эффективной методологии взаимодействия в рамках «аналитик–специалист». Другими
словами, новый метод должен был обеспечить групповую работу над созданием моде-
ли с непосредственным участием всех аналитиков и специалистов, занятых в рамках
проекта.
Со времени появления стандарт IDEFO претерпел несколько незначительных из-
менений, в основном, ограничивающего характера; последняя его редакция была вы-
пущена в декабре 1993 г. Национальным институтом по стандартам и технологиям
США (NIST).
43
Графический язык IDEFO прост и гармоничен. В основе методологии лежат че-
тыре основных понятия, первым из которых является понятие функционального блока
(Activity Box). Функциональный блок графически изображается в виде прямоугольника
(рис. 10) и представляет собой некоторую конкретную функцию в рамках рассматрива-
емой системы. По требованиям стандарта название каждого функционального блока
должно быть сформулировано в глагольном наклонении (например, «производить
услуги», а не «производство услуг»).
Каждая из четырех сторон функционального блока имеет свое определенное зна-
чение (играет свою роль):
Рис. 10 Функциональный блок
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input); правая сторона имеет значение
«Выход» (Output);
нижняя сторона имеет значение «Механизм» (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы дол-
жен иметь свой уникальный идентификационный номер.
Второе основное понятие методологии IDEF0 — интерфейсная дуга (Arrow).
Интерфейсные дуги также называют потоками или стрелками. Интерфейсная дуга
отображает элемент системы, который обрабатывается функциональным блоком или
оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная
стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование
(Arrow Label). По требованию стандарта, наименование должно быть оборотом суще-
ствительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной
степени определяющие процессы, происходящие в системе. Такими объектами могут
44
быть элементы реального мира (детали, вагоны, сотрудники и т. д.) или потоки данных
и информации (документы, данные, инструкции и т. д.).
Интерфейсные дуги бывают «входящими», «исходящими» и «управляющими» в
зависимости от стороны блока, к которой они подходят.
«Источником» (началом) и «приемником» (концом) функциональной дуги могут
быть только функциональные блоки. При этом «источником» может быть только выходная сторона блока, а «приемником» — любая из трех остальных.
Каждый функциональный блок должен иметь, по крайней мере, одну управля-
ющую интерфейсную дугу (т. е. каждый процесс протекает по каким-то правилам) и
одну исходящую (выдача некоторого результата).
При построении диаграмм по стандарту ЮЕРО необходимо правильно разделять
входящие и управляющие интерфейсные дуги, что не всегда просто.
На рис. 2.8 приведен пример диаграммы, изображающий функциональный блок
«Обработать заготовку». Для получения детали рабочему выдают заготовку и техноло-
гические указания. Неверно считать, что технологические указания (какой–то документ
или документы) и заготовка являются входящими объектами. На самом деле в этом
процессе заготовка обрабатывается по правилам, отраженным в технологических ука-
заниях, которые должны изображаться управляющей интерфейсной дугой.
Другой пример приведен на рис. 2.9, где описывается процесс обработки и из-
менения главным технологом технологических указаний. Здесь технологические указа-
45
ния отображаются входящей интерфейсной дугой, а управляющим объектом являются,
например, новые промышленные стандарты, учитывая которые производятся измене-
ния.
Теперь понятно, что входящие и управляющие интерфейсные дуги имеют схо-
жую природу. Тем не менее, для систем одного класса всегда есть определенные раз-
граничения. Так, например, в случае рассмотрения предприятий и организаций суще-
ствуют пять основных видов объектов:
• материальные потоки (детали, товары, сырье и т. д.);
• финансовые потоки (наличные и безналичные, инвестиции и т. д.);
• потоки документов (коммерческие, финансовые и организационные);
• потоки информации (информация, данные о намерениях, устные распоряжения
и т. д.);
• ресурсы (сотрудники, станки, машины и т. д.).
При этом в разных случаях входящими и исходящими интерфейсными дугами
могут отображаться все виды объектов, управляющими — только относящиеся к потокам документов и информации, а дугами–механизмами — только ресурсы.
Одно из главных отличий стандарта IDEF0 от других методологий классов DFD
(Data Flow Diagram) и WFD (Work Flow Diagram) — обязательное наличие управляющих интерфейсных дуг.
Третье основное понятие стандарта IDEF0 — это декомпозиция (Decomposition).
Декомпозиция применяется при разбиении сложного процесса на составляющие его
функции. При этом уровень детализации процесса определяется непосредственно раз-
работчиком модели.
Декомпозиция дает возможность представлять модель системы в виде иерархи-
ческой структуры отдельных диаграмм. Это делает диаграммы менее перегруженными
и легко читаемыми.
Модель IDEF0 всегда начинается с представления системы как единого цело-
го — одного функционального блока с интерфейсными дугами, входящими и выходя-
щими за пределы рассматриваемой области. Такая диаграмма с одним функциональ-
ным блоком называется контекстной диаграммой и обозначается идентификатором
«АО». В пояснительном тексте к контекстной диаграмме должна быть указана цель
(Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зре-
ния (Viewpoint).
Определение и формализация цели разработки модели IDEF0 — важнейшие ас-
пекты функционального моделирования. Цель, прежде всего, определяет первоочеред-
46
ные области исследования. Так, моделирование деятельности одного и того же пред-
приятия с целью разработки ИС или, например, оптимизации логистических цепочек
даст в результате различные модели.
Точка зрения определяет основное направление развития модели и уровень не-
обходимой детализации. Четкая фиксация точки зрения позволяет разгрузить модель,
отказаться от детализации и исследования второстепенных элементов разрабатываемой
ИС. Например, функциональные модели одного и того же предприятия, построенные
главным технологом и финансовым директором, будут существенно различаться по
направленности их детализации. Финансового директора в меньшей степени интересу-
ют аспекты обработки сырья на производственных станках, а главному технологу не
нужны детализированные схемы финансовых потоков. Правильный выбор точки зре-
ния существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции функциональный блок, который в контекстной диа-
грамме отображает систему как единое целое, подвергается детализации на другой диа-
грамме.
Диаграмма второго уровня содержит функциональные блоки, отображающие
главные подфункции функционального блока контекстной диаграммы, и называется
дочерней (Child diagram) по отношению к нему. Каждый из функциональных блоков,
принадлежащих дочерней диаграмме, соответственно называется дочерним блоком —
Child Box.
В свою очередь, функциональный блок «предок» называется родительским бло-
ком (Parent Box) по отношению к дочерней диаграмме, а диаграмма, к которой он при-
надлежит,— родительской диаграммой (Parent Diagram).
Каждая из подфункций дочерней диаграммы может затем детализироваться с
помощью аналогичной декомпозиции соответствующего ей функционального блока. В
каждом случае декомпозиции функционального блока все интерфейсные дуги, входя-
щие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим
достигается структурная целостность IDEFO-модели. Наглядно принцип декомпозиции
представлен на рис. 10. Следует обратить внимание на взаимосвязь нумерации функци-
ональных блоков и диаграмм — каждый блок имеет свой уникальный порядковый но-
мер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под
ним указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обо-
значения говорит о том, что декомпозиция для данного блока не существует.
47
Рис. 10. Декомпозиция функциональных блоков
Возможны ситуации, когда отдельные интерфейсные дуги нет смысла рассмат-
ривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или
наоборот, отдельные дуги не имеют практического смысла выше какого–то уровня.
Например, интерфейсную дугу, изображающую «деталь» на входе функционального
блока «Обработать на токарном станке», не имеет смысла отражать на диаграммах бо-
лее высоких уровней — это будет только перегружать диаграммы и делать их сложны-
ми для восприятия. С другой стороны, бывает необходимо избавиться от отдельных
«концептуальных» интерфейсных дуг и не детализировать их глубже некоторого
уровня.
Для решения подобных задач в стандарте IDEF0 предусмотрено понятие тунне-
лирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок у нача-
ла интерфейсной дуги означает, что эта дуга не была унаследована от функционального
родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою
очередь, такое же обозначение у конца (стрелки) интерфейсной дуги рядом с блоком–
48
приемником означает, что в дочерней по отношению к этому блоку диаграмме эта дуга
не будет отображаться и рассматриваться. Чаще всего отдельные объекты и соответ-
ствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных
уровнях иерархии, т. е. они сначала «погружаются в туннель», а затем при необходимо-
сти «возвращаются из туннеля».
Четвертое базовое понятие стандарта IDEF0 — глоссарий (Glossary). Для каждо-
го из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) суще-
ствующий стандарт подразумевает создание и поддержание набора соответствующих
определений, ключевых слов, повествовательных изложений и т. д., которые характе-
ризуют объект, отображенный данным элементом. Такой набор называется глоссарием
и является описанием сущности данного элемента. Например, для управляющей ин-
терфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень по-
лей соответствующего дуге документа, необходимый набор виз и т. д. Глоссарий гар-
монично дополняет наглядный графический язык, снабжая диаграммы необходимой
поясняющей информацией. Обычно IDEFO-модели несут в себе сложную и концентри-
рованную информацию, и для того, чтобы не перегружать их и сделать удобочитаемы-
ми, в соответствующем стандарте приняты следующие принципиальные ограничения
сложности:
• ограничение числа функциональных блоков на диаграмме тремя и шестью.
Верхний предел (шесть) заставляет разработчика использовать иерархии при описании
сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диа-
грамме достаточно деталей, чтобы оправдать ее создание;
• ограничение числа подходящих к одному функциональному блоку (выходящих
из одного функционального блока) интерфейсных дуг четырьмя.
Следовать этим ограничениям необязательно, однако их использование весьма
целесообразно в практической работе.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и со-
гласовывать модель большим коллективом специалистов — профессионалов в разных
областях деятельности. Обычно процесс разработки является итерационным и состоит
из следующих условных этапов.
1. Создание модели группой специалистов из разных сфер деятельности пред-
приятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение пер-
воначальной модели является динамическим процессом, в течение которого авторы
опрашивают компетентных лиц о структуре различных процессов. На основе имею-
49
щихся положений, документов и результатов опросов создается черновик (Model Draft)
модели.
2. Распространение черновика для рассмотрения, согласований и комментариев.
На этой стадии происходит обсуждении черновика модели с широким спектром компе-
тентных лиц (и терминах IDEF0 — читателей) на предприятии. При этом каждая из
диаграмм черновой модели письменно критикуется и комментируется, а затем переда-
ется автору. Автор, в свою очередь, также письменно соглашается с критикой или от-
вергает ее с изложением логики принятия решения и вновь возвращает откорректиро-
ванный черновик на дальнейшее рассмотрение. Этот цикл продолжается до тех пор,
пока авторы и читатели не придут к единому мнению.
3. Официальное утверждение модели. Утверждение согласованной модели про-
исходит руководителем рабочей группы в том случае, если у авторов модели и читате-
лей отсутствуют разногласия по поводу ее адекватности. Окончательная модель пред-
ставляет собой согласованное представление о предприятии (системе) с заданной точки
зрения и для заданной цели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для
лиц, не принимавших участия в ее создании, эффективной для проведения показов и
презентаций. В дальнейшем, на базе построенной модели могут быть организованы но-
вые проекты, нацеленные на производство изменений на Предприятии (в системе).
КОНЦЕПЦИИ УНИФИЦИРОВАННОГО ПРОЦЕССА ПРОЕКТИРОВАНИЯ ИС
Введем следующие понятия.
Артефакт — это общее название для любых видов информации, создаваемой,
изменяемой, или используемой сотрудниками при создании системы. Наиболее инте-
ресный тип артефактов, используемых в унифицированном процессе это модели
Модель — это абстракция (знания), описывающая моделируемую систему с
определенной точки зрения и на определенном уровне абстрагирования. Под точкой
зрения будем понимать представление аналитика требований или проектировщика.
Процесс разработки в бизнесе разработки программного обеспечения — набор
деятельностей, необходимых для переработки требований заказчика в согласованный
набор артефактов, представляющих собой программное обеспечение, а позднее для пе-
реработки изменений в этих требованиях в новые версии программного обеспечения.
Понятие «процесс» трактуется по–разному и употребляется в различных
смыслах для различных контекстов, например, бизнес–процесс, процесс разработки,
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]