- •Проектирование информационных систем
- •Содержание
- •Лекция 1. Руководство программным проектом
- •Организация процесса конструирования
- •Модели конструирования по:
- •Модели качества процессов конструирования
- •Процесс руководства процессом (срс)
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Планирование проектных задач
- •Лекция 2. Унифицированный язык визуального программирования uml
- •Понятия uml
- •Предметы поведения
- •Группирующие предметы
- •Поясняющие предметы
- •Отношения uml
- •Диаграммы uml
- •Механизмы расширения uml(срс)
- •Объекты
- •Физическое включение Нефизическое включение
- •Отношения в диаграммах классов
- •Деревья наследования
- •Лекция 5. Динамические модели объектно-ориентированных программных систем
- •Автоматы
- •Диаграмма схем состояний системы охранной сигнализации
- •Действия в состояниях
- •Входные и выходные действия и деятельность в состоянии Активна
- •Диаграмма деятельности покупателя в Интернет-магазине
- •Диаграммы взаимодействия
- •1. Диаграммы сотрудничества
- •Д иаграммы сотрудничества
- •2. Диаграммы последовательности.
- •Диаграммы Use Case
- •Актеры и элементы Use Case
- •Отношения в диаграммах Use Case
- •Лекция 6. Модели реализации объектно-ориентированных программных систем
- •1) Компонентные диаграммы
- •2) Диаграммы размещения (развертывания)
- •Лекция 7. Типовое проектирование ис
- •Понятие типового проектирования ис
- •Классификация типовых ис
- •Методы конфигурирования типовой ис
- •Лекция 9. Разработка алгоритмов ис
- •Понятие алгоритма
- •Правила и этапы построения алгоритмов
- •Виды и структуры алгоритмов
- •Элементы алгоритмов
- •Методы проектирования алгоритмов
- •Степень автоматизации проектных работ:
- •Принятая методология процесса разработки:
Диаграммы uml
Диаграммы классов – показывает набор классов, интерфейсов, коопераций и отношений между ними. Используется чаще всего и она обеспечивает статическое проектное представление системы.
Диаграммы объектов – показывает набор объектов и отношений между ними. Представляет статический «моментальный снимок» с экземпляров предметов, которые находятся в диаграммах классов. Данная диаграмма также обеспечивает статическое проектное представление системы.
Диаграммы Use Case (диаграммы прецедентов) – показывает набор элементов Use Case, актеров и отношений между ними. С помощью этой диаграммы для системы создается статическое представление Use Case. Она особенно важна при организации и моделировании поведения системы, задании требований заказчика к системе.
Диаграммы взаимодействия – показывают взаимодействия, включающие набор объектов и их отношений, а также пересылаемые между объектами сообщения. Они обеспечивают динамическое представление системы.
Диаграммы последовательности – это диаграммы взаимодействия, которые выделяют упорядочивание сообщений по времени.
Диаграммы сотрудничества (коопераций) – это диаграммы взаимодействия, которые выделяют структурную организацию объектов, посылающих и принимающих сообщения. Диаграммы последовательности и сотрудничества изоморфны, т.е. одну диаграмму можно трансформировать в другую.
Диаграммы схем состояний – показывают конечный автомат, представляет состояние, переходы, события и действия. Она обеспечивает динамическое представление системы.
Диаграммы деятельности – это специальная разновидность диаграммы схем состояний, которая показывает поток от действия к действию внутри системы. Она также обеспечивает динамическое представление системы.
Компонентные диаграммы – показывают организацию набора компонентов и зависимости между компонентами. Она обеспечивает статическое представление реализации системы.
Диаграммы размещения (развертывания) – показывает конфигурацию обрабатывающих узлов в периоды выполнения, а также компоненты, живущие в них. Она обеспечивает статическое представление размещения системы.
Взаимосвязи между диаграммами UML:
Механизмы расширения uml(срс)
UML — развитый язык, имеющий большие возможности, но даже он не может отразить все нюансы, которые могут возникнуть при создании различных моделей. Поэтому UML создавался как открытый язык, допускающий контролируемые расширения. Механизмами расширения в UML являются:
ограничения;
теговые величины;
стереотипы.
Ограничение (constraint) расширяет семантику строительного UML-блока, позволяя добавить новые правила или модифицировать существующие. Ограничение показывают как текстовую строку, заключенную в фигурные скобки {}. Например, на рис. введено простое ограничение на свойство сумма класса Сессия Банкомата — его значение должно быть кратно 20. Кроме того, здесь показано ограничение на два элемента (две ассоциации), оно располагается возле пунктирной линии, соединяющей элементы, и имеет следующий смысл — владельцем конкретного счета не может быть и организация, и персона.
Теговая величина (tagged value) расширяет характеристики строительного UML-блока, позволяя создать новую информацию в спецификации конкретного элемента. Теговую величину показывают как строку в фигурных скобках {}. Строка имеет вид
и
мя
теговой величины = значение
Иногда (в случае предопределенных тегов) указывается только имя теговой величины.
Отметим, что при работе с продуктом, имеющим много реализаций, полезно отслеживать версию и автора определенных блоков. Версия и автор не принадлежат к основным понятиям UML. Они могут быть добавлены к любому строительному блоку (например, к классу) введением в блок новых теговых величин. Например, на рис., класс Текстовый Процессор расширен путем явного указания его версии и автора.
Расширение класса
Стереотип (stereotype) расширяет словарь языка, позволяет создавать новые виды строительных блоков, производные от существующих и учитывающие специфику новой проблемы. Элемент со стереотипом является вариацией существующего элемента, имеющей такую же форму, но отличающуюся по сути. У него могут быть дополнительные ограничения и теговые величины, а также другое визуальное представление. Он иначе обрабатывается при генерации программного кода. Отображают стереотип как имя, указываемое в двойных угловых скобках (или в угловых кавычках).
Примеры элементов со стереотипами приведены на рис. Стереотип «exception» говорит о том, что класс ПотеряЗначимости теперь рассматривается как специальный класс, которому, положим, разрешается только генерация и обработка сигналов исключений. Особые возможности метакласса получил класс ЭлементМодели. Кроме того, здесь показано применение стереотипа «call» к отношению зависимости (у него появился новый смысл).
Таким образом, механизмы расширения позволяют адаптировать UML под нужды конкретных проектов и под новые программные технологии. Возможно добавление новых строительных блоков, модификация спецификаций существующих блоков и даже изменение их семантики. Конечно, очень важно обеспечить контролируемое введение расширений.
Лекция 3. ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРЕДСТАВЛЕНИЯ ПРОГРАММНЫХ СИСТЕМ (ООППС)
Принципы ООППС
Объекты
Классы
П
РИНЦИПЫ
ООППС
Д
ЕКОМПОЗИЦИЯ
ПРОГРАММНЫХ СИСТЕМ
алгоритмическая
объектно-ориентированная
Программная система – это сложная система, которая требует применения декомпозиции.
ООПС основывается на ряде принципов:
Принцип абстрагирования – сводится к формированию абстракций – основных характеристик объекта, которые отличают его от других видов объектов. Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации. Абстракцию удобно строить путем выделения обязанностей объекта.
Инкапсуляция: абстрагирование и инкапсуляция – взаимодополняющие понятия: абстракция выделяет внешнее поведение объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение. Инкапсуляция достигается за счет информационной закрытости. Обычно скрываются структура объектов и реализация их методов. Инкапсуляция служит для отделения интерфейса абстракции от ее реализации.
Модульность – это свойство системы, которое может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.
Свойства модулей:
Информационная закрытость – содержание модулей должно быть скрыто друг от друга, все модули должны быть независимыми и обмениваться только той информацией, которая нужна им для работы. Доступ к операциям и структурам данных модуля ограничен. Идеальный модуль это черный ящик.
Связность модуля – это мера зависимости его частей, внутренняя характеристика модуля. Чем выше связность, тем лучше результат проектирования. Для измерения связности использую понятие силы связности. Существует 7 типов связностей:
1
Связность по совпадению (СС=0)
В модуле отсутствуют явно выраженные внутренние связи. Элементы связного по совпадению модуля вообще не имеют никаких отношений друг с другом.
2
Логическая связность (СС=1)
Части модуля объединены по принципу функционального подобия. Элементы логически связного модуля принадлежат к действиям одной категории, и из этой категории клиент выбирает выполняемое действие.
3
Временная связность (СС=3)
Части модуля не связаны, но необходимы в один и тот же период работы системы. При связности по времени элементы-обработчики модуля привязаны к конкретному периоду времени (из жизни программной системы).
4
Процедурная связность (СС=5)
Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения. Процедурно связный модуль состоит из элементов, реализующих независимые действия, для которых задан порядок работы, то есть порядок передачи управления.
5
Коммуникативная связность (СС=7)
Части модуля связаны по данным (работают с одной и той же структурой данных). При коммуникативной связности элементы-обработчики модуля используют одни и те же данные, например внешние данные.
6
Информационная (последовательная) связность (СС=9)
Выходные данные одной части используются как входные данные в другой части модуля. При информационной (последовательной) связности элементы-обработчики модуля образуют конвейер для обработки данных – результаты одного обработчика используются как исходные данные для следующего обработчика.
7
Функциональная связность (СС=10)
Части модуля вместе реализуют одну функцию. Функционально связный модуль содержит элементы, участвующие в выполнении одной и только одной проблемной задачи.
Сцепление модулей – это мера взаимозависимости модулей по данным, внешняя характеристика модуля, которую необходимо уменьшить. Сцепление измеряется степенью сцепления и существует 6 их типов:
1
Сцепление по данным (СЦ=1)
М
одуль
А вызывает модуль В. Все входные и
выходные параметры вызываемого модуля
– простые элементы данных.2
Сцепление по образцу (СЦ=3)
В
качестве параметров используются
структуры данных.3
Сцепление по управлению (СЦ=4)
М
одуль
А явно управляет функционированием
модуля В (с помощью флагов или
переключателей), посылая ему управляющие
данные.4
Сцепление по внешним ссылкам (СЦ=5)
Модули А и В ссылаются на один и тот же глобальный элемент данных.
5
Сцепление по общей области (СЦ=7)
Модули разделяют одну и ту же глобальную структуру данных.
6
Сцепление по содержанию (СЦ=9)
О
дин
модуль прямо ссылается на содержание
другого модуля (не через его точку
входа). Например, коды их команд
перемежаются друг с другом.Иерархическая организация – это формирование из абстракций иерархической структуры. Иерархическая организация задает размещения абстракций на различных уровнях описания системы. Выделяют 2 разновидности иерархической организации: структура из классов и структура из объектов.
Иерархическая структура программной системы – это основной результат предварительного проектирования. Она определяет состав модулей ПС и управляющие отношения между модулями.
В этой структуре модуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным).
П
ервичные
характеристики – количество
вершин
(модулей) и количество
ребер
(связей между модулями).
Глобальные характеристики – высота и ширина.
Локальными характеристиками модулей структуры являются коэффициент объединения по входу Fan_in(i) и коэффициент разветвления по выходу Fan_out(i).
