Моделирование учебного процесса в рамках компетентностного подхода

Дипломная работа

Моделирование учебного процесса в рамках компетентностного подхода

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

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

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

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

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

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

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

Объект: процесс моделирования учебного процесса в колледже.

Предмет: компетентностный подход в рамках формирования учебного плана.

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

Задачи:

• 1. Рассмотреть основные понятия унифицированный язык моделирования UML.
• 2. Охарактеризовать использование диаграмм в UML для моделирования учебного процесса.
• 3. Дать понятие моделированию «компетентностностного подхода».
• 4. Составить диаграмму классов, описывающих учебный процесс.
• 5. Уточнить выбор средства проектирования информационной системы.
• 6. Проанализировать концептуальное проектирование объектной модели
• 7. Описать процесс реализации информационной системы «Организация учебного процесса в колледже».
• 8. Обосновать результат работы информационной системы «Организация учебного процесса в колледже» для составления учебного плана.
• 1. Унифицированный язык моделирования UML

1.1 История UML

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

С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее, многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой «войны методов». В результате этих войн появилось новое поколение методов, среди которых особое значение приобрели языки Booch, созданный Грейди Бучем (Grady Booch), OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном (Ivar Jacobson) и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо (James Rumbaugh). Кроме того, следует упомянуть языки Fusion, Шлаера-Меллора (Shlaer-Mellor) и Коада-Йордона (Coad-Yourdon). Каждый из этих методов можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны. [7]

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

Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ, партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями.

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

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

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

Начав унификацию, авторы поставили перед собой три главные цели:

— моделировать системы целиком, от концепции до исполняемого артефакта, с помощью объектно-ориентированных методов;

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

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

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

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

Главными в разработке UML были следующие цели:

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

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

— обеспечить независимость от конкретных языков программирования и процессов разработки;

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

— стимулировать рост рынка объектно-ориентированных инструментальных средств;

— интегрировать лучший практический опыт.

Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.

Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами OMG (Object Management Group) на конкурс по созданию стандартного языка моделирования.

Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML 1.1 была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG.

Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 — UML 1.3.

Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) — организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО.

Язык UML принят на вооружение практически всеми крупнейшими компаниями — производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.).

1.2 Сущность унифицированного языка моделирования UML

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

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

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

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

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

Использование UML позволяет решить третью проблему: явная модель облегчает общение.

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

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

UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования. [4]

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

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

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

— информационные системы масштаба предприятия;

— банковские и финансовые услуги;

— телекоммуникации;

— транспорт;

— оборонная промышленность, авиация и космонавтика;

— розничная торговля;

— медицинская электроника;

— наука;

— распределенные Web-системы.

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

1.3 Концептуальная модель UML

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

Словарь языка UML включает три вида строительных блоков:

— сущности;

— отношения;

— диаграммы.

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

В UML имеется четыре типа сущностей:

— структурные;

— поведенческие;

— группирующие;

— аннотационные.

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

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

Класс (Class).

Интерфейс (Interface).

Кооперация (Collaboration).

Прецедент (Use case).

Активным классом (Active class).

Компонент (Component).

Узел (Node).

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

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

Рисунок 2 — Интерфейсы Кооперация (Collaboration) определяет взаимодействие. Она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Кооперация, следовательно, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения, формирующих систему. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только имя, как показано на рисунке 3.

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

Рисунок 4 — Прецеденты Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией и обычно включает имя, атрибуты и операции, как показано на рисунке 5.

Рисунок 5 — Активные классы

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

Компонент (Component) — это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рисунке 6.

Рисунок 6 — Компоненты Узел (Node) — это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя, как показано на рисунке 7.

Рисунок 7 — Узлы

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

— актеры,

— сигналы,

— утилиты (виды классов),

— процессы и нити (виды активных классов),

— приложения,

— документы,

— файлы,

— библиотеки,

— страницы и таблицы (виды компонентов).

Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей:

— взаимодействие (Interaction);

— автомат (State machine).

Взаимодействие (Interaction) — это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции, как показано на рисунке 8.

Рисунок 8 — Сообщения Автомат (State machine) — это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение сдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход). Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, под состояния (рисунок 9).

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

Рисунок 9 — Состояния Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет.

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

Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда — содержимое (рисунок 10).

