- •Методы и средства проектирования информационных систем
- •Предисловие
- •1. Теоретические основы систем управления
- •1.1. Основные понятия
- •1.2. Классификация систем
- •1.3. Структура системы управления
- •2. Основы создания информационной системы предприятия
- •2.1. Методологии и средства разработки ис
- •2.2. Жизненный цикл ис
- •2.3. Структурный анализ
- •3. Разработка консалтинговых проектов
- •3. 1. Цели и основные этапы разработки консалтинговых проектов
- •3.2. Проведение обследования деятельности предприятия
- •3.2.1. Методика и этапы обследования
- •3.2.2. Организация сбора и первичной обработки данных
- •3.3. Построение моделей
- •3.4. Разработка системного проекта
- •3.5. Разработка предложений по автоматизации
- •3.6. Техническое проектирование
- •4. Структурные методы моделирования систем управления
- •4.1. Методология функционального моделирования idef0 (sadt)
- •4.1.1. Sadt-модели
- •4.1.2. Синтаксис и применение диаграмм
- •4.1.3. Синтаксис моделей и работа с ними
- •4.1.4. Процесс моделирования
- •4.2. Методология построения реляционных структур idef1x.
- •4.3. Диаграммы потоков данных (Data Flow Diagramming)
- •4.4. Метод описания процессов idef3
- •4.5. Описание нотации aris eEpc.
- •5. Анализ и реорганизация бизнес-процессов
- •5.2. Анализ структуры процессов в соответствии с iso 9000 - стандартом на качество проектирования, разработки, изготовления и послепродажного обслуживания
- •5.4. Ключевые моменты реорганизации деятельности предприятия
- •6. Создание модели процессов в bPwin
- •6.1. Инструментальная среда bPwin
- •6.2. Каркас диаграммы
- •6.3. Слияние и расщепление моделей
- •6.4. Создание отчетов в bPwin
- •6.5. Стоимостной анализ и свойства, определяемые пользователем
- •6.6. Диаграммы dfd и Workflow (idef3)
- •7. Создание модели данных с помощью eRwin
- •7.1. Отображение модели данных в eRwin
- •7.1.1. Физическая и логическая модели данных
- •7.1.2. Подмножества модели и сохраняемые отображения
- •7.2. Создание логической модели данных
- •7.2.1. Уровни логической модели
- •7.2.2. Сущности и атрибуты
- •7.2.3. Связи
- •7.2.4. Типы сущностей и иерархия наследования
- •7.2.5. Ключи
- •7.2.6. Домены
- •7.3. Создание физической модели данных
- •7.3.1. Уровни физической модели
- •7.3.2. Выбор сервера
- •7.3.3. Таблицы, колонки и представления (view)
- •7.3.4. Правила валидации и значения по умолчанию
- •7.3.5. Индексы
- •7.3.6. Задание объектов физической памяти
- •7.3.7. Триггеры и хранимые процедуры
- •7.3.8. Проектирование хранилищ данных
- •7.3.9. Вычисление размера бд
- •7.3.10. Прямое и обратное проектирование
- •8. Объектно-ориентированный подход
- •8.1. Основные принципы
- •8.3. Обзор диаграммных техник uml
- •8.4. Пакеты как средство работы с большими проектами
- •8.5. Диаграммы классов и объектов
- •8.5.1. Классы
- •8.5.2. Интерфейсы
- •8.5.3 Отношения между классами
- •8.5.4 Пример диаграммы классов
- •8.6. Диаграммы использования
- •8.7. Диаграммы последовательностей
- •8.8. Диаграммы сотрудничества
- •8.9. Диаграммы состояний
- •8.10. Диаграммы действий
- •8.11. Диаграммы реализации
- •9. Унифицированный процесс разработки и uml
- •9.2. Фазы унифицированного процесса и диаграммы uml
- •10. Объектно-ориентированное case средство Rational Rose
- •10.1. Состав и основные возможности
- •10.2. Этапы проектирования
- •Литература
- •Содержание.
8.4. Пакеты как средство работы с большими проектами
Пакеты представляют собой универсальное средство для группирования элементов моделей. Пакеты могут вкладываться друг в друга и могут содержать пакеты или элементы моделей. Проект в целом может рассматриваться как один пакет верхнего уровня, в который вложены все остальные составляющие части проекта. Пакет может иметь два графических обозначения: полное и сокращенное. Сокращенное обозначение пакета предназначено для обозначения пакета, входящего в состав другого пакета (рис. 31):
Рис. 31. Обозначение пакета
П олное обозначение пакета предназначено для представления этого пакета как такового (рис. 32):
Рис. 32. Полное обозначение пакета
В рамке “содержимое пакета” находится графическое изображение, представляющее другие пакеты или модели. Отношения между пакетами отображаются линиями и обозначают отношения между элементами пакета. Если разные элементы двух пакетов имеют разные отношения друг с другом, то нет четких рекомендаций, какие отношения показывать между самими пакетами. Таким образом, наличие отношения Х между двумя пакетами говорит только о том, что в пакетах присутствуют элементы, связанные между собой этим отношением.
Пакеты обеспечивают более высокий уровень абстракции по сравнению с классами. Типичный большой проект содержит несколько иерархий наследования для классов. Возьмем в качестве примера многооконный графический редактор диаграмм. Набор пакетов для этой задачи можно представить следующим образом (рис. 33):
Рис. 33. Набор пакетов проекта "графический редактор"
Пакет “геометрические фигуры” содержит определение иерархии наследования для классов всех геометрических фигур. Эти классы должны быть независимы от контекста, в который они включаются (например, диаграмма), а так же от устройства, на котором они отображаются. Базовый класс этого пакета может выглядеть так, как показано на рис. 36.
Пакет “графические диаграммы” содержит определение всех классов для диаграмм. Например, все диаграммы, рассматриваемые здесь, могут быть представлены в этом пакете. Диаграмма не должна зависеть от способа создания (например, она может быть создана не в диаграммере, а автоматически). Тем более диаграмма не должна зависеть от устройства отображения.
Пакет “диаграммер” отвечает за отображение диаграмм в некотором контексте и за ввод этих диаграмм с помощью некоторых виртуальных команд пользователя, не зависимых от контекста отображения.
Пакет “устройство отображения диаграмм” содержит классы, описывающие однооконный интерфейс конкретного диаграммера и способ создания виртуальных команд пользователя с помощью конкретных устройств ввода (например, мыши и клавиатуры).
Пакет “IDE” содержит средства, необходимые для включения одного диаграммера в интегрированную среду разработки с меню, карточками диалога, настройками параметров среды, многооконным интерфейсом.
Достоинства использования пакетов:
декомпозиция задачи упрощает понимание каждой части в отдельности и задачи в целом;
каждый пакет можно поручить отдельному разработчику за счет относительной независимости пакетов.
Все проектирование объектно-ориентированной системы должно начинаться именно с проектирования пакетов. Они позволят избежать лишних ошибок, проект станет более управляемым и обозримым. Можно сформулировать следующие рекомендации по составлению пакетов и классов в них:
каждый пакет должен быть максимально независимым от других пакетов, все связи должны быть локализованы и сведены к минимуму, идеальный случай - связь через один класс, из которого используется один метод поведения;
структура пакетов должна отражать структуру предметной области, это обеспечит возможность проектирования классов в четком соответствии с предметной областью и в дальнейшем позволит легко модифицировать систему для других задач в рамках данной предметной области;
каждый пакет должен содержать классы, однотипные с точки зрения предметной области;
желательно, что бы иерархия наследования начиналась с одного базового объекта в каждом пакете, допустимо два, три, но не более;
базовый объект в каждом пакете - это следующий принципиальный момент после составления самих пакетов; он должен отражать наиболее базовые свойства той части предметной области, к которой относится пакет.