- •1.Что такое it - консалтинг и работы, выполняемые в процессе консалтинга.
- •2. Назначение и средства построения моделей существующей as-is и новой to-be организации бизнес-процессов предприятия
- •3.Два способа перехода от модели as-is к модели to-be. (35)
- •4.Решения начальных этапов проектирования информационной системы (36)
- •5.Методология структурного анализа sadt и стандарт моделирования бизнес-процессов idef0. (44)
- •6.Каковы цели и этапы разработки консалтинговых проектов? (33)
- •7.Представить функциональную модель бизнес-процессов работы банкомата, используя нотацию idef0.
- •8.Представить информационную модель работы банкомата, используя нотацию dfd.
- •9.Каким образом можно связать технологию создания функциональных моделей Каким образом можно связать технологию создания функциональных моделей и реинжиниринг бизнес-процессов.
- •10.Суть и назначение процессного подхода, сформулированного м. Хаммером и д. Чампи.
- •11. Свойства объектного подхода: абстракция, инкапсуляция, наследование, полиморфизм, взаимодействие путем передачи сообщений, повторное использование компонентов
- •12. Основные принципы объектной модели и правила определения и документирования объектов.
- •13. Преимущества объектной модели от моделей структурного анализа, проектирования и программирования.
- •14. Природа классов и объектов объектной модели, взаимоотношения между ними; состояние, поведение и идентичность объектов на примере Вашей курсовой работы.
- •15. Что такое класс объектной модели, атрибуты и операции класса и их форматы спецификаций на примере Вашей курсовой работы. (92)
- •16. Отношения между классами: ассоциация и зависимость. Привести примеры таких отношений на диаграмме классов Вашей курсовой работы . (102)
- •17.Отношения между классами: конкретизация и зависимость. Привести примеры таких отношений на диаграмме классов Вашей курсовой работы. (103)
- •19. Объяснить назначение классов и применение отношений: ассоциация, зависимость, композиция и конкретизация между классами модельного примера "Гирлянда из цветных лампочек". (113)
- •21. Запись функциональных требований к информационной системе с помощью вариантов использования. Пример диаграммы вариантов использования интернет-системы бронирования авиабилетов.(125, 162)
- •22. Нефункциональные требования и пример нефункциональных требований к интернет-системе бронирования авиабилетов. (134, 162, 213)
- •23. Концептуальные модели: пользовательского интерфейса и предметной области - их назначение и особенности представления. Примеры этих моделей для интернет-системы бронирования авиабилетов. (162, 229)
- •26. Моделирование поведения системы, какие модели используются для этих целей и каким образом отображаются на них события и сообщения между объектами системы. (179)
- •28. Основные концепции и укрупненная схема процесса iconix. Классы анализа и базовые правила их взаимодействия. (201, 205)
- •Примеры использования анализа пригодности
- •30. Концептуальная модель пользовательского интерфейса и руководящие принципы проектирования интерфейса на примере Вашей курсовой работы. (229,239)
- •31. Моделирование вариантов использования. Основной и альтернативные потоки событий. Привести пример моделирования варианта использования «Покупка бензина на автозаправочной станции».
- •Структура спецификации требований
- •33. На примере концептуальной модели предметной области Вашей курсовой работы, смоделировать различные сценарии обслуживания, с использованием crc- карт. (118)
- •34. Методика исследования структуры объектов Вашей курсовой работы и механизмов их взаимодействия с использованием crc-карт. (118-119)]
- •35.Ассоциативный класс и примеры ассоциативных классов Вашей курсовой работы.
- •37. Объектная модель и роль языка uml как универсального средства спецификации, визуализации, конструирования и документирования при проектировании и разработке информационных систем.
- •38. Разработать диаграмму классов для варианта использования "Покупка бензина на автозаправочной станции" и показать взаимодействия объектов этой модели на диаграмме последовательностей.
26. Моделирование поведения системы, какие модели используются для этих целей и каким образом отображаются на них события и сообщения между объектами системы. (179)
Диаграммы деятельности (activity diagrams) – это технология, позволяющая описывать логику процедур, бизнес – процессы и потоки работ. Во многих случаях они напоминают блок – схемы, но принципиальная разница между диаграммами деятельности и нотацией блок – схем заключается в том, что первые поддерживают параллельные процессы. Диаграммы деятельности подвергались самым большим изменениям при смене версий языка UML. В UML-1 диаграммы деятельности разрабатывались как особый случай диаграмм состояний. Это вызвало немало трудностей у специалистов, моделирующих потоки работ, для которых хорошо подходят диаграммы деятельности. В UML 2 это ограничение было ликвидировано.
Диаграммы состояний (state machine diagrams), называемые также конечным автоматом – это известная технология описания поведения системы. В том или ином виде диаграммы состояний существуют с 1960 года, а на заре объектно- ориентированного программирования понятие автомат применялось для представления поведения системы. Автомат (state machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Таким образом, автомат задает поведение системы, как цельной, единой сущности, моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного, трудного для понимания блока (объекта) системы. Кроме того, диаграммы состояний являются хорошим способом представления протоколов, описывающих правильную последовательность сообщений, например, протоколов для доступа к базам данных или для обеспечения связи на основе протокола управления передачей (TCP). Диаграммы состояний идеально подходят для описания работы пользовательских интерфейсов. Если диаграммы взаимодействий хороши для понимания системы, то диаграммы состояний эффективны в определении точного поведения системы.
Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие групп объектов в различных условиях их поведения (в различных сценариях). UML определяет диаграммы взаимодействия нескольких типов, из которых, наиболее употребительными, являются диаграммы последовательности. Обычно диаграмма последовательности описывает один сценарий, как правило, основной. На этой диаграмме показаны экземпляры объектов и сообщения, которыми объекты обмениваются в рамках одного варианта использования. Именно поэтому диаграммы взаимодействия считаются основным аппаратом для фиксации полной динамики системы.
27. Диаграмма последовательности: элементы диаграммы, что и как она описывает, продемонстрировать пример диаграммы последовательности для сценария "Покупка бензина на автозаправочной станции". (191)
Для пояснения концепций диаграмм взаимодействия, используем пример реализации функции поиска вакансий работ на сайте jobs.com[10].
На рисунке 6.11 показан один из вариантов диаграммы последовательности для этой функции.
Рис. 6.11. Детализированная диаграмма последовательности для
функции поиска вакансий на сайте
На этом рисунке имеем клиента (соискатели), страницу поиска и поисковую систему. Используем параметрический объект КритерииПоиска для хранения, проверки и передачи введенной клиентом информации. На диаграмме отображен тот факт, что поисковая система производит чтение информации о вакансии из базы данных (на этом этапе объект БазаДанных может представлять собой интерфейс доступа к данным), а также что этот объект помещает прочтенную информацию в объект СписокПодходящихВакансий. Полученную диаграмму можно реализовать с очень малым уровнем неоднозначности.
Участвующие в потоке объекты нарисованы в прямоугольниках в верхней части диаграммы. Остальные объекты, так называемые объекты инфраструктуры, находятся на серверной стороне и отражают серверную логику, серверные страницы, интерфейсы и другие подобные объекты. Некоторые объекты имеют имена своих классов (необязательно присваивать объектам имена, отличающиеся от имен классов).
У каждого объекта имеется линия жизни, изображаемая в виде вертикальной штриховой линии под объектом. Эта линия начинается, когда создается экземпляр объекта, и заканчивается в точке разрушения объекта. Сообщения, соответствующие коммуникациям между объектами, рисуют между линиями жизни объектов. Сообщение показывает, что объект-клиент вызывает операцию объекта-сервера. При генерации кода, сообщения транслируются в вызовы методов объекта-сервера. Сообщения должны располагаться в хронологическом порядке сверху вниз. Далее, после определения операций класса, каждое сообщение станет операцией. Сообщения могут быть рефлексивными, что соответствует обращению объекта к своей собственной операции.
На диаграммах последовательности можно показывать активизацию (focus of control). Активизация – это маленький прямоугольник, поясняющий интервал активности объекта при взаимодействии. Активность соответствует времени нахождения в стеке одного из методов объекта. В языке UML полосы активности не обязательны, но считается, что они исключительно удобны при пояснении поведения.
Штриховая стрелка обозначает возврат для вызова. Их следует применять, только когда это дает дополнительную информацию, в противном случае они просто вносят неразбериху.
