35178

АВТОМАТИЗИРОВАННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Конспект

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

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

Русский

2013-09-09

6.02 MB

111 чел.

ВОРОНЕЖСКИЙ КОЛЛЕДЖ ЖЕЛЕЗНОДОРОЖНОГО ТРАНСПОРТА

ЛЕКЦИИ

по дисциплине:

«АВТОМАТИЗИРОВАННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ»

АИС

Жданова А.А.


Содержание

  1.  Понятие информационная система.

3

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

  1.  Место АИС в профессиональной деятельности.

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

  1.  История создания автоматизированных информационных систем. Требования к АИС.

  1.  Понятие жизненный цикл. Основные процессы жизненного цикла: разработка, эксплуатация, сопровождение, вспомогательные процессы, организационные процессы. Структура жизненного цикла.

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

  1.  Основные понятия и задачи, основные этапы формирования общей теории систем. Особенности сложных систем. Основные положения системного анализа.

  1.  Понятие объектно-ориентированный подход, особенности и назначение.

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

  1.  Основные понятия и определения: структурный анализ ИС, проектирование, CASE-технология. Назначение средств CASE-технологий. Характеристика и классификация CASE-средств. Тенденция развития средств CASE-технологий. Область применения.

  1.  Общие сведения о языке UML: цели и история создания языка UML. Средства UML - UML диаграммы.

  1.  Назначение Rational Rose, его структура и функции; запуск и завершение программы, вид окна, элементы окна, панели инструментов для создания диаграмм, вызов справки.

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

  1.  Диаграммы размещения и состояний: Назначение и особенности, основные элементы диаграмм размещения и состояния. Начальное и конечное состояние. Пять типов данных: деятельность, входное действие, выходное действие, событие и история состояния.

  1.  Диаграммы  взаимодействия: Назначение и особенности, основные элементы диаграмм взаимодействия: диаграмма последовательности и кооперативная диаграмма. Достоинства и недостатки. Построение диаграмм. Сравнение диаграмм последовательности и кооперативных диаграмм.

  1.  Диаграммы активности и компонентов: Назначение и особенности, основные элементы диаграмм активности и компонентов. Построение диаграмм.

  1.  Диаграммы классов: Назначение диаграммы классов. Понятие объект, класс, атрибут класса, операция класса, метод класса, тип, видимость. Точки зрения при разработке диаграммы классов: концептуальная, спецификации, реализации. Отношения внутри диаграмм классов: обобщения, ассоциации, зависимости

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

  1.  Понятие открытые АИС. Глобальная сеть Internet как пример открытой информационной системы. Назначение информационных систем, применяющихся на железной дороге на примере информационных систем   АСОУП, ДИСКОН, ДИСКОР, ДИСПАРК, ЭКСПРЕСС-3 и т.д.

  1.  Классификация  моделей: сетевая, иерархическая, реляционная, постреляционная модели данных. Основная цель моделирования.

  1.  Методы проектирования на основе структурного подхода: Структурный подход. Понятия: методология SADT; функциональное моделирование-IDEF0 – модель; информационное моделирование – IDEF1- модель; событийное моделирование – IDEF0 PN – модель; ERD; диаграмма; бизнес-процесс; системный структурный анализ при проектировании ИС. Построение диаграмм, описывающих стандарт IDEF0. Взаимосвязь структурного и объектно-ориентированного подходов.

  1.  Средства реализации структурного анализа: виды, особенности.

  1.  Понятие информационный процесс. Структура информационного процесса Элементарные операции информационного процесса (процессы сбора, хранения, обработки и передачи информации).

  1.  Понятия одноканальная и многоканальная системы массового обслуживания, эффективность системы, надежность системы.

  1.  Характеристики и показатели качества информационных процессов: временные и характеристики качества информации на выходе информационного процесса.

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

  1.  Понятия: поток данных, информация и данные, пуассоновский поток, стационарный поток, ординарный поток, поток с отсутствием последействия

Понятия: программная инженерия, пользователи АИС, эксперты предметной области, разработчики АИС. Особенности крупных проектов. Требования рынка. Проблема сложности АИС и их разработки.

  1.  
    Понятие информационная система.

Информационная система (ИС) – совокупность принципов, методов и способов обработки информации и непосредственно сам процесс ее преобразования. (Т.е процесс + те правила, по которым он выполняется)

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

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

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

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

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

А что же такое Информационная система? Для начала необходимо понять что такое «система» вообще:

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

Любая система характеризуется рядом свойств. Принято выделять 3 основных группы свойств:

  1.  Свойства, характеризующие состав или архитектуру системы
  2.  Цели функционирования системы
  3.  Свойства, характеризующие условия функционирования системы.

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

Т.е.                   или  fFg   Ввод, Преобразование, Получение информации Чем, Кто, Каким образом?


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

ДИСКОН - автоматизированная система управления контейнерными перевозками.

ДИСКОР - динамическая информационно - справочная система контроля оперативной работы.

АСУОП - автоматизированная система оперативного управления перевозками

Экспресс 3 – система управления пассажирскими перевозками.

ДИСПАРК - автоматизированная система номерного учета, контроля дислокации, анализа использования и регулирования вагонного парка на железных дорогах России

ЕКАСУФР – единая корпоративная АСУ финансами и ресурсами.


  1.  Место АИС в профессиональной деятельности.

Для «Тяги»:

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

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

Для «АСУ»

Сегодня автоматизированные информационные системы из раздела вспомогательных средств переместились в раздел основных и превратились в один из главных механизмов совершенствования управления различными процессами.

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


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

По различным критериям:

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

  •  Область применения
  •  По уровню организации
  •  По аппаратно – техническому обеспечению
  •  По масштабу

Классификация информационных систем

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

Приведем определения и пояснения ряда терминов и понятий, связанных с классификацией информационных систем.

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

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

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

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

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

К системам обработки данных относится класс информационных систем, основной функцией которых являются обработка и архивация больших объемов данных.

По виду деятельности автоматизированные информационные системы делят на:

  •  автоматизированные системы управления предприятием (АСУП),
  •  автоматизированные системы управления технологическими процессами (АСУТП),
  •  системы автоматизированного проектирования (САПР),
  •  автоматизированные обучающие системы (АОС) и т.д.

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

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

Системы с удаленным доступом (с телеобработкой) обеспечивают связи между терминалами пользователей и вычислительными средствами способом передачи данных по каналам связи (с использованием систем пере дачи данных).

Сети ЭВМ (вычислительные сети) — это взаимосвязанная совокупности территориально рассредоточенных систем обработки данных, средств (или) систем связи и передачи данных, обеспечивающая пользователям дистанционный доступ к вычислительным ресурсам и коллективное использование этих ресурсов.

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

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

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

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

В режиме индивидуального пользования все ресурсы системы предоставляются в распоряжение одного пользователя.

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

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

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

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

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

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


  1.  История создания автоматизированных информационных систем. Требования к АИС.

История создания АИС.

Изменение подхода к использованию

Концепция использования информации

Вид информационных систем

Цель использования

1950-1960

Бумажный поток расчетных документов

Информационные системы обработки документов на электронных механических машинах.

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

1960-1970 гг.

Основная помощь в подготовке отчетов

Управленческие ИС для производственной информации

Ускорение процесса подготовки отчетности

1970-1980 гг.

Управленческий контроль реализации (продаж)

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

Выработка наиболее рационального решения.

1980 и т.д.

Информационно-стратегический ресурс, обеспечивающий конкурентную преимущественность.

Стратегические ИС автоматизированные офисы.

Выживание, процветание фирм.

Требования, предъявляемые к информационным системам

Информационная система должна соответствовать требованиям гибкости, надежности, эффективности и безопасности.

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

Любая информационная система рано или поздно морально устареет, и станет вопрос о ее модернизации или полной замене. Разработчики информационных систем, как правило, не являются специалистами в прикладной области, для которой разрабатывается система. Участие в модернизации или создании новой системы той же группы проектировщиков +)существенно сократит сроки модернизации. Вместе с тем -)возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна — внимательнее относиться к подбору разработчиков информационных систем.

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

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

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

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

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

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

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

Требование безопасности обеспечивается: современными средствами разработки информационных систем,

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


  1.  Понятие жизненный цикл. Основные процессы жизненного цикла: разработка, эксплуатация, сопровождение, вспомогательные процессы, организационные процессы. Структура жизненного цикла.

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

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

       t

Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).

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

Этапы ЖЦ:

  1.  анализ требований
  2.  проектирование
  3.  программирование (разработка)
  4.  тестирование и отладка
  5.  эксплуатация и сопровождение

Можно выделить следующие фазы развития информационной системы:

  •  формирование концепции;
  •  подготовка технического задания;
  •  проектирование;

  •  разработка;
  •  ввод системы в эксплуатацию.

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

Концептуальная фаза

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

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

Подготовка технического предложения

Главным содержанием фазы подготовки технического предложения является уточнение технического предложения в ходе переговоров с заказчиком о заключении контракта. Общее содержание работ этой фазы:

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

подписание контракта с заказчиком;

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

Проектирование

На фазе проектирования определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

выполнение базовых проектных работ;

разработка частных технических заданий;

выполнение концептуального проектирования;

составление технических спецификаций и инструкций;

представление проектной разработки, экспертиза и утверждение.

Разработка

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

выполнение работ по разработке программного обеспечения;

подготовка к внедрению системы;

контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

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

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

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

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

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

Процессы, протекающие на протяжении жизненного цикла информационной системы

Основные процессы жизненного цикла

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

  1.  Разработка

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

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

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

  1.  Эксплуатация

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

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

обеспечение пользователей эксплуатационной документацией;

обучение персонала.

Основные эксплуатационные работы включают:

непосредственно эксплуатацию;

локализацию проблем и устранение причин их возникновения;

модификацию программного обеспечения;

подготовку предложений по совершенствованию системы;

развитие и модернизацию системы.

  1.  Сопровождение

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

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

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

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

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

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

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

Вспомогательные процессы жизненного цикла

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

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

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

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

определение методов описания промежуточных состояний разработки;

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

обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов информационной системы.

Верификация — это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

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

Структура жизненного цикла информационной системы

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

Структура жизненного цикла основывается на трех группах процессов:

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

Рассмотрим каждую из указанных групп более подробно.

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии:

начало;

уточнение;

конструирование;

передача в эксплуатацию.

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

Начальная стадия

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

Стадия уточнения

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

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

Стадия конструирования

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

Стадия передачи в эксплуатацию

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


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

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

При описании Case-техенологий используется понятие жизненный цикл. Программного обеспечения.

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

Этапы ЖЦ:

  1.  анализ требований
  2.  проектирование
  3.  программирование (разработка)
  4.  тестирование и отладка
  5.  эксплуатация и сопровождение

Case-технология должна помочь и однозначно выразить требования к ней.

Наибольшее распространение получили 2 модели ЖЦ:

  •  Каскадная
    •  Спиральная.

КАСКАДНАЯпереход к следующему этапу ЖЦ происходит только после того, как будет полностью завершена работа на предыдущем

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

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

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

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

