- •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. Разработать диаграмму классов для варианта использования "Покупка бензина на автозаправочной станции" и показать взаимодействия объектов этой модели на диаграмме последовательностей.
11. Свойства объектного подхода: абстракция, инкапсуляция, наследование, полиморфизм, взаимодействие путем передачи сообщений, повторное использование компонентов
Объектно-ориентированный подход (object-oriented approach) к разработке систем получил распространение в 1990-х годах прошлого столетия. Ассоциация производителей ПО Object Management Group (OMG) утвердила для этого подхода, в качестве стандартного средства моделирования, язык UML (Unified Modeling Language – унифицированный язык объектного моделирования).
По сравнению со структурным подходом , объектно-ориентированный в большей степени ориентирован на данные, – он развивается вокруг моделей классов. На этапе анализа, для классов не требуется определять операции – только атрибуты. Возрастающее значение использования в языке UML вариантов использования(Use Case) способствует незначительному смещению акцентов от данных к функциям.
Причинами популярности объектного подхода являются:
преимущества объектной парадигмы за счет таких технических свойств, как абстракция, инкапсуляция, повторное использование компонентов, наследование, взаимодействие путем передачи сообщений, полиморфизм и т.д. Эти свойства могут привести к более высокому уровню повторного использования программного кода и данных, сокращению времени разработки ПО, росту продуктивности труда программистов, повышению качества ПО и т.д.;
возможность удовлетворить требования вновь возникающих типов приложений и находить наилучшие способы борьбы с ростом количества невыполненных заказов на приложения.
Объектный подход к разработке систем следует итеративному процессу с наращиванием возможностей. Единая объектная модель конкретизируется на этапах анализа, проектирования и реализации – в результате успешных итераций добавляются новые детали, при необходимости вводятся изменения и усовершенствования, а релизы программных модулей с наращенными возможностями поддерживают высокий уровень удовлетворенности пользователей и обеспечивают обратную связь, необходимую для успешного продвижения разработки модулей, и системы в целом.
Основная трудность изучения объектной технологии связана с отсутствием очевидной отправной точки и ясного направления исследования, как, например, это происходит в структурном подходе.
В данной главе учебника будет предоставлен необходимый базовый уровень знаний объектной технологии, объектной модели, а также выполнение каких предварительных условий необходимо для анализа требований.
12. Основные принципы объектной модели и правила определения и документирования объектов.
Основными принципами объектной модели являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость.
Объектная модель представляет собой набор правил, которые предписывают, каким образом объекты определяются и документируются. Все объекты, принадлежащие данной объектной модели, соответствуют строгим правилам, которые диктуют их: определение, создание, взаимодействия между объектами и уничтожение. Другими словами, объектная модель формально определяет, что представляет собой объект, как он располагается в памяти, когда создается, как взаимодействует с другими объектами и когда уничтожается. Большинство объектно-ориентированных языков программирования не составляют и не определяют настоящие объектные модели.
Объектная модель – описывает обязанности, отношения и структуру различных объектов предметной области.
Объектная модель представляет системные сущности, их классификацию и агрегирование.
Объектные модели включают модели наследования, агрегирования и поведенческие модели.
Объектная модель предназначена для описания статической структуры информации в системе, которая включает структуру классов и отношения между ними, атрибуты классов, отношения включения и специализации.
Модель компонентного объекта (Component Object Model - COM) – это вклад компании Microsoft в мир объектных моделей. Она служит основой для технологии OLE (Object Linking and Embedding). COM представляет собой стандартную объектную модель промышленного уровня, которая унифицирует системы объектов. Эта модель специфицирует:
правила, по которым объекты структурируются и особым образом располагаются в памяти – определение объекта;
правила, по которым объекты создаются и уничтожаются – управление жизненным циклом;
правила, по которым объекты взаимодействуют друг с другом и проявляют свои функции – протоколы взаимодействия между объектами.
Клиенты и СОМ - серверы общаются друг с другом при помощи интерфейсов.
Интерфейсы – это группы функций, которыми СОМ - объекты обычно пользуются для взаимодействия друг с другом и своими клиентами.
Проявление функциональных возможностей посредством интерфейса – это фундаментальная концепция объектно-ориентированного программирования и проектирования. Используя исключительно интерфейсы, СОМ поддерживает логическую абстракцию и неуклонно проводит в жизнь строгую инкапсуляцию.
Интерфейс определяет протокол взаимодействия двух или более систем. Интерфейсы являются предсказуемыми. Заданный интерфейс всегда обеспечивает абсолютно одинаковый набор функций в любой момент времени. Например, нажатие кнопки «Ввод» на банкомате всегда подтверждает последнее действие. Это истинно для любого банкомата.
Интерфейсы являются неизменными составляющими в модели компонентного объекта (СОМ). Они представляют собой набор операций С++, С#, которые спроектированы, реализованы и выпущены как одно целое, и обеспечивают единственный путь доступа к СОМ- серверу.
