Меню

Что такое автоматизированные инструментальные средства

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

Технология создания крупных информационных систем (далее — ИС) предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно:

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

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

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

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

На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям. Ниже будет рассмотрена вполне конкретная технология разработки, основывающаяся на решениях фирм Logic Works и Rational Software, которая является одной из лучших на сегодняшний день по критерию стоимость/эффективность.

Рис.1. Общая схема взаимодействия инструментальных средств Logic Works
и Rational Software

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE — средство верхнего уровня — BPwin, поддерживающий методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей — того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция — система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес — процессе. Такая технология создания модели позволяет построить модель адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент “перекресток”, что позволяет описать логику взаимодействия компонентов системы.

На основе модели BPwin’а можно построить модель данных. Для построения модели данных Logic Works предлагает мощный и удобный инструмент — ERwin. Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Logic Works предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели — механизм двунаправленной связи BPwin — ERwin (1, рис.1). ERwin имеет два уровня представления модели — логический и физический. На логическом уровне данные представляются безотносительно конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных — это, по — существу, отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД (2, рис.1). Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того, либо другого. ERwin интегрируется с популярными средствами разработки клиентской части — PowerBuilder, SQLWindows, Visual Basic, Delphi (3, рис.1), что позволяет автоматически генерировать код приложения, который готов к компиляции и выполнению (4, рис.1).

Создание современных информационных систем, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Logic Works разработала систему Model Mart — хранилище моделей, к которому открыт доступ для участников проекта создания информационной системы (5, рис.1). Model Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных информационных систем, а именно:

Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля — Intelligent Conflict Resolution (ICR). В дополнение к стандартным средствам организации совместной работы Model Mart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.

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

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

Архитектура Model Mart. Model Mart реализована на архитектуре клиент — сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server и Oracle. Клиентскими приложениями являются ERwin 3.x и BPwin 2.0x. В следующих версиях Model Mart предполагается открыть доступ к хранилищу моделей через API, что позволит постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа.

Как было указано выше (см. пункт C), при разработке крупных проектов критичным становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения (клиентской части) CASE — средствами на основе модели предметной области. Хотя ERwin решает эту задачу, код генерируется на основе модели IDEF1X, то есть фактически на основе реляционной модели данных, которая непосредственно не содержит информацию о бизнес — процессах. Как следствие этого, сгенерированный код не может полностью обеспечить функциональность приложения со сложной бизнес-логикой. Существует альтернативная технология кодогенерации, которая лишена этого недостатка — объектно-ориентированное проектирование, реализованное в Rational Rose (Rational Software). Rational Rose – позволяющее строить объектные модели в различных нотациях (OMT, UML, Буч) и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, Power Builder, Java, Ada, Smalltalk и др. Поскольку генерация кода реализована на основе знаний предметной области, а не на основе реляционной структуры данных, полученный код более полно отражает бизнес-логику. Rational Rose поддерживает не только прямую генерацию кода, но и обратное проектирование, то есть создание объектной модели по исходному коду приложения (6, рис.1).

Rational Rose предназначен для генерации клиентской части приложения. Для генерации схемы БД объектную модель следует конвертировать в модель данных IDEF1X. Модуль ERwin Translation Wizard (Logic Works) позволяет перегружать объектную модель Rational Rose в модель данных ERwin (и обратно) и, с помощью ERwin, сгенерировать схему БД (7, рис.1). Таким образом, технологическая цепочка Rational Rose — ERwin Translation Wizard — ERwin позволяет реализовывать крупные проекты в технологии клиент — сервер.

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

