4905

CASE-технологии. Консалтинг в автоматизации бизнес-процессов

Книга

Информатика, кибернетика и программирование

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

Русский

2012-11-29

3.01 MB

120 чел.

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

Фактически проблема комплексной автоматизации стала актуальной для каждого предприятия. Уже не стоит вопрос "надо или не надо автоматизировать", предприятия столкнулись с проблемой: каким образом это осуществить. Подобная переориентация предприятий объясняется следующими основными причинами:

повышением степени организационной и финансовой самостоятельности;

выходом на зарубежный рынок;

стремлением ряда западных компаний производить свои товары в России;

завершением периода "островковой" автоматизации;

возрастающей ориентацией предприятий на бизнес-процессы, т.е. деятельности, имеющие ценность для клиента;

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

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

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

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

единая информационная среда предприятия;

режим реального времени;

независимость от законодательства;

интеграция с другими приложениями (в том числе с уже работающими на предприятии системами);

поэтапное внедрение и т.п.

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

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

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

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

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

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

ПРЕДИСЛОВИЕ К ТРЕТЬЕМУ ИЗДАНИЮ

За последние 10 лет книжный рынок России вплотную приблизился по насыщенности к Западному. Полки книжных магазинов переполнены самыми разнообразными отечественными и переводными новинками и бестселлерами в области информационных технологий. Работать и учиться стало гораздо легче, имея возможность получить необходимую информацию. Правда, когда возникает потребность в реализации полученных знаний, часто сталкиваешься с проблемой отсутствия литературы по практике применения тех или иных методов. Книга Г.Н.Калянова ('Консалтинг при автоматизации предприятий» приятное исключение.

Первое издание книги вышло в 1997 г. и стало заметным событием на книжном рынке. Своевременная, нужная, полная и профессиональная книга стала хорошим учебным и практическим пособием для специалистов, занимающихся моделированием бизнес-процессов и реализующих проекты по автоматизации предприятий. И не только для них. Целевая аудитория данного издания весьма широка: от новичка студента до профессионала консультанта. За три года «Консалтинг» Г.Н. Калянова стал букварем для всех, кто, так или иначе, занимается CASE-технологиями.

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

Новое издание, ставшее стереотипным, обязательно найдет своих читателей. Причин здесь несколько. Одна из них – актуальность технологий. Наши российские предприятия наконец-то начинают понимать необходимость не только автоматизации технологий с помощью программных средств, но и важность предварительной оценки стратегических перспектив и ценности бизнеса для всех заинтересованных лиц (клиентов, владельцев, сотрудников, поставщиков). Анализ и оценка существующих бизнес-процессов предприятия должна проводиться постоянно в режиме реального времени. Это возможно при условии функционирования на предприятии Процессной системы управления. Такая система включает в себя, как правило, и процессную систему управленческого учета затрат по методам ABC/ABM (Activity Based Costing/Activity Based Management) и расчета себестоимости продукции или услуг, а также системы бюджетирования по методу ABB (Activity Based Budget).

В условиях глобальной конкуренции, расширяющихся границ предприятия и недостаточности финансовых показателей для оценки своей деятельности современные предприятия все чаще используют новые технологии, например, технологию управления по ключевым показателям (KPI, Key Performance Indicators), а в качестве инструмента оценки эффективности – систему сбалансированных показателей (BSC, Balanced Score-Card). Хорошо сбалансированная система показателей является стратегическим оружием в конкурентной борьбе и средством для выработки индивидуальной конкурентоспособной стратегии поведения на рынке.

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

Владимир Ивлев

Генеральный директор Российской консалтинговой

компании «ВИП Анатех», к.т.н.

Татьяна Попова

Директор по финансам и маркетингу

РКК «ВИП Анатех», к. э. и.

ИЗ ОТЗЫВОВ И РЕЦЕНЗИЙ НА ПЕРВОЕ ИЗДАНИЕ КНИГИ

"Книга является основой оригинального семестрового курса лекций по CASE-технологиям, подготовленного и читаемого автором в Высшей компьютерной школе при НИВЦ МГУ в течении шести последних лет. Сделанный в книге акцент на последовательное рассмотрение наиболее важных аспектов системного структурного анализа и проектирования делает эту книгу особенно полезной для пользователей, которые выбирают CASE-системы в качестве инструмента для решения их прикладных задач, а также студентов, начинающих постигать основы современных информационных технологий".

В.А. Сухомлин, зав. лабораторией открытых информационных технологий факультета ВМК МГУ им. М.В.Ломоносова, профессор, доктор технических наук

"Книги по данной тематике сегодня просто обречены на успех. Уверен, что Георгий Николаевич Калянов, человек опытный (это не первая его книга) и много знающий, сумеет сделать второе издание настоящим отечественным бестселлером. Тем самым бестселлером, которого народ (и консультанты, и клиенты консалтинга) уже ждет. (PC WEEK/RE, 1998, N.13)

Игорь Альтшулер, вице-президент Нижегородской гильдии профессиональных консультантов, обозреватель PC WEEK/RE

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

(Еженедельник нижегородских предпринимателей "БИРЖА ", 1998, №14)

"Эта книга должна быть интересна менеджерам консалтинговых проектов и руководителям служб автоматизации предприятий, так как ее изучение поможет правильнее оценить профессионализм приглашаемых консультантов, а также быстрее и легче найти с ними общий язык". (Мир ПК, 1998, N.5)

Михаил Глинников, научный редактор журнала PC World Russia

"Выражаю надежду, что второе издание книги Г.Калянова будет принято российскими специалистами с таким же интересом, как и первое. Российский бизнес- и IT-консалтинг, постоянно находясь в тени западного, только начинает вставать на ноги. Поэтому любое издание, основанное на практическом опыте российского консультанта, будет способствовать его подъему".

Владимир Лебедев, начальник отдела банковских технологий Сберегательного банка РФ

ВВЕДЕНИЕ

В.1. Понятие консалтинга в области информационных технологий

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

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

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

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

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

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

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

знания и информация – главный и единственный их продукт;

опыт персонала, приобретаемый годами и десятилетиями при работе над конкретными проектами;

наличие методологии выполнения консалтинговых проектов;

независимость;

объективность.

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

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

В.2. Цели и этапы разработки консалтинговых проектов

Основными целями разработки консалтинговых проектов являются:

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

формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

анализ требований и проектирование спецификаций корпоративных информационных систем;

рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRPmanufacturing resource planning и ERPenterprise resource planning).

Структура подхода к разработке консалтинговых проектов приведена на рис. В.1. Опишем перечисленные этапы более подробно.

1. Анализ первичных требований и планирование работ

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

2. Проведение обследования деятельности предприятия

В рамках данного этапа осуществляется:

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

определение оргштатной и топологической структур предприятия;

определение перечня целевых задач (функций) предприятия;

анализ распределения функций по подразделениям и сотрудникам;

определение перечня применяемых на предприятии средств автоматизации.

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

Рис. В.1. Структура подхода

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

•  данные по оргштатной структуре предприятия;

• информация о принятых технологиях деятельности;

• стратегические цели и перспективы развития;

• результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

• предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

• нормативно-справочная документация;

• опыт системных аналитиков в части наличия типовых решений.

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

3. Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

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

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

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

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

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

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

4. Разработка системного проекта

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

На этом этапе определяются:

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

интерфейсы и распределение функций между человеком и системой;

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

состав людей и работ, имеющих отношение к системе;

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

Системный проект строится на основе модели "как должно быть" и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

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

описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

уменьшить затраты на разработку и внедрение системы;

оценить разработку по времени и результатам;

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

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

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

5. Разработка предложений по автоматизации предприятия

На основании системного проекта осуществляется:

• составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

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

• совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

• разработка требований к техническим средствам;

• разработка требований к программным средствам;

• разработка предложений по этапам и срокам автоматизации.

6. Разработка технического проекта

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:

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

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

При этом происходит расширение системного проекта:

• за счет его уточнения;

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

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

7. Последующие этапы

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

Настройка существующей системы MRP или ERP осуществляется по следующим этапам:

наполнение системы фактическими данными;

построение процедур их обработки;

интеграция процедур внутри автоматизированных рабочих мест;

интеграция автоматизированных рабочих мест в систему.

В.З. CASE-технологии– методологическая инструментальная база консалтинга

За последнее десятилетие сформировалось новое направление в программотехнике – CASE (Computer-Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE – технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE – это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

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

Существует мнение, что CASE является наиболее перспективным направлением в программотехнике. С этим, естественно, можно и нужно спорить, но то, что CASE – наиболее бурно и интенсивно развиваемое направление, является в настоящее время фактом. Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (точнее ее подмножество IDEF0) принята в качестве стандарта на разработку ПО Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

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

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

бизнес-анализ (фактически, модели деятельности предприятий "как есть" и "как должно быть" строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств);

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

Следует отметить, что CASE – не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальные и технологическими. Однако это и не Confuse Array of ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE-средство. Одним из ключевых признаков является поддержка методологий структурного системного анализа и проектирования.

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

Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE обладают следующими основными достоинствами:

улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта);

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

ускоряют процесс проектирования и разработки;

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

поддерживают развитие и сопровождение разработки;

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

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

ЧАСТЬ 1. МЕТОДЫ И СРЕДСТВА СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

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

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

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

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

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

В главе 5 описываются базовые средства информационного моделирования – диаграммы "сущность-связь" (при этом рассматриваются две наиболее популярные нотации – Чена и Баркера), приводятся основные этапы построения информационной модели, включая нормализацию.

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

Глава 7 посвящена средствам структурного проектирования. Рассматриваются две базовые техники структурного проектирования (Константайна и Джексона), вводятся основные символы соответствующих диаграмм, рассматриваются их достоинства и недостатки. Проводится анализ характеристик хорошего проекта, намечена схема алгоритма преобразования иерархии диаграмм потоков данных в структурные карты.

ГЛАВА 1. ПОНЯТИЕ СТРУКТУРНОГО АНАЛИЗА

  1.  Жизненный цикл программного изделия и его критичные этапы

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей. Традиционно выделяются следующие основные этапы ЖЦ ПО:

анализ требований,

проектирование,

кодирование (программирование),

тестирование и отладка,

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

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

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:

  1.  КАСКАДНАЯ МОДЕЛЬ (70-80г.г.) – предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.
  2.  ПОЭТАПНАЯ МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ (80-85г.г.) – итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.
  3.  СПИРАЛЬНАЯ МОДЕЛЬ (86-90г.г.) – делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

Специалистами отмечаются следующие преимущества спиральной модели:

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

ориентация на развитие и модификацию ПО в процессе его проектирования;

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

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

АНАЛИЗ ТРЕБОВАНИЙ является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем ПО известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований. Список требований к разрабатываемой системе должен включать:

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

описание выполняемых системой функций;

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

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

архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам ПО,
необходимые аппаратные ресурсы, требования к БД, физические характеристики компонент ПО, их интерфейсы.

ЭТАП ПРОЕКТИРОВАНИЯ дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как "(итерационный) процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям". Обычно этот этап разделяют на два подэтапа:

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

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

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

  1.  Идеи, лежащие в основе структурных методов

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

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

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

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

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

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

Облегчается доступность для понимания и освоения. Можно стать специалистом по магнитофонам без углубленных знаний о колонках.

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

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

каждый черный ящик должен реализовывать единственную функцию системы;

функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - Расчет точки приземления);

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

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

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

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

Наконец, третий момент: структурные методы широко используют графические нотации, также служащие для облегчения понимаемости сложных систем. Известно, что "одна картинка стоит тысячи слов". На рис. 1.1 изображен черноволосый мужчина, одетый в серое двубортное пальто. Мужчина держит в левой руке дипломат и т.д. Вообще говоря, нет необходимости комментировать это: читатель впитывает вышеизложенное описание с первого взгляда.

Однако, можно добавить дополнительные подробности, которые не видны из рисунка. Например, мужчину зовут Борис Борисович, ему 45 лет. Структурные методы также позволяют дополнить "картинки" любой информацией, которая не может быть отражена при использовании соответствующей графической нотации.

Рис. 1.1.

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

  1.  Принципы структурного анализа

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

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

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

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

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

спецификация системы из-за объема и технических терминов часто непонятна для заказчика;

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

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

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

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

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

  1.  Принцип абстрагирования – заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
  2.  Принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы.
  3.  Принцип упрятывания – заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
  4.  Принцип концептуальной общности – заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование –структурное тестирование).
  5.  Принцип полноты – заключается в контроле на присутствие лишних элементов.
  6.  Принцип непротиворечивости – заключается в обоснованности и согласованности элементов.

7) Принцип логической независимости – заключается в концентрации
внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

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

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

1.4. Средства структурного анализа и их взаимоотношения

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

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

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

отношения между данными;

зависящее от времени поведение системы (аспекты реального времени).

Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие:

DFD (Data Flow Diagrams) – диаграммы потоков данных (глава 2) совместно со словарями данных (глава 3) и спецификациями процессов или миниспецификациями (глава 4);

ERD (Entity-Relationship Diagrams) – диаграммы "сущность-связь" (глава 5);

STD (State Transition Diagrams) – диаграммы переходов состояний (глава 6).

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

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

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

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

Рис. 1.2. Компоненты логической модели

ГЛАВА 2. ДИАГРАММЫ ПОТОКОВ ДАННЫХ

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

Диаграммы потоков данных известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой – каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму – предвестника DFD.

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

2.1. Основные символы

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

ПОТОКИ ДАННЫХ являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.

Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним – двунаправленным.

Рис. 2.1. Основные символы диаграммы потоков данных

Назначение ПРОЦЕССА состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

2.2. Контекстная диаграмма и детализация процессов

Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня.

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

DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.

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

При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так,  например, если мы детализируем процесс номер 2 на диаграмме первого  уровня, раскрывая его с помощью DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1,2.2.2. и т.д.

2.3. Декомпозиция данных и соответствующие расширения диаграмм потоков данных

Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки ЯБЛОКИ, АПЕЛЬСИНЫ и ГРУШИ. Эти потоки могут быть сгруппированы с помощью введения нового потока ФРУКТЫ. Для этого необходимо определить формально поток ФРУКТЫ как состоящий из нескольких элементов-потомков. Такое определение задается с помощью формы Бэкуса-Наура (БНФ) в словаре данных (см. главу 3). В свою очередь поток ФРУКТЫ сам может содержаться в потоке-предке ЕДА вместе с потоками ОВОЩИ, МЯСО и др. Такие потоки, объединяющие несколько потоков, получили название групповых.

Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла (рис. 2.2), позволяющего расщепить поток на любое число подпотоков. При расщеплении также необходимо формально определить подпотоки в словаре данных (с помощью БНФ).

Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток ФРУКТЫ, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока ФРУКТЫ может не быть вовсе, но вместо него могут быть потоки ЯБЛОКИ и АПЕЛЬСИНЫ (как будто бы они переданы из детализируемого процесса). В этом случае должно существовать БНФ-определение потока ФРУКТЫ, состоящего из подпотоков ЯБЛОКИ и АПЕЛЬСИНЫ, для целей балансирования.

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

Рис 2.2. Расширения диаграммы потоков данных

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

  1.  ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме).
  2.  УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD.
  3.  НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока.
  4.  УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков
    данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой – выходным.

5) Текст в свободном формате в любом месте диаграммы. Возможный   способ   изображения   этих   узлов   приведен на рис. 2.2.

2.4. Построение модели

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

  1.  Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
  2.  Не загромождать диаграммы несущественными на данном уровне деталями.
  3.  Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой.
  4.  Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.
  5.  Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться к нему на нижних уровнях.
  6.  Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты.
  7.  Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.

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

  1.  Расчленение множества требований и организация их в основные функциональные группы.
  2.  Идентификация внешних объектов, с которыми система должна быть связана.
  3.  Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
  4.  Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями.
  5.  Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
  6.  Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
  7.  Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
  8.  Проверка основных требований по DFD первого уровня.
  9.  Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10) Проверка основных требований по DFD соответствующего уровня.

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

2.5. Пример банковской задачи

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

На рис. 2.3 приведена контекстная диаграмма системы с единственным процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИЕНТ и КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов. Опишем потоки данных, которыми обменивается проектируемая система с внешними объектами.