СПИРАЛЬНАЯ – каждый виток спирали или каждая итерация соответствует созданию фрагмента или версии ПО. При этом уточняются  параметры проекта, планируются работы следующего витка спирали. В результате на некотором витке выбирается вариант, который и доводится до окончательной реализации.

«+» - Переход на следующий этап производится без ожидания полного завершения работы на текущем этапе, а недостающая работа выполняется на следующей итерации.

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

БОЛЕЕ ПОДРОБНО О  МОДЕЛЯХ ЖЦ:  Из учебника Петров «Информационные системы»:

Модели жизненного цикла

Каскадная модель ЖЦ ПО

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

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

Модели жизненного цикла информационной системы

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

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

  •  каскадная модель, иногда также называемая моделью водопада (waterfall);
  •  спиральная модель.

Каскадная модель жизненного цикла информационной системы

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

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

Основные этапы разработки по каскадной модели

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

  •  анализ требований заказчика;
  •  проектирование;
  •  разработка;
  •  тестирование и опытная эксплуатация;
  •  сдача готового продукта.

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

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

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

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

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

Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и длиннее.

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

Основные достоинства каскадной модели

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

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

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

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

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

Недостатки каскадной модели

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

  •  существенная задержка в получении результатов;
  •  ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад;
  •  сложность параллельного ведения работ по проекту;
  •  чрезмерная информационная перенасыщенность каждого из этапов;
  •  сложность управления проектом;
  •  высокий уровень риска и ненадежность инвестиций.
  1.  Задержка в получении результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что
    1.  из-за последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ =>. Может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей, причем такие несоответствия могут возникать на любом этапе разработки — искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они необязательно хорошо разбираются в тех предметных областях, для которых производится разработка информационной системы.
    2.  Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

Помимо рассмотренных существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки можно далеко не всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т. п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным их исполнением. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

Спиральная модель жизненного цикла

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

Итерации

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

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

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

Рис. 2.4. Спиральная модель жизненного цикла информационной системы

Преимущества спиральной модели

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

Рассмотрим преимущества итерационного подхода более подробно.

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

На рис. 2.5 приведены в сравнении графики зависимости уровня рисков от времени разработки для каскадного и итерационного подходов.

Рис. 2.5. Зависимость рисков от времени разработки

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

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

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

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

Недостатки спиральной модели

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

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


Стандарты и методики

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

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

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

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

Виды стандартов

  •  По предмету стандартизации. - функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию жизненного цикла создания и использования информационных систем и программного обеспечения.
  •  По утверждающей организации - официальные международные, национальные или ведомственные национальные стандарты (ГОСТ, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OMG), стандарты де-факто — официально никем не утвержденные, но фактически действующие, фирменные стандарты (Microsoft ODBC).
  •  По методическому источнику - методические материалы ведущих фирм-разработчиков программного обеспечения, фирм-консультантов, научных центров, консорциумов по стандартизации.

Общая структура

Методика CDM определяет следующие фазы жизненного цикла информационной системы:

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

Общая структура

В стандарте ISO 12207 не предусмотрено каких-либо этапов. Стандарт определяет лишь ряд процессов, причем по сравнению с CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов (приобретение, поставка, разработка и т. п.). Один процесс ISO 12207 сопоставим со всеми процессами CDM вместе взятыми.

Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие — на ряд задач.

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

Ценность стандарта ISO 12207. В нем представлены наборы задач, характеристики качества, критерии оценки, обеспечивающие всесторонний охват проектных ситуаций.


  1.  Основные понятия и задачи, основные этапы формирования общей теории систем. Особенности сложных систем. Основные положения системного анализа.

  1.  Основные понятия и задачи теории систем.

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

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

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

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

Понятие 1. Система – объект, образованный совокупностью разнородных элементов, которые образуют в своем единстве нечто целое.

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

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

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

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

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

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

Теорию общих систем условно можно разбить на 2-е части:

Системология, в которой исследуются целостные объекты, представляемые в качестве объекта – познания

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

Основные задачи ОТС:

Предоставление конкретных реальных процессов и явлений в качестве систем.

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

Обоснование наличия системных признаков у конкретных объектов.

Классификация систем по определённым основанием и описанием особенностей различных  их видов.

Составление обобщённых моделей конкретных системных образований.

  1.  Основные этапы формирования общей теории систем:

Принято выделять несколько этапов создания Общей Теории Систем (ОТС):

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

2 этап (XVIXVIII) - Спиноза, Лейбниц, Лаплас, Ламберт

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

3 этап (XIX-XX) Гегель, Дарвин, Лобачевский, Риман, Эйнштейн, Менделеев, Бутлеров. В результате формируются понятие о свойствах, целях, условиях, характеризующих сложные системы как неотъемлемые атрибуты.

Закончилась подготовительная работа, этап.

4 этап (начало – середины XX в). А. Богданов, Л. Берталанфи, Н. Винер – попытки раскрыть ТОС как общую конкретную дисциплину. Богданов: Книга “Тектология”. Всеобщая организационная наука – I-ая формулировка полноценной общей теории систем как науки.

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

Винер – книга “Кибернетика”

Ввел ряд новых понятий для теории сложных систем – черный ящик (внутри-известно), дуализм.

  1.  Некоторые особенности исследования сложных систем.

В общей теории систем обычно методы теории познания присутствуют:

  •  установление предмета
    •  выбор метода исследования,
      •  классификация свойств объектов,
      •  метод анализа, синтеза,
      •  формулировка выводов.

Рид новых элементов, которые в традиционных науках отсутствовали:

Особенности системных исследований:

  1.  Целостность познания объекта
    1.  Стандартизация терминологии (как в математике)
      1.  Объяснительный характер связей и взаимодействий (всякое действие должно сопровождаться установлением причинно-следственной связи).
        1.  Требование предсказательности при приложении общей теории систем к различным явлениям
        2.  Возможность существования диссипативных систем.

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

  1.  Основные положения системного анализа.

Предмет исследования в системном анализе.

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

ОТС -> Общая теория систем – это методологическая теория ориентированного на некоторую абстрактную систему.

Системный анализ реализует методологию ОТС при рассмотрении различных прикладных задач.

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

ОТС – сложная системная абстракция и обработка приемов, последовательность проведения исследования.

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

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

Исследование операций – это дисциплина, созданная для решения проблемы выбора, способы действия, варианты плана. Параметров конструкции в условиях неполной определенности.

Моделирование – это основной метод исследования в системном анализе.

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

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

Важной методологической особенностью построения предметной области – является выделение из реальной действительности интересующего нас объекта с учетом его взаимодействия с другими объектами (которые непосредственно нас не интересуют).

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

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

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

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

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

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

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

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

Базовая модель или метамодель – это наиболее простая и наиболее общая модель, содержащая m, n-ое число свойств, определяющих поведение реального объекта.

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

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

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

Основные этапы и процедуры системного анализа.

Этап №1 Определение методологии системного исследования.

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

Этап №2 Формулировка проблемы и проблематики исследования.

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

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

Этап №3 Выявление целей.

Этап №4 Формирование критериев.

Критерийпараметр, обеспечивающий сравнение альтернатив.

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

Уровень профессиональной подготовки.

Этап №5 Генерирование алгоритмов (теория выбора).

Высказывая идеи о возможных способах достижения поставленных целей.

Этап №6 Построение и использование моделей.

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

Этап №8 Выбор или принятие решения – это совокупность действий называется множеством альтернатив, в результате  образуется подмножество выбранных альтернатив.

Эти 8 этапов называется подготовительной стадией.

Этап №9 Декомпозиция системы.

Разложение её на составные части или подсистемы, обеспечивающие сочетание простоты и полноты.

Этап №10 Агрегирование - объединение нескольких элементов в единое целое, позволяющее выполнять закономерности внутренней целостности системы.

Этап №11 Исследование информационных потоков. Выявление, моделирование свойств, количественное описание источников, стоков и каналов информации.

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

Этап №12 Определение ресурсных возможностей. – оборудование.

Этап №13 Наблюдение и определение результатов эксперимента и их анализа.

Этап №14 Реализация (внедрение) результатов системного анализа в данной конкретной предметной области.


9. Понятие объектно-ориентированный подход, особенности и назначение.

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

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

Проблемы, стимулировавшие развитие ООП:

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Ее основными понятиями являются: объекты и атрибуты, целое и часть, классы и экземпляры. Объектная модель является наиболее естественным способом представления реального мира. В разделе «Теория классификации» Британской Энциклопедии сказано следующее:

В постижении реального мира люди пользуются тремя методами, организующими их мышление:

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

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

(3) формирование и выделение различий между различными классами объектов - например, между классом всех деревьев и классом всех камней.

Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот с точки зрения изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность – это свойства объекта, отличающие его от всех других объектов.

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

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

Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход «сущность-связь».

Преимущества объектно-ориентированного подхода: 

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

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


10.
Основные механизмы Объектной модели

Основными механизмами объектной модели являются:

  •  абстрагирование (abstraction);
  •  инкапсуляция (encapsulation);
  •  наследование (inheritance);
  •  полиморфизм (polymorphism);
  •  модульность (modularity);
  •  иерархия (hierarchy).

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

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

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

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

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

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

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

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


11. Основные понятия и определения: структурный анализ ИС, проектирование,
CASE-технология. Назначение средств CASE-технологий. Характеристика и классификация CASE-средств. Тенденция развития средств CASE-технологий. Область применения.

Структурный анализ – (структурный подход.) – метод исследования системы, основанный на представлении ее в виде иерархии взаимосвязанных элементов.

Обычно число элементов на каждом уровне иерархии ограничено (от 3 до 6-7).

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

Используются строгие формальные правила записей и изображения системы и ее элементов.

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

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

Case-технологии получили наибольшее распространение на этапах анализа требований и проектирования. Основой для этих этапов являются методологии структурного анализа и проектирования.

Case -средства

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

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

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

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

При применении этого инструментария отмечается значительный рост производительности труда, составляющий (по оценкам фирм, использующих CASE) от 100 до 600% в зависимости от объема и сложности работ и опыта использования CASE. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования. В таблице 3 приведены оценки трудозатрат по фазам ЖЦ, в таблице 4 сведены основные изменения в ЖЦ при использовании CASE по сравнению с традиционной разработкой, на рис. представлены преимущества разработки с применением CASE-технологий.

Таблица 3

Способ

разработки

Анализ

%

Проектирование

%

Кодирование

%

Тестирование

%

Традиционная разработка

20

15

20

45

Использование структурной методологии

30

30

15

25

Использование CASE-технологий

40

40

5

15

 Таблица 4

Традиционная разработка

CASE

Основные усилия – на кодирование и тестирование

Основные усилия – на анализ и проектирование

"Бумажные" спецификации

Быстрое итеративное прототипирование

Ручное кодирование

Автоматическая кодогенерация

Ручное документирование

Автоматическая генерация документации

Тестирование кодов

Автоматический контроль проекта

Сопровождение кодов

Сопровождение спецификаций проектирования

 

Рисунок 19 

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

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

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

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

-     возможность повторного использования компонентов разработки;

-     поддержание адаптивности и сопровождения ЭИС;

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

