Шпаргалка по "Менеджменту"

все способы функциональных спецификаций имеют следующие

общие черты:

• модель имеет иерархическую  структуру, представляемую в 

виде диаграмм нескольких уровней;

• элементарной частью диаграммы  каждого уровня является

конструкция «вход —  функция — выход»;

• необходимая дополнительная информация содержится в файлах

поясняющего текста.

В большинстве случаев  функциональные диаграммы — это 

диаграммы потоков данных (DFD — Data How Diagram). В DFD

блоки (прямоугольники) соответствуют  функциям, дуги — входным 

и выходным потокам данных. Поясняющий текст дается в

виде «словарей данных», в которых указываются компонентный

состав потоков данных, число повторений циклов и т.п. Для  описания

структуры информационных потоков можно использовать

нотацию Бэкуса — Наура.

Разработка DFD начинается с построения диаграммы верхнего

уровня, отражающей связи  программной системы, представленной

в виде единого процесса, с внешней средой. Декомпозиция

процесса проводится до уровня, где фигурируют элементарные

процессы, которые могут  быть представлены одностраничными 

описаниями алгоритмов (мини-спецификациями) на языке

программирования.

Для описания информационных моделей наибольшее распространение 

получили диаграммы  «сущность — связь» (ERD — Entity-

Relations Diagrams), фигурирующие, например, в методике IDEF1X.

Поведенческие модели описывают процессы обработки информации.

В системах CASE их представляют в виде граф-схем,

диаграмм перехода состояний, таблиц решений, псевдокодов (языков

спецификаций), языков программирования, в том числе языков

четвертого поколения (4GL).

В граф-схемах блоки, как  и в DFD, используют для задания 

процессов обработки, но дуги имеют иной смысл: они описывают 

последовательность передач  управления (вместе со специальными

блоками управления).

В диаграммах перехода состояний  узлы соответствуют состояниям

моделируемой системы, дуги — переходам из состояния  в 

состояние, атрибуты дуг  — условиям перехода и инициируемым

при их выполнении действиям. Очевидно, что, как и в других,

конечно-автоматных моделях, кроме графической формы представления

диаграмм перехода состояний, можно использовать также 

табличные формы. Так, при  изоморфном представлении с помощью 

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

строка таблицы, в которой  указываются исходное состояние, условие 

перехода, инициируемое при этом действие и новое состояние

после перехода.

Близкий по своему характеру  способ описания процессов основан 

на таблицах (или деревьях) решений. Каждый столбец таблицы 

решений соответствует  определенному сочетанию условий,

при выполнении которых осуществляются действия, указанные в

нижерасположенных клетках  столбца.

В псевдокодах алгоритмы  записываются с помощью как средств 

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

операторов), так и  естественного языка (для выражения

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

(операторы) следования (условные) цикла. 

Языки четвертого поколения  направлены на описание программ

как совокупностей заранее  разработанных программных 

модулей, поэтому возможно соответствие одной команды языка

4GL значительному фрагменту программы  на языке 3GL. Примерами 

языков 4GL могут служить Informix-4GL, JAM, NewEra.

Мини-спецификации процессов могут  быть выражены с помощью 

псевдокодов (языков спецификаций), визуальных языков

проектирования или языков программирования.  

18. Технологии проектирования информационных систем

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

IDEF {Integrated Definition) разработана по программе

Integrated Computer-Aided Manufacturing в США. В этой совокупности

имеются методики функционального, информационного и 

поведенческого моделирования  и проектирования, в ее состав в  настоящее время входят IDEF-методики, отмеченные в табл. 5.1.

 

Таблиц а 5.1

 

МЕТОДИКИ функционального моделирования. Наиболее известная

методика функционального  моделирования сложных систем —  методика

SADT (Structured Analysis and Design Technique), предложенная в

1973 г. Россом и впоследствии  ставшая основой стандарта IDEF0 [8,

53]. Эта методика рекомендуется для начальных стадий проектирования

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

включающих людей, оборудование, программное обеспечение.

Разработка SADT-модели начинается с формулировки вопросов,

на которые модель должна давать ответы, т.е. формулируется

цель моделирования. Далее  выполняются этапы:

1) сбор информации. Источниками  информации могут быть документы, 

