Методы систематического программирования

ВОПРОСЫ К ЗАЧЕТУ ПО КУРСУ “ТЕХНОЛОГИИ КОМПЬЮТЕРНОГО ПРОЕКТИРОВАНИЯ” ДЛЯ ГРУПП КНит-11, КНитС-13.

 

1. Общая характеристика методов систематического программирования. Структурный подход к разработке ПО.

2. Методология объектно-ориентированного проектирования и ее основные этапы

3. Средства методологии объектно-ориентированного анализа и проектирования (ООАП). Предпосылки создания языка UML.

4. Общая характеристика языка UML.

5. Компонентный подход к проектированию программных средств.

6. Понятие аспектно–ориентированного программирования

7. Понятие генерирующего(порождающего) программирования

8. Понятие агентного программирования

9. Понятие методологии управления жизненным циклом приложений (ALM).

10. Краткая характеристика рынка ALM-продуктов: ведущие компании-разработчики этих средств и их стратегии в сфере создания этих продуктов.

11. Структура линейки ALM-продуктов компании IBM Rational.

12. Рациональный унифицированный процесс (RUP) и его основные компоненты.

13. Общая характеристика интегрированного набора продуктов Rational Suite и варианты его поставки.

14. ALM-стратегия компании Borland.

15. Комплекс программных средств Borland Suite и его основные компоненты

16. Характеристика компонентов комплекса Borland Suite, реализующих этапы определения требований, анализа и проектирования, разработки, тестирования и профилирования.

17. Характеристика компонентов комплекса Borland Suite, реализующих этапы развертывания и управления изменениями. Реализация Возможность выбора инфраструктуры в ALM-стратегии компании Borland.

18. Особенности ALM-методологии Microsoft Solutions Framework (MSF) и ее структура.

19. Модель процессов MSF.

20. Модель проектной группы MSF.

17. Интегральный пакет инструментальных средств AllFusion Modeling Suite 4.1. фирмы Computer Associates (CA) и его основные компоненты.

18. Краткая характеристика CASE-средства верхнего уровня AllFusion Process Modeler (BPwin).

19. Краткая характеристика CASE-средства моделирования данных AllFusion ERwin Data Modeler (ERwin).

20. Краткая характеристика средства коллективной разработки приложений AllFusion Model Manager 4.1 (ModelMart).

21. Краткая характеристика средств поиска и исправления ошибок модели данных AllFusion Data Model Validator 4.1 (ERwin Examiner) и инструмента создания объектных моделей и кодогенерации AllFusion Component Modeler 4.1 (Paradigm Plus).

22. Понятие интеграции ПО

23. Преимущества использования компонентной архитектуры приложений

24. Требования к компонентам

25. Ограничения компонентов

26. Общие сведения о технологии COM.

27. Основные понятия COM-технологии.

28. Структура компонентов COM

29. Основные принципы построения COM-объектов

30. Основные принципы организации интерфейсов: идентификация и реализация интерфейса

31. Основные принципы организации интерфейсов: спецификация интерфейса, классы.

32. Традиционные методы доступа к сервисам приложений

33. Доступ к сервисам приложений с использованием COM

34. Серверы COM

35. Клиенты COM

36. Использование технологии COM

37. Библиотека COM

38. Фабрика класса

39. Общая характеристика расширений СОМ

40. Технология автоматизации (OLE Automation)

41. Мастера СОМ-объектов и создание новых СОМ-объектов с их помощью

42. Общие сведения о семействе методологий IDEFx.

43. Критерии предъявляемые к языкам описания производственных процессов и предпосылки создания методологии IDEF0.

44. Особенности реализации методологии IDEF0.

45. Нотация методологии IDEF0 и графическое обозначение ее элементов.

46. Общая характеристика методологии IDEF1/IDEF1x и основные конструкции ее моделей.

47. Основные требования к методологии IDEF1/IDEF1x.

48. Общая характеристика методология IDEF3. Диаграмма Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN)

