4064

Проектирование автоматизированных систем. Конспект лекций

Конспект

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

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

Русский

2012-11-12

227 KB

72 чел.

Введение

1. Общие сведения об автоматизированных системах управления. Понятие об АСУ, основные определения, классификация

Особенности современных систем.

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

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

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

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

Описание целей и объекта проектирования.

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

2. Основные определения.

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Классификация систем управления

Автоматические системы регулирования (АСР) предназначены для поддержания значений технологических параметров на заданном уровне или их изменение по заданному закону.

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

Автоматизированные системы управления технологическими процессами (АСУТП) предназначены для ведения ТП отдельного аппарата, установки в соответствии с заданным технологическим режимом с участием человека на основе современных технико-экономических средств и методов. Цель управления - поддержание заданных значений регулируемых величин, оптимизация координат ОУ.

Автоматизированные системы управления предприятиями и/или производствами (АСУП) это АСУ, предназначенные для решения основных задач управления производственно-хозяйственной деятельностью промышленного предприятия и его самостоятельных частей на основе применения экономико-математических методов и современных средств вычислительной техники.

Если АСУП включает в свой состав подсистемы управления нижнего уровня и подсистемы управления верхним уровнем, то такие АСУ называют интегрированным

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

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

Лекция № 2

«Цель и анализ процесса проектирования»

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

4.Этапы планирования проекта

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

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

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

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

5. Контроль выполнения проекта

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

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

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

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

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

6. Этапы проектирования

Основными этапами проектирования являются:

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

Выбор конкретного варианта и его реализация.

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

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

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

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

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

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

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

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

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

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

Он основан на:

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

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

Лекция № 3-4

«ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ПРОЕКТА»

Содержание:

  1.  Понятие информационной системы обеспечения проекта
  2.  Концепция информационной системы
  3.  Стратегическое планирование проекта информационной системы
  4.  Особенности современных крупных проектов информационных систем
  5.  Сложности при реализации проекта

8. Понятие информационной системы обеспечения проекта

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

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

Регулярный обмен информацией позволяет осуществлять:

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

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

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

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

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

9. Концепция информационной системы

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

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

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

10. Стратегическое планирование проекта информационной системы

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

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

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

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

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

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

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

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

11. Особенности современных крупных проектов информационных систем (14)

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

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

12. Сложности при реализации проекта (15)

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

Лекция №5

13. Цель системного проектирования сложных комплексов программ

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

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

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

14.  Этапы системного проектирования

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

  1.  обобщенный  анализ  проведенного обследования  объекта информатизации, функций существующей информационной системы, качества ее основных программных компонентов и базы данных;
  2.  совокупность предварительных исходных требований к функциям и характеристикам качества комплекса программ;
  3.  оценки имеющихся и потенциально доступных ресурсов (финансовых, вычислительных средств, специалистов) для обеспечения всего жизненного цикла и требуемого качества проекта комплекса программ;
  4.  результаты предварительного анализа архитектуры комплекса программ на основе моделей и прототипов аналогичных систем, позволяющие наметить планы разработки и  жизненный цикл проекта программных средств;
  5.  цели, задачи и функции предполагаемой новой или модернизированной информационной системы, обобщенные в концепции создания соответствующего программного средства;
  6.  проекты  планов  жизненного   цикла,   гарантирования  требуемого качества программного средства, защиты и обеспечения безопасности его
    функционирования;
  7.  результаты  технико-экономического  обоснования  целесообразности и основных направлений продолжения проектирования и всего жизненного цикла программного средства;
  8.  результаты анализа существующей и возможной инструментальной среды разработки, а также системы обеспечения качества, перспективы их развития и совершенствования;
  9.  предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла программного средства;
  10.  проект формализованного технического задания и спецификации требований к программному средству, а также предложения по его финансированию и обеспечению ресурсами;
  11.  системный проект, обобщающий проведенные исследования и разработки,  позволяющий заключить контракт между разработчиком и заказчиком на финансирование и продолжение проектирования и/или на весь жизненный цикл программного средства.

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

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

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

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

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

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

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

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

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

16. Методы структурного проектирования программ

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

нисходящего проектирования - сверху вниз;

восходящего проектирования - снизу вверх;

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

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

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

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

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

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

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

Лекция №6

CASE-ТЕХНОЛОГИИ И CASE-СРЕДСТВА

 

Содержание:

  1.  Понятие CASE – технологий и CASE – средств.
  2.  Особенности CASE-технологий.

  1.   Понятие CASE – технологий и CASE – средств.

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

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

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

1. подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

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

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

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

18. Особенности CASE-технологий

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

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

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

  1.  широкое разнообразие качества и возможностей CASE-средств;
  2.  относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
  3.  широкое разнообразие в практике внедрения различных организаций;
  4.  отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
  5.  широкий диапазон предметных областей проектов;
  6.  различная степень интеграции CASE-средств в различных проектах.

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

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

  1.  Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
  2.  Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
  3.  Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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

  1.  достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки программного обеспечения;
  2.  внедрение CASE-средств может представлять собой достаточно длительный процесс и может не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;
  3.  отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;
  4.  CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому;
  5.  некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение;
  6.  негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

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

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

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

- приемлемый уровень отдачи от инвестиций в CASE-средства.

Лекция № 7-8

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

Содержание:

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

2. Требования, устанавливаемые стандартами для технологии проектирования.

3. Методология быстрой разработки приложений RAD.

4. Области применения методологии RAD.

5. Основные принципы методологии RAD.

6. Методология функционального моделирования SADT.

7. Состав функциональной модели по методологии SADT.

8. Типы связей между функциями при проектировании информационных систем по методологии SADT.

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

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

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

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

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

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

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

21. Требования, устанавливаемые стандартами для технологии проектирования

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

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

Стандарт проектирования должен устанавливать:

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

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

22. Методология быстрой разработки приложений RAD

Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином понимается процесс разработки программного обеспечения, содержащий 3 элемента:

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

  1.  фаза анализа и планирования требований;
  2.  фаза проектирования;
  3.  фаза построения;
  4.  фаза внедрения.

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

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

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

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

Результатом данной фазы должны быть:

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

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

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

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

Завершается физическое проектирование системы:

- определяется необходимость распределения данных;

- производится анализ использования данных;

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

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

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

- завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

23. Области применения методологии RAD

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

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

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

24. Основные принципы методологии RAD

К основным принципам методологии RAD относятся:

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

25. Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий).

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

  •  графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения»;
  •  строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
  •  ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
  •  связность диаграмм (номера блоков);
  •  уникальность меток и наименований (отсутствие повторяющихся имен);
  •  синтаксические правила для графики (блоков и дуг);
  •  разделение входов и управлений (правило определения роли данных).
  •  отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

26. Состав функциональной модели по методологии SADT

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

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

Р и с у н о к.  Функциональный блок и интерфейсные дуги

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

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

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

27. Типы связей между функциями при проектировании информационных систем по методологии SADT

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

Тип связи

Относительная значимость

Случайная

0

Логическая

1

Временная

2

Процедурная

3

Коммуникационная

4

Последовательная

5

Функциональная

6

(0) Тип случайной связности: наименее желательный. Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом.

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

(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса.

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

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

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

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

Значимость

Тип связности

Для функций

Для данных

0

Случайная

Случайная

Случайная

1

Логическая

Функции одного и того же множества или типа (например, "редактировать все входы")

Данные одного и того же множества или типа

2

Временная

Функции одного и того же периода времени (например, "операции инициализации")

Данные, используемые в каком-либо временном интервале

3

Процедурная

Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора")

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

4

Коммуникацион-ная

Функции, использующие одни и те же данные

Данные, на которые воздействует одна и та же деятельность

5

Последовательная

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

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

6

Функциональная

Функции, объединяемые для выполнения одной функции

Данные, связанные с одной функцией


 

А также другие работы, которые могут Вас заинтересовать

45128. What do you do on the Net? What are your favorite websites? 15.06 KB
  I cfn spend lot of free time surfing the Internet nd get ll sorts of informtion from it. You cn enter the cht the Internet nd get ll sorts of informtion from it. I cn enter the cht room with other Internet users nd debte urgent problems on line.
45129. The Internet 13.99 KB
  The Internet is sves time nd money. The Internet hs both dvntges nd disdvntges. However using the Internet in the best wy is problem which depends on the ttitude of ech people I think tht in our society nowdys so mny people tke dvntge of the Internet even to do bd things.
45130. About Myself 14.65 KB
  When I ws pupil my fvorite subjects ws History nd Society becuse I hd wnted to become lwyer. My fvorite supervisors re Jmes Cmeron Gy Richy Peter Jckson nd Leonid Gidi. My fvorite footbll tems re Mnchester United nd CSK. I like reding; my fvorite writers re Jorge Orwell for his “1984†Ioghn Wolfgng Gete for “Fust†nd Plto for “Stteâ€.
45131. Barristers and Solicitors 18.78 KB
  The solicitor deals with 1)petty crimes, some 2)matrimonial matters in magistrate courts. He 3)prepares the case and the evidence, may 4)represent his client in the lower courts. He has limited rights of audience. There in civil action solicitor can speak in the county court, when the case is about divorce or recovering some depts. 5)They act as an intermediary between their clients and barristers
45132. Barristers 13.19 KB
  Baristers ct s sole trders with unlimited libility. Some brristers re employed prctice nd represent their employer for exmple inhouse lwyer or lwyer in government bodies. Mny of the brristers work in selfemployed prctice t the chmbers or t the Br. The Inns re noncdemic societies which provide collegite nd eductionl resources for brristers nd trinees.
45133. British Political System 16.82 KB
  Queen Elizbeth II is the fourth sovereign of the House of Windsor. It consists of two chmbers known s the House of Commons nd House of Lords nd the Queen s its hed but only House of Commons hve rel power. The House of Commons consist of 650 elected members nd it’s persisted over by the Speker. Only four members House of Commons hve reserved sets: Speker Prime Minister leder of the prty tht hs mjority in the House of Commons nd Leder of the Opposition nd member who hs st in the House of Commons for the longest unbroken period who clled...
45134. British Parliament 13.87 KB
  It consists of two chmbers known s the House of Commons nd House of Lords nd the Queen s its hed but only House of Commons hve rel power. The House of Commons consist of 650 elected members nd it’s persisted over by the Speker. Only four members House of Commons hve reserved sets: Speker Prime Minister leder of the prty tht hs mjority in the House of Commons nd Leder of the Opposition nd member who hs st in the House of Commons for the longest unbroken period who clled Fther of the House of Commons. The House of Lords consist of 750...
45135. Geography and Economy of Great Britain 16.75 KB
  They lie to the west of the continent of Europe. The lrger of the two big islnds is known s Gret Britin. The smller Islnd is Irelnd with Northern Irelnd nd Irish Republic.
45136. Просвещенный абсолютизм Екатерины II 20.12 KB
  Время царствования Екатерины II называют эпохой просвещенного абсолютизма. Основы просвещённого абсолютизма: человек есть самое ценное на земле и его свобода важнее интересов государства; все люди равны в своих человеческих правах невзирая на сословные различия; общество нуждается в совершенствовании и важнейшую роль должны сыграть в этом наука просвещение законотворчество. Время царствования Екатерины II называют эпохой просвещенного абсолютизма . Смысл просвещенного абсолютизма состоит в политике следования идеям Просвещения...