Статические модели объектно-ориентированных программных систем

Статические модели объектно-ориентированных программных систем

Статические модели обеспечивают представление структуры систем в терминах базовых строительных блоков и отношений между ними. «Статичность» этих моделей состоит в том, что здесь не показывается динамика изменений системы во времени. Вместе с тем следует понимать, что эти модели несут в себе не только структурные описания, но и описания операций, реализующих заданное поведение системы. Основным средством для представления статических моделей являются диаграммы классов [8], [23], [53], [67]. Вершины диаграмм классов нагружены классами, а дуги (ребра) — отношениями между ними. Диаграммы используются:

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

q в ходе проектирования — для фиксации структуры классов, которые формируют системную архитектуру.

(содержит атрибуты, методы и взаимосвязи)

Свойства, операции, отношения классов и их отображение на диаграмме классов

Основным средством для представления статических моделей являются диаграммы классов [8], [23], [53], [67]. Вершины диаграмм классов нагружены классами, а дуги (ребра) — отношениями между ними. Диаграммы используются:

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

q в ходе проектирования — для фиксации структуры классов, которые формируют системную архитектуру.

(содержит атрибуты, методы и взаимосвязи)

Вершины в диаграммах классов

Итак, вершина в диаграмме классов — класс. Обозначение класса на рис. 11.1.

Рис. 11.1. Обозначение класса

Имя класса указывается всегда, свойства и операции — выборочно. Предусмотрено задание области действия свойства (операции). Если свойство (операция) подчеркивается, его областью действия является класс, в противном случае областью Действия является экземпляр (рис. 11.2).

Свойства

Общий синтаксис представления свойства имеет вид

Видимость Имя [Множественность]: Тип = НачальнЗначение {Характеристики}

Рассмотрим видимость и характеристики свойств.

В языке UML определены три уровня видимости:

public protected private

Видимый для всех, обозначается символом + Защищенный, обозначается символом # Только для объектов класса, обозначается символом -

Если видимость не указана, считают, что свойство объявлено с публичной видимостью (public).

Определены три характеристики свойств:

changeable addOnly frozen

Неизменяемый Только добавление Не изменнное значение

Если характеристика не указана, считают, что свойство объявлено с характеристикой changeable.

Примеры объявления свойств:

начало + начало начало: Координаты имяфамилия [0..1]: String левыйУгол: Координаты=(0, 10) сумма: Integer {frozen}

Только имя Видимость и имя Имя и тип Имя, множественность, тип Имя, тип, начальное значение Имя и характеристика

Операции

Общий синтаксис представления операции имеет вид

Видимость Имя (Список Параметров): ВозвращаемыйТип {Характеристики}

Примеры объявления операций:

записать + записать зарегистрировать) и: Имя, ф: Фамилия) балансСчета (): Integer нагревать () (guarded)

Только имя Видимость и имя Имя и параметры Имя и возвращаемый тип Имя и характеристика

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

Направление Имя: Тип = ЗначениеПоУмолчанию

Элемент Направление может принимать одно из следующих значений:

in out   inout

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

Допустимо применение следующих характеристик операций:

leaf   isQuery guarded concurrent

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

Множественность

Иногда бывает необходимо ограничить количество экземпляров класса: (ноль экземпляров, один экземпляр, конкретное количество экземпляров, не ограничивать количество экземпляров).

Выражение множественности записывается в правом верхнем углу значка класса.

Рис. 11.4. Множественность

Множественность применима не только к классам, но и к свойствам. Множественность свойства задается выражением в квадратных скобках, записанным после его имени.

Диаграммы схем состояний

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

Диаграмма схем состояний показывает: 1) набор состояний системы;

2) события, которые вызывают переход из одного состояния в другое;

3) действия, которые происходят в результате изменения состояния.

Используется в системах реального времени.

Диаграммы деятельности

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

Условные переходы

Между состояниями возможны различные типы переходов. Обычно переход инициируется событием. Допускаются переходы и без событий.

Порядок выполнения условного перехода:

1) происходит событие;

2) вычисляется условие УсловиеПерехода;

3) при УсловиеПерехода=true запускается переход и активизируется действие, в противном случае переход не выполняется.

Пример условного перехода между состояниями

Вложенные состояния

Это подсостояния.Цель: упростить моделирование сложного поведения. Подсостояние — это состояние, вложенное в другое состояние.

Рис. 12.10. Переходы в состоянии Активна

На рис. 12.10 приведена внутренняя структура составного состояния Активна.