49. Диаграмма Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD)

50. Использование диаграмм потоков данных (DFD)

51. Общие сведения о шаблонах проектирования

52. Параметризованные классы

53. Кооперации (сотрудничества)

54. Паттерны (шаблоны проектирования)

55. Паттерн Наблюдатель (Observer)

56. Паттерн Компоновщик (Composite)

57. Паттерн Команда (Command)

58. Бизнес-модели

 

ОТВЕТЫ НА ВОПРОСЫ:

Методы и средства проектирования программных систем

 

В последние годы наибольшее развитие и использование получил объектно–ориентированный, компонентный, сервисно–ориентированный подходы. Для их поддержки были разработаны и соответствующие инструментальные средства (Rational Rose, Rational Software, RUP, Demral , OОram и др.).

Эти подходы составляют основу методам проектирования ПС, которые практически применяются разными разработчиками, использующими подходящие для своих целей возможности этих методов. Получили дальнейшее развитие теоретические методы (алгебраическое, алгеброалгоритмическое, композиционное и др.), которые основываются на математических, алгебраических и логико–алгоритмических подходах и методах формального построения и доказательства программ.

 

Методы систематического программирования

 

К методам систематического программирования отнесены следующие методы:

– структурный;

– объектно–ориентированный (включая моделирование в UML);

– компонентный;

– аспектно–ориентированный;

– генерирующий;

– агентный и др.

Каждый метод имеет свое множество понятий и операций для проведения процесса разработки компонентов или ПС. Вновь появившиеся методы, например, генерирующее программирование использует возможности объектно–ориентированного, компонентного и аспектно–ориентированного методов.

Структурный подход.

Сущность структурного подхода разработки ПС заключается в декомпозиции (разбиении) системы на автоматизируемые функции, которые в свою очередь делятся на подфункции, на задачи и так далее. Процесс декомпозиции продолжается вплоть до определения конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны.

В основу структурного подхода положены такие общие принципы:

– разбивка системы на множество независимых задач, легких для понимания и решения;

– иерархическое упорядочивание, т.е. организация составных частей проблемы в древовидные структуры с добавлением новых деталей на каждом уровне.

В основе этих принципов лежат операции:

– абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных;

– формализации, т.е строгое методологическое решение проблемы;

– непротиворечивости, состоящей в обосновании и согласовании элементов системы;

– структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:

v SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы;

v SSADM (Structured Systems Analysis and Design Method) – метод структурного анализа и проектирования;

v IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 – информационной модели, IDEF2 – динамической модели и др.

На стадии проектирования эти модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

 

2. Объектно–ориентированное проектирование.

Представляет собой стратегию, в рамках которой разработчики системы вместо операций и функций мыслят в понятиях объектов.Объект – это нечто, способное пребывать в различных состояниях и имеющее определенное множество операций. Состояние определяется как набор атрибутов объекта. Операции, связанные с объектом, предоставляют сервисы другим объектам (клиентам) для выполнения определенных вычислений.

Широкое распространение методологии ООП оказало влияние на процесс разработки программ. В частности, процедурно-ориентированная декомпозиция программ уступила место объектно-ориентированной декомпозиции, при которой отдельными структурными единицами программы стали являться не процедуры и функции, а классы и объекты с соответствующими свойствами и методами. Как следствие, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а стала событийно-управляемой. Последнее обстоятельство стало доминирующим при разработке широкого круга современных приложений. В этом случае каждая программа представляет собой бесконечный цикл ожидания некоторых заранее определенных событий. Инициаторами событий могут быть другие программы или пользователи. При наступлении отдельного события, например, нажатия клавиши на клавиатуре или щелчка кнопкой мыши, программа выходит из состояния ожидания и реагирует на это событие вполне адекватным образом. Реакция программы при этом тоже связывается с последующими событиями.

