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

1.Кодирование

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

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

При кодировании необходимо следовать стандарту на выбран­ный язык, например, для языка С - это ANSI С, а для C++ - ISO/IEC 14882 «Standartforthe C++ ProgrammingLanguage».

Кроме общепринятого стандарта на язык программирования в компании могут использоваться разработаны и свои дополнитель­ные требования к правилам написания программ. В основном они касаются правил оформления текста программы.

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

На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Все воп­росы, связанные с тестированием ПП, рассмотрены в гл. 10, здесь же описана технология тестирования, которая применяется на этапе разработки ПП. Эта технология называется тестированием «стеклянного ящика» (glassbox); иногда ее еще называют тестиро­ванием «белого ящика» (whitebox) в противоположность класси­ческому понятию «черного ящика» (blackbox).

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

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

1. Направленность тестирования. Программист может тестировать программу по частям, разрабатывать специальные тестовые подпрограммы, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как «стеклянный ящик».

2.Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы. Ниже описано, как отслеживать степень охвата программного кода про­веденными тестами.

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

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

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

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

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

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

Структурное тестирование является одним из видов тестирования «стеклянного ящика». Его главной идеей является правиль­ный выбор тестируемого программного пути. В противоположность ему функциональное тестирование относится к категории тестиро­вания «черного ящика». Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко.

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

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

3. Разработка справочной системы программного продукта. Создание документации пользователя

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

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

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

У хорошо документированного ПП имеются следующие преимущества.

1. Легкость использования. Если ПП хорошо документирован, то его гораздо легче применять. Пользователи его быстрее изучают, делают меньше ошибок, а в результате быстрее и эффективнее выполняют свою работу.

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

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

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

1. Назначение технологии программирования. История развития технологии программирования. Типы программных проектов. Составные части технологии программирования. Проект, продукт, процесс и персонал

2. Жизненный цикл программы. Циклический характер разработки. Основные понятия технологии программирования. Процессы и модели. Фазы и витки. Вехи и артефакты. Заинтересованные лица и работники.

3. Выявление и анализ требований. Требования к программному обеспечению . Схема разработки требований. Управление требованиями.

4. Архитектурное и детальное проектирование. Реализация и кодирование. Тестирование и верификация . Процесс контроля качества. Методы «белого ящика» и «чёрного ящика». Инспектирование и обзоры. Цели тестирования. Верификация, валидация и системное тестирование. Сопровождение и продолжающаяся разработка.

5. Модели процесса разработки. Водопадные и конвейерные модели. Спиральные и инкрементные модели. Гибкие модели процесса разработки.

6. Конструирование модели процесса. Выявление требований к процессу. Используемые фазы, вехи и артефакты. Выбор архитектуры процесса. Порядок проведения типового проекта . Документированные процедуры.

7. Модели команды разработчиков. Коллективный характер разработки. Оптимальный размер команды. Подчиненность участников проекта. Развитие команды и развитие персонала. Специализация, кооперация и взаимодействие.

8. Модели команды разработчиков. Иерархическая модель команды. Метод хирургической бригады. Модель команды равных.

9. Природа программирования. Наука программирования. Искусство программирования. Ремесло программирования. Парадигмы программирования. Структурное программирование. Логическое программирование. Объектно-ориентированное программирование.

10. Программная архитектура. Событийное управление. Архитектура клиент/сервер. Службы. Трёхслойная архитектура. Проектирование программ. Концептуальное проектирование. Логическое проектирование. Детальное проектирование.

1. Новиков подходы к разработке ПО» http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Экстремальное программирование. – Спб.: Питер, 2002.

3. Технология разработки программного обеспечения. – СПб. : Питер, 2004.

4. Брукс-мл. проектируются и создаются программные комплексы. М.: Наука, 1975; новое издание перевода: Мифический человеко-месяц. СПб.: СИМВОЛ+, 1999.

5. Алгоритмы + структуры данных = программы. М., Мир, 1978.

6. Систематическое программирование. Введение. М.: Мир, 1977.

7. Структурное программирование. М.: Мир, 1975.

8. Дисциплина программирования. М.: Мир, 1978.

9. Технологии разработки программного обеспечения. – СПб.: Питер, 2002.

10. Терехов программирования. М.: БИНОМ, 2006.

11. Рамбо Дж. Унифицированный процесс разработки программного обеспечения. СПб: Питер, 2002.

Экономическая теория для менеджеров

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

Курс экономической теории : учебник для вузов / Под ред. . –Киров: «АСА», 2004. Колемаев -математическое моделирование. Моделирование макроэкономических процессов и систем: учебник. М.:ЮНИТИ-ДАНА, 2005. Бажин кибернетика. Харьков: Консул, 2004. Леушин практикум по методам математического моделирования: учебное пособие . Нижегородский гос. техн. унив.- Н. Новород, 2007. Политикам об экономике: Лекции нобелевских лауреатов по экономике. М.: Современная экономика и право, 2005. Черемных. Продвинутый уровень: Учебник.-М.:ИНФРА-М, 2008. Эволюция институтов миниэкономики. Институт экономики УРО РАН,- М.: Наука, 2007.

Технологии разработки и принятия управленческих решений [ Н]

Принятие решений как основа деятельности менеджера. Введение в теорию принятия решений. Основные понятия теории принятия решений. Модели управления бизнесом и их влияние на принятие решений. Различные способы классификации решений. Классификации: по степени формальности, по степени рутинности, по периодичности, по срочности, по степени достижения целей, по способу выбора альтернативы. Основные методы принятия решений. Волевые методы принятия решений. Цели принятия решений. Время при поиске решений. Основные ошибки Математические методы принятия решений. Математические аспекты теории принятия решений. Исследование операций. Математический подход к принятию решений. Дерево решений. Модели разработки и принятия решений. Теория игр. Математические методы принятия решений. Математические аспекты теории принятия решений. Модели теории очередей. Модели управления запасами. Модель линейного программирования. Транспортные задачи. Имитационное моделирование. Сетевой анализ. Экономический анализ. Ограниченность рациональных моделей. Особенности разработки и принятия решений в группе. Метод определения групповой сплоченности на основе степени связности множеств. Методики принятия коллективного решения. Метод консенсуса. Методы голосования. Творческие методы принятия решений. Мозговой штурм. Конференция идей. Корабельный совет. Метод «Мысленных шляп» по де-Боно. Теория решения изобретательских задач (ТРИЗ). Идеальное конечное решение. Примеры задач и их решения при помощи ТРИЗ. Применение методов ТРИЗ при принятии уникальных и творческих решений. Методы разработки идей решений и их адаптация к ситуации. Модель дерева целей . Стратегия согласования интересов. Формирование решений по согласованию интересов. Методы определения интересов контрагентов . Системы поддержки принятия решений (экспертные системы). История создания систем принятия решений. Классификация систем принятия решений. Типовая структура экспертной системы. Способы представления знаний. Способы логического вывода. Применение экспертных систем на практике.

И. Теория принятия решений: учебник. - М.: Экзамен, 2006. - 573 с. И. Принятие решений. Теория и методы разработки управленческих решений. Учебное пособие. - М.: МарТ, 2005. - 496 с Г. Разработка управленческого решения - М.: Издательство «Дело», 2004 г. - 392 с. Г. Экспертные оценки и принятие решений.- М.: Патент, 1996. - 271 с. Таха // Введение в исследование операций = Operations Research: An Introduction. - 7-е изд. - М.: «Вильямс», 2007. - С. 549-594. Г. Тейл. Экономические прогнозы и принятие решений. М.: «Прогресс» 1970. К. Д. Льюис. Методы прогнозирования экономических показателей. М.: «Финансы и статистика» 1986. Г. С. Кильдишев, А. А. Френкель. Анализ временных рядов и прогнозирование. М.: «Статистика» 1973. О. Ким, Ч. У. Мьюллер, У. Р. Клекка и др. Факторный, дискриминантный и кластерный анализ. М.: «Финансы и статистика» 1989. Эффективный менеджер. Книга 3. Принятие решений. – МИМ ЛИНК, 1999 Туревский и управление автотранспортным предприятием. - М.: Высшая школа, 2005. , ; под ред. . Системный анализ в управлении: учебное пособие. – М.: Финансы и статистика, 2006. , Тиньков: учебное пособие. – М.: КНОРУС, 2006.

Моделирование бизнес-процессов в интегрированных системах менеджмента

По каким принципам выделяют бизнес-процессы? В чем заключается проблема целостного описания бизнес-процессов. Что такое система, какими свойствами она обладает? Роль системного анализа в моделировании бизнес-процессов? Процесс, как объект управления. Окружение процесса. Основные элементы бизнес-процесса. Достоинства и недостатки функционального и процессного менеджмента. Управленческий цикл PDCA. Этапы цикла управления процессами. Цикл PDCA и реализация требований стандарта ISO 9001:2008. Методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). Сущность. Основные положения. Как представляется функциональная модель деятельности в методологии IDEF0? Что обозначают работы в диаграммах функциональной модели, как они отображаются по методологии IDEF0? Для чего предназначены стрелки в диаграммах функциональной модели, каковы их типы и виды? Методология DFD. Сущность. Основные компоненты диаграмм DFD. В чем особенности DFD-диаграмм, что в них описывается? В чем особенности объектов DFD-диаграмм? Что обозначают стрелки на диаграмме DFD? Методология IDEF3. Сущность. Средства документирования и моделирования. В чем особенности IDEF3-диаграмм, что в них описывается? В чем особенности объектов IDEF3-диаграмм? И стрелок? Классификация процессов. Типовые бизнес-процессы. Реинжиниринг и его технология. Когда целесообразно применять реинжиниринг при управлении компанией? Мониторинг и измерение процессов. Показатели процессов организации. Численная и рейтинговые оценки процессов.

"Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1)Диалог-МИФИ" 2003 "Создание информационных систем с AllFusion Modeling Suite" изд. "Диалог-МИФИ" 2003 "Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как?" изд. "Диалог-МИФИ" 2004 Дубейковский моделирование с AllFusion Process Modeler (BPwin). изд. "Диалог-МИФИ" 2007 Д. Марка, К. МакГоуэн "Методология структурного анализа и проектирования SADT" 1993 г. классический труд по методологии SADT. Черемных анализ систем: IDEF-технологиис, Моделирование и анализ систем. IDEF-технологии. Практикум. M.: Финансы и статистика, 2001. , “Структурные модели бизнеса: DFD-технологии” http://www. /Level4.asp? ItemId=5810 "Теория и практика реорганизации бизнес-процессов"2003/ P50.1.. Методология функционального моделирования. М.: Госстандарт России, 2000. http://www. IDEF0, IDEF3, DFD http://www. Моделирование бизнес-процессов средствами BPwin http://www. /department/se/devis/7/ IDEF0 в моделировании бизнес-процессов управления http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Оценка эффективности программных продуктов

1. Архитектура ИТ

2. Домены процессов управления.

3. Перечень процессов домена Планирование и Организация

4. Перечень процессов домена Приобретение и Внедрение

5. Перечень процессов домена Эксплуатация и Сопровождение

6. Перечень процессов домена Мониторинг и Оценка

7. Характеристика уровней модели зрелости процессов

9. KPI и KGI их взаимосвязь и назначение

1. 10.Общие меры контроля в ИТ и меры контроля приложений. Зоны ответственности и обязанности бизнеса и ИТ.

Cobit 4.1 российское издание.

Правовое регулирование создания и использования интеллектуальной собственности

1. Перечислите интеллектуальные права на результаты интеллектуальной деятельности и раскройте их содержание.

2. Перечислите виды договоров по распоряжению исключительным правом. Охарактеризуйте каждый из указанных договоров по распоряжению исключительным правом.

4. Охарактеризуйте основные положения правовой охраны Программы для ЭВМ как объекта авторского права .

5. Сравните основные положения правовой охраны Базы данных как объекта авторского права и как объекта смежных прав.

6. Охарактеризуйте условия патентоспособности объектов патентных прав: изобретений; полезных моделей; промышленных образцов.

7. Раскройте содержание критериев патентоспособности изобретения: новизна; изобретательский уровень; промышленная применимость.

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

9. Дайте определение «ноу-хау» и перечислите условия, при создании которых возникает и осуществляется правовая охрана секретов производства.

10. Перечислите охраняемые средства индивидуализации и дайте их сравнительную характеристику.

1. , Право интеллектуальной собственности в Российской Федерации, учебник // М, Проспект, 2007 г.

2. , Право интеллектуальной собственности, учебное пособие // М, РИОР, 2009 г.

Управление проектами и разработкой ПО [ И]

Что такое методология, зачем она нужна. Общая структура методологии, основные элементы методологии. Принципы конструирования собственной методологии. Примеры различных артефактов, ролей, компетенций, граничных условий. Структура методологии по Коуберну, метрики методологии. Критерии проекта по Коуберну. Критерии выбора методологии, матрица Коуберна. Жизненный цикл проекта. Водопадная и итерационные модели жизненного цикла. Границы применимости для водопадной и итерационной моделей. RUP как пример итерационной методологии. Основные концепции RUP, границы применимости. Роль человека в разработке ПО. Гибкие методологии, основные принципы гибких методологий. Причина возникновения гибких методологий. Scrum как пример гибкой методологии. Роли, артефакты, деятельности в Scrum. Границы применимости Scrum. Экстремальное программирование (XP) Идеи, ценности, основные практики, границы применимости. Сходства и различия между Scrum и XP. Сбор и управление требованиями. Основные практики, термины, принципы. Подходы к документированию проекта и продукта, основные виды документов. Примеры практик по управлению требованиями из рассмотренных в курсе методологий. Планирование разработки ПО. Типы планов, управление риском, популярные риски. Примеры практик по планированию разработки из рассмотренных в курсе методологий. Тестирование при разработке ПО. Понятие сборки (билда) программного продукта. Основные методы тестирования, термины. Примеры практик по тестированию из рассмотренных в курсе методологий. Понятие сборки (билда), способы хранения кода, инструменты. Два принципа организации работы с системой контроля версий. Особенности процесса выпуска/выкладки продукта для разных категорий продуктов, примеры практик. Современные концепции архитектуры ПО, многоуровневые архитектуры, критерии архитектуры. Список необходимых решений при проектировании ПО, подходы к выбору системы хранения данных.

Кент Бек - Экстремальное программирование Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы. Том де Марко - Deadline. Роман об управлении проектами. Том де Марко, Тимоти Листер - Вальсируя с медведями. Том де Марко, Тимоти Листер - Человеческий фактор_ успешные проекты и команды. Алистер Коуберн - Каждому проекту своя методология. Алистер Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения. Андрий Орлов - Записки автоматизатора. Профессиональная исповедь. Филипп Крачтен - Введение в Rational Unified Process. Хенрик Книберг - Scrum и XP: заметки с передовой. Презентации лекций по курсу

Информатика, кибернетика и программирование

Итерация N Унифицированный процесс разработки программного обеспечения USDP Модель вариантов использования описывает случаи в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами Модель развертывания описывает распределение программного обеспечения по компьютерам.

Занятие №20
Общие принципы и подходы к разработке ПО

Модели разработки ПО

  1. Водопадная
  2. Каскадная модель
  3. Спиральная
  4. Экстремальное программирование
  5. Инкрементальная
  6. Методология MSF

Водопадная модель

Спиральная модель

Инкрементальная разработка

Анализ требований

Проектирование

Реализация

Компонентное

тестирование

Интеграция

Тестирование

единого целого

Итерация 1 Итерация 2 …. Итерация N

Унифицированный процесс разработки программного обеспечения (USDP)

  1. Модель вариантов использования, описывает случаи, в которых приложение будет использоваться.
  2. Аналитическая модель описывает базовые классы для приложения.
  3. Модель проектирования описывает связи и отношения между классами и выделенными объектами
  4. Модель развертывания описывает распределение программного обеспечения по компьютерам.
  5. Модель реализации описывает внутреннюю организацию программного кода.
  6. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Методология MSF

Типичные компоненты архитектуры программного продукта и типичные требования к ПО

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

Надежность – способность системы противостоять различным отказам и сбоям.

Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.

Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.

Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.


А также другие работы, которые могут Вас заинтересовать

57355. Многообразие органических соединений, их классификация. Органические вещества живой природы 48.5 KB
Многообразие органических соединений определяется уникальной способностью атомов углерода соединяться друг с другом простыми и кратными связями образовывать соединения с практически неограниченным числом атомов связанных в цепи циклы бициклы трициклы полициклы каркасы и др.
57359. Обработка словесных информационных моделей 291 KB
Основные понятия: модель; информационная модель; словесная информационная модель; аннотация; конспект. Конспект Конспект от лат. Создайте конспект к 2. Сохраните документ в собственной папке под именем Конспект.
57361. Число і цифра 3. Порівняння чисел у межах 3. Написання цифри 3. Порівняння довжини й товщини предметів 35.5 KB
Скільки всього тварин Хто стоїть першим Хто стоїть останнім Хто стоїть під номером 1 Хто стоїть під номером 2 Назвіть сусідів їжачка. Хто сусід праворуч білочки Хто сусід ліворуч жирафа Хто є найвищим Хто є найнижчим Хто стоїть посеред тварин Гра Покажи не помились.

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

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:

принцип "разделяй и властвуй" (см. подраздел 2.1.1);

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

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

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

принцип непротиворечивости - обоснованность и согласованность элементов системы;

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

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

DFD (Data Flow Diagrams) - диаграммы потоков данных;

SADT(Structured Analysis and Design Technique - метод структурного анализа и проектирования,) - модели и соответствующие функциональные диаграммы;

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".

Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в CASE-средствах виды моделей.

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели "AS-IS" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

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

Предметной областью для большинства примеров диаграмм, приведенных в данной главе, является налоговая система РФ, наиболее полное описание которой содержится в Налоговом кодексе РФ. Информационные технологии, применяемые в налоговой системе РФ, имеют определенные особенности.

Итак, сущность структурного подхода к разработке ПО ЭИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу-вверх», от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

1. Принцип «разделяй и властвуй»;

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, т.к. игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта»). Основными из этих принципов являются:

1. Принцип абстрагирования- выделение существенных аспектов системы и отвлечение от несущественных.

2. Принцип непротиворечивости,обоснованность и согласованность элементов системы.

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

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

· DFD (Data Flow Diagrams) - диаграммы потоков данных;

· SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы: нотации IDEF0 (функциональное моделирование систем), IDEF1х (концептуальное моделирование баз данных), IDEF3х (построение систем оценки качества работы объекта; графическое описание потока процессов, взаимодействия процессов и объектов, которые изменяются этими процессами);

· ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:

1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).

2. Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).