Обычно сначала строится модель существующей организации работы -“AS-IS” (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Найденные в модели “AS-IS” недостатки можно исправить при создании модели “TO-BE” (как должно быть) — модели новой организации бизнес-процессов.

Наиболее удобным языком моделирования бизнес- процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (Ранее назывался SADT — Structured Analysis and Design Technique).

Подробно методология SADT излагается в книге Дэвида А.Марка и Клемента МакГоуэна“ Методология структурного анализа и проектирования SADT”, издательство Метатехнология, 1993.

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

Читайте также:  Лучшее средство для обезвоженной кожи лица

Основу методологии IDEF0 составляет графический язык описания бизнес- процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, называется контекстной диаграммой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес — процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Таким образом достигается соответствие модели реальным бизнес — процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели. Работы (Activity), которые означают некие поименованные процессы, функции или задачи, изображаются в виде прямоугольников. Именем работы должен быть глагол или глагольная форма (например “Изготовление детали”, “Прием заказа” и т.д.). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, “Заготовка”, “Изделие”, “Заказ”). В IDEF0 различают пять типов стрелок:

Вход (Input) — материал или информация, которая используется или преобразовывается работой.

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.

Выход (Output) — материал или информация, которая производится работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

Механизм (Mechanism)- ресурсы, которые выполняют работу, например, персонал предприятия станки, механизмы и т.д.

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

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

При создании новой модели (меню File / New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует кликнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Definition Editor (вызывается из меню Edit/Model Definition).

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

перенесите курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

щелкните один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

вернитесь в палитру инструментов и выберите опцию редактирования стрелки ;

дважды щелкните на линии стрелки , во всплывающем меню выберите Name Editor

и добавьте имя стрелки.

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Словарь стрелок можно распечатать в виде отчета (меню Report / Arrow Report. ) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.

Рис.2. Контекстная диаграмма

Рис.3. Словарь стрелок

Рис.4. Диаграмма декомпозиции

После создания контекстной диаграммы можно приступить к декомпозиции. Для этого нужно кликнуть по кнопке перехода на нижний уровень . Появляется диалог Activity Box Count, в котором необходимо указать количество работ на диаграмме декомпозиции (в дальнейшем можно будет добавить недостающие работы или удалить лишние) и нотацию диаграммы. BPwin позволяет создавать смешанные модели — в рамках одной модели могут сосуществовать и быть связанными модели IDEF0, DFD и IDEF3. Такой подход позволяет описать интересующие нас аспекты каждой подсистемы. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3-х до 6-ти блоков на одной диаграмме. Остановимся пока на нотации IDEF0 и кликнем на OK. Появляется диаграмма декомпозиции. Работы расположены в так называемом порядке доминирования (по степени важности или в порядке очередности выполнения), начиная с левого верхнего угла и кончая нижним правым углом, что значительно облегчает в дальнейшем чтение диаграммы. Стрелки, которые были внесены на контекстной диаграмме, показываются и на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются, как синтаксическая ошибка. Для связывания стрелки необходимо перейти в режим редактирования стрелок, кликнуть по стрелке и кликнуть по соответствующему сегменту работы. Для связи работ между собой используются внутренние стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.

Для рисования внутренней стрелки необходимо в режиме рисования стрелок кликнуть по сегменту (например выхода) одной работы и затем по сегменту (например входа) другой. В IDEF0 различают пять типов связей работ:

прямая связь по входу, когда стрелка выхода вышестоящей (далее просто выход) работы направляется на вход нижестоящей (например, на рисунке стрелка “Детали” связывает работы “Изготовление деталей” и “Сборка деталей”);

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

обратная связь по входу, когда выход нижестоящей работы направляется на вход вышестоящей (стрелка “Брак”);

обратная связь по управлению, когда выход нижестоящей работы направляется на управление вышестоящей (стрелка “Рекомендации”);

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

Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их “перетаскивания” наверх нужно сначала выбрать кнопку на палитре инструментов и кликнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor.

Рис.5. Диалог Border Arrow Editor

Если кликнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel, стрелка будет затуннелирована и не попадет на другую диаграмму. Туннелирование может быть применено для изображения малозначимых стрелок.

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

Список синтаксических ошибок модели можно получить сгенерировав отчет об ошибках (Report / Model Consistency Report. ).

Дополнение модели процессов диаграммами DFD и Workflow (IDEF3)

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

Рис.6. Диаграмма в нотации DFD

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывают функции обработки информации (работы), документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации (внешние ссылки, external references) и таблицы для хранения документов (хранилище данных, data store). В отличие от IDEF0 для стрелок нет понятия вход, выход, управление или механизм и неважно, в какую грань работы входит или из какой грани выходят стрелки. В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона. Для того, чтобы дополнить модель IDEF0 диаграммой DFD нужно в процессе декомпозиции в диалоге Activity Box Count кликнуть по радиокнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

— добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели ;

— добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде чем использовать в работах.

— ссылка на другую страницу. В отличие от IDEF0 инструмент off- page reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако, для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес — процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.

Прямоугольники на диаграмме Workflow называются единицами работы (Unit of Work, UOW) и обозначают событие, процесс, решение или работу. Для редактирования диаграммы используются примерно те же диалоги, что и для IDEF0. В палитре инструментов на диаграмме Workflow имеются кнопки для новых элементов:

— добавить в диаграмму объект ссылки (Referent). Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных (о том, как использовать модель данных в BPwin будет рассказано в следующем разделе). Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные. Синхронные и асинхронные, используемые в диаграммах переходов состояний объектов не поддерживаются.

— добавить в диаграмму перекресток (Junction). Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму в диалоге Junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.

Читайте также:  Как собрать свое средства передвижения

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс “J”. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD, в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Здесь различают три типа стрелок, стиль которых устанавливается через меню Edit / Arrow Style:

Старшая (Precedence) — сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз.

Тип перекрестка

Обозначение

Наименование

Смысл в случае слияния стрелок (Fan-in Junction)

Смысл в случае разветвления стрелок (Fan-out Junction)

Asynchronous AND

Все предшествующие процессы должны быть завершены

Все следующие процессы должны быть запущены

Synchronous AND

Все предшествующие процессы завершены одновременно

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

Asynchronous OR

Один или несколько предшествующих процессов должны быть завершены

Один или несколько следующих процессов должны быть запущены

Synchronous OR

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

Один или несколько следующих процессов запускаются одновременно

XOR (Exclusive OR)

Только один предшествующий процесс завершен

Только один следующий процесс

запускается

Отношения (Relational Link) — пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) и между единицами работ и объектами ссылок.

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

