Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
Структурный анализ (Structured Analysis, SA) и структурное проекти- рование (Structured Design, SD) – результат появившегося в 1970-х структурно- го программирования, развивался из классического системного анализа. Мето- дологии структурного анализа используют каскадную (водопадную) модель ЖЦ ИС; самые известные и используемые методологии структурно анализа – SADDT, SSADM. Методы структурного анализа дорабатывались и используют- ся уже на протяжении многих лет. Структурному анализу и структурному про- ектированию посвящен раздел 4 данной книги. Сравнительно позже появились и стали невероятно популярны объектно- ориентированные языки. По мере нарастания их популярности была разработа- на методология помощи программисту в разработке приложений с использова- нием объектно-ориентированных языков. Эта методология стала известна как объектно-ориентированный анализ и проектирование (оbject-oriented analy- sis and design, OOAD). OOAD – это подход к инженерии ПО, моделирующий систему как группу взаимодействующих объектов. Объектно-ориентированный анализ (Object- oriented analysis, OOA ) использует методы объектного моделирования для ана- лиза функциональных требований к системе. Объектно-ориентированное проектирование, ООП (Object-oriented design, OOD) разрабатывает аналитические модели для создания спецификаций реализации (например, ТЗ). Концептуальной основой OOП является объектная модель, которая строится с учетом принципов абстрагирования, инкапсуляции, модульности, иерархии, типизации, параллелизма, устойчивости. Основными понятиями объектно-ориентированного подхода являются объект и класс. Объект – представляет собой определенную сущность, соот- ветствующую значимому предмету или явлению предметной области, характе- ризуется классом, состоянием (state (data elements)) и поведением. Для этих взаимодействующих (collaborating) между собой объектов можно создать раз- 77 личные модели, характеризующие статическую структуру, динамическое по- ведение и развертывание в действии (run-time deployment). Класс – это множе- ство объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют по- лиморфизм (способность класса принадлежать более чем одному типу) и насле- дование (построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов). На сегодняшний день существует более тридцати объектно- ориентированных методов проектирования (например, IDEF4 – Object-Oriented Design – методология ООП, позволяющая отображать структуру объектов и принципы их взаимодействия) с множеством различных нотаций представления объектных моделей. Два самых популярных стандартных языка объектно-ориентированного моделирования – UML (The Unified Modeling Language) и SysML. Унифицированный язык моделирования UML (Unified Modeling Language) – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы (UML-модели); был создан для опреде- ления, визуализации, проектирования и документирования в основном про- граммных приложений. Методы описания результатов анализа и проектирова- ния семантически близки к методам программирования на современ- ных объектно-ориентированных языках. На основании UML-модели возмож- на генерация программного кода. С помощью UML можно также разработать детальный план создаваемой системы, содержащий системные функции и биз- нес процессы, схемы баз данных, программные компоненты многократного ис- пользования. UML позволяет рассмотреть систему со всех точек зрения, имею- щих отношение к ее разработке и последующему развертыванию. UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей следующие набор диаграмм: структурные диа- граммы (Structure Diagrams); диаграммы поведения (Behavior Diagrams );диаграммы взаимодействия (Interaction Diagrams). 78 UML фокусируется не трех архитектурных видениях системы: • функциональном (описывает внешнее поведение системы с точки зрения пользователя с помощью use-case диаграмм); • статическом (в терминах атрибутов, методов, связей, классов, сообще- ний с помощью CRC cards, class diagrams, object diagrams); • динамическом (sequence diagrams, collaboration diagrams, statecharts) и имеет практическое значение в описании сервисно-ориентированных ар- хитектур (SOAs). Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка уточнялась и была расширена для под- держки методологии Model Driven Development, MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве междуна- родного стандарта ISO/IEC 19505-1, 19505-2. Проблематика выбора. Появление новых и все более сложных объект- но-ориентированных языков должно было, как представлялось, увеличить по- требность в использовании объектного подхода для разработки бизнес прило- жений. Но так ли это на самом деле, дает ли популярность объектно- ориентированного программирования гарантию преимущества нового объект- ного подхода к проектированию перед традиционной структурной методологи- ей, остается вопросом. Ниже перечислены преимущества и недостатки струк- турной и объектно-ориентированных методологий. Основные преимущества структурных методологий: • основаны на классическом системном анализе и процессно- ориентированы, подходят для описания любых (не только информацион- ных) систем, идеальны для исследования предметной области, реинжи- ниринга бизнес процессов; • понятное и относительно простое визуальное представление системы, легко понимаемое как пользователями, так и разработчиками; • акцент на командной работе; 79 • четко определенные этапы, что облегчает управление проектом и позво- ляет разрабатывать системы лучшего качества; • допускают использование средств проверки требований; • SSAD и IDEF0 – классические, широко известные методологии в области проектирования ИС, существующие на протяжении длительного времени и достаточно «зрелые»; Недостатки структурных методологий: • поскольку процессно-ориентированы, то соответственно, игнорируют нефункциональные требования: не идеальные решения при использова- нии объектно-ориентированных языков программирования, т.к. изна- чально создавались для структурных языков; • поскольку SSAD и SSADM неитеративны, то изменение требований мо- жет привести к перезапуску всего процесса разработки; • возможны трудности при определении глубины декомпозиции – момента, когда нужно остановиться и переходить к реализации модели; Преимущества объектно-ориентированных методологий: • упрощение и ускорение программной реализации системы по сравнению со структурными методологиями; • повторное использование кода в других проектах, благодаря независимо- сти объектов и инкапсуляции, что сокращает стоимость проектирования, программирования и проверки; повторное использование кода может способствовать улучшению качества последующих проектов («Если 90% нового приложения содержит проверенные компоненты, то только 10% кода должна быть проверена с нуля» (Vivek Shah); • отсутствие разделения между фазами анализа и разработки обеспечивает взаимодействие с пользователями до самого конца проекта; • аналитики и программисты не связаны ограничениями внедрения систе- мы, поэтому могут формулировать проекты, которые будут соответство- вать различным средам исполнения; 80 • программное обеспечение устойчиво к изменениям, что обеспечивает бо- лее высокий уровень уверенности в его корректности, способствуя сни- жению рисков при разработке сложных систем; • те преимущества, которые представляет объектно-ориентированное про- граммирование по сравнению со структурным: при разработке объектов со сложным взаимодействием, аналитик думает на ином уровне детали- зации, чем это возможно в структурном коде, т.е. об атрибутах объекта; стандартизация объектов увеличивает степень понимания проекта. Недостатки объектно-ориентированных методологий: • изначальная модель слишком упрощена для того, чтобы быть адекватной; • чрезмерная фокусировка на коде; • не так много внимания уделяется командной работе, как в структурных методологиях; • определение всех необходимых для системы классов и объектов – это не такая, на самом деле, простая задача; • попытка сочетания объектного программирования с анализом различных функций системы; однако, эти функциональные методы совершенно не соответствуют OOAD; • преувеличение значимости и универсальности объектной методологии, когда, фактически, другой подход мог бы подойти лучше для анализа и разработки системы в зависимости от конкретных обстоятельств; • требует новый вид управления проектами, который включает различные типы анализа, отличные от традиционного функционального подхода де- композиции. Следовательно, для команд разработчиков проекта, которые имеют долгую историю использования методологий SSAD и SSADM, пе- реход к методологии OOAD является чрезвычайно сложным, длительным и трудоемким (Hantos, 2005); • другой недостаток – это сама концепция повторного использования, ко- торая заявляется как крупное преимущество и причина для перехода на OOAD. Однако, без явной процедуры повторного использования многие 81 из систем, разработанных с помощью данной методологии, не ведут к успешному повторному использованию в больших масштабах (Hantos, 2005); • функциональное описание системы в UML основано на сценариях ис- пользования, которые подходят для документирования требований, не основанных на взаимодействии с системой (таких как алгоритм или ма- тематические требования) или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность); следова- ние шаблонам не гарантирует качества сценариев, качество зависит толь- ко от навыков создателя сценария; • объектный подход к моделированию данных при том, что большинство ИС используют реляционные модели; В конце концов, ИС чаще разраба- тываются через комбинацию объектно-ориентированных языков про- граммирования и реляционных баз данных, а не полностью объектные базы данных и языки. В одной из опубликованных в 2001 году работ (Sircar, Nerur, and Maha- patra) было сделано интересное замечание: «недавний опрос ИТ менеджеров показал, что 39% организаций приняли OO технологии в той или иной форме. Тем не менее, ОО методологии проектирования используются только в 5% ИТ проектов» Заключение. При разработке конкретного приложения первая задача – решить, какая методология наиболее подходит для этой разработки. Иногда, возможно, придется адаптировать различные методологи. Существует мнение, что для решения простых задач лучше подходят структурные методы, в то вре- мя как объектно-ориентированные методы уместнее для более высоких уровней абстракции. В ситуациях, где вероятность изменения данных выше, чем изме- нение функциональности, объектные методы также будут более подходящими. 82 2. НОРМАТИВНО-МЕТОДИЧЕСКАЯ ПОДДЕРЖКА ЖЦ ИС 2 .1. Нормативно-методическое обеспечение (НМО) ЖЦ ИС Методологии создания ИС описывают поддержку определенной модели жизненного цикла (ЖЦ) ИС и реализуется через стандарты и методики, а также поддерживающие их технологии и инструментальные средства (CASE- средства). Комплекс документов, регламентирующих деятельность разработчиков называют нормативно-методическим обеспечением (HMО). Входящие в состав НМО документы – это стандарты, руководящие документы, методики, положе- ния, инструкции, шаблоны и т.п., которые регламентируют: • порядок разработки, внедрения и сопровождения ПО; • общие требования к составу, связям между компонентами и качеству ПО; • виды, состав и содержание проектной и программной документации. В СССР в 1970-е годы процесс создания ПО регламентировался стандар- тами ЕСПД (Единой Системы Программной Документации – серия ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых про- грамм небольшого объема, создаваемых отдельными программистами в период « лоскутной автоматизации». Стандарты ЕСПД практически лишены содержательной составляющей и содержат формальные требования к составу, содержанию и оформлению доку- ментов, описывающих программу на разных стадиях ее жизненного цикла, а также порядку хранения и обновления документации. Многие авторы считают эти стандарты морально устаревшими (концептуально и по форме), тем не ме- нее, ими продолжают активно пользоваться при оформлении проектной доку- ментации. 83 Альтернативной современной нормативной базой НМО являются следу- ющие международные и отечественные стандарты (сгруппированы по статусу): 1) официальные (public) стандарты: • международные: o ISO/IES (ISO – International Organization of Standardization, международная организация по стандартизации; IEC – International Electrotechnical Commission , международная ко- миссия по электротехнике); o ANSI (American National Standards Institute); o стандарты международных консорциумов и комитетов по стандартизации (например, консорциума OMG); • стандарты Российской Федерации (ГОСТ): o ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»; o ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»; o ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». • отраслевые стандарты, • ведомственные стандарты. 2) Стандарты «де-факто» – официально никем не утвержденные, но фак- тически действующие (например, стандартом «де-факто» долгое время были языки взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Mi- crosoft ODBC). Другие способы классификации стандартов: по объекту стандартизации: 84 • стандарты на продукты и услуги; • стандарты на процессы и технологии; • стандарты на формы коллективной деятельности, или управленче- ские стандарты; по предмету стандартизации: 1) функциональные стандарты: • стандарты на языки программирования; • стандарты на интерфейсы и протоколы и др.; 2) стандарты на организацию ЖЦ ИС. Отдельно выделяют корпоративные стандарты. Корпоративные стандарты. Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, со- глашений), которые должны соблюдаться всеми участниками проекта. Для большинства сложных проектов приходится создавать свои комплекты норма- тивных и методических документов, регламентирующих процессы, этапы, ра- боты и документы конкретных программных продуктов. Такие стандарты называются корпоративными и представляют собой соглашение об единых правилах организации технологии или управления в организации. К таким стандартам относятся: • стандарты проектирования; • стандарты оформления проектной документации; • стандарты пользовательского интерфейса. Стандарт проектирования должен устанавливать: • набор необходимых моделей (диаграмм) на каждой стадии проектирова- ния и степень их детализации; • правила фиксации проектных решений на диаграммах, в том числе: пра- вила именования объектов (включая соглашения по терминологии), набор 85 атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.; • требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.; • механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена про- ектной информацией, механизм фиксации общих объектов и т.д.), прави- ла проверки проектных решений на непротиворечивость и т.д. Стандарт оформления проектной документации должен устанавли- вать: • комплектность, состав и структуру документации на каждой стадии про- ектирования; • требования к ее оформлению (включая требования к содержанию разде- лов, подразделов, пунктов, таблиц и т.д.), • правила подготовки, рассмотрения, согласования и утверждения доку- ментации с указанием предельных сроков для каждой стадии; • требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; • требования к настройке CASE-средств для обеспечения подготовки до- кументации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: • правила оформления экранов (шрифты и цветовая палитра), состав и рас- положение окон и элементов управления; • правила использования клавиатуры и мыши; • правила оформления текстов помощи; 86 • перечень стандартных сообщений; • правила обработки реакции пользователя. За основу корпоративных стандартов могут приниматься отраслевые, национальные или международные стандарты. Сюда могут относятся различ- ного рода методические материалы ведущих фирм-разработчиков ПО, фирм- консультантов, научных центров, консорциумов по стандартизации. |