26798

Основы методологии проектирования ИС

Реферат

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

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

Русский

2013-08-18

152 KB

11 чел.

  1.  Основы методологии проектирования ИС

Проектирование ИС охватывает три основные области:

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

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

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

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

Конечными продуктами этапа проектирования являются:

  1.  схема базы данных (на основании ER-модели, разработанной на этапе анализа);
  2.  набор спецификаций модулей системы (они строятся на базе моделей функций).

Этап проектирования завершается разработкой технического проекта ИС.

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

Этап тестирования обычно оказывается распределенным во времени.

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

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

Понятие ЖЦ является одним из базовых в программной инженерии. ЖЦ ПО определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (IEEE Std 610.12 - 1990).

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995. В соответствии с этим стандартом все процессы ЖЦ ПО разделены натри группы:

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

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

•четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).

Основные процессы

1. Процесс приобретения состоит из действий и задач заказчика, приобретающего ПО.

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

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

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

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

Вспомогательные процессы

1. Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО.

2. Процесс управления конфигурацией позволяет учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

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

4. Процесс верификации состоит в определении правильности ПО.

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

6. Процесс совместной оценки предназначен для оценки состояния работ по проекту.

7. Процесс аудита представляет собой определение соответствия требованиям, планам и условиям договора.

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

Организационные процессы

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

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

3. Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

4. Процесс обучения охватывает первоначальное обучение и после-дующее постоянное повышение квалификации персонала.

Взаимосвязь между процессами

Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (или в различных аспектах), который показан на рис. 2.1. Такими аспектами являются:

• договорной аспект;

• аспект управления;

• аспект эксплуатации;

• инженерный аспект;

• аспект поддержки.

3. Модели жизненного цикла ПО

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО.Модель ЖЦ представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ.

В состав ЖЦ ПО обычно включаются следующие стадии:

  1.  Формирование требований к ПО.
    1.  Проектирование.
      1.  Реализация.
      2.  Тестирование.
      3.  Ввод в действие.
      4.  Эксплуатация и сопровождение.
      5.  Снятие с эксплуатации.

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

К настоящему времени наибольшее распространение получили каскадная (1970 - 1985 гг.) и спиральная (1986 - 1990 гг.) модель ЖЦ ПО.

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

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

Рис. 2.2. Каскадная схема разработки ПО

Преимущества применения каскадного способа заключаются в следующем:

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

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

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

Обычно на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:

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

Рис. 2.3. Реальный процесс разработки ПО

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

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

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

Основная проблема спирального цикла - определение момента перехода на следующую стадию.

Рис. 2.4. Спиральная модель ЖЦ ПО

4. Общие требования к методологии и технологии

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

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

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

Рис. 1.4. Представление технологической операции проектирования

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

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

  1.  технология должна поддерживать полный ЖЦ ПО;
  2.  технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
  3.  технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
  4.  технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
  5.  технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
  6.  технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
  7.  технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
  8.  технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.

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

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

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

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

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

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

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

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

правила обработки реакции пользователя.

5. Методология RAD

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

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

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

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

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

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

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

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

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

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

6. Структурный подход к проектированию ИС

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

Базовыми принципами структурного подхода к разработке ПО ИС являются:

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

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

  1.  Средства для описания функциональной структуры системы.
  2.  Средства для описания отношений между данными.

Каждой группе средств соответствуют определенные виды моделей:

  1.  SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
  2.  DFD (Data Flow Diagrams) диаграммы потоков данных;
  3.  ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

7. Сущность структурного подхода проектирования ИС

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

Базовыми принципами структурного подхода к разработке ПО ИС являются:

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

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

  1.  Средства для описания функциональной структуры системы.
  2.  Средства для описания отношений между данными.

Каждой группе средств соответствуют определенные виды моделей:

  1.  SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
  2.  DFD (Data Flow Diagrams) диаграммы потоков данных;
  3.  ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

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

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

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

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

9. Состав функциональной модели

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

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

 

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

10. Иерархия диаграмм

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

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

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

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

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

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

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

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

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7 показано типичное дерево диаграмм.

11. Типы связей между функциями

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

Тип связи

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

Случайная  

0

Логическая  

1

Временная  

2

Процедурная  

3

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

4

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

5

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

6

Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.

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

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

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

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

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

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

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