Рис.7. Диаграмма в нотации IDEF3

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть в окне Model Explorer Работы в нотации IDEF0 изображаются зеленым цветом, IDEF3 — желтым, DFD- синим.

Рис.8. Смешанная модель в окне Model Explorer

Синтаксический анализ модели BPwin’а позволяет легко обнаружить “бесполезные” (не имеющие выхода), “неуправляемые” (не имеющие управления) и “простаивающие” работы. Более тонкий анализ позволяет выявить дублирующие, избыточные или неэффективные работы. Модель дает целостное представление о работе системы в целом и позволяет понять взаимосвязи всех составляющих системы. При этом часто выясняется, что обработка информации и использование ресурсов неэффективны, важная информация не доходит до соответствующего рабочего места и т.д. Признаком неэффективной организации работ является, например, отсутствие обратных связей по входу и управлению для многих, критически важных работ.

Невозможно построить эффективную ИС при неэффективной общей организации работы. Поэтому результатом анализа и критической оценки модели AS-IS должно быть перенаправление информационных потоков и усовершенствование бизнес- процессов в новой модели TO-BE, которая должна использоваться для реорганизации деятельности предприятия. Такой результат построения модели сам по себе самодостаточен, то есть если удается более рационально организовать бизнес-процессы на предприятии — это уже результат, оправдывающей капиталовложения. Однако при создании ИС модель процессов — это только первый шаг, за которым обычно следует построение модели данных.

