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

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

69

Содержание

• Введение 2
• Глава 1. Исследование предметной области 5
• 1.1 Центр проектирования контента белгородского филиала МЭСИ 5
• 1.2 Электронные образовательные ресурсы и их виды 7
• 1.3 Постановка задачи и определение основных требований к разрабатываемой системе 10
• 1.4 Анализ существующих разработок 12
• Глава 2. Проектирование системы учета работ по созданию электронных образовательных ресурсов 15
• 2.1 Выбор методологии 15
• 2.2 Выбор инструментального средства проектирования 23
• 2.3 Проектирование системной архитектуры 24
• 2.4 Структура базы данных 35
• Глава 3. Разработка автоматизированной системы учета работ по созданию электронных образовательных ресурсов 40
• 3.1 Выбор средств реализации системы 40
• 3.2 Разработка пользовательского интерфейса 44
• 3.3 Контрольный пример 50
• Глава 4. Оценка экономической эффективности проекта 56
• 4.1 Технико-экономическое обоснование разработки ПО 56
• 4.2 Расчет единовременных затрат на разработку ПО 57
• 4.3 Стоимость внедрения ПО Заказчиком 62
• 4.4 Расходы заказчика при эксплуатации ПО 65
• 4.5 Эффективность внедрения для Заказчика ПО 65
• Заключение 68
• Список литературы 70

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 1. Исследование предметной области

1.1 Центр проектирования контента белгородского филиала МЭСИ

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

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

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

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

В своей деятельности региональный центр проектирования контента руководствуется действующим законодательством, Уставом Московского государственного университета экономики, статистики и информатики, Положением о филиале МЭСИ и положением об отделе РЦПК.

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

Можно выделить основные функции Центра проектирования контента:

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

2. Участие в согласовании плана подготовки контента.

3. Контроль входящего контента на соответствие стандартам.

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

5. Разработка электронных учебных курсов по плану ЦПК МЭСИ.

6. Разработка электронных изданий на заказ.

7. Участие в организации электронного обучения в БФ МЭСИ.

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

1.2 Электронные образовательные ресурсы и их виды

Одним из главных элементов информационно-образовательной среды являются образовательные ресурсы.

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

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

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

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

1. Программно-методические электронные ресурсы (учебные планы, рабочие программы учебных дисциплин в соответствии с учебными планами);

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

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

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

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

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

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

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

§ Руководство по изучению дисциплины;

§ Теоретическая часть (учебное пособие);

§ Практикум;

§ Глоссарий;

§ Список рекомендуемой литературы;

§ Система контроля.

Можно выделить следующие этапы разработки такого курса:

1. Создание элементов (страниц) электронного курса (инженер- (техник- ) программист);

2. Сборка элементов в единый ресурс (инженер- (техник- ) программист);

3. Проверка на наличие орфографических и иных видов ошибок (начальник);

4. Исправление несоответствий, ошибок (инженер- (техник- ) программист);

5. Публикация готового ресурса в среде обучения (начальник).

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

1. Анализ и обработка материалов, предоставленных тьюторами;

2. Конвертация данных материалов в формат, поддерживаемый системой тестирования;

3. Подготовка теста к публикации, проверка;

4. Размещение в системе тестирования.

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

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

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

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

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

1.3 Постановка задачи и определение основных требований к разрабатываемой системе

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

1. Уменьшение времени поиска по базе готового контента в 2 раза;

2. Уменьшение времени на формирование отчетов на 15 минут;

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

Для достижения этих целей необходимо решить следующие задачи:

ь Ведение базы данных (отображения, редактирования и сохранения данных):

- всех видов контента,

- сотрудников отдела,

- работ, осуществляемых сотрудниками,

- отчетов.

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

Требования к разрабатываемой системе:

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

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

· ввод данных;

· редактирование данных;

· хранение данных;

· просмотр данных;

· поиск данных.

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

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

Требования к информационной и программной совместимости

Автоматизированная система должна обеспечивать информационную совместимость с известными приложениями операционной системы Windows (MS Word, MS Excel, MS Access). Программная совместимость обеспечивается автоматически в связи с использованием программных средств, совместимость которых обеспечена конструктивно (на этапе их создания) - Delphi, MS Access и т.д. Система реализуется под операционной системой Windows XP-Vista и СУБД InterBase.