Если система находится в состоянии Активна, то она должна быть точно в одном из подсостояний: Проверка, Звонок, Ждать. В свою очередь, в подсостояние могут вкладываться другие подсостояния. Степень вложенности подсостояний не ограничивается. Данная семантика соответствует случаю последовательных подсостояний.

Возможно наличие параллельных подсостояний — они выполняются параллельно внутри составного состояния.

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

ИмяОбъекта: ИмяКласса

Примеры записи имени:

Адам: Человек : Пользователь мойКомпьютер агент:

Имя объекта и класса Только имя класса (анонимный объект) Только имя объекта (подразумевается, что имя класса известно) Объект — сирота (подразумевается, что имя класса неизвестно)

Синтаксис представления свойства имеет вид

Имя: Тип = Значение

Примеры записи свойства:

номер:Телефон = "7350-420" активен = True

Имя, тип, значение Имя и значение

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

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

«global» «local» «parameter» «self»

Объект-поставщик находится в глобальной области определения Объект-поставщик находится в локальной области определения объекта-клиента Объект-поставщик является параметром операции объекта-клиента Один и тот же объект является и клиентом, и поставщиком

Сообщение — это спецификация передачи информации между объектами о требуемой деятельности. Прием сообщения рассматривается как событие.

Результатом обработки сообщения обычно является действие. В языке UML моделируются следующие разновидности действий:

Вызов Возврат Посылка(Send) Создание Уничтожение

В объекте запускается операция Возврат значения в вызывающий объект В объект посылается сигнал Создание объекта, выполняется по стандартному сообщению «create» Уничтожение объекта, выполняется по стандартному сообщению «destroy»

Для записи сообщений в языке UML принят следующий синтаксис:

ВозврВеличина:= ИмяСообщения (Аргументы),

где ВозврВеличина задает величину, возвращаемую как результат обработки сообщения.

Примеры записи сообщений:

Коорд:= ТекущПоложение(самолетТ1) оповещение() УстановитьМаршрут(х) «create»

Вызов операции, возврат значения Посылка сигнала Вызов операции с действительным параметром Стандартное сообщение для создания объекта

Пример:

Рис. 12.17. Поток синхронных сообщений

 

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

Рис. 12.18. Поток асинхронных сообщений

Так же может использоваться итерации и ветвления.

Итерация *[i:= 1.. n].

Ветвление 1 [х>0]:вычислить корень(х).

Таким образом, для формирования диаграммы сотрудничества выполняются следующие действия:

1) отображаются объекты, которые участвуют во взаимодействии;

2) рисуются связи, соединяющие эти объекты;

3) связи помечаются сообщениями, которые посылают и получают выделенные объекты.

Рис. 12.19. Итерация и ветвление

Пример диаграммы Use Case

Рис. 12.35. Использование включения и расширения

Стрелки расширения в диаграмме подписаны. Помимо стереотипа, здесь указаны:

q в круглых скобках — имена точек расширения;

q в квадратных скобках — условие расширения.

Разновидности компонентов

Стандартные стереотипы, предусмотренные в UML для компонентов:

Стереотип	Описание
«executable» «library» «file» «table» «document»	Компонент, который может выполняться в физическом узле (имеет расширение.ехе) библиотека (имеет расширение.dll) исходный код (имеет расширение.ini) таблицу базы данных (имеет расширение.tbl) документ (имеет расширение.hip)

Рис. 13.5. Пиктограмма исполняемого Рис. 13.6. Пиктограмма объектной

элемента библиотеки Рис. 13.7. Пиктограмма документа Рис. 13.8. Пиктограмма таблицы с исходным кодом или данными базы данных

Рис. 13.9. Пиктограмма документа

Функции Модуля отчетности

• формирование обязательной отчетности в соответствии с требованиями инструкций Банка России;
• формирование оперативных отчетов о процессах и операциях пользователей системы;
• обеспечение расчета в тысячах единиц и их консолидация на основе данных головной организации и филиалов.

Подсистема «Интернет-банк»

· организация защищенного электронного документооборота;

· платежное поручение в рублях;

· поручение на сделку с ценными бумагами;

· депозитарные поручения;

· просмотр выписок, остатков по счетам в режиме реального времени;

· интеграция с любыми внешними бухгалтерскими программами;

· акцептование электронно-цифровой подписью банка полученных от клиента платежных документов.

Функции Модуля отчетности

• формирование обязательной отчетности в соответствии с требованиями инструкций Банка России;
• формирование оперативных отчетов о процессах и операциях пользователей системы;
• обеспечение расчета в тысячах единиц и их консолидация на основе данных головной организации и филиалов.

Подсистема «Интернет-банк»

· организация защищенного электронного документооборота;