Соответствие модели данных и модели процессов

Стрелки в модели процессов означают некоторую информацию, использующуюся в моделируемой системе. ERWin поддерживает два уровня представления модели данных – логический и физический. Логический уровень не зависит от конкретной реализации БД и позволяет наглядно представить данные для обсуждения с экспертами предметной области. Физический уровень является отображением системного каталога БД и зависит от конкретной реализации БД. На логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы). Сущности состоят из совокупности отдельных записей — экземпляров сущностей (соответствуют записям в таблице). К модели данных предъявляются определенные требования (т.н. нормализация данных), которые призваны обеспечить компактность и непротиворечивость хранения данных. Основная идея нормализации данных – каждый факт должен хранится в одном месте. Это приводит к тому, что информация, которая моделируется в виде одной стрелки в модели процессов может содержаться в нескольких сущностях и атрибутах в модели данных. Кроме того, на диаграмме модели процессов могут присутствовать различные стрелки, изображающие одни и те же данные, но на разных этапах обработки (например, необработанные детали — обработанные детали — собранное изделие). Информация о таких стрелках находится в одних и тех же сущностях. Следовательно, одной и той же стрелке в модели процессов могут соответствовать несколько сущностей в модели данных и наоборот, одной сущности может соответствовать несколько стрелок.

Рис.9. Преобразование стрелки в сущность

Стрелке в модели процессов может соответствовать отдельная сущность в модели данных. Так, стрелке “Части” на рис. 9 соответствует сущность “Часть”, стрелке “Конечные продукты” – сущность “Продукт”.

Информация о стрелке может содержаться только в нескольких атрибутах сущности. Разным атрибутам одной и той же сущности могут соответствовать разные стрелки. На рис. 10 стрелка “Новая часть” соответствует атрибутам “Номер части” и “Название части”, стрелка “Наличное количество” – атрибутам “Количество”.

Рис.10. Преобразование стрелки в атрибут

Работы в модели процессов могут создавать или изменять данные, которые соответствуют входящим или выходящим стрелкам. Они могут воздействовать как целиком на сущности (создавая или модифицируя экземпляры сущности, рис. 11), так и на отдельные атрибуты сущности (рис. 12).

Рис.11. Воздействие работы на сущность

Рис.12. Воздействие работы на атрибут

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

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

ERwin имеет развитый инструмент для облегчения проектирования модели данных. Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен. В дальнейшем будет описан интерфейс версии 3.5.

Кнопки панели инструментов описаны в табл. 2.

Кнопки панели инструментов

Создание, открытие, сохранение и печать модели.

Вызов диалога Report Browser для генерации отчетов.

Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов и уровень определений.

Изменение масштаба просмотра модели.

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

Вызов дополнительной панели инструментов для работы с репозиторием Model Mart. (Работа с Model Mart будет рассмотрена в следующем разделе).

Переключение между областями модели – Subject Area.

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). В примерах будет использоваться нотация IDEF1X.

Для внесения сущности в модель необходимо (убедившись предварительно, что Вы находитесь на уровне логической модели – переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) кликнуть по кнопке сущности на панели инструментов (ERwin Toolbox) , затем кликнуть по тому месту на диаграмме, где Вы хотите расположить новую сущность. Кликнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor… можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.

Рис.13. Диалог Entity Editor

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note2, Note3, UDP (User Defined Properties — Свойства, Определенные Пользователем) служат для внесения дополнительных комментариев и определений сущности. В закладке Icon каждой сущности можно поставить в соответствие изображение (файл bmp), которое будет отображаться в режиме просмотра модели на уровне иконок (см. ниже).

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

Рис.14. Диалог Attribute Editor