Рисунок 10 — Пакеты Пакеты — это основные группирующие сущности, с помощью которых можно организовать модель UML. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.

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

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

В языке UML определены четыре типа отношений:

— зависимость;

— ассоциация;

— обобщение;

— реализация.

Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.

Зависимость (Dependency) — это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку (см. рисунок 12).

Рисунок 12 — Зависимости Ассоциация (Association) — структурное отношение, описывающее совокупность связей. Связь — это соединение между объектами. Разновидностью ассоциации является агрегирование (Aggregation) — так называют структурное отношение между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, на пример кратность и имена ролей. На рисунке 13 показан пример отношений этого типа.

Рисунок 13 — Ассоциации Обобщение (Generalization) — это отношение «специализация / обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка).

Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent). Графически отношение обобщения изображается в виде линии с не закрашенной стрелкой, указывающей на родителя, как показано на рисунке 14.

Рисунок 14 — Обобщения Наконец, реализация (Realization) — это семантическое отношение между классификаторами, при котором один классификатор определяет «контракт», а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с не закрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости (см. рисунок 15).

Рисунок 15 — Реализации

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

1.4 Правила языка UML

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

В языке UML имеются семантические правила, позволяющие корректно и однозначно определять.

1. Имена, которые можно давать сущностям, отношениям и диаграммам.

2. Область действия (контекст, в котором имя имеет некоторое значение).

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

4. Целостность (как элементы должны правильно и согласованно соотноситься друг с другом).

5. Выполнение (что значит выполнить или имитировать некоторую динамическую модель).

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

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

— неполные (отдельные элементы пропущены).

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

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

1.5 Общие механизмы языка UML

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

— спецификации (Specifications);

— дополнения (Adornments);

— принятые деления (Common Pisions);

— механизмы расширения (Extensibility mechanisms).

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

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

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

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

Рисунок 16 — Дополнения Каждый элемент нотации UML содержит базовый для него символ, к которому можно добавлять разнообразные специфичные для него дополнения.

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

Прежде всего, существует разделение на классы и объекты. Класс — это абстракция, объект — конкретная материализация этой абстракции. В языке UML можно моделировать и классы, и объекты, как показано на рисунке 17. На этом рисунке показан один класс Customer (Клиент) и три объекта: Jan (явно определенный как объект данного класса), Customer (анонимный объект класса Customer) и Elyse (спецификация которого относит его к классу Customer, хотя это и не выражено явно).

Рисунок 17 — Классы и объекты Практически все строительные блоки UML характеризуются дихотомией «класс / объект». Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т. д. В графическом представлении для объекта принято использовать тот же символ, что и для его класса, а название объекта подчеркивать.

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

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

— стереотипы;

— помеченные значения;

— ограничения.

Стереотип (Stereotype) расширяет словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы. Например, работая с такими языками программирования, как Java или C++, часто приходится моделировать исключения (Exceptions) — они являются обыкновенными классами, хотя и рассматриваются особым образом. Обычно требуется, чтобы исключения можно было возбуждать и перехватывать, и ничего больше. Если пометить исключения соответствующим стереотипом, то с ними можно будет обращаться как с обычными строительными блоками языка. На рисунке 19 это продемонстрировано на примере класса Overflow.

Рисунок 19 — Механизмы расширения Помеченное значение (Tagged value) расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Скажем, если вы работаете над «коробочным» продуктом и выпускаете много его версий, то зачастую необходимо отслеживать версию и автора какой-нибудь важной абстракции. Ни версия, ни автор не являются первичными концепциями UML, но их можно добавить к любому блоку, такому, например, как класс, задавая для него новые помеченные значения. На рисунке 19 показано, как это можно сделать, на примере класса Event Queue.

Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс Event Queue так, чтобы все события добавлялись в очередь по порядку. На рисунке 19 показано, как можно определить ограничение, которое явно постулирует это правило для операции add.

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

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

2. Моделирование процесса обучения в колледже

2.1 Использование диаграмм в UML для моделирования учебного процесса

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

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

2. Диаграммы объектов.

3. Диаграммы прецедентов.

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

5. Диаграммы кооперации.

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

7. Диаграммы действий.

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

9. Диаграммы развертывания.

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

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

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

Диаграммы последовательностей и кооперации являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации — структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга. [6]

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

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

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

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

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