Наиболее существенным обстоятельством в развитии методологии ООП явилось осознание того факта, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Действительно, до того как начать программирование классов, их свойств и методов, необходимо определить, чем же являются сами эти классы. Более того, нужно дать ответы на такие вопросы, как: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами.

Объекты создаются в соответствии с определением класса объектов, который служит шаблоном для создания объектов. В него включены описания всех атрибутов и операций, связанных с объектом данного класса.

Программная система состоит из взаимодействующих объектов, которые имеют собственное локальное состояние и могут выполнять набор операций, определяемый состоянием объекта. Объекты скрывают информацию о представлении состояний и ограничивают к ним доступ.

Под процессомобъектно–ориентированного проектирования подразумевается проектирование классов объектов и взаимоотношений между этими классами. Когда проект реализован в виде исполняемой программы, все необходимые объекты создаются динамически с помощью определений классов. Этот подход подразумевает выполнение трёх этапов при проектировании:

1. Объектно–ориентированный анализ.Создание объектно–ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты–сущности и операции, выполняемые этими объектами.

2. Объектно–ориентированное проектирование.Разработка объектно–ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.

3. Объектно–ориентированное программирование.Реализация архитектуры (модели) системы с помощью объектно–ориентированного языка программирования (С++, Java и др.) для определения объектов и средств определения классов объектов.

Данные этапы могут ”перетекать” друг в друга, т.е. они могут не иметь четких рамок и на каждом этапе применяется одна и та же система нотации. Переход к следующему этапу приводит к усовершенствованию результатов предыдущего этапа путём более детального описания определенных ранее классов объектов и определения новых классов.

Объектно–ориентированные системы можно рассматривать как совокупность автономных и независимых объектов. Изменение реализации какого–нибудь объекта или добавление ему новых функций не влияет на другие объекты системы. Четкое соответствие между реальными объектами (например, аппаратными средствами) и управляющими объектами программной системы облегчает понимание и реализацию проекта.

Объекты могут быть повторно используемыми компонентами, они независимо инкапсулируют данные о состоянии и операциях. Архитектуру ПО можно разрабатывать проект на базе объектов, ранее созданных в предыдущих проектах. Это снижает стоимость проектирования, программирования и тестирования ПО. Кроме того, возможность использования стандартных объектов уменьшает риск, связанный с разработкой ПО.

По сути, программист в процессе разработки ОО программы создает модель заданной предметной области (или системы), в которой в качестве программных объектов обычно выступают модели некоторых реально существующих физических или логических объектов.

Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП), которая оказалась весьма тесно связанной с концепцией автоматизированной разработки программного обеспечения (CASE-средствами).

Методология ООАП, согласно которой любая система представляет собой совокупность некоторого количества взаимодействующих объектов, обеспечила единый подход к проектированию ПО самого разнообразного назначения. И, хотя на первых порах, появилось несколько отличающихся между собой графических нотаций (языков), их различия были не столь существенны, как у графических нотаций структурного системного анализа. К 1994 году наибольшее распространение получили языки Booch, созданный Г. Бучем, OOSE (Object-Oriented Software Engineering), разработанный А. Джекобсоном и ОМТ (Object Modeling Technique), автором которого является Дж. Рамбо. Каждый из этих языков можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны. Выразительные возможности метода Буча особенно важны на этапах проектирования и конструирования модели. OOSE великолепно приспособлен для анализа и формулирования требований, а также для высокоуровневого проектирования. ОМТ-2 оказался особенно полезным для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.

 

В середине 90-х годов, Г. Буч (компания Rational Software Corporation), А. Джекобсон (Objectory) и Дж. Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ, они попытались создать новый, унифицированный язык моделирования. Начав унификацию, авторы поставили перед собой три главные цели:

· моделировать системы целиком, от концепции до исполняемого артефакта, с помощью объектно-ориентированных методов;

· решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения ответственных задач;

· создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.

4. Общая характеристика языка UML.

 

