Корпоративные информационные системы. Лекция 11. Раздел 4. Разработка ПО КИС. Часть 4.4

1.

Корпоративные
информационные системы
Лекция 11
Раздел 4. Разработка ПО КИС
Часть 4.4. Объектно-ориентированный анализ
(кроме нефункциональных требований)
Преподаватель: Недашковский В. М.

2.

Часть 4. Объектно-ориентированный анализ.

3.

Объектно-ориентированный анализ
Этап объектно-ориентированного анализа
включает:
• описание предметной области,
• анализ требований (кроме нефункциональных
требований)
•.

4.

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

5.

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

6.

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

7.

Описание предметной области
Отчет о предпроектном обследовании предприятия имеет
следующую структуру:
• краткое схематическое описание бизнес-процессов
(управление закупками и запасами, управление производством,
управление продажами, управление финансовыми ресурсами);
• основные требования и приоритеты автоматизации;
• оценка необходимых для обеспечения проекта ресурсов
заказчика;
• оценка возможности автоматизации и предложения по
созданию КИС с оценкой примерных сроков и стоимости.

8.

Анализ требований
Требование к ПО – это некоторое свойство ПО,
необходимое пользователю для решения проблемы при
достижении поставленной цели.
Другими словами, требования задают возможности,
которые должна предоставлять система.
Управление требованиями – это систематический подход
к выявлению, организации и документированию требований к
системе, а также процесс, в ходе которого вырабатывается и
обеспечивается соглашение между заказчиком и выполняющей
проект группой по поводу меняющихся требований к системе.

9.

Анализ требований
Рассмотрение требований рекомендуется начинать с
рассмотрения области проблем.
Область проблем – это предметная область реальных
пользователей, чьи потребности надо удовлетворять путем
построения соответствующей системы.
Задача разработчиков – понять проблемы
пользователей в их предметной области и на их языке и
построить систему, удовлетворяющую их потребности.
По мере выявления потребностей разработчики
формируют набор потребностей.

10.

Анализ требований
Следовательно, первоначально полезно
сформулировать, что разработчики узнали о потребностях
в предметной области и как они собираются этого достичь
по средствам решения.
Эти формулировки называют функциями создаваемой
системы.
Таким образом, функция – это предоставляемое
системой обслуживание для удовлетворения одной или
нескольких потребностей заинтересованных лиц.

11.

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

12.

Анализ требований
Система чаще всего создается для решения
определенной проблемы. Для правильного понимания
проблемы рекомендуется использовать методы анализа
проблем.
Анализ проблемы – это, во-первых, процесс
осознания реальных проблем и потребностей
пользователя, а, во-вторых, предложения решений для
удовлетворения этих потребностей.

13.

Анализ требований
Пять этапов анализа проблемы
1. Достигнуть соглашения об определении проблемы.
2. Выделить основные причины проблемы, стоящие за
проблемой.
3. Выявить заинтересованных лиц и пользователей.
4. Определить границу системы решения.
5. Выявить ограничения, которые необходимо наложить на
решение.

14.

Анализ требований
Этап 1. Достижение соглашения об определении проблемы.
Один из простейших способов достижение соглашения об
определении проблемы. - это просто записать проблему и
выяснить, все ли согласны с такой формулировкой.
Часто бывает полезно записать проблему стандартной форме

15.

Анализ требований
Элемент
Описание
Проблема
[описание проблемы]
воздействует
Результатом чего
является
Выигрыш от
[указание лиц, на которых оказывает влияние
данная проблема]
[описание воздействия данной проблемы на
заинтересованных лиц и бизнес-деятельность]
[указание предлагаемого решения]
может состоять в
следующем
[список основных предоставляемых решением
преимуществ]

16.

Анализ требований
Этап 2. Выделение основных причин - проблем, стоящие за проблемой
Пониманию реальных проблем и их причин помогает метод
анализа корневых причин.
Способ определения корневых причин зависит от конкретного
случая, и выявить их чаще всего помогают люди, непосредственно
занимающихся этим делом. Однако для серьезных проблем часто
нужно произвести детальное исследование каждой из причинпроблем и количественно определить вклад ее в отдельности.
Часто устранение большой части корневых причин не дает
желаемого результата, поскольку затраты на их устранение
превысят причиняемый проблемой ущерб.

17.

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

18.

