- •Оглавление
- •Архитектура эвм
- •SharePoint 2010
- •Процессор
- •Этапы проектирования информационных систем в образовании
- •Периферийные устройства эвм, Внешние запоминающие устройства
- •Стохастическое моделирование
- •Организация прерываний в эвм
- •Функции, процедуры и службы управления учебным процессом
- •Информатика и информация.
- •1.Содержательный подход 2. Алфавитный подход
- •3. Вероятностный подход - Формула Шеннона:
- •Имитационное моделирование.
- •1. Модели систем массового обслуживания
- •2. Модели случайных событий
- •3. Клеточные автоматы
- •Обеспечение целостности и безопасности информации
- •Экспертные системы
- •Назначение и функции oc
- •Анализ компромиссов и рисков программного проекта
- •Организация памяти компьютера
- •Системный подход к исследованию систем
- •Система управления вводом-выводом
- •Критерии качества программ
- •Id и name
- •Idref и idrefs
- •Процессы жизненного цикла программных средств
- •Основы JavaScript
- •Основные структуры программирования
- •Управление проектированием информационных систем в образовании
- •EXtreme Programming или xp (экстремальное программирование)
- •Структурные типы данных в языках программирования
- •Массивы
- •Записи (структуры)
- •Множества
- •Агентное моделирование
- •Этапы развития технологии программирования
- •Методы представления знаний
- •Представление математических объектов в системах компьютерной алгебры
- •Uml как язык объектно-ориентированного проектирования
- •Модулярная арифметика
- •Состав и функции подсистем ису
- •Понятие информации формы её представления
- •Системный подход в моделировании
- •Энтропия
- •Процесс проектирования информационных систем в образовании
- •Количество информации
- •1.2.3. Различные подходы к измерению информации
- •Методы описания информационных систем
- •Кодирование
- •Сжатие данных
- •Помехоустойчивое кодирование
- •Управление проектированием информационных систем в образовании
- •Методики (методологии) управления ит-проектами (тяжеловесные, легковесные): особенности, примеры.
- •Алгоритм Евклида
- •Этапы развития технологии программирования
- •1 Этап: методологии программирования нет.
- •2 Этап: структурное программирование.
- •3 Этап: модульное программирование.
- •4 Этап: объектно-ориентированное программирование.
- •Основы web-дизайна
Uml как язык объектно-ориентированного проектирования
Возможности UML для проектирования информационных систем.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это— открытый стандарт,использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью.
UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), агрегация (aggregation) и поведение) и больше сконцентрироваться
на проектировании и архитектуре.
UML позволяет описывать систему следующими моделями:
Модель функционирования (показывает, как описывается функциональность системы с точки зрения пользователя).
Объектная модель (показывает, как выглядит проект системы с точки зрения объектного подхода).
Динамическая модель (показывает, как взаимодействуют друг с другом компоненты системы в динамике, с течением времени). Демонстрирует, какие процессы происходят в системе.
Взаимосвязь и рекомендуемая последовательность диаграмм языка.
Диаграммы UML предназначены для визуального отображения моделей и их компонентов.
UML 2.0 содержит 13 типов диаграмм. В том числе:
Структурные диаграммы (6).
Диаграммы поведения (3).
Диаграммы взаимодействия (4).
Структурные диаграммы: диаграммы классов, компонентов, коопераций.
Класс (class) - категория вещей, которые имеют общие атрибуты и операции.
Диаграмма классов - это набор статических, декларативных элементов модели.
Могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем.
Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части.
В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов.
Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области.
Третья часть содержит перечень операций, отражающих его поведение в модели предметной области
Зависимость возникает тогда, когда реализация класса одного объекта зависит от спецификации операций класса другого объекта
Ассоциация. Это просто связь между объектами, по которой можно между ними перемещаться. Ассоциация может иметь имя, показывающее природу отношений между объектами, при этом в имени может указываться направление чтения связи при помощи треугольного маркера. Однонаправленная ассоциация может изображаться стрелкой.
Кроме направления ассоциации, мы можем указать на диаграмме роли, которые каждый класс играет в данном отношении, и кратность, то есть количество объектов, связанных отношением
Ассоциация может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом на пересечении линий:
Связь типа "часть-целое - ассоциация с агрегированием. В этом случае один класс имеет более высокий статус (целое) и состоит из низших по статусу классов (частей). Выделяют простое и композитное агрегирование - агрегация и композиция.
Диагра мма компоне нтов, Component diagram — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграммы поведения: деятельности, состояний, прецедентов.
Диаграмма прецедентов (use case diagram)
Цели создания диаграмм прецедентов: определение границы и контекста моделируемой предметной области на ранних этапах проектирования; формирование общих требований к поведению проектируемой системы; разработка концептуальной модели системы для ее последующей детализации; подготовка документации для взаимодействия с заказчиками и пользователями системы.
Диаграммы взаимодействия: коммуникаций, последовательностей.
Между элементами диаграммы прецедентов могут существовать различные отношения, которые описывают взаимодействие экземпляров эктеров и вариантов использования. В языке UML существует несколько стандартных видов отношений между актерами и вариантами использования:
ассоциации (association relationship); • расширения (extend relationship);
общения (generalization relationship);
включения (include relationship).
Диаграммы последовательности
Диаграмма последовательностей показывает последовательность, в которой объекты в процессе взаимодействия обмениваются сообщениями.
Объект - это просто прямоугольник, внутри которого указаны подчеркнутые имя объекта и название класса (не обязательно), разделенные двоеточием.
Объекты располагаются в верхней части