2.2 Моделирование понятия «компетентность»

На рисунке 20 представлена метамодель понятия «компетентность».

Статическая структура Competence представляет компетентность специалиста и ее составляющие в виде пакетов, с каждым из которых в свою очередь связываются статические структуры. Статическая структура на рисунке 3 легко может быть восстановлена в виде UML-модели с помощью, например, Microsoft Office Visio (при создании файла — пункт контекстного меню Software/UML Model Diagram).

Рисунок 20 — Метамодель понятия «компетентность»

Понятие компетентность представляется в модели пакетом с именем Competence, отнесенным к стереотипу «system». Содержание самого понятия отображается во вкладке Tagged Values (помеченные значения) c трех позиций.

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

2. С точки зрения результата образования (Outcome of education) смысл понятия компетентность (Tag OutcomeEducation Value) определяется как «реализованная образованность».

3. С точки зрения умения (Skill) смысл понятия компетентность (Tag Skill Value) определяется как «проявленные специалистом на практике стремление и способность (готовность) реализовать свой потенциал…».

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

1. Пакет «Готовность к реализации» (Readiness for realization). Tagged Values — Стремление и способность (готовность) реализовать свой потенциал.

2. Пакет «Практическая способность к реализации» (Practical capacity to realization). Tagged Values — Проявленная на практике способность реализовать свои знания, умения, опыт для успешной творческой деятельности.

3. Пакет «Стремление к совершенствованию» (Tendency to perfecting). Tagged Values — Осознание социальной значимости и личной ответственности за результаты своей деятельности, необходимость ее постоянного совершенствования.

4. Пакет «Результат образования» (Outcome of education). Tagged Values — Это сам человек, прошедший обучение в определенной образовательной системе. Это его опыт как совокупность сформированных интеллектуальных, личностных, поведенческих качеств, знаний и умений позволяет ему адекватно действовать на основе этих знаний в любой ситуации.

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

Диаграмма компетенций как диаграмма компонентов представлена на рисунке 21.

Рисунок 21 — Использование сущности «компонент» для моделирования понятия «компетенция»

Компетенции ФГОС СПО, как требования к результату обучения в колледже, играют ключевую роль в модели, замыкая на себя учебные дисциплины и профессиональные модули, которыми они формируются. В информационной модели (рисунок 21) каждая компетенция представляется в виде компонента на диаграмме компонентов, при этом внутреннее содержание и структура компетенции раскрываются с помощью атрибутов и операций соответствующего компонента (рисунок 22), а её связь с нотациями учебных дисциплин отображается с помощью узлов («Nodes»). С помощью UML-нотации «Компонент», можно поместить составляющие компетенции ПК-01 в атрибуты компонента, представляющего данную компетенцию, при этом возможность задания свойств («Properties») атрибута позволит нам дальнейшую детализацию каждой способности.

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

Рисунок 23 — Внутренняя структура учебной дисциплины, представленная с помощью диаграммы пакетов

2.3 Диаграмма классов, описывающих учебный процесс

На рисунке 20 представлена диаграмма классов, отражающая структуру учебного процесса в колледже.

Рассмотрим функционирование предметной области «Организация учебного процесса в колледже».

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

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

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

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

3. Проектирование объектной модели предметной области «Организация учебного процесса в колледже» с применением редактора баз данных Microsoft Access

3.1 Выбор средств — методология проектирования

В создании информационной системы используются разные системы управления базами данных. Однако, Microsoft Access является одним из самых популярных приложений в семействе настольных система управления базами данных (СУБД). Все версии Access имеют в своем арсенале средства, значительно упрощающие ввод и обработку данных, поиск данных и предоставление информации в виде таблиц, графиков и отчетов. В состав Microsoft Access входят конструкторы таблиц, форм, запросов и отчётов. Используя макросы или модули для автоматизации решения задач, можно создавать ориентированные на пользователя приложения такими же мощными, как и приложения, написанные непосредственно на языках программирования. Помимо этого, Access позволяет использовать электронные таблицы и таблицы из других настольных и серверных баз данных для хранения информации, необходимой приложению. Присоединив внешние таблицы, пользователь Access будет работать с базами данных в этих таблицах так, как если бы это были таблицы Access. При этом и другие пользователи могут продолжать работать с этими данными в той среде, в которой они были созданы. [9]