В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 12, имеет следующий вид:

C = g(B) = g(f(A))

Значимость

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

Для функций

Для данных

0

Случайная

Случайная  

Случайная

1

Логическая

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

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

2

Временная

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

"операции инициализации")  

3

Процедурная

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

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

4

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

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

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

5

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

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

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

6

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

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

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

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

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

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

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

  1.  внешние сущности;
  2.  системы/подсистемы;
  3.  процессы;
  4.  накопители данных;
  5.  потоки данных.

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

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

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

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

  1.  "Ввести сведения о клиентах";
  2.  "Выдать информацию о текущих расходах";
  3.  "Проверить кредитоспособность клиента".

Использование таких глаголов, как "обработать", "модернизировать" или "отредактировать" означает, как правило, недостаточно глубокое понимание данного процесса и требует дальнейшего анализа.

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

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

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

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

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

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

13. Построение иерархии диаграмм потоков данных

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

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

наличие большого количества внешних сущностей (десять и более);

распределенная природа системы;

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

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

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

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

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

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

  1.  правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
  2.  правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.

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

Миниспецификация является конечной вершиной иерархии ДПД. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

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

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

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

14. Моделирование данных

Одной из основных частей информационного обеспечения является информационная база. Информационная база (ИБ) представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

УД теоретико-множественные модели: иерархическая, сетевая, реляционная

15. Case-метод Баркера

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

Наиболее распространенные средства моделирования:

- ER-диаграммы П.Чен

Используются для проектирования реляционных БД

- Метод Баркера - развитие ER-Diagram

Поянтия метода Баркера:

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

Свойства сущности:

- Имеет уникальное имя

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

- Может обладать любым количеством связей с другими сущностями.

Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

# - ключевой атрибут

Супертипы и подтипы

В методе Баркера подтип рисуется внутри супертипа.

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

Взаимоисключающие связи

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

Рекурсивная связь

Сущность связана сама с собой.

Неперемещаемая связь - экземпляр сущности не м.б. перемещен из одного экземпляра связи в другой.

16. Методология IDEF

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

  1.  IDEF0 (методология моделирования функциональных блоков);
    1.  IDEF1 (методология моделирования информационных потоков в компании);
    2.  IDEF2 (методология моделирования динамики развития компании);
    3.  IDEF3 (методология документирования бизнес-процессов в компании);
    4.  IDEF4 (методология описания различных объектов в компании и действий над ними);
    5.  IDEF5 (методология описания текущего состояния компании и тенденций его изменения).

17. Объектно-ориентированный подход к проектированию ИС

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

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

В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектно-ориентированных методов язык объектного моделирования UML (Unified Modeling Language - унифицированный язык моделирования). Нотация (синтаксис языка) UML включает ряд графических диаграмм.

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

18. Сущность объектно–ориентированного подхода

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

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

В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектно-ориентированных методов язык объектного моделирования UML (Unified Modeling Language - унифицированный язык моделирования). Нотация (синтаксис языка) UML включает ряд графических диаграмм.

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

19.Методология объектно–ориентированного анализа и проектирования

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

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

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

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) -технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). К первым CASE-средствам отнеслись с определенной настороженностью. Со временем появились как восторженные отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД). Визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает проблем создания приложений других типов.

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

В рамках ООАП исторически рассматривались три графических нотации:

  1.  диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD),
  2.  диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT),
  3.  диаграммы потоков данных (Data Flow Diagrams, DFD).

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

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

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

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

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

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

  1.  Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем
  2.  Нотация IDEF1 - для документирования информации о производственном окружении систем
  3.  Нотация IDEF2 - для документирования поведения системы во времени

Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF нашла применение в правительственных и коммерческих организациях, поскольку в 1993 году появился стандарт FIPS правительства США для двух технологий IDEF0 и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых CASE-средствах, наиболее известным из которых является AllFusion Process Modeler® (новое название BPwin® ) компании Computer Associates.

Процесс моделирования IDEF представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы какой-либо предметной области. Функциональная модель IDEF отображает структуру процессов функционирования системы и ее отдельных подсистем, то есть, выполняемые ими действия и связи между этими действиями. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели нотации IDEF0 процесса являются деятельность (activity) и стрелки (arrows).

