
- •Введение
- •1.Определение требований к информационной подсистеме
- •Словесное описание содержания бизнес-процесса
- •Выбор метода моделирования информационных процессов в хозяйственной деятельности организации
- •Выбор метода
- •Определение требования к информационной подсистеме
- •Варианты использования проектируемой информационной подсистемы действующими лицами бизнес-процесса
- •Диаграмма деятельности, моделирующая бизнес-процесс
- •2.Разработка проекта информационной подсистемы
- •Спецификации вариантов использования информационной подсистемы
- •2.1.1.Анализ бизнес- процессов
- •2.1.1.1 Концепция функционирования информационной подсистемы
- •2.1.1.2 Бд, используемые информационной подсистемой
- •2.1.1.3 Процедуры обработки сведений в бд
- •Уточнение концепции состава и назначения программных средств и таблиц бд web - сайта авиакомпании
- •Интерфейсы пользователей информационной подсистемы. Запросы пользователей
- •Диаграммы интерфейсных классов, классов управления и сущностей
- •• Ассоциации (например, клиент может сделать заказ);
- •• Подтипы (частный клиент является разновидностью клиента)
- •Ассоциации классов. Диаграммы последовательности и кооперативные
- •Диаграммы ассоциации классов (показаны на Рисунке 2.3.1):
- •Атрибуты и методы классов
- •3.Класс поисковика
- •4.Класс «Начальная страница Web-сайта»
- •5.Класс с sql-операторами
- •Диаграмма развертывания, показывающая состав аппаратного и обеспечивающего по информационной подсистемы
- •6.Заключение
- •Приложение 1 глоссарий проекта
Выбор метода
Существует два основных способа проектирования программных систем – структурное проектирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако эти способы, по сути, ортогональны, поэтому нельзя сконструировать сложную систему одновременно двумя способами. Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения.
Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить некоторые операции.
Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:
Объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств.
Объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируются на устойчивых промежуточных формах. Объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых уже есть уверенность.
Объектная декомпозиция помогает разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.
В объектно-ориентированном анализе существует четыре основных типа моделей: динамическая, статическая, логическая и физическая. Через них можно выразить результаты анализа и проектирования, выполняемые в рамках любого проекта. Эти модели в совокупности семантически достаточно богаты и универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры. Кроме того, эти модели достаточно полны, чтобы служить техническим проектом реализации практически на любом объектно-ориентированном языке программирования.
Фактически все сложные системы можно представить одной и той же канонической формой – в виде двух ортогональных иерархий одной системы: классов и объектов. Каждая иерархия является многоуровневой, причем в ней классы и объекты более высокого уровня построены из более простых. Какой класс или объект выбран в качестве элементарного, зависит от рассматриваемой задачи. Объекты одного уровня имеют четко выраженные связи, особенно это касается компонентов структуры объектов. Внутри любого рассматриваемого уровня находится следующий уровень сложности. Структуры классов и объектов не являются независимыми: каждый элемент структуры объектов представляет специфический экземпляр определенного класса. Объектов в сложной системе обычно гораздо больше, чем классов. С введением структуры классов в ней размещаются общие свойства экземпляров классов.
Для курсового проектирования предпочтительнее использовать объектно-ориентированное проектирование, которое позволяет выделить объекты рассматриваемого бизнес-процесса и детально разобрать их поведение.