Кликнув по кнопке New…, в появившемся диалоге New Attribute следует указать имя атрибута, имя соответствующей ему колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели [1]. Для атрибутов первичного ключа в закладке Key Group диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key. При определении первичного ключа может быть рассмотрено несколько наборов атрибутов. Такие наборы называются потенциальными ключами. Например, если рассматривается сущность “Сотрудник”, такими наборами могут быть:

  • Имя, Фамилия, Отчество, Дата рождения;
  • Номер паспорта;
  • Табельный номер;
  • Отдел.

К первичным ключам предъявляются определенные требования. Первичный ключ должен однозначно идентифицировать экземпляр сущности (этому требованию не удовлетворяет четвертый ключ, поскольку он может идентифицировать группу сотрудников, работающих в определенном отделе, но не каждого сотрудника). Первичный ключ должен быть компактен, то есть удаление любого атрибута из состава первичного ключа должно приводить к потере уникальности экземпляра сущности (если удалить Дату рождения из первого ключа, то невозможно будет идентифицировать полных тезок). Каждый атрибут из состава первичного ключа не должен принимать NULL – значений (например, если принять в качестве первичного ключа номер паспорта, необходимо быть уверенным, что все сотрудники имеют паспорта). Каждый атрибут первичного ключа не должен менять свое значение в течение всего времени существования экземпляра сущности (сотрудник может сменить фамилию и паспорт, поэтому первый и второй потенциальные ключи не могут стать первичными). Потенциальные ключи, не ставшие первичными, называются альтернативными. Атрибуты, или наборы атрибутов, использующиеся для доступа к группе экземпляров сущности, называются инверсионными ключами. Для описания альтернативных и инверсионных ключей необходимо кликнуть по кнопке … (диалог Attribute Editor, закладка Key Group) и в появившемся диалоге закладка Key Group Editor создать новую ключевую группу (либо инверсионную, либо альтернативную) и указать, какие атрибуты входят в ту или иную группу.

Рис. 15. Диалог Key Group Editor

ERwin имеет несколько уровней отображения диаграммы. Переключиться между ними можно кликнув по любому месту диаграммы, не занятому объектами модели и выбрав в появившемся меню пункт Display Level. В табл. 3 показаны уровни отображения модели.

На уровне атрибутов атрибуты альтернативного ключа помечаются номером (AKm.n), где m – номер ключа, n – номер атрибута в ключе. Инверсионные ключи помечаются номером (IEm.n). В дальнейшем при генерации БД на атрибутах альтернативных ключей могут быть сгенерированы уникальные индексы, на атрибутах инверсионного ключа – неуникальные. Имена индексов задаются в диалоге New Key Group (рис. 15). Атрибуты первичного ключа отображаются выше горизонтальной линии – прочие атрибуты – ниже.

К модели данных предъявляются определенные требования, называемые нормальными формами. Процесс приведения к нормальным формам называется нормализацией. Так, первая нормальная форма требует, чтобы все атрибуты были атомарными (не должно быть атрибута “Адрес” – должны быть атрибуты “Индекс”, “Страна”, “Область”, “Город”, “Улица”, “Дом”, “Квартира”). Вторая нормальная форма требует, чтобы каждый неключевой атрибут зависел от всего первичного ключа, не должно быть зависимости от части ключа. (здесь не ставится целью описание приведения к нормальным формам. Подробно вопросы нормализации освещены, например, в [2]). Для приведения ко второй нормальной форме необходимо создать новую сущность, перенести в нее атрибуты, зависящие от части ключа, сделать часть ключа первичным ключом новой сущности и установить идентифицирующую связь (см. ниже) от новой сущности к старой. Например, в сущности “Служащий” (слева на рис. 16 ) атрибут “Руководитель” отдела зависит от “Наименования отдела”. Справа изображены сущности, приведенные ко второй нормальной форме. Для установки связи между сущностями нужно воспользоваться кнопками в палитре инструментов.