-     возможность коллективной разработки ИС в режиме реального времени.

Большинство CASE-средств основано на парадигме методология метод нотация средство. Состав средств CASE – технологий:

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

Метод - это систематические  процедуры (или техника генерации) построения моделей проектируемой системы (например, построение моделей (структур) данных, потоков и т.д.)

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

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

5.2. Классификация CASE-средств

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

1)            классификация по ориентации на процессы ЖЦ ПО: 

-         средства анализа и проектирования (BPWin, Silverrun, Oracle Designer, Rational Rose, Paradigm Plus, Power Designer, System Architect);

-         средства проектирования баз данных (средствапроектирования базданных имеются в составе таких CASE-средств, как Silverrun, Oracle Designer, Paradigm Plus, Power Designer. Наиболее известным средством, ориентированным только на проектирование БД, является ERWin);

-         средства управления требованиями (RequisitePro, DOORS - Dynamic Object-Oriented Requirements System - динамическая объектно-ориентированная система управления требованиями);

-         средства управления конфигурацией ПО  (PVCS, ClearCase и др.);

-         средства документирования. (SoDA - Software Document Automation - автоматизированное документирование ПО);

-         средства тестирования. (Rational Suite TestStudio);

-         средства управления проектом (Open Plan Professional , Microsoft Project 98 и др.);

-         средства реверсного инжиниринга, предназначенные для переноса существующей системы ПО в новую среду. Средства анализа схем БД и формирования ERD входят в состав таких CASE-средств, как Silverrun, Oracle Designer, Power Designer, ERwin. Анализаторы программных кодов имеются в составе Rational Rose и Paradigm Plus.

2)            классификация по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

3)            классификация по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

4)            классификация по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

5)            классификация по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

6)            классификация по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

7)            классификация по типу операционной системы: работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNDO, OS/2 и др.).

8) классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе.

-         Анализ и проектирование. Средства этой группы используются для создания спецификаций системы и ее проектирования: они поддерживают широко известные методологии проектирования. К таким средствам относятся: The Developer (Asyst Technologies), Design Generator (Computer Sciences). Pose (Computer Systems Advises). Analisi/ Designer (Jour- don)...

-         Проектирование баз данных и файлов. Средства обеспечивают логическое моделирование данных, генерацию схем БД и описание форматов файлов: PowerDesigner, Idef/Leverage (D.Appleton), Chen Toolkit (CTien & Associates). Case+Designer (Orale)...

-         Программирование. Средства поддерживают шаги программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: Cobol 2/ Workbench (Miero Focus), Decase (DEC), Netron/Cap (Netron)...

-         Сопровождение и реинженерия. К таким средствам относятся докумен-таторы, анализаторы программ, (средства реструктурирования и обратной инженерии: Adpac Case Tools (Adpac), Superstructure (Computer Data Systems)...

-         Окружение. Средства поддерживающие платформы для интеграции, создания и придания товарного вида CASE-средствам: Multi/ Cum (ACiS Management Systems), Sylvia Foondey (Codinare).

-         Управление проектом. Средства поддерживающие планирование, контроль. руководство, взаимодействие, то есть функции. необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).

9) классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает:

-         Вспомогательные программы (Tools), решающие небольшую автономную задачу, принадлежащую проблеме более широкого масштаба.

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

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

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

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

-         Средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры АС. Основная выгода от использования среднего CASE состоит в значительном облегчении проектирования систем; проектирование превращается в итеративный процесс, включающий действия: пользователь обсуждает с аналитиком требования к информации: аналитик документирует эти требования, используя диаграммы и словари входных данных: пользователь проверяет эти диаграммы н словари, при необходимости модифицируя их; аналитик отвечает на эти модификации изменяя соответствующие спецификации. Кроме того, средние CASE обеспечивают возможности быстрого документирования требований и прототипирования.

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

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

В таблице 5 приведены наиболее популярные CASE-средства проектирования ИС.

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

 Таблица 5 - Наиболее популярные CASE-средства

CASE – средство

Производитель

Адрес сайта производителя

Designer 2000

Oracle

http://www.oracle.com/

ERwin/BPwin

Computer Associates

http://www.cai.com/

PowerDesigner

Sybase

http://www.sybase.com/

ER/Studio

Embarcadero

http://www.embarcadero.com/

System Architect

Popkin Software

http://www.popkin.com/

Visible Analyst

Visible Systems

http://www.visible.com/

Visio Enterprise

Microsoft

http://www.microsoft.com/

Тенденции развития CASE-технологий

  •  Появление CASE-технологий явилось естественным этапом в развитии средств разработки программного обеспечения
  •  В эволюции CASE-технологий можно выделить два этапа:
  •  Первый этап характеризуется развитием технологий и CASE-средств, основанных на методологии структурного анализа и ориентированных на поддержку первых двух стадий жизненного цикла (анализ требований, проектирование). К CASE-средствам этого типа относятся такие, как Design/IDEF (компании Meta Software), BPWin (Platinum), Design/2000 (ORACLE) и др.
  •  Второй этап характеризуется развитием технологий и средств, поддерживающих все стадии жизненного цикла, в первую очередь, стадии программирования, тестирования и отладки. Применение этих средств обеспечивает автоматическую кодогенерацию из полученных спецификаций с полным документированием разработанных программ. К CASE-средствам этого уровня относятся такие пакеты, как COBOL2/Workbench (Mikro Focus), DECASE (DEC) и др. CASE-средства второго этапа могут включать до 100 функциональных компонентов, поддерживающих все этапы жизненного цикла, предоставляя пользователям возможность выбора необходимых средств и их интеграцию в нужном составе.
  •  С начала 90-х годов получают развитие CASE-технологии, основанные на комбинировании методологии структурного анализа и объектно-ориентированных методов создания ПО. 

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


12. Общие сведения о языке UML: цели и история создания языка UML. Средства UML – UML диаграммы.

UML – унифицированный язык объектно-ориентированного моделирования ИС

Цели и история создания языка UML

Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch [Буч-99] и OMT (Object Modeling Technique) [Rumbaugh-91] под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) [Jacobson-92] Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus (CA), System Architect (Popkin Software), Microsoft Visual Modeler  и др.). Полное описание UML можно найти на сайтах http://www.omg.org, http://www.rational.com и http://uml.shl.com. Первое описание UML на русском языке содержится в книге [Фаулер-99], в дальнейшем изложении терминология языка соответствует данному переводу. Кроме него, имеется также перевод [Буч-2000].

Средства UML

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

  •  диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации (требований к системе);
  •  диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;
  •  диаграммы поведения системы (behavior diagrams):
  •  диаграммы взаимодействия (interaction diagrams):
  •  диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
  •  диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
  •  диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
  •  диаграммы реализации (implementation diagrams):
  •  диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
  •  диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.


Назначение
Rational Rose, его  структура и функции; запуск и завершение программы, вид окна, элементы окна, панели инструментов для создания диаграмм, вызов справки.

Rational Rose

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

В составе Rational Rose можно выделить 6 основных структурных компонент:

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

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

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

Selection tool

Textbox

Note

Anchornotetoitem

Package

Use case

Actor

Unidirectional association

Dependency or instantiates  

Generalization

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

Кнопка

Назначение

Selection tool (Выделение объекта или отмена его выделения)

Превращает курсор в стрелку указателя, так что вы можете выделить объект

Text box (Текст)

Добавляет к диаграмме текст

Note (Примечание)

Добавляет к диаграмме примечание

Anchor note to item (Прикрепление примечания к объекту)

Связывает примечание с вариантом использования или объектом на диаграмме

Package (пакет)

Помещает на диаграмму новый пакет

Use case (вариант использования)

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

Actor (Действующее лицо )

Помещает на диаграмму новое действующее лицо

Unidirectional association (Однонаправленная ассоциация)

Рисует связь между действующим лицом и вариантом использования

Dependency or instantiates  (Зависимость или наполнение)

Рисует зависимость между элементами диаграммы

Generalization (Обобщение)

Рисует связь использования или расширения между вариантами использования, или рисует связь наследования между действующими лицами


Кнопки на панели инструментов диаграммы последовательности.

Кнопка

Назначение

Selects or deselects an item (Выделение объекта или отмена его выделения)

Превращает курсор в стрелку указателя, так что вы можете выделить объект

Text box (Текст)

Добавляет к диаграмме текст

Note (Примечание)

Добавляет к диаграмме примечание

Anchor note to item (Прикрепление примечания к элементу)

Связывает примечание с элементом на диаграмме

Object (Объект)

Помещает на диаграмму новый объект

Object message (Сообщение для объекта)

Рисует сообщение между двумя объектами

Message to self (Сообщение самому себе)

Рисует рефлексивное сообщение

Кнопки панели инструментов кооперативной диаграммы.

Кнопка

Назначение

Selects or deselects an item (Выделение объекта или отмена его выделения)

Превращает курсор в стрелку указателя, так что вы можете выделить объект

Text box (Текст)

Добавляет к диаграмме текст

Note (Примечание)

Добавляет к диаграмме примечание

Anchor note to item (Прикрепление примечания к элементу)

Связывает примечание с элементом на диаграмме

Object (Объект)

Помещает на диаграмму новый объект

Class Instance (Экземпляр класса)

Помещает на диаграмму новый экземпляр класса

Object Link (связь с объектом)

Создает путь коммуникации между объектами

Link to Self (связь с самим собой)

Показывает, что объект может обращаться к своим операциям

Link Message (Сообщение по связи)

Показывает сообщение, передаваемое между двумя объектами или передаваемое объектом самому себе

Reverse Link Message (Ответное сообщение)

Показывает сообщение, передаваемое в противоположном направлении по связи между объектами или от объекта самому себе

Data Flow (Поток данных)

Показывает поток информации между объектами

Reverse Data Flow (Обратный поток данных)

Показывает поток информации между объектами в противоположном направлении


3.3. Диаграммы вариантов использования.

В течение достаточно длительного периода времени, в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие им лучше понять требования к системе. Эти сценарии трактовались весьма неформально – они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые ввел понятие варианта использования (такое название он дал сценариям) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.

Вариант использования (другое название Прецедент).

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

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

Например, два типичных варианта использования обычного текстового процессора – «сделать некоторый текст полужирным» и «создать индекс». Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.

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

Когда Якобсон ввел понятие прецедента в качестве основного элемента процесса разработки, он ввел также диаграмму вариантов использования (Use Case Diagram) для их наглядного представления.

Вместе с прецедентами вводится и тесно используется понятие «Действующее лицо». Для его обозначения используют пиктограмму.

Действующее лицо (другое название Актер)

Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

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

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

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

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

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

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

Пример диаграммы прецедентов

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

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

 Описание отношений внутри диаграмм прецедентов.

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

Связи между актером и прецедентом

Связи между прецедентами.

Связи между актерами

Все эти связи несут различную смысловую нагрузку. Рассмотрим все виды связей подробно.

 Связь между актером и прецедентом

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

