Основные пути использования UML
Эскизы
Главное преимущество рисования эскизов – их выборочность. Рисуя эскизы, можно набрасывать условно некоторые проблемы кода, который будет создан, обычно после обсуждения их с группой людей в команде. Главная цель состоит,
с одной стороны в том, чтобы, используя эскизы, донести до своих коллег идеи и альтернативы того, что планируется сделать, с другой стороны – более полно понять проблемную область.
При этом нет смысла говорить о сотнях или тысячах строках кода, которые будут созданы или модифицированы. Концентрация осуществляется на ключевых, концептуальных проблемах. Визуализировав их, прежде чем начнется программирование, можно избежать многих часов бессмысленного кодирования.
Проектная модель
Идея заключается в том, что проект разработан проектировщиком или командой проектировщиков, которые должны сделать его настолько детально, что он будет понятен для программиста, который будет кодировать его. Такой проект должен быть настолько полон и детален, что гарантирует реализацию всех проектных решений программистами без дополнительного осмысления или обсуждения. Т.е. для программиста это выглядит как детальное руководство. В реальной ситуации правильный подход опытных дизайнеров – разработать на уровне модели проекта общие интерфейсы систем, оставив программистам возможность решать детали реализации этих систем.
UML как программный язык
Дизайнеры рисуют диаграммы UML, которые затем компилируются непосредственно в исполняемый код. Таким образом UML становится исходным кодом программы. Само создание инструментов, реализующих этот подход, требует немалых усилий.
Нотации и метамодель
Нотация – совокупность графических объектов, которые используются
в моделях. В качестве примера на диаграмме показано, как в нотации диаграммы класса определяются понятия и предметы типа «класс», «ассоциацция», «множественность» и т.д.
Нотация диаграммы классов определяет способ представления класса, ассоциации, множественности. Причем эти понятия должны быть точно определены.
Проектирование подразумевает всесторонний анализ всех ключевых вопросов разработки. И строгое определение всех понятий может не позволить описать реальные требования системы.
Большинство объектно-ориентированных методов является не слишком строгими. Их нотация прибегает в большей степени к интуиции, чем к формальному определению.
Метамодель – диаграмма, определяющая нотацию.
Метамодель помогает понять, что такое хорошо организованная, т.е. синтаксически правильная, модель.
Уровень владения и понимания языка моделирования зависит от задач, которые решаются с его помощью. В основном диаграммы используются как средства обмена информации между разработчиками.
| Feature |
| Structural Feature |
| Behavioral |
| Feature |
| Parameter |
| * {ordered} |
| 0..1 |
Если не придерживаться согласованного понимания, то другие разработчики просто не поймут, что вы хотели выразить своей диаграммой.
Рис. 1. Нотации и метамодель
· Activity – процедурное и параллельное поведение. Введено в UML 1;
· Class – классы, свойства и взаимоотношения. Введено в UML 1;
· Communication – взаимодействие между объектаими; акцент на связи.
В UML 1 называлась Сollaboration diagram;
· Component – структрура и связи компонентов. Введено в UML 1;
· Composite structure – декомпозиция класса во время выполнения. Новая
в UML 2;
· Deployment – размещение артефактов. Введено в UML 1;
· Interaction overview – смешение Sequence и Activity. Новая в UML 2;
· Object – пример конфигурации экземпляров. Неофициальная в UML 1;
· Package – иерархическая структура во время компиляции. Неофициальная в UML 1;
· Sequence – взаимодействие между объектами. Акцент на последовательности. Введено в UML 1;
· State machine – способы изменения объекта различными событиями
в течение его жизненного цикла. Введено в UML 1;
· Timing – взаимодействие между объектами. Акцент на распределении во времени. Новая в UML 2;
· Use case – способы взаимодействия пользователей с системой. Введено
в UML 1.
| Diagram |
| Structural |
| Diagram |
| Behavior Diagrma |
| Class Diagram |
| Composite |
| Structure Diagram |
| Object Diagram |
| Component |
| Diagram |
| Deployment |
| Diagram |
| Package Diagram |
| Activity Diagram |
| Use Case |
| Diagram |
| State Machine |
| Interaction |
| Diagram |
| Sequence |
| Diagram |
| Communication |
| Diagram |
| Interaction |
| Overview |
| Diagram |
| Timing Diagram |
Рис. 2. Диаграммы UML
Основные понятия
К основным понятиям UML относятся:
· Сущности – абстракции, являющиеся основными элементами модели;
· Отношения – связывают различные сущности;
· Диаграммы – группируют представляющие интерес совокупности сущностей.
Сущности
· структурные – статические части модели, соответствующие концептуальным или физическим элементам модели;
· поведенческие – динамические составляющие, описывающие поведение модели во времени и в пространстве;
· группирующие;
· аннотационные.
Структурные сущности
Класс (Class) – описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Реализует несколько интерфейсов.
Интерфейс (Interface) – совокупность операций, которые определяют набор услуг, предоставляемых классом или компонентом. Описывает видимое извне поведение элементов.
Кооперация (Collaboration)– совокупность операций, которые производят некоторый общий эффект, не сводящийся к простой сумме слагаемых.
Вариант использования (Use сase) – описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-либо определенного действующего лица (Actor).
Активный класс (Active class) – класс, объекты которого вовлечены в один или несколько процессов и могут инициировать управляющее воздействие.
Компонент (Component) – физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию.
Узел (Node) – элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс.
Поведенческие сущности
Взаимодействие (Interaction) – поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенных целей.
Автомат (State machine) – поведение, определяющее последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакция на эти события.
Правильный UML
Правильный UML – хорошо форматированный в соответствии со спецификацией UML. Однако всё находится в реальном мире и всё не так просто. Каким языком считать UML? Предписывающим, как языки программирования, или описательным? Сложившееся понимание в ИТ индустрии на данный момент – рассматривать UML как описательный язык. И в этом случае, всё, что считается правильным в разрабатываемом конкретной группой программистов проекте, и есть правильный UML. Формально можно написать персональную метамодель, и тогда мы получим новый, абсолютно формально правильный UML. Нужны ли такие усилия?
Другой важный момент, UML обеспечивает весьма значительное количество различных диаграмм, тем не менее этот список не должен рассматриваться как конечный набор, который можно использовать. Весьма часто есть необходимость изобразить нечто, для чего нет формального типа диаграммы. В этой ситуации используйте подходящую не-UML диаграмму.
Диаграммы, которые ниже будут рассмотрены с разной степенью детализации:
• диаграмма классов;
• диаграмма последовательности действий;
• диаграмма объектов;
• диаграмма пакетов;
• диаграмма Use cases;
• диаграмма активностей.
Диаграмма классов
Это главная диаграмма, с которой работает программист. Она описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними. Также здесь показываются свойства и операторы класса
и ограничения, которые накладываются на способ, которым они связаны. UML использует термин «свойство» как общий термин для свойств и операторов (методов) класса. Следует различать свойства как поднабор операторов следующих контракту Java Beans – get<Имясвойства>, set<Имясвойства>.
Рис. 3. «Свойства» классов
Свойства
Свойствапредставляют собой структурные особенности класса. В первом приближении можно думать о свойствах как о полях в классе. Действительность подправит понимание, но это хорошая стартовая точка для начала.
Свойстваотображаются двумя существенно отличающимися нотациями:
в виде атрибута и в виде ассоциации. Они выглядят отличными друг от друга на диаграмме, но в действительности они одно и то же.
Атрибут – нотация, описывающая свойство текстовой строкой внутри изображения класса.
При проектировании системы необходимо не только идентифицировать сущности в виде классов, но и указать, как они соотносятся друг с другом.
Отношение – нотация, описывающая свойство линией, соединяющей классы между собой. В объектно-ориентированном проектировании особое значение имеют четыре типа отношений: зависимости, обобщения, реализации и ассоциации.
Зависимостью (Dependency) называется отношение использования, определяющее, что изменение состояния объекта одного класса может повлиять на объект другого класса, который его использует, причем обратное в общем случае неверно. Зависимости применяются тогда, когда экземпляр одного класса использует экземпляр другого, например, в качестве параметра метода.
Рис. 4. Отношение зависимости
Обобщение (Generalization) означает, что объекты подкласса могут использоваться всюду, где встречаются объекты суперкласса, но не наоборот. Подкласс наследует свойства родителя (атрибуты и методы). Идентификация суперклассов и подклассов осуществляется с использованием модели предметной области.
В итоге улучшается понимание кода (особенно для систем с сотнями классов), уменьшается объем повторяемой информации.
| Payment |
| CashPayment |
| CreditPayment |
| CheckPayment |
Например, понятия CashPayment, CreditPayment, CheckPayment очень похожи, и разумно организовать их в иерархию обобщения, чтобы подчеркнуть специализацию классов. Класс Payment представляет более общее понятие, а его подклассы – специализированные свойства.
Рис. 5. Отношение обобщения
Подкласс создается в случаях, если:
· имеет дополнительные атрибуты;
· имеет дополнительные ассоциации;
· ему соответствует понятие, управляемое, обрабатываемое или используемое способом, отличным от способа, определенного суперклассом или другими подклассами;
· представляет объекту поведение, которое отлично от поведения, определяемого суперклассом или другими подклассами.
Отношение обобщения реализуется при наследовании классов.
| AdminMessage |
| «interface» |
| AbstractMessage |
Реализацией (Realization) называется отношение между классификаторами (классами, интерфейсами), при котором один описывает контракт (интерфейс сущности), а другой гарантирует его выполнение.
Рис. 6. Отношение реализации
Ассоциация (Association) показывает, что объект одного класса связан с объектом другого класса и отражает некоторое отношение между ними. В этом случае можно перемещаться (с помощью вызова методов) от объекта одного класса к объекту другого. Изображается сплошной линией между двумя классами, направленной от исходного класса к целевому классу.
Рис. 7. Отношение ассоциации
Одним из вариантов отношения ассоциации является агрегация.
| Факультет |
| Кафедра |
Агрегация – ассоциация, моделирующая взаимосвязь “часть/целое” между классами, которые в то же время могут быть равноправными. Оба класса при этом находятся на одном концептуальном уровне, и ни один не является более важным, чем другой.
Рис. 8. Отношения коллективной агрегации и композиции
Множественность
| Presentation::EmployeeCustomer |
| - |
| ID: int |
| - |
| pageBean: PageBean |
| «property get» |
| + |
| getPageBean() : PageBean |
| «property set» |
| + |
| setPageBean(PageBean) : void |
| «Event» |
| + |
| validateCard(AbstractCard) : boolean |
| Presentation::PageBean |
| ~ |
| age: int |
| # |
| colorOfHair: int |
| - |
| lastName: String |
| - |
| middleName: String |
| - |
| name: String |
| + |
| weight: int |
| «property get» |
| + |
| getName() : String |
| «property set» |
| + |
| setName(String) : void |
| +pageBean |
В общем случае множественность определяет нижнюю и верхнюю границу количества объектов, которые могут соответсвововать свойствам.
Рис. 9. Множественность
/* пример # 1: множественность отношений между классами :
EmployeeCustomer.java */
public class EmployeeCustomer {
private int ID = 0;
private PageBean pageBean = null;
public int getID() {
return this.ID;
}
public void setID(int newID) {
this.ID = newID;
}
public PageBean getPageBean() {
return this.pageBean;
}
}
| AbstractCard |
| Presentation:: |
| CreditCard |
| Presentation:: |
| Wallet |
| +Owner |
| Owns |
| +Participant |
| 1..* |
Двунаправленная ассоциация
Рис. 11. Двунаправленная ассоциация
/* пример # 2: взаимная видимость классов : Wallet.java, CreditCard.java */
public classWallet {
private List<CreditCard> creditCards = null;
public void addCreditCard(CreditCard newCreditCard) {
creditCards.add(newCreditCard);
}
}
public class CreditCard {
private Wallet wallet = null;
public void setWallet(Wallet newWallet) {
this.wallet = newWallet;
}
}
Операторы
Наиболее очевидный пример оператора – метод класса. То есть операторы можно рассматривать как действия, которые класс знает, как выполнить. Хотя getter и setter для свойства тоже являются методами, как правило, их не указывают на диаграммах, так как их наличие очевидно в соответствии с конкрактом Java Beans. Обычно их указывают на диаграммах в случае несимметричного использования, например, класс может иметь только getter-методы по каким-то специфическим причинам.
При наличии ассоциации между классами объекты одного класса могут «видеть» объекты другого и осуществлять навигацию к ним, если это не запрещено явным указанием односторонней навигации. Навигация осуществляется посредством вызова метода. Вызов метода объектом одного класса с помощью ссылки на другой класс определяет передачу сообщения от первого класса ко второму.
Интерфейсом называется набор операций, которые используются для спецификации услуг, предоставляемых классом или компонентом, причем один класс может реализовать несколько интерфейсов. Перечень всех реализуемых классом интерфейсов образует полную спецификацию поведения класса. Однако в контексте ассоциации с другим целевым классом исходный класс может не раскрывать все свои возможности.
БАЗЫ ДАННЫХ И ЯЗЫК SQL
Каждая область человеческой деятельности нуждается в хранении и обработке сопутствующей информации. Например, библиотека хранит сведения о книжных фондах и параллельно ведет списки читателей. Бухгалтерия оперирует счетами и производит различные операции над ними. Склад ведет учет наличия товаров и отслеживает их движение.
Под базой данных (БД) понимается некий организованный набор информации. В качестве примера простейшей БД можно привести список товаров, каждый из которых обладает набором стандартных характеристик (наименование, единица измерения, количество, цена и т.д.):
| № | Наименование | Ед. изм. | Цена | Кол-во |
| Кирпич | штука | |||
| Краска | литр | |||
| Шифер | лист | |||
| … | … | … | … | … |
| Гвоздь | штука | |||
| Кабель | метр |
Способов организации баз данных великое множество. В недавнем прошлом бумажные листки со списками товаров держали подшитыми в отдельную папку либо раскладывали по ящикам стола в соответствии с некоторыми критериями.
В наше время для подобных целей повсеместно используются компьютеры, что значительно облегчает процесс создания базы данных и дальнейшей работы с ней. Существуют специальные компьютерные программы, позволяющие полностью автоматизировать процесс хранения, получения и модификации данных любого типа и назначения. В общем случае они называются системами управления базами данных (СУБД) и состоят из языковых и программных средств, предназначенных для создания и эксплуатации баз данных. Базовые свойства любой СУБД включают в себя:
- скорость (время доступа к данным);
- разграничение доступа (отдельные категории пользователей имеют доступ только к определенным категориям данных);
- гибкость (возможность формировать и обрабатывать сложные запросы
к данным); - целостность (средства поддержки согласованности взаимосвязанных данных при их изменении);
- отказоустойчивость (средства архивирования и восстановления данных на случай выхода из строя оборудования либо ошибок в программном обеспечении).
Базовые функции СУБД:
- интерпретация запросов пользователя, сформированных на специальном языке (обычно – SQL);
- определение данных (создание и поддержка специальных объектов, хранящих поступающие от пользователя данные, ведение внутреннего реестра объектов и их характеристик – так называемого словаря данных);
- исполнение запросов по выбору, изменению или удалению существующих данных или добавлению новых данных;
- безопасность (контроль запросов пользователя на предмет попытки нарушения правил безопасности и целостности, задаваемых при определении данных);
- производительность (поддержка специальных структур для обеспечения максимально быстрого поиска нужных данных);
- архивирование и восстановление данных.
Реляционные СУБД