Информационное обеспечение - Разработка электронного пособия
Функциональная модель
Для описания процессов подлежащих учету в автоматизированных системах используют функциональное моделирование. Функциональную модель строится исходя из точки зрения исполнителя. Цель моделирования - выявить связи между этапами построения АИС. На рисунке № 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 Диаграмма вариантов использования (роль - студент)
Похожие статьи
-
Важную роль в проектировании информационных систем играют CASE-средства (Computer-Aided Software/System Engineering). Под термином "CASE-средства"...
-
Понятие Data Mining Средства Data Mining включают в себя очень широкий класс различных технологий и инструментов. Средства Data Mining на рынке...
-
Введение - Разработка электронного пособия
Современный период развития цивилизованного общества характеризует процесс информатизации. Информатизация общества -- это глобальный социальный процесс,...
-
В среде электронного ресурса ИИС "MD_SLAGMELT" (Рис. 6) для доступа к компоненту "моделирование" необходима учетная запись (пара логин/пароль) (Рис.7)....
-
Обеспечение совместимости программного обеспечения в корпоративных системах В некоторых технических областях существуют жесткие требования к...
-
Основанием для разработки электронного пособия по дисциплине "Компьютерные сети" является наличие электронных пособий по данной дисциплине с рядом...
-
Выбор средств реализации информационной системы Названные в параграфе 1.4. настоящей работы задачи могут быть решены тремя типами средств автоматизации:...
-
Инфологическое проектирование Стандартным способом представления концептуальной модели базы данных являются диаграммы "сущность-связь" (ERD),...
-
Основной трудностью при создании интегрированных АИС является длительность разработки -- большая протяженность этапов проектирования зачастую приводит к...
-
Правовое аспекты - Организационно-правовое обеспечение информационной безопасности
В развитых странах мира, в том числе и в Российской Федерации, электронная цифровая подпись широко используется в гражданском обороте. Различные банки...
-
Внедрение системы workflow. - Информационное обеспечение менеджерской деятельности
В качестве наиболее органичного и эффективного способа внедрения ИСУП можно предложить использование системы автоматизации деловых процессов (workflow) в...
-
Введение - Методика моделирования основных процессов разработки программного обеспечения
В последнее время во многих предприятиях происходит внедрение новых моделей управления и различных информационных систем, обеспечивающих увеличение...
-
Хорошо продуманный интерфейс, подобно хорошему учителю и учебникам, обеспечивает плодотворное взаимодействие пользователя и компьютера. Удачные...
-
На данный момент существует множество аналогов данного приложения, можно выделить такие как стандартный проводник Windows и Total Commander. Заказчику...
-
Разработка политики безопасности организации - Основные понятия политики информационной безопасности
Разработка политики безопасности ведется для конкретных условий функционирования информационной системы. Как правило, речь идет о политике безопасности...
-
В работе использовались следующее программное обеспечение для решения поставленных задач: AutoCAD, ANSYS Workbench, ANSYS Icepak. Система AutoCAD...
-
Оценка стоимости разработки программного обеспечения, или, в частности информационной системы, - один из самых важных, сложных и в то же время неизбежных...
-
Экономическое обоснование необходимости разработки информационной системы "Учет посещаемости в детском саду" В современных условиях хозяйствования...
-
Среда объектно-ориентированного программирования Delphi Delphi - это комбинация нескольких важнейших технологий, высокопроизводительный компилятор в...
-
Структура программно-математического обеспечения АСУ, его функции и принципы разработки Программные средства обеспечивают обработку данных и состоят из...
-
Информация с точки зрения информационной безопасности обладает следующими категориями: * конфиденциальность -- гарантия того, что конкретная информация...
-
Дальнейшим развитием локальных средств разработки программ, являются интегрированные программные среды разработчиков. Основное назначение инструментария...
-
Цель Работы - изучить приемы создания и использования шаблонов классов. - Теоретические сведения Достаточно часто встречаются классы, объекты которых...
-
Математическое и программное обеспечение (МО, ПО)- совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач...
-
Информационное обеспечение - совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем информационных...
-
Цель Работы - изучить основные способы работы с пользовательским типом данных "класс", его объектами, методами и способы доступа к ним. - Теоретические...
-
Введение - Технология разработки программного обеспечения систем управления
С++ является языком объектно-ориентированного программирования (ООП). Объект - абстрактная сущность, наделенная характеристиками объектов реального мира....
-
Проектирование модели - Разработка программного приложения "Калькулятор коммунальных услуг"
При проектировании информационных систем предметная область отображается моделями данных нескольких уровней. Число используемых уровней зависит от...
-
Техническое задание - Разработка информационно-справочной системы "Аптека"
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки...
-
Общее описание программного обеспечения, реализующего разработанный алгоритм Основной идеей дипломного проекта, является реализация алгоритма...
-
Введение - Разработка информационно-справочной системы "Аптека"
Для большинства средних и мелких российских предприятий информационные системы с использованием сетей персональных компьютеров являются фактическим...
-
Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из...
-
Последовательность действий при принятии решения о внедрении корпоративной информационной системы С чего начать разработку решения? Любая промышленная...
-
В данной главе проводится анализ деятельности кафедры информационных технологий в бизнесе. Анализ показывает, насколько важен процесс поиска для...
-
Моделирование предметной области Этапом проектирования базы данных любого типа начинается с анализа предметной области, который заканчивается построением...
-
Разработка концептуальной модели АИС - Проектирование автоматизированной информационной системы
Любая деятельность компании отражается в документах, и, чтобы улучшить качество рабочих бизнес-процессов, необходимо улучшить документооборот, т. е....
-
Определение методов реинжиниринга информационных систем Основные задачи, которые стоят перед проектировщиком, занимающимся реинжинирингом информационных...
-
Borland Delphi 7 - Разработка справочной информационной системы "Рецепты"
Интерфейс программы был написан в среде Borland Delphi 7 - визуальной среде программирования, использующей объектно-ориентированную модификацию языка...
-
IDS сетевого уровня имеют много достоинств, которые отсутствуют в системах обнаружения атак на системном уровне. В действительности, многие покупатели...
-
При генерации шаблона Rails-движка в папке test, помимо каталогов для различных тестов, создается изолированное тестовое Rails-приложение для быстрой...
Информационное обеспечение - Разработка электронного пособия