Что такое CASE-СРЕДСТВАCASE-средства (от англ.Computer-Aided Software
Engineering) -– это инструментальные средства
автоматизации проектирования ИС.
CASE-СРЕДСТВА это методы программной инженерии для
проектирования программного обеспечения, которые
позволяют обеспечить высокое качество программ,
отсутствие ошибок и простоту в обслуживании
программных продуктов.
Также под CASE понимают совокупность средств
проектирования информационных систем с
использованием CASE-инструментов.
Case средства
К Case средствам относят любое ПО, котороеавтоматизирует различные этапы Жизненного цикла
ПО и обладает следующими характеристиками:
1. Имеется мощное графическое средство для
описания ИС, которое обеспечивает удобство работы
пользователя,
2. Присутствует интеграция отдельных компонентов
Case- средства,
3. Используется централизованное хранилище
проектных данных Репозиторий.
Функции проектирования, которые наиболее часто автоматизируемые в рамках CASE-средств:
-анализ и формулировка требований к ИС;
проектирование баз данных и приложений;
генерация программного кода;
тестирование;
обеспечение качества ПО;
управление конфигурацией ИС;
управление проектом и др.
Результат применения CASE-средств:
оптимизация структуры ИС;снижение расходов на разработку;
повышение эффективности ИС;
снижение вероятности ошибок при
проектировании ИС.
Архитектура типового Case-средства
Репозиторий
Ядром любой системы проектирования ПО является репозиторий.Репозиторий представляет собой специализированную БД,
которая используется для отображения состояния системы в любой момент
времени и содержит информацию о всех объектах проектной ИС:
Имена проектировщиков и их права доступа,
Организованные структуры,
Компоненты диаграмм и диаграммы в целом,
Структуры данных,
Взаимосвязи между диаграммами,
Программные модули, процедуры и библиотеки модулей.
Классификация Современных Case средств:
1. Классификация Case средств поподдерживаемым методологиям:
-
функциональные или структурно-ориентированные;
-
объектно-ориентированные;
-
комплексно-ориентированные.
2. Классификация Современных Case средств по типам:
Отражает функциональную ориентацию средств напроцессы жизненного цикла разработки программного
обеспечения:
средства анализа - предназначены для построения и
анализа модели предметной области;
средства проектирования баз данных;
средства разработки приложений;
Средства реинжиниринга процессов;
средства планирования и управления проектом;
средства тестирования;
средства документирования.
Примеры Case-средств различных типов:
Средства анализа (Design, BpWin);Средства анализа и проектирования (Designer - Oracle);
Средства проектирования БД (ErWin, Designer - Oracle);
Средства разработки приложений (Developer – Oracle,
Delphi);
Средства реинженеринга (ErWin, Rational Rose).
3. Классификация Современных Case средств по категориям:
Определяет выполняемые инструментами функции и включает:отдельные локальные средства, решающие небольшие автономные
задачи, набор частично интегрированных средств, охватывающих
большинство этапов жизненного цикла и полностью интегрированные
средства, охватывающие весь жизненный цикл информационной
системы и связанные общим репозиторием.
Типичными CASE-инструментами являются:
инструменты управления конфигурацией;
инструменты моделирования данных;
инструменты анализа и проектирования;
инструменты преобразования моделей;
инструменты редактирования программного кода;
генераторы кода;
инструменты для построения UML-диаграмм.
Другие виды классификации Case-средств:
4.Классификация Case-средств по поддерживаем
графическим нотациям;
5.
Классификация Case-средств по степени
интегрированности отдельных инструментов;
6.
Классификация Case-средств по типу и архитектуре
используемой вычислительной техники;
7.
Классификация Case-средств по типу коллективной
разработки;
8.
Классификация Case-средств по типу используемой
операционной среды.
При выборе Case средств необходимо учитывать следующие аспекты:
Наличие БД, архива или словаря;Наличие интерфейсов с другими Case системами;
Возможности экспорта и импорта информации;
Открытая архитектура;
Наличие необходимых методологий;
Наличие графических средств поддержки проекта;
Возможность автоматической генерации кода программ;
Возможность планирование и управление проектом.
Case-средство Универсальный язык моделирования UML
Создание языка UML преследовало следующие цели:предоставить разработчикам единый язык визуального
моделирования;
предусмотреть механизмы расширения и специализации языка;
обеспечить независимость языка от языков программирования и
процессов разработки.
Взаимосвязь диаграмм UML
Диаграмма вариантовиспользования
Диаграмма
последовательности
Диаграмма
классов
Диаграмма
кооперации
Диаграмма
компонентов
Диаграмма
состояний
Диаграмма
развертывания
Диаграмма
видов деятельности
Case-средство IBM Rational Rose
Rational Rose - современное и мощное средство анализа,моделирования и разработки программных систем,
охватывающее весь Жизненный цикл ПО
от анализа бизнес-процессов до кодогенерации на
заданном языке программирования.
Такой арсенал позволяет не только проектировать новую
информационную систему, но и доработать старую,
произведя процесс обратного проектирования.
Основные возможности пакета Rational Rose:
прямое и обратное проектирование на языках: ADA,Java, С, C++, Basic;
поддержка технологий COM, DDL, XML;
возможность генерации схем БД Oracle и SQL.
Версии продукта Rational Rose:
Версия Rational Rose Modeler позволяет проводить анализ бизнес-процессов ипроектировать систему. Но не поддерживает кодогенерацию.
Версия Rational Rose Professional В зависимости от выбранного языка программирования
позволяет выполнять прямое и обратное проектирование. Заказывается только в
определенной конфигурации (например, Rose Professional С++ или Rose Professional С++
DataModeler). Не создает 100 % исполняемого кода. На выходе разработчик получает
каркасный код информационной системы на определенном (заказанном) языке
программирования, который впоследствии нужно еще дорабатывать.
Версия Rational Rose RealTime создана специально для получения 100 % исполняемого
кода в реальном масштабе времени, позволяет проводить прямое и обратное
проектирование на языках С или С++. На выходе модель автоматически компилируется
и собирается в исполняемый файл.
Версия Rational Rose Enterprise эта версия продукта покрывает весь спектр задач по
проектированию, анализу и кодогенерации. Поддерживаются все функции других
редакций, за исключением возможности 100 % кодогенерации.
Версия Rational Rose DataModeler вариант продукта по проектированию баз данных.
Функции DataModeler входят в состав Rose Enterprise или Professional.
В пакет MS Visual Studio 6.0 встроен Visual Modeler - усеченный вариант Rational Rose 98.
Дополнительная информация по пакету Rational Rose:
Бесплатной версии продукта Rational Rose несуществует;
для образовательных учреждений все программное
обеспечение IBM доступно бесплатно;
бесплатное использованиея в учебных целях возможно
в рамках программы IBM Academic Initiative.
Значительно лучше соответствуют большой размерности задачи иерархические CASE-модели. Аббревиатура CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки.
CASE-технология - актуальное и интенсивно развивающееся направление создания САПР в области программных продуктов и систем обработки информации. Практически ни один крупный зарубежный программный продукт не создается в настоящее время без использования CASE-средств.
Среди отечественных систем, созданных с использованием CASE-средств, следует отметить систему БОСС-КОРПОРАЦИЯ фирмы АйТи. На всех стадиях создания этой системы использовались средства разработки, относящиеся к семейству Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).
Область применения CASE-технологий относится к созданию, прежде всего, экономических информационных систем, что объясняется массовостью этих систем.
Следует отметить, что CASE-технологий применяются не только для создания автоматизированных систем управления, но и для разработки моделей систем, помогающих в принятии решений в области стратегического планирования, управления финансами фирмы, обучения персонала и т.д. Это направление применения CASE-технологий получило свое собственное название - бизнес-анализ.
CASE-технологий применяются также там, где проблематика предметной области отличается большой сложностью, например, в разработке системного программного обеспечения.
Рассмотрим методологические основы CASE-технологий.
Основой CASE-методологии является моделирование. CASE-технология - это модельный метод автоматизации проектирования системы.
CASE-технология основана на парадигме: методология - метод - нотации - средства
Методология определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, подходы к выбору методов.
Метод конкретизирует порядок проектирования отдельных компонентов системы (например, известны методы проектирования потоков данных в системе, задания спецификаций (описаний) процессов, представления структур данных в хранилище и т.д.).
Нотации - это графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации, структуры данных и т. д. Нотации включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки.
Наконец, средства - это инструментарии, средства автоматизации проектирования в виде программных продуктов для обеспечения интерактивного режима проектирования (создание и редактирование графического проекта информационной системы) и кодогенерацни программ (автоматического создания кодов программ системы).
Методология проектирования на основе компьютерной поддержки, очевидно, требует построения формализованного описания информационной системы в виде информационной модели. Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.
Модель системы должна отражать:
Функциональную часть системы;
Отношения между данными;
Переходы состояний системы при работе в реальном времени. Для моделирования информационной системы в трех указанных аспектах используются три разновидности графических средств с определенными нотациями.
1. Диаграммы потоков данных - DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.
2. Диаграммы „сущность-связь" - ERD (Entity Relationship Diagrams), показывающие отношения между данными.
3. Диаграммы переходов состояний - STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
Ведущая роль в моделировании принадлежит DFD.
DFD предназначена для отражения взаимосвязей источников и приемников данных (так называемых внешних сущностей по отношению к информационной системе), потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.
Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания и другие средства конкретизации процессов обработки и структуры данных.
Так, потоки данных конкретизируются в части их структуры в словарях данных. Каждый процесс (функция системы) может быть детализирована с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных.
Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса. Спецификация процесса содержит номер и имя процесса, списки имен входных и выходных данных из словаря данных и алгоритм процесса, трансформирующий входные потоки данных во входные. В CASE-технологии используются такие методы задания алгоритмов процессов, как:
Текстовое описание;
Естественный структурированный язык;
Таблицы решений;
Деревья решений;
Визуальные языки;
Языки программирования.
Языки программирования (С, Cobol и др.) вызывают затруднения в написании алгоритмов применительно к DFD, поскольку требуют использования, помимо потоков данных, словарей данных, и требуют синхронной корректировки спецификаций процессов при корректировке DFD.
Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.
Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными возможностями для кодогенерации программ.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.
Иерархическая структура CASE-модели представлена на рис. 11.9.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:
Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);
Проектную, предполагающую логическое проектирование системы (без программирования);
Стадию программирования (включая проектирование физической базы данных);
Послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т. е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе DFD и спецификаций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.
На следующей стадии (программирования) осуществляется физическое проектирование системы. Эта стадия предусматривает автоматическую кодогенерацию по спецификациям процессов программного обеспечения системы и физическое проектирование базы данных.
Заключительная послепроектная стадия начинается с приемосдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.
Последовательность операций создания информационной системы на основе CASE-технологии представлена на рис. 11.10.
Рассмотрим факторы эффективности CASE-технологии.
1. Следует отметить, что CASE-технология создает возможность и предусматривает перенос центра тяжести в трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок в проектировании, исправлять которые на последующих стадиях затруднительно.
2. Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет осуществить принцип пользовательского проектирования, предусматривающий участие пользователей в создании системы. CASE-модель позволяет достичь взаимопонимания между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
3. Наличие формализованной модели системы на предпроектной стадии создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована физически. Этот подход ускоряет и удешевляет создание системы.
4. Закрепление в формализированном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок по новым требованиям пользователей.
5. Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.
6. Наличие формализованной модели реализации системы и соответствующих средств автоматизации позволяет осуществить автоматическую кодогенерацию программного обеспечения системы и создать рациональную структуру базы данных.
7. На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, возможно, силами специалистов отдела автоматизации фирмы.
8. Модель системы может использоваться не только как основа ее создания, но и в целях автоматизированного обучения персонала с использованием диаграмм.
9. На основе модели действующей системы может выполняться бизнес-анализ для поддержки управленческих решений и бизнес-реинжиниринг при изменении направления деятельности фирмы.
Рассмотрим программные средства, обеспечивающие CASE-техно-логию. В зависимости от функционального назначения они подразделяются на следующие классификационные группировки, обеспечивающие:
Анализ и проектирование информационной системы;
Проектирование баз данных;
Программирование;
Сопровождение и реинжиниринг;
Управление процессом проектирования.
Средства анализа и проектирования служат для построения CASE-модели как действующей, так и реализуемой системы управления. Они поддерживают графическое построение и контроль иерархической модели диаграмм потоков данных и описание ее компонентов. Эти средства позволяют аналитикам и проектировщикам получить доступ к базе данных проектируемой системы (репозитарию).
К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.
Для согласования требований пользователей создаются прототипы пользовательских интерфейсов, включающих в себя меню, экранные формы и отчеты в виде таблиц или графиков. Примером программного средства создания пользовательского интерфейса является Developer/2000 (Oracle).
Средства проектирования баз данных обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примерами таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.
Средства программирования поддерживают автоматическую кодогенерацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.
Средства сопровождения и реижиниринга позволяют вносить изменения в систему на уровне моделей при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).
Средства управления процессом проектирования поддерживают планирование и контроль выполнения комплекса проектных работ, а также взаимодействие аналитиков, проектировщиков и программистов на основе общей базы данных проекта (например, Project Workbench фирмы Applied Business Technology). Очевидна актуальность создания интегрированного пакета инструментальных средств поддержки 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 - не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальными или технологическими. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурных методологий проектирования 60-70-х гг. XX в. (сложности понимания, большой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т. д.) за счет их автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными методологиями, они только развивают структурные методологии и делают более эффективным их применение за счет автоматизации.
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE-средства обладают следующими основными достоинствами:
♦ улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего контроля проекта);
♦ позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат;
♦ ускоряют процесс проектирования и разработки;
♦ освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки;
♦ поддерживают развитие и сопровождение разработки;
♦ поддерживают технологии повторного использования компонента разработки.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. В 70-80-х гг. стала на практике применяться структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания АИС и принимаемых-технических решений. Она основана на наглядной графической технике: для описания различного рода моделей АИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке контактных АИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Это и способствовало появлению программно-технических средств особого класса - CASE-средств, реализующих CASE-технологию создания и сопровождения АИС.
Необходимо понимать, что успешное применение CASE-средств невозможно без понимания базовой технологии, на которой эти средства основаны. Сами по себе программные CASE-средства являются средствами автоматизации процессов проектирования и сопровождения информационных систем. Без понимания методологии проектирования ИС невозможно применение CASE-средств.
1. Жизненный цикл программного обеспечения информационной системы
Одним из базовых понятий методологии проектирования АИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации .
Структура ЖЦ ПО базируется на трех группах процессов:
♦ основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
♦ вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
♦ организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т. д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).
Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т. д. и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ.
Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т. п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:
♦ каскадная модель (1970-1980 гг.) - предлагает переход на следующий этап после полного окончания работ по предыдущему этапу;
♦ поэтапная модель с промежуточным контролем (1980-1985 гг.) - итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью, однако время жизни каждого из этапов растягивается на весь период разработки;
♦ спиральная модель (1986-1990 гг.) - делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Специалистами отмечаются следующие преимущества спиральной модели:
♦ накопление и повторное использование программных средств, моделей и прототипов;
♦ ориентация на развитие и модификацию ПО в процессе его проектирования;
♦ анализ риска и издержек в процессе проектирования.
Главная особенность индустрии создания ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта.
2. RAD -технологии прототипного создания приложений
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:
♦ небольшую команду программистов (от 2 до 10 человек);
♦ короткий, но тщательно проработанный производственный график (от 2 до б мес);
♦ повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействия с заказчиком.
Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также иметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
♦ фазы анализа и планирования требований;
♦ фазы проектирования;
♦ фазы построения;
♦ фазы внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т. п. Результатом данной фазы должны быть список и приоритетность функций будущей АИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении АИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - примерно 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
♦ общая информационная модель системы;
♦ функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
♦ точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
♦ построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репо-зитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
♦ определяется необходимость распределения данных;
♦ производится анализ использования данных;
♦ производится физическое проектирование базы данных;
♦ определяются требования к аппаратным ресурсам;
♦ определяются способы увеличения производительности;
♦ завершается разработка документации проекта. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения, и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы.
Приведенная схема разработки АИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается ли совершенно новая система; было ли проведено информационное обследование организации и существует ли модель ее деятельности; существует ли в организации некоторая АИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой и т. п.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального временил), и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Основные принципы методологии RAD:
♦ разработка приложений итерациями;
♦ необязательность полного завершения работ на каждом из этапов жизненного цикла;
♦ обязательное вовлечение пользователей в процесс разработки АИС;
♦ необходимое применение CASE-средств, обеспечивающих целостность проекта;
♦ применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
♦ необходимое использование генераторов кода;
♦ использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;
♦ тестирование и развитие проекта, осуществляемые одновременно с разработкой;
♦ ведение разработки немногочисленной хорошо управляемой командой профессионалов;
♦ грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
3. Структурный метод разработки программного обеспечения
Сущность структурного подхода к разработке АИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип «разделяй и властвуй» и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, более легких для понимания и решения. Второй принцип декларирует, что устройство этих частей также существенно для понимания. Уровень уяснения проблемы резко повышается при представлении ее частей в виде древовидных иерархических структур, т. е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Выделение двух базовых принципов инженерии программного обеспечения не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов.
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 отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
♦ графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;
♦ строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика.
Правила SADT включают:
♦ ограничение количества блоков на каждом уровне декомпозиции (правило 3-б блоков);
♦ связность диаграмм (номера блоков);
♦ уникальность меток и наименований (отсутствие повторяющихся имен);
♦ синтаксические правила для графики (блоков и дуг);
♦ разделение входов и управлений (правило определения роли данных);
♦ отделение организации от функции, т. е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 1.6.1).
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т. е., как уже отмечалось, так называемый родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоеди-ненным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т. д.
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию.
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм
Моделирование потоков данных (процессов)
Основным средством моделирования функциональных требований АИС являются диаграммы потоков данных (DFD:- Data Flow Diagrams). С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД, или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
♦ внешние сущности;
♦ системы/подсистемы;
♦ процессы;
♦ накопители данных;
♦ потоки данных.
Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой АИС.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т. д. В различных нотациях процесс может изображаться на диаграммах по-разному. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например:
♦ «Ввести сведения о клиентах»;
♦ «Выдать информацию о текущих расходах»;
♦ «Проверить кредитоспособность клиента».
Использование таких глаголов, как «обработать»,«модернизировать» или «отредактировать» означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.
В последнее время принято использовать еще и поле физической реализации, информация в котором показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Хранилище (накопитель данных) представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т. д. Накопитель данных идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно быть увязано с информационной моделью. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т. д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление. Каждый поток данных имеет имя, отражающее его содержание.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проецировании относительно простых АИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Для сложных АИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой АИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует АИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры АИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации должны выполняться следующие правила:
♦ правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
♦ правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т. д.
Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком, исходя из следующих критериев:
♦ наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
♦ возможности описания преобразования данных процессом в виде последовательного алгоритма;
♦ выполнения процессом единственной логической функции преобразования входной информации в выходную;
♦ возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20- 30 строк).
При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т. п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать. В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.
Моделирование данных
Цель моделирования данных состоит в обеспечении разработчика АИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных (см. подразд. 2.2).
Нотация ERD была впервые введена П. Ченом (P. Chen) и получила дальнейшее развитие в работах Баркера.
Методология IDEF 1
Метод IDEF1, разработанный Т. Рэмеем (Т. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF IX-диаграммы используются рядом распространенных CASE-средств (в частности, ERWin, Design/IDEF).
Использованная литература
· Федотова Д.Э. CASE – технологии: учебник – М: Горячая линия – Телеком, 2007
· Трофимов В.Е., Лобачева И.Н. Информационные системы в экономике – М: Юнити-Дана, 2008
· Балдин Н.В., Уткин В.Б. Информационные системы и технологии в экономике – М: Юнити, 2007
· Титоренко Т.А. Автоматизированные информационные технологии в экономике – М: Юнити, 2006
· Барановская Т.П., Лойко В.И., Семенов М.И., Трубилин И.Т. Автоматизированные информационные технологии в экономике – М: Финансы и статистика, 2006
1.3.1. Общие требования к методологии и технологии
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
- пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);
- критериев и правил, используемых для оценки результатов выполнения технологических операций;
- нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Рис. 1.4. Представление технологической операции проектирования
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:
- технология должна поддерживать полный ЖЦ ПО;
- технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
- технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
- технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
- технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
- технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
- технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
- технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие:
- стандарт проектирования;
- стандарт оформления проектной документации;
- стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
- правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
- требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
- комплектность, состав и структуру документации на каждой стадии проектирования;
- требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.),
- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
- требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
- правила использования клавиатуры и мыши;
- правила оформления текстов помощи;
- перечень стандартных сообщений;
- правила обработки реакции пользователя.
CASE-средства проектирования информационных систем
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.