Для банковского обслуживания клиенту необходимо предоставить системе свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее информации {ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сообщить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ и ЗАПРОС НА ОБСЛУЖИВАНИЕ, т.е. требуемую ему услугу (например, снятие со счета наличных денег). Банковское обслуживание с позиций клиента, в свою очередь, должно обеспечить следующее:

выдать СООБЩЕНИЕ, приглашающее клиента ввести КЛЮЧЕВЫЕ ДАННЫЕ;

выдать клиенту ДЕНЬГИ;

выдать клиенту ВЫПИСКУ по проведенному обслуживанию, включающую ВЫПИСКУ О ДЕНЬГАХ,  ВЫПИСКУ ПО БАЛАНСУ и ВЫПИСКУ ПО ОПЕРАЦИИ, проведенной банком.

Рис. 2.3. Контекстная диаграмма банковской задачи

Контекстный процесс и КОМПЬЮТЕР БАНКА должны обмениваться следующей информацией:

ДАННЫЕ ПО СЧЕТУ клиента в банке;

ПРОТОКОЛ  ОБСЛУЖИВАНИЯ,  включающей  информацию  об ОБРАБОТАННОЙ ДОКУМЕНТАЦИИ,  изымаемой  ДЕНЕЖНОЙ СУММЕ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.

Контекстный процесс может быть детализирован DFD первого уровня как показано на рис. 2.4. Эта диаграмма содержит 4 процесса и хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ, которое изображено дважды на диаграмме с целью избежания пересечений линий потоков данных.

Процесс 1.1 {ПОЛУЧИТЬ ПАРОЛЬ) осуществляет прием и проверку пароля клиента и имеет на входе/выходе следующие потоки:

внешний выходной поток СООБЩЕНИЕ для информирования клиента о своей готовности принять пароль;

входной поток ВВЕДЕННЫЙ ПАРОЛЬ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;

входной  поток ПАРОЛЬ  из  хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для проверки вводимого клиентом пароля.

Процесс 1.2 {ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) осуществляет прием и проверку запроса клиента на проведение необходимой ему банковской операции и имеет на входе/выходе следующие потоки:

внешний выходной поток СООБЩЕНИЕ для информирования клиента о своей готовности принять запрос на обслуживание;

входной поток ЗАПРОС НА ОБСЛУЖИВАНИЕ как элемент внешнего потока КЛЮЧЕВЫЕ ДАННЫЕ;

входной   поток  ЛИМИТ  ДЕНЕГ  из   хранилища  ДАННЫЕ КРЕДИТНОЙ КАРТЫ для контроля наличия денег на счете клиента.

Рис. 2.4. Детализация процесса ОБСЛУЖИТЬ

Процесс 1.3 (ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) имеет внешний входной поток ДАННЫЕ ПО СЧЕТУ (из внешней сущности КОМПЬЮТЕР БАНКА), входной поток ДЕТАЛИ КЛИЕНТА (из хранилища), а также внешние выходные потоки ВЫПИСКА, ДЕНЬГИ и ПРОТОКОЛ ОБСЛУЖИВАНИЯ.

Процесс 1.4 (ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ) осуществляет считывание информации с кредитной карты и имеет на входе внешний поток КРЕДИТНАЯ КАРТА, а на выходе поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ. Отметим, что нет необходимости в идентификации последнего потока, т.к. идентифицировано соответствующее хранилище.

Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходимости в их детализации с помощью DFD уровня 2 (они будут раскрыты с помощью спецификаций процессов в главе 4). Процесс 1.3 может быть детализирован с помощью DFD второго уровня как показано на рис. 2.5. Эта диаграмма содержит 4 элементарных процесса, спецификации которых также будут приведены в главе 4.

Рис. 2.5. Детализация процесса ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ

Процесс 1.3.1 (ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА) осуществляет обработку внутренней банковской документации по клиенту и имеет входной поток ДЕТАЛИ КЛИЕНТА и выходной поток ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ (часть внешнего потока ПРОТОКОЛ СДЕЛКИ).

Процесс 1.3.2 (РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА) выдает справку по истории счета клиента и по балансу клиента. Входные потоки – ДЕТАЛИ КЛИЕНТА и ДАННЫЕ ПО БАЛАНСУ (часть внешнего потока ДАННЫЕ ПО СЧЕТУ), выходные потоки – ВЫПИСКА ПО БАЛАНСУ (часть внешнего потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть внешнего потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Процесс 1.3.3 (ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ) обеспечивает выдачу наличных денег и информирование компьютера банка об изъятых из банка деньгах. Он имеет входные потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ КЛИЕНТА, и выходные потоки ДЕНЬГИ и ДЕНЕЖНАЯ СУММА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Процесс 1.3.4 (РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА) выдает справку по истории счета и уведомление по проведенной операции. Входные потоки ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА, выходные потоки – ВЫПИСКА ПО ОПЕРАЦИИ (часть потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

2.6. Расширения реального времени

Расширения реального времени используются для дополнения модели функционирования данных (иерархии DFD) средствами описания управляющих аспектов в системах реального времени. Для этих целей применяются следующие символы (рис. 2.6):

Рис. 2.6. Расширения реального времени

  1.  УПРАВЛЯЮЩИЙ ПРОЦЕСС. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени (глава 6). Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления.
  2.  УПРАВЛЯЮЩЕЕ ХРАНИЛИЩЕ. Представляет "срез" управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны.

3) УПРАВЛЯЮЩИЙ ПОТОК. Представляет собой "трубопровод", через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.

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

При этом режим выполнения процесса зависит от типа управляющего потока. Имеются следующие типы управляющих потоков:

а) Т-поток (trigger flow). Является потоком управления процессом, который может вызывать выполнение процесса. При этом процесс как бы включается одной короткой операцией. Это – аналог выключателя света, единственным нажатием которого "запускается" процесс горения лампы.

б) А-поток (activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток "включен" (т.е. течет непрерывно), с "выключением" потока выполнение процесса завершается. Это – аналог переключателя лампы, которая может быть как включена, так и выключена.

в) E/D-поток (enable/disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по Е-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это – аналог
выключателя с двумя кнопками: одной – для включения света, другой – для его выключения. Отметим, что можно использовать 3 типа таких потоков: Е-поток,
D-поток, E/D-поток.

Иногда возникает необходимость в представлении одного и того же фрагмента данных потоками различных типов. Например, поток данных СКОРОСТЬ МАШИНЫ в отдельных случаях может использоваться как управляющий для контроля критического значения. Для обеспечения этого используется УЗЕЛ ИЗМЕНЕНИЯ ТИПА (рис. 2.7): поток данных является входным для этого узла, а управляющий поток – выходным.

Дополним модель предложенной в 2.5 банковской системы, введя в диаграммы управляющий процесс и управляющие потоки, позволяющие описать ее функционирование в реальном времени. После такого расширения DFD, приведенные на рис. 2.4 и 2.5 будут выглядеть, как показано на рис. 2.8 и 2.9, соответственно.

Рис. 2.7. Узел изменения типа

Управляющий процесс 1.5 (УПРАВЛЕНИЕ ОБСЛУЖИВАНИЕМ), получив информацию о том, что кредитная карта введена (поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА), вызывает выполнение процесса 1.1 (поток А: ПОЛУЧИТЬ ПАРОЛЬ). Получив информацию о введенном пароле (поток КОРРЕКТНЫЙ ПАРОЛЬ), процесс 1.5 информирует процесс 1.4 о необходимости удаления кредитной карты (поток: УДАЛЕННАЯ КРЕДИТНАЯ КАРТА) и с помощью потока Т: ОБЕСПЕЧИТЬ ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ вызывает выполнение процесса 1.2, затем процесса 1.3 (поток ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ).

Рис. 2.8. Расширение диаграммы, детализирующей контекстный процесс

Последний управляющий поток на детализирующей процесс 1.3 диаграмме расчленяется на 4 подпотока, каждый из которых вызывает выполнение процессов 1.3.1 – 1.3.4, соответственно.

Рис. 2.9. Расширение диаграммы, детализирующей процесс 1.3

ГЛАВА 3. СЛОВАРЬ ДАННЫХ

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

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

описанием значений потоков и хранилищ, изображенных на DFD;

описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные символы (например, АДРЕС ПОКУПАТЕЛЯ содержит
ПОЧТОВЫЙ ИНДЕКС, ГОРОД УЛИЦУ и т.п.);

описанием композиции групповых данных в хранилище;

специфицированием значений и областей действия элементарных
фрагментов информации в потоках данных и хранилищах;

описанием деталей отношений между хранилищами.

3.1. Содержимое словаря данных

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

По типу потока в словаре содержится информация, идентифицирующая:

простые (элементарные) или групповые (комплексные) потоки;

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

потоки данных или потоки управления;

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

Атрибуты потока данных включают:

имена-синонимы потока данных в соответствии с узлами изменения
имени;

БНФ-определение в случае группового потока (см. 3.2);

единицы измерения потока;

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

список значений и их смысл для дискретного потока;

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

список потоков, в которые данный поток входит (как элемент БНФ-определения);

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

3.2. БНФ – НОТАЦИЯ

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

Важно понимать, что точные определения потоков содержатся в словаре данных, а не на диаграммах. Например, на диаграмме может иметься групповой узел с входным потоком X и выходными подпотоками Y и Z. Однако это вовсе не означает, что соответствующее определение в словаре данных обязательно должно быть X=Y+Z. Это определение может быть следующим:

Х=А+В+С; Y=A+B; Z=B+C

Такие, определения хранятся в словаре данных в так называемой БНФ-статье. БНФ-статья используется для описания компонент данных в потоках данных и в хранилищах. Ее синтаксис имеет вид:

@БНФ = <простой оператор> ! <БНФ-выражение> ,

где <простой оператор> есть текстовое описание, заключенное в "/", а <БНФ-выражение> есть выражение в форме Бэкуса-Наура, допускающее следующие операции отношений:

=   – означает "композиция из",

+   – означает "И",

[! ] - означает "ИЛИ",

() - означает, что компонент в скобках не обязателен,

{} - означает итерацию компонента в скобках,

" " - означает литерал.

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

3{болт}7 – от З до 7 итераций

1 {болт} -1 и более итераций

{шайба}3 – не более 3 итераций

БНФ-выражение может содержать произвольные комбинации операций:    

@БНФ = [винт ! болт + 2{гайка}2 + (прокладка) ! клей]

Ниже приведен пример описания потока данных с помощью БНФ:

@ИМЯ = ВОСЬМЕРИЧНАЯ ЦИФРА

@ТИП = дискретный поток

@БНФ = ["0"!"1".'"2"!"3"!"4".'"5"!"6"!"7"]

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

@ИМЯ = ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА

@ТИП = управляющий поток

@БНФ = /указывает, что кредитная карта введена/

@ИМЯ = ДАННЫЕ КРЕДИТНОЙ КАРТЫ

@ТИП — дискретный поток

@БНФ = ПАРОЛЬ + ДЕТАЛИ КЛИЕНТА + ЛИМИТ ДЕНЕГ

@ИМЯ = ДАННЫЕ ПО БАЛАНСУ

@ТИП дискретный поток

@БНФ = /текущий баланс счета клиента/

@ЕДИНИЦА ИЗМЕРЕНИЯ = доллар

@ДИАПАЗОН = +/- 100000

@ТОЧНОСТЬ =01

@ИМЯ = ДЕНЬГИ

@ТИП = дискретный поток

@БНФ = /деньги, выдаваемые клиенту/

@ЕДИНИЦА ИЗМЕРЕНИЯ = доллар

@НОРМА = 5..1ООО

@КОММЕНТАРИЙ Сумма выдаваемых денег должна делиться на 5

@ЦМЯ = ПРОТОКОЛ ОБСЛУЖИВАНИЯ

@ТИП = дискретный поток

@БНФ = (ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ)

+ (ДЕНЕЖНАЯ СУММА)

+ (ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА)

ГЛАВА 4. МЕТОДЫ ЗАДАНИЯ СПЕЦИФИКАЦИЙ ПРОЦЕССОВ

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

Независимо от используемой нотации спецификация процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД = <имя символа данных>

@ВЫХОД = <имя символа данных>

@ВХОДВЫХОД = <имя символа данных>, где <имя символа данных> – соответствующее имя из словаря данных.

Эти ключевые слова должны использоваться перед определением СП, например:

@ВХОД = СЛОВА ПАМЯТИ

@ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ

@СПЕЦПРОЦ

Для всех СЛОВ ПАМЯТИ выполнить:

Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ

@

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

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

Спецификации должны удовлетворять следующим требованиям:

для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;

спецификация должна определять способ преобразования входных потоков в выходные;

нет необходимости (на данном этапе) определять метод реализации этого преобразования;

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

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

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

4.1. Структурированный естественный язык

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

В состав языка входят следующие основные символы:

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

термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.п.);

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

общеупотребительные математические, физические и технические термины;

арифметические уравнения;

таблицы, диаграммы, графы и т.п.;

• комментарии.

Управляющие структуры языка имеют один вход и один выход. К ним относятся:

  1.  последовательная конструкция:

ВЫПОЛНИТЬ функция1

ВЫПОЛНИТЬ функция 2

ВЫПОЛНИТЬ функция З

  1.  конструкция выбора:

ЕСЛИ <условие> ТО

ВЫПОЛНИТЬ функция 1

ИНАЧЕ

ВЫПОЛНИТЬ функция2

КОНЕЦЕСЛИ

  1.  итерация:

ДЛЯ <условие>

ВЫПОЛНИТЬ функция

КОНЕЦДЛЯ

или

ПОКА <условие>

ВЫПОЛНИТЬ функция

КОНЕЦПОКА

При использовании структурированного естественного языка приняты следующие соглашения:

  1.  Логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций.
  2.  Ключевые слова ЕСЛИ, ВЫПОЛНИТЬ, ИНАЧЕ и т.д. должны быть написаны заглавными буквами.
  3.  Слова или фразы, определенные в словаре данных, должны быть написаны заглавными буквами.
  4.  Глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать).
  5.  Логика процесса должна быть выражена четко и недвусмысленно.

Ниже приведен пример спецификации процесса 1 (ПОЛУЧИТЬ ПАРОЛЬ) для диаграммы, изображенной на рис. 2.8.

@ВХОД = ВВЕДЕННЫЙ ПАРОЛЬ

@ВХОД = ПАРОЛЬ

@ВЫХОД = СООБЩЕНИЕ

@ВЫХОД = КОРРЕКТНЫЙ ПАРОЛЬ

@СПЕЦПРОЦ 1.1 ПОЛУЧИТЬ ПАРОЛЬ

ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту,

запрашивающее ввод пароля

принять ВВЕДЕННЫЙ ПАРОЛЬ

ДОТЕХПОРПОКА ВВЕДЕННЫЙ ПАРОЛЬ = ПАРОЛЬ

или были сделаны три попытки ввода

КОНЕЦВЫПОЛНИТЬ

ВЫПОЛНИТЬ установить флаг КОРРЕКТНЫЙ

ПАРОЛЬ в случае равенства

@  КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.1

4.2. Таблицы и деревья решений

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

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа "да-нет". Однако иногда в условии может присутствовать и ограниченное множество значений, например, ЯВЛЯЕТСЯ ЛИ ДЛИНА СТРОКИ БОЛЬШЕЙ, МЕНЬШЕЙ ИЛИ РАВНОЙ ГРАНИЧНОМУ ЗНАЧЕНИЮ?

Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Так, в конструкции

ЕСЛИ ИДЕТ ДОЖДЬ ТО РАСКРЫТЬ ЗОНТ

ИДЕТ ДОЖДЬ является условием, а РАСКРЫТЬ ЗОНТ - действием.

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

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

  1.  если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки;
  2.  если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;
  3.  если очередной символ не находится в заданном диапазоне, то подать звуковой сигнал и вернуть код ошибки;
  4.  иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.

Таблица решений для данного примера приведена ниже (см. табл. 4.1).

Заметим, что если выполняется условие С1, то нет необходимости в проверке условий С2 и СЗ. Поэтому комбинации условий 1, 2, 3, 4 могут быть заменены обобщающей комбинацией (Д,-,-), где "-" означает любую из возможных альтернатив (в данном случае, Д или Н). Аналогично, комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н, Д,-). Редуцированная таким образом таблица решений приведена ниже (табл. 4.2).

Таблица 4.1

Таблица 4.2

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

IF (isctrl(c))   { beep(); return(ERROR)}

ELSE{

IF (i>max_length)  { beep(); return(ERROR)}

ELSE{

IF (out_of_range(c))  { beep(); return(ERROR)}

ELSE { putchar(c); return(++i) }

}

}

Построение ТР рекомендуется осуществлять по следующим шагам:

  1.  Идентифицировать все условия (или переменные) в спецификации. Идентифицировать все значения, которые каждая переменная может иметь.
  2.  Вычислить число комбинаций условий. Если все условия являются бинарными, то существует 2**N комбинаций N переменных.
  3.  Идентифицировать каждое из возможных действий, которые могут вызываться в спецификации.
  4.  Построить пустую таблицу, включающую все возможные условия и действия, а также номера комбинаций условий.
  5.  Выписать и занести в таблицу все возможные комбинации условий.
  6.  Редуцировать комбинации условий.
  7.  Проверить каждую комбинацию условий и идентифицировать соответствующие выполняемые действия.
  8.  Выделить комбинации условий, для которых спецификация не указывает список выполняемых действий.
  9.  Обсудить построенную таблицу.

Вариантом таблицы решений является дерево решений (ДР), позволяющее взглянуть на процесс условного выбора с позиции схемы. Дерево решений для вышерассмотренного примера приведено на рис. 4.1.

Рис. 4.1. Дерево решений

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

4.3. Визуальные языки проектирования спецификаций

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

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

Символы FLOW-форм приведены на рис. 4.2. Каждый символ является блоком обработки. Каждый прямоугольник внутри любого символа также представляет собой блок обработки.

Рис. 4.2. Символы FLOW-форм.

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

Рис. 4.3. Пример FLOW-формы

Рис. 4.4. Диаграмма Насси-Шнейдермана.

Дальнейшее развитие FLOW-формы получили в диаграммах Насси-Шнейдермана. На этих диаграммах символы последовательной обработки и цикла изображаются также, как и соответствующие символы FLOW-форм. В символах условного выбора и case-выбора собственно условие располагается в верхнем треугольнике, выбираемые варианты – на нижних сторонах треугольника, а блоки обработки – под выбираемыми вариантами. Диаграмма Насси-Шнейдермана для вышеприведенного примера изображена на рис. 4.4.

4.4. Сравнение методов

Спектр методов задания спецификаций процессов в соответствии с увеличением трудности их проектирования приведен на рис 4.5. Наиболее трудным методом задания СП являются языки программирования (С, COBOL, FORTRAN и др.). Сложность заключается в том, что языки программирования концентрируют внимание на деталях реализации, а потоки данных в DFD представляются абстрактно (их фактическая композиция определяется в словаре данных). Поэтому сложность – не в написании СП, а в их синхронизации и согласовании с DFD, поскольку при редактировании DFD, вообще говоря, должны корректироваться и спецификации процессов.

Рис. 4.5. Спектр методов задания спецификаций процессов

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

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

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

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