Требования к техническому и аппаратному обеспечению

Разрабатываемая система ориентирована на использование персональным компьютером класса IBM PC, начиная с Pentium III, включенного в локальную сеть.

Необходимое аппаратное обеспечение:

- компьютер типа Pentium III или старше,

- минимум 64 Мб оперативной памяти.

Необходимый объем свободного пространства на жестком диске составляет 2 Мб. При работе с приложением в ходе модификации баз данных объем требуемого дискового пространства возрастает в зависимости от объема хранимых данных.

1.4 Анализ существующих разработок

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

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

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

Ресурс, заносимый в БЭРОН, может быть также позиционирован по виду и назначению.

БЭРОН реализуется в виде трех самостоятельных рабочих мест: пользователя, создателя, администратора. Пользовательское рабочее место обеспечивает возможности поиска требуемых ресурсов по классификатору, по атрибутам. Производит формирование выборок и сортировку данных внутри выборок.

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

Рассмотрим данный продукт с точки зрения решения поставленных задач:

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

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

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

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

Выводы по главе

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

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

Глава 2. Проектирование системы учета работ по созданию электронных образовательных ресурсов

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

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

ь ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла;

ь ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного программного обеспечения. Стандарт не содержит описания фаз, стадий этапов;

ь Rational Unified Process (RUP) от Rational Software предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей, а не бумажных документов, поэтому этот процесс привязан к использованию конкретных средств моделирования (Unified Modeling Language, UML), а так же конкретной технологии проектирования и разработки;

ь Microsoft Solution Framework (MSF) представляет общую методологию разработки и внедрения решений в сфере информационных технологий (Information Technologies, IT). Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Последняя версия модели дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения и включает пять фаз: анализ, проектирование, разработка, стабилизация и внедрение, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;

ь Application Lifecycle Management (ALM) от Borland направлена на ускорение и оптимизацию жизненного цикла приложений, а также интеграцию и совместное использование продуктов Borland. Данная стратегия, реализованная в наборе кросс-платформенных средств управления жизненным циклом приложений, призвана ускорить создание программных систем и обеспечить гарантированное получение нужного результата в рамках контролируемого и предсказуемого процесса разработки.

Методологии ГОСТ 34.601-90 и ISO/IEC 12207:1995 не поддерживают объектно-ориентрованный подход, поэтому использоваться не будут.

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

Таблица 2.1. Сравнительный анализ методологий проектирования

В соответствии с проведенным анализом, для проектирования ИС выбрана методология RUP (Rational Unified Process) - одна из технологий, претендующая на роль фактического стандарта.

Рис. 2.1. Жизненный цикл программного обеспечения по RUP

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

1. Бизнес-моделирование (Business modeling);

2. Управление требованиями (Requirements);

3. Анализ и Проектирование (Analysis and Design);

4. Реализация (Implementation);

5. Тестирование (Test);

6. Развертывание (Deployment).

И три вспомогательные:

1. Управление проектом (Project management);

2. Управление изменениями (Change management);

3. Среда (Environment).

Каждый цикл, в свою очередь, разбивается на 4 стадии:

1. начальная стадия (Inception),

2. стадия разработки (Elaboration),

3. стадия конструирования (Construction),

4. стадия ввода в действие - (Transition).

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

Основными принципами RUP являются:

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

2. Планирование и управление проектом на основе функциональных требований к системе - вариантов использования;

3. Построение системы на базе архитектуры программного обеспечения.

Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language™ (UML) -- универсальный язык моделирования.

Важнейшие аспекты RUP

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

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

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

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

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

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

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

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

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

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

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

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

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

Язык UML и его особенности

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

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

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

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

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

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

Таким образом, в UML выделяют девять типов диаграмм:

§ диаграммы классов;

§ диаграммы объектов;

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

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

§ диаграммы кооперации;

§ диаграммы состояний;

§ диаграммы действий;

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

§ диаграммы развертывания.

2.2 Выбор инструментального средства проектирования

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

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

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

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

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

Таблица 2.2. Сравнительный анализ средств проектирования

Страницы: 1, 2