Similar presentations:
Корпоративные информационные системы. Лекция 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.
Нефункциональные требованияПрозрачность отказа
Прозрачность отказа означает, что пользователям и программистам
не требуется знать, как распределенная система справляется с отказами.
Прозрачность отказов вскрывает отказы от пользователей, от
клиентов и серверных компонентов.
Значит, при проектировании компонентов можно не принимать во
внимание возможность отказа тех служб, на которые они опираются.
Прозрачность отказов подразумевает, что разработчик сервера не
должен принимать специальных мер по восстановлению серверных
компонентов после отказов.
Прозрачность
отказов
обеспечивается
прозрачностью
одновременного выполнения и прозрачностью репликации.