А.М. Вендров - Объектно-ориентированный анализ и проектирование (1158627), страница 16
Текст из файла (страница 16)
Каждое представление выражено водной или более диаграммах. Диаграммы могут иметь различные типы иизображать процессы, правила, цели и ресурсы во взаимодействиях друг сдругом. Метод Eriksson-Penker использует четыре различныхпредставления бизнес-модели:• концептуальное представление - структура целей и проблем(дерево целей, представленное в виде диаграммы объектов);• представление процессов - взаимодействие между процессами иресурсами (в виде набора диаграмм деятельности);• структурное представление - структура организации и ресурсов (ввиде диаграмм классов). В качестве примера одной из моделей81этого представления можно привести образец Employment изподразд. 1.5;• представление поведения - поведение отдельных ресурсов идетализация процессов (в виде диаграмм деятельности, состояний ивзаимодействия).«goal»Goal«resourse»«process»«resourse»In: aClassProcess AOut: aClass«control»«supply»«resourse»«resourse»Resourse AResourse BРис.
2.7. Диаграмма деятельности для процесса2.3. Пример использования объектно-ориентированногоподходаВ данном примере используется методика Rational Unified Process,описанная в предыдущем подразделе.2.3.1. Постановка задачиПеред руководителем информационной службы университетаставится задача разработки автоматизированной системы регистрациистудентов на дополнительные платные курсы.
Система должна позволятьстудентам регистрироваться на курсы и просматривать свои табелиуспеваемости с персональных компьютеров, подключенных к локальнойсети университета. Профессора должны иметь доступ к системе, чтобыуказать курсы, которые они будут читать, и проставить оценки за курсы.82В настоящее время в университете функционирует база данных,содержащая всю информацию о курсах (каталог курсов).
Регистрация накурсы происходит следующим образом: в начале каждого семестрастуденты могут запросить у регистратора каталог курсов, содержащийсписок курсов, предлагаемых в данном семестре. Информация о каждомкурсе должна включать имя профессора, наименование кафедры итребования к предварительному уровню подготовки (прослушаннымкурсам).Студент может выбрать 4 курса в предстоящем семестре.
Вдополнение к этому каждый студент может указать 2 альтернативныхкурса на тот случай, если какой-либо из выбранных им курсов окажетсяуже заполненным или отмененным. На каждый курс может записаться неболее 10 и не менее 3 студентов (если менее 3, то курс будет отменен). Вкаждом семестре существует период времени, когда студенты могутизменить свои планы (добавить или отказаться от выбранных курсов).После того, как процесс регистрации некоторого студента завершен,регистратор направляет информацию в расчетную систему, чтобы студентмог внести плату за семестр. Если курс окажется заполненным в процессерегистрации, студент должен быть извещен об этом до окончательногоформирования его личного учебного плана.
В конце семестра студентымогут просмотреть свои табели успеваемости.2.3.2. Создание модели бизнес-процессовДействующие лица:• Студент - записывается на курсы и просматривает свой табельуспеваемости.• Профессор - выбирает курсы для преподавания и ставит оценки закурсы.• Расчетная система - получает информацию по оплате за курсы.• Каталог курсов - база данных, содержащая информацию о курсах.Варианты использования:Исходя из потребностей действующих лиц, выделяются следующиеварианты использования (Business Use Case):• Зарегистрироваться на курсы;• Просмотреть табель успеваемости;• Выбрать курсы для преподавания;• Проставить оценки.83Диаграмма вариантов использования для модели бизнес-процессовпоказана на рис.
2.8.Рис. 2.8. Диаграмма вариантов использования для модели бизнеспроцессовПример спецификации Business Use Case "Зарегистрироваться накурсы":Наименование:Зарегистрироваться на курсы.Краткое описание:Данный Business Use Case позволяет студенту зарегистрироваться наконкретные курсы в текущем семестре. Студент может изменить свойвыбор, если изменение выполняется в установленное время в началесеместра.Основной сценарий:841. Студент приходит к регистратору и просит зарегистрировать его наконкретные курсы или изменить свой график курсов.2.
В зависимости от запроса студента, выполняется один изподчиненных сценариев (создать график или изменить график).Подчиненный сценарий "Создать график":1. Регистратор выполняет поиск в каталоге курсов доступных внастоящий момент курсов и выдает студенту их список.2. Студент выбирает из списка 4 основных курса и 2 альтернативныхкурса.3. Регистратор формирует график студента.4. Выполняется подчиненный сценарий "Принять график".Подчиненный сценарий "Изменить график":1. Регистратор находит текущий график студента.2. Регистратор выполняет поиск в каталоге курсов доступных внастоящий момент курсов и выдает студенту их список.3.
Студент может изменить свой выбор курсов, удаляя или добавляяконкретные курсы.4. После выбора регистратор обновляет график.5. Выполняется подчиненный сценарий "Принять график".Подчиненный сценарий "Принять график":1. Для каждого выбранного студентом курса регистраторподтверждает выполнение студентом предварительных требований(прохождение определенных курсов), факт открытия конкретногокурса и отсутствие конфликтов графика.2. Регистратор вносит студента в список каждого выбранногоконкретного курса.
Курс фиксируется в графике.Альтернативные сценарии:Не выполнены предварительные требования, курс заполнен илиимеют место конфликты графика:Если во время выполнения подчиненного сценария "Принять график"регистратор обнаружит, что студент не выполнил необходимыепредварительные требования, или выбранный им конкретный курсзаполнен (уже записалось 10 студентов), или имеют место конфликтыграфика (два или более курсов с совпадающим расписанием), то онпредлагает студенту изменить свой выбор курсов, либо отменитьформирование графика и вернуться к нему позже.Система каталога курсов недоступна:Если во время поиска в каталоге курсов окажется, что невозможноустановить связь с системой каталога курсов, то регистрацию придетсяпрервать и дождаться восстановления связи.Регистрация на курсы закончена:Если в самом начале выполнения регистрации окажется, чторегистрация на текущий семестр уже закончена, то процесс завершится.852.3.3.
Создание модели бизнес-анализаИсполнители:• Регистратор - формирует учебный план и каталог курсов,записывает студентов на курсы, ведет все данные о курсах,профессорах, успеваемости и студентах.Сущности:•••••Студент.Профессор.График студента (список курсов)Курс (в программе обучения).Конкретный курс (курс в расписании).Диаграмма классов для модели бизнес-анализа, описывающейBusiness Use Case "Зарегистрироваться на курсы", приведена на рис. 2.9.Рис.
2.9. Диаграмма классов модели бизнес-анализа862.4. Спецификация требований к ПОСпецификация требований к ПО является составной частью процессауправления требованиями. Требование [10] – это условие, которомудолжна удовлетворять система, или свойство, которым она должнаобладать, чтобы:• удовлетворить потребность пользователя в решении некоторойзадачи;• удовлетворить требования контракта, стандарта или спецификации.Спецификация требований к ПО является основным документом,который играет определяющую роль по отношению к другим элементамплана разработки ПО. Все требования, определенные в спецификации,делятся на функциональные и нефункциональные. Функциональныетребования определяют действия, которые должна выполнять система,без учета ограничений, связанных с ее реализацией.
Тем самымфункциональные требования определяют поведение системы в процессеобработки информации. Нефункциональные требования не определяютповедение системы, но описывают ее атрибуты или атрибуты системногоокружения. Можно выделить следующие типы нефункциональныхтребований:• требования к применению определяют качество пользовательскогоинтерфейса, документации и учебных курсов;• требования к производительности накладывают ограничения нафункциональные требования, задавая необходимую эффективностьиспользования ресурсов, пропускную способность и времяреакции;• требованиякреализациипредписываютиспользоватьопределенные стандарты, языки программирования, операционнуюсреду и др.;• требования к надежности определяют допустимую частоту ивоздействие сбоев, а также возможности восстановления;• требования к интерфейсу определяют внешние сущности, скоторыми может взаимодействовать система, и регламент этоговзаимодействия.Для выявления требований используются (в различных сочетаниях)следующие методы:• собеседование (интервьюирование);• анкетирование;• моделирование и анализ бизнес-процессов (далее будетрассмотрена методика перехода от объектной бизнес-модели ксистемным требованиям);• сессии по выявлению требований (мозговой штурм);87• создание и демонстрация пользователям работающих прототиповприложений (для выявления замечаний и дополнительныхтребований).Выявленные в результате требования к ПО оформляются в виде рядадокументов и моделей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