· платежное поручение в рублях;

· поручение на сделку с ценными бумагами;

· депозитарные поручения;

· просмотр выписок, остатков по счетам в режиме реального времени;

· интеграция с любыми внешними бухгалтерскими программами;

· акцептование электронно-цифровой подписью банка полученных от клиента платежных документов.

РИС 1.3

Витрины данных и хранилище данных значительно отличаются друг от друга. Хранилище данных создается для решения корпоративных задач(т.е. всей компании), а Витрина данных - для решения узкоспециализированных задач опредеоенного круга.

 

Рис. 1.3. Схема взаимосвязи витрин данных и хранилища данных

Структура витрин данных также ориентирована в виде витрин гиперкуба, используя схему «звезда».

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

Обработка

XSLT. В спецификации XSLTопределяется язык, используемый для описания преобразований входного XML-документа в выходное дерево. Выходное дерево может, например, принять форму HTML-документа или другого XML-формата и, таким образом, XSLT может считаться языком, предназначенным для преобразования XML в форму представления традиционного браузера или для обработки XML-файлов с помощью скриптов. Это преобразование представляет собой XML-документ, определенный в отдельном словаре, а для обращения к исходному документу и выполнения общих операций обработки используются выражения спецификации XPath (рассмотренной ранее). Специальные инструкции устанавливают правила обработки (XSLT является декларативным языком) и управляют процессом создания выходного дерева.

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

Принцип эффективности

При внедрении ИБТ необходимо помнить и об эффективности. Автоматизация не должна быть разорительной для банка. Стоимость технологии не должна превышать эффект от ее внедрения. Поэтому при выборе технологии следует учитывать объем информации (в том числе и количество документов, ежедневно обрабатываемых банком), наличие филиалов и отделений, количество клиентов и оказываемых услуг (сегментация клиентской базы и пакета услуг), необходимость взаимодействия с внешними системами (биржами, платежными системами S.W.I.F.T., РКЦ), наличие возможности обмена данными с локальным программным обеспечением (ПО) и системами, которые уже используются в кредитной организации.

Для оценки эффективности информационной технологии применяется следующий подход. С одной стороны, подсчитывается так называемая «стоимость владения» (поддержание оборудова­ния и программного обеспечения, составляющего информацион­ную систему компании), а с другой - определяется, насколько использование этой информационной системы повышает производительность труда. Для оценки эффективности банковской технологии кроме соотношения «стоимость владения/производительность труда» необходимо учитывать и другие факторы:

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

• возможность поддержки уникального бизнеса компании - способность реализовывать конкурентные преимущества банка на рынке услуг;

• возможность адаптации - способность поддерживать новые бизнес-решения и новые услуги банка.

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

 

Принцип внедрения:

Эффект от внедрения определяется, исходя из повышения производительности труда.

Учитывается возможность контроля при проведении операции, поддержки бизнеса компании, адаптации.

Для внедрения требуется:

Поддержка главы компании

Наличие технически грамотного специалиста со стороны заказчика

Лицензионное ПО

 

Для автоматизации бизнес-процесса нужно провести:

Комплексный анализ существующей системы и процесса, который нужно автоматизировать, перестоить

Реинжиниринг

Внедрить систему управления

2 пути:

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

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

Функции Модуля отчетности

• формирование обязательной отчетности в соответствии с требованиями инструкций Банка России;
• формирование оперативных отчетов о процессах и операциях пользователей системы;
• обеспечение расчета в тысячах единиц и их консолидация на основе данных головной организации и филиалов.

Подсистема «Интернет-банк»

· организация защищенного электронного документооборота;

· платежное поручение в рублях;

· поручение на сделку с ценными бумагами;

· депозитарные поручения;

· просмотр выписок, остатков по счетам в режиме реального времени;

· интеграция с любыми внешними бухгалтерскими программами;

· акцептование электронно-цифровой подписью банка полученных от клиента платежных документов.

Статические модели объектно-ориентированных программных систем

Статические модели обеспечивают представление структуры систем в терминах базовых строительных блоков и отношений между ними. «Статичность» этих моделей состоит в том, что здесь не показывается динамика изменений системы во времени. Вместе с тем следует понимать, что эти модели несут в себе не только структурные описания, но и описания операций, реализующих заданное поведение системы. Основным средством для представления статических моделей являются диаграммы классов [8], [23], [53], [67]. Вершины диаграмм классов нагружены классами, а дуги (ребра) — отношениями между ними. Диаграммы используются:

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

q в ходе проектирования — для фиксации структуры классов, которые формируют системную архитектуру.

(содержит атрибуты, методы и взаимосвязи)