Информационное обеспечение - Разработка электронного пособия

Функциональная модель

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

функциональная модель системы

Рисунок 1 Функциональная модель системы

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

Диаграммы построения информационной системы

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

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

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

В UML используются следующие виды диаграмм:

1. Структурные диаграммы:

A. Классов ;

B. Компонентов ;

C. Кооперации;

D. Развертывания ;

E. Объектов;

F. Пакетов;

2. Диаграммы поведения:

A. Деятельности ;

B. Конечных автоматов (состояний);

C. Прецедентов;

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

A. Коммуникации/Кооперации;

B. Обзора взаимодействия;

C. Последовательности;

D. Синхронизации.

Диаграмма классов

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

графическое изображение класса на диаграмме классов

Рисунок 3 Графическое изображение класса на диаграмме классов

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

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

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

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

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

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

    1. [кратность]: 2. = {строка-свойство}

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

    1. Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма. 2. Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса. 3. И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

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

Рекомендации по построению диаграмм классов

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

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

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

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

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

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

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

диаграмма классов

Рисунок 4 Диаграмма классов

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

Диаграмма последовательности (англ. sequence diagram) -- диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.

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

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

диаграмма сотрудничества

Рисунок 6 Диаграмма сотрудничества

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

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

Если пользователь будет выступать в роли преподавателя ему будут предоставлены следующие возможности:

    1. Входить в программу; 2. Проверять тесты; 3. Редактировать теорию; 4. Редактировать тесты; 5. Выходить из программы.
диаграмма вариантов использования (роль - преподаватель)

Рисунок 7 Диаграмма вариантов использования (роль - преподаватель)

Если пользователь будет выступать в лице студента то ему будут предоставлены следующие возможности:

    1. Входить в программу; 2. Изучать теорию; 3. Выполнять практические работы; 4. Выполнять тестовые задания; 5. Отвечать на контрольные вопросы; 6. Просматривать глоссарий; 7. Просматривать видеоролики; 8. Выходить из программы.
диаграмма вариантов использования (роль - студент)

Рисунок 8 Диаграмма вариантов использования (роль - студент)

Похожие статьи




Информационное обеспечение - Разработка электронного пособия

Предыдущая | Следующая