- •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.
- •10.Суть и назначение процессного подхода, сформулированного м. Хаммером и д. Чампи.
- •9.Каким образом можно связать технологию создания функциональных моделей Каким образом можно связать технологию создания функциональных моделей и реинжиниринг бизнес-процессов.
- •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. Разработать диаграмму классов для варианта использования "Покупка бензина на автозаправочной станции" и показать взаимодействия объектов этой модели на диаграмме последовательностей.
19. Объяснить назначение классов и применение отношений: ассоциация, зависимость, композиция и конкретизация между классами модельного примера "Гирлянда из цветных лампочек". (113)
Чаще всего, отношение реализации используется для отношения между интерфейсом и классом, реализующим интерфейс. Интерфейс определяет набор операций, характерных для объектов, обладающих определенными свойствами.
На основе рассмотренных отношений между классами, приведем пример (рис. 4.19) полной иерархии классов проекта «Гирлянда из цветных лампочек» (Garland Application) [18].
На рис. 4.19 представлен вариант определения класса ColorableObject на основе интерфейса IColorable. Проиллюстрируем на этом примере основную идею, лежащую в основе концепции интерфейса. Цветом могут характеризоваться не только лампочки, но и самые разнообразные объекты.
В рамках программной модели было бы неплохо иметь какой-нибудь вполне унифицированный механизм работы с такими объектами. Интерфейс IColorable, «в кооперации» с типом – перечислением ColorEnum, предоставляет простейшую модель такого механизма. Тип ColorEnum содержит элементы перечисления, которые мы будем использовать для идентификации цвета. Интерфейс IColorable использует этот тип для определения сигнатур двух методов SetColor() и GetColor(), которые должен поддерживать любой объект, характеризуемый цветом.
В такой интерпретации класс ColoredLight может трактоваться как разновидность ColorableObject.
Можно реализовать и другие разновидности ColorableObject.
Графически отношение реализации изображается пунктирной линией с полой стрелкой, направленной от сущности (класса), обеспечивающей реализацию, к сущности, определяющей контракт, то есть, к интерфейсу.
Рис.4.19. Диаграмма классов GarlandApplication
Наличие интерфейсов предоставляет возможность работать с объектами разных типов в той части, которая поддерживает соответствующий интерфейс. Это означает, что программист имеет возможность написать общий код для объектов самых разных типов, если этот код затрагивает только ту функциональность, которая связана с реализуемым интерфейсом, например:
void SetWhite (IColorable * arg)
{ arg -> SetColor (WHITE); }
В данный метод, в качестве параметра, можно передать указатель на любой объект, который поддерживает интерфейс IColorable.
В заключение отметим, что большинство современных языков программирования поддерживают интерфейсы в виде встроенных средств языка (включая Java, C#, Visual C++.Net with Managed Extentions). Язык С++ напрямую не поддерживает интерфейсы, однако эквивалентная
20. Что является источниками классов предметной области, каковы типичные приемы и методы выявления и моделирования классов. Привести пример классов интернет-системы бронирования авиабилетов. (116, 162)
Систему образует системное состояние. Состояние является функцией системного текущего набора объектов - экземпляров. Определение внутреннего состояния системы дается в модели классов (class model). К элементам, принимающим участие в моделировании классов, относятся сами классы, атрибуты и операции классов, ассоциации, агрегации и композиции, а также обобщение. Диаграмма классов дает обобщенное визуальное представление обо всех этих элементах модели.
До сих пор мы использовали классы для определения бизнес – объектов. Все приведенные нами примеры классов относились к долгоживущим (постоянным или перманентным) сущностям бизнес – процессов, таким как: Личность, Компания, Курс, Студент, Заказ, Товар и т.д. Это классы, которые определяют модель базы данных для прикладной области. По этой причине подобные классы часто называют классами – сущностями (entity classes) или модельными классами. Они представляют постоянно хранимые объекты базы данных.
Классы – сущности определяют существо любой информационной системы, поэтому понадобится определить классы – сущности для отдельных таблиц и различных смешанных запросов, включающих обращение сразу к нескольким таблицам. Начиная с этого момента, эти сущности просто моделируются как классы. Можно использовать стереотип <<table>>, если сущности представляют какие-либо таблицы, или вообще не указывать стереотип, если необходимо обозначить какой-то собственный (пользовательский) класс.
Анализ функциональных требований направлен преимущественно на выявление классов – сущностей. Однако для функционирования системы требуются также и другие типы классов. Пользователям системы, например, необходимы классы, которые определяют GUI – объекты (такие как экранные формы интерактивного диалога), называемые пограничными классами (boundary classes) (классами представления –view classes). Основной задачей интерфейсных классов является абстрагирование системы от прямого взаимодействия с внешними системами.
Построение концептуальной модели предметной области начинается с выявления абстракций, существующих в реальном мире, то есть тех основных концептуальных объектов, которые встречаются (имеют место) в предметной области. Это связано с тем, что требования к программе меняются намного быстрее, чем реальный мир.
Лучшими источниками классов являются: высокоуровневое описание задачи, низкоуровневые требования и экспертная оценка задачи и предметной области.
В ходе выявления объектов из предметной области (существительные и именные группы), необходимо устанавливать существующие между ними связи. Особый интерес в этом случае представляют два вида отношений: обобщение и агрегирование.
Одной из главных целей построения программы на основе абстракций предметной области является повторное использование, возможность которого выявляется именно на этапе моделирования предметной области. Выделение классов представляет собой итеративную задачу, и первоначальный перечень предполагаемых классов, как правило, претерпевает изменения.
Диаграмма классов интернет-системы бронирования авиабилетов
