Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ЛАБОРАТОРНАЯ РАБОТА3.doc
Скачиваний:
12
Добавлен:
10.11.2019
Размер:
566.78 Кб
Скачать

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

Структурный подход (slructuied appmach) к разработке систем получил широкое рас­пространение (и был признан стандартом де-факто) в 1980-х годах. Этот подход осно­ван на двух методах: диаграммах потоков данных ( (data flow diagrams — DFD) для мо­делирования процессов и диаграммах сущность-связь (entity relationship diagrams — ERD) для моделирования данных.

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

Объектно-ориентированный подход

Объектно-ориентированный подход (objecUnienled approach) к разработке систем получил распространение в 1990-х годах. Ассоциация производителей ПО Object Management Group утвердила в качестве стандартного средства моделирования для этого подхода язык UML (Unified Modeling Language—Унифицированный язык моделирования).

По сравнению со структурным подходом объектно-ориентированный подход в большей степени ориентирован на данные— он развивается вокруг моделей классов. На этапе анализа для классов не требуется определять операции — только атрибуты. [4]

КОНТРОЛЬНЫЕ ВОПРОСЫ:

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

  2. Производство ПО — это искусство или ремесло. В качестве под­тверждения этого тезиса можно привести высказывание о том, что "Искусство — это союз ме­жду Богом и художником, и чем меньше вкладывает в него художник, тем лучше" (АндреЖид). Какой урок можно вынести из этого?

  3. Охарактеризуйте инвариант разработки ПО.

  4. Что первоначально необходимо для создания системы?

  5. Какие компонентные системы Вы знаете?

  6. Объясните разницу между программными пакетами и компонентами. Какое будущее, по-вашему, ожидает эти две технологий?

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

  8. Какой уровень технологической зрелости требуется для организации, чтобы овладеть кризисной ситуацией? Объясните свою точку зрения.

  9. В ходе объяснения SWOT-подхода к системному планированию мы заметили, что "верно сформулированная миссия отводит главное место потребностям клиентов, а не товарам или услугам, которые предоставляет организация*. Пожалуйста, объясните и проиллюст­рируйте, каким обрезом нацеливание формулировки миссии на определенные товары или услуги может привести к утрате, основной цели системного планирования — дости­жения эффективности.

  10. Кто такой участник проекта?

  11. Реинжиниринг бизнес-процессов (ВРR) проводит ясное различие между бизнес-процессом и бизнес-функцией. В чем заключается это различие? Приведите пример бизнес-процесса, который резервам по горизонтали по всей организации.

  12. Сравните концепции цепочек ценности и бизнес-процесса.

  13. Почему пони мои но метода ISA (архитектура информационной системы) важно для сис­темной разработки?

  14. Назовите три уровня управления организацией. Рассмотрите банковское приложение, которое предназначено для отслеживания стереотипов поведения владельцев кредитных карточек, чтобы автоматически блокировать карточку, если банк заподозрит злоупотреб­ление (кража, подделка и т.д.). Какой уровень управления поддерживает подобное при­ложение? Обоснуйте свое заключение.

  15. Какие этапы можно выделить на детализированном уровне ЖЦ?

  16. Охарактеризуйте Этап установления требований

  17. Охарактеризуйте Этап спецификации требований

  18. Охарактеризуйте Этап проектирования архитектуры

  19. Охарактеризуйте Этап детализированного проектирования

  20. Охарактеризуйте Этап реализации

  21. Охарактеризуйте Этап интеграции

  22. Охарактеризуйте Этап сопровождения

  23. Из каких стадий состоит Этап сопровождения?

  24. Объясните разницу между этапами определения требований и разработки спецификации.

  25. Объясните взаимосвязь двух этапов проектирования (архитектурное проектирование и детализированное проектирование) с первыми двумя этапами жизненного цикла — эта­пом определения требований и этапом разработки спецификации.

  26. Что вы понимаете, под соглашением, объектно-ориентированные системы должны про­ектироваться под интеграцию?

  27. Охарактеризуйте Планирование проекта в течение жизненного цикла ПО

  28. Системное планирование и измерения ПО существенно связаны. Объясните этот тезис.

  29. Какие измерения в течение жизненного цикла ПО Вы знаете?

  30. Дайте определение тестированию(в течении жизненного цикла)

  31. Какие виды тестирования существуют?

  32. Объясните взаимосвязь между прослеживаемостью и тестопригодностью.

  33. Какие подходы к разработки ПО Вы знаете?

  34. Дайте определение структурному подходу

  35. Какой основной метод моделирования применяется при структурном подходе к разработке?

  36. Дайте определение объектно-ориентированному подходу.

  37. Каковы основные причины сдвига от структурного подхода к проектированию объектно-ориентированному?

СПИСОК ЛИТЕРАТУРЫ:

  1. Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2;

  2. Steve McConnell. Rapid Development;

  3. Кобёрн А. Современные методы описания функциональных требований к системам. — М.: Лори, 2002. — ISBN 0-201-70225-8, ISBN 5-85582-152-8;

  4. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. — М.: Вильямс, 2002. — ISBN ISBN 5-8459-0275-4;

  5. Лешек А. Мацяшек. Анализ требований и проектирование систем. – Вильямс, 2002. 432стр.;

  6. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002 г. - 288 с.: ил.;

  7. Фаулер М., Скотт К. UML. Оснвы. – Пер. с англ. – СПб:Символ-Плюс,2002. – 192с.,ил.;

  8. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.:Питер, 2002. — 496 с: ил.;

  9. Г. Буч, Д. Рамбо, А. Джекобсон, Язык UML. Руководство пользователя. Перевод с английского.;

  10. http://ru.wikipedia.org;

  11. www.all-eBooks.com;