наблюдение, анкетирование  и т.п. Существуют специальные 

методики выбора экспертов  и анкетирования;

2) создание модели. Используется нисходящий стиль: сначала

разрабатываются верхние  уровни, затем нижние;

3) рецензирование модели. Реализуется в итерационной процедуре 

рассылки модели на отзыв  и ее доработки по замечаниям

рецензентов, в завершение собирается согласительное совещание.

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

определения динамики функционирования сложных систем. В его 

основе лежат модели и методы имитационного моделирования 

систем массового обслуживания, сети Петри, возможно применение

конечно-автоматных моделей, описывающих поведение системы 

как последовательности смены состояний.

Поведенческие аспекты  приложений отражает методика IDEF3

[9]. Если методика IDEF0 связана  с функциональными аспектами 

и позволяет отвечать на вопрос «что делает система?», то в IDEF3

детализируются и конкретизируются IDEFO-функции, IDEF3-MOдель

отвечает на вопрос «как система это делает?». В IDEF3 входят

два типа описаний:

1) процессно-ориентированные  в виде последовательности 

операций;

2) объектно-ориентированные,  представляемые диаграммами 

перехода состояний, характерными для конечно-автоматных моделей,

в этих диаграммах имеются  средства для изображения состояний 

системы, активностей, переходов  из состояния в состояние 

и условий перехода.

Системы информационного  моделирования реализуют методики

инфологического проектирования баз данных. Широко используются

язык и методика IDEF1X создания информационных моделей 

приложений, развивающая  более раннюю методику IDEFI [7]. Кроме 

того, развитые коммерческие СУБД, как правило, имеют в своем 

составе совокупность CASE-средств  проектирования приложений.

Этапы разработки информационной модели. В IDEF1X имеется 

ясный графический язык для описания объектов и отношений в 

приложениях. Этот язык есть язык диаграмм «сущность — связь»

(ERD). Разработка информационной  модели по IDEF1X выполняется 

в несколько этапов.

Этап 1. Выясняются цели проекта, составляется план сбора 

информации. Обычно исходные положения  для информационной

модели вытекают из IDEFO-модели.

Этап 2. Выявление и определение  сущностей. Это неформальная

процедура.

Этап 3. Выявление и определение  основных отношений. Результат 

представляется или графически в виде ER-диаграмм, или 

в виде матрицы отношений, элемент  которой Ау = 1, если имеется

связь между сущностями / и у, иначе  Д-, = 0, транзитивные связи не

указываются.

Этап 4. Детализация неспецифических  отношений, определение 

ключевых атрибутов, установление внешних ключей. Детализация 

неспецифических отношений заключается в замене связей

«многие ко многим» на связи «многие  к одному» и «один ко многим

» введением сущности-посредника.

Этап 5. Определение атрибутов и  их принадлежности сущностям.

Методика IDEF4 реализует объектно-ориентированное  проектирование

больших систем [19]. Она предоставляет пользователю

графический язык для изображения  классов, диаграмм наследования,

таксономии методов.

Методика IDEF5 направлена на представление  онтологической

информации приложения в удобном для пользователя виде. Для 

этого используются символические  обозначения (дескрипторы)

объектов, их ассоциаций, ситуаций и схемный язык описания отношений 

классификации, «часть — целое», перехода и т.п. В методике

имеются правила связывания объектов (термов) в правильные

предложения и аксиомы интерпретации термов.

Развитие BPR методик продолжается в США по программе ПСЕ 

(Information Integration for Concurrent Engineering) [6]. Разработаны

методики:

• IDEF6, направленная на сохранение рационального  опыта 

проектирования информационных систем, что способствует

предотвращению повторных ошибок;

• IDEF8 для проектирования диалога  человека с технической 

системой;

• IDEF9 для анализа имеющихся  условий и ограничений (в том 

числе физических, юридических, политических) и их влияния

