Главная
Коллекция "Revolution"
Программирование, компьютеры и кибернетика
Разработка и эксплуатация информационных систем
Разработка и эксплуатация информационных систем
Понятие жизненного цикла программного обеспечения. Методы и инструментальные средства проектирования. Проблема сложности больших систем. Типы связей между функциями. Моделирование потоков данных. Концептуальная основа объектно-ориентированного подхода.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | учебное пособие |
| Язык | русский |
| Дата добавления | 07.04.2014 |
| Размер файла | 5,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
выходной элемент приложения (отчет, документ, экранная форма);
запрос (пара "вопрос/ответ");
логический файл (совокупность записей данных, используемых внутри приложения);
интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Далее проект распределяется между различными командами разработчиков. (Опыт разработки крупных ЭИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.) В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода (см. главу 2) или диаграммы вариантов использования для объектно-ориентированного подхода (см. главу 3)). Результатом данной стадии должны быть:
общая информационная модель системы;
функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранных форм, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.
В отличие от имевшего место ранее подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую стадию передается более полная и полезная информация.
На стадии реализации выполняется непосредственно сама быстрая разработка приложения:
разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.);
пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ:
осуществляется анализ использования данных и определяется необходимость их распределения;
производится физическое проектирование базы данных;
формулируются требования к аппаратным ресурсам;
устанавливаются способы увеличения производительности;
завершается разработка документации проекта.
Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.
На стадии внедрения производятся обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Так как стадия реализации достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило на стадии проектирования системы. Приведенная схема разработки ЭИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка:
разрабатывается совершенно новая система;
уже было проведено обследование организации и существует модель ее деятельности;
в организации уже существует некоторая ЭИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой системой.
Следует, однако, отметить, что подход RAD, как и любой другой, не может претендовать на универсальность. Он хорош в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является законченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Подход RAD не применим для построения сложных расчетных программ, операционных систем или программ управления сложными объектами в реальном масштабе времени, т.е. программ, содержащих большой объем (сотни тысяч строк) уникального кода.
Не годится подход RAD и для приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложений реального времени), и приложений, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе совокупности функциональных точек. Подобная метрика не зависит от языка программирования, на котором ведется разработка. Ориентировочный состав команды разработчиков приложения, которое может быть выполнено на основе подхода RAD, для хорошо отлаженной среды разработки ЭИС с максимальным повторным использованием программных компонентов определяется следующим образом:
менее 1 тыс. функциональных точек - один человек;
от 1 до 4 тыс. функциональных точек - одна команда разработчиков;
более 4 тыс. функциональных точек - одна команда разработчиков на 4 тыс. функциональных точек.
Итак, перечислим основные принципы подхода RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждой стадии ЖЦПО;
обязательность вовлечения пользователей в процесс разработки ЭИС;
целесообразность применения CASE-средств, обеспечивающих целостность проекта и генерацию кода приложений;
целесообразность применения средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;
тестирование и развитие проекта, осуществляемые одновременно с разработкой;
ведение разработки немногочисленной хорошо управляемой командой профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
1.3 ПОНЯТИЯ МЕТОДА И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПО
1.3.1 ОПРЕДЕЛЕНИЕ МЕТОДА И ТЕХНОЛОГИИ
Методы и инструментальные средства проектирования (CASE-средства) составляют центральную часть формализованной дисциплины выполнения проекта любого ПО ЭИС. Метод проектирования ПО представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации.
На более формальном уровне метод определяется как совокупность следующих составляющих:
концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход;
нотаций, используемых для построения моделей статической структуры и динамики поведения проектируемой системы. В качестве таких нотаций обычно используются графические диаграммы, поскольку они наиболее наглядны и просты в восприятии (диаграммы потоков данных и диаграммы "сущность-связь" для структурного подхода, диаграммы вариантов использования, диаграммы классов и др. - для объектно-ориентированного подхода);
* процедуры, определяющей практическое применение метода (последовательность и правила построения моделей, критерии, используемые для оценки результатов).
Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО.
Технология проектирования ПО определяется как совокупность технологических операций проектирования (рис. 1.6) в их последовательности и взаимосвязи, приводящая к разработке проекта ПО.
1.3.2 ТРЕБОВАНИЯ К ТЕХНОЛОГИИ
Современная технология проектирования ПО ЭИС должна обеспечивать:
соответствие стандарту ISO/IEC 12207 (поддержка всех процессов ЖЦ ПО);
гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время;
возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 человек), с последующей интеграцией составных частей;
минимальное время получения работоспособного ПО ЭИС. Речь идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем. Реализация ПО ЭИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков. При этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ЭИС зачастую идет последовательно по отдельным подсистемам;
независимость получаемых проектных решений от средств реализации ЭИС (СУБД, операционных систем, языков и систем программирования);
поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Современные технологии поставляются, как правило, в электронном, виде вместе с CASE-средствами и включают библиотеки процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии включают также средства, которые должны обеспечивать их адаптацию для конкретных пользователей и развитие по результатам выполнения конкретных проектов.
Процесс адаптации заключается в удалении ненужных процессов и действий ЖЦ, компонентов методов, в изменении неподходящих или в добавлении собственных процессов и действий, а также методов, методик, стандартов и руководств. Настройка технологии может осуществляться также по следующим параметрам: стадии ЖЦ, участники проекта, используемые модели ЖЦ и др.
Электронные технологии (и поддерживающие их CASE-средства) составляют ядро комплекса согласованных инструментальных средств среды разработки ЭИС. Реальное применение любой технологии проектирования ПО ЭИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта (это особенно актуально при коллективной разработке ПО большим количеством групп специалистов). К таким стандартам относятся следующие:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт интерфейса конечного пользователя с системой.
Стандарт проектирования. Он должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм (включая требования к форме и размерам объектов) и т. д.;
требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств и т.д.;
механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила анализа проектных решений на непротиворечивость и т.д.
Стандарт оформления проектной документации. Он должен устанавливать:
комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127-94 "Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов");
требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.);
правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными правилами.
Стандарт интерфейса конечного пользователя с системой. Он должен регламентировать:
правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя.
Следует запомнить:
1. Одним из базовых понятий программной инженерии является понятие жизненного цикла программного обеспечения (ЖЦ ПО). Жизненный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наиболее распространенными моделями являются каскадная и спиральная.
Центральную часть формализованной дисциплины выполнения проекта любого ПО ЭИС составляют методы и инструментальные средства проектирования (CASE-средства). Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО.
Основные понятия:
Программная инженерия, программное обеспечение, жизненный цикл программного обеспечения, процессы жизненного цикла. Модель ЖЦ ПО, стадия ЖЦ ПО, каскадная модель, спиральная модель.
Метод, технология проектирования ПО.
Вопросы для самоконтроля:
Что такое жизненный цикл программного обеспечения?
Чем регламентируется ЖЦ ПО?
Какие группы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?
Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степени и почему?
Что понимается под стадией ЖЦ ПО и какие стадии входят в его состав?
Каково соотношение между стадиями и процессами ЖЦ ПО?
Каковы принципиальные особенности каскадной модели?
В чем заключаются преимущества и недостатки каскадной модели?
Каковы принципиальные особенности спиральной модели?
В чем состоят преимущества и недостатки спиральной модели?
Каким образом определяются метод и технология проектирования ПО?
Каким требованиям должна удовлетворять технология проектирования ПО?
Какие стандарты необходимы для выполнения конкретного проекта?
2. СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Вы узнаете:
Что представляет собой структурный подход к проектированию ПО.
В чем заключается метод функционального моделирования SADT.
Как строятся диаграммы потоков данных и "сущность- связь".
2.1 СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА
2.1.1 проблема сложности больших систем
Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как "разделяй и властвуй" (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие "правильная" по отношению к декомпозиции означает следующее:
количество связей между отдельными подсистемами должно быть минимальным;
связность отдельных частей внутри каждой подсистемы должна быть максимальной.
Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:
каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Инкапсуляция позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
2.1.2 СТРУКТУРНЫЙ ПОДХОД К РАЗРАБОТКЕ ПО
На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем. Первый подход называют функционально-модульным или структурным. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:
принцип "разделяй и властвуй" (см. подраздел 2.1.1);
принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются:
принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных;
принцип непротиворечивости - обоснованность и согласованность элементов системы;
принцип структурирования данных - данные должны быть структурированы и иерархически организованы.
В структурном подходе используются в основном две группы средств, описывающих функциональную структуру системы и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются:
DFD (Data Flow Diagrams) - диаграммы потоков данных;
SADT(Structured Analysis and Design Technique - метод структурного анализа и проектирования,) - модели и соответствующие функциональные диаграммы;
ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".
Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в CASE-средствах виды моделей.
Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.
На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели "AS-IS" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).
На стадии проектирования DFD используются для описания структуры проектируемой системы ПО, при этом они могут уточняться, расширяться и дополняться новыми конструкциями. Аналогично ERD уточняются и дополняются новыми конструкциями, описывающими представление данных на логическом уровне, пригодном для последующей генерации схемы базы данных. Данные модели могут дополняться диаграммами, отражающими системную архитектуру ПО, структурные схемы программ, иерархию экранных форм и меню и др.
Перечисленные модели в совокупности дают полное описание ПО ЭИС независимо оттого, является ли система существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от сложности системы и необходимой полноты ее описания.
Предметной областью для большинства примеров диаграмм, приведенных в данной главе, является налоговая система РФ, наиболее полное описание которой содержится в Налоговом кодексе РФ. Информационные технологии, применяемые в налоговой системе РФ, имеют определенные особенности.
2.2 МЕТОД ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ SADT
2.2.1 ОБЩИЕ СВЕДЕНИЯ
Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1973 г. Данный метод успешно использовался в военных, промышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, разработка ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEFO (Icam DEFinition) - подмножества SADT, являющегося основной частью программы ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США. IDEF0 был утвержден в качестве федерального стандарта США, его подробные спецификации можно найти на сайте http:/ /www.idef.com.
Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на следующих концепциях:
графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа-выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих "ограничения", которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;
строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков), связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных);
отделение организации от функции, т.е. исключение влияния административной структуры организации на функциональную модель.
Метод SADT может использоваться для моделирования самых разнообразных систем и определения требований и функций с последующей разработкой информационной системы, удовлетворяющей этим требованиям и реализующей эти функции. В существующих системах метод SADT может применяться для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются.
2.2.2 СОСТАВ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ
Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 2.1).
Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
На рис. 2.2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.
2.2.3 ПОСТРОЕНИЕ ИЕРАРХИИ ДИАГРАММ
Построение SADT-модели начинается с представления всей системы в виде простейшего компонента - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также соответствуют полному набору внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом в целях большей детализации.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма изображают одну и ту же часть системы.
На рис. 2.3 - 2.5 приведены различные варианты выполнения функций и соединения дуг с блоками.
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рис. 2.5).
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рис. 2.6).
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом формируется иерархия диаграмм.
Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2.
Аналогично диаграмма А2 детализирует блок А2 на диаграмме АО, которая является самой верхней диаграммой модели. На рис. 2.7 показан пример дерева диаграмм.
2.2.4 типы связей между функциями
Одним из важных моментов при моделировании бизнес-процессов организации с помощью метода SADT является точная согласованность типов связей между функциями. Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):
случайная;
логическая;
временная;
процедурная;
коммуникационная;
последовательная;
функциональная.
Случайная связь - показывает, что конкретная связь между функциями незначительна или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют слабую связь друг с другом. Крайний вариант этого случая показан на рис. 2.8.
Логическая связь - данные и функции собираются вместе благодаря тому, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
Временная связь - представляет функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
Процедурная связь (рис. 2.9) - функции сгруппированы вместе благодаря тому, что они выполняются в течение одной и той же части цикла или процесса.
Коммуникационная связь - функции группируются благодаря тому, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рис. 2.10).
Последовательная связь - выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем в рассмотренных выше случаях, поскольку моделируются причинно-следственные зависимости (рис. 2.11).
Функциональная связь - все элементы функции влияют на выполнение одной и только одной функции. Диаграмма, являющаяся чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связи. Одним из способов определения функционально связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рис. 2.12.
В математических терминах необходимое условие для простейшего типа функциональной связи (см. рис. 2.12) имеет следующий вид:
С = g(B) = g(f(A)).
В табл. 2.1 представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4 - 6 устанавливают типы связей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.
Таблица 2.1
Описание типов связей
|
Уровень значимости |
Тип связи |
Характеристика типа связи |
||
|
для функций |
для данных |
|||
|
0 |
Случайная |
Случайная |
Случайная |
|
|
1 |
Логическая |
Функции одного и того же множества или типа (например, "редактировать все входы") |
Данные одного и того же множества или типа |
|
|
2 |
Временная |
Функции одного и того же периода времени (например, "операции инициализации") |
Данные, используемые в каком-либо временном интервале |
|
|
3 |
Процедурная |
Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") |
Данные, используемые во время одной и той же фазы или итерации |
|
|
4 |
Коммуникационная |
Функции, использующие одни и те же данные |
Данные, на которые воздействует одна и та же деятельность |
|
|
5 |
Последовательная |
Функции, выполняющие последовательные преобразования одних и тех же данных |
Данные, преобразуемые последовательными функциями |
|
|
6 |
Функциональная |
Функции, объединяемые для выполнения одной функции |
Данные, связанные с одной функцией |
2.3 моделирование потоков данных (ПРОЦЕССОВ)
2.3.1 ОБЩИЕ СВЕДЕНИЯ
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Диаграммы потоков данных известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м гг. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой два клерка, обменивающихся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии друг от друга. Так появилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD.
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордана и Гейна - Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. Далее при построении примеров будет использоваться нотация Гейна - Сэрсона.
В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации.
2.3.2 СОСТАВ ДИАГРАММ ПОТОКОВ ДАННЫХ
Основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы и подсистемы;
процессы;
накопители данных;
потоки данных.
Внешняя сущность представляет собой материальный объект или физическое лицо, представляющие собой источник или приемник информации, например заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 2.13), расположенным как бы над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений.
При построении модели сложной ЭИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо может быть декомпозирована на ряд подсистем (рис. 2.14).
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображен на рис. 2.15.
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о налогоплательщиках", "Выдать информацию о текущих расходах", "Проверить поступление денег".
Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать", означает недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных - это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных на диаграмме потоков данных (рис. 2.16) идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью (ERD).
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой, и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рис. 2.17). Каждый поток данных имеет имя, отражающее его содержание.
2.3.3 ПОСТРОЕНИЕ ИЕРАРХИИ ДИАГРАММ ПОТОКОВ ДАННЫХ
Главная цель построения иерархии DFD заключается в том, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один процесс или два;
не загромождать диаграммы не существенными на данном уровне деталями;
декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой;
выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы.
Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному (или более) потоку данных: входные потоки интерпретируются как воздействия, а выходные потоки - как реакции системы на входные потоки.
Если для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и, кроме того, единственный главный процесс не раскрывает структуры такой системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более), распределенная природа системы, многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных систем строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует система.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ЭИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в создании которых участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. При детализации должны выполняться следующие правила:
правило балансировки - при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников или приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеют информационную связь детализируемые подсистема или процесс на родительской диаграмме;
правило нумерации - при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк). Спецификации должны удовлетворять следующим требованиям:
для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;
спецификация должна определять способ преобразования входных потоков в выходные;
нет необходимости (по крайней мере на стадии формирования требований) определять метод реализации этого преобразования;
спецификация должна стремиться к ограничению избыточности - не следует переопределять то, что уже было определено на диаграмме;
набор конструкций для построения спецификации должен быть простым и понятным.
Фактически спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Спецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое количество разнообразных методов, позволяющих описать тело процесса. Соответствующие этим методам языки могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования.
Структурированный естественный язык применяется для читабельного, достаточно строгого описания спецификаций процессов. Он представляет собой разумное сочетание строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм.
В состав языка входят следующие основные символы:
глаголы, ориентированные на действие и применяемые к объектам;
термины, определенные на любой стадии проекта ПО (например, задачи, процедуры, символы данных и т.п.);
предлоги и союзы, используемые в логических отношениях;
общеупотребительные математические, физические и технические термины;
арифметические уравнения;
таблицы, диаграммы, графы и т.п.;
комментарии.
К управляющим структурам языка относятся последовательная конструкция, конструкция выбора и итерация (цикл).
При использовании структурированного естественного языка приняты следующие соглашения:
логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций;
глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие {заполнить, вычислить, извлечь, а не модернизировать, обработать);
логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается с помощью структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области). Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение показывает, что данный компонент может отсутствовать в структуре (например, структура "данные о страховании" для объекта "служащий"). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация предусматривает вхождение любого числа элементов в указанном диапазоне (например, элемент "имя ребенка" для объекта "служащий"). Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
2.4 СРАВНИТЕЛЬНЫЙ АНАЛИЗ SADT-МОДЕЛЕЙ И ДИАГРАММ ПОТОКОВ ДАННЫХ
Как уже отмечалось, практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:
диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0);
диаграммы, моделирующие данные и их отношения (ERD).
Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа могут быть разбиты на две группы - использующие DFD (в различных нотациях) и использующие SADT-модели. Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет 90% для DFD и 10% для SADT. Вероятно, соотношение такого же порядка справедливо и для распространенности рассматриваемых моделей на практике.
Сравнительный анализ этих двух разновидностей методов структурного анализа проводится по следующим параметрам:
...Подобные документы
Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.
курсовая работа [686,9 K], добавлен 13.12.2010Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат [36,1 K], добавлен 29.04.2010Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.
презентация [152,1 K], добавлен 07.12.2013Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
курсовая работа [1,8 M], добавлен 20.11.2010Основы методологии проектирования информационных систем, понятие их жизненного цикла. Основные модели жизненного цикла. Методология функционального моделирования SADT. Состав функциональной модели. Моделирование данных, характеристика case-средств.
реферат [327,5 K], добавлен 28.05.2015Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).
курсовая работа [1,1 M], добавлен 13.05.2014Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Создание функциональной структуры фирмы. Методологии проектирования информационных систем. Состав стандарта IDEF. Средства структурного системного анализа. Метод функционального моделирования SADT. Стратегии декомпозиции. Диаграмма потоков данных DFD.
презентация [324,1 K], добавлен 27.12.2013Развитие информационных систем. Современный рынок финансово-экономического прикладного программного обеспечения. Преимущества и недостатки внедрения автоматизированных информационных систем. Методы проектирования автоматизированных информационных систем.
дипломная работа [1,5 M], добавлен 22.11.2015Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
презентация [874,4 K], добавлен 19.09.2016Создание программного обеспечения - системы имитационного моделирования на тему "Производственная линия с пунктами технического контроля". Описание входных и выходных данных. Объектно-ориентированное программирование. Диаграммы модулей и процессов.
курсовая работа [1,2 M], добавлен 09.01.2014Общая характеристика объектно-ориентированного подхода в программировании, его основные свойства и принципы. Разработка программы для автоматизация деятельности кафе на основе объектно-ориентированного подхода, проектирования и реализации схемы данных.
курсовая работа [1,2 M], добавлен 22.01.2012Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.
курсовая работа [2,7 M], добавлен 23.06.2011Разработка программного обеспечения для управления базой данных. Место задачи в системе автоматизации. Семантическое моделирование данных. Разработка программного обеспечения и базы данных. Расчет трудоемкости и себестоимости этапов проектирования.
дипломная работа [2,9 M], добавлен 04.02.2016Общая характеристика структурного программирования. Использование конструкций цикла и условного оператора. Методология функционального моделирования SADT, ее основные элементы. Типы связей между функциями. Моделирование потоков данных (процессов).
дипломная работа [704,7 K], добавлен 20.10.2009История развития информационных технологий. Классификация, виды программного обеспечения. Методологии и технологии проектирования информационных систем. Требования к методологии и технологии. Структурный подход к проектированию информационных систем.
дипломная работа [1,3 M], добавлен 07.02.2009Задачи системы электронного документооборота. Анализ существующих информационных систем. Методы и средства инженерии программного обеспечения. Концептуальная модель данных в BPWin. Построение инфологической модели системы документооборота "Doc_Univer".
курсовая работа [56,1 K], добавлен 25.03.2014Анализ тенденций развития информационных технологий. Назначение и цели применения систем автоматизированного проектирования на основе системного подхода. Методы обеспечения автоматизации выполнения проектных работ на примере ЗАО "ПКП "Теплый дом".
курсовая работа [210,0 K], добавлен 11.09.2010Цель инфологического моделирования предметной области. Источники данных, базы данных и система управления, разработка модели. Принципы проектирования базы данных, концептуальная, логическая, материальная разработка. Типы сущностей, атрибутов и связей.
курсовая работа [188,6 K], добавлен 15.07.2012