4.5. Спецификации процессов для примера банковской задачи

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

  1.  Спецификация процесса 1.1 приведена в 4.1.
  2.  Спецификация процесса 1.2.

@ВХОД = ЛИМИТ ДЕНЕГ

@ВХОД = ЗАПРОС НА ОБСЛУЖИВАНИЕ

@ВЫХОД = ДЕНЕЖНАЯ СУММА

@ВЫХОД = СООБЩЕНИЕ

@ВЫХОД = ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ

@СПЕЦПРОЦ 1.2 ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ

ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту по вводу запроса на обслуживание

принять ЗАПРОС НА ОБСЛУЖИВАНИЕ

обновить данные ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ (а именно, ЗАПРОС ДОКУМЕНТАЦИИ, ЗАПРОС ДЕНЕГ, ЗАПРОС БАЛАНСА, ЗАПРОС НА ОПЕРАЦИЮ)

ЕСЛИ был сделан ЗАПРОС ДЕНЕГ

ТО ВЫПОЛНИТЬ запросить ДЕНЕЖНУЮ СУММУ выдать требуемую ДЕНЕЖНУЮ СУММУ с учетом того, что она не должно превышать ЛИМИТ ДЕНЕГ

КОНЕЦЕСЛИ

ДОТЕХПОРПОКА запрашивается продолжение обслуживания или не все обслуживание было выполнено

КОНЕЦВЫПОЛНИТЬ

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.2

3) Спецификация процесса 1.3.

  1.  Спецификация процесса 1.3.1.

®ВХОД = ЗАПРОС ДОКУМЕНТАЦИИ

@ВХОД = ДЕТАЛИ КЛИЕНТА

@ВЫХОД = ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ

@СПЕЦПРОЦ 1.3.1 ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА

По получении ЗАПРОСА ДОКУМЕНТАЦИИ выдать ОБРАБОТАННУЮ ДОКУМЕНТАЦИЮ, содержащую ДЕТАЛИ КЛИЕНТА, КОМПЬЮТЕРУ БАНКА

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.1

  1.  Спецификация процесса 1.3.2.

@ВХОД = ДАННЫЕ ПО БАЛАНСУ

@ВХОД = ЗАПРОС БАЛАНСА

@ВХОД = ДЕТАЛИ КЛИЕНТА

@ВЫХОД = ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА

@ВЫХОД = ВЫПИСКА ПО БАЛАНСУ

@СПЕЦПРОЦ 1.3.2 РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА

По получении ЗАПРОСА БАЛАНСА выдать ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА

Затем выдать ВЫПИСКУ ПО БАЛАНСУ, содержащую ДАННЫЕ ПО БАЛАНСУ

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3 2

  1.  Спецификация процесса 1.3.3.

@ВХОД = ДЕНЕЖНАЯ СУММА

@ВХОД = ЗАПРОС ДЕНЕГ

@ВХОД = ДЕТАЛИ КЛИЕНТА

@ВЫХОД = ДЕНЬГИ

@ВЫХОД = ВЫПИСКА О ДЕНЬГАХ

@ВЫХОД = ДЕНЕЖНАЯ СУММА

@СПЕЦПРОЦ 1.3.3 ПРИГОТОВИТЬ ДЕНЬГИ ДЛЯ КЛИЕНТА

По  получении  ЗАПРОСА  ДЕНЕГ  выдать  ДЕНЬГИ  по  значению ДЕНЕЖНОЙ СУММЫ

Выдать ВЫПИСКУ О ДЕНЬГАХ, содержащую ДЕНЕЖНУЮ СУММУ

Передать КОМПЬЮТЕРУ БАНКА информацию о ДЕНЕЖНОЙ СУММЕ

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.3

  1.  Спецификация процесса 1.3.4.

@ВХОД = ДАННЫЕ ПО СЧЕТУ

@ВХОД = ЗАПРОС НА ОПЕРАЦИЮ

@ВХОД = ДЕТАЛИ КЛИЕНТА

@ВЫХОД = ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА

@ВЫХОД = ВЫПИСКА ПО ОПЕРАЦИИ

@СПЕЦПРОЦ 1.3.4 РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА

получении ЗАПРОСА НА ОПЕРАЦИЮ выдать ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА для

специфицирования  ДЕТАЛЕЙ  КЛИЕНТА,  чтобы  получить  текущие

ДАННЫЕ ПО СЧЕТУ

Выдать ВЫПИСКУ ПО ОПЕРАЦИИ, содержащую ДАННЫЕ ПО СЧЕТУ

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.4

4) Спецификация процесса 1.4.

@ВХОД = УДАЛЕННАЯ КРЕДИТНАЯ КАРТА

@ВХОДВЫХОД = КРЕДИТНАЯ КАРТА

@ВЫХОД = ДАННЫЕ КРЕДИТНОЙ КАРТЫ

@ВЫХОД = ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА

@СПЕЦПРОЦ 1.4 ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ

ВЫПОЛНИТЬ считать КРЕДИТНУЮ КАРТУ

записать в хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ

выдать управляющий поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА

по получении управляющего потока УДАЛЕННАЯ КРЕДИТНАЯ КАРТА

удалить

КРЕДИТНУЮ КАРТУ

@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.4

ГЛАВА 5. ДИАГРАММЫ «СУЩНОСТЬ-СВЯЗЬ»

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

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

5.1. Сущности, отношения и связи в нотации Чена

СУЩНОСТЬ представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

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

• обеспечение, хранения информации в единственном месте (даже если она используется в различных комбинациях);

• использование этой информации различными приложениями. Символы ERD, соответствующие сущностям и отношениям, приведены на рис. 5.1.

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

Рис. 5.1. Символы ERD в нотации Чена

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

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

ЗНАЧЕНИЕ связи характеризует ее тип и, как правило, выбирается из следующего множества:

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

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

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

На рис.5.2 приведена диаграмма "сущность-связь", демонстрирующая отношения между объектами банковской системы (см. п.2.5). Согласно этой диаграмме каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ ровно один зависимый от нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ.

Рис 5.2. ER-диаграмма в нотации Чена.

Рис. 5.3. Диаграмма атрибутов.

5.2. Диаграммы атрибутов

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

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

Пример диаграммы атрибутов, детализирующей сущность КРЕДИТНАЯ КАРТА (см. рис.5.2) приведен на рис. 5.3.

5.3. Категоризация сущностей

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

Для демонстрации декомпозиции сущности на категории используются диаграммы категоризации. Такая диаграмма содержит общую сущность, две и более сущности-категории и специальный узел-дискриминатор, который описывает способы декомпозиции сущностей (см. рис. 5.4).

Рис. 5.4. Диаграмма категоризации

Существуют 4 возможных типа дискриминатора (рис.5.5):

  1.  Полное и обязательное вхождение Е/М (exclusive/mandatory) – сущность должна быть одной и только одной из следуемых категорий. Для примера на рис. 5.4 это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК.
  2.  Полное и необязательное вхождение Е/О (exclusive/optional) – сущность может быть одной и только одной из следуемых категорий. Это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК, или преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

Неполное и обязательное вхождение I/M (inclusive/mandatory) – сущность должна быть по крайней мере одной из следуемых категорий. Это предполагает в дополнение к 1) задавать следующую ситуацию:
ПРЕПОДАВАТЕЛЕМ является одновременно и ФИЗИК и ХИМИК

Неполное и необязательное вхождение I/O (inclusive/optional) – сущность может быть по крайней мере одной из следуемых категорий. В дополнение к 2) ПРЕПОДАВАТЕЛ является преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

Рис 5.5. Типы дискриминаторов.

5.4. Нотация Баркера

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

В нотации Баркера используется только один тип диаграмм – ERD. Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак "#" перед именем атрибута).

Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи – в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной – пунктирная линия. На рис. 5.6 приведен фрагмент ERD для банковской задачи в нотации Баркера.

Рис. 5.6. Нотация Баркера.

Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова "должен (быть)" или "может (быть)". Так, диаграмма, приведенная на рис. 5.6, читается следующим образом:

Каждый  КЛИЕНТ  может  ВЛАДЕТЬ  одной  или  более КРЕДИТНОЙ КАРТОЙ или

Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ.

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

5.5. Построение модели

Разработка ERD включает следующие основные этапы:

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

Этап 1 является определяющим при построении модели, его исходной информацией служит содержимое хранилищ данных, определяемое входящими и выходящими в/из него потоками данных. На рис. 5.7 приведен фрагмент диаграммы потоков данных, моделирующей деятельность бухгалтерии предприятия. Его единственное хранилище ДАННЫЕ О ПЕРСОНАЛЕ должно содержать информацию о всех сотрудниках: их имена, адреса, должности, оклады и т.п.

Рис. 5.7. Деятельность бухгалтерии

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

ВХОДНЫЕ СТРУКТУРЫ ВЫХОДНЫЕ СТРУКТУРЫ

ДАННЫХ ДАННЫХ

вновь _нанятые адрес _служащего

дата найма фамилия

фамилия адрес

таб_номер

адрес подробности_з/пл

должность фамилия

начальная_з/пл таб_помер

текущая_з/пл

уволенные

фамилия история _занятости

таб_номер фамилия

таб_номер

изменение адреса дата_найма

фамилия история_каръеры *

таб_номер должность

старый адрес дата_изменения

новый_адрес история_з/пл *

з/пл

изменение _з/пл

фамилия таб_номер

старая з/т

новая з/пл

дата изменения

Сравнивая входные и выходные структуры, отметим следующие моменты:

  1.  Поле АДРЕС хранит текущий адрес сотрудника, а структура ИЗМЕНЕНИЕ АДРЕСА хранит и старый адрес, что не является необходимым, исходя из выходных потоков.
  2.  ИСТОРИЯ 3/ПЛ, наоборот, требует перечень всех окладов сотрудника, поэтому необходимо иметь набор, состоящий из пар (3/ПЛ, ДАТА), а не просто СТАРАЯ 3/ПЛ и НОВАЯ 3/ПЛ (как во входном потоке).
  3.  Аналогичная ситуация и с ИСТОРИЕЙ КАРЬЕРЫ. Отметим что на диаграмме вообще отсутствует поток, определяющий изменения в должности, то есть обнаружено серьезное упущение в функциональной модели!
  4.  Отметим, что изменение в ДОЛЖНОСТИ обычно (но не всегда) соответствует изменению в 3/ПЛ.

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

фамилия

таб_номер

адрес

текущая_з/пл

дата_найма

история_карьеры *

должность

дата_изменения

исторш_з/пл *

з/пл

дата_изменения

На следующем шаге осуществляется упрощение схемы за счет устранения избыточности. Действительно, ТЕКУЩАЯ_3/ПЛ всегда является последней записью в ИСТОРИИ_3/ПЛ, а ДАТА_НАЙМА содержится в разделах ИСТОРИЯ_3/ПЛ и ИСТОРИЯ_КАРЬЕРЫ. Кроме того, несколько дат в последних разделах одни и те же, поэтому целесообразно создать на их основе структуру ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ и вводить в нее данные при изменении ДОЛЖНОСТИ и/или З/ПЛ.

фамилия

тпаб_номер

адрес

история_з/пл_карьеры *

з/пл

должность

дата_изменения

Следующий шаг – упрощение схемы при помощи нормализации (удаления повторяющихся групп). Единственным способом нормализации является расщепление данной схемы на две, являющиеся более простыми. Первая схема содержит ФАМИЛИЮ и АДРЕС (которые, как правило, не меняются), вторая – каждое изменение З/ПЛ и ДОЛЖНОСТИ. Кроме того, каждая схема должна содержать ТАБ_НОМЕР – единственный элемент данных, уникально идентифицирующий каждого сотрудника.

Для идентификации сущностей осталось определить ключевые атрибуты. Для первой схемы ключевым атрибутом является ТАБ_НОМЕР, для второй – ключом является конкатенация атрибутов ТАБ_НОМЕР и ДАТА_ИЗМЕНЕНИЯ (рис.5.8), т.к. для каждого сотрудника возможно несколько записей в схеме ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ.

Рис. 5.8. Сущности модели

Концепции и методы нормализации были разработаны Коддом (Codd), установившим существование трех типов нормализованных схем. названных в порядке уменьшения сложности первой, второй и третьей нормальной формой (соответственно, 1НФ, 2НФ и ЗНФ). Рассмотрим, как преобразовывать схемы к наиболее простой ЗНФ. При этом будем представлять схемы в общепринятом виде, например, для сущностей, приведенных на рис.5.8, имеем:

история_з/пл_карьеры(таб_номер.дата_изменения, должность, з/пл)

сотрудник(таб_номер. фамилия, адрес)

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

заказ_на_книгу(имя_заказчика, дата_заказа, ISBN, название, автор,

количество, цена, сумма_заказа)

Согласно Кодду, любая нормализованная схема (схема без повторяющихся групп) автоматически находится в 1НФ независимо от того, насколько сложен ее ключ и какая взаимосвязь может существовать между ее элементами.

Отметим, что в последней схеме атрибуты НАЗВАНИЕ, АВТОР, ЦЕНА могут быть идентифицированы частью ключа (а именно, ISBN), тогда как атрибут КОЛИЧЕСТВО зависит от всего ключа (соответственно, полная и частичная функциональная зависимость от ключа). По определению схема находится в 2НФ если все ее неключевые атрибуты полностью функционально зависят от ключа. После избавления от частичной функциональной зависимости последняя схема будет выглядеть следующим образом:

заказ_на_книгу  (имя заказчика,  датазаказа.  ISBN,  количество,

сумма_заказа)

книга (ISBN, автор, название, цена)

Заметим, что возможно упростить ситуацию и дальше: атрибуты КОЛИЧЕСТВО и СУММА_ЗАКАЗА являются взаимно-зависимыми. По определению схема находится в ЗНФ если она находится в 2НФ и никакой из неключевых атрибутов не является зависимым ни от какого другого неключевого атрибута. Поскольку в нашем примере атрибут СУММА_ЗАКАЗА фактически является избыточным, для получения ЗНФ его можно просто удалить.

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

сотрудник (таб_номер. телефон, почасовая_оплата, N_npoeктa, дата_окончания)

Очевидно, что данная схема находится в 2НФ. Однако N ПРОЕКТА и ДАТА_ОКОНЧАНИЯ являются зависимыми атрибутами. После расщепления схемы получим ЗНФ:

участник_проекта (таб_номер.     телефон,     почасовая_оплата, №_проекта)

проект(№ проекта, дата_окончания)

На практике отношения 1НФ и 2НФ имеют тенденцию возникать при попытке описать несколько реальных сущностей в одной схеме (заказ и книга, проект и сотрудник). 3НФ является наиболее простым способом представления данных, отражающим здравый смысл. Построив 3НФ, мы фактически выделяем базовые сущности предметной области.

В заключание зафиксируем алгоритм приведения ненормализованных схем в третью нормальную форму (рис. 5.9).

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На данном этапе некоторые отношения могут быть неспецифическими (n*m – многие-ко-многим). Такие отношения потребуют дальнейшей детализации на этапе 3.

Определение отношений включает выявление связей, для этого отношение должно быть проверено в обоих направлениях следующим образом: выбирается экземпляр одной из сущностей и определяется, сколько различных экземпляров второй сущности может быть с ним связано, и наоборот. Для примера на рис. 5.8 рассмотрим отношение между сущностями СОТРУДНИК и ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ. У отдельного сотрудника должность и/или зарплата может меняться ноль, один или много раз, порождая соответствующее число экземпляров сущности ИСТОРИЯ_3/ПЛ'КАРЬЕРЫ. Анализируя в другом направлении, видим, что каждый экземпляр сущности ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ соответствует ровно одному конкретному сотруднику. Поэтому между этими двумя сущностями имеется отношение типа 1*n (один ко многим) со связью "один" на конце отношения у сущности СОТРУДНИК и со связью "ноль, один или много" на конце у сущности ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ.

Рис. 5.9. Алгоритм приведения в ЗНФ

Этап 3 предназначен для разрешения неспецифических (многие ко многим) отношений. Для этого каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых (а именно, ассоциативных) сущностей. Рассмотрим пример на рис. 5.10.

Неспецифическое отношение на рис 5.10 указывает, что СТУДЕНТ может изучать много ПРЕДМЕТОВ, а ПРЕДМЕТ может изучаться многими СТУДЕНТАМИ. Однако мы не можем определить, какой СТУДЕНТ изучает какой ПРЕДМЕТ, пока не введем для разрешения этого неспецифического    отношения    третью    (ассоциативную)    сущность

ИЗУЧЕНИЕ_ПРЕДМЕТА. Каждый экземпляр введенной сущности связан с одним СТУДЕНТОМ и с одним ПРЕДМЕТОМ.

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

Рис. 5.10 Разрешение неспецифического отношения

ГЛАВА 6. СПЕЦИФИКАЦИИ УПРАВЛЕНИЯ

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

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

STD состоит из следующих объектов:

СОСТОЯНИЕ – может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.

НАЧАЛЬНОЕ СОСТОЯНИЕ – узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.

ПЕРЕХОД определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, СЧЕТЧИК=999 или КНОПКА НАЖАТА). Следует отметить, что, вообще говоря, не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.

Таким образом УСЛОВИЕ представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, "ПАРОЛЬ"=666, где ПАРОЛЬ – входной поток.

Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. То есть ДЕЙСТВИЕэто операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока, то имя этого потока должно заключаться в кавычки, например:

"ВВЕДЕННАЯ КАРТА" = TRUE,

где ВВЕДЕННАЯ КАРТА – выходной поток.

Кроме того, для спецификации А-, Т-, E/D-потоков имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:

А: "ПОЛУЧИТЬ ПАРОЛЬ" – активировать процесс ПОЛУЧИТЬ ПАРОЛЬ.

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

На STD состояния представляются узлами, а переходы – дугами (рис. 6.1).

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