Приведенная в качестве примера диаграмма, например, отражает взаимодействие между вариантами использования и действующими лицами системы АТМ. В сущности, диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере, клиент банка инициирует большое количество различных вариантов использования: Снять деньги со счета, Перевести деньги, Сделать вклад, Показать баланс и Изменить идентификационный номер. Некоторые из связей заслуживают более детального рассмотрения. Банковский служащий может также инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Осуществить оплату" стрелка указывает на Кредитную систему. Действующими лицами могут быть внешние системы, и потому в данном случае Кредитная система показана именно как действующее лицо - она внешняя для системы АТМ. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом. В данном случае вариант использования "Осуществить оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.

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

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

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

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

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

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

Связи между прецедентами

Связи между прецедентами – позволяют одному прецеденту использовать функциональность другого. В UML и Rational Rose предполагаются два вида связей, которые имеют один тип Обобщение (Generalization) – это связи Использование (Uses) и Расширение (Extends).  

Рассмотрим пример диаграммы прецедентов, в которой рассматривается задача документооборота «Принятие решения по документу».

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

Прецедент, к которому направлена связь, в данном случае «Сформировать список доставки»,  является абстрактным и пользователем никогда напрямую не вызывается. Абстрактный прецедент – такой прецедент,  который предоставляет другим вариантам использования свою функциональность через связи использования и расширения. Когда какому-нибудь варианту использования потребуется выполнить эти действия, он может использовать функциональность созданного нами прецедента "Сформировать список доставки".

Связь расширение применяется в тех случаях, когда один прецедент подобен другому, но несет несколько большую нагрузку. В нашем примере основным вариантом использования является «Наложить резолюцию». Однако логика выполнения работ в документообороте требует, чтобы секретарь, выполняя обработку корреспонденции, мог отправить документ исполнителю со стандартной резолюцией от имени руководителя. В этом случае процесс, связанный с наложением резолюции, не может выполняться обычным образом и должен претерпеть некоторые изменения (например должна быть проверка на допустимость резолюции для данного документа и допустимость исполнителя для этой резолюции).

Можно было бы предусмотреть эти изменения в рамках основного прецедента «Наложить резолюцию». Однако такой подход может привести к загромождению прецедента разной «побочной» логикой, за которой может потеряться его «нормальная» логика. Другим способом учесть изменения – это поместить нормальный процесс в рамки одного прецедента, а все отклонения от него – куда-нибудь в другое место. Что и представлено на рисунке.

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

Фаулер в своей книге [Фаулер-99] предлагает следующий процесс образования связи «расширение»:

Зафиксируйте сначала простой, «нормальный» вариант использования.

Анализируя каждый шаг в этом варианте использования, задавайте вопросы «Что здесь может идти не так как надо?» и «Как иначе можно выполнить этот шаг?».

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

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

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

Связи между актерами.

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

С помощью связи обобщения действующего лица (actor generalization relationship) показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные.

Это отношение можно моделировать с помощью нотации, показанной на рисунке.

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

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


15 . Диаграммы размещения и состояний

Диаграммы размещения

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

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

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

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

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

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

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


Диаграммы состояний

Диаграммы состояний являются хорошо известным средством описания поведения систем.

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

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

Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее популярная форма, используемая в объектно-ориентированных методах, впервые применялась в методе ОМТ и впоследствии была адаптирована Гради Бучем.

Диаграммы состояний отображают поведение объекта.

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

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

Если клиент снимает деньги с открытого счета, он может перейти в состояние "Превышение кредита". Это происходит, только если баланс по этому счету меньше ноля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратных скобках условие (guard condition) определяет, когда может или не может произойти переход из одного состояния в другое.

Диаграмма состояний для класса Account.

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

С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Давайте теперь рассмотрим каждый из них в контексте диаграммы состояний для класса Account системы ATM.

Деятельность

Деятельностью (activity) называется поведение, реализуемое объектом, пока он находится в данном состоянии. Например, когда счет находится в состоянии "Закрыт", происходит возврат кредитной карточки пользователю. Деятельность – это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность изображают внутри самого состояния, ей должно предшествовать слово do (делать) и двоеточие.

Входное действие

Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. В примере счета в банке, когда он переходит в состояние "Превышен счет", выполняется действие "Временно заморозить счет", независимо от того, откуда объект перешел в это состояние. Таким образом, данное действие осуществляется не после того, как объект перешел в это состояние, а, скорее, как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое.

Входное действие также показывают внутри состояния, ему предшествует слово entry (вход) и двоеточие.

Выходное действие

Выходное действие (exit action) подобно входному. Однако, оно осуществляется как составная часть процесса выхода из данного состояния. В нашем примере при выходе объекта Account из состояния "Превышен счет", независимо от того, куда он переходит, выполняется действие "Разморозить счет". Оно является частью процесса такого перехода. Как и входное, выходное действие является непрерываемым.

Выходное действие изображают внутри состояния, ему предшествует слово exit (выход) и двоеточие.

Поведение объекта во время деятельности, при входных и выходных действиях может включать отправку события другому объекту. Например, объект account (счет) может посылать событие объекту card reader (устройство чтения карты). В этом случае описанию деятельности, входного действия или выходного действия предшествует знак ^. Соответствующая строка на диаграмме выглядит как

Do: ^Цель.Событие(Аргументы)

Здесь Цель – это объект, получающий событие, Событие – это посылаемое сообщение, а Аргументы являются параметрами посылаемого сообщения.

Деятельность может также выполняться в результате получения объектом некоторого события. Например, объект account может быть в состоянии Открыто. При получении некоторого события выполняется определенная деятельность.

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

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

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

События

Событие (event) - это то, что вызывает переход из одного состояния в другое. В нашем примере событие "Клиент требует закрыть" вызывает переход счета из открытого в закрытое состояние. Событие размещают на диаграмме вдоль линии перехода.

На диаграмме для отображения события можно использовать как имя операции, так и обычную фразу. В нашем примере события описаны обычными фразами. Если вы хотите использовать операции, то событие "Клиент требует закрыть" можно было бы назвать RequestClosure().

У событий могут быть аргументы. Так, событие "Сделать вклад", вызывающее переход счета из состояния "Превышен счет " в состояние "Открыто", может иметь аргумент Amount (Количество), описывающий сумму депозита.

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

Ограждающие условия

Ограждающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. В нашем примере событие "Сделать вклад" переведет счет из состояния "Превышение счета" в состояние "Открыто", но только если баланс будет больше нуля. В противном случае переход не осуществится.

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

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

Действие

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

Например, при переходе счета из открытого в закрытое состояние выполняется действие "Сохранить дату закрытия счета". Это непрерываемое поведение осуществляется только во время перехода из состояния "Открыто" в состояние "Закрыто".

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

Событие или действие могут быть поведением внутри объекта, а могут представлять собой сообщение, посылаемое другому объекту. Если событие или действие посылается другому объекту, перед ним на диаграмме помещают знак ^.

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

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

Диаграммы состояний для прецедентов.

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

В качестве примера возьмем описанный ранее прецедент «Наложить резолюцию». Пользователь выполняя задачу «Наложить резолюцию» обращается к системе как к «черному ящику» - назовем его System. Он должен выполнить последовательно три операции: Вызвать процесс ввода резолюции – операция «Сформировать резолюцию», Заполнить предоставленные поля для ввода – операция «Добавить элемент резолюции» и дать команду системе об окончании ввода данных – операция «Закончить ввод резолюции». При вводе последней команды система должна сформировать список доставки, вызвав соответствующий абстрактный прецедент. Пример диаграммы последовательтности, описывающей эти операции пользователя с системой представлен на рисунке.

Исходя из имеющихся операций можно сформировать следующую диаграмму состояний прецедента:

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

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

[Слайд: Диаграммы деятельностей. Пример описания не программной задачи.]


16. Диаграммы взаимодействия

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

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

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

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

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

Диаграмма последовательности для снятия клиентом 20 долларов со счета.

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения, этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" (account) и инициализирует экран АТМ. Экран, в свою очередь, запрашивает у Джо его регистрационный номер. Он вводит число 1234. Экран проверяет номер у объекта "Счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и он выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо выбирает 20 долларов. Затем экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "Счет Джо". Во-первых, осуществляется проверка, что на этом счету лежит, по крайней мере, 20 долларов. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать 20 долларов наличными, а также чек. Наконец, все тот же объект "Счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать само-делегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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

Кооперативные диаграммы

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

Кооперативная диаграмма, описывающая процесс снятия клиентом со своего счета 20 долларов

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

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

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

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

Сравнение диаграмм последовательности и кооперативных диаграмм

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

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

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

 Диаграммы кооперации. Подробно.

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

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

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

Если необходимо указать, что операция выполняется в цикле, то сразу за порядковым номером указывается звездочка. Можно так же указать условия цикла. В примере представлено условие цикла FOR.

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

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


17. Диаграммы активности (деятельности)  и компонентов.

Диаграмма деятельности (активности)

За каждой деятельностью может следовать другая деятельность. Такое следование образует простую последовательность. Например, за деятельностью Положить Кофе в Фильтр следует деятельность Вставить Фильтр в Автомат. Деятельность Поискать Напиток активизирует на выходе два действия. Каждое действие содержит условие – логическое выражение, которое может принимать одно из двух значений: «истина» или «ложь», так же, как и на диаграмме состояний. В ситуации, изображенной на рисунке, Личность осуществляет деятельность Поискать Напиток, выбирая между кофе и колой.

Предположим, что мы отыскали кофе и идем вниз по кофейному маршруту. Этот путь ведет к линейке синхронизации, с которой связана активизация трех деятельностей: Положить Кофе в Фильтр, Добавить Воду в Емкость и Достать Чашки.

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

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

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

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

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

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

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

Теперь переместимся к другому маршруту.

В данном случае мы имеем дело с составным решением. Первое решение принимается относительно кофе, оно определяется двумя выходами из деятельности Поискать Напиток. Если кофе нет, мы приходим ко второму решению, связанному с колой.

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

Деятельность Выпить Напиток имеет два входа, что означает ее выполнение в любом из случаев. Данную ситуацию можно рассматривать как условие «ИЛИ» (выполняется, если выполняется хотя бы одна из двух деятельностей), а линейку синхронизации можно рассматривать как условие «И» (выполняется, если выполняются обе деятельности).

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

Их можно также применять где угодно – например, для описания вариантов использования.

[Слайд: Диаграммы деятельностей. Пример описания прецедента.]

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

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

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

Этот случай подчеркивает второй источник параллелизма на диаграмме деятельностей. Параллельные деятельности могут быть связаны не только с линейкой синхронизации, но также с множественной активизацией. Для любой множественной активизации нужно обязательно показать на диаграмме ее основу, как, например, в данном случае – «для каждой строки». Такое обозначение не является частью официального UML, однако можно считать его весьма важным для понимания диаграмм.

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

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

Рисунок. Получение заказа

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

Диаграмма деятельности прецедента, показанная на рисунке, содержит также тупик: деятельность Повторно заказать Позицию. После выполнения этой деятельности больше ничего не происходит. Тупики вполне нормально выглядят на такой не имеющей завершения диаграмме деятельностей, как данная. Иногда они выглядят очевидными, как деятельность Повторно заказать Позицию. В других случаях они не столь очевидны. Посмотрим на деятельность Проверить Позицию Заказа. У нее только один выход, который содержит условие. Что произойдет, если данной позиции не окажется на складе? Ничего – такая ветвь отсутствует.

