Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы информатики, организации ЭВМ, вычислительных и информационных систем. Учебное пособие
.pdf
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационным системам "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут
внести свои замечания только после того, как работа над системой
будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания
программного обеспечения, пользователи получают систему, не
удовлетворяющую их потребностям.
Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в
ее декомпозиции (разбиении) на автоматизируемые функции: си-
стема разбивается на функциональные подсистемы, которые в свою
очередь делятся на подфункции, подразделяемые на задачи и так
далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное
представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством
имеет системность разработки, а основные недостатки - медленно и
дорого.
Спиральная модель
Для преодоления перечисленных проблем была предложена
спиральная модель жизненного цикла (рис. 50), делающая упор на
начальные этапы жизненного цикла: анализ и проектирование. На
этих этапах реализуемость технических решений проверяется путем
создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем
уточняются цели и характеристики проекта, определяется его каче-
ство и планируются работы следующего витка спирали. Таким об-
разом, углубляются и последовательно конкретизируются детали
проекта и в результате выбирается обоснованный вариант, который
доводится до реализации.
130
Рис. 50 – Схема спиральной модели ЖЦ ИС
Разработка итерациями отражает объективно существующий
спиральный цикл создания системы. Неполное завершение работ на
каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на
следующей итерации. Главная же задача - как можно быстрее пока-
зать пользователям системы работоспособный продукт, тем самым,
активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента
перехода на следующий этап. Для ее решения необходимо ввести
временные ограничения на каждый из этапов жизненного цикла.
Переход осуществляется в соответствии с планом, даже если не вся
запланированная работа закончена. План составляется на основе
статистических данных, полученных в предыдущих проектах, и
личного опыта разработчиков.
Одним из возможных подходов к разработке программного
обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение ме-
тодология быстрой разработки приложений RAD (Rapid Application
Development). Под этим термином обычно понимается процесс раз-
работки программного обеспечения, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный
график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере то-
го, как приложение начинает обретать форму, запрашивают и реа-
131
лизуют в продукте требования, полученные через взаимодействие с
заказчиком.
Жизненный цикл программного обеспечения по методологии
RAD состоит из четырех фаз:
1. фаза определения требований и анализа;
2. фаза проектирования;
3. фаза реализации;
4. фаза внедрения.
4.3. Методология и технология разработки информацион-
ных систем [2,11]
Методология создания информационных систем заключается в
организации процесса построения информационной системы и
обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки. Методология реализуется через
конкретные технологии и поддерживающие их стандарты, методики
и инструментальные средства, которые обеспечивают выполнение
процессов жизненного цикла информационных систем. Технология
проектирования может быть представлена как совокупность состав-
ляющих:
используемых методов проектирования;
заданной последовательности выполнения технологических
операций проектирования;
критериев и правил, используемых для оценки результатов
выполнения технологических операций;
графических и текстовых средств (нотаций), используемых
для описания проектируемой системы. Можно сформулировать
следующий ряд общих требований, которым должна удовлетворять
технология проектирования, разработки и сопровождения инфор-
мационных систем:
поддерживать полный жизненный цикл информационной си-
стемы;
обеспечивать гарантированное достижение целей разработки
системы с заданным качеством и в установленное время;
132
обеспечивать возможность разделения крупных проектов на
ряд подсистем — декомпозицию проекта на составные части, раз-
рабатываемые группами исполнителей ограниченной численности,
с последующей интеграцией составных частей;
технология должна обеспечивать возможность ведения работ
по проектированию отдельных подсистем небольшими группами (37 человек).
обеспечивать минимальное время получения работоспособной
системы;
предусматривать возможность управления конфигурацией
проекта, автоматического выпуска проектной документации и син-
хронизацию ее версий с версиями проекта;
обеспечивать независимость выполняемых проектных реше-
ний от средств реализации системы — системы управления базами
данных, операционной системы, языка и системы программирова-
ния. 2
Методы проектирования информационных систем
Методы проектирования ИС можно классифицировать по степени использования средств автоматизации, типовых проектных
решений, адаптивности к предполагаемым изменениям.
Рис. 51 – Классификация методов проектирования
133
Так, по степени автоматизации методы проектирования разделяются на:
ручное, при котором проектирование компонентов ИС осу-
ществляется без использования специальных инструментальных
программных средств, а программирование — на алгоритмических
языках;
автоматизированное, при котором производится генерация
или конфигурирование (настройка) проектных решений на основе
использования специальных инструментальных программных
средств (CASE-средств). По степени использования типовых проектных решений различают следующие методы проектирования:
оригинальное (индивидуальное), когда проектные решения
разрабатываются «с нуля» в соответствии с требованиями к ИС. Характеризуется тем, что все виды проектных работ ориентированы на
создание индивидуальных для каждого объекта проектов, которые в
максимальной степени отражают все его особенности.
типовое, предполагающее конфигурирование ИС из готовых
типовых проектных решений (программных модулей). Выполняется
на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты, как обобщение опыта для некоторых
групп организационно-экономических систем или видов работ, в
каждом конкретном случае связаны со множеством специфических
особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной докумен-
тации.
По степени адаптивности проектных решений к предполагаемым изменениям выделяют методы:
реконструкции, когда адаптация проектных решений выпол-
няется путем переработки соответствующих компонентов (перепро-
граммирования программных модулей);
параметризации, когда проектные решения настраиваются
(генерируются) в соответствии с изменяемыми параметрами;
реструктуризации модели, когда изменяется модель проблем-
ной области, на основе которой автоматически заново генерируются
проектные решения.
Сочетание различных признаков классификации методов обусловливает характер используемых технологий проектирования ИС,
134
среди которых выделяют два основных класса: каноническую и ав-
томатизированная технологии.
Каноническое проектирование ИС
Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования,
осуществляемого на уровне исполнителей без использования каких-
либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Область применения: для не-
больших локальных ИС. В основе канонического проектирования
лежит каскадная модель жизненного цикла ИС. Выделяют следующие стадии (этапы) создания ИС, выполняемые организациямиучастниками канонического проектирования.
Стадия 1. Формирование требований к ИС:
обследование объекта и обоснование необходимости со-
здания ИС;
формирование требований пользователей к ИС;
оформление отчета о выполненной работе и тактико-
технического задания на разработку.
Стадия 2. Разработка концепции ИС:
изучение объекта автоматизации;
разработка вариантов концепции ИС, удовлетворяющих
требованиям пользователей;
оформление отчета и утверждение концепции.
Стадия 3. Техническое задание:
разработка и утверждение технического задания на созда-
ние ИС.
Стадия 4. Эскизный проект:
разработка предварительных проектных решений по си-
стеме и ее частям;
разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект:
разработка проектных решений по системе и ее частям;
разработка документации на ИС и ее части;
разработка и оформление документации на поставку ком-
плектующих изделий.
Стадия 6. Рабочая документация:
135
разработка и адаптация программного обеспечения;
разработка рабочей документации.
Стадия 7. Ввод в действие:
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми изделиями (программ-
ными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний;
проведение опытной эксплуатации;
проведение приемочных испытаний.
Стадия 8. Сопровождение ИС:
выполнение работ в соответствии с гарантийными обяза-
тельствами;
послегарантийное обслуживание.
Достоинства и недостатки этой технологии проектирования
обусловлены и соответствуют достоинствам и недостаткам каскад-
ной модели жизненного цикла ИС.
Автоматизированное проектирование ИС
Автоматизированное проектирование ИС – это проектирование
с использованием CASE-технологий. CASE-технология – совокуп-
ность методов анализа, проектирования, разработки и сопровождения ИС, поддержанных комплексом взаимосвязанных средств авто-
матизации. Цель CASE-технологии – отделить процесс проектиро-
вания ИС от ее кодирования и последующих этапов разработки,
максимально автоматизировать процесс разработки и функциони-
рования систем. Характеристики CASE-средств:
мощная графика для описания и документирования систем;
интеграция, обеспечивающая легкость передачи данных и
позволяющая управлять всем процессом проектирования и разра-
ботки системы непосредственно через процесс планирования про-
екта;
использование репозитория для хранения всей информации о
проекте.
136
Репозиторий (словарь данных) – специализированная база
данных, являющаяся ядром системы. Обеспечивает хранение версий проекта и его отдельных компонентов и объектов, синхронизацию поступающей от проектировщиков информации, контроль метаданных на полноту и непротиворечивость. Сравнительная оценка
трудозатрат по фазам ЖЦ для канонического и автоматизированно-
го проектирования представлена на рис. 52.
Рис. 52 – Сравнительная оценка трудозатрат при каноническом
и автоматизированном проектировании ИС
В качестве примеров популярных CASE-средств укажем следующие:
BPwin и Ramus - моделирование бизнес-процессов;
ERwin - моделирование баз данных и хранилищ данных;
ERwin Examiner - проверка структуры СУБД и моделей, со-
зданных в Erwin;
ModelMart - среда для командной работы проектировщиков;
Paradigm Plus - моделирование приложений и генерация объ-
ектного кода;
Rational Rose - моделирование бизнес-процессов и компонен-
тов приложений;
Rational Suite Analyst Studio - пакет для аналитиков данных;
Oracle Designer (входит в Oracle Developer Suite) - высоко-
функциональное средство проектирования программных систем и
баз данных, реализующее технологию CASE и собственную мето-
дологию Oracle - CDM. Позволяет команде разработчиков полностью провести проект, начиная от анализа бизнес-процессов через
137
моделирование к генерации кода и получению прототипа, а в даль-
нейшем и окончательного продукта.
4.4. Универсальный язык моделирования UML [6]
Общая характеристика и структура унифицированного языка
моделирования UML.
UML – это унифицированный графический язык моделирова-
ния для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех
этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчи-
вая сопровождением системы. Разные организации могут применять
UML по своему усмотрению в зависимости от своих проблемных
областей и используемых технологий. На рис. 53 представлена
структура языка UML.
Рис. 53 – Структура языка UML
UML представляет собой графическую нотацию, которая предназначена для моделирования и описания всех процессов протекающих в процессе разработки. Основу UML представляют диаграммы, которые различаются по типам и предназначены для моделирования различных аспектов разработки. Все диаграммы можно
условно разделить на поведенческие и структурные.
138
Поведенческие диаграммы отображают процессы, протекаю-
щие в моделируемой среде.
Структурные диаграммы отображают элементы, из которых
состоит система. При этом одни и те же типы диаграмм могут ис-
пользоваться как для моделирования бизнес-процессов, так и для
непосредственного проектирования архитектуры.
Способы применения UML
Существует три основных режима использования UML диа-
грамм:
1) режим эскиза;
2) режим проектирования;
3) режим языка программирования.
У режимов есть две опции: прямой (диаграммы до кода) и обратный (диаграммы на основании кода) – инжиниринг.
Рассмотрим способы использования UML–диаграмм:
Моделирование. Графические средства UML можно и нужно
использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли
и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе. Обмен информацией. Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать дру-
гие, и вы будете понимать других специалистов.
Спецификация систем. Это важнейший способ использования
UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, по мере развития языка все
меньше будет оставаться таких исключений, где UML неприменим.
Повторное использование архитектурных решений — ключ к
повышению эффективности. К сожалению, модели UML пока что
повторно используются в весьма ограниченных масштабах. Генерация кода. Генерировать код нужно и можно, но возможности име-
ющихся инструментов не стоит переоценивать.
Имитационное моделирование. Возможности построения моделей UML, из которых путем вычислительных экспериментов можно
было бы извлекать информацию о моделируемом объекте, пока что
уступают возможностям специализированных систем, сконструиро-
ванных для этих целей.
139
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]