Диаграмма переходов состояний для примера банковской задачи приведена на рис. 6.2. Она содержит два состояния – ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты (ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА). При этом выполняется действие по запуску процесса 1.1 на рис. 2.8 (ПОЛУЧИТЬ ПАРОЛЬ). Отметим, что для запуска используется А-поток, обеспечивающий непрерывность процесса 1.1, т.е. возможность повторного ввода пароля.

Рис. 6.1 Символы STD

Переход из состояния ОБРАБОТКА в состояние ОЖИДАНИЕ осуществляется двумя различными способами. При условии трехкратного ввода неверного пароля (см. спецификацию процесса 1.1) кредитная карта удаляется из системы, при этом она переходит в режим ожидания очередного клиента. При условии КОРРЕКТНЫЙ ПАРОЛЬ выполняются действия по обеспечению требуемого сервиса (последовательное включение процессов 1.2 и 1.3) и удалению кредитной карты, и затем переход в режим ожидания очередного клиента.

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

• строить STD на как можно более высоком уровне детализации DFD;

• строить как можно более простые STD;

• по возможности детализировать STD;

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

Рис. 6.2. STD для банковской задачи

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

• все ли состояния определены и имеют уникальное имя?

• все ли состояния достижимы?

• все ли состояния имеют выход?

• (для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?

• все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD?

Таблица 6.1.

ТЕКУЩЕЕ СОСТОЯНИЕ

УСЛОВИЕ

ДЕЙСТВИЕ

СЛЕДУЮЩЕЕ

СОСТОЯНИЕ

начальное состояние

активируется каждый раз

-

ОЖИДАНИе

ОЖИДАНИЕ

введенная кред. карта

получить пароль

ОБРАБОТКА

ОБРАБОТКА

некорректный пароль

удалить кред. карт

ОЖИДАНИЕ

ОБРАБОТКА

корректный пароль

обеспечить, треб.сервис удалить кред. карт

ожидание

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

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

ГЛАВА 7. СРЕДСТВА СТРУКТУРНОГО ПРОЕКТИРОВАНИЯ

В предыдущих главах были рассмотрены средства структурного системного анализа, применение которых позволяет построить модель требований (или логическую модель) системы, состоящую из множества взаимоувязанных диаграмм, текстов и словаря данных. Используемые на этом этапе диаграммные техники включают DFD, ERD, STD и спецификации процессов. Модель требований описывает, что должна делать проектируемая система без ссылок на то, как это достигается.

Проектирование – фаза ЖЦ, на которой вырабатывается, как реализуются требования пользователя, которые порождены и зафиксированы на фазе анализа. На этом этапе осуществляется построение модели реализации (или физической модели), демонстрирующей, как система будет удовлетворять предъявленным к ней требованиями (без технических подробностей). Модель реализации является расширением модели требований и состоит из взаимоувязанных диаграмм (DFD, STD, ERD, структурные карты), текстов и словаря данных. Фактически структурное проектирование является мостом между структурным анализом и реализацией.

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

7.1. Структурные карты Константайна

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

  1.  модуль состоит из множества операторов языка программирования, записанных последовательно;
  2.  модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту;
  3.  модуль может принимать и/или передавать данные как параметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.

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

Фундаментальные элементы структурных карт в соответствии со стандартами IBM, ISO и ANSI приведены на рис. 7.1.  

Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей (см. рис. 7.2):

  1.  Собственно МОДУЛЬ. Используется для представления обрабатывающего фрагмента для его локализации на диаграмме.
  2.  ПОДСИСТЕМА: Ранее определенный модуль, детализированный посредством декомпозиции ранее определенных диаграмм. Может повторно использоваться любое число раз на любых структурных картах.
  3.  БИБЛИОТЕКА. Отличается от подсистемы тем, что определена вне проекта данной системы.
  4.  ОБЛАСТЬ ДАННЫХ. Используется для указания модулей, содержащих исключительно области глобальных/распределенных данных.

При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использованием потоков, демонстрирующих иерархию вызовов. Типы используемых при этом потоков приведены на рис. 7.3. При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно (параллельно).

Для моделирования условных и циклических вызовов применяются следующие узлы (рис. 7.4):

Условный узел используется для условного вызова модуля-потомка. Он изображается с помощью ромба, потоки – альтернативные вызовы изображаются выходящими из него. Таким образом, если из ромба выходят два потока, это соответствует конструкции IF-THEN-ELSE, если один поток – конструкции IF-THEN.

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

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

Рис. 7.1. Элементы структурных карт

Рис.7.3. Типы вызовов модулей

Рис. 7.4. Условные и циклические вызовы модулей

Связи по данным и управлению между модулями (передаваемые как параметры) раскрываются аннотированием потоков-вызовов (рис. 7.5). Стрелками отмечаются направления связей.

Рис.7.5. Связи по данным и управлению

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

Рис 7.6. Пример структурной карты Константайна

7.2. Структурные карты Джексона

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

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

  1.  СТРУКТУРНЫЙ блок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.
  2.  ПРОЦЕДУРНЫЙ блок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.
  3.  БИБЛИОТЕЧНЫЙ блок аналогичен процедурному и представляет вызов библиотечного модуля.

Для взаимоувязывания блоков используются связи следующих типов:

последовательная связь, обеспечивающая последовательное выполнение слева направо;

параллельная связь, обеспечивающая одновременное выполнение блоков;

условная связь, обеспечивающая выбор одной из альтернатив;

итерационная связь, обеспечивающая выполнение блока в цикле.

Пример структурной карты Джексона приведен на рис. 7.7.

7.3. Характеристики хорошей модели реализации

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

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

Рис 7.7. Структурная карта Джексона

7.3.1. Сцепление

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

• уменьшение количества соединений между двумя модулями приводит к уменьшению вероятности появления "волнового эффекта" (ошибка в одном модуле влияет на работу других модулей);

• минимизация риска появления "эффекта ряби" (внесение изменений, например при исправлении ошибки, приводит к появлению новых ошибок), т.к. изменение влияет на минимальное количество модулей;

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

• упрощение системы для понимания, насколько это возможно.

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

• удаления необязательных связей;

• уменьшения количества необходимых связей;

• упрощения необходимых связей.

Специалистами предлагаются следующие практические рекомендации для ослабления сцепления модулей:

  1.  Создавайте минимальные по количеству параметров межмодульные связи.
  2.  Создавайте прямые (а не косвенные) межмодульные связи, поскольку интерфейс между двумя модулями наиболее понятен (и, следовательно, менее сложен), если человек может постигнуть его сразу без предварительной ссылки к некоторым другим информационным объектам.
  3.  Создавайте локализованные связи (например, значения списка параметров вычисляйте непосредственно перед вызовом модуля).
  4.  Создавайте явные связи. Красноречивым примером неявной связи является взаимодействие модуля А с модулем В за счет модификации области данных из В: для того, чтобы человек, сопровождающий модуль В понял, за счет чего модифицируется эта область данных, он будет должен проделать огромную работу.

Создавайте гибкие связи для облегчения модификаций.

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

Два модуля А и В являются нормально сцепленными, если

• А вызывает В,

• В возвращает управление А,

• вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

Существует три типа нормального сцепления: сцепление по данным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используемым типом сцепления является сцепление по данным (data coupling). Два модуля сцеплены по данным, если они взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. В случае небольшого количества передаваемых параметров сцепление по данным обладает наилучшими характеристиками в соответствии с п.п.1-5.

Два модуля сцеплены по образцу (stamp coupling), если один посылает другому составной информационный объект, т.е. объект, имеющий внутреннюю структуру. Примером составного объекта может быть объект Данные о клиенте, включающий в себе поля: Название организации, Почтовый адрес, Номер счета и т.п..

Два модуля сцеплены по управлению (control coupling), если один посылает другому информационный объект – флаг, предназначенный для управления его внутренней логикой. Существует два типа флагов – описательный и управляющий. Описательный флаг обычно описывает ситуацию, которая произошла, и именуются с использованием существительных и прилагательных: Конец файла, Введенная кредитная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с использованием глаголов: Читать следующую запись, Установить в начало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

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

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

Таблица 7.1

Тип сцепления

Устойчивость к волновому эффекту

Модифицируемость

Понятность

Используемость в других системах

data coupling

*

хорошая

хорошая

хорошая

stamp coupling

*

средняя

средняя

средняя

control coupling

средняя

плохая

плохая

плохая

common coupling

плохая

средняя

плохая

плохая

content coupling

плохая

плохая

плохая

плохая

• Зависит от количества параметров интерфейса.

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

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

7.3.2. Связность

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

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

Функционально связный модуль содержит объекты, предназначенные для выполнения одной и только одной задачи, например: Расчет заработанной таты. Считывание данных кредитной карты. Каждый из этих модулей имеет одну четко определенную цель, при его вызове выполняется только одна задача (при этом она выполняется полностью без исполнения любого другого дополнительного действия).

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

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

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

  1.  Сделать зарядку
  2.  Принять душ
  3.  Сварить кофе
  4.  Одеться
  5.  Отправиться на службу

Отправиться на службу – это последний шаг, внесенный в список этого "модуля". Но, например, действия Прочитать газету или Сходить в магазин могут быть в равной степени пригодными кандидатами для шага 5, поскольку шаги в этом списке связаны только тем, что они происходят в данном порядке в течение конкретного дня.

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

1. Почистить зубы

2. Выключить телевизор

3. Выгнать кота в коридор

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

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

1. Поехать автомобилем

2. Поехать поездом

  1.  Поплыть на корабле
  2.  Полететь на самолете

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

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

Случайно связным является модуль, объекты которого соответствуют подзадачам, незначительно связанным друг с другом:

1.Ремонтировать автомобиль

  1.  Пить пиво
  2.  Смотреть фильм

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

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

Таблица 7.2

Уровень связности

Сцепление

Модифицируемость

Понятность

Сопровождаемость

функциональная

хорошее

хорошая

хорошая

хорошая

последовательная

хорошее

хорошая

близкая к хорошей

хорошая

информационная

среднее

средняя

средняя

средняя

процедурная

переменная

переменная

переменная

плохая

временная

плохое

средняя

средняя

плохая

логическая

плохое

плохая

плохая

плохая

случайная

плохое

плохая

плохая

плохая

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

7.3.3. Другие принципы проектирования

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

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

• чтобы уменьшить размеры модуля;

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

• чтобы избегать дублирования подзадачи, выполняемой более чем одним модулем;

• чтобы отделить собственно вычисления от управления (вызовы и принятия решения);

• чтобы обеспечить более широкую пригодность модулей для их использования в различных частях системы:

• чтобы упростить реализацию.

  1.  Принцип единства решения. Процесс любого решения состоит из двух частей: распознавания того, какое действие выбрать, и исполнения этого действия. Поскольку эти две составляющие решения очень различны, информационные объекты, используемые при распознавании и исполнении также могут существенно различаться и, следовательно, могут быть недоступными в одном модуле. Такая ситуация получила название расщепления решения (decision split). Сильное расщепление решения
    (хотя иногда расщепления не удается избежать) обычно является симптомом плохой организации модулей. Исполнительная часть решения должна располагаться как можно ближе к распознавательной части, чтобы распознанной информации не пришлось долго "блуждать" для того, чтобы быть
    обработанной.
  2.  Обработка ошибок. Сообщения об ошибках целесообразно формировать и визуализировать в модуле, который ошибку обнаруживает (и, следовательно, "знает'", что это за ошибка). Тексты сообщений рекомендуется хранить вместе по следующим резонам:

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

• Появляется возможность хранить тексты сообщений в отдельном файле, а не внутри кода модуля.

• Легче избежать дублирования сообщений.

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

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

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

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

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

• Он включает в себя условия о месте и способе его использования.

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

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

• Он имеет дело с слишком избыточными типами данных, их значениями и структурами. Например, использование числа типа REAL вместо INTEGER для того, чтобы следить за количеством болтов на складе, было бы чрезмерным обобщением.

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

  1.  Принцип минимизации избыточности. Если любой факт, условие или реализационное решение явно проявляются в более чем одном модуле, то усилия по сопровождению, состоящие из нахождения всех случаев этого факта и их изменения, увеличиваются. Также возникает опасность того, что человек, сопровождающий такую систему, забудет изменить один из дублей.
  2.  Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается количество непосредственных вызывающих его модулей. Соответственно, нагрузка модуля по выходу – это количество непосредственно подчиненных ему модулей. По уже упоминавшимся выше причинам нагрузка по выходу не должна превышать 6-7 модулей. Высокая нагрузка по входу требует от модуля хорошей связности.

7.4. Транзакционный и трансформационный анализ или как получить структурные карты из диаграмм потоков данных

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

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

• конвертирование каждой единицы в ''хорошую" структурную карту средствами трансформационного анализа;

• обратное соединение разделенных единиц в полную модель реализации.

Определим транзакцию как объект, содержащий следующие пяль компонент:

СОБЫТИЕ в системе или ее внешнем окружении

СИГНАЛ к системе

ДЕЙСТВИЕ системы

ОТКЛИК от системы

ВЛИЯНИЕ на систему или ее окружение

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

СОБЫТИЕ Диспетчер замечает, что корабль движется слишком быстро

СИГНАЛ Замедлить скорость корабля на 210 м/сек

ДЕЙСТВИЕ Определить, какой из тормозных ракетных двигателей включить и на какое время

ОТКЛИК Сигнал тормозному двигателю ракеты для его включения на 4.8 сек

ВЛИЯНИЕ Корабль замедлил скорость на 210 м/сек

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

СОБЫТИЕ Владелец дачи Сергей Чечении устал пилить и колоть дрова для камина и решил установить газовое отопление

СИГНАЛ Информация о г-не Чеченине и его даче, а также дата начала обслуживания

ДЕЙСТВИЕ Добавить данные о г-не Чеченине в базу данных клиентов

ОТКЛИК Разрешение на предоставление услуг

ВЛИЯНИЕ В освободившееся от дровяных работ время г-н Чеченин проектирует систему автоматизации газовой компании

Отметим, что подобные отдельные транзакции относятся к классам, определяемым как классы транзакционного типа. Например, три транзакции "ДОБАВИТЬ ЧЕЧЕНИНА", "ДОБАВИТЬ ИВАНОВА" и "ДОБАВИТЬ ПЕТРОВА" являются примерами одного транзакционного типа, который может быть назван "ДОБАВИТЬ НОВОГО КЛИЕНТА".

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

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

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

• выявление центрального преобразования – фрагмента DFD, который содержит концептуальные функции системы и не зависит от особенностей реализации системных входов и выходов;

• конвертирование DFD в предварительную структурную карту;

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

• проверка окончательной структурной карты на соответствие требованиям первоначальной DFD.

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

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

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

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

• Добавить модули обработки ошибок.

• Добавить детали инициализации и завершения, если требуется.

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

• Добавить все связи по данным и управлению, которые являются необходимыми на структурной схеме, но не на DFD, например, информация "Конец потока".

• Проверить все критерии структурного проектирования и улучшить проект в соответствии с этими критериями.

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

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

ЧАСТЬ 2. МЕТОДОЛОГИИ СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

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

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

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

В гл. 9 приведены основные принципы, возможности и особенности наиболее часто используемых методологий структурного системного анализа и проектирования (Йодан/ДеМарко, Гейн-Сарсон, SADT, Джексон, Варнье-Орр, Мартин), предложен сравнительный анализ наиболее часто применяемых методологий.

Глава 10 кратко описывает архитектуру современной системы и ее влияние на изменения в методологиях анализа и проектирования.

ГЛАВА 8. КЛАССИФИКАЦИЯ СТРУКТУРНЫХ МЕТОДОЛОГИЙ

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

В настоящее время успешно используются практически все известные методологии структурного анализа и проектирования, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана/Де Марко (Yourdon/DeMarko), развития систем Джексона (Jackson), развития структурных систем Варнье-Орра (Warnier-Orr), анализа и проектирования систем реального времени Уорда-Меллора (Ward-Mellor) и Хатли (Hatley), информационного моделирования Мартина (Martin).

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

  1.  разделение проекта на 10-50 модулей;
  2.  организация иерархии модулей;
  3.  определение маршрутов данных между модулями;
  4.  определение форматов внешних файлов;
  5.  определение способов доступа к внешним файлам;
  6.  определение структур данных;
  7.  проектирование ключевых алгоритмов;
  8.  определение подпрограмм внутри каждого модуля.

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

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

диаграммы потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем;

расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах и деревьях решений, картах и схемах потоков управления;

диаграммы "сущность-связь" (в нотации Чена или Баркера) или скобочные диаграммы Варнье-Орра для проектирования структур данных, схем БД, форматов файлов как части всего проекта;

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

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

по отношению к школамSoftware Engineering (SEi) и Information Engineering (IE);

по порядку построения модели – процедурно-ориентированные, ориентированные на данные и информационно-ориентированные:

по типу целевых систем – для систем реального времени (СРВ) и для
информационных систем (ИС).

SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем. IE – более новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны. IE – более узкая дисциплина, чем SE. т.к. IE используется только для построения информационных систем, a SE – для всех типов систем.

Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных.

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

Таблица 8.2 классифицирует наиболее часто используемые методологии в соответствии с вышеперечисленными признаками (данные по частоте использования получены на основе анализа информации по 127 CASE-пакетам).

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

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

Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.

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

Таблица 8.1

Информационные системы

Системы реального времени

Управляемы данными

Управляемы событиями

Сложные структуры данных

Простые структуры данных

Большой объем входных данных

Малое количество входных данных

Интенсивный ввод/вывод

Интенсивные вычисления

Машинная независимость

Машинная зависимость

Таблица 8.2

Название

Частота использования, %

Школа

Порядок построения

Тип целевых систем

Йодан-

Де Марко

36.5

SE

процедурно-ориентированная

ИС, СРВ

Гейн-Сарсон

20.2

SE

процедурно-ориентированная

ИС. СРВ

Констан-тайн

10.6

SE

процедурно-ориентированная

ИС. СРВ

Джексон

7-7

SE

ориентированная на данные

ИС. СРВ

Варнье-Орр

5.8

SE

ориентированная на данные

ИС

Мартин

22,1

IE

информационно-ориентированная

ИС

SADT

3.3

IE

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

2)ориентированная на данные

ИС

Stradis

1.9

IE

процедурно-ориентированная

ИС

Таблица 8.3

Название

Процедуры

Данные

1. Средства анализа

- диаграммы потоков данных

+

- диаграммы потоков управления

+

- таблицы, деревья решений

+

- матрицы

+

+

- диаграммы зависимости

+

- диаграммы декомпозиции

+

- SADT- диаграммы

+

+

2. Средства проектирования

- структурные карты

+

- диаграммы деятельности

+

- диаграммы Варнье-Орра

+

+

- диаграммы переходов состоянии

+

- языки проектирования спец-ий

+

- блок-схемы

+

- схемы экранов

+

- диаграммы "сушность-связь"

+

ГЛАВА 9. ПРИМЕРЫ СТРУКТУРНЫХ МЕТОДОЛОГИЙ

9.1. Методологии структурного анализа Йодана/Де Марко и Гейна-Сарсона

Как уже неоднократно отмечалось, структурный анализ – это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методологии Гейна-Сарсона и Йодана/Де Mapко, основанные на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход.

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

  1.  DFD – диаграммы потоков данных. Являются графическими иерархическими спецификациями, описывающими систему с позиций потоков данных. В состав DFD могут входить четыре графических символа, представляющих потоки данных, процессы преобразования входных потоков данных в выходные, внешние источники и получатели данных, а также файлы и БД, требуемые процессами для своих операций.
  2.  Словари данных. Являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты.
  3.  Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификации является полной спецификацией системы. Миниспецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, собственно и являющееся спецификацией алгоритма или операции,
    трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа
    FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.

DFD-диаграммы являются ключевой частью документа спецификации требований. Каждый узел – процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей (отметим, что структурные методологии, ориентированные на потоки управления, не обладают этим свойством). Проектные спецификации строятся по DFD и их миниспецификациям автоматически. Наиболее часто для описания проектных спецификаций используется методика структурных карт Джексона, иллюстрирующая иерархию модулей, связи между ними и некоторую информацию об их исполнении (последовательность вызовов, итерацию). Существует ряд методов автоматического преобразования DFD в структурные карты: один из таких методов, а также реализующий его алгоритм приводится Фишером в его обзорной книге по CASE-технологиям [Fisher 1988].

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

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

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

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

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

Рис. 9.1. Пример диаграммы Гейна-Сарсона 

9.2. SADT – технология структурного анализа и проектирования

SADT (Structured Analysis and Design Technique) – одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается Министерством обороны США. которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.

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

Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в диаграмме было 3-6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Однако такое жесткое требование на число блоков на диаграмме ограничивает применение SADT для ряда предметных областей. Например, в банковских структурах имеется 15-20 равноправных деятельностей, которые целесообразно отразить на одной диаграмме. Искусственное их растаскивание по разным уровням SADT-модели явно не улучшает ее понимаемость.

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

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

Рис. 9.2. Пример SADT-блока

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

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

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

Дуги SADT, как правило, изображают наборы предметов, поэтому они могут разветвляться и соединяться вместе различным образом. Разветвления дуги означают, что часть ее содержимого (или весь набор предметов) может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена в соответствии со следующими правилами: считается, что непомеченная ветвь содержит все предметы. указанные в метке перед разветвлением; каждая метка ветви уточняет, что именно содержит эта ветвь. Слияние дуг указывает, что содержимое каждой ветви участвует в формировании после слияния объединенной дуги. После слияния дуга всегда помечается для указания нового набора, кроме того, каждая ветвь перед слиянием может помечаться в соответствии со следующими правилами: считается, что непомеченные ветви содержат Reel предметы, указанные в общей метке после слияния: каждая метка ветви уточняет, что именно содержит эта ветвь.

Рис. 9.3 Пример отношения Выход-Исполнитель

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

Пример SADT-диаграммы, моделирующей деятельность компании, занимающейся распределением товаров по заказам (рис. 9.1), приведен на рис. 9.4.

Рис. 9.4. Пример SADT–диаграмм

SADT. как и другие методологии проектирования, целесообразно использовать на ранних этапах ЖЦ: для понимания системы до ее воплощения. SADT позволяет сократить дорогостоящие ошибки на ранних этапах создания системы, улучшить контакт между пользователями и разработчиками, сгладить переход от анализа к проектированию. Несомненное достоинство SADT заключается в том. что она легко отражает такие характеристики как управление, обратная связь и исполнители.

9.3. Сравнительный анализ SADT-моделей и потоковых моделей

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

• диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями – для этой цели чаще всего используются DFD или SADT (IDEF0);

• диаграммы, моделирующие данные и их взаимосвязи (ERD);

• диаграммы, моделирующие поведение системы (STD).

Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного системного анализа могут быть разбиты на две группы – применяющие методы и технологию DFD (в различных нотациях) и использующие SADT-методологию. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет по материалам CASE Consulting Group 90% для DFD и 10% для SADT. По данным автора, основанным на анализе 127 существующих CASE-пакетов, это соотношение выглядит как 94% к 3%, соответственно. Оставшиеся 3% CASE-средств используют методологии, не относящиеся ни к одной из перечисленных разновидностей. Представляется очевидным, что соотношение такого же порядка справедливо и для цифр распространенности рассматриваемых методологий на практике.

Сравнительный анализ этих двух разновидностей методологий проводится по следующим параметрам:

• адекватность средств рассматриваемой проблеме;

• согласованность с другими средствами структурного анализа;

• интеграция с последующими этапами разработки (и прежде всего с этапом проектирования).

1) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. Предметом бизнес-консалтинга являются организационные системы (точнее, функционирование или деятельность таких систем). Для моделирования таких систем традиционно используется методология SADT (точнее ее подмножество IDEF0). Однако статическая SADT-модель не обеспечивает полного решения задач бизнес-консалтинга, необходимо иметь возможность исследования динамических характеристик бизнес-процессов. Одним из решений является использование методологии и средств динамического моделирования, основанной, например, на цветных (раскрашенных) сетях Петри CPN (Color Petri Nets). Фактически SADT и CPN служат компонентами интегрированной методологии бизнес-консалтинга: SADT-диаграммы автоматически преобразуются в прообраз CPN-модели, которая затем дорабатывается и исполняется в различных режимах, чтобы получить соответствующие оценки.

Следует отметить, что не существует принципиальных ограничений в использовании DFD в качестве средства построения статических моделей деятельностей. Более того, в настоящий момент доступен ряд методологий и продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базирующихся на сетях Петри различного вида и интегрируемых с DFD-моделью, которые позволяют успешно решать задачи бизнес-консалтинга.

Методология SADT успешно работает только для реорганизации хорошо специфицированных и стандартизованных западных бизнес-процессов, поэтому она и принята на Западе в качестве типовой. Например, в Министерстве Обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. В российской действительности с ее слабой типизацией бизнес-процессов, их стихийным появлением и развитием, разумнее ориентироваться на методологию организации и/или реорганизации потоков информации и отношений: для таких задач методологии, основанные на потоковых диаграммах, не просто допустимы, а являются единственно возможными.

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

SADT-диаграммы значительно менее выразительны и удобны для моделирования систем обработки информации (сравните рис. 9.1 и 9.4). Так, дуги в SADT жестко типизированы (вход, выход, управление, исполнитель). В то же время применительно к системам обработки информации стирается смысловое различие между входами-выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и/или управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.

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

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

Ограничения SADT, запрещающие использовать более 5-7 блоков на диаграмме, в ряде случаев вынуждают искусственно детализировать систему, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной картине.

2) Согласованность. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моделирования. Согласование SADT-модели с ERD и/или STD практически невозможно или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели (см. рис. 1.2).

Таблица 8.4 отражает возможность такой интеграции для DFD и SADT-моделей.

Таблица 8.4

Название

ERD

STD

Структурные карты

DFD

+

+

+

SADT

+

-

-

Отметим, что интеграция DFD-STD осуществляется за счет расширения классической DFD специальными средствами проектирования систем реального времени (управляющими процессами, потоками, хранилищами данных), и STD является детализацией управляющего процесса, согласованной по управляющим потокам и хранилищам. Интеграция DFD-ERD осуществляется с использованием отсутствующего в SADT объекта – хранилища данных, структура которого описывается с помощью ERD и согласуется по соответствующим потокам и другим хранилищам на DFD.

3) Интеграция с последующими этапами. Важная характеристика методологии – ее совместимость с последующими этапами применения результатов анализа (и прежде всего с этапом проектирования, непосредственно следующим за анализом и опирающимся на его результаты).

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

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

9.4. Методология SSADM

Примером еще одной методологии, ориентированной на диаграммы потоков данных, является методология SSADM (Structured Systems Analysis and Design Method), созданная в начале 80-х годов и принятая в 1993 году в качестве национального стандарта Великобритании для разработки информационных систем. Ее несомненным достоинством является наличие взаимосогласованных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. В то же время SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы, отсылая разработчика к другим общедоступным методологиям, рекомендуемым британским государственным агентством по информатике и вычислительной технике.

В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.

Согласно SSADM определение системных требований включает следующие шесть основных этапов:

I) Оценка реализуемости. Данный этап предваряет инициацию работ по созданию системы, его основными процессами являются следующие:

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

• предварительная экономическая оценка проекта

• построение план-графика выполнения основных работ

• подготовка документов по оценке возможности создания системы.

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

• определение границ будущей системы

• выявление основных требований

• выявление процессов обработки информации

• выявление обрабатываемых данных

• построение информационно-логической модели требований

• обобщение результатов и подготовка отчетов

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

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

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

6) Физическое проектирование.

• разработка физической информационной модели

• разработка спецификаций к программным компонентам

• оптимизация информационной модели

• уточнение спецификаций к программным компонентам

• оформление документации.

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

• среднее время наработки на отказ

• время отклика

• ограничения доступа

• требования безопасности и т.п.

9.5. Методологии, ориентированные на данные

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

Классическим примером рассматриваемого подхода является структурное проектирование Джексона. Его базовая процедура проектирования предназначена для "простых" программ ("сложная" программа разбивается на "простые" традиционными методами) и включает следующие 4 этапа:

1) Этап проектирования данных.

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

• Представление каждой входной и выходной структуры данных древовидной структурной диаграммой.

2) Этап проектирования программ.

• Формирование  структуры  программы  комбинированием  структур данных.

• Идентификация всех связей между компонентами структур данных.

• Верификация полученной структуры программы.

3) Этап проектирования операций.

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

• Назначение операций компонентам структуры программы.

4) Этап проектирования текстов.

• Трансляция построенной модели программы в текстовый вид с добавлением ряда логических условий для управления выполнением циклов и выбором данных.

Другим примером рассматриваемого подхода является DSSD (Data-Structured Systems Development), предложенная Варнье-Орром и ориентированная на разработку систем со структурными данными методологиям использующая теорию множеств для описания проекта ПО. Также как и в математике, множество определяется перечислением его элементов. Так множество отделов компании может быть описано следующим образом:

компания = {бухгалтерия, маркетинг, производство, распространение}

DSSD использует аналогичную нотацию, а именно множественную скобку (рис. 9.5).

Рис. 9.5. Множественная скобка

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

При построении модели в DSSD используются диаграммы сущностей (диалект DFD) для определения системного контекста и диаграммы Варнье-Орра (assembly-line diagrams) в качестве основного средства моделирования системы. Базовым элементом диаграммы Варнье-Орра является множественная скобка. Детализация элементов данных производится слева-направо, предполагаемая последовательность действий осуществляется слева-направо и сверху-вниз. Такая нотация удобна для представления композиции структур, определения структур данных, спецификации форматов файлов, и может быть использована для иллюстрирования структуры программы и иерархии модулей (заменой структур данных на модули или файлы, а на нижних уровнях – на подпрограммы. DO-циклы, условные и другие операторы), являясь в этом случае неким аналогом визуального языка проектирования типа FLOW-форм. Основные этапы методологии изображены на рис. 9.6 с помощью диаграммы Варнье-Орра.

Рис. 9.6. Диаграмма Варнье-Орра

Диаграмма Варнье-Орра использует 4 базовые конструкции: иерархии, последовательности, повторения и альтернативы. Значительно реже применяются конструкции параллелизма и рекурсии.

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

"Методология содержит в качестве первого этапа – планирование проекта, в качестве второго этапа – определение требований, в качестве третьего этапа – проектирование ...".

Повторение является эквивалентом понятия цикла в классическом программировании и обозначается указанием нижней и верхней гранив количества итераций (рис. 9.7).

Рис. 9.7. Повторение

Альтернатива или выбор отражает традиционный процесс принятия решения и определяет отношение между двумя и более подмножествами множества (рис. 9.8).

Рис. 9.8. Альтернатива

Параллелизм синтаксически отличается от альтернативы заменой символа "@" на символ "+" и используется, когда порядок исполнения не имеет значения. Данная конструкция, как правило, используется при проектировании ПО для моделирования параллельной обработки.

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

Рис. 9.9. Рекурсия

9.6. Основные этапы подхода Мартина

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

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

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

Основные этапы подхода Мартина приведены на рис. 9.10

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

2) На этапе анализа основные бизнес-процессы, разработанные на этапе 1), используются для разбиения общей задачи на частные, при этом основное внимание уделяется определению информационной и функциональной моделей для частных задач. При этом диаграммы "сущность* связь" трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD, диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы "сущность/процесс".

Рис. 9.10. Основные этапы подхода Мартина

  1.  На Этапе логического проектирования IE становится аналогична SE для разработки ПО. Базой для проектирования являются процессы, разработанные на этапе анализа. Используя методики нисходящей функциональной декомпозиции, проектируются спецификации обработки в процессах и их логические структуры данных. При этом используются диаграммы структуры данных (диалект ERD). определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности (вид миниспецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов.
  2.  На этапе физического проектирования и реализации производится преобразование логической модели ИС в физическую и ее реализация.

9.7. Собственные методологии фирм – разработчиков программных систем

Рассмотренные в разд. 9.1-9.6 классические методологии структурного системного анализа и проектирования послужили основой разработок собственных методологий крупных компаний – производителей программного обеспечения. Главной отличительной чертой таких методологий является их ориентация на конкретный инструмент анализа и проектирования, производимый и/или продвигаемый соответствующей компанией. Ниже приводится краткое описание двух таких ориентированных на данные методологий: Custom Development Method (CDM) фирмы ORACLE, ориентированной на пакет Designer/2000, и DATARUN фирмы Computer Systems Advisers, ориентированной на пакет SILVERRUN (краткое описание этих пакетов см. в разд. 17.1).

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

Особенностью CDM является регламентация трех вариантов разработки:

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

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

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

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

Рис. 9.11 Процессы CDM

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

Ориентированная на данные методология DATARUN так же как и CDM опирается на две модели: модель предприятия и модель информационной системы, основанные на ERD и DFD. Основные этапы этой методологии приведены ниже.

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

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

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

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

ГЛАВА 10. АРХИТЕКТУРА СОВРЕМЕННЫХ СИСТЕМ И МЕТОДОЛОГИИ

В центре любой методологии находится некоторая системная архитектура, и лишь затем совокупность стратегий и методов анализа и проектирования. Архитектура современных систем является трехслойной (рис. 10.1) и имеет следующие характеристики:

• четко определенные слои

• формальные и явные интерфейсы между слоями

• скрытые и защищенные детали внутри каждого слоя.

Рис. 10.1 Архитектура современной системы

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

• выполнение требуемых задач

• принятие решений в соответствующей компетенции

• запуск других задач в слое правил бизнеса и других слоях.

Независимость слоев трехслойной   системной   архитектуры обеспечивает следующие основные преимущества:

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

• гибкость интерфейсов пользователя – изменение интерфейсов без влияния на бизнес-процессы и наоборот;

• разделение усилий коллектива разработчиков.

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

• информационная  модель  (и  база  данных)  рассматриваются  как центральные понятия при анализе и проектировании;

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

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

• построенная на ее основе функциональная модель либо является слабо связанной с информационной моделью, либо неадекватно отражает существующие бизнес-процессы и правила;

• сама по себе информационная модель является недостаточной (хотя и важной) для решения задач консалтинга;

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

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

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

В таблице 10.1 представлена трехслойная системная архитектура в разрезе регламентируемых методологией этапов разработки (анализ требований, проектирование, реализация).

Таблица 10.1

Слои

Анализ

Проектирование

Реализация

Документы

Поток работ

Поток форм

Формы

Правила бизнеса

Поток процессов

Модель компонентов

Программы

База данных

Модель данных

Схема базы данных

Таблицы и т.п.

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

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

Реализация. На данном этапе проект преобразуется в систему.

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

ЧАСТЬ 3. ЭТАПЫ РАЗРАБОТКИ КОНСАЛТИНГОВЫХ ПРОЕКТОВ

В третьей части книги рассматривается, как исследованные в гл. 1 -10 методы и средства структурного системного анализа могут быть использованы на ранних этапах разработки систем, т.е. будет намечена методология разработки консалтинговых проектов – общий подход к консалтингу, основанный на структурном анализе и проектировании.

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

Глава 12 посвящена обработке результатов обследования – построению моделей. Приводятся основные характеристики моделей деятельности и системного проекта (модели требований), описываются принципиальные различия моделей.

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

ГЛАВА 11. ПРОВЕДЕНИЕ ОБСЛЕДОВАНИЯ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ

11.1. Цели и основные этапы консалтинга

Основными   целями   разработки   консалтинговых   проектов являются:

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

формирование на основании анализа предложений по реорганизации
организационно-управленческой структуры;

упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

анализ требований и проектирование спецификаций корпоративных  информационных систем;

рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями, прежде всего классов MRP (manufacturing resource planning) и ERP (enterprise resource planning).

Структура подхода к разработке консалтинговых проектов приведена на рис. 11.1.

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

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

• В чем недостатки существующей ситуации?

• Какие улучшения возможны?

• На кого окажет влияние новая система?

Рис. 11.1. Структура подхода

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

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

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

В рамках этапа 2 (проведение обследования деятельности предприятия) осуществляется:

• предварительное выявление требований, предъявляемых к будущей системе;

• определение оргштатной и топологической структур предприятия;

• определение перечня целевых задач (функций) предприятия;

• анализ распределения функций по подразделениям и сотрудникам;

• определение перечня применяемых на предприятии средств автоматизации.

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

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

На этапе 3 (построение моделей деятельности предприятия) осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

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

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

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

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

Отметим, что для построения каждой из требуемых моделей необходима интенсивная работа 6-7 квалифицированных системных аналитиков в течении 2-4 месяцев.

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

• составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

• анализ применимости существующих систем управления предприятиями (прежде всего классов MRP и ERP) для решения требуемых задач и формирование рекомендаций по выбору такой системы;

• совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

• разработка требований к техническим средствам;

• разработка требований к программным средствам;

• разработка предложений по этапам и срокам автоматизации.

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

• уточнение логической модели (разработка подробной логики каждого процесса с использованием диаграмм потоков данных и спецификаций процессов);

• проектирование физической базы данных:

• построение иерархии функций модулей, подлежащих программированию;

• оценка затрат на реализацию.

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

11.2. Проведение обследования 

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

Необходимо отметить, что каждый из участвующих в проекте системных аналитиков должен обследовать не более 2-3 деятельностей предприятия (таких как, например, учет кадров, бухгалтерия, маркетинг, ремонт оборудования, перевозки и т.п.) для того, чтобы тщательно в них разобраться. Современное предприятие является сложной системой, состоящей из крупных взаимоувязанных подсистем (деятельностей), а возможности человека в одновременном охвате большого количества таких подсистем ограничены, поэтому здесь в полной мере должен использоваться принцип "разделяй и властвуй". И в этой связи вызывают недоумение заявления некоторых компаний о' готовности провести обследование предприятия (обычно культивирующего 15-25 деятельностей) за 1-2 дня силами в 2-3 человека.

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

• данные по оргштатной структуре предприятия;

• информация о принятых технологиях деятельности;

• стратегические цели и перспективы развития;

• результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

• предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

• нормативно-справочная документация;

• данные по имеющимся на предприятии средствам и системам автоматизации;

• опыт системных аналитиков в части наличия типовых решений.

При проведении обследования целесообразно применять следующие методы:

• анкетирование

• сбор документов

• интервьюирование.

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

ФИО руководителя подразделения, телефон

Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться)

