Главная | Обратная связь | Поможем написать вашу работу!

Основные принципы объектно-ориентированного подхода

Состав и характеристика процессов ЖЦ ПО(основных, вспомогательных и организационных)

Основные:

1- Приобретение (действия и задачи заказчика, приобретающего ПО)

2- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)

3- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

4- Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

5- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения).

Вспомогательные:

1- Документировани е (формализованное описание информации, созданной в течение ЖЦ ПО)

2- Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

3- Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

4- Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)

5- Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

6- Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

7- Аудит (определение соответствия требованиям, планам и условиям договора)

8- Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

Организационные:

1- Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)

2- Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

3- Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Существующие подходы к проектированию программного обеспечения экономических информационных систем и их общая характеристика.

Существуют два подхода:

1- структурный

2- объектно ориентированный

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

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

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

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

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

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

-Принцип непротиворечивости – обоснованность и согласованность элементов системы

-Принцип структурирования данных – данные д.б. структурированы и иерархически организованы

Основные принципы объектно-ориентированного подхода

-Абстрагирование - выделение существенных характеристик объекта, отличающего его от всех других видов объектов.

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

-Модульность – разделение программы на фрагменты, которые компилируются по отдельности, но могут устанавливать связи с другими модулями.

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

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

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

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

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

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

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

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

Сравнительный анализ методов SADT и DFD при структурном проектировании программного обеспечения.

Сравнительный анализ методовSADTиDFDструктурного анализа проводится по следующим параметрам:

1- адекватность средств решаемым задачам;

SADT-диаграммы оказываются значительно менее выразительными и удобными при моделировании ПО.

Дуги в SADT жестко типизированы (вход, выход, управление, механизм).

В SADT отсутствуют выразительные средства для моделирования особенностей ИС. Жесткие ограничения SADT, запрещающие использовать более 6—7 блоков на диафамме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной предметной области.

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

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

2- согласованность с другими средствами структурного анализа;

3- интеграция с другими процессами ЖЦ ПО (прежде всего с процессом проектирования).

Совместное применение структурного и объектно-ориентированного подходов.

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

Состав и характеристика интегрированных case-средств проектирования ПО

CASE-средства (Computer Aided Software Engineering) - это программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

- графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

- средства разработки приложений, включая языки 4GL и генераторы кодов;

- средства конфигурационного управления;

- средства документирования;

- средства тестирования; - средства управления проектом; -средства реинжиниринга.

Схемы (варианты) клиент-серверной архитектуры.

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

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

В трехуровневом (сервер БД и сервер приложений – клиенты)приложении появляется третий, промежуточный уровень, реализующий бизнес-правила, которые являются наиболее часто изменяемыми компонентами приложения

Сущность и классификация методов типового проектирования (элементный, подсистемный, объектный).

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

Элементный метод

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

Достоинства и недостатки такого подхода:

1-система достаточно гибкая

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

3-система получается дорогостоящей как в плане времени внедрения, так и стоимости внедрения.

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

Подсистемный метод

Компоненты являются более обширными и функционально-полными по спектру решаемых задач. Например 1С:Бухгалтерия для автоматизации ведения бухгалтерского учёта, 1C:Склад для складского учёта и так далее. По сути, это промежуточное звено между элементным подходом и объектным методом.
Достоинства и недостатки:

1-Дешевле стоимость формирования ЭИС, проще поддержка

2-Хорошее документирование и в целом, более проработанная взаимосвязь элементов подсистемы.

3-Слабые возможности непрерывного инжиниринга бизнес-процессов

Объектный метод

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

Типовое проектирование ЭИС. Основные понятия и методы проектирования.

Типовое проектирование – разбиение системы на множество составных компонентов и создание для каждой из них законченного проектного решения, которое про внедрении привязывается к конкретным условиям объекта.

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

Методы проектирования:

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

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

3-объектный-декомпозиция ЭИС не производится. Типовой проект создается в целом для некоторого обобщеного объекта, определенной группы.

Функционально-ориентированное проектирование ЭИС.

Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования информационных систем.

Они заключаются в следующем:

1-Декомпозиция(разбиение) всей системы на некоторое множество иерархически подчинённых функций.

2-Представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.

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

1-BFD (Business Function Diagram) - диаграмма бизнес-функций (функциональные спецификации)

2-DFD (Data Flow Diagram) - диаграмма потоков данных

3-STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрёстных ссылок)

4-ERD (Entity Relation Diagram) - ER-модель данных предметной области (информационно-логические модели "сущность-связь")

5-SSD (System Structure Diagram) - диаграмма структуры программного приложения

Характеристика IDEF0(SADT)-метода проектирования функциональной структуры программного обеспечения.

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

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

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

Характеристика DFD-метода проектирования при определении функциональных требований к программному обеспечению.

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

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

Диаграммы потоков данных содержит объекты следующих типов:

- процессы;

- хранилища данных;

- потоки данных.

Процессы предназначены для преобразования входящих в них потоков данных в выходные потоки данных. Процессы на DFD могут состоять из подпроцессов. Первый уровень иерархии образует единственный процесс, представленный на контекстной диаграмме. Далее производится декомпозиция этого процесса на процессы первого уровня, затем операция декомпозиции применяется к процессам первого уровня, при этом образуется второй уровень иерархии и так далее.

Воспользуйтесь поиском по сайту: