7. Структуризація прецедентів проекту за рівнями цілей.

Рівні цілей поділяються на три групи:

• узагальнений рівень;

• рівень цілі користувача;

• рівень окремої функції.

У першій і третій групі виділяються підгрупи. У першій – рівень хмари і рівень повітряного змія, у третій – підводний рівень і рівень дна. У назвах рівнів використовується характерна метафора – море, його поверхня, небо над морем. Ця метафора дозволяє ввести для прецедентів відповідні кольори: білий, блідо-блакитний, яскраво-блакитний, темно-синій і чорний.

Як визначається цілі рівня користувача?

Ціль (прецедент) рівня користувача – це коли відрядна платня користувача як робітника залежить від того, скільки разів ним використовувався відповідний прецедент (використовувалась ціль).

Наприклад, “Реєстрація клієнта” є прецедентом рівня користувача, а от “Уведення пароля” – ні.

Відштовхуючись від прецедентів рівня цілі користувача легко шукати узагальнені прецеденти і прецеденти рівня окремої функції.

Розгляньте будь-який прецедент “А” рівня цілі користувача. Поставте запитання: для чого (why) виконується прецедент “А” ?. Відповідь на це запитання дасть узагальнений прецедент.

Задайте інше питання: як (how) виконується прецедент “А” по кроках? Відповідь на це запитання дасть вам колекцію прецедентів рівня окремої функції.

8. Поняття концептуальної моделі.

Концептуальна модель:

• Це представлення понять в термінах предметної області

• Представляється у вигляді статичних структурних діаграм

• Є найбільш важливим артефактом, що створюється на етапі ОО-аналізу

• Важливою властивістю є представлення понять реального світу, а не програмних компонентів

Концептуальна модель відображає

• Поняття – представлення ідеї чи об’єкта

• Асоціації між поняттями – зв’язок між поняттями, що відображає відношення між ними

• Атрибути понять – абстрактні властивості об’єкта

Концептуальна модель – це не модель структури програми

В концептуальній моделі не використовуються наступні елементи:

• артефакти програмування (наприклад, вікна чи бази даних);

• обов’язки чи методи

9. Особливості використання елементів структурного моделювання при створенні концептуальних моделей.

• Концептуальна модель – це не модель структури програми

• В концептуальній моделі не використовуються наступні елементи:

  • артефакти програмування (наприклад, вікна чи бази даних);

  • обов’язки чи методи

• Поняття - це представлення ідеї чи об’єкта

• Детально розглядається в термінах:

  • символи – слова чи образи, що представляють поняття

  • зміст – визначення поняття

  • розширення – набір прикладів, по відношенню до яких можна використовувати поняття

10. Символ, зміст та розширення концептуального класу.

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

Диаграммы классов обычно содержат следующие сущности:

• классы;

• интерфейсы;

• кооперации;

• отношения зависимости, обобщения и ассоциации.

Подобно всем остальным диаграммам, они могут включать в себя примечания и ограничения.

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

 

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

1)      граничные (boundary)  классы: объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов, упоминавшихся ранее);

2)      сущностные (entity)  классы: объекты этих классов представляют собой блоки длительно хранимой информации, используемые  для организации баз данных и знаний, файловых систем хранения данных различной логической структуры; в основном в этих классах развит атрибутный раздел, однако имеется небольшое число операций контроля ограничений целостности, как стандартных, так и специфичных для данной предметной области;

3)      классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем  и систем управления базами данных (СУБД), таймеры, координаторы и т.п.;

4)      классы прикладной логики (logic): объекты этих классов реализуют основную логику решения задач приложения; обычно это отдельные программные или аппаратные модули, осуществляющие сложные расчеты, решение оптимизационных задач и т.п.

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

Обычно диаграммы классов используются в следующих целях:

• для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов вы можете определить эти абстракции и их обязанности;

• для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, вы не сможете понять происходящие процессы, глядя на один-единственный класс, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;

• для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию (см. главу 23) в реляционной или объектно-ориентированной базе данных. Моделировать схемы также можно с помощью диаграмм классов.

 

Пример диаграммы сущностных классов