В данном примере невозможно выполнить заказ, пока не пополнится запас на складе с помощью комплектующей поставки. Этой деятельности может соответствовать отдельный вариант использования.

[Слайд: Диаграммы деятельностей. Пример описания прецедента 2.]

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

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

Рисунок. Получение комплектующей поставки

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

[Слайд: Диаграммы деятельностей. Пример описания двух прецедентов.]

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

Рисунок. Получение заказа и комплектующей поставки

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

Любая деятельность может быть подвергнута дальнейшей декомпозиции. Описание декомпозированной деятельности может быть представлено в виде текста, кода или другой диаграммы деятельностей (см. рис. Декомпозированная диаграмма деятельностей).

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

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

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

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

[Слайд: Диаграммы деятельностей. Достоинства и недостатки.]

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

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

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

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

анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

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

Не рекомендуется использовать диаграммы деятельностей в следующих ситуациях:

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

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


Диаграммы компонентов

[Слайд: Диаграммы компонентов для клиента АТМ.]

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

На них изображены компоненты программного обеспечения вашей системы и связи между ними.

При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.

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

На рисунке изображена одна из диаграмм Компонентов для системы АТМ.

На этой диаграмме показаны компоненты клиента системы АТМ. В данном случае команда разработчиков решила строить систему с помощью языка С++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением .СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Например, класс ATM screen преобразуется в компонент ATM Screen диаграммы. Он преобразуется также и во второй компонент ATM Screen. Вместе эти два компонента представляют тело и заголовок класса ATM Screen. Выделенный темным компонент называется спецификацией пакета (package specification) и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка С++ (файл с расширением .Н). Компонент ATM.exe является спецификацией задачи и представляет поток обработки информации (thread of processing). В данном случае поток обработки является исполняемой программой.

Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс Card Reader зависит от класса ATM Screen. Это означает, что, для того, чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe.

[Слайд: Диаграммы компонентов для сервера АТМ.]

Пример АТМ содержит два потока обработки и, таким образом, получаются два исполняемых файла. Один из них – это клиент АТМ, он содержит компоненты Cash Dispenser, Card Reader и ATM Screen. Второй файл – это сервер ATM, включающий в себя компонент Account. Диаграмма Компонентов для сервера АТМ показана на рисунке.

Как видно из примера, у системы может быть несколько диаграмм компонентов, в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В общем случае, пакеты – это совокупности компонентов. Пример АТМ содержит два пакета: клиент АТМ и сервер АТМ.

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


18. Диаграммы классов.

[Слайд: Пример диаграммы классов.]

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

Пример диаграммы классов из задачи о банковском автомате для варианта использования "Снять деньги" показан на рисунке. Из рисунка видно, что в процессе «Снять деньги» задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM Screen (экран АТМ) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй – его атрибуты. Атрибут – это некоторая информация, характеризующая класс. Например, у класса Account (счет) имеется три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Account имеется четыре операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег).

Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen (экран АТМ), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct Funds и Verify Funds также закрыты для этого класса.

Точки зрения.

[Слайд: Точки зрения при разработке диаграмм классов.]

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

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

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

Точка зрения реализации. В этом случае модель действительно определяет реализацию классов ПО. Эта точка зрения является наиболее распространенной среди программистов.

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

Определения.

[Слайд: Определение класса.]

В UML принято следующее определение класса. Классом (class) называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

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

На рисунке представлено обобщенное представление класса, принятое в UML.

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

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

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

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

В UML отсутствует определение термина «понятие». Крэг Ларман [Ларман-2001] использует термины “понятие” и “тип” как взаимозаменяемые при описаниях объектов реального мира.

Видимость.

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

Public (Открытый, Общий, Общедоступный) – любой другой класс, который знает о существовании (видит) данный, может пользоваться его открытыми свойствами. В соответствии с нотацией UML открытые свойства обозначают знаком «+» (плюс) перед именем атрибута или операции. В Rational Rose они обозначаются наклоненным прямоугольником.

Protected (Защищенный) – любой потомок данного класса и сам класс может пользоваться его защищенными свойствами. Нотация в UML для защищенного свойства «#» (диез). В Rational Rose к наклоненному прямоугольнику добавляется символ ключа.

Private (Закрытый, Секретный) – только сам класс может пользоваться его закрытыми свойствами. В UML обозначается символом «-» (минус). В Rational Rose – к наклоненному прямоугольнику добавляется символ замка.

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

В каждом языке программирования существуют свои особенности использования описанных выше уровней видимости. Не вдаваясь в анализ различий (в книге [Фаулер-99] он кратко описан) можно сказать, что лучше применять правила определения видимости того языка на котором ведется разработка, и, поскольку видимость может изменяется в процессе кодирования, не следует определять ее слишком рано.

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

Описание отношений внутри диаграмм классов.

[Слайд: Диаграммы классов. Виды отношений.]

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

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

Существует три типа отношений, особенно важных для объектно-ориентированного моделирования:

Обобщения (Generalization) – определяет связи между обобщенными и специализированными классами. Проще говоря, это связи наследования.

Ассоциации (Association) – определяет структурные отношения между объектами. Показывает, как объекты одного класса связаны с объектами другого класса.

Зависимости (Dependency) – описывают существующие между классами отношения использования.

Отношение обобщения.

[Слайд: Диаграммы классов. Отношение обобщения.]

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

В этом примере описаны два типа сотрудников: с почасовой оплатой и получающих оклад. Оба этих типа наследуют от класса Employee. Класс Employee в таком случае называется суперклассом (superclass) или обобщенным классом (наиболее понятная терминология на мой взгляд – класс-предок), а оба производных от него класса – подклассами (subclass) или специализированными классами (класс-потомок). Стрелка показывает направление от специализированного класса к обобщенному.

Общие для обоих типов элементы размещаются в классе Employee. Таким образом, классы HourlyEmp и SalariedEmp наследуют от него атрибуты Name, Address, SSN и операции Hire() и Fire().

Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи. Класс сотрудников с почасовой оплатой имеет уникальный атрибут Rate (оплата в час), а класс сотрудников на окладе имеет уникальный атрибут Salary (Оклад).

Связи обобщения позволяют сэкономить время и усилия как при разработке, так и при дальнейшей поддержке программы. В приведенном примере вам не требуется писать и поддерживать две различные копии операции Hire() - для каждого подкласса. Достаточно разработать только одну копию. Любые сделанные в ней изменения будут автоматически наследоваться классами HourlyEmp, SalariedEmp и всеми остальными подклассами суперкласса Employee.

Определяя обобщение на диаграмме, можно развертывать структуру наследования сверху вниз или снизу вверх. В первом случае необходимо найти классы, у которых имеется несколько различных разновидностей. Например, изучив класс Employee, вы поймете, что существуют различные типы сотрудников. Если вы строите структуру снизу вверх, ищите классы, имеющие между собой что-то общее. В нашем примере, рассмотрев классы HourlyEmp и SalariedEmp, вы поймете, что они похожи друг на друга. После этого можно уже создать новый класс Employee для хранения общих элементов.

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

Отношение Ассоциации.

[Слайд: Диаграммы классов. Отношение Ассоциации.]

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

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

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

На рисунке приведен пример ассоциаций.

Существуют следующие дополнения, применимые к ассоциациям:

Имя – Ассоциации может быть присвоено имя, описывающее природу отношения. Обычно имя ассоциации указывают для явного задания смысла ассоциации. Это особенно полезно если в модели очень много ассоциаций и возникает потребность ссылаться на них по именам, чтобы отличать друг от друга. Имя ассоциации очень полезно в случае, если между одними и теми же классами существует несколько различных ассоциаций. В качестве имени ассоциации обычно используется глагольная фраза («Работает на», «Хранит», «Содержится в»), начинающаяся с прописной буквы.

Роль – Класс, участвующий в ассоциации, играет в ней некоторую роль. По существу, это «лицо», которым класс, находящийся на одной стороне ассоциации, обращен к классу с другой ее стороны. Один класс может играть в разных ассоциациях как одну и туже роль, так и различные. Имя роли задается меткой. В отсутствии метки имя роли совпадает с именем класса.

Кратность (Multiplicity) – роль также обладает кратностью (множественностью), которая показывает, сколько объектов может участвовать в данной связи. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце.

[Слайд: Диаграммы классов. Отношение Ассоциации. Множественность.]

В языке UML приняты следующие нотации для обозначения множественности:

Множественность

Значение

*

Много

0

Ноль

1

Один

0..*

Ноль или больше

1..*

Один или больше

0..1

Ноль или один

1..1

Ровно один

Можно также ввести собственное значение множественности в одном из следующих форматов:

Формат

Значение

<число>

ровно <число>

<число 1>..<число 2>

Между <числом 1> и <числом 2>

<число>..n

<число> или больше

<число 1>, <число 2>

<число 1> или <число 2>

<число 1>, <число 2>..<число 3>

ровно <число 1> или между <числом 2> и <числом 3>

<число 1>..<число 2>, <число 3>..<число 4>

между <числом 1> и <числом 2> или между <числом 3> и <числом 4>

Значение множественности позволяет понять, является ли данная связь обязательной. В рассматриваемом примере Работник может числится только в одном подразделении. При этом в подразделении может вообще не числится ни один работник. Если бы множественность была 1..*, то для каждого подразделения обязательно должен быть приписан хотябы один работник. Таким образом, множественность реализует бизнес-правило "Работник всегда должен числится в каком-либо подразделении".

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

[Слайд: Диаграммы классов. Отношение Ассоциации. Пример Жилец-Дом 1.]

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

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

[Слайд: Диаграммы классов. Отношение Ассоциации. Пример Жилец-Дом 2.]

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

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

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

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

[Слайд: Диаграммы классов. Рефлексивная Ассоциация.]

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

Классы ассоциации.

[Слайд: Диаграммы классов. Классы Ассоциации.]

Классы ассоциаций позволяют для ассоциаций определять атрибуты, операции, как это показано на рисунке.

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

Агрегация и композиция.

[Слайд: Диаграммы классов. Агрегация и композиция.]

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

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

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

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

Связь между классом-целое и классом-часть фактически для агрегации осуществляется по ссылке (By Reference), а для композиции по значению (By Value).

Отношение зависимости.

Зависимостью (Dependency) называют отношения использования, согласно которому изменение в спецификации одного элемента (например, класса Event) может повлиять на другой элемент, его использующий (в данном случае – класс Window), причем обратное необязательно. Графически зависимость изображается пунктирной линией со стрелкой, направленной от данного элемента на тот, от которого он зависит. Зависимость используется, когда необходимо показать, что один элемент использует другой. У зависимости может быть собственное имя, хотя оно редко требуется – разве что в случае, когда модель содержит много зависимостей и при работе необходимо ссылаться на них или отличать друг от друга. Чаще, однако, для различения зависимостей используются стереотипы.

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

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

[Слайд: Диаграммы классов. Отношение зависимости.]

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

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

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

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