на принимаемые решения  в процессе реинжиниринга;

• IDEF14 для представления  и анализа данных при проектировании

вычислительных сетей  на графическом языке с описанием 

конфигураций, очередей, сетевых компонентов, требований

к надежности и т.п.

Основные положения стандартов IDEF0 и IDEF1X использованы

также при создании комплекса  стандртов ISO 10303, задающих

технологию STEP для представления  в компьютерных средах

информации, относящейся  к промышленному производству. В 

свою очередь стандарты STEP, совокупность языков таких, как

Express и SGML, а также  стандарты P-LIB и MANDATE [26] составляют 

основу технологии CALS информационного обеспечения 

всех этапов жизненного цикла промышленных изделий.

Технология CALS призвана разрешить проблему согласования

содержания и формы  представления данных о промышленной

продукции в территориально распределенной сети проектных и 

производственных узлов  на основе совокупности международных 

стандартов и телекоммуникационных технологий. Только в этих

условиях станет возможной оптимальная специализация предприятий,

распределенное проектирование, минимизация затрат на освоение

и эксплуатацию созданных  систем.  

19. Классическое проектирование информационных систем

Как классическое рассматривается  проектирование ИС для

достаточно стабильных условий, что явно или неявно предполагалось

в 70-е и в первой половине 80-х годов XX в. Представительность

соответствующих технологий, ориентация на наиболее массовую

часть ИС, наличие не только теоретических оснований, но

и промышленных методик и стандартов, использование этих методик

в течение десятилетий  — именно это позволяет называть

описываемые методы классическими. Методы проектирования

таких ИС в 80-х годах  были хорошо описаны и в зарубежной, и в 

отечественной литературе разных направлений: методические монографии,

стандарты (ГОСТы, ANSI, ISO), учебники.

Рассматриваемые методы в разной терминологии под различными

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

работ. За 20 лет и в  разных «школах» проектирования разбиение

работ на стадии и их названия менялись. Кроме того, наиболее

разумно организованные методики и стандарты избегали жестко однозначного

приписывания работ  к конкретным стадиям. Вместе с тем 

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

схему прагматически  устойчиво выделялись следующие  проектные 

стадии (некоторые названия соответствующих этапов работ и 

(или) соответствующих  документов в англоязычной литературе):

• запуск: организация  основания для деятельности и  запуск

работ: приказ и(или) договор  о разработке автоматизиро

ванной системы, задание на выполнение работ (proposal for

the development, agreement, mobilization);

• обследование: предпроектное обследование, общий анализ ситуации

на предприятии, разработка общего обоснования целесообразности

создания ИС (feasibility stady, scope analysis,

strategy stady and planning, requirement definition);

• концепция, ТЗ: исследования требований предприятия и пользователей,

выработка рекомендаций по разработке ИС, разработка

ТЗ на проектирование ИС в целом  и частных ТЗ по

подсистемам (strategy planning, analysis, requirement specification,

function description);

• эскизный проект: разработка архитектуры  будущей ИС в рамках

эскизного проекта (detailed analysis, high level design);

• опытный вариант ИС: разработка упрощенного варианта, пилотного 

проекта будущей ИС (pilot-project, test development);

• опытное использование пилот-проекта  ИС, разработка исправлений 

и дополнений к ТЗ (test, corrected requirement

specification);

• ТП: разработка технического проекта  ИС (detailed analysis

and design, test development);

• РП: разработка рабочей документации проекта (development,

test, system implementation);

• ввод в действие: по-другому  — «внедрение» ИС (deployment,

put into operation).

Одно из использовавшихся в западной литературе названий

такой схемы организации  работ — это «водопадная или  каскадная 

модель* (waterfall model). Схема  обязана была включать итерационные

процедуры уточнения  требований к системе и рассмотрения

вариантов проектных  решений. Все же эти процедуры  и целые 

этапы работ носили в  основном последовательный характер,

а, кроме того, предметом  была проектируемая ИС целиком, в  целостном