- •Разработка и стандартизация программных систем
- •1. Три типа жизненных циклов программных систем.
- •Водопадная (каскадная, последовательная) модель
- •Итерационная модель
- •Спиральная модель
- •3. Стандарт iso серии 9000 при разработке программных систем.
- •Iso 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий.
- •4. Стандарты Единой системы программной документации (еспд)
- •Классификация:
- •5. Стандарты рф (гост р) на документирование пс
- •6. Организация группы проекта при разработке программных систем.
- •7. Три способа определения требований к программной системе.
- •8. Спецификация требований к программной системе.
- •9. Методы контроля спецификации требований.
- •10. Спецификация качества программных систем.
- •11. Функциональная спецификация программных систем.
- •12. Архитектура программных систем
- •13. Основные классы архитектур программных систем.
- •14. Основные модели при разработке программных систем.
- •(См. Вопрос 1!)
- •15. Принципы объектно-ориентированного анализа и проектирования пс
- •16. Принципы компонентной архитектуры информационных систем.
- •17. Стандарты семейства idef
- •18. Принципы построения модели idef0
- •19. Принципы разработки моделей as-is и то-ве
- •20. Диаграммы в стандарте idef0
- •21. Понятие работы в стандарте idef0
- •22. Описание взаимодействия работ в стандарте idef0
- •23. Типы связей работ в стандарте idef0
- •24. Стандарт idef1x
- •26. Диаграммы потоков данных.
- •27. Архитектурные виды программной системы.
- •28. Фазы, итерации и циклы разработки программных систем - руп.
- •29. Рабочие процессы создания программных систем - руп.
- •30. Основные артефакты при разработке программных систем.
- •31. Концепция языка uml
- •32. Язык uml как система визуализации, специфицирования, конструирования, документирования
- •33. Понятия модели и системы в языке uml
- •34. Принципы моделирования системной архитектуры в языке uml.
- •35. Принципы представления системы в языке uml.
- •36. Понятие сущностей в языке uml
- •37. Структурные сущности предметной области.
- •38. Отношения в языке uml
- •39. Диаграммы в языке uml
- •40. Правила языка uml.
- •41. Общие механизмы языка uml
- •42. Прецедент как спецификация поведения программных систем.
- •43. Организация прецедентов в языке uml.
- •44. Приемы анализа прецедентов в языке uml
- •45. Диаграммы прецедентов.
- •46. Моделирование требований к системе с помощью диаграмм прецедентов.
- •47. Критерии сравнения инструментальных систем разработки программных систем.
- •48. Технико-экономические показатели разработки программных средств
- •49. Сертификация программных средств
- •50. R-технология программирования
44. Приемы анализа прецедентов в языке uml
Прецедент (use case) - это спецификация поведения системы или ее части без определения реализации системы.
С помощью прецедентов моделируют поведение элемента: системы в целом, подсистемы или класса. При этом важно сконцентрироваться исключительно на том, что должен делать элемент, а не на том, как он это будет делать.
Подобное применение прецедентов к элементам представляет важность по трем причинам.
Во-первых, моделируя поведение элемента с помощью прецедентов, эксперты в предметной области (системные аналитики) могут описать взгляд на систему извне с такой степенью детализации, что разработчики сумеют сконструировать ее внутреннее представление. Прецеденты дают возможность экспертам, системным аналитикам, конечным пользователям и разработчикам общаться на одном языке.
Во-вторых, прецеденты позволяют разработчикам понять назначение элемента. Система, подсистема или класс могут быть сложными образованьями с большим числом операций и других составных частей. Описав прецеденты элемента, вы поможете их потенциальным пользователям разобраться в том, как с ними обращаться. Иначе им пришлось бы на собственном опыте постигать, как использовать той или иной элемент.
В-третьих, прецеденты являются основой для тестирования каждого элемента на всем протяжении его разработки. Постоянно сравнивая функционирование каждого элемента с прецедентами, можно контролировать корректность его реализации. При этом мы получаем источник тестов и при появлении нового прецедента данного элемента должны проверить реализацию, чтобы убедиться в том, что элемент в достаточной степени изменяем. Если это не так, следует пересмотреть архитектуру.
Моделирование поведения элемента осуществляется следующим образом:
· Идентифицируются актеры, взаимодействующие с данным элементом. К числу кандидатов в актеры относятся группы, которые требуют определенного поведения для выполнения своих задач или необходимы, прямо или косвенно, для выполнения функций элемента.
Актеры конкретизируются путем выделения общих и специализированных ролей.
· Для каждого актера рассматриваются пути его взаимодействия с элементом, а также взаимодействия, изменяющие состояния элемента или его окружения или предполагающие реакцию на некоторое событие.
Рассматриваются альтернативные (исключительные) способы взаимодействия актеров с элементом.
· Организуется выявленное поведение в виде прецедентов, применяя отношения включения и расширения для выделения общего и исключительного поведения.
По мере развития модели обнаруживается тенденция к объединению прецедентов в концептуально и семантически близкие группы. В UML для моделирования таких групп применяются пакеты.
Моделируя прецеденты в UMLдолжен представлять некоторое четко идентифицируемое поведение системы или ее части. Хорошо структурированный прецедент обладает следующими свойствами:
именует простое, идентифицируемое и в некотором смысле атомарное поведение системы или ее части,
выделяет общее поведение, извлекая его из всех прецедентов, которые его включают,
выделяет вариации, помещая некоторое поведение в другие прецеденты, которые его расширяют,
описывает поток событий в степени, достаточной для понимания посторонним читателем,
описывается с помощью минимального набора сценариев, специфицирующих его нормальную и дополнительную семантику.