Стереотипы классов

[Слайд: Диаграммы классов. Стереотипы классов.]

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

В языке UML определены три основных стереотипа:

Boundary (граница),

Entity (объект) и

Control (управление).

Пограничные классы

Пограничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.

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

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

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

Классы-сущности

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

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

Управляющие классы

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

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

Взаимодействие всех трех стереотипов схематично показано на диаграмме классов

и на диаграмме кооперации

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

Помимо упомянутых выше стереотипов можно создавать и свои собственные. В целом концепция стереотипов применима ко всем элементам UML и служит дополнительной классификацией для этих элементов. Каждый элемент может содержать не более одного стереотипа. Стереотип – это не то же самое, что родительский класс в отношении обобщения «Родитель-потомок». Его можно охарактеризовать как некоторый метатип.


19. Структура АИС

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

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

Поэтому информационная система, как и всякая иная, может иметь множество различных структур:

  1.  функциональную,
  2.  структуру комплекса технических средств,
  3.  структуру функциональной части,
  4.  структуру обеспечивающей части,
  5.  объектную структуру.

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

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

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

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

Рис. 1 Структура сети железных дорог

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

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

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

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

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

Правовое   Лингвистическое

Рис. 2 Структура ф-ц-ной и обеспечивающей частей ИС

Рис. 3. Структура ф-ц-ой части ИС сортировочной станции (уровень функций)

Техническое обеспечение — это совокупность всех технических средств, используемых при функционировании автоматизированной системы.

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

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

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

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

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

  1.  
    Понятие открытые АИС. Глобальная сеть
    Internet как пример открытой информационной системы. Назначение информационных систем применяющихся на железной дороге на примере информационных систем АСОУП, ДИСКОН, ДИСКОР, ДИСПАРК, ЭКСПРЕСС-3 и т.д.

Профили открытых информационных систем.

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

Широко используется стандарптная система многоуровневых протоколов – базовая эталонная модель взаимосвязи открытых систем (BOC), разработанная ISO и и изданная в 1984 г. в виде международного стандарта ISO 7498 «Базовая эталонная модель взаимосвязи открытых систем.». Позже этот стандарт методом прямого внедрения был принят Международным консультативным комитетом по телеграфии и телефонии в виде Рекомендаций Х.200 «Эталонная модель ВОС для применения МККТТ».

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

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

Internet - глобальная компьютерная сеть, охватывающая весь мир. Сегодня Internet имеет около 15 миллионов абонентов в более чем 150 странах мира. Ежемесячно размер сети увеличивается на 7-10%. Internet образует как бы ядро, обеспечивающее связь различных информационных сетей, принадлежащих различным учреждениям во всем мире, одна с другой.

ИНТЕРНЕТ (англ. Internet, от лат. inter — между и англ. net — сеть), всемирная компьютерная сеть, соединяющая вместе тысячи сетей, включая сети вооруженных сил и правительственных организаций, образовательных учреждений, благотворительных организаций, индустриальных предприятий и корпораций всех видов, а также коммерческих предприятий (сервис-провайдеров), которые предоставляют частным лицам доступ к сети

АСОУПАвтоматизированная система оперативного управления перевозками.

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

В состав АСОУП входят: комплекс технических средств, система информационного обеспечения, технология, обеспечивающая её функционирование, программные средства.

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

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

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

ДИСКОН - автоматизированная система контроля дислокации контейнерного парка.

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

ДИСКОН имеет 3-х уровневую структуру:

  1.  линейный: станции -
  2.  дорожный: управление дорог;
  3.  сетевой: МПС.

На линейном - операции непосредственно с контейнерами, документируют тип операции и вводят информацию в систему. Основан на использовании АСУ КП (контейнерного пункта), АРМ СПВ (пограничные переходы), АРМ агента припортовой станции.

ДИСКОН - мощная система контроля входной информации. Информация проверяется на соответствие с НСИ и ранее введенной информации.

ДИСПАРК - Автоматизированная система полномерного учета, контроля дислокации, анализа использования и регулирования вагонного парка на железных дорогах России.

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

Система ДИСПАРК предназначена для: формирования объективных данных о наличии и состоянии вагонного парка на сети, железных дорогах, обеспечения сохранности вагонного парка РФ. Обеспечения функционирования систем взаиморасчетов за пользование вагонами на основе учета времени нахождения каждого вагона на территории государства и железной дороги; обеспечения полномерного контроля наличия вагонов на новостройках, за границей и на подъездных путях; создания условий для отказа от безномерного способа учета простоя вагонов. Получения данных о дислокации и состоянии вагонов заданного типа, оперативного анализа использования вагонов в соответствии со специализацией и техническими характеристиками вагонов. Получения (по номерам) данных о дислокации вагонов заданного типа, назначения, с определенным грузом; гарантированного розыска вагонов по инвентарному номеру; подбора вагонов по заявкам клиентов; оперативной корректировки плана формирования поездов; оптимального управления парком вагонов предприятий; отслеживания по каждому вагону инвентарного парка объемов выполненной им работы (пробегов) в груженом и порожнем состоянии.

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

ДИСПАРК является одним из важнейших комплексов информационных технологий и включает три уровня:

  1.  сетевой (ГВЦОЛО «РЖД»); Сетевой уровень системы ДИСПАРК реализуется на базе вагонной модели ГВЦ ОАО «РЖД» в увязке с цен тральной картотекой электронных паспортов вагонов (ЦКПВ).
  2.  дорожный (ИВЦ ж.д.); Дорожный уровень 1-й очереди системы реализуется в АСОУ11 на базе средств ведения вагонной модели дороги (ВМД), в увязке с ЕК ИОДВ и АРМ ТВК по информации о погрузке грузов в вагоны. Дорожный уровень ДИСПАРК-2 реализуется как часть общей системы управления грузовыми перевозками железных дорог (АСУ ГП ж.д.), на современных ГПК
  3.  линейный (локальные сети и отдельные АРМ на базе ПК для работников линейных предприятий), с постепенным преобразованием линейных систем в комплексы АРМ пользователей, работающих напрямую с дорожными базами данных. Линейный уровень 1-й очереди системы ДИСПАРК основывается на следующих системах: АСУ сортировочных, грузовых и других крупных станций; АСУ (АРМ) СПВ; АРМ ТВК; АРМ операторов по учету в ВЧД, ППС, ППВ, ПТО.

Организационная структура системы ДИСПАРК приведена на рис. 2.5.

Необходимым условием функционирования системы ДИСПАРК является наличие разработанном и внедренной системы АБД11В (Автоматизированный банк данных инвентарного парка вагонов железных дорог и вагонов, принадлежащих предприятиям и другим организациям), включающую центральную картотеку парка вагонов (ЦКПВ) в ГВЦ ОАО «РЖД», дорожные их копии (ДЦКПВ) в АСОУП и программные средства их актуализации и синхронизации. В ЦКПВ и ДКПВ описываются технические характеристики всех эксплуатируемых па общей сети железных дорог СНГ вагонов. По сути, эти базы являются статической вагонной моделью. Вагонные модели системы ДИСПАРК являются динамическими базами данных, отражающими в реальном времени вес операции с вагонами. При этом соблюдается принцип — все вагоны, до выхода их на общую сеть железных дорог должны быть зарегистрированы в АБД ПВ.

Принципы ведения вагонной модели системы ДИСПАРК. Вагонная модель дороги (ВМД) является основным элементом системы — на базе информации ВМД решаются все прикладные задачи дорожного и линейного уровня системы ДИСПАРК и ведется сетевая вагонная модель в ГВЦ ОАО «РЖД» (ВМС).

Парк вагонов, отражаемый в ВМД, включает:

а) вагоны, находящиеся на выделенных станциях в поездах вне поездов на станционных путях; на территории ВЧД, ППВ, ППС и т.п.; на подъездных путях клиентов;

б) вагоны, находящиеся па участках между выделенными станциями: в поездах па участке; вне поездов на станциях участка; на подъездных путях клиентов;

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

На первом этапе внедрения системы введены в действие методы оперативного управления «чужими» вагонами с просроченными сроками возврата и налажен анализ передачи, погрузки и выгрузки, как на железных дорогах, так и в ОАО «РЖД». Созданы предпосылки для проведения полномерных взаиморасчетов за пользование вагонами других государств. Завершен переход к автоматизированному оперативному контролю и анализу нарушений сроков доставки грузов, формированию отчетности о вагонном парке и решению ряда других задач.

Основные задачи управления вагонным парком.

  •  Анализ распределения вагонов на РЖД по любому типу подвижного состава.
    •  Контроль времени нахождения вагонов других государств на РЖД.
    •  Анализ нарушений погрузки «чужих» вагонов.
    •  Управление нарком полувагонов.
    •  Управление парком цистерн.
    •  Управление передачей поездов и вагонов.
    •  Управление вагонами, отцепляемыми от транзитных поездов.
    •  Управление отдельно взятым вагоном.
    •  Управление техническим состоянием вагонного парка.

Важной функцией системы является оперативный анализ использования вагонов рабочего парка Системой ДИСПАРК регулярно фиксируется неудовлетворительное использование грузовых вагонов принадлежности стран СНГ на российских железных дорогах.

Дальнейшее развитие функций системы предусматривает расширение применяемых методов контроля качества использования вагонного парка, которые более подробно рассмотрены в следующих подсистемах ДИСПАРК: управление национальным парком, включая, кроме РЖД, железные дороги стран СИГ и Балтии; управление выделенными типами подвижного состава в условиях работы национального парка вагонов; слежение за вагонами других администраций на территории Российских железных дорог; слежение за российскими вагонами, длительно простаивающими в странах СНГ и Балтии; управление работой парка цистерн ОАО «РЖД»; управление парком вагонов собственности предприятий, переданных в аренду, приобретенных по лизингу и т.д.

ДИСКОН - Автоматизированная система управления контейнерными перевозками

На РЖД ежесуточно осуществляется погрузка до 10 тыс. контейнеров принадлежности российских железных дорог, инвентарного парка общего пользования стран СНГ и Балтии, а также приватных (собственных) контейнеров.

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

- наиболее рациональной работы с каждым контейнером;

- осуществления постоянного контроля за дислокацией и состоянием контейнера;

- контроля соблюдения правильности выполнения каждой операции с ним.

Ни один контейнер не должен выходить из поля зрения системы при нахождении его на российских железных дорогах. Такие подходы приняты сейчас в мире и реализованы на многих ведущих железных дорогах Европы и Америки. Таким образом, с созданием новой Автоматизированной системы управления контейнерными перевозками и РЖД в этом вопросе выходят на один уровень с передовыми железными дорогами мира. 

Автоматизированная система ДИСКОН аналогично действующей системе управления в отрасли имеет трехуровневую структуру:

  1.  линейный уровень — уровень станций;
  2.  дорожный уровень — уровень управлений железных дорог;
  3.  сетевой уровень — уровень ОАО «РЖД».

На линейном уровне непосредственно осуществляются операции с контейнерами, документирование этих операций и ввод информации в систему.

