Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Нижегородский Государственный Университет им. Н.И. Лобачевского

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Методичка ПИС.doc

Скачиваний:

Добавлен:

11.11.2019

Размер:

287.23 Кб

Скачать

☆

Основные положения case Сложность программного обеспечения

Говоря о сложности программного обеспечения в работе [1] Гради Буч выделяет четыре основные причины:

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

Остановимся подробнее на каждой из этих причин.

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

Сложность возникает из-за «нестыковки» между заказчиками программного продукта и его исполнителями, так как часто они разговаривают на разных языках.

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

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

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

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

Пять признаков сложной системы

Гради Буч приводит следующие пять признаков сложной системы [1]:

Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь могут быть разделены на подсистемы и т.д., вплоть до самого низкого уровня. Важно осознать, что архитектура сложных систем складывается и из компонентов, и из иерархических отношений этих компонентов.
Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя. Низший уровень для одного разработчика может оказаться достаточно высоким для другого. Особенно это важно на начальной стадии проектирования программных систем.
Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это различие внутрикомпонентных и межкомпонентных взаимодействий обуславливает разделение функций между частями системы и дает возможность относительно изолированно изучать каждую часть.
Иерархические системы обычно состоят из немногих подсистем, по-разному скомбинированных и организованных. То есть разные сложные системы содержат одинаковые структурные части. Эти части содержат общие боле мелкие компоненты, например, модули решения квадратного уравнения или модули решения линейных систем. В качестве одинаковых структурных частей могут использоваться и целые подсистемы. В настоящее время этот признак нашел отражение в технологии повторного использования программных продуктов [2].
Любая работающая система является результатом развития более простой системы. Сложная система, спроектированная «с нуля», никогда не заработает. Следует начинать с работающей системы. Здесь частично отражен предыдущий признак, говорящий о том, что ранее созданная сложная система становится «элементарной» и может использоваться в качестве подсистемы для строительства более сложной системы. В то же время, подчеркивается тот факт, что невозможно сразу создать сложные объекты. Целесообразно их строить уже из «элементарных», либо сначала создать набор «элементарных» подсистем и уже из них создавать сложную систему, либо развивать какую-то из «элементарных» подсистем.

Структурный анализ. Его принципы

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

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

принцип «разделяй и властвуй»
принцип иерархического упорядочивания.

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

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

В работе [3] приводятся еще 10 принципов, который заслуживают внимания:

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

Руководствуясь указанными принципами, можно уже при проектировании понять, что будет представлять из себя создаваемая система. Использование структурных методов также обеспечивает стандартизацию описания логической структуры анализируемой системы. Выгоды такого подхода очевидны:

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

· над системой может работать большая группа людей;

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

Назначение методов и средств case

Стремительное внедрение компьютеров в различные сферы человеческой деятельности потребовало и значительной разработки программных средств (ПС). Создание современных программ - это сложный и трудоемкий процесс, как правило, коллективного инженерного труда. Этот процесс уже требует соответствующих “технологий программирования” или более современный термин “программная инженерия”. Неотъемлемой частью этих технологий является автоматизация проектирования программных средств (Computer - Aided Software Engineering - автоматизация проектирования программных средств).

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

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

Два поколения case –средств

Существует два поколения CASE - средств. Рассмотрим рисунок, приведенный в статье Б.А. Позина ”Современные средства программной инженерии: классификация и направления развития”.

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

Рассмотрим понятие языка четвертого поколения(4GL).

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

Суть понятия языка “четвертого поколения” состоит в создании среды разработчика прикладной программы. Обычно в 4GL собственно язык программирования в явном виде отсутствует. Его заменяет совокупность заполняемых таблиц или рисуемых (создаваемых) программистом экранов, меню. По способу создания прикладной программы 4GL подразделяются на реализующие генерацию (Oracle) либо компилирующие, либо интерпретирующие прикладную программу (PRO IV) с помощью библиотеки процедур или классов (объектов). По отношению к СУБД языки четвертого поколения подразделяются на СУБД - зависимые и СУБД - независимые. Первые обычно поставляются вместе с СУБД (Oracle, Informix, Ingres). СУБД независимые 4GL обычно соединяются с несколькими СУБД с помощью мостов и позволяют создавать приложения для работы с несколькими СУБД в одной прикладной системе (PRO IV, JAM). Программы, написанные на таких языках, не только практически переносимы, но представляют собой абсолютно лучшее решение для гетерогенных сетей, а также систем, использующих несколько СУБД.

Рассмотрим второе поколение CASE - средств.

Реализация CASE-средств второго поколения направлена на создание интегрированной среды комплексной автоматизации процессов проектирования, разработки и сопровождения, реализующих некоторую методологию проектирования ПС. В этих средствах охватываются не только традиционные процессы проектирования и разработки, но и работы по анализу готового ПС (re-engineering) с целью устранения ошибок и, главное, оптимизация характеристик, а также и по укрупненному описанию готового ПС с целью проектирования нового по прототипу уже созданного (reverse engineering). Эти процессы в первую очередь традиционны для сопровождения и модификации ПС.

Средства второго поколения, как правило, ориентированы на решение задачи комплексной автоматизации процесса разработки и сопровождения ПС. Хотя обычно результатом проектирования с помощью CASE 2-го поколения является проектная документация, а в некоторых случаях и прототип интерфейса с конечным пользователем, имеется практическая потребность в автоматическом использовании проектной информации генерации части ПС. В этой связи эти CASE обычно содержат мосты к СУБД и языкам четвертого поколения. С помощью этих мостов осуществляется генерация SQL - текстов для описания логической структуры баз данных или текстов на языке четвертого поколения. В некоторых случаях объем генерируемой части может составлять до 50-70% прикладной программы. Однако создание работающего приложения все-таки остаются задачей программиста. Работа на языках четвертого поколения, к тому же по хорошо проработанному проекту, позволяет существенно снизить трудоемкость создания программ, но обычно не позволяет исключить программистский труд.

Диаграммы потоков данных (dfd) (Data Flow Diagram)

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используются две различные нотации: Йодана (Yordon) и Гейна-Сарсона (Gane-Sarson).

Рассмотрим основные символы DFD

	Нотация Йодана	Нотация Гейна-Сарсона
Поток данных
Процесс
Хранилище
Внешняя сущность

Более подробно будем говорить о нотации Гейна-Сарсона.

Внешняя сущность.

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

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

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

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

Потоки данных

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

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

Процесс

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

Кроме того, каждый процесс должен иметь уникальный номер для ссылки на него внутри диаграммы.

Следует отметить, что если вы используете такие элементы как “обработать”, “модернизировать”, или “отредактировать”, то это означает, что вы, вероятно, пока недостаточно глубоко понимаете данную функцию процесса и потребуется дальнейший анализ.

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

Процессы обозначаются прямоугольниками с закругленными углами, распределенными на три сектора.

Накопитель данных.

В процессе анализа может обнаружиться, что имеются участки, где нам необходимо определить данные, которые будут сохраняться в памяти между процессами, при этом не делается никаких предложений о физической реализации памяти. Фактически накопитель данных представляет “срез“ потоков данных во времени.

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

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

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

Диаграммы “Сущность-связь”

Диаграммы “Сущность-связь”(ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию. объектов, важных для предметной области(сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами(связей).

Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker).

Приведем некоторые определения:

Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникальной. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, Заказчик, а не Петров).

Отношение представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.д.).

Приведем символы ERD в нотации Чена:

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

Зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она всегда должна иметь отношения с другими сущностями.

Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.

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

Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями.

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

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

{“0 или 1”, “0 или более”, “1”, “1 или более”, “p:q” (диапазон)}.

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

1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
1*n (один-ко-многим). Отношения данного типа являются наиболее часто используемыми.
n*m (много-ко-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением ассоциативных сущностей и с введением новых отношений).

Дадим ряд определений применительно к системе Visible Analyst Workbench (VAW).

Сущность(Entity)

Сущность (или более правильно - тип сущности) - это ничто иное, как некоторый объект реального мира, который Вы можете описать. Наиболее общим типом сущности является фундаментальная сущность (fundamental entity), которая обычно называется просто сущностью. Она включает элементы данных (также называемые атрибутами) и Вы можете описать ее состав в поле "состав" (composition field) репозитория.

Фундаментальная сущность - это или объект или событие. Она представляется на ER - схеме в виде прямоугольника.

Ассоциативная сущность (Associative Entity)

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

Атрибутивная сущность (Attributive Entity)

Третьим типом является атрибутивная сущность. Она используется, чтобы показать данные, которые зависят от существования фундаментальной сущности. Она также используется для отображения повторяющихся групп данных. Например, ассоциативная сущность Заказ может иметь атрибутивную сущность Поставка, отражающая полностью или частично поставку продукции по этому заказу. Она изображается прямоугольником с закругленными линиями, пересекающими углы, и представляется последней кнопкой символов в управляющей строке.

Логическая связь (Relationship)

Логическая связь показывает, как одна сущность влияет на другую или какое влияние другая сущность оказывает на нее. Логическая связь представляется линией, соединяющей две сущности. Линии связи обычно имеют две метки по каждому направлению связи. Связи имеют терминаторы (terminators), которые показывают: каким отношением данные связаны между собой: один-к-одному, один-ко-многим или многие-ко-многим (что также называется показателем кардинальности), а также является ли связь необязательной (optional) или обязательной (mandatory).

Кластер (Cluster)

Кластер - это объединение сущностей и связей между ними. Он не является реальной частью Вашей схемы, т.к. не несет никакой новой информации. Тем не менее, он может быть очень полезен, когда Вы хотите показать очень большие модели данных на одной схеме и, в то же время, сделать ее понятной. У Вас имеется возможность объединять группы сущностей в кластеры и соединять их связями на схеме, отображаемыми обобщенным образом. Эта возможность позволяет ограничить отображение деталей на схеме, т.к. более обобщенный взгляд позволяет сделать наглядным представление Вашей модели данных. Кластер создается в репозитории и сущности перечисляются в его поле "состав" (composition field). Схема кластеров (cluster view) может, затем, создана VAW для отображения не реальных связей сущностей, а псевдо- связей между этими кластерами. VAW сформирует неструктурную схему, но информация, содержащаяся на этой схеме соответствует имеющимся ER - схемам.

Кардинальность связи

VAW поддерживает три различные нотации для отображения кардинальности связей, включая "вороньи лапки" (Crowsfoot), стрелки (arrow) и по Бахману (Bachman). Тип нотации, которую Вы будете использовать, выбираете Вы сами, когда создаете новый проект. Число имен на одну связь также выбираете Вы сами. Вы можете задать одно или два имени на одну связь. В практикуме используется стандартная нотация Crowsfoot с двумя именами на одну связь.

