Сделай Сам Свою Работу на 5

Рекомендации по построению диаграмм классов





 

Процесс разработки диаграммы классов занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы. Как показывает практика ООП, каждый программист в своей работе стремится в той или другой степени использовать уже накоплен личный опыт при разработке новых проектов. Это обусловлено желанием возвести новое задание уже решенным, чтобы иметь возможность использовать не только проверенные фрагменты программного кода, но и отдельные компоненты в целом (библиотеки компонентов).

Такой стереотипный подход позволяет существенно сократить сроки реализации проекта, однако приемлемый лишь в том случае, когда новый проект концептуально и технологически не очень отличается от предыдущих. Иначе платой за сокращение сроков проекта может стать его реализация на устаревшей технологической базе. Что касается собственной объектной структуризации наглядной области, то здесь уместно придерживаться тех рекомендаций, которые накоплены в ООП. Они широко освещены в литературе [1, 2, 4, 10, 13, 18, 20] и потому здесь не рассматриваются.



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

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



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

Больше того, использование CASE -инструментариев для автоматизации ООАП, чаще всего, накладывает свои собственные требования на язык спецификации моделей. Именно по этой причине большинство примеров в литературе даются в англоязычном представлении, а при их переводе на русский может быть потеряна не только точность формулировок, но и семантика соответствующих понятий.

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



 

Архитектура

 

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

Архитектура - это совокупность существенных решений касательно:

· организации программной системы;

· выбору структурных элементов, составляющих систему, и их интерфейсов;

· поведения этих элементов, специфицированного в кооперациях с другими элементами;

· складывание из этих структурных и поведенческих элементов все более и более крупных подсистем;

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

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

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

 

Рис. 1.6 Моделирование системной архитектуры

 

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

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

Вид с точки зрения процессов (Process view) охватывает нити и процессы, которые формируют механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статичные и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особенное внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.

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

Вид с точки зрения развертывания (Deployment view) охватывает узлы, которые формируют топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, снабжением и установкой частей, составляющих физическую систему. Его статичные аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий.

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

 

 








Не нашли, что искали? Воспользуйтесь поиском по сайту:



©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.