В системе предусмотрено автоматическое формирование и передача на дорожный уровень сообщений о выполняемых с контейнерами операциях. Кроме того, раз в сутки формируется комплекс сообщений в объеме отчета формы КЭО-3 «Отчет о движении контейнеров». Система в автоматическом режиме выдает оперативные документы: вагонные листы, наряды на завоз-вывоз контейнеров, наряды крановщику, а также все установленные формы учета и отчетности по контейнерным перевозкам.

Автоматизированная система управления контейнерным пунктом решает следующие задачи:

  •  оперативное планирование работы контейнерного пункта;
    •  взаимодействие с дорожным уровнем АСУ контейнерными перевозками;
    •  контроль за подачей и уборкой вагонов с контейнерами;
    •  обеспечение оптимального контейнерообразования;
    •  оптимальное планирование порейсовой работы крапов, передачи информации на кран и с крана в ПК;
    •  выполнение погрузочно-разгрузочных работ, учет работы крановщиков;
    •  организация ввоза и вывоза контейнеров, планирование работы автомобильного транспорта;
    •  ведение модели контейнерной площадки;
    •  ведение учета и отчетности о работе с контейнерами;
    •  оформление перевозок грузов в контейнерах и другие функции товарного кассира.

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

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

Информация с линейного уровня в ДИСКОН поступает на дорожный уровень системы, где в каждом из 17 ИВЦ железных дорог ведутся оперативные динамические модели операций с контейнерами (КМД) 11ривсдсппос описание информационного обеспечения системы позволяет сделать еще один вывод: в системе сделана основательная подготовка к переходу на электронный документооборот в контейнерных перевозках. Это должно стать одной из первоочередных задач развития системы.

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

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

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

Уже на первых этапах создания системы ДИСКОН номерные контейнерные модели на дорожном и сетевом уровне позволили по-новому, более эффективно решать ряд важнейших задач, а именно:

обеспечение сохранности инвентарного парка контейнеров;

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

обоснованный и точный расчет платы за пользование контейнерами как «чужими» на РЖД, так и принадлежности ОАО «РЖД» на других дорогах СНГ и Балтии;

информирование контрагентов перевозки о состоянии и дислокации контейнеров на любой момент времени;

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

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

В связи с этим одной из задач нового этапа развития ДИСКОН должна стать разработка средств формирования статистической отчетности. Для контейнерных перевозок это прежде всего отчет формы КЭО-3.

Еще одна проблема, которая становится вес более актуальной для системы ДИСКОМ — автоматизация идентификации контейнеров. В мире существует и практически используется несколько типов систем автоматического считывания информации с контейнеров. Основными из них являются системы двух типов: с использованием датчиков, устанавливаемых на контейнеры, и оптические системы считывания номеров контейнеров. Каждая из названных систем имеет свои достоинства и недостатки. Для условий Российских железных дорог, возможно, следует вести проработки по обоим направлениям. Оптическая система имеет одно неоспоримое преимущество — это возможность работы с контейнерами любой принадлежности. Дело в том, что доля контейнеров принадлежности ОАО «РЖД» в контейнерных перевозках не является до минирующей и имеет тенденцию к снижению. А это значит, что альтернативный вариант — с установкой датчиков, помимо более существенных затрат на реализацию, не обеспечит автоматизации ввода кодов для значительной части контейнеров. Таким образом, одной из важнейших задач должна стать практическая отработка автоматическою считывания номеров контейнеров с использованием оптических систем.

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

«Экспресс3».

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

«Экспресс-3». Главное требование при организации ведения классификаторов - идентичность нормативно-справочной информации во всех информационно-вычислительных центрах дорог для решения комплекса задач на сетевом уровне.

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

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

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

Система «Эффективность» функционирует на базе технического и программно-математического обеспечения АСУ «Экспресс-3».

Организационная структура АСУ «Экспресс-3» включает дорожные информационно-вычислительные центры (ИВЦ) и головной ИВЦ Московской дороги. Головной центр помимо решения задач дорожного уровня обслуживает сетевую аналитическую базу данных (АБД). Здесь в оперативном режиме осуществляется решение комплекса задач «Эффективность» и создается архив о работе пассажирского подвижного состава с глубиной хранения информации 12 лет.

В функции системы оперативного отслеживания экономической эффективности входят формирование банка данных о суммарных расходах и эксплуатационных показателях по пассажирским перевозкам в дальнем сообщении, расчет укрупненных расходных ставок по железным дорогам, обеспечение автоматизированного сбора, обработки, накопления эксплуатационных измерителей по пассажирским поездам с учетом их нахождения на территории дороги формирования и дорог - участниц перевозки. Кроме этого, система оперативно отслеживает финансовые результаты работы пассажирского подвижного состава, обеспечивает функционирование принятой в АСУ «Экспресс» методики определения экономической эффективности назначения пассажирских поездов и отдельных вагонов, а также способствует выработке и принятию решений об изменении схем составов, периодичности курсирования и размерах движения поездов. В процессе информационного взаимодействия участвуют Департамент дальних пассажирских перевозок ОАО «РЖД», Департамент бухгалтерского и налогового учета ОАО «РЖД», головной ИВЦ Московской дороги, дорожные ИВЦ, пассажирские службы, дирекции по обслуживанию пассажиров. Департамент дальних пассажирских перевозок контролирует выполнение экономических расчетов по поездам дальнего следования на всей сети РЖД, определяет основные направления развития в соответствии с целями и задачами реформирования пассажирского хозяйства. Департамент бухгалтерского и налогового учета отвечает за передачу информации годового отчета формы 6-жел в АСУ «Экспресс-3».

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

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

Дорожные ИВЦ передают информацию общего архива систем «Экспресс» и нормативно-справочную информацию по поездам дальнего следования в головной ИВЦ. Пассажирские службы дорог и дирекции по обслуживанию пассажиров передают в АБД системы «Экспресс» сообщения о показателях работы дорог за отчетный год.


21. Классификация моделей: сетевая, иерархическая, реляционная, постреляционная модели данных. Основная цель моделирования.

Типы моделей:

  1.  Иерархическая модель – модель этого типа жестко структурирована, т.е. взаимосвязи между объектами внутри модели подчинены строгому ранжиру (порядок).

Подчинение объектов разделено на уровни: - На 1-м уровне представлен главный объект, которому подчиняются объекты на 2-м уровне. При чем объект 1-го уровня не может напрямую управлять объектом 3-го уровня. Управление объектом 3-го уровня возможно только через 2-й. Запрещены взаимосвязи на одном уровне. Взаимосвязь между главным и подчиненными один ко многим. Иерархические модели представлены графически как перевернутое дерево.

  1.  Сетевая модель. Она более демократична, в ней отсутствует понятие главного и подчиненного объекта. Один и тот же объект может выступать как главный, так и подчиненный. Доступно любое количество взаимосвязей, допустимы связи на одном уровне. (WWW)

  1.  Комбинированная модель = иерархическая + сетевая.
  2.  Реляционная модель. В ней объекты представлены в виде таблиц. Таблицей могут отображаться не только объекты, но и связи. Каждая таблица состоит из произвольного количества строк и столбцов.

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

В реляционной модели имеются следующие типы объектов:

  •  Таблица (отношения);
  •  Атрибуты (столбцы);
  •  Домены (допустимые значения атрибутов)

Существуют 3-и типа взаимосвязи:

  1.  Один к одному;
    1.  Один ко многим;
    2.  Многие ко многим.

Преимущества реляционных моделей:

  •  Простота представления данных;
    •  Минимальный избыток данных, что достигается путем нормализации таблиц;
      •  Независимость приложения пользователя от данных;
      •  Возможность изменения состава атрибутных отношений;
      •  Отсутствие необходимости описывать схемы данных.

Недостатки реляционных моделей:

- Нормализация таблиц приводит к значительной фрагментации данных

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

Под моделью понимается полное описание системы ПО с определенной точки зрения.

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

Разработка модели архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, в такой же мере необходима, как и наличие проекта для строительства большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продуктов класса R/3 или BAAN, в составе которых также имеются собственные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры. Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других факторов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным.

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


22. Методы проектирования на основе структурного подхода

Методы проектирования на основе структурного подхода

Использование системного структурного анализа при проектироние ИС.

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

Для таких методов характерно:

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

Этапы процесса разработки КИС

Этапы процесса разработки информационных систем - "системный анализ и проектирование", "разработка", "кодирование", "тестирование", "внедрение" были выделены еще в 70-е годы XX века.
Модель называется каскадной, если каждый последующий этап вытекает из предыдущего этапа (рис. 1.1).

Рис. 1.1. Каскадная модель разработки информационных систем.

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

Рис. 1.2. Итерационная модель разработки информационных систем

Следует отметить, что этап системного анализа и проектирования является обязательным этапом работ, который должен предварять все последующие и определяет "фундамент для обеспечения функциональной адекватности и качества" разрабатываемой информационной системы [4]. От качества системного анализа и проектирования непосредственно зависит степень удовлетворенности заказчика от внедренной информационной системы, особенно, если речь идет о корпоративных информационных системах (КИС).
В последовательности выработки требований заказчика по этапу системного анализа и проектирования выделяют три фазы [2]:

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

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

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

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

В этапах разработки определены особенности, характерные для крупных проектов КИС. Это:

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

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

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

Одной из самых известных и распространенных методологий бизнес-анализа и функционального проектирования информационных систем является методология SADT (Structured Analysis and Design Technique), введенная в 1973 году Россом. SADT успешно использовался и используется в военных, промышленных и коммерческих организациях для решения широкого спектра задач. Подмножеством SADT является стандарт IDEF0, который, обладая автоматизированной поддержкой, является доступным и простым в употреблении. Применение необходимо ограничить, в основном, первыми уровнями декомпозиции бизнес-процессов. Излишняя детализация усложняет чтение и сопровождение модели.

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

  1.  Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются.
  2.  Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); связность диаграмм (номера блоков); уникальность меток и наименований (отсутствие повторяющихся имен); синтаксические правила для графики (блоков и дуг); разделение входов и управлений (правило определения роли данных).
  3.  Отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 3 - Структура SADT-модели. Декомпозиция диаграмм

Функциональное моделирование IDEF0-модель

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

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

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

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

Рис. 1 Пример описание функции с помощью IDEF0-диаграммы.

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

На рис.1 пример контекстной диаграммы. Здесь мы имеем:

Вход: Исходный документ о приеме на работу

Управляющая и нормативная информация: штатное расписание; Правила согласования в администрации предприятия.

Выход: Утвержденный документ(приказ о приеме на работу)

Исполнитель: инспектор отдела кадров, автоматизированная система отдела кадров

Технология IDEF0 не ограничивает количество уровней декомпозиции. Это дает возможность получить модель процедуры с требуемой степенью детализации. IDEF0-техналогия поддерживается пакетами BPWin, Design/IDEF.

Информационное моделирование IDEF1-модель

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

Связь –поименованная ассоциация между сущностями.

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

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

Технология IDEF1 включает в себя набор правил, процедур построения и графического отображения информационной модели (IDEF1-модели).

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

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

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

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

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

Событийное моделирование IDEF0 PN-модель

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

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

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

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

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

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

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