При проектировании диаграмм «сущность-связь» необходимо помнить, что основным "строительным блоком" модели является тип сущности (или просто сущность), а поскольку связи не могут существовать без сущностей, то Вы сначала будете размещать сущности данных на схеме, чтобы затем добавить и связи.

Структурные схемы (Схемы Констатайна)

Структурная схема - это схема, применяемая в методике структурного проектирования. Цель структурного проектирования заключается в том, чтобы дать средства для преобразования описания процессов и спецификаций, создаваемых на основе схем потоков данных, в проект программного обеспечения. Таким образом, это один из методов графического программирования. Структурное проектирование имеет более субъективный характер, чем структурный анализ, в том смысле, что здесь имеется гораздо меньше точных и строгих правил, связанных с тем, как преобразовать результаты структурного анализа в структурный проект. Мы проведем Вас через простой процесс проектирования, который завершится генерацией кода программ из Вашего учебного проекта.

В отличие от схемы потоков данных структурная схема рассматривается, как одна, возможно и очень большая, схема. Для облегчения изучения схемы ее части отображаются на отдельных страницах. Модули могут инициировать модули, располагаемые на других страницах схемы, но все модули концептуально считаются расположенными на схеме одного уровня. Вместо того, чтобы размещать схемы на нескольких страницах, используя для их соединения межстраничные коннекторы, Вы можете создать также одну большую схему с использованием опции Multi - Page (Многостраничная).

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

Модуль (Module)

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

Библиотечный модуль (Library Module)

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

Макрос (Macro)

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

Библиотечный макрос(Library Macro)

Это макрос, который используется многократно в системе. Его символ - прямоугольник со штриховыми краями и штриховыми вертикальными линиями по бокам.

Модуль-данные (Data Only Module)

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

Информационный кластер (Information Cluster)

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

Страничный коннектор (On-Page Connector)

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

Межстраничный коннектор (Off-page Connector)

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

Линия вызова (Invocation Line)

Линия вызова рисуется от одного модуля к другому и она символизирует то, что первый модуль вызывает (invokes или calls) второй - с предположением, что вызванный модуль вернет управление в вызывающий модуль. Линия обычно, хотя и не всегда, имеет стрелку на конце, указывающую на вызываемый модуль. Cуществует еще две разновидности линий вызова, называемые связью по управлению (сontrol сonnection) и связью по данным (data connection).

Связь по управлению (Control Connection)

Связь по управлению описывает одностороннюю передачу управления от модуля к модулю. Она изображается, как линия с зачерченным кружком (filled in circle) на одном из концов и стрелкой на другом конце. Стрелка - необязательный элемент.

Связь по данным (Data Connection)

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

Параметр (Couple)

Параметр - это часть информации, передаваемая между модулями и символизирует аргументы, передаваемые между программами или функциями. Он размещается рядом с линией вызова, указывая направление передачи данных. Существуют параметры-данные (data couples), параметры-управление (control couples), обобщенные параметры (generic couples). Третья кнопка в управляющей строке переводит курсор в режим добавления параметров. Он имеет вид похожий на "карандаш со стрелкой".

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

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

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

Работа с Visible Analyst 7.2 на примере разработки системы выдачи водительских удостоверений Краткий обзор Visible Analyst 7.2

Visible Analyst – это приложение для Microsoft Windows. Версии Visible Analyst 7.2 и выше работают с Windows 95 и 98, а также с Windows NT.

К основным компонентам Visible Analyst относятся: средства разработки диаграмм, блок репозитория и модуль, ответственный за соблюдение правил выбранной методологии. Средства разработки диаграмм используются для создания «схемы» разрабатываемой вами системы.

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

Блок репозитория представляет собой модуль, управляющий индивидуальными репозиториями проектов. Репозиторий проекта содержит детальную информацию обо всех объектах, которые используются в разрабатываемой системе. Объекты репозитория это процессы, сущности, отношения, классы и т.д. Для каждого объекта в репозитории хранится описание, состав, числовые и смысловые значения, ссылки вхождения и другие более конкретные данные. Репозиторий делает Visible Analyst более сильным инструментом разработки. Visible Analyst это больше, чем просто средство разработки диаграмм; использование репозитория и модуля контроля за соблюдением правил выбранной методологии, предоставляет возможность описания задачи, документирования и обеспечения непротиворечивости системы в целом. Visible Analyst дополнительно имеет возможность создания отчетов и программного кода для вашей системы, используя для этого данные из репозитория.

Преимущества Windows-версии Visible Analyst

Рабочая область приложения

Вся работа с Visible Analyst происходит либо в главной рабочей области приложения (см. рис 1.1), либо в репозитории.

Настройки Windows

Настройки Visible Analyst регулируются через Windows, включая определение аппаратных средств, цветов рабочего стола, настроек принтера и набора доступных шрифтов. Любые изменения этих свойств, проведенные в операционной системе Windows, автоматически влияют на настройки Visible Analyst.

Многодокументный интерфейс

Многодокументный интерфейс (MDI) приложения позволяет открывать сразу несколько диаграмм различных типов, каждую в своем окне (см. рис. 1.2). Можно изменять размеры этих окон, перемещать их, сворачивать и разворачивать на весь экран и т.д. Используя буфер обмена Windows можно копировать объекты из одной диаграммы в другую или в другое Windows-приложение.

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

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

Левой кнопкой

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

Правой кнопкой

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

Двойной щелчок

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

Клавиша TAB

Чтобы выделить только текст подписи для выделенного объекта, нажмите клавишу TAB. Если подпись находится вне границ объекта, вы можете выделить ее с помощью щелчка мышкой. Продолжая нажимать TAB, Вы будете по порядку выделять все объекты на диаграмме.

Выделение блока

Чтобы выделить блок, т.е. группу объектов, на диаграмме, удерживая левую кнопку мышки, обведите прямоугольник вокруг нужных объектов. Все объекты, полностью попавшие в этот прямоугольник, будут выделены. После этого вы можете производить с блоком такие операции, как вырезание, вставка, перемещение, изменение настроек шрифтов для выделенных объектов и некоторые другие.

Отмена выделения

Чтобы снять выделение, надо просто щелкнуть левой кнопкой мышки на любое свободное от объектов место на диаграмме. Также можно выбрать пункт Clear (Очистить) в меню Edit (Правка).

Горячие клавиши

Горячие клавиши предоставляют быстрое выполнение некоторых действий, избегая при этом использования меню. Некоторые горячие клавиши в Visible Analyst являются стандартными для Windows, например CTRL+P, вызывает команду Print (Печать) вывода диаграммы на печать. Все доступные горячие клавиши представлены ниже.

CTRL+A Анализ Анализ диаграммы или проекта

CTRL+C Копировать Копировать в буфер обмена

CTRL+D Определить Обращение к репозиторию

CTRL+E Соединить Соединить выделенные объекты линией

CTRL+F Найти Обращение к поисковой системе

CTRL+L Линия Переход в режим рисования линий

CTRL+N Новая диаграмма Создание новой диаграммы

CTRL+O Открыть Открытие диаграммы

CTRL+P Печать Печать текущей диаграммы

CTRL+Q Отчет Создание произвольного отчета

CTRL+R Отчет Создание стандартного отчета

CTRL+S Сохранить Сохранение текущей диаграммы

CTRL+T Текст Переход в режим добавления текста

CTRL+U Очистить Отмена выделения

CTRL+V Вставить Вставка из буфера обмена

CTRL+Y Выравнивание Выравнивание объектов

CTRL+X Вырезать Вырезать в буфер обмена

CTRL+Z Отменить Отмена предыдущего действия

DEL Удалить Удаление объекта с диаграммы

F1 Помощь Контекстно-зависимая справка

SHIFT+F1 Справка по командам меню

SHIFT+F10 Меню объекта Вызывает появление меню объекта

Панель управления

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

Панель управления содержит четыре панели инструментов.

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

С помощью пункта Control Bar (Панель Управления) меню Options (Настройки) можно настроить различный вид панели управления.

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

Окно просмотра объектов

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

Создание нового проекта

Каждый проект представляет собой одну законченную систему. Проект также может представлять собой часть очень большой системы. При расположении всей системы в одном проекте Visible Analyst обеспечивает непротиворечивость всех ее компонент.

Выберите пункт New Project из меню File. Появится диалоговое окно, показанное на рис. 2.1.
Наберите TUTOR в поле Name (Имя проекта). Имя проекта может содержать до 128 символов. Оно должно начинаться с символа и содержать буквы и цифры.
Поместите курсор в поле Description (Описание). Наберите «Учебный проект».

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

В блоке Repository (Репозиторий) вы можете отключить использование репозитория для нового проекта. Разрешите использование репозитория, проверив, что опция Disabled отключена.
Выберите Btrieve в качестве ядра системы базы данных.
В блоке Rules (Нотация) выберите Gane & Sarson. Здесь вы выбираете методологию для своего проекта.
В блоке ERD Notation (Кардинальность связи) вы выбираете нотацию для отображения кардинальности связи. Вы можете задать одно или два имени использовать на одну связь в блоке Names Per Relationship. Установите здесь значение Two.
Нажмите OK, чтобы создать новый проект.

Открывается окно для создания новой диаграммы, изображенное на рис. 2.2

Установите в поле Diagram Type значение Decomposition, чтобы создать диаграмму функциональной декомпозиции, и нажмите кнопку OK.

Диаграмма функциональной декомпозиции

В предыдущей главе было описано, как создать диаграмму функциональной декомпозиции непосредственно при создании проекта. То же самое можно сделать, используя пункт New Diagram меню File.

Перед Вами открывается новая диаграмма. На панели управления появляются соответствующие данному типу диаграммы кнопки. Для создания диаграммы, Вам потребуется кнопка Function (Функция) и кнопка Process (Процесс). Функции отображаются на диаграмме в виде прямоугольников, а процессы в виде прямоугольников со скругленными углами. Чтобы добавить процесс или функцию на диаграмму, необходимо щелкнуть по соответствующей кнопке, и тогда форма курсора мыши на диаграмме изменится, превратившись в прицел. Наведите его на нужное место на диаграмме и нажмите левую кнопку мыши. Visible Analyst запросит у Вас ввести имя создаваемого объекта.

Создайте на диаграмме функции и процессы, как показано на таблице «Функциональная декомпозиция»

При добавлении элементов на диаграмму не забывайте пользоваться горячими клавишами для выравнивания и соединения объектов. Чтобы выровнять или соединить группу объектов на диаграмме, выделите нужные объекты в блок и нажмите CTRL+Y для выравнивания или CTRL+E для соединения.

После создания диаграммы функциональной декомпозиции нажмите кнопку Save (Сохранить) на панели управления, чтобы сохранить ее. Visible Analyst предложит ввести имя диаграммы.

На диаграмму в Visible Analyst можно помещать текст. Для этого используйте кнопку Add Text (Добавить Текст) на панели управления. Нажав эту кнопку, укажите место на диаграмме, куда должен быть помещен текст. Появится специальное окно для ввода текста, наберите в нем «Диаграмма Функциональной декомпозиции» и нажмите OK. Чтобы изменить шрифт текста, перейдите в режим редактирования, используя кнопку ,и щелкните правой кнопкой мыши по тексту. Появится контекстное меню объекта, в котором следует воспользоваться пунктом Text Settings (Шрифт).

С помощью контекстного меню можно выполнять многие действия с объектами. Например, чтобы удалить объект с диаграммы, надо воспользоваться пунктом Delete (Удалить). Следующим шагом в разработке диаграммы функциональной декомпозиции является добавление описаний к функциям и процессам. Вызовите контекстное меню для процесса «Система подготовки водительских прав» и нажмите Define (Определить). Появляется окно, изображенное на рис.3.1

В поле Description (Описание), введите «Система используется для отслеживания всех процессов, касающихся выдачи водительских удостоверений» в качестве краткой характеристики процесса. Затем нажмите кнопку Save (Сохранить) и Exit (Выход). Аналогично введите описания для остальных процессов на диаграмме.

Диаграммы потоков данных. Часть 1

Чтобы создать диаграммы потоков данных можно использовать уже созданную Вами в предыдущей главе диаграмму функциональной декомпозиции. Для генерации диаграмм потоков данных используется специальная функция Spawn (Породить). Откройте диаграмму функциональной декомпозиции, используя пункт Open Diagram (Открыть Диаграмму) из меню File (Файл). Выделите функцию «Отделение водительских прав» и нажмите на ней правой кнопкой мыши. В контекстном меню выберите Spawn (Породить), чтобы породить диаграммы потоков данных. Visible Analyst запросит у Вас подтверждения на создание новых диаграмм в виде специального диалога, где Вам необходимо будет нажать кнопку Update DFDs (Обновить диаграммы потоков данных).

Теперь, если Вы сделали все правильно, в окне открытия диаграмм (вызывается командой Open Diagram из меню File) в папке Data Flow (Потоки Данных) должны быть следующие диаграммы:

1. Отделение водительских прав

2. Система подготовки водительских прав

3. Подготовить права

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

Откройте диаграмму «Отделение водительских прав». На этой диаграмме присутствует только один процесс «Система подготовки водительских прав». Эта диаграмма является диаграммой верхнего уровня. Чтобы перейти к диаграмме более низкого уровня, вызовите контекстное меню для процесса, щелкнув по нему правой кнопкой мыши, и выберете пункт Explode (Раскрыть). Вы перейдете на диаграмму «Система подготовки водительских прав», в которой аналогичным образом можно раскрыть процесс «Подготовить права».

Кроме процессов на диаграмме потоков данных могут располагаться хранилища, внешние сущности и потоки данных:

Объект	Изображение
Процесс (Process)
Хранилище (Data Store)
Внешняя сущность (External Entity)
Поток данных (Dataflow)

Перейдем теперь к детальной разработке диаграммы верхнего уровня. Откройте диаграмму «Отделение водительских прав» с помощью пункта Open Diagram (Открыть Диаграмму) из меню File (Файл). На рис. 4.1 представлен конечный вид диаграммы «Отделение водительских прав».

Как видно из рисунка, на диаграмму надо добавить новые элементы: внешние сущности, потоки данных и хранилище. Для добавления каждого из этих элементов удобно пользоваться панелью инструментов (рис 4.2)

На панели инструментов расположены специальные кнопки для добавления различных объектов. Чтобы разместить на диаграмме новый процесс, внешнюю сущность или хранилище, надо нажать соответствующую кнопку на панели инструментов и затем указать мышкой нужную позицию для вставки нового объекта в области разработки диаграммы. При этом Visible Analyst запросит имя создаваемого объекта и Вам необходимо будет указать его таким, как на рис.4.1.

Для добавления потока данных необходимо выбрать стрелку нужного вида и мышкой провести ее из одного соединяемого объекта в другой, удерживая при этом нажатой левую кнопку мышки. Первый тип стрелки – это наклонная линия (Point to Point). Второй тип используется для добавления строго горизонтальных или вертикальных стрелок. Для добавления стрелки в виде угла используйте третий тип линии (Elbow). При добавлении стрелки в виде угла, для изменения его ориентации, необходимо, во время рисования стрелки, дополнительно к левой кнопке мышки нажать и правую.

Добавьте объекты на диаграмму так, чтобы она приобрела вид как на рис. 4.2 и сохраните ее. При создании диаграммы функциональной декомпозиции Вы вводили описания для процессов. Процессы являются объектами репозитория и они едины для всех диаграмм. Вы можете проверить, что описания для процессов сохранились и доступны также и на диаграмме потоков данных. Теперь Вам надо ввести описания для остальных объектов на диаграмме потоков данных. Для этого из контекстного меню объекта выберите Define (Определить) и заполните поле Description (Описание). Например, для внешней сущности «Заявитель» можно ввести описание «Человек, желающий получить водительское удостоверение», а для сущности «Инспектор» - «Инспектор ГИБДД, уполномоченный принимать экзамены на выдачу водительских удостоверений». После того, как Вы ввели все описания, не забудьте сохранить диаграмму.

Теперь перейдем на диаграмму более низкого уровня, раскрыв процесс «Система подготовки водительских прав». Для раскрытия процесса используйте пункт контекстного меню Explode (Раскрыть). Перед Вами открывается диаграмма «Система подготовки водительских прав», но кроме процессов на ней уже находятся потоки данных. Таким образом, при раскрытии процесса, на диаграмму нижнего уровня переносятся все потоки данных, входящие или выходящие из этого процесса.

Приведите диаграмму «Система подготовки водительских прав» к виду, показанному на рис. 4.3

Как видно из рис. 4.3, Вам необходимо присоединить все потоки данных к процессам и кроме этого добавить несколько новых потоков данных. После завершения редактирования диаграмму сохраните ее.

Аналогичным образом раскройте и отредактируйте диаграмму «Подготовить права». Ее конечный вид смотрите на рис. 4.4

Особенность данной диаграммы в том, что необходимо добавить хранилище «База данных водителей», которое уже есть в репозитории. Сделать это можно, просто перетащив его мышкой из окна просмотра объектов (из папки Data Store) в область разработки диаграммы. Не забудьте сохранить результаты своей работы.

После того, как Вы закончили редактировать диаграмму «База данных водителей», Вы можете проверить правильность всех своих диаграмм с помощью пункта Analyze (Анализ) из меню Diagram (Диаграмма). При выборе этого пункта открывается окно анализа, в котором выберите опцию Entire Project (Весь проект) и нажмите кнопку ОК. Если Вы делали все верно, то выдается сообщение «Project Correct». В противном случае, Visible Analyst выдаст список ошибок, которые необходимо исправить, чтобы проект удовлетворял требованиям выбранной методологии.

В дальнейшем, мы еще вернемся к диаграммам потоков данных, чтобы указать непосредственно сами данные, передающиеся из процесса в процесс. Но сначала познакомимся с моделированием данных с помощью диаграммам типа «Сущность – Связь».

Диаграммы «Сущность – Связь»

Чтобы научиться создавать диаграммы «Сущность – Связь» нам необходимо сначала ввести элементы данных в репозиторий Visible Analyst. Затем эти данные понадобятся нам для описания сущностей на диаграмме.

Чтобы войти в репозиторий системы, выберите пункт Define (Определить) из меню Repository (Репозиторий) или просто нажмите комбинацию клавиш CTRL+D. Перед Вами появится окно репозитория, показанное на рис. 5.1

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

Label (Имя)	Description (Описание)	Type (Тип)	Length (Длина)	Entry Type (Тип элемента)
Drv_address	Адрес водителя	Char	30	Data Element
Dep_address	Адрес отделения ГИБДД	Char	30	Data Element
Drv_birth	Дата рождения водителя	Date	8	Data Element
Exm_date	Дата экзамена	Date	6	Data Element
Drv_name	Имя водителя	Char	30	Data Element
Eval_name	Имя инспектора ГИБДД	Char	30	Data Element
Appl_num	Номер заявителя	Integer	5	Data Element
Eval_num	Номер инспектора ГИБДД	Integer	4	Data Element
Lic_num	Номер водительской лицензии	Char	11	Data Element
Med_num	Номер мед. страховки	Char	11	Data Element
Dep_num	Номер отделения ГИБДД	Integer	3	Data Element
Result	Результат экзамена	Binary	1	Data Element
Fee	Cумма взноса	Integer	4	Data Element

Поля Label, Description и Entry Type вводятся на вкладке Description, а поля Type и Length на вкладке Physical Characteristics. Не забывайте сохранять введенные вами данные с помощью кнопки Save.

Кроме Элементов данных (Data Element), в Visible Analyst есть понятие Структуры данных (Data Structure), которая может включать в себя несколько элементов. Нам потребуется добавить в репозиторий структуру данных «Drv_info» - «Информация о водителе», которая будет включать в себя такие элементы, как «Drv_name», «Drv_birth», «Drv_address» и «Med_num». Чтобы добавить структуру данных, войдите в репозиторий и в поле Entry Type (Тип элемента) введите Data Structure. Затем введите имя новой структуры и нажмите кнопку Save. Для добавления элемента данных в структуру проделайте следующие шаги:

В окне просмотра объектов вызовите контекстное меню для папки Data Structure и выберите пункт Expand (Развернуть). Затем в развернувшемся списке найдите нужную Вам структуру данных и из ее контекстного меню выполните команду Define (Определить)
Нажмите кнопку , и перед Вами появится окно для ввода атрибутов структуры, как называют входящие в ее состав элементы данных.
Перейдите в поле Global Name (Глобальное имя) и нажмите кнопку Search (Поиск)
Вы увидите перед собой список всех элементов данных репозитория. Выполните двойной клик мышкой по элементу, который Вы хотите добавить
Нажмите OK
Нажмите кнопку Save.

Добавьте в структуру «Drv_info» указанные выше элементы данных.

Итак, мы заполнили репозиторий необходимыми данными и теперь можем перейти непосредственно к созданию диаграммы «Сущность - Связь». Для создания новой диаграммы можно использовать пункт New Diagram (Новая диаграмма) из меню File (Файл) или комбинацию клавиш CTRL+N. В окне создания новой диаграммы укажите в качестве Diagram Type (Тип диаграммы) - Entity Relationship («Сущность – Связь»). Откроется новая диаграмма. При ее сохранении, с помощью кнопки Save (Сохранить) на панели управления, запрашивается имя для этой диаграммы. Введите «Модель данных» в качестве имени.

В нижеприведенной таблице изображены основные объекты, помещаемые на диаграммы типа «Сущность - Связь»:

Объект	Изображение
Сущность (Entity)
Ассоциативная сущность (Associative Entity)
Атрибутивная сущность (Attributive Entity)
Связь типа 1 : М (Relationship)

Кардинальность связи изображается в Visible Analyst с помощью использования различных терминаторов у изображающих связи линий. В нашем проекте используется нотация Crowsfoot («Куриные лапки») и этим объясняется текущий вид линий связи. В нижеприведенной таблице приведены основные типы терминаторов для данной нотации:

Значение	Изображение
1 и только 1
1 или 0
1 или много
0 или много

Добавление всех объектов на диаграмму типа «Сущность – Связь» аналогична добавлению объектов на диаграммы потоков данных, поэтому приведем сразу конечный вид диаграммы на рис. 5.2, отметив что, в отличие от потоков данных, каждая связь имеет две подписи. Каждая из подписей характеризует суть связи в своем направлении, являясь по сути описанием взаимоотношения между двумя сущностями.

Обратите внимание на то, что сущность «Экзамен» является ассоциативной.

Следующим шагом в разработке диаграммы «Сущность - Связь» является описание сущностей и связей с точки зрения данных. Каждая сущность должна иметь некоторые атрибуты. Например, «Отделение ГИБДД» имеет номер отделения и адрес. Выделите сущность «Отделение ГИБДД» на диаграмме и вызовите его контекстное меню. Выберите пункт Define (Определить). Открывается окно репозитория. Нажмите кнопку , и перед Вами появится окно для ввода атрибутов сущности, показанное на рис. 5.3

Установите курсор в поле Global Name (Глобальное имя) и нажмите кнопку Search (Поиск). В появившемся окне выполните двойной клик по элементу данных Dep_num. Нажмите OK и затем Save (Сохранить). Таким образом, Вы добавили атрибут «Номер отделения» к сущности «Отделение ГИБДД». Аналогично добавьте атрибуты для других сущностей, ориентируясь по нижеприведенной таблице.

Сущность	Атрибуты
Отделение ГИБДД	Dep_num Dep_address
Заявитель	Appl_num Dep_num Drv_info
Водительское удостоверение	Lic_num Dep_num Drv_info
Инспектор	Dep_num Eval_num Eval_name
Экзамен	Eval_num Dep_num Appl_num Exm_date Result

Прослеживается явное сходство между сущностями и таблицами баз данных. Атрибуты сущности можно интерпретировать как поля таблицы. Также как и таблицы, сущности могут иметь Первичные ключи (Primary Key) и Внешние ключи (Foreign Key). На рис. 5.4 изображена схема данных для нашего примера

В качестве примера, рассмотрим, как добавить первичный и внешний ключи для сущности «Инспектор». Из рис. 5.4 видно, что у сущности «Инспектор» атрибут Eval_num является ключевым, а атрибут Dep_num – внешним ключом, так как по нему идет связь с сущностью «Отделение ГИБДД».

Чтобы сделать атрибут Eval_num ключевым, выполните следующую последовательность действий:

Выделите сущность «Инспектор» на диаграмме и вызовите его контекстное меню. Выберите пункт Define (Определить). Открывается окно репозитория.
Нажмите кнопку и в специальном окне выделите атрибут Eval_num. Оно автоматически переносится в список ключевых полей. Нажмите OK и затем Save (Сохранить).

Чтобы сделать атрибут Dep_num внешним ключом, выполните следующую последовательность действий:

Выделите сущность «Инспектор» на диаграмме и вызовите его контекстное меню. Выберите пункт Define (Определить). Открывается окно репозитория. Перейдите на вкладку Foreign Keys (Внешние ключи).
В поле Relationship (Связь) удостоверьтесь, что выбрана связь с сущностью «Отделение ГИБДД»
В поле Available Columns (Доступные поля) выполните клик мышкой по атрибуту Dep_num.
Выполните клик мышкой на поле, расположенное слева от поля Available Columns. Теперь атрибут Dep_num является внешним ключом. Нажмите кнопку Save (Сохранить).

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

На этом разработку диаграммы «Сущность - Связь» для нашей системы можно считать законченной. Правильность созданной диаграммы можно проверить с помощью пункта Analyze (Анализ) из меню Diagram (Диаграмма). При выборе этого пункта открывается окно анализа в котором выберите опцию Current Diagram (Текущая диаграмма). Поочередно выполните проверку с параметром Syntax Check (Синтаксическая проверка) и Normalization (Нормализация). Если Вы делали все верно, то выдается сообщение «Project Correct». В противном случае, Visible Analyst выдаст список ошибок, которые необходимо исправить, чтобы проект удовлетворял требованиям выбранной методологии. Ошибки в ключевых полях можно обнаружить, используя пункт Key Analysis (Анализ ключей) из меню Repository (Репозиторий). Если ошибок в ключевых полях не найдено, то Visible Analyst выдает сообщение «No Errors Fount During Key Analysis» («В процессе анализа ключей ошибок не найдено»). В противном случае выдается список ошибок, которые Вам необходимо устранить.

