Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Системный анализ и проектирование информационных систем на основе объектно-ориентированного подхода. Учебно-методическое пособие по дисциплине «Методы
.pdf
проектирования и разработки программного обеспечения
(ПО) бизнес-процесса. Очевидно, автоматизация процесса
создания ПО предполагает наличие формализованной
процедуры разработки, то есть процедуры, в которой
однозначно определены этапы разработки, методы,
используемые на каждом этапе, способы документирования
решений, проверки их правильности и т.д.
CASE-средство – программное средство,
поддерживающее процессы жизненного цикла (ЖЦ) ПО,
определенные в стандарте ISO/IEC 12207:1995.
Традиционно выделяются следующие основные этапы
ЖЦ ПО:
анализ требований,
проектирование (моделирование),
кодирование (программирование),
тестирование и отладка,
эксплуатация и сопровождение.
Анализ требований выделяется в отдельный этап, то есть
этой проблеме придается большое значение при создании
программных продуктов. Считается, что именно здесь
лежит ключ к успеху разработки. На этом этапе дается ответ
на вопрос, что должна делать создаваемая система, то есть
каковы ее функции, условия их выполнения, особенности
взаимодействия с пользователями и другими системами.
Безусловно, что этот этап основан на творческой работе
разработчика (системного аналитика). CASE-технология
должна помочь ему четко представить все особенности
создаваемой системы и также четко и однозначно выразить
требования к ней.
Этапы анализа требований и проектирования,
являющиеся наиболее трудно формализуемыми, как раз и
явились теми, где CASE-технологии получили наибольшее
распространение.
11
Большинство CASE-средств основано на парадигме
методология/метод/нотация/средство:
Методология определяет руководящие указания для
оценки и выбора проекта разрабатываемого ПО, шаги
работы и их последовательность, а также правила
распределения и назначения методов и исполнителей.
Метод – это систематическая процедура или техника
генерации описаний компонент ПО (например,
проектирование потоков и структур данных).
Нотации предназначены для описания структуры
системы, элементов данных, этапов обработки и включают
графы, диаграммы, таблицы, блок-схемы, формальные и
естественные языки.
Средства – инструментарий для поддержки и усиления
методов. Например, поддержка работы пользователей при
создании и редактировании графического проекта в
интерактивном режиме и др.
1.3 Методологии CASE-средств
Существующие CASE-средства основаны на
методологиях структурного или объектноориентированного подходов к анализу и проектированию
информационных систем бизнес-процессов, использующих
спецификации в виде диаграмм или текстов для описания
внешних требований, связей между моделями системы,
динамики поведения системы и архитектуры программных
средств.
Структурным подходом принято называть метод
анализа бизнес-процессов, представленный как
совокупность взаимодействующих функций или работ,
который начинается с ее общего обзора и затем
детализируется, приобретая иерархическую структуру со
все большим числом уровней. Для таких методов
12
характерно разбиение на уровни абстракции с
ограничением числа элементов на каждом из уровней
(обычно от 3 до 6-7); ограниченный контекст, включающий
лишь существенные на каждом уровне детали; дуальность
данных и операций над ними; использование строгих
формальных правил записи; последовательное
приближение к конечному результату.
В основе объектно-ориентированного подхода (ООП)
лежит объектная декомпозиция, при этом статическая
структура системы описывается в терминах объектов и
связей между ними, а поведение системы – в терминах
обмена сообщениями между объектами.
Главный недостаток структурного подхода: процессы и
данные существуют отдельно друг от друга, причем анализ
бизнес-процессов ведется от процессов к данным.
В ООП основная категория объектного анализа «Класс»
объединяет в себе данные и операции, которые над ними
выполняются. Поскольку данные по сравнению с
процессами являются более стабильной и редко
изменяющейся частью бизнес-процесса, то объектноориентированные модели и системы более открыты и легче
поддаются внесению изменений, так как их конструкции
базируются на устойчивых формах.
В рамках курса лабораторных работ используется
методология объектно-ориентированного подхода.
1.4 Принципы и понятия объектно-ориентированного
подхода (ООП)
Концептуальной основой ООП является объектная
модель, обладающая следующими принципами:
Абстрагирование – выделение наиболее важных,
существенных характеристик некоторого объекта бизнеспроцесса и игнорирование незначительных деталей. Оно
13
позволяет управлять сложностью системы, концентрируясь
на существенных свойствах объекта. Абстрагирование
зависит от предметной области и точки зрения – то, что
важно в одном контексте, может быть неважно в другом.
Объекты и классы – основные абстракции бизнес-процесса.
Инкапсуляция – физическая локализация свойств и
поведения в рамках единственной абстракции, скрывает
реализацию объекта за общим доступным интерфейсом.
Полиморфизм – процесс, при котором методам, с
одинаковым именем, соответствует различный код. Все
будет зависеть от того, какой объект вызывает данный
метод.
Наследование – означает, что можно создать класс на
основе уже существующего. Наследование реализует
концепцию повторного использования кода. Когда вы
создаете класс на основе уже существующего – то к
создаваемому переходят все свойства и методы, которые
были у класса-родителя.
Модульность – свойство системы с возможностью её
декомпозиции. Модульность снижает сложность системы и
позволяет выполнять независимую разработку системы.
Иерархия – ранжирование системы абстракции,
расположенные по уровням.
К основным понятиям ООП (элементам объектной
модели) относятся:
Объект – осязаемая сущность, предмет или явление
(процесс), имеющий чёткое поведение. Может
представлять абстракцию некоторой сущности (объект
бизнес-процесса) или программной системы (архитектуры).
Любой объект обладает:
o Состоянием – характеризуется перечнем всех
возможных статических свойств данного
объекта и текущими значениями каждого из этих
свойств
14
o Поведением – определяет действие объекта и его
реакцию на запросы от других объектов.
Определяется набором операций.
Класс – множество объектов, связанных общностью
свойств, связей и семантики. Инкапсулирует в себе данные
(атрибуты) и поведение (операции). Любой объект является
экземпляром класса. Класс является классификатором
объекта.
Атрибут – поименованное свойство класса,
определяющее диапазон допустимых значений, которые
могут принимать экземпляры данного свойства.
Операция – реализация услуги, которую можно
запросить у объекта данного класса (отражает поведение
объекта).
Интерфейс – совокупность операций, определяющих
набор услуг класса.
1.5 Метод RUP ООП
При создании сложных информационных систем
бизнес-процессов требуется четко и грамотно организовать
весь процесс разработки ИС – от написания технического
задания до внедрения на предприятии и дальнейшего ее
развития.
Rational Unified Process (RUP) – один из лучших
методов разработки информационных систем бизнеспроцессов на основе объектно-ориентированного подхода,
созданный компанией IBM Rational Software.
Технология RUP обладает следующими основными
особенностями:
1. Итеративный характер процесса разработки ПО. В
современных динамичных условиях практически
невозможно создавать сложные программные системы
последовательно, т. е. сначала выявлять все проблемы,
15
затем принимать проектные решения, потом формировать
программное обеспечение и, наконец, проверять
полученное изделие. Итеративный подход позволяет
улучшать понимание проблем на основе последовательных
усовершенствований и конкретизировать их в эффективных
решениях.
2. Управление проектной деятельностью на базе
прецедентов, определяющих функционал системы.
Прецеденты способствуют эффективному управлению
технологическим маршрутом от бизнес-моделирования и
определения требований вплоть до испытаний. Они
обеспечивают связанные и доступные для анализа
направления разработки и развертывания системы.
3. Ориентация на создание и физическое воплощение
визуальных моделей. Основное внимание в RUP
сосредоточивается на разработке и дальнейшем развитии
надежной и гибкой архитектуры, которая облегчает
параллельную разработку и минимизирует необходимость
изменений.
1.6 Нотация UML ООП
RUP технология использует в качестве визуальной
нотации моделирования язык UML (Unified Modeling
Language).
Главные цели использования UML:
предоставить пользователям готовый к
использованию выразительный язык визуального
моделирования, позволяющий разрабатывать осмысленные
модели и обмениваться ими;
предусмотреть механизмы расширения и
классификации;
обеспечить независимость от конкретных языков
программирования и процесса разработки.
16
Язык UML представляет собой общецелевой язык
Наименование
Обозначение
Определение (семантика)
Структурные сущности
Класс
(class)
Множество объектов,
имеющих общую
структуру и поведение
визуального моделирования, разработанный для
спецификации, визуализации, проектирования и
документирования компонентов программного
обеспечения, бизнес-процессов и других систем. Этот язык
одновременно является простым и мощным средством
моделирования и может быть эффективно использован для
построения концептуальных, логических и графических
моделей сложных систем самого различного целевого
назначения.
Нотация UML обеспечивает семантику языка, является
способом унификации обозначений визуального
моделирования, обеспечивает всестороннее представление
системы, которое сравнительно легко и свободно
воспринимается человеком. Последняя версия нотации
UML 2.5 опубликована в июне 2015 года. Проектирование
информационных систем бизнес-процессов с помощью
UML осуществляется поэтапным построением ряда
диаграмм, каждая из которых отражает определенную часть
или сторону системы.
1.6.1 Элементы модели в нотации UML
Главными элементами модели в нотации UML
являются сущности и отношения между ними. Сущности
разделяют на четыре группы: структурные, поведенческие,
группирующие и аннотационные. В таблице 1 приведены
основные виды сущностей UML.
Таблица 1 – Основные сущности UML
17
Наименование
Обозначение
Определение (семантика)
Объект
(object)
Абстракция реальной или
воображаемой сущности с
четко выраженными
концептуальными
границами,
индивидуальностью
(идентичностью),
состоянием и поведением.
С точки зрения UML
объекты являются
экземплярами класса
(экземплярами сущности)
Интерфейс
(interface)
iРасчет
Совокупность операций,
определяющая сервис
(набор услуг),
предоставляемый классом
или компонентом
Актер
(actor)
Инженер
службы пути
Внешняя по отношению к
системе сущность, которая
взаимодействует с
системой и использует ее
функциональные
возможности для
достижения определенных
целей или решения
частных задач. Таким
образом, актер – это
внешний источник или
приемник информации
Вариант
использования
(use case)
Описание
последовательности
выполняемых системой
действий, которая
18
Наименование
Обозначение
Определение (семантика)
приводит к значимому для
актера результату
Состояние
(state)
Описание момента в ходе
жизни сущности, когда она
удовлетворяет некоторому
условию, выполняет
некоторую деятельность
или ждет наступления
некоторого события
Кооперация
(collaboration)
Описание совокупности
экземпляров актеров,
объектов и их
взаимодействия в процессе
решения некоторой задачи
Компонент
(component)
Физическая часть системы
(файл), в том числе модули
системы, обеспечивающие
реализацию
согласованного набора
интерфейсов
Узел
(node)
Физическая часть системы
(компьютер, принтер и т.
д.), предоставляющая
ресурсы для решения
задачи
Группирующие сущности
Пакет
(package)
Элемент, используемый
для некоторого смыслового
объединения элементов
диаграммы
Аннотирующие сущности
Примечание
(comment)
Комментарий к элементу
диаграммы
В UML используются четыре типа отношений,
представленные в таблице 2.
19
Наименование
Обозначение
Определение (семантика)
Ассоциация
(association)
Описывает совокупность
взаимодействий между
объектами. Имеет имя,
кратность, роль. Наиболее
общий вид отношения
Агрегация
(aggregation)
Подвид ассоциации,
описывающей связь «часть» –
«целое», в котором «часть»
может существовать отдельно
от «целого». Ромб указывается
со стороны «целого».
Отношение указывается только
между сущностями одного
типа
Композиция
(composition)
Подвид агрегации, в которой
«части» не могут существовать
отдельно от «целого».
Зависимость
(dependency)
Отношение между двумя
сущностями, в котором
изменение в одной сущности
(независимой) может влиять на
состояние или поведение
другой сущности (зависимой).
Со стороны стрелки
указывается независимая
сущность
Обобщение
(generalization)
Отношение между
обобщенной сущностью
(предком, родителем) и
специализированной
сущностью (потомком,
дочкой). Треугольник
указывается со стороны
родителя. Отношение
указывается только между
сущностями одного типа
Таблица 2 – Основные сущности UML
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]