31. Технологии проектирования программного обеспечения аис (структурный и объектно-ориентированный подходы).

Общие принципы проектирования программной системы, проистекающие из структурного подхода:

- принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

- принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

- принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

- принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.

Проект информационной системы в рамках структурного подхода должен быть представлен:

1. В виде декомпозиции небольших подсистем, каждую из которых можно разрабатывать независимо от других, в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами SADT (Structured Analysis and Design Technique) модели и соответствующими функциональными диаграммами.

2. DFD (Data Flow Diagrams) диаграмма потоков данных позволяет достигнуть и проиллюстрировать, что количество связей между отдельными подсистемами минимизировано (принцип «слабой связанности» (Low Coupling), а связность отдельных частей внутри каждой подсистемы максимальна (принцип «сильного сцепления» (High Cohesion).

3. Каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами. Выделение интерфейсов позволяет строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство. Структура системы должна быть такой, чтобы взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки, показываемые на ERD (Entity-Relationship Diagrams) диаграмме "сущность-связь".

4. Каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем). Инкапсуляция (принцип «черного ящика») позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Для каждой подсистемы диаграммы, отражающие структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм, разрабатываются независимо.

Объектно-ориентированное проектирование является надстройкой над структурным проектированием и обеспечивает построение объектной модели разрабатываемой системы, процесс декомпозиции и приёмы представления логической и физической, а так же статической и динамической составляющих проектируемой системы. Объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Объектно-ориентированный подход применить можно, когда в предметной области можно выделить классы и объекты.

В современных программах стараются брать из предметной области вовлечённые в них объекты. Объекты, которые, взаимодействуя друг с другом, участвуют в бизнес-процессах, можно разбить на большое количество категорий, основными из которых являются (с примерами в области экономики и управления):

- информация, характеризующая прикладную задачу в целом. Наиболее простой пример подобной информации - название организации и элементов её внутренней структуры и внешней среды, различных федеральных, региональных и муниципальных органов, которые, как правило, не меняются.

- постоянная и условно-постоянная информация с некоторым множеством значений, хранимых в картотеках. Например, сведения о заказчиках и конечных пользователях, сотрудниках организации, собственниках и/или инвесторах, поставщиках и партнерах.

- бумажные документы и журналы с информацией о совершаемых хозяйственных операциях, являющихся основаниями для тех или иных учетных действий или расчетов. Например, финансовые документе, документы маркетинга и анализа рынка; документы стратегического планирования деятельности предприятия; документы стратегического и оперативного управления; документы производства и поставки продукции; документы закупки материалов и комплектующих; документы технического обслуживания и ремонта оборудования; документы учета кадров и управления персоналом, и так далее.

- отчеты для получения сводной информации на основании данных, введенных в системе (например, отчеты по остаткам и продажам товаров) и другие объекты.

Применение объектно-ориентированного подхода необходимо для сложной системы, когда: она состоит из иерархически вложенных подсистем (иногда нескольких уровней); выбор элементарных подсистем остаётся на усмотрение разработчика; внутренние связи между составляющими элементами одной подсистемы сильнее, чем связи между подсистемами более высокого, более абстрактного уровня; подобно конструктору, существует небольшое количество базовых подсистем, по-разному скомбинированных и организованных между собой; имеется работающая более простая система. Сложная система, спроектированная «с нуля» никогда не заработает. Следует начинать с работающей более простой системы.

Нотация рациональных унифицированных процессов (RUP) фирмы IBM охватывает объектно-ориентированную разработку программного обеспечения, начиная с анализа и заканчивая внедрением продукта. Основные принципы RUP:

1. Управляемая итеративная разработка (CID). RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре фазы (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание).

2. Принцип управления требованиями. Требование — это условие или характеристика, которой должна удовлетворять система. Функциональные требования определяют действия, которые должна выполнять система. Нефункциональные требования (ограничения) — к применению, к производительности, к реализации, к надежности и интерфейсу.

3. Принцип компонентной архитектуры. Компонентная архитектура RUP является результатом анализа и проектирования. Ее назначение — трансформация требований в системный проект, создание стабильной архитектуры системы, адаптация системного проекта к среде реализации, отображение проектной модели в модель данных при проектировании баз данных, идентификация компонентов, подсистем и интерфейсов.

4. Принцип визуального моделирования. В RUP используются следующие виды моделей UML: Проектная модель (Design model), модель процессов (Process model), модель размещения (Deployment model).

5. Принцип проверки качества. Оценка уровня качества продукта выполняется при тестировании. Она включает в себя проверку взаимодействий между объектами и компонентами, проверку корректности интеграции всех компонент системы, проверку корректности реализации всех требований к системе, выявление всех дефектов до внедрения программного обеспечения.

6. Унифицированное управление изменениями (UCM). Контроль изменений требований в рамках управления проектом предполагает, что все запросы на изменения должны проходить через установленный процесс утверждения, своего рода алгоритм, в соответствии с которым взаимодействуют друг с другом клиенты, маркетологи, кодировщики, тестировщики и пользователи.

Проект информационной системы в рамках объектно-ориентированного подхода должен быть представлен с использованием диаграмм UML (универсального языка моделирования): диаграммы сценариев; диаграммы классов; диаграммы последовательностей; диаграммы взаимодействия; диаграммы состояний и активности; диаграммы компонентов; диаграммы топологии (развертывания системы).

Диаграммы сценариев показывают желаемое поведение системы с точки зрения взаимодействия с ней внешних объектов (актеров), как видится внешнее взаимодействие с ней и какие наиболее важные требования к взаимодействию существуют.

Диаграммы последовательностей используются для точного определения логики сценария (как работают объекты).

Диаграммы взаимодействия - подразумевают основные ассоциации между объектами, поток сообщений информационного обмена в объектно-ориентированном приложении.

Диаграммы состояний описывают изменения атрибутов объектов в терминах состояний и бизнес-правил перехода от одного состояния к другому.

Диаграммы классов - это набор статических, декларативных элементов модели, таких как классы, интерфейсы и их отношения. Диаграммы могут организовываться в модули (packages), в котором они логически собраны.

Диаграммы компонентов показывает программные компоненты, которые и составляют повторно используемые части программного обеспечения, их интерфейсы и их внутренние отношения.

Диаграммы топологии показывают конфигурацию выполняющих блоков или частей системы, включая аппаратное и программное обеспечение, которое на них выполняется.