Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки
 Скачать 3.53 Mb.
|
|
6.2.2. Синтаксис и семантика моделей IDEF4 6.2.2.1. Подмодель классов IDEF4 Подмодель классов описывает структуру классов и их наследование. Диа- граммы наследования описывают порядок наследования классов. Например, класс Filled-Rectangle наследует структуру и поведение непосредственно от классов Rectangle и Filled-Object, которые, в свою очередь, наследуют классу Object (рис. 6.2). Диаграммы наследования уточняются с помощью таблиц инва- риантов классов. Диаграммы экземпляров связаны с диаграммами типов и используются с целью их уточнения (например, если между ними существуют сложные взаимо- связи) (рис. 6.3). Диаграммы протоколов описывают типы аргументов классов при вызове методов. На рис. 6.4 дана диаграмма протоколов для объекта Fill-ClosedObject. Он воспринимает экземпляр класса Polygon в качестве первичного аргумента и экземпляр класса Color — в качестве второго, и возвращает экземпляр себя клас- су Polygon. 6.2.2.2. Подмодель методов IDEF4 Диаграмма таксономий методов классифицирует методы по подобности поведения. На рис. 6.5 метод Print выражает контракт, что состояние метода олжно быть печатаемо, и быть либо печатаемым текстом, либо печатаемой гра- фикой. 95 Рис. 6.2. Пример диаграммы наследования IDEF4 Рис. 6.3. Пример диаграммы типов IDEF4 Диаграммы клиентов связывают вызывающие и вызываемые процедуры. Сдвоенные стрелки направлены от вызываемой к вызывающей процедуре. На рис. 6.6 процедура Redisplay вызывает процедуру Erase объекта Erasable-Object и процедуру Draw объекта Drawable-Object. 96 Рис. 6.4. Пример диаграммы протоколов IDEF4 Рис. 6.5. Пример диаграммы таксономий методов IDEF4 97 Рис. 6.6. Пример диаграммы клиент IDEF4 7. Методика DFD. Диаграммы потоков данных 7.1. Методология DFD Методика IDEF0 может дополняться не только диаграммами потока работ (IDEF3), но и диаграммами потоков данных (Data Flow Diagramming, DFD). Нотация диаграмм потоков данных позволяет отображать на диаграмме как шаги бизнес-процесса, так и поток документов и управления (в основном управления, поскольку на верхнем уровне описания процессных областей значе- ние имеет передача управления). Также на диаграмме можно отображать средст- ва автоматизации шагов бизнес-процессов. Обычно используется для отображе- ния третьего и ниже уровня декомпозиции бизнес-процессов (первый уровень — перечень бизнес-процессов (IDEF0), а второй — функции, выполняемые в рам- ках бизнес-процессов (IDEF3)). Области применения диаграмм потоков данных: –– моделирование функциональных требований к проектируемой системе; –– моделирование существующего процесса движения информации; –– описание документооборота, обработки информации; –– дополнение к модели IDEF0 для более наглядного отображения теку- щих операций документооборота; 98 –– проведение анализа и определения основных направлений реинжини- ринга информационной системы. Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнесфункциями, так и системы в целом с внешней информационной средой. Методика DFD удобна для описания не только бизнес-процессов (как до- полнение к IDEF0), но и программных систем: –– DFD-диаграммы создавались как средство проектирования программ- ных систем (в то время как IDEF0 — средство проектирования систем вообще), поэтому DFD имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных являются прообразами файлов или баз данных); –– наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершённость IDEF0 (моделирование обрывается на некотором достаточно низком уровне, когда дальнейшая детализация модели становится бессмысленной) и построить полную функциональную специфика- цию разрабатываемой системы. С помощью DFD-диаграмм требования к проектируемой информационной системе разбиваются на функциональные компоненты (процессы) и представля- ются в виде сети, связанной потоками данных. Главная цель декомпозиции DFD- функций — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. На схемах бизнес-процесса отображаются: –– функции процесса; –– входящая и исходящая информация при описании документов; –– внешние бизнес-процессы, описанные на других диаграммах; –– точки разрыва при переходе процесса на другие страницы. При моделировании DFD система рассматривается как сеть связанных ме- жду собой функций, т. е. как совокупность сущностей. Методология основана на 99 идее нисходящей иерархической организации. Целью является преобразование общих, неясных знаний о требованиях к системе в точные определения. Внима- ние фокусируется на потоках данных. Методология поддерживается традицион- ными нисходящими методами проектирования. 7.1.1. Варианты методологии DFD Существует два основных варианта методологии DFD: методология Гей- на–Сарсона (Gane–Sarson) и методология Йордана–Де Марко (Yourdon–De arko). Главной отличительной чертой методологии Гейна-Сарсона является на- личие этапа моделирования данных, определяющего содержимое хранилищ дан- ных (БД и файлов) в DFD. Этот этап включает построение списка элементов данных, располагающихся в каждом хранилище данных; анализ отношений ме- жду данными и построение соответствующей диаграммы связей между элемен- тами данных; представление всей информации по модели в виде связанных нор- мализованных таблиц. Кроме того, эти методологии отличаются нотацией. Обе методологии основаны на простой концепции нисходящего поэтапно- го разбиения функций системы на подфункции: 1) формирование контекстной диаграммы верхнего уровня, идентифици- рующей границы системы и определяющей интерфейсы между системой и ок- ружением; 2) формирование списка внешних событий, на которые система должна реагировать (после интервьюирования эксперта предметной области), для каж- дого из которых строится пустой процесс (Bubble) в предположении, что его функция обеспечивает требуемую реакцию на это событие (в большинстве слу- чаев включает генерацию выходных потоков и событий); 3) проведение детализации для каждого из пустых процессов. Методология DFD позволяет уже на стадии функционального моделирова- ния определить базовые требования к данным. В этом случае совместно исполь- зуются методологии DFD и IDEF1X. 100 Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0: 1) строится физическая модель, отображающая текущее состояние дел; 2) полученная модель преобразуется в логическую модель, которая ото- бражает требования к существующей системе; 3) строится модель, отображающая требования к будущей системе; 4) строится физическая модель, на основе которой должна быть построена новая система. Альтернативным является подход, применяемый при создании программ- ного обеспечения, называемый событийным разделением (Event Partitioning), в котором различные диаграммы DFD выстраивают модель системы. 1) Логическая модель строится как совокупность процессов и документи- рования того, что эти процессы должны делать. 2) С помощью модели окружения система описывается как взаимодейст- вующий с событиями из внешних сущностей объект. Модель окружения (Environment Model) обычно содержит описание цели системы, одну контекст- ную диаграмму и список событий. Контекстная диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаи- модействует, ссылки и некоторые стрелки, импортированные из диаграмм IDEF0 и DFD. Включение внешних ссылок в контекстную диаграмму не отменяет тре- бования методологии чётко определить цель, область и единую точку зрения на моделируемую систему. 3) Модель поведения (Behavior Model) показывает, как система обрабаты- вает события. Эта модель состоит из одной диаграммы, в которой каждый блок изображает каждое событие из модели окружения, могут быть добавлены храни- лища для моделирования данных, которые необходимо запоминать между собы- тиями. Потоки добавляются для связи с другими элементами, и диаграмма про- веряется с точки зрения соответствия модели окружения. 101 7.1.2. Мини-спецификация Мини-спецификация — это алгоритм описания задач, выполняемых про- цессами, множество всех мини-спецификаций является полной спецификацией системы. Мини-спецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся специфи- кацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Проектные спецификации строятся по DFD и их мини-спецификациям ав- томатически. Наиболее часто для описания проектных спецификаций использу- ется методика структурных карт Джексона, иллюстрирующая иерархию моду- лей, связи между ними и некоторую информацию об их исполнении (последова- тельность вызовов, итерацию). Существует ряд методов автоматического преоб- разования DFD в структурные карты. 7.2. Синтаксис и семантика моделей DFD Диаграммы потоков данных применяются для графического представления (Flowchart) движения и обработки информации. Обычно диаграммы этого типа используются для проведения анализа организации информационных потоков и для разработки информационных систем. Каждый блок в DFD может развёрты- ваться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагиро- ваться от деталей. DFD-диаграммы моделируют функции, которые система должна выпол- нять, но почти ничего не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени — для этих целей используются диаграммы сущность-связь и диаграммы переходов состояний. Основные объекты нотации DFD: –– блоки (Blocks) или работы (Activities) — отображают процессы обра- ботки и изменения информации; 102 –– стрелки (Arrows) или потоки данных (Data Flow) — отображают ин- формационные потоки; –– хранилища данных (Data Store) — отображают данные, к которым осу- ществляется доступ; эти данные используются, создаются или изменяются рабо- тами; –– внешние ссылки (External References) или внешние сущности (External Entity) — отображают объекты, с которыми происходит взаимодействие. Работы DFD –– графическое изображение операции по обработке или пре- образованию информации (данных). Входная информация преобразуется в вы- ходную. Работы именуются глаголами в неопределённой форме с последующим дополнением. По нотации Гейна–Сарсона DFD-блок изображается прямоугольником со скруглёнными углами (рис. 7.1). Каждый блок должен иметь уникальный номер для ссылки на него внутри диаграммы. Номер каждого блока может включать префикс, номер родительского блока (А) и номер объекта, представляющий со- бой уникальный номер блока на диаграмме. Например, работа может иметь но- мер А.12.4. Рис. 7.1. Работа DFD Во избежание пересечений линий потоков данных один и тот же элемент может на одной и той же диаграмме отображаться несколько раз; в таком случае 103 два или более прямоугольников, обозначающих один и тот же элемент, могут идентифицироваться линией, перечёркивающей нижний правый угол. Поток данных –– механизм, использующийся для моделирования передачи информации между участниками процесса информационного обмена (функция- ми, хранилищами данных, внешними ссылками). По нотации Гейна–Сарсона по- ток данных изображается стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причём направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0-диаграммы, стрелки DFD могут входить или выходить из любой стороны блока. Стрелки описывают, как объекты (включая данные) двигаются из одной части системы в другую. Поскольку в DFD каждая сторона блока не имеет чёт- кого назначения, в отличие от блоков IDEF0-диаграммы, стрелки могут подхо- дить и выходить из любой грани. В DFD-диаграммах для описания диалогов типа команды-ответа между операциями применяются двунаправленные стрелки между функцией и внешней сущностью и/или между внешними сущностями. Стрелки могут сливаться и раз- ветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сег- мент сливающейся или разветвляющейся стрелки может иметь собственное имя. Иногда информация может двигаться в одном направлении, обрабатывать- ся и возвращаться обратно. Такая ситуация может моделироваться либо двумя различными потоками, либо одним двунаправленным потоком. На поток данных можно ссылаться, указывая процессы, сущности или накопители данных, кото- рые поток соединяет. Каждый поток должен иметь имя, расположенное вдоль или над стрелкой, выбранное таким образом, чтобы в наибольшей степени пере- давать смысл содержания потока пользователям, которые будут рассматривать диаграмму потоков данных. Хранилище данных –– графическое представление потоков данных, им- портируемых/экспортируемых из соответствующих баз данных, изображает объ- 104 екты в покое. Является неким прообразом базы данных информационной систе- мы организации. Хранилища данных предназначены для изображения неких абстрактных устройств для хранения информации, которую можно в любой момент времени поместить или извлечь из них, безотносительно к их конкретной физической реализации. Хранилища данных используются: –– в материальных системах (там, где объекты ожидают обработки, на- пример в очереди); –– в системах обработки информации для моделирования механизмов со- хранения данных с целью дальнейших операций. По нотации Гейна–Сарсона хранилище данных обозначается двумя гори- зонтальными линиями, замкнутыми с одного края (рис. 7.2). Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным чис- лом в квадрате с левой стороны, например D5. Рис. 7.2. Хранилище данных DFD В модели может быть создано множество вхождений хранилищ данных, каждое из которых может иметь одинаковое имя и ссылочный номер. Для того чтобы не усложнять диаграмму потоков данных пересечениями линий, можно изображать дубликаты накопителя данных дополнительными вертикальными линиями с левой стороны квадрата. Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов. Внешняя сущность –– объект диаграммы потоков данных, являющийся ис- точником или приёмником информации извне модели. Внешние сущности изо- бражают входы и/или выходы, т. е. обеспечивают интерфейс с внешними объек- 105 тами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляющие со- бой источник или приёмник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т. д. По нотации Гейна–Сарсона пиктограмма внешней ссылки представляет собой оттенённый прямоугольник, верхняя левая сторона которого имеет двой- ную толщину и обычно располагается на границах диаграммы (рис. 7.3). Внеш- няя ссылка может идентифицироваться строчной буквой Е в левом верхнем углу и уникальным номером, например Е5. Кроме того, внешняя ссылка имеет имя. Рис. 7.3. Внешняя сущность DFD Одна и та же внешняя ссылка может быть использована многократно на одной или нескольких диаграммах. Обычно к такому приёму прибегают для то- го, чтобы не рисовать слишком длинных и запутанных стрелок. Каждая внешняя сущность имеет префикс. При рассмотрении системы как внешней функции часто указывается, что она находится за пределами границ моделируемой системы. После проведения анализа некоторые внешние ссылки могут быть перемещены внутрь диаграммы потоков данных рассматриваемой системы или, наоборот, какая-то часть функ- ций системы может быть вынесена и рассмотрена как внешняя ссылка. Преобра- зования потоков данных во внешних сущностях игнорируются. Межстраничные ссылки (Off-Page Reference) –– инструмент нотации DFD, описывающий передачу данных или объектов с одной диаграммы модели на 106 другую. Стрелка межстраничной ссылки имеет идентифицирующее имя, номер и изображение окружности. Помимо этого, для каждого информационного потока и хранилища опре- деляются связанные с ними элементы данных. Каждому элементу данных при- сваивается имя. Также для него может быть указан тип данных и формат. Имен- но эта информация является исходной на следующем этапе проектирования — построении модели «сущность–связь». При этом, как правило, информационные хранилища преобразуются в сущности. Проектировщику остаётся только решить вопрос с использованием элементов данных, не связанных с хранилищами. В качестве примера построим схему бизнес-процесса «Выдача диплома» (рис. 7.4). Рис. 7.4. DFD-схема «Выдача диплома» 107 8. Универсальный язык UML моделирования сложных систем 8.1. Диаграммы UML Описание языка UML состоит из двух взаимодействующих частей: 1) семантики языка UML — некоторой метамодели, определяющей абст- рактный синтаксис и семантику понятий объектного моделирования на языке UML; 2) нотации языка UML — графической нотации для визуального представ- ления семантики языка UML. Семантика определяется для двух видов объектных моделей: –– структурных моделей (статических моделей), которые описывают структуру сущностей или компонентов некоторой системы; –– моделей поведения (динамических моделей), которые описывают пове- дение или функционирование объектов системы. Нотация языка UML включает в себя описание отдельных семантических элементов, которые могут применяться при построении диаграмм. В рамках языка UML все представления о модели сложной системы фик- сируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм: –– диаграмма вариантов использования (Use Case Diagram); –– диаграмма классов (Class Diagram); –– диаграммы поведения (Behavior Diagrams): – диаграмма состояний (Statechart Diagram), – диаграмма деятельности (Activity Diagram), – диаграммы взаимодействия (Interaction Diagrams): * диаграмма последовательности (Sequence Diagram), * диаграмма кооперации (Collaboration Diagram); –– диаграммы реализации (Implementation Diagrams): – диаграмма компонентов (Component Diagram), – диаграмма развёртывания (Deployment Diagram). |