Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Объектно-ориентированное проектирование).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 12.03.2024

Просмотров: 25

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Содержание:

Введение

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

1.Основные моменты проектирования

1.1 Сложность программного обеспечения


Учитывая огромное количество и многообразие информационных систем, далеко не все они сложны на столько, как это может показаться с первого взгляда. Даже всего один человек может придумать, спроектировать и воплотить в жизнь, а в дальнейшем успешно сопровождать и использовать программное обеспечение. Причем это может быть как и человек, только начинающий свою карьеру, так и уже состоявшийся профессионал-программист. Это не означает, что эта система не соответствует требованиям заказчика, или же сделана специалистом низкого уровня, вероятнее всего она просто-напросто имеет довольно узкую специализацию[1]. А ещё жизненный цикл данного ПО как правильно довольно мал, из-за чего целесообразнее разработать новое ПО чем реконструировать имеющееся. Из этого следует, что при создании подобных систем нужно запастись скорее терпением, чем быть гениальным разработчиком, и поэтому имеет смысл обратить внимание на другие процессы.

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

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

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


- сложность предметной области, для которой производится ПО

- определенные трудности при управлении процессом разработки

- ПО должно иметь определенную вариативность использования

- описание поведения больших дискретных систем порой не совсем удовлетворительно[2]

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

Если попытаться анализировать систему крупного океанского лайнера, то можно увидеть всё то многообразие и сложность различных подсистем, которые в свою очередь тоже делятся на подсистемы, которые в свою очередь, как не сложно догадаться, тоже отнюдь не состоят из одной строчки кода. Взять, к примеру, систему освещения, которая в свою очередь делится на системы освещения жилых помещений, подсобных помещений, технических помещений, систему внешнего освещения, добавить к этому ещё и систему аварийной световой сигнализации, которая в свою очередь интегрирована в каждую из вышеупомянутых подсистем. А ведь это только часть общей системы управления лайнером. При этом компания-заказчик будет вносить постоянно какие-либо изменения, так сказать «под себя», требовать, чтобы все системы были удобны, производительны, имели продолжительный срок службы, и были при этом максимально дешевы. Исходя из сложности задач мы и получаем сложность, свойственную ПО[3].

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


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

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

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

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

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


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

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

1.2. Структура сложных систем

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

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

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