В конце 1995 года появилась пробная версия унифицированного языка моделирования (Unified Modeling Language, UML), который был ориентирован на решение задач первых двух этапов ЖЦ ПО (анализ и проектирование). Его появление было воспринято с большим оптимизмом всем сообществом корпоративных программистов. На сегодняшний день UML является фактическим стандартом описания программных систем и многие производители предлагают пакеты, позволяющие строить диаграммы UML и интегрировать их в рамках модели, а также обеспечивать генерацию программного кода на основе этих моделей. Наиболее известным является пакет Rational Rose компании Rational Software, которая сейчас является одним из подразделений фирмы IBM. Существуют и другие системы – Together Control Center, Model Maker и Bold (компания Borland) Select Enterprise, Visual UML и др.

Язык моделирования UML поддерживает большое количество возможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей. Он широко используется ведущими разработчиками ПО как метод моделирования программных продуктов на всех стадиях жизненного цикла разработки программных систем.

 

5. Компонентный подход к проектированию

По оценкам экспертов, 75 % работ по программированию в мире дублируются (например, программы складского учета, начисления зарплаты, расчета затрат на производство продукции и т.п.). Большинство из этих программ типовые, но каждый раз находятся особенности, которые влияют на их повторное разработку. Компонентное проектирование сложных программ из готовых компонентов является наиболее производительным.

Переход к компонентам происходил эволюционно: от подпрограмм, модулей, функций. При этом усовершенствовались элементы, методы их композиции и накопления для дальнейшего использования (табл.1.1).

Компонентный подход дополняет и расширяет существующие подходы в программировании, особенно ООП. Объекты рассматриваются на логическом уровне проектирования программной системы, а компоненты – это непосредственная физическая реализация объектов. Один компонент может быть реализацией нескольких объектов или даже некоторой части объектной системы, полученной на уровне проектирования. Компоненты конструируются как некоторая абстракция, которая состоит из трех частей: информационной, внешней и внутренней.

Таблица 1.1 Схема эволюции элементов компонентов
Элемент композиции	Описание элемента	Схема взаимодействия	Представле–ние, хранение	Результат композиции
Процедура, подпрограмма, функция	Идентификатор	Непосредственное обращение, оператор вызова	Библиотеки подпрограмм и функций	Программа
Модуль	Паспорт модуля, связи	Вызов модулей, интеграция модулей	Банк, библиотеки модулей	Программа с модульной структурой
Объект	Описание класса	Создание экземпляров классов, вызов методов	Библиотеки классов	Объектно–ори-ентированная программа
Компонент	Описание логики (бизнес), интер-фейсов (APL, IDL), схемы развертывания	Удаленный вызов в компонентных моделях (COM, CORBA, OSF, …)	Репозитарий компонентов, серверы и контейнеры компонентов	Распределенное компонентно–ориентирован-ное приложение
Сервис	Описание биз-нес–логики и интерфейсов сервиса (XML, WSDL, …)	Удаленный вызов (RPC, HTTP, SOAP, …)	Индексация и каталогизация сервисов (XML, UDDI, …)	Распределенное сервисо–ориен-тированное приложение

 

Разработана новая архитектура компонента – контейнер, в котором определяются функции, порядок их выполнения, вызываемые события и сервисные свойства. Выполнение контейнера осуществляется через его интерфейс с помощью провайдера.

Компоненты наследуются в виде классов и используются в модели или композиции, а также в каркасе интегрированной среды. Управление компонентами проводится на трех уровнях: архитектурном, компонентном и на уровне инфраструктуры интерфейса. Между этими уровнями существует взаимная связь.

Компонент описывается в языке программирования, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать.

Расширением понятия компонента есть паттерн – абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность. Представляется повторяемой частью программного элемента, как схемы или взаимосвязи контекста описания решения проблемы.

Методология компонентной разработки систем включает в себя две основные фазы процесса разработки:

1. Разработка отдельных компонентов;

2. Интеграция (композиция) компонентов в более сложные программные образования.