Реферат. Корпоративные информационные системы

Министерство образования Республики Казахстан

Казахский экономический университет

им. Т.Рыскулова

 

 

 

 

 

 

 

Реферат

 

 

 

Кафедра: Прикладная Информатика

На тему: Корпоративные информационные системы

 

 

 

 

 

 

                                                                         Выполнил студент:

гр. Ис-203

Онгарбаев Р.Н

Проверила:

Рябченко В.А.

 

2008

 

1. Введение

 

Цель курса.

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

Задача курса.

Формирование у студентов знаний, которые являются общими для пользователей и разработчиков КИС.

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

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

• Понятие КИС

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

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

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

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

Замечание.

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

• Автоматизированные системы управления (АСУ);
• Интегрированные системы управления (ИСУ);
• Интегрированные информационные системы (ИИС);
• Информационные системы управления предприятием (ИСУП).

 

 

• Этапы разработки КИС

 

В данном разделе использованы материалы из книги Орлов С.А. Технологии разработки программного обеспечения: Учебник. – СПб.: Питер, 2002. – 464 с.

Классический жизненный цикл

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

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

 

Рис. Классический жизненный цикл разработки ПО.

Приведем краткое описание основных этапов. Разработка начинается на системном уровне и проходит через

— анализ,

— проектирование,

— кодирование (реализация),

— тестирование,

— сопровождение

При этом моделируются действия стандартного инженерного цикла.

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

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

На этом этапе начинается решение задачи планирования проекта ПО.

В ходе планирования проекта определяются:

            — объем проектных работ,

            — риск проектных работ,

            — необходимые трудозатраты,

            — формируются рабочие задачи,

            — формируется план-график работ.

Анализ требований, относящийся к программному элементу, т.е. к ПО, уточняет и детализирует:

            — функции ПО,

            — характеристики ПО,

            — интерфейс ПО.

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

Проектирование создает представления:

            — архитектуры ПО,

            — модульной структуры ПО,

            — алгоритмической структуры ПО,

            — структуры данных,

            — входного и выходного интерфейса (входных и выходных форм данных).

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

Тестирование – это выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:

            — исправление ошибок,

            — адаптация к изменениям внешней для ПО среды,

            — усовершенствование ПО по требованию заказчика.

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

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

Достоинствами классического жизненного цикла являются:

            — получение плана и временного графика по всем этапам проекта,

            — упорядочение хода разработки.

К недостаткам классического жизненного цикла относятся:

            — частое отклонение реальных проектов от стандартной последовательности                       шагов,

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

— доступность результатов проекта заказчику лишь в конце работы.

Макетирование (прототипирование)

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

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

Модель может принимать одну из трех форм:

— бумажный макет или макет на основе ПК (изображает или рисует человеко – машинный диалог),

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

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

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

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

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

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

 

Рис. Последовательность действий при макетировании.

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

К недостаткам макетирования относятся:

            — возможность принятия заказчиком макета за продукт,

            — возможность принятия разработчиком макета за продукт

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

 

 

Стратегия разработки ПО

Стратегии разработки ПО можно подразделить на три группы:

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

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

Инкрементная стратегия

 

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

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

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

Замечание. Современная реализация инкрементного подхода – экстремальное программирование ХР. Оно ориентировано на очень малые приращения функциональности.

 

Эволюционная стратегия разработки ПО

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

Спиральная модель

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

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

С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются:

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

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

К достоинствам спиральной модели относится:

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

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

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

 

Компонентно-ориентированная модель.

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

К достоинствам компонентно-ориентированной модели относится:

• уменьшение времени разработки ПО;
• снижение стоимости программной разработки;
• повышение производительности разработки.

Тяжеловесные и облегченные процессы

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

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

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

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

 

• Об унифицированном процессе и языке моделирования

 

В данном разделе использованы материалы из книг:

 Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2002. – 496с.;

Скотт К. UML. Основные концепции. – М.: Издательский дом «Вильямс», 2002. -144 с.

 

Общие сведения.

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

 

Рис. Процесс разработки ПО.

 

УП – это обобщенный каркас процесса, который может быть специализирован для:

• широкого круга программных систем,
• различных областей применения,
• размеров проекта

 

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

 Для разработки чертежей программной системы используется унифицированный язык программирования (UML). UML является неотъемлемой частью УП. УП и UML разрабатывались совместно. Специфические аспекты УП:

• управляемый вариантами использования;
• архитектурно-ориентированный;
• итеративный и инкрементный.

Краткие пояснения.

УП управляется вариантами использования

 

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

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

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

 

УП ориентирован на архитектуру

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

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

• выбор платформы для работы программы (т.е. компьютерной архитектуры, ОС, СУБД, сетевых протоколов);
• нефункциональные требования (например, производительность, надежность);
• и т.д.

Архитектура – это представление всего проекта с выделением важных характеристик.

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

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

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

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

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

УП является итеративным и инкрементным

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

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

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

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

Полное представление готового продукта состоит из:

модели вариантов использования, содержащей все варианты использования и их связи с пользователями;

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

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

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

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

модели тестирования, описывающей тесты для проверки вариантов использования;

представления архитектуры.

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

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

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

Разделение цикла разработки на фазы разработки

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

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

УП включает следующие фазы:

• исследование (анализ и планирование требований)
• уточнение (проектирование)
• построение
• развертывание (внедрение)

Исследование

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

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

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

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

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

Уточнение (проектирование)

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

В течение фазы разработки следует решить следующие задачи:

— определить большую часть оставшихся функциональных требований;

— расширить примерную архитектуру до архитектурной основы, осуществить внутренний выпуск системы, рассчитанный на описанную архитектуру;

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

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

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

— модели вариантов использования,

— модели анализа,

— модели проектирования,

— модели реализации,

— модели развертывания.

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

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

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

Построение

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

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

Замечание.

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

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

 

Развертывание (внедрение)

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

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

Фаза развертывания (внедрения) включает в себя такие действия как:

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

 

Пять технологических процессов

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

№№	Технологический процесс	Наименование по Бучу
1	управление требованиями	требования
2	анализ	анализ
3	проектирование	разработка
4	реализация	реализация
5	тестирование	тестирование

 

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

 

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

 

Рис. Шесть основных моделей унифицированного процесса

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

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

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

Реализация. Целью этого технологического процесса является построение модели реализации, которая описывает, как элементы модели проектирования формируют такие компоненты как  файлы исходного кода и библиотеки динамической компоновки (DLL и Enterprise Java Beans).

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

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

 

Артефакты и исполнители.

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

— модели,

— прототипы пользовательского интерфейса,

— план проекта.

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

 

Назначение UML

Унифицированный язык моделирования UML ( Unified Modeling Languagе) был создан для того, чтобы участники процесса создания ПО могли строить модели для

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

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

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

Конструкции, создаваемые UML, имеют много общего с объектно-ориентированными языками программирования С++ или Java или языками программирования баз данных.

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

Язык UML явился логическим продолжением разработок способов объектно-ориентированного моделирования, моделирования объектов OMT, и написания кода. Язык UML был разработан тремя ведущими специалистами в области моделирования и разработки ПО Гради Бучем (Grady Booch), Джимом Румбахом (Jim Rumbaugh), Айваром Якобсоном (Ivar Jacobson) в компании Rational и ноябре 1997 г. стал стандартным языком объектно-ориентированного моделирования UML версии 1.0. Затем появились версии 1.2, 1.3, а сейчас, есть версия 2.0.