Каталог Рефератов - Программа регистрации процесса производства для автоматизированной системы управления предприятием электронной промышленности

	Информационно-образоательный портал
	Рефераты, курсовые, дипломы, научные работы,



МЕНЮ\|

поиск

Программа регистрации процесса производства для автоматизированной системы управления предприятием электронной промышленности

MainFrame - этот класс, производный от CFrameWnd, используется для управления главным окном приложения.

CAngstremView - является наследником класса CView. Класс CView, производный от CWnd, служит базовым для пользовательских классов отображения. Отображение (view) служит промежуточным звеном между документом и пользователем. Обычно отображение - это дочернее окно главного окна.

CAngstremDoc - класс используется для хранения данных.

Технологическая часть:

Технология разработки программных систем

Выполнил:

Ляшко М.А.

Консультант:

Брусникин Г.Н.

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

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

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

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

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

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

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

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены.

4.3 Модели жизненного цикла программного обеспечения
Стандарт ISO/IEC 12207 не предлагает конкретную модель жизненного цикла и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий его разработки.

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

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

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

Рис.12. Каскадная схема разработки программного обеспечения

Преимущества применения каскадного способа заключается в следующем:

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

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

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

В то же время этот подход обладает рядом существенных недостатков, вызванных прежде всего тем, что реальный процесс создания достаточно сложного ПО никогда полностью не удавалось уложить в такую жесткую схему, постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал вид, представленный на рис.13. Вторым недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационной системе “заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена.

Рис.13. Схема реального процесса разработки программного обеспечения

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

Рис.14. Спиральная модель жизненного цикла

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

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

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

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

удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;

согласована с ограничениями, накладываемыми оборудованием;

удовлетворяет явным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению;

удовлетворяет явным и неявным критериям дизайна продукта;

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

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

4.5.1 Методы проектирования
Ясно, что не существует такого универсального метода, который бы провел инженера-программиста по пути от требований к сложной информационной системе до их выполнения. Проектирование такой информационной системы отнюдь не сводится к слепому следованию некоему набору рецептов. Скорее это постепенный и итеративный процесс. И тем не менее использование методологии проектирования вносит в процесс разработки определенную организованность. Как уже утверждалось выше, инженеры-программисты с момента зарождения программирования до с настоящих дней разработали десятки различных методов, которые можно классифицировать по трем категориям:

Страницы: 1, 2, 3, 4, 5, 6, 7

© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.