Рис. 16. Иллюстрация второй нормальной формы

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

Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Зависимая сущность изображается прямоугольником со скругленными углами (сущность “Служащий”, справа на рис. 16). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, то есть в структуре на рис.16 информация о служащем не может быть внесена и не имеет смысла без информации об отделе, в котором он работает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности переносятся в состав первичного ключа дочерней сущности (миграция атрибутов). В дочерней сущности они помечаются как внешний ключ — (FK). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности.

Для редактирования свойств связи следует кликнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor. В появившемся диалоге можно задать:

Мощность (cardinality) связи — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Verb Phrase – фраза, характеризующая отношение между родительской и дочерней сущностями.

Тип связи (идентифицирующая / не идентифицирующая).

Правила ссылочной целостности (будут сгенерированы при генерации схемы БД).

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

Источник



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

I. Стратегический уровень ориентирован на руководителей высшего ранга. Основными целями стратегического уровня управления являются:

· определение системы приоритетов развития организации;

· оценка перспективных направлений развития организации;

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

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

· обеспечение устойчивого функционирования организации в целом;

· создание потенциала для развития организации;

· создание и корректировка базовых планов работ и графиков реализации заказов на основе накопленного в процессе развития организации потенциала.

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

· получение прибыли за счет реализации запланированных заранее мероприятий с использованием накопленного потенциала;

· регистрацию, накопление и анализ отклонений хода производства от запланированного;

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

10. Каковы место и значение информационной технологии и информационной системы?

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

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

1. Информационное обеспечение(ИО) — представляет собой совокупность проектных решений по объемам, размещению, форма организации информации, циркулирующей в ИС.

2. Лингвистическое обеспечение (ЛО) — объединяет совокупность языковых средств для формализации естественного языка, построения и сочетания информационных единиц в ходе общения пользователей со средствами вычислительной техники.

3. Техническое обеспечение(ТО) — представляет собой комплекс технических средств (технические средства сбора, регистрации, передачи, обработки, отображения, тиражирования информации, оргтехника и др.), обеспечивающих работу ИТ.

4. Программное обеспечение(ПО) — включает совокупность программ, реализующих функции и задачи ИС и обеспечивающих устойчивую работу комплексов технических средств.

5. Математическое обеспечение(МО) — совокупность математических методов, моделей и алгоритмов обработки информации, используемых при решении функциональных задач и в процессе автоматизации проектировочных работ.

6. Организационное обеспечение(ОО) — представляет собой комплекс документов, составленный в процессе проектирования ИС, утвержденный и положенный в основу эксплуатации.

7. Правовое обеспечение(ПрО) — представляет собой совокупность правовых норм, регламентирующих правоотношения при создании и внедрении ИС и ИТ.

8. Эргономическое обеспечение(ЭО) — как совокупность методов и средств, используемых на разных этапах разработки и функционирования ИС и ИТ, предназначено для создания оптимальных условий высококачественной, высокоэффективной и безошибочной деятельности человека в ИТ, для ее быстрейшего освоения.

Дата добавления: 2015-01-30 ; просмотров: 66 | Нарушение авторских прав

Источник

инструментальное средство

3.17 инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.

Словарь-справочник терминов нормативно-технической документации . academic.ru . 2015 .

Смотреть что такое «инструментальное средство» в других словарях:

инструментальное средство интерфейса системного управления — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN system management interface toolSMIT … Справочник технического переводчика

инструментальное средство оператора — [Интент] Тематики информационные технологии в целом EN user interface tool … Справочник технического переводчика

Switch-технология — технология разработки систем логического управления на базе конечных автоматов, охватывающая процесс спецификации, проектирования, реализации, отладки, верификации, документирования и сопровождения. Предложена А. А. Шалыто в 1991 году [1].… … Википедия

ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию — Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

Инсталляция (ПО) — У этого термина существуют и другие значения, см. инсталляция. Содержание 1 Некоторые жаргонные выражения … Википедия

встроенный инструмент — встроенное инструментальное средство — [Интент] Тематики автоматизированные системы Синонимы встроенное инструментальное средство EN embedded tool … Справочник технического переводчика

инструмент создания отчетов — инструментальное средство создания отчетов [Интент] Тематики автоматизированные системы Синонимы инструментальное средство создания отчетов EN report design toolreporting tool … Справочник технического переводчика

инструмент создания отчётов уровня предприятия — инструментальное средство создания отчетов уровня предприятия — [Интент] Тематики автоматизированные системы Синонимы инструментальное средство создания отчетов уровня предприятия EN enterprise wide reporting tool … Справочник технического переводчика

Together — Изображение интерфейса и реализующего его класса в Together «Together» инструментальное средство фирмы «UML диаграмм. Ссылки Borland «Together» … Википедия

Шалыто, Анатолий Абрамович — Анатолий Абрамович Шалыто Дата рождения: 28 мая 1948(1948 05 28) (64 года) Место рождения: Ленинград Страна … Википедия

Источник

инструментальные средства

Большой англо-русский и русско-английский словарь . 2001 .

Смотреть что такое «инструментальные средства» в других словарях:

инструментальные средства — Комплекс средств, предназначенный для разработки и отладки программного обеспечения. В него обычно входят трансляторы, интерпретаторы, различного рода отладчики и другие программные средства. [Л.М. Невдяев. Телекоммуникационные технологии. Англо… … Справочник технического переводчика

инструментальные средства — Syn: инструментарий … Тезаурус русской деловой лексики

инструментальные средства публикации — — [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN publication tools (SpacePub) … Справочник технического переводчика

инструментальные средства аудита — 3.5 инструментальные средства аудита (audit tools): Автоматизированные инструментальные средства, помогающие анализировать содержание протоколов аудита. Источник … Словарь-справочник терминов нормативно-технической документации

инструментальные средства поддержки программного обеспечения, — 3.6 инструментальные средства поддержки программного обеспечения, инструментальные средства поддержки ПО: Средства разработки, проектирования, кодирования, тестирования, отладки, управления конфигурацией программного обеспечения. Источник … Словарь-справочник терминов нормативно-технической документации

Средства программирования в Интернет — языки описания веб страниц и инструментальные средства разработки веб ресурсов. Языки описания веб страниц поддерживаются браузерами. См. также: Средства программирования в Интернет Инструментальное программное обеспечение Веб браузеры Веб… … Финансовый словарь

инструментальные (рабочие) средства — тестовая (рабочая) программа оценки производительности — [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом Синонимы тестовая (рабочая) программа оценки… … Справочник технического переводчика

инструментальные программные средства — сервисные (вспомогательные) программы (См. tools.) [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом Синонимы сервисные (вспомогательные) программы EN software… … Справочник технического переводчика

ГОСТ Р ИСО/МЭК 18028-1-2008: Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность информационных технологий. Часть 1. Менеджмент сетевой безопасности — Терминология ГОСТ Р ИСО/МЭК 18028 1 2008: Информационная технология. Методы и средства обеспечения безопасности. Сетевая безопасность информационных технологий. Часть 1. Менеджмент сетевой безопасности оригинал документа: 3.3 аудит (audit):… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р ИСО/МЭК 27033-1-2011: Информационная технология. Методы и средства обеспечения безопасности. Безопасность сетей. Часть 1. Обзор и концепции — Терминология ГОСТ Р ИСО/МЭК 27033 1 2011: Информационная технология. Методы и средства обеспечения безопасности. Безопасность сетей. Часть 1. Обзор и концепции оригинал документа: 3.2 архитектура (architecture): Базовая организация системы,… … Словарь-справочник терминов нормативно-технической документации

Switch-технология — технология разработки систем логического управления на базе конечных автоматов, охватывающая процесс спецификации, проектирования, реализации, отладки, верификации, документирования и сопровождения. Предложена А. А. Шалыто в 1991 году [1].… … Википедия

Источник