Диаграммы потоков данных. Часть 2

Теперь, когда в репозитории для нашего проекта имеются элементы данных, пришло время описать объекты диаграмм потоков данных. Для этого, также как и при описании сущностей модели данных, используют команду Define (Определить) из контекстного меню объекта. Сам процесс добавления атрибутов для потоков данных и хранилищ полностью аналогичен добавлению атрибутов сущностей (см. гл. Диаграммы «Сущность – Связь»).

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

Объект	Атрибуты объекта
Потоки данных
Водительское удостоверение	Lic_num, Drv_info Dep_num Dep_address
Запись о выдаче водительского удостоверения	Lic_num Drv_info
Зарегистрированное заявление	Appl_num Drv_info Dep_num Dep_address
Заявление	Drv_info Dep_num Dep_address
Неуспешный результат	Result Drv_info
Новая дата экзамена	Exm_date
Оплата	Fee
Подтвержденное право управления ТС	Lic_num Drv_info Result Dep_num Drv_address
Требования к навыкам вождения и знаниям ПДД	Eval_name Eval_num
Успешный результат	Result Drv_info
Фотография	Lic_num, Drv_info Result Dep_num Dep_address Drv_address
Экзаменационная карта	Eval_name Eval_num Drv_name Result
Хранилища
База данных водителей	Lic_num Drv_info

После ввода всех атрибутов можно проверить сбалансированность диаграмм потоков данных и диаграммы «Сущность – Связь». Для этого используйте пункт Model Balancing (Балансировка модели) из меню Repository (Репозиторий). Если Вы ввели все данные правильно, то Visible Analyst выдаст сообщение, что в процессе анализа ошибок не найдено. В противном случае Вам необходимо будет проверить данные репозитория, найти ошибку и исправить ее.

Структурное проектирование (Схемы Констатайна)

Для создания новой структурной диаграммы можно использовать пункт New Diagram (Новая диаграмма) из меню File (Файл) или комбинацию клавиш CTRL+N. В окне создания новой диаграммы укажите в качестве Diagram Type (Тип диаграммы) - Structure Chart (Структурная диаграмма). Откроется новая диаграмма. При ее сохранении, с помощью кнопки Save (Сохранить) на панели управления, запрашивается имя для этой диаграммы. Введите «Схема Констатайна» в качестве имени.

В нижеприведенной таблице перечислены основные объекты структурных диаграмм:

Объект	Изображение
Модуль (Module)
Библиотечный модуль (Library Module)
Макрос (Macro)
Модуль-данные (Data Only Module)
Линия вызова (Invocation Line)
Cвязь по управлению (Control Connection)
Связь по данным (Data Connection)
Параметр-данные (Data Couple)
Параметр-управление (Control Couple)
Линия цикла (Loop Line)
Условная линия вызова (Conditional Invocation)

На рис. 6.1 приведена структурная диаграмма для нашего проекта. Используя рис. 6.1 добавьте необходимые объекты на свои диаграммы. Учтите, что для добавления параметров управления или параметров данных, необходимо сначала выбрать их, нажав соответствующую кнопку на панели управления, а затем выполнить клик по концу линии вызова, по которой передается параметр.

После завершения работы со структурной диаграммой сохраните ее. На этом наш краткий курс по использованию Visible Analyst заканчивается.

Литература

Г. Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-еизд./Пер. с англ.-М.:»Издательство Бином», Спб.:»Невский диалект», 1999 г.-560с.
Липаев В.В., Позин Б.А., Штрик А.А. Технология сборочного программирования, Под. Ред. В.В. Липаева,-М.:1992-272с.
Калянов Г.Н. Структурный системный анализ. М.: «Лори»
"CASE-технология". Материалы к семинару -М.: Общество "Знание" РФ, 1994 г.
"Рабочие станции". Материалы семинара -М.: Общество "Знание" РФ, 1992 г.
"CASE-технология". Материалы семинара -М.: Общество "Знание" РФ, 1992 г
"Учебные материалы для практического освоения системы ProKit*Workbench". Инженерные методы и средства создания информационных систем.
Боэм Б. Инженерное проектирование программного обеспечения. М.: «Эйткес»
Гейн К., Сарсон Т. Системный и структурный анализ: средства и методы. М.: «Лори»
Калянов Г.Н. Современные CASE-технологии. М.: ИПУ,1992
CASE. Аналитик для IBM PC. Руководство аналитика. М.: «Эйткес»
Позин Б.А. CASE - автоматизация проектирования программных средств. Материалы к семинару - М.: Общество "Знание" РФ, 1994 г
Штрик А.А. Состояние, характеристики и перспективы развития инструментальных CASE-средств автоматизации создания прикладных программ для информационных технологий. Материалы к семинару - М.: Общество "Знание" РФ, 1994 г
PRO-IV Administrators Manual. McDonell Information System Limited, 1993 г.
PRO-IV Developers Manual. Volumes 1&2. McDonell Information System Limited, 1993 г.