Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf
Добавлен: 28.03.2023
Просмотров: 399
Скачиваний: 2
СОДЕРЖАНИЕ
Глава 1. Теоретические основы объектно-ориентированного подхода.
Параграф-1.1 Сущность объектно-ориентированного подхода.
Параграф-1.2 Преимущества и недостатки объектно-ориентированного подхода.
Глава 2. Анализ деятельности предприятия.
Параграф-2.1. Обоснование необходимости проектирование ИС.
Глава 3. Реализация объектно-ориентированного подхода при проектировании ИС
3-разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
1-разработка проектных решений по системе и ее частям;
2-разработка документации на ИС и ее части;
3-разработка и оформление документации на поставку комплектующих
изделий;
4-разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
1-разработка рабочей документации на ИС и ее части;
2-разработка и адаптация программ.
Стадия 7. Ввод в действие.
1-подготовка объекта автоматизации;
2-подготовка персонала;
комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний ;
проведение опытной эксплуатации ;
проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Oбследование - это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:
обоснования разработки и поэтапного внедрения систем;
составления технического задания на разработку систем;
разработки технического и рабочего проектов систем.
На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.
Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня . Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечениеh6span> и разработку нового программного обеспечения ).
Результатом этапа определения стратегии является документ ( технико-экономическое обоснование проекта ), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Ориентировочное содержание этого документа:
ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
описание выполняемых системой функций;
возможности развития системы;
информационные объекты системы;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, требования к СУБД;
что не будет реализовано в рамках проекта.
На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;
возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
функции - информация о событиях и процессах, которые происходят в бизнесе;
сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.
При изучении каждой функциональной задачи управления определяются:
наименование задачи; сроки и периодичность ее решения;
степень формализуемости задачи;
источники информации, необходимые для решения задачи;
показатели и их количественные характеристики;
порядок корректировки информации;
действующие алгоритмы расчета показателей и возможные методы контроля;
действующие средства сбора, передачи и обработки информации;
действующие средства связи;
принятая точность решения задачи;
трудоемкость решения задачи;
действующие формы представления исходных данных и результатов их обработки в виде документов;
потребители результатной информации по задаче.
Глава 3. Реализация объектно-ориентированного подхода при проектировании ИС
Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается, прежде всего, прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.
Методология объектно-ориентированного программирования пришла на смену процедурной или алгоритмической организации структуры программного кода,
когда стало очевидно, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с повышением их надежности.
Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования.
Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного проектирования лежит методология объектно-ориентированного программирования.
Методы структурного проектирования помогают упростить процесс разработки сложных систем за счет использования алгоритмов как готовых строительных блоков. Аналогично, методы объектно-ориентированного проектирования созданы, чтобы помочь разработчикам применять мощные выразительные средства объектного и объектно-ориентированного программирования, использующего в качестве блоков классы и объекты.
По определению «объект» будем называть понятие, абстракцию или любую вещь с четко очерченными границами, имеющую смысл в контексте рассматриваемой прикладной проблемы.
Введение объектов преследует две цели:
1- понимание прикладной задачи (проблемы);
2-введение основы для реализации на компьютере.
При разработке программы рейтинговых данных студентов необходимо определиться с выбором объектно-ориентированного языка программирования.
После этого возникает вопрос: «Что же такое объектно-ориентированное программирование (object-oriented programming, OOP)»?
Мы определяем его следующим образом: «Объектно-ориентированное программирование — это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования».
Можно выделить три части требований к ООП:
1. OOП использует в качестве базовых элементов объекты.
2. Каждый объект является экземпляром определенного класса.
3. Классы организованы иерархически.
Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований.
В соответствии с этим определением не все языки программирования являются объектно-ориентированными.
Б. Страуструп определил так: «Если термин «объектно-ориентированный язык» вообще что-либо означает, то он должен означать язык, имеющий средства хорошей поддержки объектно-ориентированного стиля программирования».
Основные принципы ООП: абстракция, наследование, инкапсуляция и полиморфизм.
• Абстракция (abstraction) — характеристика сущности, которая отличает ее от других сущностей. Абстракция определяет границу представления соответствующего элемента модели и применяется для определения фундаментальных понятий ООП, таких как класс и объект.
• Принцип, в соответствии с которым знание о наиболее общей категории разрешается применять для более частной категории, называется наследованием.Наследование тесно связано с иерархией классов, определяющей, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом, если общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс (потомок) должен содержать этот же набор свойств и подобное поведение, а также дополнительные, которые будут характеризовать уникальность полученного класса. В этом случае говорят, что производный класс наследует свойства и поведение родительского класса.
• Инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей.
Пользователю, взаимодействующему с объектом класса, необязательно знать, каким образом осуществлен тот или иной элемент класса. Конкретная реализация присущих классу свойств и методов, которые определяют его поведение, является собственным делом данного класса. Более того, отдельные свойства и методы класса могут быть невидимы за его пределами, это относится к базовой идее введения различных категорий видимости для элементов класса.
• Полиморфизм также один из основных принципов ООП. Под полиморфизмом (греч.Poly — много, morfos — форма) понимается свойство объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод.
Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) — технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.
Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). К первым CASE-средствам отнеслись с определенной настороженностью. Со временем появились как восторженные отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД). Визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает проблем создания приложений других типов.
Вторая причина связана с графической нотацией, реализованной в CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко не однозначно. На этом фоне разработка и стандартизация унифицированного языка моделирования UML вызвала воодушевление у всего сообщества корпоративных программистов.
В рамках ООП исторически рассматривались три графические нотации:
1. Диаграммы «сущность–связь» (Entity-Relationship Diagrams, ERD).
2. Диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT).
3. Диаграммы потоков данных (Data Flow Diagrams, DFD).
Диаграммы «сущность–связь» (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними.