Учебная работа. Реферат: CASE-технологии проектирования автоматизированных информационных систем

Учебная работа. Реферат: CASE-технологии проектирования автоматизированных информационных систем

Федеральное агентство по образованию

Федеральное государственное образовательное учреждение Высшего проф образования «Чувашский муниципальный институт им. И.Н.Ульянова»

Финансово — экономический институт

Экономический факультет

Реферат на тему:
CASE-технологии проектирования автоматических информационных систем

Выполнила студентка

Группы ЭК 22-06

Евграфова И.А

Проверила: Павлова С.Ю.

Чебоксары 2007

Содержание

· Введение……………………………………………………………..3

· Актуальный цикл программного обеспечения информационной системы……………………………………………………………….5

· RAD-технологии прототипного сотворения приложений……………7

· Структурный способ разработки программного обеспечения……10

· Использованная литература………………………………………..17

Введение

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

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

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

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

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

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

♦ облагораживают свойство создаваемого ПО за счет средств автоматического контроля (до этого всего контроля про­екта);

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

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

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

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

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

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

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

1. Актуальный цикл программного обеспечения информационной системы

Одним из базисных понятий методологии проектирования АИС является понятие актуального цикла ее программного обеспечения (ЖЦ ПО ). ЖЦ ПО — это непрерывный процесс, который начинается с момента принятия решения о необхо­димости его сотворения и завершается в момент его полного изъятия из эксплуатации [6].

структура ЖЦ ПО базируется на 3-х группах процес­сов:

♦ главные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

♦ организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оцен­ка и улучшение самого ЖЦ, обучение ).

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

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

Управление проектом соединено с вопросцами планирова­ния и организации работ, сотворения обществ разработчи­ков и контроля за сроками и качеством выполняемых работ.

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

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

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

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

♦ каскадная модель (1970—1980 гг.) — дает пере­ход на последующий шаг опосля полного окончания работ по предшествующему шагу;

♦ поэтапная модель с промежным контролем (1980—1985 гг.) — итерационная модель разработки ПО с циклами оборотной связи меж шагами. Преимуще­ство таковой модели состоит в том, что межэтап­ные корректировки обеспечивают наименьшую трудоем­кость по сопоставлению с каскадной моделью, но вре­мя жизни всякого из шагов растягивается на весь пе­риод разработки;

♦ спиральная модель (1986—1990 гг.) — делает упор на исходные этапы ЖЦ: анализ требований, проектиро­вание спецификаций, предварительное и детализированное про­ектирование. На этих шагах проверяется и обосновыва­ется реализуемость технических решений методом созда­ния прототипов. Любой виток спирали соответствует поэтапной модели сотворения фрагмента либо версии про­граммного изделия, на нем уточняются цели и характе­ристики проекта, определяется его свойство, планиру­ются работы последующего витка спирали. Таковым обра­зом, углубляются и поочередно конкретизируют­ся детали проекта и в итоге выбирается обосно­ванный вариант, который доводится до реализации.

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

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

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

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

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

2.
RAD
—технологии прототипного сотворения приложений

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

♦ маленькую команду программистов (от 2 до 10 чело­век);

♦ маленький, но кропотливо проработанный производствен­ный график (от 2 до б мес);

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

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

Актуальный цикл ПО по методологии RAD состоит из 4 фаз:

♦ фазы анализа и планирования требований;

♦ фазы проектирования;

♦ фазы построения;

♦ фазы внедрения.

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

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

Опосля детализированного определения состава действий оцени­вается количество многофункциональных частей разрабатыва­емой системы и принимается решение о разделении АИС на подсистемы, поддающиеся реализации одной командой раз­работчиков за применимое для RAD-проектов время — приблизительно 60—90 дней. С внедрением CASE-средств проект распределяется меж разными командами (делится фун­кциональная модель). Результатом данной фазы должны быть:

♦ общая информационная модель системы;

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

♦ буквально определенные при помощи CASE-средства интер­фейсы меж автономно разрабатываемыми подсисте­мами;

♦ построенные макеты экранов, отчетов, диалогов.

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

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

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

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

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

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

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

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

♦ определяются методы роста производительности;

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

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

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

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

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

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

♦ разработка приложений итерациями;

♦ необязательность полного окончания работ на каж­дом из шагов актуального цикла;

♦ непременное вовлечение юзеров в процесс раз­работки АИС;

♦ нужное применение CASE-средств, обеспечива­ющих целостность проекта;

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

♦ нужное внедрение генераторов кода;

♦ внедрение прототипирования, позволяющего пол­нее узнать и удовлетворить потребности конечного юзера;

♦ тестирование и развитие проекта, осуществляемые сразу с разработкой;

♦ ведение разработки малочисленной отлично управ­ляемой командой экспертов;

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

3. Структурный способ разработки программного обеспечения

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

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

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

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

2. Принцип формализации — заключается в нужно­сти серьезного методического подхода к решению задачи.

3. Принцип «упрятывания» — заключается в упрятыва­нии несущественной на определенном шаге инфы: каж­дая часть «понимает» лишь нужную ей информацию.

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

5. Принцип полноты — заключается в контроле присут­ствия излишних частей.

6. Принцип непротиворечивости — заключается в обо­снованности и согласованности частей.

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

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

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

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

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

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

♦ SADT (Structured Analysis and Design Technique) — модели и надлежащие многофункциональные диаграм­мы;

♦ DFD (Data Flow Diagrams) — диаграммы потоков дан­ных;

♦ ERD (Entity-Relationship Diagrams) — диаграммы»сущ-ность—связь»;

♦ STD (State Trasition Diagrams) — диаграммы переходов состояний.

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

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

Методология

SADT

Методология SADT разработана Дугласом Россом, на ее базе разработана, а именно, популярная методология IDEFO (Icam Definition), которая является главный частью программки Icam (Интеграция компьютерных и промышлен­ных технологий), проводимой по инициативе США

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

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

Правила SADT включают:

♦ ограничение количества блоков на любом уровне де­композиции (правило 3—б блоков);

♦ связность диаграмм (номера блоков);

♦ неповторимость меток и наименований (отсутствие по­вторяющихся имен);

♦ синтаксические правила для графики (блоков и дуг);

♦ разделение входов и управлений (правило определе­ния роли данных);

♦ отделение организации от функции, т. е. исключение воздействия организационной структуры на функциональ­ную модель.

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

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

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

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

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

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

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

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

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

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

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

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

Моделирование потоков данных (действий)

Главным средством моделирования многофункциональных требований АИС являются диаграммы потоков данных (DFD:— Data Flow Diagrams). С помощью их эти требования разбива­ются на многофункциональные составляющие (процессы) и представ­ляются в виде сети, связанной потоками данных. Основная цель таковых средств — показать, как любой процесс конвертирует свои входные данные в выходные, также вы­явить дела меж этими действиями.

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

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

♦ наружные сути;

♦ системы/подсистемы;

♦ процессы;

♦ накопители данных;

♦ потоки данных.

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

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

♦ «Ввести сведения о клиентах»;

♦ «Выдать информацию о текущих расходах»;

♦ «Проверить кредитоспособность клиента«.

Внедрение таковых глаголов, как «обработать