
- •Тема 1. Проектирование ис
- •Этапы развития ис
- •1.2. Классификация рынка современных ис
- •1.3. Проектирование ис как формализационный процесс
- •Вопросы.
- •Этапы развития ис.
- •Понятие программной инженерии и этапы ее развития.
- •Тема 2. Понятие жц по
- •2.1. Понятие жц по. Процессы жц по
- •2.1.1. Основные процессы
- •2.1.2. Вспомогательные процессы
- •2.1.3. Организационные процессы
- •2.1.4. Взаимосвязь между процессами
- •2.2. Модели и стадии жц по
- •Вопросы
- •Тема 3. Организация разработки по ис
- •3.1. Внутренняя и внешняя деятельность
- •3.2. Четыре фазы разработки по ис (во внешней деятельности)
- •3.3. Задачи разработки по ис
- •Вопросы для самоконтроля
- •Тема 4. Внутренняя (мыслительная) деятельность
- •4.1. Компетенция инженера
- •4.2. Состав, сложность задач проблемы и компетентность инженера
- •4.3. Связь понятия компетенция и умение
- •Вопросы для самоконтроля
- •Тема 5. Структурный подход к проектированию
- •5.1. Сущность структурного подхода
- •5.1.1 Подход к решению проблемы сложности больших систем
- •5.1.2. Структурный подход к разработке по
- •5.2. Методология функционального моделирования idef0
- •5.2.1. Сущность методологии idefo
- •5.2.2. Синтаксис и семантика моделей idefo
- •5.2.3. Типы связей между функциями
- •5.2.4. Построение моделей idef0
- •5.3. Методология описания бизнес-процессов idef3
- •5.3.1. Сущность методологии idef3
- •5.3.2. Синтаксис и семантика моделей idef3
- •5.3.3. Требования 1def3 к описанию бизнес-процессов
- •5.4. Взаимосвязь моделей idefo и idef3
- •5.5.Структурный анализ потоков данных
- •5.5.1.Сущность структурного анализа потоков данных
- •5.5.2. Синтаксис и семантика диаграмм потоков данных
- •5.5.3. Построение диаграмм потоков данных
- •5.6. Сравнительный анализ idefo-моделей и диаграмм потоков данных
- •5.7. Рекомендации по применению методологий функционального моделирования
- •5.8. Моделирование данных
- •5.8.1. Основные понятия
- •5.8.2. Основы методологии idef1x
- •Вопросы для самоконтроля
- •Тема 6. Объектно-ориентированный подход к проектированию
- •6.1.Сущность объектно-ориентированного подхода
- •6.2. Диаграммы uml
- •6.3. Синтаксис и семантика основных объектов uml
- •6.3.1. Диаграммы прецедентов
- •6.3.2. Диаграммы классов
- •6.3.3. Диаграммы последовательностей
- •6.3.4. Диаграммы коммуникаций
- •6.3.5. Диаграммы состояний
- •6.3.6. Диаграммы деятельности
- •6.3.7. Диаграммы компонентов
- •6.3.8. Диаграммы развертывания
- •6.4. Рекомендации по применению uml
- •Вопросы для самоконтроля
- •Тема 7. Проектирование бд
- •7.1. Особенности проектирования хранилищ данных
- •7.2. Особенности проектирования клиент-серверных ис
- •7.3.Интерфейсы доступа к бд
- •7.3.1. Odbc - открытый интерфейс доступа к бд
- •7.3.2.Объектная модель ole db
- •7.4. Классы бд
- •7.4.1. Документографические и документальные бд
- •7.4.2. Бд о продукции
- •7.4.3. Бд экономической и конъюнктурной информации
- •7.4.4.Фактографические базы социальных данных
- •7.4.5. Бд транспортных систем страны
- •7.4.6. Справочные базы для населения и организаций
- •7.4.7. Ресурсные бд
- •7.4.8. Фактографические базы научных данных
- •7.4.9. Фактографические бд в области культуры и искусства
- •7.4.10. Лингвистические бд
- •Вопросы для самоконтроля
6.3.2. Диаграммы классов
Классы – это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами - атрибутами, операциями, отношениями и семантикой.
В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если в начале имени добавляется имя пакета, куда входит класс (используется составное имя), то имя класса должно быть уникальным в пакете.
Атрибут класса – это свойство класса, которое может принимать множество значений. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов.
Объект – экземпляр некоторого класса.
Операция – реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.
На рис. 6.3 приведено графическое изображение класса «Заказ» в нотации UML.
Рис. 6.3. Изображение класса в UML
Синтаксис UML для атрибутов классов может быть следующий: <признак видимости> <имя атрибутах [кратность атрибута]> :
<тип> = <значение по умолчанию>
Синтаксис UML для операций классов может быть следующий: <признак видимости> <имя операции> (<список аргументов>):
<тип возвращаемого значения>
Некоторые синтаксические единицы могут отсутствовать. В отдельных программных средствах, поддерживающих UML, порядок записи параметров может быть иным.
Признак видимости указывает на возможность использования атрибута или операции другими классами. В языке UML определены три уровня видимости:
public (общий) - любой внешний класс, который «видит» данный класс, может пользоваться его общими свойствами (обозначение - символ «+» перед именем атрибута или операции);
protected (защищенный) - только любой потомок данного класса может пользоваться его защищенными свойствами (обозначение - символ «#» перед именем атрибута или операции);
private (закрытый) - только данный класс может пользоваться этими свойствами (обозначение - символ «-» перед именем атрибута или операции).
Кратность атрибута означает количество объектов заданного типа, которые могут заполнять данный атрибут. Чаще всего используются следующие кратности атрибута:
1 - один объект;
0.. 1 - один или ни одного объекта;
*– количество объектов не ограничено.
Например, на рис. 6.4 изображен класс «Клиент». Атрибуты «Имя» и «Адрес» могут быть заполнены одним объектом string, а атрибут «Заказы» может быть заполнен неограниченным числом объектов «Заказ», т.е. клиент может сделать сколько угодно заказов. Если кратность атрибута не указана, то по умолчанию подразумевается кратность «1».
Рис. 6.4. Кратность атрибутов класса
Классы в UML изображаются на диаграммах классов. Данные диаграммы позволяют описать систему в статическом состоянии, т.е. позволяют определить классы системы и различные отношения между ними.
На рис. 6.4 представлена диаграмма классов, на которой определены два отношения: обобщение и ассоциация.
Обобщение - это отношение между общей сущностью (родителем) и ее конкретным воплощением (потомком). На диаграмме, представленной на рис.6.5, родителем является класс «Клиент», а потомками данного класса являются классы «Корпоративный клиент» и «Частный клиент».
При выполнении отношения «обобщение» объекты класса-потомка наследуют атрибуты и операции класса родителя. Наследование - это правило, согласно которому один объект может приобретать свойства другого.
Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя, это свойство называют полиморфизмом.
Класс, у которого нет родителей, но есть потомки, называется корневым классом. Класс, у которого нет потомков, называется листовым классом.
Ассоциация - это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа, например, «Клиент» может сделать «Заказ» (см. рис. 6.5).
Рис. 6.5. Диаграмма классов
Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рис. 6.6). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.
Рис. 6.6 иллюстрирует модель формирования заказа. Каждый заказ может быть создан единственным клиентом (множественность роли 1).
Рис.6.6. Двунаправленная ассоциация
Каждый клиент может сделать сколько угодно заказов (множественность роли*).
Отметим, что структура классов на рис.6.6 аналогична структуре на рис. 6.4. Однако, диаграмма классов, использующая ассоциации, более наглядна.
Ассоциация на рис.6.6 является двунаправленной. Такая ассоциация показывает, что пара атрибутов связана в противоположных направлениях. В рассмотренном примере класс «Клиент» имеет атрибут «Заказы[*]:3аказ», а класс «Заказ» имеет атрибут «Заказчик[1]:Клиент». Такое же обозначение ассоциации используется в том случае, когда направление не учитывается.
Если требуется подчеркнуть направление ассоциации, то конец линии на стороне класса, являющегося типом атрибута, отмечается стрелкой. Таким образом, для обозначения двунаправленной ассоциации можно использовать линию со стрелками на обеих концах.
Ассоциация может быть однонаправленной. Например, если в классе «Клиент» убрать атрибут «Заказы[*]:3аказ», то ассоциация между классами «Клиент» и «Заказ» будет изображена стрелкой, направленной от класса «Заказ» к классу «Клиент» (рис. 6.7).
Рис.6.7. Представление атрибута в виде ассоциации
Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса.
Диаграммы классов описывают структуру ПО и составляют фундамент UML. Однако нельзя сосредотачиваться исключительно на диаграммах классов. Помня о структуре, не следует забыть о поведении. Поэтому диаграммы классов используются совместно с различными диаграммами поведения. Далее будут рассмотрены следующие диаграммы поведения: последовательностей, коммуникаций, состояний, деятельности.