Принцип инкапсуляции характеризует сокрытие деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. То есть, взаимодействующему с классом объекту или пользователю не нужно знать, каким образом реализован тот или иной метод класса, чтобы им воспользоваться.
Полиморфизм в объектно-ориентированном программировании означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов они относятся.
1.2 Унифицированный Язык Моделирования
UML (Unified Modeling Language) - Унифицированный Язык Моделирования. UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose 98i.
Так как, в последнее время наблюдается общее повышение интереса ко всем аспектам, связанным с разработкой сложных программных приложений, то для многих организаций корпоративное программное обеспечения и базы данных (БД) представляют стратегическую ценность. Существует высокая заинтересованность в разработке и верификации методов и подходов, позволяющих автоматизировать создание сложных программных информационных систем (ИС). Известно, что систематическое использование таких методов позволяет значительно улучшить качество, сократить стоимость и время поставки ИС. В настоящее время эти методы включают в себя:
- компонентную технологию разработки моделей ИС,
- визуальное программирование (RAD средства),
- использование образцов (patterns) при проектировании ИС,
- визуальное представление различных аспектов проекта (визуальное моделирование, CASE - средства)
Визуальные модели широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации ИС постоянно приходится решать такие задачи как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п.
Построение модели корпоративной ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования "хороших" методов моделирования ИС. Язык моделирования, как правило, включает в себя:
- элементы модели - фундаментальные концепции моделирования и их семантику;
- нотацию - визуальное предоставление элементов моделирования;
- принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.
Построение визуальных моделей позволяет решить сразу несколько типичных проблем. Во-первых, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Визуальное моделирование не является «серебряной пулей», способной раз и навсегда решить все проблемы, однако его использование существенно облегчает достижения таких целей как:
- повышение качества программного продукта,
- сокращение стоимости проекта,
- поставка системы в запланированные сроки.
Рис. 1. Пример диаграммы классов
При проектировании сложной ИС ее разбивают на части, каждая из которых затем рассматривается отдельно. Возможны два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция. Суть функционального разбиения хорошо отражена в известной формуле: “Программа=Данные + Алгоритмы”. При функциональной декомпозиции программной системы ее структура может быть описана блок-схемами, узлы которых представляют собой “обрабатывающие центры” (функции), а связи между узлами описывают движение данных. Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: "разработка, основанная на компонентах" (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на “активные сущности” - объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении “клиент/сервер”. Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения "объекту-серверу" эквивалентна вызову соответствующего метода объекта.
Так вот, если при проектировании информационная система разбивается на объекты (компоненты), то UML может быть использован для ее визуального моделирования. Если используется функциональная декомпозиция ИС, то UML не нужен, и следует использовать другие (структурные) нотации. С точки зрения визуального моделирования, UML можно охарактеризовать следующим образом. UML предоставляет выразительные средства для создания визуальных моделей, которые: единообразно понимаются всеми разработчиками, вовлеченными в проект и являются средством коммуникации в рамках проекта.
Унифицированный Язык Моделирования (UML): не зависит от объектно-ориентированных (ОО) языков программирования, не зависит от используемой методологии разработки проекта, может поддерживать любой ОО язык программирования. UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.
Принципы моделирования. Использование языка UML основывается на следующих общих принципах моделирования:
- абстрагирование - в модель следует включать только те элементы проектируемой системы, которые имеют непосредственное отношение к выполнению ей своих функций или своего целевого предназначения. Другие элементы опускаются, чтобы не усложнять процесс анализа и исследования модели;
- многомодельность - никакая единственная модель не может с достаточной степенью точности описать различные аспекты системы. Допускается описывать систему некоторым числом взаимосвязанных представлений, каждое из которых отражает определенный аспект её поведения или структуры;
- иерархическое построение - при описании системы используются различные уровни абстрагирования и детализации в рамках фиксированных представлений. При этом первое представление системы описывает её в наиболее общих чертах и является представлением концептуального уровня, а последующие уровни раскрывают различные аспекты системы с возрастающей степенью детализации вплоть до физического уровня. Модель физического уровня в языке UML отражает компонентный состав проектируемой системы с точки зрения ее реализации на аппаратурной и программной платформах конкретных производителей.
При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Рассмотрим некоторые диаграммы.
Диаграммы использования. Эти диаграммы описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент - это типичное взаимодействия пользователя с системой, которое при этом:
- описывает видимую пользователем функцию,
- может представлять различные уровни детализации,
- обеспечивает достижение конкретной цели, важной для пользователя.
Рис. 2. Элементы и отношения между ними на диаграмме классов
Прецедент рисуется как овал, связанный с типичными пользователями, называемыми "актерами" (actors). Актеры используют систему (или используются системой) в данном прецеденте. Актер, представляющий человека-пользователя, характеризуется ролью в данном прецеденте. На диаграмме изображается только один актер, однако, реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, с помощью которых может быть сформулировано техническое задание.
Диаграммы классов (class diagrams) описывают статическую структуру классов. Эти диаграммы могут описывать "словарь предметной области" на концептуальном уровне. С другой стороны, на детальном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Они используются для генерации каркасного программного кода на заданном языке программирования, а также для генерации SQL DDL предложений, определяющих логическую структуру реляционных таблиц БД.
Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на диаграммы состояний (statechart diagrams), диаграммы активностей (activity diagrams) и диаграммы взаимодействия (interaction diagrams), состоящие из диаграмм последовательности (sequence diagrams), диаграмм взаимодействий (collaboration diagrams)
И, наконец, диаграммы реализации (implementation diagrams) состоят из компонентных диаграмм· (component diagrams) и диаграмм развертывания· (deployment diagrams). На рисунке 5 показаны элементы и отношения для диаграмм взаимодействий, диаграмм последовательности·и диаграмм состояний.
Рис. 3. Элементы и отношения для диаграмм взаимодействий, последовательности и состояний
Процесс проектирования с использованием той или иной визуальной нотации принято называть методологией проектирования, и все нотации, предшествующие UML, использовались в рамках соответствующей методологии. Методологию трудно стандартизировать, и UML - это только нотация, которая может использоваться в рамках разных методологий. Одной из таких методологий является Rational Unified Process (RUP) - методология фирмы Rational Software. RUP описывает успешно проверенные на практике подходы к созданию ИС и определяет организацию коллективной работы над проектом на основе следующих принципов:
- итерационная разработка проекта,
- управление требованиями,
Страницы: 1, 2, 3, 4, 5