Каковы (с позиций Вашего подразделения) должны быть цели создания интегрированной системы управления предприятием

Основные фуккции подразделения

Какая информация поступает из других подразделений (заявки, запросы, отчеты и т.п.)

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

Какая информация формируется ("рождается ") в подразделении

С какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается

Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журчат, картотека и т.п.)

Время хранения информации

Документы от и для руководства

Штатная структура и квалификация кадров

Техническое оснащение подразделения (компьютеры, сеть, модем и т. п.)

Используемые программные продукты

Подпись

Просьба приложить:

  1.  Положение о подразделении
  2.  Набор документальных форм без внутреннего наполнения, т.е. используемые формы, бланки и др. (например, карточка складского учета, отчет по форме N, наряд-задание, товарно-транспортная накладная)

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

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

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

• Тезис в начале беседы – я ничего (или почти ничего) не знаю о Вашей работе, расскажите как можно подробнее, чем Вы занимаетесь?

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

• Правило 2 – если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие вопросы должен один из них, неясные для других вопросы проясняются в конце беседы.

• Правило 3 – даже если Вы прекрасно знаете предметную область, не говорите много сами и не учите интервьюируемого: в любом случае выявляются тонкости и детали, специфичные для данного предприятия и, естественно, Вам неизвестные.

В принципе этих и подобных им правил достаточно для выявления в ходе беседы необходимой аналитику информации приблизительно у 90% интервьюируемых, а этого более, чем достаточно в соответствии с законом "20 на 80" (сравните: 20% людей выпивают 80% пива). Тем не менее постараемся составить основанную на опыте типизацию остальных 10% и предложить возможные действия по выходу из тупика.

  1.  "Отказник" – как правило, квалифицированный специалист, осознающий свою незаменимость. Обычно руководству известен его характер, поэтому необходимы жесткие меры: либо данная деятельность не будет включена в модель, либо она будет промоделирована на основании
    опыта и соображений здравого смысла.
  2.  "Говорун" – как правило, руководитель среднего звена, понимающий, что по-старому работать нельзя и хватающийся за любую возможность улучшить ситуацию. Очень полезный для поддержки проекта человек, тем не менее в беседе готов бесконечно обсуждать свои трудности и проблемы, получить от него необходимую для построения модели информацию практически невозможно. Единственный способ работы с ним – обсуждение уже построенной (пусть примитивной и во многом
    ошибочной) модели с целью ее доводки.
  3.  "Балласт" – человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы типа "Какие функции Вы выполняете?", "С какими документами Вы работаете?" агрессивно повторяет как попугай "Я делаю все", "Со всеми документами", "Все документы ко мне приходят и все уходят". Какой-либо информации получить не удается по причине ее отсутствия. Естественно никакого отражения подобной "деятельности" в модели не производится.
  4.  Человек, занимающий экзотическую и малопонятную должность типа "главный обогатитель". Представляет собой модификацию варианта с той лишь разницей, что реально деятельность по обогащению руды существует и, следовательно, должна быть отражена в модели.
  5.  "Мелкая сошка" – человек, не привыкший к проявлению интереса к себе и своей работе и занимающий низшую должность. При должном терпении реально получение того небольшого куска информации, которым он владеет. При обследовании диспетчерской службы одного из северных предприятий на одной из удаленных точек автор имел неосторожность во время кратковременной беседы включить диктофон. Беседа была тут же прервана, и автору пришлось ждать минут сорок, пока интервьюируемая приводила себя в порядок – накладывала косметику и делала прическу!

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

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

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

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

2) Элементы данных. О каждом элементе данных необходимо знать формат данных и допустимые значения этого элемента. Формат (включая тип) и физическая длина очень полезны при проектировании
экранных форм и определении размеров баз данных.

  1.  Потоки данных. Такие характеристики потока как скорость и интенсивность являются необходимыми при определении требований к аппаратным (техническим) средствам. Кроме того, для любого составного потока данных полезно знать распределение компонентов внутри этого
    потока данных. Например, если в фирме "Рога и Копыта" заказ определяется, как
    заказ={заказ на рога! заказ на копыта}, и выясняется, что 12% всех заказов составляют заказы на рога, 84% – на копыта, а 4% заказов – на заполнение стержней для шариковых ручек, то данная статистика может
    использоваться для определения пиковых нагрузок на соответствующие обрабатывающие процессы (а также, возможно, для принятия решения об оказании дополнительного вида услуги –
    upgrade стержней).
  2.  Процессы. Важнейшими характеристиками процессов являются частота и время выполнения. Именно здесь и лежит ключ к улучшению их функционирования. Кроме того, такие сведения являются необходимыми при определении требований к аппаратным средствам.
  3.  Хранилища данных. По хранилищам данных обычно собирается следующая информация: среднее количество записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из процессов, включающих перечисленные действия.
    Проектировщик баз данных может использовать эту статистику для нескольких целей – например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа
    и т.д. Более того, к этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую частоту и/или гибкость доступа к данным.

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

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

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

ГЛАВА 12. ПОСТРОЕНИЕ МОДЕЛЕЙ

12.1. Построение и анализ моделей деятельности предприятия

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

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

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

При этом переход от модели "как есть" к модели "как должно быть" обычно осуществляется следующими двумя способами:

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

• Радикальным изменением технологий и переосмыслением бизнес-процессов ("жесткий" реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть следует задуматься, а нужна ли вообще такая проверка?
Возможно затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести банк в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы сделок незначительны)!

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

В рамках создания моделей деятельности должен быть осуществлен:

•  анализ функциональной деятельности структурных подразделений предприятия;

• анализ функционального взаимодействия структурных подразделений;

• анализ внутреннего документооборота структурных подразделений;

• анализ информационных потоков и информационного взаимодействия структурных подразделений;

• анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и на предприятии в целом.

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

• количество потребителей продукции предприятия;

• стоимость издержек производства продукции;

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

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

• стоимость и длительность выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;

• дублирование и противоречивость выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;

• степень загруженности структурных подразделений и должностных лиц;

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

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

Результатом проведения анализа и оценки являются предложения по совершенствованию деятельности предприятия, а именно:

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

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

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

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

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

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

• последовательность, формы, способы и время выполнения задач, поставленных структурным подразделениям предприятия;

• распределение сотрудников структурных подразделений и материальных средств по решаемым задачам;

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

В связи с вышесказанным каждая из моделей деятельности должна включать:

• полную функциональную модель с глубиной проработки до уровня конкретного действия должностного лица структурного подразделения предприятия;

• информационную модель, интегрированную с функциональной моделью;

• динамические, стоимостные, событийные и т.п. модели для осуществления соответствующих оценок.

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

1) Разработка структурной функциональной модели деятельности предприятия:

• определение информационных потоков между основными процессами деятельности, связей между процессами и внешними объектами;

• оценка объемов и интенсивности информационных потоков;

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

• анализ и оптимизация структурной функциональной модели.

2) Разработка информационной модели предприятия:

• определение сущностей модели и их атрибутов;

• проведение атрибутного анализа и оптимизация сущностей;

• идентификация отношений между сущностями и определение типов отношений;

• разрешение неспецифических отношений;

• анализ и оптимизация информационной модели.

3) Разработка событийной модели предприятия:

• идентификация перечня состояний модели и определение возможностей переходов между состояниями:

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

• анализ и оптимизация событийной модели.

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

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

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

  1.  Основной принцип заключается в том, что структурирование должно осуществляться  в соответствии  с деятельностями  и  бизнес-процессами предприятия, а не в соответствии с его оргштатной структурой. Именно бизнес-процессы представляют ценность для клиента, и
    именно их улучшением предстоит в дальнейшем заниматься консультанту. Модель, основанная на оргштатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором, в принципе, руководству и так известно, иначе оно не воспользовалось бы услугами
    консультантов), на ее основе возможно внести предложения только об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе (не всегда в явном виде) и оргштатную структуру предприятия.
  2.  Верхний уровень модели должен отражать только контекст системы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более. В случае построения модели структуры, включающей в себя несколько разнотипных предприятий, на контекстном уровне необходимо отразить каждое из них и их соответствующие взаимосвязи. Например, контекстная диаграмма горно-обогатительного комбината может содержать процессы Автобаза, Карьер, Фабрика и Управление ГОК, контекстная диаграмма регионального банка Сбербанка РФ содержит Процессы Территориальное Управление, Типовое Отделение, Типовой Филиал.
  3.  На втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи. Например, для автотранспортного предприятия одним из решений может быть выделение следующих деятельностей: Эксплуатация автотранспорта, Ремонт и техническое обслуживание, Контроль безопасности, Управление производством, Обеспечивающая деятельность. В случае большого количества деятельностей некоторые из них можно вынести на третий уровень модели. Так Обеспечивающая деятельность может включать в себя Учет кадров, Бухгалтерский  учет,  Экономическое  планирование,  Материально-техническое снабжение, Складской учет и т.п. Но в любом случае под деятельности необходимо отводить не более двух уровней модели.
  4.  Каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня). Например, деятельность по учету кадров включает в себя бизнес-процессы Прием на работу, Увольнение и т.п.
  5.  Дальнейшая детализация бизнес-процессов осуществляется по средством бизнес-функций. Так процесс Прием на работу содержит в себе функции Прием заявления, Оформление приказа, Регистрация и др. Обычно для моделирования бизнес-функции достаточно 2-3 уровней детализации, которая завершается описанием элементарного алгоритма с помощью миниспецификации.
  6.  Таким образом, общее число уровней в модели не должно превышать 6-7. Практика показывает, что этого вполне достаточно для построения полной модели деятельности современного предприятия любой отрасли.

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

Первый пример касается автобазы, входящей в состав горно-обогатительного комбината и занимающейся перевозкой породы от нескольких территориально разделенных предприятий по добыче руды (карьеров) на аналогичные предприятия по ее обогащению (фабрики). Парк автобазы содержит около 200 самосвалов "БелАЗ" грузоподъемностью 120 тонн, работы по перевозкам осуществляются в 3 смены. На каждую смену водителю выписывается путевой лист, содержащий 52 графы для однократного заполнения (хотя реально не все заполняются), при этом 5 граф заполняются многократно в соответствии с количеством погрузок/разгрузок. Кроме этого, на каждом путевом листе должно быть проставлено 17 подписей самых различных лиц, прежде чем он попадает в бухгалтерию автобазы и на его основе производится расчет соответствующих выплат. Даже если на получение каждой подписи и заполнение графы затратить в среднем по одной минуте, то оформление одного путевого листа (не включая его обработку в бухгалтерии) занимает более часа, а в день таких листов в принципе может быть шестьсот! Конечно, руководство автобазы прекрасно понимало проблему и ставило задачу сократить количество подписей хотя бы до 9-10. После проведения обследования и построения и анализа моделей выяснилось, что вся информация, за исключением контроля состояния водителя и, частично, самосвала (техническая исправность, медицинский контроль), дублируется в различных первичных документах (прежде всего, в диспетчерской сводке, ведомостях на выдачу талонов и различных накладных на отпуск горючего, масел и т.п.), то есть по своей сути путевой лист является производным документом! После предоставления таких результатов с резюме об уничтожении путевых листов как класса у руководства оставался единственный аргумент – требования ГАИ. Но, позвольте, для таких большегрузных самосвалов требуются специальные дороги, да и ездят они по четко определенным маршрутам карьер-фабрика. Более того, у них отсутствует государственный номер, весь учет ведется в соответствии с гаражным номером (от первого до двухсотого), не говоря уже о том, что за все время длительных командировок автору не встретился ни один инспектор. Второй пример относится к распределенной диспетчерской службе того же самого комбината. Фактически имеется 8 диспетчерских пунктов (2 автобазы, 3 карьера, 2 фабрики, контора), на которых собирается и сводится одна и та же информация по перевозкам породы: карьер собирает данные по вывозу, фабрика – по разгрузке, автобаза – по перевозке, контора – всю эту информацию по каждому из предприятий, то есть одни и те же данные фиксируются 4 раза! Более того, все эти данные не совпадают, это связано со спецификой производства: например, в сырую погоду при разгрузке на кузов самосвала может налипнуть до 5 тонн породы! А поскольку объемы перевозок оказывают существенное влияние на начисляемую зарплату, все эти 8 диспетчеров ежедневно тратят уйму времени, сил и нервов на согласование этих данных (и в конце концов находят компромиссное решение). А дальше начинается самое интересное: с определенной периодичностью (неделя, месяц) специалист-маркшейдер делает замеры, сравнивает их результаты с предыдущими и выдает информацию по вывезенной породе за соответствующий период. И именно эта информация служит основой для начисления зарплаты и формирования отчетов по деятельности!

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

12.2. Разработка системного проекта

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

Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

• архитектура системы, ее функции, внешние условия ее функционирования, распределение функций  между аппаратной и программной частями;

• интерфейсы и распределение функций между человеком и системой;

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

• состав людей и работ, имеющих отношение к системе;

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

В рамках системного проектирования должно быть осуществлено:

• определение состава, структуры и характеристик функциональных задач в рамках деятельности структурных подразделений;

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

• определение структуры и характеристик информационного обеспечения технологии решения задач;

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

• разработка состава автоматизируемых процедур документооборота.

Системный проект должен включать:

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

• комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

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

• концептуальную модель интегрированной базы данных (пакет диаграмм);

• архитектуру системы с привязкой к концептуальной модели;

• предложения по оргштатной структуре для поддержки системы.

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

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

• описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

• уменьшить затраты на разработку и внедрение системы;

• оценить разработку по времени и результатам;

• достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);

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

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

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

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

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

1. Подсистема управления производством – включает в себя требования по автоматизации деятельности начальника автобазы, главного инженера, главного механика, главного энергетика, организации документооборота, деятельности центра управления производством – ЦУП (включая контроль неснижаемого запаса на оборотном складе, планирование ремонтов дизелей по периодам, планирование ремонтов и технического обслуживания (ТО) автосамосвалов по периодам, расчет резерва времени по шинам и фильтрам, расчет средней наработки и анализ отказов узлов автосамосвала и дизеля, формирование заказов на изготовление деталей, заявок на запчасти, наряд-заданий на ремонт и ТО) и технического отдела (включая учет транспортных средств, анализ надежности парка, узлов и агрегатов, анализ расхода запчастей и материалов, трудоемкости ТО и ремонтов, расчет коэффициента технической готовности, планирование, контроль и формирование отчетности).

Рис. 12.1. Фрагмент системного проекта