Анализ требований
Пример.
Предположим,
что
корневая
причина
«неправильные заказы на покупку» является
причиной половины всех остатков.
Предположим также, что команда разработчиков
вышла с аргументированным предложением заменить
существующую систему ввода заказов на покупку
Теперь можно записать проблему ввода заказов
на покупку в стандартной форме

19.

Анализ требований
Элемент
Проблема
воздействует на
результатом чего является
Выигрыш от
может состоять в
следующем
Описание
неправильность заказов на покупку
выполняющий заказы персонал
увеличение остатков, повышение производственных
затрат, неудовлетворенность клиентов, уменьшение
прибыли
новой системы, направленной на решение данной
проблемы
- повышение точности заказов в точке ввода,
- совершенствование учета данных о покупках,
- в конечном счете, увеличение прибыли

20.

Анализ требований
Этап 3. Выявление заинтересованных лиц и пользователей.
Заинтересованные лица – это прямые и непрямые пользователи,
которых затрагивает реализация новой системы или приложения.
Понимание их потребностей является важнейшим фактором в
выработке успешного решения.
Потребности прямых пользователей легко учитываются, так
как они непосредственно привлекаются к определению и
использованию системы.
Потребности непрямых пользователей, а также тех, на кого
воздействуют только бизнес–последствия разработки выявить и
учесть гораздо сложнее.

21.

Анализ требований
Этап 4. Определение границ системы-решения
Границы системы представляет собой «рубеж» между
решением и окружающим его реальным миром. Все
взаимодействия с системой осуществляются посредством
интерфейсов между системой и внешним миром.
Обозначим понятием «актеры», «то, что взаимодействует
с разрабатываемой системой» и заставляет ее работать.
Определившись с подобной информацией, аналитик
может создать блок-схему, описывающую границы системы,
пользователей и другие интерфейсы. Пример.

22.

Анализ требований
Имеющаяся
информационная
система
Новый ввод
заказов на
покупку
Граница системы
Продавец
вводит заказы
на покупки
Продавец
выписывает
счет

23.

Анализ требований
Этап 5. Выявление ограничений, налагаемых на решение.
Существуют различные источники ограничений. Ограничения могут быть
заданы еще до начала работы. Примеры видов ограничений.
1. Экономические:
- финансовые,
- бюджетные,
-связанные с вопросами себестоимости и ценообразования,
- связанные с вопросами лицензирования.
2. Политические, влияющие на потенциальное решение:
- внешние;
- внутренние;
- проблемы между подразделениями;

24.

Анализ требований
3. Технические, накладывающие ограничения на выбор
технологии:
- возможность использования новых технологий;
- необходимость закупки новых пакетов;
- использование существующих платформ.
4. Системные:
- использование существующих систем;
- необходимость создания новых систем;
- необходимость совместимости с существующими решениями.

25.

Анализ требований
5. Эксплуатационные:
- наличие ограничений на информационную среду;
- наличие юридических, правовых ограничений;
- ограничения требований техники безопасности;
6. Временные и ресурсные:
- наличие графика;
- ограничения на ресурсы;
- возможность увеличения штатов;
- возможность привлечения сотрудников со стороны.

26.

Нефункциональные требования
Различают функциональные и нефункциональные требования КИС.
Функциональные требования относятся к тем функциям, которые
система должна выполнять для своих пользователей.
Нефункциональные требования относятся к качеству системы.
Они, как правило, носят глобальный характер, то есть относятся ко всей
системе в целом.
Чаще всего КИС реализуется в виде распределенной
информационной системы. Поэтому обсуждение нефункциональных
требований
будем
проводить
в
контексте
распределенной
информационной
системы
(набор
независимых
компьютеров,
представляющийся их пользователям единой системой).
Нефункциональные требования существенно влияют на выбор
архитектуры систем.

27.

Нефункциональные требования
На выбор архитектуры системы обычно
следующие нефункциональные требования:
- масштабируемость,
- открытость,
- неоднородность,
- разделение ресурсов,
- отказоустойчивость.
влияют

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

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

35.

Нефункциональные требования
Прозрачность местонахождения
Прозрачность
местонахождения
означает,
что
запрашивающему обслуживание объекту не требуется знать о
физическом расположении компонента.
Прозрачность миграции
Бывают случаи, когда возникает необходимость в переносе
компонента с одного узла на другой. Это может быть вызвано,
например перегрузкой узла (решаемыми задачами) или заменой
аппаратуры. Перенос может потребоваться и при изменении
доступа к компоненту, например, если компонент должен стать
ближе к пользователям.

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

Спасибо за внимание