Фактически IDEF0, IDEF1, IDEF0 PN-модели являются компонентами интегрированной технологии разработки программного обеспечения: статические IDEF0 –модели преобразуется в динамическую модель IDEF0 PN, которая затем исполняется в различных режимах с целью получения динамических характеристик проектируемой системы.

ERD

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

В реальном проектировании структуры базы данных применяется метод, называемый семантическим моделированием. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты «диаграмм сущность-связь» (ER - Entity-Relationship).

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

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

Основные понятия ER-диаграмм

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

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

Каждая сущность в модели изображается в виде прямоугольника с наименованием:

Рис. 12. Пример сущности

2. Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".

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

3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

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

Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

Рис. 13.  Пример Атрибутов сущности

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

Сущность может иметь несколько различных ключей.

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

Рис.  14.  Пример ключа сущности

5. Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.

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

Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

Графически связь изображается линией, соединяющей две сущности:

Рис. 15. Пример связи сущности

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

Каждая связь может иметь один из следующих типов связи:

Рис. 16.  Типы связей ER-диаграмм

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на рис. 15.

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

Каждая связь может иметь одну из двух модальностей связи рис. 17:

Рис. 17.  Модальность связей

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

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

Связь может иметь разную модальность с разных концов (как на рис. 15).

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 15 читается так:

Слева направо: "каждый сотрудник может иметь несколько детей".

Справа налево: "каждый ребенок обязан принадлежать ровно одному сотруднику".

Типы диаграмм

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

Основные типы диаграмм:

  •  · контекстная диаграмма А-0 (в каждой модели может быть только одна контекстная диаграмма);
  •  · диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную).

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

Рис. 3.3. Контекстная диаграмма А-0.

Элементы диаграмм

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

Рис. 3.4. Диаграмма А0.

Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу.
Стрелки (Arrows). Взаимодействие работ с внешним миром описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, "Заготовка", "Изделие", "Заказ").
В IDEF0 различают пять типов стрелок:

  •  · Вход (Input) - материал или информация, которая используется или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне блока, или выходит из нее. Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.
  •  · Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Управление влияет на работу, но не преобразуется ей. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом.
  •  · Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла.
  •  · Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д.
  •  · Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. Используются в механизме слияния и разделения моделей.

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


Построение диаграмм, описывающих стандарт IDEF0

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

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

Выходными данными будут печатные издания, требуемые читателями. Определив входы и выходы модели, необходимо определить ограничения:

Во-первых, так как выполнение работы библиотеки лежит полностью на ее работниках, то и исполнителем работы будет персонал.

Во-вторых, управляющим инструментом («руководством к действию») являются установленные правила библиотеки и должностные инструкции в которых описываются основные правила и инструкции совершения всех операций по работе библиотеки её работниками. В результате получается контекстная диаграмма (рис 3). Таким образом, мы получаем общее представление модели.

Рисунок 3 – Контекстная диаграмма А-0

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

Рисунок 4 – Диаграмма декомпозиции А0

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

  1.  Сортировка печатных изданий.
  2.  Оформление печатных изданий.
  3.  Размещение печатных изданий по местам хранения.
  4.  Обслуживание читателя

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

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

На следующей схеме представлена детализация работы «Сортировка печатных изданий» (см. приложение):

Поступившие печатные издания необходимо разгрузить, т.е. провести разгрузочные работы.

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

Перечисленные работы подлежат дальнейшей декомпозиции:

Разгрузочные работы можно разделить на следующие этапы:

- доставка в библиотеку

- прием по накладным

- распаковка

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

- Проверка количества изданий

- Проверка качества изданий

- Сверка по цене

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

- Сортировка по видам изданий (книги, журналы)

- Сортировка по тематике (научная, художественная литература)

- Сортировка по отделам (абонемент, читальный зал, хранилище)

Выходными данными являются отсортированные издания.

Каждой диаграмме присваивается свой уникальный номер. Номер начинается с буквы А (Activity) и включает в себя порядковый номер родительской диаграммы. Таким образом получается иерархия диаграмм модели, которую можно отобразить в виде дерева узлов (node tree). Дерево узлов представлено на рисунке 5.

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

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

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

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

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

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

объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

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


Программа BPwin

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

  •  Обеспечить эффективность операций, рассматривая текущие бизнес-операции через мощные инструменты моделирования.
  •  Совершенствовать бизнес-процессы, формулируя и определяя альтернативные реакции на воздействия рынка.

С использованием BPwin строятся диаграммы бизнес-процессов (блоки), показывающие результаты их работы и ресурсы, необходимые для их функционирования.

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

В чем польза от BPwin

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

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

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

BPwin позволяет:

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

Совершенствовать бизнес-процессы, формулируя и определяя альтернативные реакции на воздействия рынка.

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

Некоторые достоинства BPwin

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

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

BPwin позволяет адаптироваться к постоянно меняющимся реалиям современного рынка

Конкуренция предполагает мгновенную реакцию на новые возможности, угрозы и потребности покупателей. Сегодня постоянные изменения стали нормой. Поскольку бизнес-процессы становятся все более сложными, требуются решения, представляющие интегрированный взгляд на функционирование компании. Таким решением является новый BPwin 4.0 SP1.

Управление сложными бизнес-процессами

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

Анализ бизнеса с различных сторон: поддержка в BPwin сразу трех нотаций: IDEF0, IDEF3 и DFD

BPwin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям бизнес-аналитиков и системных аналитиков. BPwin позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования.

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

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

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

С использованием BPwin строятся диаграммы бизнес-процессов (блоки), показывающие результаты их работы и ресурсы, необходимые для их функционирования.

BPwin можно также использовать для моделирования потоков работ, потоков процессов и потоков данных.

BPwin поддерживает 3 методологии моделирования:

функциональное моделирование (IDEF0);

- описание бизнес-процессов (IDEF3);

- диаграммы потоков данных (DFD).

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

Рисунок  – Иерархия стадий моделирования

Построение контекстной диаграммы

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

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

В качестве примера рассматривается деятельность вымышленной компании «Computer Word». Компания занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры.

Основные виды работ в компании таковы:

продавцы принимают заказы клиентов;

операторы группируют заказы по типам компьютеров;

операторы собирают и тестируют компьютеры;

операторы упаковывают компьютеры согласно заказам;

кладовщик отгружает клиентам заказы.

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


23. Структурный анализ

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

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

Для таких методов характерно:

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

  •  Методологии структурного подхода базируются на следующих принципах:
    •  Решение сложных проблем путем их разбиения на множество меньших задач, легких для понимания
    •  Иерархическое упорядочение составных частей
    •  Абстрагирование – т.е. выделение существенных аспектов системы и отбрасывание несущественных
    •  Непротиворечивость – т.е. согласованность элементов

Три вида структурного анализа:

  1.  Анализ функций системы (функциональное моделирование) – используются диаграммы потоков данных (DFD).
    1.  Анализ данных (информационное моделирование) - используются диаграммы «сущность - связь» (ERD)
    2.  Анализ поведения систем (событийное моделирование) - используются диаграммы переходов состояний (STD)

Этапы процесса разработки КИС

Этапы процесса разработки информационных систем - "системный анализ и проектирование", "разработка", "кодирование", "тестирование", "внедрение" были выделены еще в 70-е годы XX века.
Модель называется каскадной, если каждый последующий этап вытекает из предыдущего этапа (рис. 1.1).

Рис. 1.1. Каскадная модель разработки информационных систем.

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

Рис. 1.2. Итерационная модель разработки информационных систем

Следует отметить, что этап системного анализа и проектирования является обязательным этапом работ, который должен предварять все последующие и определяет "фундамент для обеспечения функциональной адекватности и качества" разрабатываемой информационной системы [4]. От качества системного анализа и проектирования непосредственно зависит степень удовлетворенности заказчика от внедренной информационной системы, особенно, если речь идет о корпоративных информационных системах (КИС).
В последовательности выработки требований заказчика по этапу системного анализа и проектирования выделяют три фазы [2]:

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

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

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

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

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

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

Принципы структурного анализа

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

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

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

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

аналитик сталкивается с чрезмерным количеством подробных сведений, как о предметной области, так и о новой системе;

спецификация системы из-за объема и технических терминов часто непонятна для заказчика;

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

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

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

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

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

  1.  Принцип абстрагирования  заключается   в   выделении существенных с некоторых позиций аспектов системы и в отвлечении от несущественных с  целью представления проблемы в простом общем виде.
  2.  Принцип   формализации заключается   в   необходимости строгого методического подхода к решению проблемы.
  3.  Принцип упрятывания  заключается   в   упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
  4.  Принцип концептуальной общности заключается    в следовании единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование).
  5.  Принцип полноты заключается в контроле на присутствие лишних элементов.
  6.  Принцип непротиворечивости заключается в обоснованности и согласованности элементов.
  7.  Принцип логической независимости заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
  8.  Принцип независимости данных заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
  9.  Принцип структурирования данных заключается в том, что данные     должны быть структурированы и иерархически организованы.
  10.  Принцип доступа конечного пользователя заключается в том,  что  пользователь должен иметь средства доступа к базе данных, которые он  может использовать непосредственно (без программирования).

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


24. Понятие и
нформационный процесс. Структура информационного процесса. Элементарные операции информационного процесса (процессы сбора, хранения, обработки и передачи информации)

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

Структура информационного процесса

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

Рис.1. Структура информационного процесса

Элементарные операции информационного процесса

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

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

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

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

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

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

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

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

Рис. 5.1. Работа системы зрительного восприятия текстовой информации

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

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

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

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

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

Сбор информации

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

Как правило, современные системы сбора информации не только обеспечивают кодирование информации и ее ввод в ЭВМ, но и выполняют, предварительную (первичную) обработку этой информации.

Сбор информации — это пpoцесс получения информации из внешнего мира и приведение ее к виду, стандартному для данной информационной системы.

Обмен информацией между воспринимающей информацию системой и окружающей средой осуществляется посредством сигналов.

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

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

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

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

2 шаг - вторичный (электрический) сигнал в некоторый выделенный момент времени оцифровывается специальным устройством — аналого-цифровым преобразователем (АЦП). АЦП значению электрического сигнала ставит в соответствие некоторое число из конечного множества таких чисел.

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

Конечно, не все технические средства сбора информации работают по описанной схеме. Так, клавиатура, предназначенная для ввода алфавитно-цифровой информации от человека, не имеет в своем составе АЦП. Здесь первичный сигнал — нажатие клавиши — непосредственно преобразуется в соответствующий нажатой клавише цифровой код. Но в любом случае, будь то цифровой измерительный прибор, клавиатура или иное устройство ввода информации в ЭВМ, в конечном счете поступающая в ЭВМ информация представлена в виде цифрового кода — двоичного числа. Современные системы сбора информации (например, в составе автоматизированных систем управления) могут включать в себя большое количество (тысячи) цифровых измерительных приборов и всевозможных устройств ввода информации (от человека в ЭВМ, от ЭВМ к ЭВМ и т.п.). Такое комплексирование средств приводит к необходимости управления процессом сбора информации и к разработке соответствующего программного (и аппаратного) обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информацию, поступающую в информационную систему, называют