Использование объектно-ориентированного анализа и проектирования по сравнению с традиционными структурного анализа и проектирования
РЕЗЮМЕ
Существующая методология используется в основном в промышленности сегодня в здании компьютерных приложений, известный как структурного анализа и проектирования. Эта методика появилась в результате структурированного программирования, созданные в 1970-х. Эта структурированная методология разработки систем (SDM) была доработаны и использованы в течение многих лет в реальном мире. Тем не менее, в течение последних нескольких лет объектно-ориентированного Языки становятся все более популярными и более широко используются в промышленных организаций, а также высших учебных заведений. Как эта тенденция сохранилась и методика была разработана для оказания помощи программиста разработки приложений с использованием объектно-ориентированных Языки. Эта методика стала известна как объектно-ориентированного анализа и проектирования (OOAD). Стратегии OOAD подходы к проблеме с объектом перспективы по сравнению с функциональной точки зрения, что основное внимание в рамках традиционных структурированную методологию развития. За последние несколько лет все более широкое использование OOAD по сравнению с традиционным структурированную методологию развития значительного распространения. По мере появления новых и более сложных объектно-ориентированных Языки создаются, как представляется, даже большая потребность в объектно-ориентированный подход к разработке бизнес-приложений.
Ключевые слова: системы анализа и проектирования, объектно-ориентированный анализ и проектирование, Водопад модели, системы Жизненный цикл разработки, объектно-ориентированного жизненного цикла, диаграммы классов, диаграммы потока данных.
1. ВВЕДЕНИЕ
После съемки многих статей, а также текущий и популярных учебников по системному анализу и дизайна, которые включают, но не ограничивается упомянутой в ссылках (Рамбо, Блаха, Premerlani, Эдди и Лоренсен, 1991; Эмбли, Курц и Вудфилд, 1992; Гибсон и Хьюз, 1994, Норман, 1996 года; Dewitz, 1996; Бахрами, 1999; Деннис, Уиксом и Тегарден, 2002; Браун, 2002; Satzinger, Джексон и Берд, 2005; Буч, 2007; Хоффер, Джордж и Valacich, 2008; ), автор отметил, много дискуссий по вопросу об использовании объектно-ориентированного анализа и проектирования по сравнению с традиционным анализа структурированных систем и дизайна. Хотя использование методологии OOAD оправдано во многих случаях, в некоторых случаях это могут быть неуместными и мы должны рассмотреть вопрос об использовании традиционных структурированную методологию анализа в проектировании и разработке информационных систем. Эта статья попытки уточнить использование этих методик, сравнить преимущества и недостатки каждого из них и выносить соответствующие рекомендации.
2. ИСТОРИЯ
Методология представляет собой процедуру решения проблем существующей системы, либо для создания нового. Есть много методик для проектирования и разработки информационных систем, которые включают в себя: системы развития жизненного цикла (SDLC), быстрой разработки приложений (RAD), объектно-ориентированный анализ и проектирование, макетирование и многие другие (Деннис, Уиксом, Тигарден, 2002) . SDLC более широко известный как Структурного Системного Анализа
Первый объектно-ориентированный Языки возник в 1960 и 1970 с Симула и Smalltalk. Тем не менее, он не был до нескольких лет, что объектно-ориентированный анализ и проектирование (OOAD) методология возникла (Ларман, 2004). Первый в 1982 объектно-ориентированного дизайна возникла как независимое тему (Г. Буч, 1982), а затем в 1988 объектно-ориентированный анализ был представлен С. Shlaer и С. Меллор (1988) и С. Бейлин (1988). Много различных объектно-ориентированного анализа и проектирования методы, разработанные с того времени такие известные лица, как Дж. Рамбо (1991), П. и Е. Коед Йордан (1991) и многие другие.
Методология OOAD использует объектно-ориентированной точки зрения, а не функциональной точки зрения, как и в методологии SSAD. Объект представляет собой личность, место или вещь, сначала обращается с проблемой области, которая имеет три аспекта: что он знает (его личность и некоторые атрибуты), которые он знает (отношения с другими объектами) и что она делает (ее методы, которые он отвечает за выполнение по его данным) (Норман, 1996). Объектно-ориентированного анализа процесса разработки объектно-ориентированной модели предметной области, где исходные объекты представляют собой объекты и методы, связанные с проблемой, которую необходимо решить. Объектно-ориентированного проектирования является процесс разработки объектно-ориентированной модели системы, необходимые для выполнения указанных требований. Таким образом, в данной методики мы считаем, с точки зрения вещи (предметы), а не функции.
+3. Традиционный анализ СИСТЕМЫ
Уклада жизни и цикла развития (SDLC) или структурированных систем анализа
* Первый принцип SSAD это "сверху вниз" функциональной декомпозиции. При этом система рассматривается во всей его полноте, где аналитик первый пытается понять основные характеристики системы, игнорируя мелкие детали позже.
* Следующий сферы системы определяется, где физические подробности существующей системы анализируются. Аналитик фокусируется на двух целей: что новая система должна делать и каким образом он должен это делать. (Davis, 1983).
* Эта методология предполагает, что пользователь участие от начала и до конца проекта. Аналитик встретится с пользователей регулярно для решения проблем и проверки потребностей пользователя. Это также требует, чтобы аналитик обладают сильно развитые навыки общения (Боумен, 2004).
* Два главных проблем в развитии информационной системы, процессы и данные, которые моделируются самостоятельно с этой методологии. Процессы моделируются данных схем, которые иллюстрируют поток данных между процессами и хранилищами данных и как она меняется, как она движется через систему от источника к месту назначения. Модели данных определяются сущность-связь диаграмм (ERD в), которые описывают данные (лиц) и различных ассоциаций между ними.
* Этот принцип самостоятельного моделирования данных и процессов, продолжается в течение всего этапа проектирования. Схемы для концептуальной модели базы данных определена и разработана база данных, нормированные и заполняются данными в ходе осуществления. В то же время модель процесса превращается в модули, которые будут разработаны, и этот этап также включает в себя разработку подробных логики программы. Из структуры диаграмм и программной логики программных модулей затем развита. Наконец, для подтверждения того, что система соответствует требованиям пользователя, целей и задач, мы подвергаем системы на различные уровни проверки.
4. Объектно-ориентированный анализ
По его текст Джон Satzinger и др. (2005) описывает объект методологии следующим образом: "объектно-ориентированный подход к разработке системы просмотров информационная система как совокупность взаимодействующих объектов, которые работают вместе для достижения задач. Концептуально Есть нет отдельных процессов или программ; Есть не отдельных субъектов данных или файлы. системы состоит в эксплуатацию объектов. объектом является вещь в компьютерной системы, способной реагировать на сообщения ". Таким образом, методология OOAD может быть разбит на два основных направления:
* Объектно-ориентированного анализа. Это связано с развивающимися объектно-ориентированную модель задачи (приложение) домена. Эти объекты представляют собой определены лица, а также обладать отношения и методы, которые необходимы для проблемы, которую предстоит решить.
* Объектно-ориентированное проектирование. Это связано с развивающимися объектно-ориентированной модели системы, необходимые для осуществления указанных требований. Аналитики и программисты должны мыслить вещи (предметы), а не процессов и функций.
Объектную модель основана на принципах, включая абстракция, инкапсуляция, модульность, иерархия, параллелизм и настойчивость, и следует повторяющиеся и поэтапный подход к разработке систем (Роб, 2004). Основное внимание в объектной модели является объектом разложение, в отличие от функциональной декомпозиции, где сложная система распадается на несколько объектов. Объектно-ориентированная система будет состоять из этих различных объектов, каждый из которых будет взаимодействовать и сотрудничать с другими объектами для достижения конкретных задач. Следовательно, объект разложения позволяет аналитику разрушить проблему в отдельный и более управляемые части. Это более подробно описаны следующим образом:
* В отличие от структурированный процесс развития систем, объектно-ориентированного программирования следует постепенно, жизненного цикла. 4 этапов объектно-ориентированного жизненного цикла являются создания, разработки, строительства и переходной экономикой. Таким образом, информационная система эволюционирует, проходя через несколько итераций, каждая из которых состоит из всех трех основных задач анализа, проектирования и строительства. Требования определены случаи использования, которые объектно-ориентированных инструментов, которые описывают сценарии взаимодействия между системой и ее пользователями.
* Эти сценарии также поможет определить объекты, которые моделируют данные (атрибуты) и соответствующих процессов (методов). Объекты, которые представляют тот же лица группируются вместе, чтобы сформировать классы. Классы могут быть связаны друг с другом различные виды ассоциаций, которые могут включать наследования и агрегации. Мы документируем эти классы и их различные отношения с проблемой домена диаграммах классов. Эти диаграммы, а также представления отношений между классами являются частью Unified Modeling Language (UML), который стал стандартом для методологии OOAD (Podeswa, 2005).
* На этапе проектирования этих классов будут расширены в конструкцию классов. На этом этапе детальные требования для каждого класса, который включает в себя определить его атрибуты и методы. Процессов для системы распределены между объектами, как методы или услуги. Таким образом, объекты должны сотрудничать друг с другом для того, чтобы выполнить различные сценарии описываются случаи использования. Мы документ такого сотрудничества между объектами с помощью диаграмм взаимодействия, описываемые как диаграммы последовательности и диаграммы кооперации. Тогда мы строить информационную систему с помощью комбинации классов, которые были разработаны ранее (повторное использование) и доступны в библиотеке классов, в дополнение к разработке новых использованием спецификации определены на стадии проектирования. Наконец мы оцениваем в результате системы тестирования (Буч, 2005).
В целом Существуют три основные компоненты объектно-ориентироваться анализа и разработки методологии, и они заключаются в следующем:
1. Требования Моделирование: Это описывает, кто использует систему и как, состоящая из актеров, прецедентов и сценариев. Актеры лиц или организаций, которые взаимодействуют с системой. Прецеденты определена для описания ожидаемого поведения системы. Сценарии являются частными случаями таких прецедентов, которые описывают конкретные требования системы.
2. Информационное моделирование: Это описывает сущности и отношения к проблеме, состоящий из объектов, их атрибутов и особенно отношения между собой.
+3. Жизненный цикл моделирования: Здесь описывается так, что объект отвечает к окружающей среде, которая состоит из различных государств, в которых объект может перехода, конкретные события, вызывающие эти переходы между государствами и конкретные мероприятия, связанные с входом и выходом определенного состояния (Гувер и Olekshy, 2001).
В следующей таблице сравниваются и обобщаются эти две методологии (Jadalowen, 2002):
5. ПРЕИМУЩЕСТВА И НЕДОСТАТКИ SSAD <p> преимущества и недостатки анализа структурированных систем и методологии проектирования можно резюмировать следующим образом:
Преимущества 5,1
* Есть отдельные этапы SSAD что делает отслеживание проще для управления проектами.
* С SSAD очень визуальной, оно делает его более удобным для пользователей / программистов понять.
* SSAD позволяет эффективно использовать его графического анализа и инструменты, такие как DFD в.
* SSAD очень хорошо известны, и установленной методологии в данной отрасли.
* SSAD была вокруг в течение длительного времени и, следовательно, пожилые техники.
* SSAD позволяет средств требованиям проверки.
* Наконец SSAD относительно проста и легка для понимания.
5,2 Недостатки
* С SSAD является процессно-ориентированный, в нем игнорируется нефункциональные требования.
* Существует менее непосредственное участие в управлении SSAD.
* С SSAD не является итерационным, как модели водопада, так что изменения требований означало бы перезапуска всего процесса.
* В SSAD есть некоторые, но не достаточно пользователей / аналитик взаимодействия.
* За исключением логического проектирования и DFD в, SSAD не дает никаких других средств для общения с пользователями, и, следовательно, это более сложно для пользователей для измерения прогресса.
* В SSAD труднее решить, когда следует прекратить функциональной декомпозиции и приступить к созданию системы.
* SSAD не всегда учитывать потребности пользователей.
* Наконец, SSAD не подходящими для объектно-ориентированного программирования Языки, так как она была первоначально разработана для структурированных Языки программирования, а не объектно-ориентированным (Jadalowen, 2002).
6. ПРЕИМУЩЕСТВА И НЕДОСТАТКИ OOAD
Преимущества и недостатки объектно-ориентированный анализ и проектирование методологии можно резюмировать следующим образом:
Преимущества 6,1
* OOAD значительно упрощает разработку системы по сравнению с SSAD.
* По сравнению с SSAD, время разработки, уровень организации, надежности, и повторное использование кода, все значительной степени зависит от методологии OOAD (Sommerville, 2000).
* В OOAD нет разделения между стадиях анализа и проектирования, что улучшает коммуникацию между пользователями, от начала и до конца проекта.
* В OOAD аналитиков и программистов, которые не связаны трудности внедрения системы, с тем чтобы они могли разрабатывать проекты, которые соответствуют различные среды исполнения.
* Поскольку объекты относятся к лицам (вещи), с которыми мы обычно взаимодействуют, как правило четкое соответствие между реальными лицами и соответствующих объектов в системе. Это значительно улучшает понимание конструкции (Sommerville, 2000).
* В OOAD программное обеспечение устойчивых к изменениям, в результате чего более высокий уровень уверенности в правильности программного обеспечения, которое помогает снизить риски при разработке сложных систем (Буч, 2007).
* В OOAD при разработке объектов со сложными взаимодействиями, аналитик думает о другой уровень детализации, чем это возможно со структурированными код. В этом случае аналитик думает, какие атрибуты объекта необходимо знать, и как он будет действовать на тех атрибутов (Фелан, 2002).
* Поскольку объекты являются независимыми инкапсуляции данных и методов, они пригодны для повторного использования и могут быть использованы в других проектах, в дополнение к 1, для которых они были созданы. Это приведет к сокращению дизайн, программирование и подтверждение расходов.
* OOAD улучшает качество системы за счет повторного использования программы. Vivek Шах говорит в своей статье, что "если 90% от нового приложения состоит из проверенных, существующие компоненты, а затем лишь оставшиеся 10% кода должна быть проверена с нуля. Это замечание означает порядку величины сокращения дефектов "(Shah, Sivitanides и Мартин, 1997).
* OOAD позволяет стандартизации объектов, решение увеличивает понимание и снижает риски, связанные с разработкой проектов.
* Объект разложения позволяет аналитику сломать задачи на независимые и управляемые части. Во многих случаях рабочие смены из развивающихся новый код для объединения существующих объектов в творческих подходов к решению этой проблемы. Таким образом OOAD методологии сокращает время разработки и расходы, которые будут стимулировать и стимулировать рынок и конкурентные преимущества. Это приводит к очень гибкая, легко изменены и более легким в обслуживании системы.
6,2 Недостатки OOAD
* В OOAD первоначальный дизайн для системы может оказаться слишком упрощенным на адекватном уровне.
* В OOAD там, как правило, гораздо больше внимания, чем в код SSAD.
* В OOAD там не так много внимания на командной работе, как в SSAD.
* В OOAD это не простая задача определить все необходимые классы и объекты, необходимые для системы.
* Много раз объектно-ориентированного программирования используется в сочетании с анализом различных функций системы, однако эти функции методов, основанных на неуместные в OOAD.
* Еще один крупный недостаток OOAD является чрезмерной этого объекта методологии в целом, где, по сути, еще один подход может быть гораздо лучше использовать для проектирования и разработки системы, в зависимости от конкретных обстоятельств.
* OOAD требует нового типа управления проектами, которая включает различные типы анализа от традиционного функционального подхода разложения и структурированных методов программирования. Следовательно, для развития проекта группы, которые имеют долгую историю использования методологии SSAD, переход к методологии OOAD крайне сложно и отнимает много времени (Hantos, 2005).
* Наконец, еще одним недостатком методологии OOAD является концепция повторного использования. Повторное считается одним из главных преимуществ этой методологии и основанием для перехода к OOAD. Тем не менее, без явного процедуры повторного использования на месте многих систем, разработанных с этой методологии не приводят к успешной повторного использования в больших масштабах (Hantos, 2005).
7. ЗАКЛЮЧЕНИЕ
В своей работе Sumit Сиркар (Сиркар, Nerur и Махапатра, 2001) делает следующее замечание: "Недавний опрос IS менеджеров показал, что 39% организаций приняли OO технологии в той или иной форме. Тем не менее, методологии OO развития применяются только в 5% от IS проекты, разработанные в методологии OO (стекло, 1999) ". Для конкретного применения первой задачей является решить, какая методология является наиболее подходящей для своего развития. Иногда мы, возможно, придется адаптировать различные методики. Некоторые положения может оказаться, что простых задач может быть легче достичь с помощью структурированных методов программирования с использованием объектно-ориентированных методов может быть лучше подходит для более высокого уровня абстракции. Это может также помочь в конструкции модуля и задача о разбиении. Для ситуаций, в которых данные, скорее всего, изменения, чем его функциональность, объектов будет более уместным.
Для компаний с переходом от методологии SSAD методологии OOAD, они должны понять суть изменений и барьеры, которые необходимо преодолеть, иначе переход к этой новой методологии может закончиться неудачей. Следовательно, для аналитиков и программистов принять эту новую методологию, они должны переориентировать свою мышления с функциональной точки зрения на объект точки зрения. Более конкретно для аналитиков и программистов с опытом работы в традиционной методики, обучение должно подчеркнуть моделирования аспекты методологии, в отличие от обучения синтаксис и особенности объектно-ориентированного языка. Переход от SSAD к OOAD может быть легче, контролируемому обучению и использование объектно-ориентированных средств (Сиркар, 2001).
Хотя методология OOAD предоставляет много преимуществ, она не решает всех проблем, связанных с традиционной методики SSAD. Есть еще некоторые недостатки, и недостатки, которые необходимо решать в том числе: объем подготовки не требуется, время, необходимое, чтобы узнать новые методики и сумму денег, чтобы вкладывать в него средства. Согласно стекла (стекло, 2002) нет никакой гарантии, что принятие новых технологий приведет к он используется эффективно и рационально. Кроме того, если организация полностью погружает себя в новой методологии OOAD, не может быть дорогостоящим и разрушительным результатам. Следовательно, чтобы воспользоваться всеми положительных преимуществ, которые предлагает новая методология, организация должна разработать тщательно спланировано и постепенное внедрение методологии для всех разработчиков системы.
Перед усилия для использования методологии OOAD как упоминалось ранее, важно, чтобы необходимое образование предоставляется в целях обеспечения его успеха. Навыки, знания и опыт системного анализа и программистов, которые воспитывались в традиционной методики SSAD может быть повышена за счет новых методов. Поскольку изменения в основной структуре методологии OOAD вызывают стресс в управлении, первые попытки использовать эту методику следует применять только в небольших масштабах и не критически важных приложений. Это позволит компании получить немедленную обратную связь и иметь время, чтобы внести все необходимые изменения в применении методологии OOAD. Таким образом, выгоды и преимущества от использования новой методики OOAD может быть значительно больше и больше пользы для организации в долгосрочной перспективе, чем при использовании традиционных методов SSAD (стекло, 2002).
Ссылки:
Бахрами А., объектно-ориентированных систем развития, Ирвин McGraw-Hill, Бостон, Массачусетс, 1999.
Бейлин, S., Замечания по объектно-ориентированному спецификации требований, компьютерная техника Associates, лавр, MD, 1988.
Буч Г., Объектно-ориентированное проектирование ", том Ада Письма 1 (3), 1982, 64-76.
Буч Г. Рамбо Дж., Якобсон И., унифицированный язык моделирования Руководство пользователя, 2-е изд., Addison-Wesley, Верховья реки седла, New Jersey, 2005.
Буч Г. Максимчук Р., Энгл, М., Молодая, B., Conallen, J., Хьюстон, К., объектно-ориентированный анализ и проектирование с приложениями, третье издание, Addison Wesley, чтение М., 2007 .
Боумен, Кевин, системный анализ: руководство для начинающих, Palgrave Macmillan, Гордонсвилл, VA. 2004.
Браун Д., Введение в объектно-ориентированный анализ, объектов и UML в равнинных Английский, М. Джон и сыновья ", Нью-Йорк, Нью-Йорк, 2002.
Коед П., Йордан Е., объектно-ориентированный анализ, 2 изд., Йордан Пресс, Englewood Cliffs, New Jersey, 1991.
Дэвис, W., системного анализа и проектирования Структурный подход, Addison-Wesley, Ридинг, Массачусетс, 1983.
Денис А., Уиксом, B., и Тегарден Д., системного анализа и проектирования объектно-ориентированного подхода в UML, John Wiley
Dewitz, S., системного анализа и проектирования и перехода к объектам, Ирвин McGraw-Hill, Бостон, Массачусетс, 1996.
Эмбли Д., Курц, Б. и Вудфилд, S., объектно-ориентированные системы анализа на основе моделей подхода, Йордан Пресс Prentice Hall, Englewood Cliffs, New Jersey, 1992.
Гибсон, М., Хьюз, C., системного анализа и дизайн: всеобъемлющей методологии с Case, Бойд и Фрейзер, Danvers, Массачусетс, 1994.
Стекло, RL, "снимок системы развития практики", IEEE Software, Vol. 16 (3), 1999, 110-112.
Стекло, RL, "Естественность объектно-ориентированного подхода: Избиение мертвой лошади"? IEEE Software, Vol. 19 (3), 2002, 103-104.
Hantos П., риски, присущие объектно-ориентированного программирования, февраль 2005; Aerospace Corporation, <a target="_blank" href="http://www.stc.hill.af.mil" rel="nofollow"> www.stc.hill.af.mil </ A>.
Хоффер, J., Джордж Дж., Valacich, J., современного системного анализа и дизайна, пятое издание, Пирсон Prentice Hall, Верховья реки седла, New Jersey, 2008.
Пылесос, H., и Olekshy, T., объектно-ориентированный анализ и проектирование подход практики в мае 2001 года, Авра Software Lab Инк, <A HREF = "http://www.avrasoft.com" целевых = "_blank" относительной = "NOFOLLOW" <> www.avrasoft.com / A>.
Jadalowen И., структурного анализа и Structured Design (SSAD) резюме, 2002; инженерии программного обеспечения научно-исследовательской сети, pages.cpsc.ucalgary.ca.
Ларман, К., Применение UML и шаблонов: Введение в объектно-ориентированный анализ и проектирование и итерационных развития, третье издание, Prentice Hall, Верховья реки седла, New Jersey, 2004.
Норман Р., объектно-ориентированные системы анализа и проектирования, Prentice Hall, Верховья реки седла, New Jersey, 1996.
Фелан П., каким образом это объектно-ориентированной методологии лучше, чем структурированную методологию, ноябрь 2002, эксперт знаний, <a target="_blank" href="http://www.techtarget.com" rel="nofollow"> www.techtarget.com </ A>.
Podeswa, H., BOOM Бизнес объектно-ориентированного моделирования для бизнес-аналитиков, курс технологии, Boston, MA, 2005.
Роб, М., "Вопросы структурированной против объектно-ориентированной методологии системного анализа и дизайна", проблемы в области информационных систем, том V (1), 2004, 275-280.
Рамбо, J., Блаха, М., Premerlani, W., Эдди Ф., Лоренсен, W., объектно-ориентированного моделирования и дизайна, Prentice-Hall, Englewood Cliffs, New Jersey, 1991.
Satzinger, J., Джексон, Р. и Бурд, S., объектно-ориентированный анализ и проектирование с Unified Process, курс технологии, Бостон, Массачусетс, 2005.
Сенна, J., анализа и проектирования информационных систем, McGraw-Hill, Нью-Йорк, Нью-Йорк, 1989.
Шах В., Sivitanides, М., Мартин Р., ошибки объектно-ориентированного развития "Бизнес" Квест "Журнал прикладной темы в области бизнеса и экономики, ноябрь 1997, <A HREF =" http://www. westga.edu "целевых =" _blank "относительной =" NOFOLLOW "> www.westga.edu </ A>.
Shlaer, S., и Меллор, S., объектно-ориентированные системы анализа: моделирование мира в данных. Йордон Пресс, Englewood Cliffs, New Jersey, 1988.
Сиркар, S., Nerur, S., и Махапатра Р., революция или эволюция? Сравнение объектно-ориентированного и структурного развития систем методы ", MIS Quarterly, Vol. 25 (4), 2001, 457-471.
Соммервилл И., Software Engineering, 6 изд. Международный компьютерный науки серии, Addison Wesley, Чтение, М., 2000.
У С. и У, М., системного анализа и дизайна, курс технологии, Кембридж в штате Массачусетс, 1994.
Д-р Кеннет Pefkaros получил степень доктора философии в области прикладной математики в Университете Делавэра в 1972 году. В настоящее время он профессор менеджмента в Университете штата Калифорния, Ист Бэй. Его исследования включают исследование операций, системы поддержки принятия решений, и прикладной математики. Он опубликовал множество текстов, и его документы оказались в журнале по компьютерным информационным системам, обзор бизнес-исследований, Калифорния Журнал операционного менеджмента и Труды IABE.