2. Подсистема ремонта и технического обслуживания – включает в себя требования по автоматизации деятельности по диагностике (дефектоскопия, технический контроль состояния гидросистемы, силового агрегата и электрической части автосамосвала, химический анализ масел, топлива и охлаждающей жидкости), ремонту (уточнение наряд-задания, определение ремонтного участка, оформление заявки на запчасти, сдача деталей на оборотный склад, учет выполненного ремонта по каждому из ремонтных участков), техническому обслуживанию всех видов (ТО-250, ТО-500, ТО-1500), а также учет на оборотном складе.

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

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

  1.  Сотрудники – предназначен для хранения данных о сотрудниках автобазы. Используется при учете кадров (при приеме и увольнении, подготовке пенсионных дел, награждении), учете ремонтов и ТО (для фиксации, кем выполнен ремонт),  бухгалтерии  (при  проведении  начислений  и  удержаний,  учете
    материальных ценностей) и др.
  2.  Технологический транспорт – используется для хранения данных по автосамосвалам: учетной карточки, данных по проведенным ТО, истории автосамосвала.
  3.  Перевозки – используется для хранения данных по перевозкам на основе диспетчерской сводки.
  4.  Ремонты – используется для хранения данных о любом ремонте, включая перечень замененных узлов и агрегатов.
  5.  Запасные части и материалы – используется для хранения данных о имеющихся в наличии запчастях и материалах, включая данные по складу запчастей, складу материалов, инструментальному складу и оборотному складу.

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

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

ГЛАВА 13. РАЗРАБОТКА ПРЕДЛОЖЕНИЙ ПО АВТОМАТИЗАЦИИ И ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

13.1. Предложения по автоматизации

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

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

• разработку требований к техническим средствам;

• разработку требований к программым средствам;

• разработку топологии, состава и структуры локальной вычислительной сети;

• анализ имеющихся на рынке систем управления предприятием с учетом их соответствия системному проекту и формирование рекомендаций по выбору такой системы;

• совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием (или отдельных ее элементов) или о разработке собственной системы;

• разработку предложений по этапам и срокам автоматизации.

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

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

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

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

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

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

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

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

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

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

• единая информационная среда предприятия;

• режим реального времени;

• независимость от законодательства;

• интеграция с другими приложениями (в том числе с уже работающими на предприятии системами);

• поэтапное внедрение и т.п.

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

Ниже перечислены некоторые из критериев выбора готовой системы:

• поддержка  большинства  функций,  выявленных  при  анализе требований;

• поддержка концептуальной модели данных;

• наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;

• функционирование на различных аппаратных платформах;

• достаточные размеры внутренних таблиц;

• локализация.

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

4) Разработка собственной системы. Отметим недостатки такого подхода по сравнению с покупкой готовой системы:

• трудозатраты на создание собственной интегрированной системы огромны и составляют сотни и тысячи человеко-лет, стоимость разработки соизмерима со стоимостью готовой системы (а часто значительно превышает ее): такие продукты должны реализовываться большими коллективами программистов;

• использование готовой системы менее рискованно, чем разработка собственной;

• готовая система внедряется поэтапно и поэтому частично может быть доступна в рабочем режиме гораздо быстрее, чем собственная.

13.2. Техническое проектирование

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:

• проектирование  архитектуры  системы,  включающее  разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными
компонентами, связей между ними и внешними объектами;

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

При этом происходит расширение системного проекта:

• за счет его уточнения;

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

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

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

13.3. Фрагмент технического проекта ремонтной службы

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

В состав ремонтной службы входят:

• центр управления ремонтным производством (ЦУП);

• ремонтные участки (участки технического обслуживания (ТО) и текущего ремонта (ТР). шиномонтажный и шиноремонтный участок, участок диагностики и оперативного аварийного ремонта, участок-ремонта дизелей и топливной аппаратуры, участки механосварочного производства и ремонта агрегатов);

• оборотный склад;

• инструментальная кладовая;

• мойка автосамосвалов.

  1.  Состав, структура и характеристик» функциональных задач в рамках деятельности ремонтной службы

1.1) Ремонтные участки 

АРМ каждого из ремонтных участков должен фиксировать информацию по решению следующих фунциональных задач:

• уточнение наряд-задания;

• выявление необходимых деталей и их бронирование;

• оформление заявок на запчасти;

• сдача деталей на оборотный склад;

• учет выполненного ремонта.

1.2) ЦУП

Осуществляет оперативное управление ремонтными подразделениями и проводит анализ текущей и перспективной обстановки. АРМ ЦУП должен обеспечить решение следующих задач:

• контроль неснижаемого запаса на оборотном складе;

• планирование ремонтов дизелей по периодам;

• планирование ремонтов автосамосвалов по периодам (включая ППР, текущие ремонты и ТО на двое суток и на месяц вперед);

• расчет резерва времени по шинам;

• расчет резерва времени по фильтрам;

• расчет средней наработки и анализ отказов узлов автосамосвала;

• расчет средней наработки и анализ отказов узлов дизеля;

• формирование заказов на изготовление деталей;

• формирование заявок на запчасти;

• формирование наряд-заданий;

• анализ и учет расхода запасных частей, оборотных агрегатов, шин, материалов ГСМ и др.;

• учет движения крупных агрегатов после ремонта по самосвалам (дизель, генератор, РМК, электродвигатели), сопровождение происходивших по ним неисправностей для облегчения диагностирования самосвалов в дальнейшем;

• проведение анализа технического состояния парка по определенным критериям (пробег, моточасы, проведенные ремонты в хронологическом порядке, результаты диагностики по спектральному анализу масел и др.);

• учет времени простоев по определенным критериям (по вине персонала, по причине отсутствия запчастей, ГСМ, инструментов, по причине ожидания ремонта из-за отсутствия места или ремонтников);

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

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

• на основании графика проведения ТО, выданного техотделом, и с учетом  реального времени наработки осуществление перерасчета постановки на техобслуживание автосамосвалов;

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

1.3) Оборотный склад

• учет номенклатуры и количества поступивших на оборотный склад отремонтированных агрегатов и узлов с участков;

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

1.4) Инструментальная кладовая

• учет номенклатуры и количества поступивших на склад инструментов и расходных материалов к ним;

• учет расхода инструментов и материалов.

1.5) Мойка автосамосвалов

• учет операций по мойке автосамосвалов.

Ниже рассматриваются фрагменты технического проектирования двух автоматизарованных рабочих мест: АРМ ДИАГНОСТИКА и АРМ ХИМИЧЕСКИЙ АНАЛИЗ.

2) Логическая модель базы данных ремонтной службы и ее привязка к функциональной модели автобазы

2.1) Схема базы данных ремонтной службы

Фрагменты схем базы данных ремонтной службы для АРМ ДИАГНОСТИКА и ХИМИЧЕСКИЙ АНАЛИЗ приведены на рис. 13.1 и 13.2, соответственно. Подробное описание атрибутов, выделенных в этих фрагментах приводится ниже.

  1.  ДЕФЕКТОСКОПИЯ – результаты дефектоскопии автосамосвала

 ДАТА ИСПЫТАНИЙ – дата проведения дефектоскопии

ТИП ДИАГНОСТИКИ – тип проводимых испытаний

НОМЕР ШАССИ – номер шасси проверяемого автосамосвала

2) ДИАГНОСТИКА – результаты диагностики автосамосвала

 ДАТА ИСПЫТАНИЙ – дата проведения диагностики

ТИП ДИАГНОСТИКИ – тип проводимых испытаний

НОМЕР ШАССИ – номер шасси проверяемого автосамосвала

ТАБЕЛЬНЫЙ НОМЕР СОТР – табельный номер сотрудника автобазы, проводящего испытания

  1.  ДИАГНОСТИКА ГИДРАВЛИКИ – результаты диагностики гидравлики

 ДАТА ИСПЫТАНИЙ- дата проведения диагностики

ТИП ДИАГНОСТИКИ – тип проводимых испытаний

НОМЕР ШАССИ – номер шасси проверяемого автосамосвала

РЕЗУЛЬТАТЫ ИСПЫТАНИЙ – результаты диагностики гидравлики

Рис. 13.2

  ДИАГНОСТИКА ДИЗЕЛЯ – результаты диагностики дизеля

ДАТА ИСПЫТАНИЙ – дата проведения диагностики

ТИП ДИАГНОСТИКИ – тип проводимых испытаний

НОМЕР ШАССИ – номер шасси проверяемого автосамосвала

ДАВЛЕНИЕ МАСЛА – давление масла в системе

ДАВЛЕНИЕ ТУРБОНАДДУВА ЛЕВ – давление турбонаддува левого

ДАВЛЕНИЕ ТУРБОНАДДУВА ПРАВ – давление турбонаддува правого

ДАВЛЕНИЕ В ТОПЛ МАГИСТ – давление в топливной магистрали

МОЩНОСТЬ ДИЗЕЛЯ – мощность двигателя в л/с

5) ДИАГНОСТИКА ТРАНСМИССИИ – результаты диагностики трансмиссии

ДАТА ИСПЫТАНИИ – дата проведения диагностики

НОМЕР ШАССИ – номер шасси проверяемого автосамосвала

ТИП ДИАГНОСТИКИ – тип проводимых испытаний

I-A – ток в амперах

Р-кВт – мощность в киловаттах

U-b – напряжение в вольтах

ОБ-МИН ПО ПАСПОРТУ- количество оборотов в минуту по паспорту (по 11 точкам)

ОБ-МИН ПЕРЕД НАЛАДКОЙ – количество оборотов в минуту перед наладкой (по 11 точкам)

ОБ-МИН ПОСЛЕ НАЛАДКИ- количество оборотов в минуту после наладки (по 11 точкам)

6) ЖИДКОСТЬ – топлива, масла и охлаждающие жидкости, имеющиеся в запасе на автобазе

МЕСТО ХРАНЕНИЯ – код тары, в которой хранится жидкость

ДАТА ПОСТАВКИ – дата поставки жидкости

ПОСТАВЩИК – завод-изготовитель

ТИП ЖИДКОСТИ – топливо, масло или охлаждающая жидкость

ОБЪЕМ – объем жидкости

СЕЗОННОСТЬ – идентификатор времени применения

7) ИСТОРИЯ КАРЬЕРЫ – движения сотрудников автобазы в рамках ее оргштатной структуры

ДАТА ИЗМЕНЕНИЯ – дата изменения должности, зарплаты или подразделения автобазы, в котором работает сотрудник

ТАБЕЛЬНЫЙ НОМЕР СОТР – табельный номер сотрудника

ДОЛЖНОСТЬ – занимаемая сотрудником автобазы должность

ЗАРПЛАТА – зарплата сотрудника

ПОДРАЗДЕЛЕНИЕ – код подразделения, в котором работает сотрудник

8) МАСЛО – результаты химического анализа масел

КОД ХИМ АНАЛИЗА – уникальный внутренний для автобазы номер проводимого химического анализа

ЗОЛЬНОСТЬ

КИНЕМАТ ВЯЗКОСТЬ

СОДЕРЖАНИЕ ВОДЫ

ЩЕЛОЧНОЕ ЧИСЛО МЕХАН ПРИМЕСИ

ТЕМП-PA ВСПЫШКИ

Результаты анализа (Ag, Al, Ва, Ca, Cr, Fe, FoNOoh, Mg, Mo, Na, Ni, Pb, Si, Sn, Zh)

9) ОХЛ ЖИДКОСТЬ – результаты химического анализа охлаждающих жидкостей

КОД ХИМ АНАЛИЗА – уникальный внутренний для автобазы номер проводимого химического анализа

РЕЗ-ТЫ НА ПРИСАДКИ ДСА – результаты анализа

10) СОТРУДНИК – данные о сотрудниках автобазы

ТАБЕЛЬНЫЙ НОМЕР СОТР – табельный номер сотрудника

ФАМИЛИЯ – фамилия сотрудника

ИМЯ – имя сотрудника

ОТЧЕСТВО – отчество сотрудника

ДАТА РОЖДЕНИЯ – дата рождения сотрудника

МЕСТО РОЖДЕНИЯ – место рождения сотрудника

АДРЕС – домашний адрес сотрудника

ПАСПОРТ – паспортные данные сотрудника

РАБ ТЕЛЕФОН – рабочий телефон сотрудника

ДОМ ТЕЛЕФОН – домашний телефон сотрудника

11) ТОПЛИВО – результаты химического анализа топлива

КОД ХИМ АНАЛИЗА – уникальный внутренний для автобазы номер проводимого химического анализа

КИНЕМАТ ВЯЗКОСТЬ

СОДЕРЖАНИЕ ВОДЫ

МЕХ ПРИМЕСИ

ТЕМП-PA ВСПЫШКИ

  1.  ТРАНСПОРТ – данные по автопарку

НОМЕР ШАССИ – номер шасси автомобиля

МОДЕЛЬ АВТОМОБИЛЯ

ГАРАЖНЫЙ НОМЕР – номер, присвоенный автомобилю на автобазе (только  для технологического транспорта)

ГОСУД НОМЕР – государственный номер автомобиля (только для хозяйственного транспорта)

ДАТА ВЫПУСКА – дата выпуска автомобиля заводом-изготовителем

ДАТА ВВОДА В ЭКСПЛ – дата ввода автомобиля в эксплуатацию на автобазе

ТИП КУЗОВА – тип кузова автомобиля (самосвал, тягач, автоцистерна, легковой, бортовой, сед. тягач, полуприцеп, прицеп бортовой, микроавтобус и др.)

ГРУЗОПОДЪЕМНОСТЬ – отсутствует для легкое., сед. тягача, микроавтобуса

ЗАВОД ИЗГОТОВИТЕЛЬ – название завода изготовителя

НОМЕР ДВИГАТЕЛЯ – номер двигателя автомобиля

МОДЕЛЬ ДВС – модель двигателя

МОЩНОСТЬ ЛС – мощность двигателя в лошадиных силах

НОМЕР ТЕХПАСПОРТА – только для хозяйственного транспорта

ИНВЕНТАРНЫЙ НОМЕР – номер инвентаризации

ПРИМЕЧАНИЕ – цвет и т.п.

13) ХИМ АНАЛИЗ – результаты химического анализа топлива, масел и охлаждающих жидкостей

КОД ХИМ АНАЛИЗА – уникальный внутренний для автобазы номер проводимого химического анализа

НОМЕР ШАССИ – номер шасси автомобиля

МЕСТО ХРАНЕНИЯ – код тары, в которой хранится жидкость

ДАТА АНАЛИЗА – дата проведенного анализа

ТАБЕЛЬНЫЙ НОМЕР СОТР – табельный номер сотрудника, проводившего анализ

2.2) Взаимосвязи информационной и функциональной моделей Соответствие сущностей информационной модели и накопителей данных функциональной модели приведено в таблице 13.1.

3) Состав и структура автоматизированных рабочих мест ремонтной службы

3.1) АРМ ДИАГНОСТИКА

Функции АРМ ДИАГНОСТИКА (рис. 13.3):

учет выполненной диагностики по электрической трансмиссии;

учет выполненной диагностики по дизелю;

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

Таблица 13.1

3.1.1) Учет выполненной диагностики по электрической трансмиссии

1) Занесение в таблицу ДИАГНОСТИКА следующей информации:

дата испытаний

номер шасси

тип диагностики (электрическая трансмиссия)

табельный номер сотрудника

2) Занесение в таблицу ДИАГНОСТИКА ТРАНСМИССИИ следующей информации:

-U(b) -1(А)

Р(кВт)

n (об/мин) по паспорту, перед наладкой и после наладки по 11 точкам измерений

Рис. 13.3. АРМ ДИАГНОСТИКА

3.1.2) Учет выполненной диагностики по дизелю

Занесение в таблицу ДИАГНОСТИКА следующей информации:

дата испытаний

номер шасси

тип диагностики (дизель)

табельный номер сотрудника

2) Занесение в таблицу ДИАГНОСТИКА ДИЗЕЛЯ следующей информации:

- давление масла в магистрали смазки

- давление турбонаддува (левого и правого)

давление в топливной магистрали между топливным насосом и форсунками

мощность дизеля

3.1.3) Учет выполненной диагностики по гидравлической системе

1) Занесение в таблицу ДИАГНОСТИКА следующей информации:

дата испытаний

номер шасси

тип диагностики (гидравлическая система)

табельный номер сотрудника

2) Занесение в таблицу ДИАГНОСТИКА ГИДРАВЛИКИ следующей информации:

данные по результатам испытаний

3.2) АРМ ХИМИЧЕСКИЙ АНАЛИЗ

Функции АРМ ХИМИЧЕСКИЙ АНАЛИЗ (рис. 13.4):

учет результатов химического анализа масел;

учет результатов химического анализа топлива;

учет результатов химического анализа охлаждающих жидкостей.

3.2.1) Учет результатов химического анализа масел

1) Занесение в таблицу ХИМ АНАЛИЗ следующей информации:

дата испытаний

номер шасси или место хранения

тип химического анализа (масла)

табельный номер сотрудника

2) Занесение в таблицу МАСЛО следующей информации:

зольность масла

кинематическая вязкость

содержание воды

щелочное число

механические примеси

температура вспышки

- параметры по спектральному анализу (Zh, Ba, Ca, Fe, Cr, Mg, Pb, Si, Al, Mo, Sn, Ag,Ni, FoN Фон, Na)

3.2.2) Учет результатов химического анализа топлива

1) Занесение в таблицу ХИМ АНАЛИЗ следующей информации:

дата испытаний

номер шасси или место хранения

тип химического анализа (топлива)

табельный номер сотрудника

2) Занесение в таблицу ТОПЛИВО следующей информации:

кинематическая вязкость

содержание воды

механические примеси, определенные методом фильтрации

температура вспышки

сезонность    

3.2.3) Учет результатов химического анализа охлаждающих

жидкостей

1) Занесение в таблицу ХИМ АНАЛИЗ следующей информации:

дата испытаний

номер шасси или место хранения

тип химического анализа (охлаждающие жидкости)

табельный номер сотрудника

2) Занесение в таблицу ОХЛ ЖИДКОСТЬ следующей информации:

результат анализа на присадки ДСА

Рис. 13.4. АРМ ХИМИЧЕСКИЙ АНАЛИЗ

ЧАСТЬ 4. CASE-СРЕДСТВА АВТОМАТИЗАЦИИ МЕТОДОЛОГИЙ СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

Четвертая часть книги посвящена описанию CASE-средств автоматизации методологий структурного системного анализа и проектировали – инструмента современного консультанта.

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

В гл. 15 приводится классификация CASE-средств по типам, категориям и уровням.

В гл. 16 рассматривается отечественное CASE-средство первого поколения – пакет CASE. Аналитик. Приведено описание основных функций пакета, а также основные особенности используемых средств структурного системного анализа.

Глава 17 посвящена аналитическому обзору российского рынка CASE-средств.

ГЛАВА 14. КОНЦЕПТУАЛЬНЫЕ ОСНОВЫ CASE – ТЕХНОЛОГИЙ

14.1. Эволюция CASE-средств

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

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

компиляторов, интерпретаторов, трассировщиков;

символических отладчиков, пакетов программ;

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

СASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I);

CASE-cpeдcmв генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла (ЖЦ) разработки ПО (вторая генерация CASE-II).

CASE-I является первой технологией, адресованной непосредственно системным аналитикам и проектировщикам, и включающей средства для поддержки графических моделей, проектирования спецификации, экранных редакторов и словарей данных. Она не предназначена для поддержки полного ЖЦ и концентрирует внимание на функциональных спецификациях и начальных шагах проекта – системном анализе, определении требовании, системном проектировании, логическом проектировании БД.

CASE-II отличается значительно более развитыми возможностями. Улучшенными характеристиками и исчерпывающим подходом к полному ЖЦ. В ней в первую очередь используются средства поддержки автоматической кодогенерации, а также обеспечивается полная функциональная поддержка для порождения графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации, а также информации по управлению проектированием; построения прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам ЖЦ. CASE-II может включать свыше 100 функциональных компонент, поддерживающих все этапы ЖЦ, при этом пользователям предоставляется возможность выбора необходимых средств и их интеграции в нужном составе.

14.2. Сase-модель жизненного цикла ПО

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

В таблице 14.1 приведены оценки трудозатрат по фазам ЖЦ . Первая строка таблицы соответствует традиционной разработке, вторая – разработке с использованием структурных методологий проектированиям третья – разработке с использованием CASE-технологий. В таблицу 14.2 сведены основные изменения в ЖЦ при использовании CASE-технологий по сравнению с традиционной разработкой.

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

Таблица 14.1

Способ разработки

Анализ

Проектирование

Кодирование

Тестирование

Традиционная разработка

20%

15%

20%

45%

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

30%

30%

15%

25%

Использование CASE-технологий

40%

40%

5%

15%

Рис. 14.1. Модели жизненного цикла ПО

Таблица 14.2.

Традиционная разработка

CASE

1

Основные усилия – на кодирование и тестирование

Основные усилия – на анализ и проектирование

2

"Бумажные" спецификации

Быстрое итеративное прототипирование

3

Ручное кодирование

Автоматическая кодогенерация

4

Ручное документирование

Автоматическая генерация документации

5

Тестирование кодов

Автоматический контроль проекта

6

Сопровождение кодов

Сопровождение спецификаций проектирования

Рис. 14.2. Уменьшение затрат на проектирование программных систем за счет

CASE-технологий

14.3. Состав, структура и функциональные особенности case-средств

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

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

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

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

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

  1.  Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
  2.  Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др).
  3.  Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.

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

  1.  Доступность для разных категорий пользователей.
  2.  Рентабельность.

Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

Интегрированный CASE-пакет содержит четыре основные компоненты:

1) Средства централизованного хранения всей информации о проектируемом ПО в течении всего ЖЦ (репозитарий) являются основой CASE-пакета. Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

инкрементный режим при вводе описаний объектов;

распространение действия нового или скорректированного описания на информационное пространство всего проекта;

синхронизацию поступления информации от различных пользователей;

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

сборку любой запрошенной версии;

контроль информации на корректность, полноту и состоятельность.

  1.  Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщика
    ми, инженерами, администраторами и т. д.
  2.  Средства анализа, проектирования и разработки предназначены для того, чтобы обеспечить планирование и анализ различных описаний, а также их преобразования в процессе разработки.
  3.  Средства вывода служат для документирования, управления проектом и кодовой генерации.

Все перечисленные компоненты в совокупности должны:

поддерживать графические модели;

контролировать ошибки;

организовывать и поддерживать репозитарий;

поддерживать процесс проектирования и разработки.

14.4. Поддержка графических моделей

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

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

создание иерархически связанных диаграмм, в которых комбинируются графические и текстовые объекты;

создание и редактирование объектов в любом месте диаграммы;

создание, перемещение и выравнивание групп объектов, изменение их размеров, масштабирование;

сохранение связей между объектами при их перемещении и изменении размеров;

автоматический контроль ошибок и др.

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

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

14.5. Контроль ошибок

Важность контроля ошибок на этапах анализа требований и проектирования спецификаций обуславливается возможностью их автоматического обнаружения на ранних этапах ЖЦ. CASE обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах ЖЦ, что влияет на успех разработки в целом. В подтверждение этого можно привести следующие статистические данные, основанные на отчетах фирмы TRW по анализу 5 крупных проектов:

при традиционной организации работ ошибки проектирования и кодирования составляют, соответственно, 64% и 32% от общего числа ошибок;

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

В CASE диаграммеры и верификаторы способны осуществлять следующие типы контроля:

1) Контроль синтаксиса диаграмм и типов их элементов. Обычно такой контроль осуществляется при вводе и редактировании элементов диаграмм. Примеры контролируемых ситуаций:

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

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

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

4) Сквозной контроль диаграмм одного или различных типов на предмет их состоятельности по уровням – вертикальное и горизонтальное балансирование диаграмм. При вертикальном балансировании (диаграммы одного типа) выявляются несбалансированные потоки данных между
детализируемой и детализирующей диаграммами. Горизонтальное балансирование определяет некорректности между
DFD, ERD, STD, словарями данных и миниспецификациями процессов. Так при балансировании DFD-ERD контролируется соответствие каждого хранилища данных на DFD
сущности или отношению на
ERD. Контроль DFD-STD осуществляется по следующим правилам: каждый управляющий процесс на DFD детализируется спецификацией управления STD. и наоборот, каждой STD должен соответствовать управляющий процесс; каждое условие (действие) в
STD должно соответствовать входному (выходному) управляющему потоку на DFD, и наоборот, каждому управляющему потоку в зависимости от его направленности должно соответствовать условие/действие на STD. При балансировании DFD-словарь данных-миниспецификация должны
проверяться следующие правила:

каждый поток и хранилище данных должны быть определены в словаре данных (контроль неопределенных значений), и наоборот, каждое определение в словаре должно быть отражено на диаграмме, в миниспецификации или другом определении (контроль неиспользуемых значений);

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

ссылки к данным в миниспецификациях должны соответствовать объектам на диаграммах и в словаре данных:

по возможности должна контролироваться семантика миниспецификации: например, если входные и/или выходные потоки связаны с хранилищем данных, то это должно быть отражено в миниспецификации (операторами READ, GET, WRITE, PUT и т.п.).

14.6. Организация и поддержка репозитария

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

Рис. 14.3. Содержимое репозитария

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

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

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

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

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

Пример отчета по функциональным блокам SADT-модели управления банком, автоматически создаваемого пакетом Design/IDEF, приведен ниже.

Activity Report

[АО] Банк

Inputs: Платежные документы

Outputs: Деньги

Controls: Законы, Время, Баланс

Mechanisms: Техника, Сотрудники

Sub-Activities: [A1] Операционные залы,

[А2] Управление банком,

[A3] Центральный банк

[А1] Операционные залы

Inputs: Платежные документы

Outputs: Принятые платежные документы

Controls: Законы, Продолжит, раб. дня,

Остатки счетов клиентов

Mechanisms: Сотрудники, Терминал БД

[А2] Управление банком

Inputs: Принятые платежные документы

Outputs: (Unlabled), Деньги, (Unlabled)

Controls: Спец. законы, Расчет баланса. Срок обработки

Mechanisms: Управленческий персонал, Компьютеры

[A3] Центральный банк

Inputs: (Unlabled)

Outputs: Деньги, (Unlabled)

Controls: Срок отправки

Mechanisms: Экспедиторы, Автомашины

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

14.7. Поддержка процесса проектирования и разработки

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

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

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

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

подготовка документации, графическая поддержка построения структурных диаграмм различных типов, продуцирование спецификаций для детализации функциональных блоков в диаграммах и структур данных на нижних уровнях (для таких спецификаций введен специальный термин – "миниспецификация");

корректное использование шагов обработки в методологиях.

Кодогенерация осуществляется на основе репозитария и позволяем автоматически построить до 80-90% объектных кодов или текстов программ на языках высокого уровня. При этом различными CASE-пакетами поддерживаются практически все известные языки программирования, однако наиболее часто в качестве целевых языков выступают COBOL, С и ADA.. Средства кодогенерации по отношению к полноте целевого продукта разделяются на средства генерации каркаса ПО и средства генерации полного продукта. В первом случае автоматически строится откомментированная логика (потоки управления) ПО, а также коды для БД, файлов, экранов, отчетов и т.п.. остальные фрагменты ПО кодируются вручную. Во втором случае из проектных спецификаций генерируется полная документированная программа, включая выполняемый код, пользовательскую и программную документацию, наборы тестов и т.д. Все эти компоненты полной программы связываются в единый объект, хранящийся в репозитарии для облегчения доступа и сопровождения.

Идея автоматической кодогенерации на основе модели заключается в следующем. Любая программа схематически может быть представлена в виде тройки: обрабатываемые данные, логический каркас обработки, линейные участки обработки. Схема базы данных может быть легко сгенерована на основании модели "сущность-связь", и современные средства информационного моделирования (например, ERWin, Designer/2000 и др.) обеспечивают такую генерацию. Логика обработки генерируется на основе диаграмм потоков данных: известны алгоритмы автоматического преобразования иерархии DFD в структурные карты, а с задачей получения из структурных карт соответствующих кодов легко справляется теория компиляции. Наконец, линейным участкам соответствуют миниспецификации модели. И именно здесь лежит ключ к высокому проценту автоматически сгенерированного кода, существенно зависящему от метода задания миниспецификаций.

ГЛАВА 15. КЛАССИФИКАЦИЯ CASE – СРЕДСТВ

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

  1.  АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Средства данной группы используются для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования (см. часть 2). К таким средствам относятся: САSЕ.Аналитик (Эйтэкс), The
    Developer  (ASYST  Technologies),  POSE  (Computer  Systems  Advisers), ProKit*Workbench (McDonnell Douglas), Excelerator (Index Technology), Design-Aid (Nastec), Design Machine (Optima), MicroStep (Meta Systems), vsDesigner (Visual Software), Analist/Designer (Yourdon), Design/JDEF (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architect  (Popkin  Software  &  Systems),  West mount  I-CASE  Yourdon (Westmount Technology
    В. V. & CADRE Technologies), CASE/4/0 (microTOOL GmbH). Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. На выходе продуцируются спецификации компонент системы и интерфейсов, связывающих эти компоненты, а также "калька" архитектуры системы и детальная "калька" проекта, включающая алгоритмы и определения структур данных.
  2.  ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода: ERWin (Logic Works), Chen Toolkit (Chen & Asssociates), S-Designor (SDP), Designer2000 (Oracle), Silverrun (Computer Systems Advisers).
  3.  ПРОГРАММИРОВАНИЕ. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную  выполняемую  программу:  COBOL  2/Workbench  (Mikro  Focus),
    DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software).
    Помимо диаграммеров различного назначения и средств поддержки работы с депозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы
    наборов тестов, анализаторы покрытия тестами, отладчики.
  4.  СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL u Superstructure (Computer Data Systems), Inspector/Recoder (Language Technology). Их целью является корректировка, изменение, анализ, пре образование и реинжениринг существующей системы. Средства позволяют осуществлять поддержку всей системной документации, включая коды, спецификации, наборы тестов; контролировать покрытие тестами для оценки полноты тестируемости; управлять функционированием системы и т.п. Особый интерес представляют средства обеспечения мобильности (в CASE они получили название средств миграции) и реинжиниринга. К средствам миграции относятся трансляторы, конверторы, макрогенераторы и др., позволяющие обеспечить перенос существующей системы в новое операционное или аппаратурное окружение. Средства реинжиниринга включают:

статические анализаторы для продуцирования схем системы ПО из ее кодов, оценки влияния модификаций (например,"эффекта ряби" - внесение изменений с целью исправления ошибок порождает новые ошибки);

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

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

редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры (например, спецификации);

средства доступа к спецификациям, их модификации и генерации нового (модифицированного) кода;

средства реверсного инжиниринга, транслирующие коды в спецификации.

  1.  ОКРУЖЕНИЕ. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам: Multi/Cam (AGS Management Systems), Design/OA (Meta Software).
  2.  УПРАВЛЕНИЕ ПРОЕКТОМ. Средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые  в  процессе  разработки  и  сопровождения  проектов:  Project Workbench (Applied Business Technology).

Классификация no категориям определяет уровень интегрированности по выполняемым функциям и включает вспомогательные программы (tools), пакеты разработчика (toolkit) и инструментальные средства (workbench). Категория tools обозначает вспомогательный пакет, решающий небольшую автономную задачу, принадлежащую проблеме более широкого масштаба. Категория toolkit представляет совокупность интегрированных программных средств, обеспечивающих помощь для одного из классов программных задач; использует репозитарий для всей технической и управляющей информации о проекте, концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа разработки ПО. Категория workbench представляет собой интеграцию программных средств, которые поддерживают системный анализ, проектирование и разработку ПО; используют репозитарий, содержащий всю техническую и управляющую информацию о проекте; обеспечивают автоматическую передачу системной информации между разработчиками и этапами разработки; организуют поддержку практически полного ЖЦ (от анализа требований и проектирования ПО до получения документированной выполняемой программы). Workbench, по сравнению с toolkit, обладает более высокой степенью интеграции выполняемых функций, большей самостоятельностью и автономностью использования, а также наличием тесной связи с системными и техническими средствами аппаратно-вычислительной среды, на которой workbench функционирует. По существу, workbench может рассматриваться как автоматизированная рабочая станция, используемая как инструментарий для автоматизации всех или отдельных совокупностей работ по созданию ПО.

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

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

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

пользователь обсуждает с аналитиком требования к проектируемой системе;

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

пользователь проверяет эти диаграммы и словари, при необходимости модифицируя их;

аналитик отвечает на эти модификации, изменяя соответствующие спецификации.

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

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

ГЛАВА 16. ПРИМЕР РЕАЛИЗАЦИИ – ПАКЕТ САSЕ.АНАЛИТИК

Пакет CASE.Аналитик является единственной отечественной, доведенной до рынка разработкой, которая без всяких натяжек может быть отнесена к CASE первой генерации. В основе пакета лежит методология структурного системного анализа Гейна-Сарсона, применимая к широкому классу систем обработки информации: информационно-[А1] вычислительных. АСУ, АСУТП, систем автоматизации делопроизводства, бухгалтерских систем, баз данных, систем автоматизации эксперимента, организационных систем и т.п. Пакет обеспечивает:

помощь для ясного понимания потребностей пользователя;

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

"принудительный" хороший стиль;

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

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

предоставление доступа к любой части проекта;

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

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

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

Рис. 16.1. Информационно-логическая модель системы

В состав пакета входят:

1) База данных проекта. В базе данных проекта САSЕ.Аналитик хранит всю информацию о модели системы – как о топологии и иерархии диаграмм, так и о структурных компонентах. При этом пользователю предоставляется графический интерфейс с базой данных и возможность получения разнообразных отчетов по проекту. В CASE.Аналитик используется база данных в формате СУБД Paradox. Для работы с CASE.Аналитик и базой данных проекта, порождаемой CASE.Аналитик, не требуется каких-либо дополнительных программ. В то же время база данных проекта доступна для программ, работающих с форматом Paradox. В этом смысле база данных проекта является открытой.

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

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

  1.  Средства вывода экранных и печатных форм для контроля и анализа проекта и его презентации. Предусмотрены следующие экранные и печатные формы: контекстная диаграмма, диаграмма потоков данных, диаграмма потоков управления, структурограмма данных, перечни объектов словаря данных, отсортированных и выбранных различными способами, содержание элементов словаря данных, миниспецификация логики процесса, протоколы верификации проекта, отчеты проекта.
  2.  Документатор. Состав и содержание документов проекта системы регламентируются комплексами стандартов и руководящих документов. CASE.Аналитик поддерживает следующие стандарты и руководящие документы:

Информационная технология. Комтекс стандартов и руководящих документов на автоматизированные системы.  М.: Госстандарт СССР, 1991г., – ГОСТы 34.ХХХ;

Единая система программной документации – ГОСТы 19.XXX.

Кроме того, оформление диаграмм при печати может быть выполнено в соответствии с требованиями ЕСКД: автоматически генерируется рамка и надписи.

5) Верификатор. Принципиальные решения по верификации проекта делает пользователь-аналитик. Эти решения аналитик принимает по результатам простых, но очень трудоемких процедур контроля и верификации, которые CASE.Аналитик выполняет автоматически и по запросу.
CASE.Аналитик предоставляет следующие средства верификации:

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

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

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

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

16.1. Особенности потоковых диаграмм информационно-логический модели