Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
otvety_k_ekzamenu_po_IT_2010.doc
Скачиваний:
5
Добавлен:
26.09.2019
Размер:
699.9 Кб
Скачать
  1. Сущность и принципы объектно-ориентированного подхода (ооп). Отличие от структурного подхода. Концептуальная основа ооп. Основные понятия. Конечный результат.

  1. Унифицированный язык моделирования uml. Цели разработки языка. Содержание стандарта uml версии l.1, принятый в 1997 г

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт (общедоступная и не секретная техническая спецификация, у которой либо отсутствует правообладатель (общественное достояние), либо же правообладателем является общественная организация, не совпадающая тождественно с производителем, использующим спецификацию в своих продуктах), использующий графические обозначения для создания абстрактной модели (отражающей лишь самые общие характеристики моделируемого явления) системы, называемой UML моделью.

Цель разработки

UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация. Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение, и больше сконцентрироваться на проектировании и архитектуре.

  • UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;

  • UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

  • Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

  • UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

  • UML получил широкое распространение и динамично развивается.

В UML используются следующие виды диаграмм:

  • Use case diagram (диаграммы прецедентов);

  • Deployment diagram (диаграммы топологии);

  • Statechart diagram (диаграммы состояний);

  • Activity diagram (диаграммы активности);

  • Interaction diagram (диаграммы взаимодействия);

  • Sequence diagram (диаграммы последовательностей действий);

  • Collaboration diagram (диаграммы сотрудничества);

  • Class diagram (диаграммы классов);

  • Component diagram (диаграммы компонент).

  1. Диаграммы вариантов использования. Назначение, компоненты. Типы действующих лиц. Типы связей.

    Для того, чтобы более точно понять как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты). Варианты использования это - описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. Варианты использования отражают функциональность системы с точки зрения получения значимого результата для пользователя, поэтому они точнее позволяют ранжировать функции по значимости получаемого результата.

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

Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что пользователи ждут от системы?" задавать вопрос "что система должна сделать для конкретного пользователя?"