Одна из наиболее важных особенностей нотации IDEF0 - постепенное введение все более детальных представлений модели системы по мере разработки отдельных диаграмм. Построение модели IDEF0 начинается с представления всей системы в виде простейшей диаграммы, состоящей из одного блока процесса и стрелок ICOM, служащих для изображения основных видов взаимодействия с объектами вне системы. Поскольку исходный процесс представляет всю систему как единое целое, данное представление является наиболее общим и подлежит дальнейшей декомпозиции. Пример представления общей модели процесса оформления кредита в банке, разработанной с помощью CASE-средства AllFusion Process Modeler®, изображен на.

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

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

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

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

20. Методология системного анализа и системного моделирования

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

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

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

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

21. Унифицированный язык моделирования UML

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

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

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

Диаграмма композитной/составной структуры, Composite structure diagram — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

Диаграмма развёртывания, Deployment diagram — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

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

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

Диаграмма деятельности, Activity diagram — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

Диаграмма автомата, State Machine diagram (диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

Диаграмма прецедентов, Use case diagram (диаграмма вариантов использования) — диаграмма, на которой отражены отношения, существующие между актерами и прецедентами.

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

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

Диаграмма коммуникации, Communication diagram (в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности, Sequence diagram — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

Диаграмма обзора взаимодействия, Interaction overview diagram — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

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

Преимущества UML:

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

22. Варианты использования UML

 

23. Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов

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

Буч отметил также ряд следующих преимуществ ООП:

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

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

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

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

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

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

Взаимосвязь между структурным и объектно-ориентированным подходами достаточно четко просматривается в различных ТС ПО.

24. Вспомогательные средства поддержки жизненного цикла ПО

1. Средства конфигурационного управления

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

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

2. Средства документирования

Для создания документации в процессе разработки ИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Аutomation).

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

3. Средства тестирования

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

Одно из наиболее развитых средств тестирования QA (новое название - Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

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

25. Средства конфигурационного управления ПО

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

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

26. Средства документирования ПО

Для создания документации в процессе разработки ИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Аutomation).

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

27. Оценка затрат на разработку ПО

28. Средства тестирования ПО

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

Одно из наиболее развитых средств тестирования QA (новое название - Quality Works) [20] представляет собой интегрированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.

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

29. Управление проектом ПО

30. Примеры комплексов CASE-средств.


 

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

64738. Воруем изображение с помощью плат видеозахвата 394.5 KB
  Рано или поздно счастливый обладатель видеокамеры в своем стремлении к самовыражению посредством видео сталкивается с проблемой превращения отснятого им видеоматериала в законченный фильм.
64741. Методика профессионального обучения (МПО) как учебный предмет 755 KB
  Частные методики это методики с предметной направленностью например методика обучения физики или математике. В учебном процессе есть элементы которые относятся к группе профессий или не имеют предметной направленности такие элементы характерны для общих методик обучения.
64742. ИСТОРИЯ ВОЕННОЙ МЕДИЦИНЫ И ФАРМАЦИИ В РУССКОЙ АРМИИИ 332.5 KB
  Различия в понимании специфики военно-медицинской деятельности в дореволюционный и советский периоды развития российской военной системы. Основные источники по истории военной медицины и фармации в русской армии.
64744. КУРС ЛЕКЦІЙ З ДИСЦИПЛІНИ «ІСТОРІЯ УКРАЇНИ» 881.5 KB
  Якщо мати на увазі історію нашої країни то предметом курсу історії України є вивчення розвитку людського суспільства на українських землях з найдавніших часів, тобто з часу появи людини і до наших днів.
64745. ФИЗИЧЕСКАЯ КУЛЬТУРА. КУРС ЛЕКЦИЙ 992 KB
  Физкультурное физкультурно-спортивное движение форма социального движения целью которого является содействие повышению уровня физической культуры населения целенаправленной деятельности государственных и общественных организаций граждан...
64746. ЛЕКЦИИ ПО ЗАРУБЕЖНОЙ ЛИТЕРАТУРЕ ХХ ВЕКА 1.03 MB
  И в самом деле на определенное время Невидимка завладевает сознанием и руководит действиями Марвела который помогает ему в частности переносить книги и Кемпа который по воле автора повести почти безпрекословно выслушивает довольно длинный рассказ...