Некоторые правила выявления классов

Ниже приведен перечень руководящих принципов или правил, ко­торым должен следовать аналитик при выборе потенциальных классов.

1. Для каждого класса должно быть ясно сформулировано его назначение в системе.

2. Каждый класс - это шаблон описания множества объектов. Единичные классы, для которых можно представить существование только одного объекта, весьма маловероятны среди "бизнес-объектов". Подобные классы обычно составляют в приложении "общее знание" и как правило жестко запрограммированы в программах приложения. Например, если система спроектирована для единст­венной организации, существование класса Organization (Организация) мо­жет быть не оправданно.

3. Каждый класс (т.е. класс-сущность) должен содержать набор атрибутов. Хоро­шим приемом является установление идентифицирующих атрибутов (ключей), чтобы помочь нам судить о мощности (cardinality) класса (т.е. ожидаемом коли­честве объектов данного класса в базе данных). Следует, однако, помнить о том, что класс не обязательно должен обладать пользовательским ключом. Объекты классов идентифицируются с помощью идентификаторов объектов (OID) .

4. Каждый класс должен отличаться от атрибута. Представляется ли понятие классом или атрибутом зависит от области приложения. Цвет автомобиля обычно воспринимается как атрибут класса Саг (Автомобиль). Однако на фаб­рике по производству красок Color (Цвет) - это определенно класс со своими собственными атрибутами (яркостью, насыщенностью, прозрачностью и т.д.).

Задание: Выполнить спецификацию требований проекта. Выполнить прототипирование и разработку приложений проекта.

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

Контрольные вопросы:

1. Какие принципы установления требований?

2. Что такое доминантный класс?

3. Что такое отношение соединения?

4. Объясните, в чем заключаются основные различия четырех подходов к выявлению классов.

5. В чем заключается сущность подхода на основе использования общих шаблонов классов?

Лабораторная работа № 3

Тема: Системное проектирование. Проектирование баз данных.

Цель: Приобретение практических навыков системного проектирования и проектирования баз данных

Краткие теоретические сведения

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

Архитектура программного обеспечения

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

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

Описание системы в терминах ее модулей называется архитектурным проектирова­нием (architectural design). Архитектурный проект включает выбор стратегии решений в отношении клиентской и серверной компонент системы.

Описание внутренних функций каждого модуля (прецедента) называется детализированным проектированием (detailed design). Детализированный проект направ­лен на разработку завершенных алгоритмов и структур данных для каждого модуля. Эти алгоритмы и структуры данных приспосабливаются ко всем (усиливающим и на­вязываемым) ограничениям базовой платформы реализации.