«Проектирование информационных систем»

1. Жизненный цикл программного изделия – анализ требований, проектирование, программирование, тестирование, эксплуатация и сопровождение. Модели жизненного цикла.

ЖЦ является моделью создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.

Основные этапы ЖЦ ПО: анализ требований, проектирование, кодирование (программирование), тестирование и отладка, эксплуатация и сопровождение.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. Модели ЖЦ:

Каскадная модель— предполагает переход на следующий этап после полного окончания работ по предыдущему этапу;

Поэтапная модель — итерационная модель разработки ПО с циклами обратной связи между этапами. (межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; но, время жизни каждого из этапов растягивается на весь период разработки;

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

Стадии ЖЦ:

Анализ требований. Требования заказчика уточняются, формализуются и документируются. На этом этапе дается ответ на вопрос: “Что должна делать будущая система”.

Список требований к разрабатываемой: совокупность условий, при которых предполагается эксплуатировать будущую систему; описание выполняемых системой функций; ограничения в процессе разработки. Цель анализа: преобразование общих знаний о требованиях к будущей системе в точные определения. На этом этапе определяются: архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО; интерфейсы и распределение функций между человеком и системой; требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.

Этап проектирования дает ответ на вопрос: “Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?”. Задача: исследование структуры системы и логических взаимосвязей ее элементов. Проектирование определяется как процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям”.

Программирование или, иначе говоря, кодирование функциональных модулей;

Тестирование и отладка, в процессе которых выявляется соответствие ПП его спецификациям;

Эксплуатация и сопровождение, когда разработанное ПО функционирует в составе (или в качестве) АСОИ в конкретной области применения.

2. Сущность структурного и объектно-ориентированного подходов к проектированию информационных систем.

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

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

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Основные принципы структурного подхода:

В качестве двух базовых принципов используются следующие:

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

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

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

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

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT модели и соответствующие функциональные диаграммы; DFD диаграммы потоков данных; ERD диаграммы "сущность-связь".

Объектно-ориентированный подход к проектированию ИС

В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов в терминах предметной области. Основная идея объектно-ориентированного анализа и проектирования состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов.

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

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

Процесс разработки системы позволяет решить следующие задачи:

• определение перечня артефактов, которые должны быть разработаны;

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

• определение задач отдельных исполнителей и всей группы разработчиков в целом;

• выбор критериев контроля и оценки полученных результатов.

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

Процесс разработки системы является итеративным. Это означает, что каждая его стадия – формулировка требований, анализ, проектирование, реализация, тестирование, оценка полученных результатов – повторяется, позволяя совершенствовать полученные результаты до тех пор, пока не будут полностью удовлетворены требования к системе. Итеративный процесс отличается от традиционного однопроходного, когда перед переходом к следующему этапу должна быть завершена работа над предыдущим (реально разработка систем никогда не выполнялась в процессе однопроходного жизненного цикла).

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

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

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

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

В отличие от структурного подхода объектно-ориентированный имеет ряд преимуществ:

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

• сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;

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

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

• сопровождения системы на разных стадиях жизненного цикла;

• повторного использования компонентов;

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

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