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

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

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

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

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

Достоинствами объектно-ориентированного подхода являются следующие.

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

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

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

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

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

осознавать выгоды такого подхода;

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

заниматься поиском подходящих для повторного использования программ;

стремиться непременно найти такие программы;

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

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

Естественность описания. Объектно-ориентированный подход позволяет описывать как статические, так и динамические отношения между объектами модели. По описанию предметной области, выполненному на естественном языке, легко выделить объекты и статические связи между ними. Объекты соответствуют существительным, а связи - глаголам и отглагольным формам. Например, фраза "фирмы выполняют заказы" позволяет выделить классы объектов "фирма" и "заказ" и отношение "выполнять" между ними типа M:N (многие к многим), так как фирма может выполнять много заказов, а заказ может быть выполнен разными фирмами.

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

Недостатки объектно-ориентированного подхода лежат в области программирования. Динамическое связывание, предполагающее поиск метода в классе, которому принадлежит получающий сообщение объект, приводит к тому, что обращение к методу занимает в 1,75 -2,5 раза больше времени, чем в обычной подпрограмме. Это, конечно, замедляет работу приложения. Однако, как указывает Г. Буч, динамическое связывание при использовании строго типизированных языков применяется примерно в 20% случаев от общего числа вызовов методов. Это позволяет снизить непроизводительные потери времени. В приложениях, где такие потери критичны, приходится прибегать к специальным программистским приемам.

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

Рис.3-Рост эффективности разработок по отношению к затратам при традиционном и объектно-ориентированном программировании

Глава 2. Анализ деятельности предприятия.

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

Портфельный анализ необходим для:

1-оценки и правильного анализа деятельности компании

2-для построения маркетингового плана стратегий

3-для правильного распределения денег в компании

Цели портфельного анализа-Главная цель «портфельного анализа» заключается в том, чтобы найти наиболее привлекательное с точки зрения финансовых результатов, эффективное и правильное использование уже имеющихся финансовых ресурсов у компании.
Ещё одна цель системы портфельного анализа состоит в стабильном и устойчивом финансовом положении компании. Для того чтобы в будущем от реализованных проектов получитать доход постоянно.

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

Ещё в прошлом веке Игорь Ансофф создал матрицу в двух измерениях «рынок — продукты», обещающую управленцам при ее использовании в планировании получать стабильные доходы с проекта диверсификации уже после 3–5 лет.

Рис.4-(Нет Называние)

Матрицы портфельного анализа: Первая известная матрица, которую создали специалисты из Бостона 1960-м г. Так и назвали «бостонской», её система прогнозирования основывается на двух гипотезах:

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

изучение непосредственно рынка (стагнация или зрелость) и уже из этого делается вывод, нуждается ли товар в обновлении, следует ли расширять производство того или иного продукта или нет.
Вторая матрица "McKincey" строилась на системе уже известной «бостонской» матрицы, с помощью которой можно сделать выводы относительно показателя роста на рынке. Несмотря на это между двумя двумерными матрицами есть колоссальные различия:

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

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

Спустя время Абель немного усовершенствовал модель матрицы, дополнив её третьим показателем технологией.
Матрица направленной политики (Shell) используется для промышленных компаний. Уникальность этой матрицы заключается в том, что путём стратегического планирования в бизнесе можно создать баланс между недостатком товара и его переизбытком.
Из недочётов всех матричных способов стратегического анализа можно отметить: неправильность сравнения отдельных стратегических единиц в бизнесе, которые относятся к области индустрии, а также некорректность в выявлении количественной оценки.

Параграф-2.1. Обоснование необходимости проектирование ИС.

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

1-обследование объекта и обоснование необходимости создания ИС;

2-формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

1-изучение объекта автоматизации;

2-проведение необходимых научно-исследовательских работ;

3-разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

4-оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.