лабраторная работа 1. Лабораторная работа 1 Структурный анализ и проектирование программных систем
 Скачать 369.83 Kb.
|
|
Лабораторная работа №1 Структурный анализ и проектирование программных систем Понятие жизненного цикла (ЖЦ) программного обеспечения (ПО) ре- гламентирует основные процессы его разработки и эксплуатации. ЖЦ фор- мулируется как модель создания и использования ПО, отражающая его раз- личные состояния, начиная с момента возникновения необходимости в дан- ном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей. В ЖЦ ПО выделяются следующие основные этапы [1]: 1. Анализ требований и постановка задачи; 2. Анализ и исследование задачи, модели, проектирование; 3. кодирование (программная реализация); 4. тестирование и отладка, 5. эксплуатация и сопровождение. ЖЦ образуется в соответствии с принципом нисходящего проектирова- ния и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с измене- ниями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ порождается определенный набор документов и техниче- ских решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается ве- рификацией порожденных документов и решений с целью проверки их соот- ветствия исходным. Модель ЖЦ формулирует порядок исполнения этапов в ходе разработки, а также правила перехода от одного этапа к другому. На литературе по про- граммной инженерии выделяют следующие модели как основные вехи в ис- тории развития принципов анализа: 1. КАСКАДНАЯ МОДЕЛЬ была предложена Уинтсоном Ройсом в 1970- м году. Эту модель принято называть классической и она предполагает, что переход на следующий этап после полного окончания работ по преды- дущему этапу (рис.1). К преимуществам каскадной модели относят: - Четкую регламентацию выполнения этапов проекта - Возможность оценки качества продукта на каждом из этапов В то же время у этой модели имеются существенные недостатки: - Модель не предусматривает обратных связей между этапами - Она не соответствует реальным условиям разработки программного продукта Рисунок 1. – Каскадная модель жизненного цикла ПО 2. ПОЭТАПНАЯ МОДЕЛЬ С ПРОМЕЖУТОЧНЫМ КОНТРОЛЕМ - итерационная модель разработки ПО с циклами обратной связи между эта- пами. Преимущество такой модели заключается в том, что межэтапные кор- ректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки. Рисунок 2. – Поэтапная модель с промежуточным контролем. В этой модели предусмотрен промежуточный контроль за счет обратных связей. По итогам каждого из этапов возможен откат на предыдущий (-ие) шаги в случае, если выход этапа плохо верифицируем или в процессе разра- ботки изменились исходные требования к системе. При работе с реальным проектом в классической каскадной модели обычно возникают проблемы при обнаружении недоработок и ошибок, допущенных на ранних этапах. Строй- ность процесса разработки нарушают также изменениями окружения, в кото- ром разрабатывается ПО, такие как изменения требований заказчика, изме- нения политик разрабатывающей или эксплуатирующей организации, изме- нения отраслевых стандартов, появление конкурирующих продуктов и пр. Подобные нелинейности в процессе разработки учитываются в модели с промежуточным контролем. Недостатком поэтапной модели в сравнении с классической можно назвать существенное (до 10 раз) увеличение затрат на реализацию проекта. 3. СПИРАЛЬНАЯ МОДЕЛЬ - делает упор на начальные этапы ЖЦ (рис.3): анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Модель строится на четырех основных операциях, соответствующих квадрантам спирали: - Планирование – определяет цели разработки, формулирует варианты решения и накладывает ограничения на работу системы; - Анализ рисков – заключается в оценке рисков для различных вариантов решения; - Конструирование – непосредственная разработка продукта на новом уровне; - Оценивание – предполагает оценку результатов, достигнутых на этапе конструирования. Каждый виток спирали соответствует поэтапной модели создания фраг- мента или версии программного изделия, на нем уточняются цели и характе- ристики проекта, определяется его качество, планируются работы следующе- го витка спирали. Таким образом, углубляются и последовательно конкрети- зируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. При этом на этапе конструирование на каждом витке спирали может включать полный каскад классического жиз- ненного цикла. Специалистами отмечаются следующие преимущества спиральной модели: 1. накопление и повторное использование программных средств, моделей и прототипов; 2. ориентация на эволюционное развитие и модификацию ПО в процессе его проектирования; 3. позволяет оценивать риски и издержки в процессе проектирования на каждом витке эволюции разработки. Недостатками спиральной модели можно считать сложность оценки времени процесса разработки и необходимость более тесного вовлечения за- казчика в процесс разработки. Рисунок 3. – Спиральная модель жизненного цикла ПО, Главная особенность индустрии ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невы- сокой сложности и трудоемкости последующих этапов. Более того, нерешен- ные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти эта- пы более подробно. Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО: • функциональных возможностей, включая характеристики производи- тельности и среды функционирования компонента; • внешних интерфейсов; • спецификаций надежности и безопасности; • эргономических требований; • требований к используемым данным; • требований к установке и приемке; • требований к пользовательской документации; • требований к эксплуатации и сопровождению. Требования к ПО оцениваются исходя из критериев соответствия требо- ваниям к системе, реализуемости и возможности проверки при тестировании. ЭТАП ПРОЕКТИРОВАНИЯ дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимо- связей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как "(итерационный) процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим тре- бованиям". Обычно этот этап разделяют на два подэтапа: Этап проектирования ПО включает задачи (для каждого компонента ПО): • трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав ее компонентов; • разработку и документирование программных интерфейсов ПО и баз данных; • разработку предварительной версии пользовательской документации; • разработку и документирование предварительных требований к тестам и планам интеграции ПО. Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам. Детальное проектирование ПО включает следующие задачи: 1. описание компонентов и интерфейсов между ними на более низ- ком уровне, достаточном для их последующего самостоятельного кодирова- ния и тестирования; 2. разработку и документирование детального проекта базы данных; 3. обновление (при необходимости) пользовательской документа- ции; 4. разработку и документирование требований к тестам и плана те- стирования компонентов ПО; 5. обновление плана интеграции ПО. В результате деятельности на этапах анализа и проектирования должен быть получен проект системы, содержащий достаточно информации для реа- лизации системы на его основе в рамках бюджета выделенных ресурсов и времени. Жизненный цикл ПО в настоящее время представляет собой набор усто- явшихся процессов, содержание и последовательность выполнения которых регламентируются. Федеральным агентством по техническому регулирова- нию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 при- нят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла про- граммных средств», идентичный международному стандартуISO/IEC 12207:2008 «System and software engineering — Software life cycle processes». Разработчики сложных программных (и не только программных) систем уже достаточно давно осознали необходимость создания унифицированной методики анализа бизнес-процессов решаемых задач для упрощения их по- нимания и дальнейшего программного описания. Наиболее эффективные ме- тоды структурного системного анализа, зарекомендовавшие себя при анализе задач самой разнообразной тематики стали государственными стандартами по анализу и проектированию сложных объектов и процессов. Примерами здесь могут быть: система стандартов Icam Definition в США, SSADM – ме- тодология структурного системного анализа и проектирования, стандартизо- ванная в Великобритании или отечественный стандарт Р 50.1.028-2001 «Ме- тодология функционального моделирования». Icam Definition представляет собой оформление в виде стандарта технологии анализа сложных систем SADT (Str uctured Analysis and Design Technique), разработанной в период с 1969 по 1973 годы группой аналитиков во главе с Дугласом Т. Россом [мато- рин]. Рассмотрим основные принципы структурного анализа по методике «3- V iew Modelling», предложенной Томом Де Марко в 1979г. Структурным анализом принято называть метод исследования задачи, которое начинается с ее общего обзора и затем она детализируется, приобретая иерархическую структуру со все большим числом уровней. На каждом из уровне детализа- ции описания решение задачи разбивается на более мелкие подзадачи, рас- сматриваемые как «черные ящики», принимающие на входе исходные дан- ные и формирующие в результате своей работы некоторый результат. На следующем уровне иерархи каждая из задач – «черных ящиков» анализиру- ется и в свою очередь разбивается на подзадачи более низкого уровня иерар- хии. Итерационный процесс подобного разбиения приводит к формулирова- нию простых, понятных и эффективно реализуемых на выбранном языке программирования задач. Общая процедура структурного анализа включает следующие основные этапы: - декомпозиция задачи на подзадачи, формирование структур данных и их описание; - определение качественных и количественных характеристик (показа- телей) выделенных подзадач (оценивание структур); - формирование критериев и оценка эффективности выделенных подза- дач; - принятие решения o необходимости совершенствования структурных характеристик полученной декомпозиции. В методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие средства описания процессов предмет- ной области: 1. DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов; 2. ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь" 3. STD (State Transition Diagrams) - диаграммы переходов состояний. Взаимодействие перечисленных диаграмм для формирование комплекс- ной схемы анализируемой(моделируемой) системы приведено на рис. 4. Диаграммы потоков данных (Data Flow Diagrams — DFD) представ- ляют собой иерархию функциональных процессов, связанных потоками дан- ных. Цель такого представления [3]— продемонстрировать, как каждый про- цесс преобразует свои входные данные в выходные, а также выявить отно- шения между этими процессами. В результате построения диаграммы анали- тик получает сеть (граф), узлы которой представляют выполняемые процес- сы, поставщиков и потребителей данных, хранилища данных, а соединяющие их направленные стрелки (ребра) описывают передаваемые потоки данных. Для построения DFD традиционно используются две различные нота- ции, соответствующие методам Йордона-ДеМарко и Гейна- Сэрсона. Рассмотрим основные графические обозначения, приняты в каждой из этих нотаций. Таблица 1. Основные элементы диаграммы потоков данных Элемент Нотация Йордона-ДеМарко Нотация Гейна-Сэрсона Поток данных Процесс Хранилище Внешняя сущ- ность Рисунок 4.- Модель структурного анализа программной системы Поток данных 1 Хранилище Процесс 1 Управляю- щий процесс 1 STD- диаграмма Словарь данных Специфи- кация про- цесса ERD- диаграмма Имя Имя Имя Номер Имя Номер Имя Имя Имя Имя Рассмотрим назначение каждого из представленных в таблице 1 эле- ментов. Потоки данных моделируют процесс передачи информации из одной части системы в другую. Потоки данных могут связывать два процесса обра- ботки информации или процесс обработки данных с хранилищем данных. Потоки на диаграммах обычно изображаются именованными стрелками, ори- ентация которых указывает направление передачи информации, а имя отра- жает тип или назначение передаваемой информации. Активным элементом схемы является процесс. Назначение процесса состоит в обработке входных потоков и формировании на их основе выход- ных в соответствии с действием, задаваемым именем процесса. Это имя обычно содержит описание выполняемых процессом действий. С учетом то- го, что структурная декомпозиция представляет собой разбиение по действи- ям, название должно состоять из глагола в неопределенной форме с после- дующим дополнением (например, Сформировать отчет, Вычислить стои- мость, Найти среднее значение). Процессы индексируются уникальным но- мером в рамках диаграммы. Этот номер в совокупности с именем самой диа- граммы может служить уникальной ссылкой на процесс в рамках всей моде- ли. Объект схемы, называемый хранилищем (накопителем) данных указы- вает, в каком месте (на каком этапе обработке) данные подлежат сохранению в памяти после обработки одним из процессов. Хранилище инвариантно по времени и порядку извлечения информации: после сохранения данных они хранятся сколь угодно долго и извлекаются в произвольный момент времени. Имя хранилища должно указывать на его содержимое и определяется именем существительным. Еще один тип элементов DFD-диаграммы – внешняя сущность или терминатор. Объекты этого типа описывают сущность, лежащую вне кон- текста системы, которая не входит в состав системы и является источником или приемником данных. Ее имя задается существительными, например, За- казчик, Банк, Склад. Объекты, представленные такими узлами, с точки зре- ния DFD-диаграммы пассивны, они не участвуют в обработке информации. Процесс описания системы с использованием DFD-схем итеративен. На верхнем уровне представляются самые обобщенные процессы обработки данных между поставщиком и потребителем. Детализация этих обобщенных процессов осуществляется на схемах следующих уровней, как это показано на рис.5. На рис. 6 представлен фрагмент возможной DFD-диаграмм для систе- мы бронирования билета в кинотеатр. В процессы бронирования места выделены три процесса: – обработки заявок, в котором должен осуществлять диалог с покупа- телем, отображаться список сеансов, схема зала для выбранного сеанса, под- тверждаться сделанный покупателем выбор; - проверки наличия мест, который должен осуществлять поиск и филь- трацию мест в соответствии с высказанными предпочтениями покупателя; - оформления билета, в котором выбранные места резервируются за покупателем с занесением данных в схему зала на выбранный сеанс. Каждый из перечисленных процессов может быть детализирован в виде DFD- диаграммы следующего уровня. Представленная на рис. 6 схема использует два хранилища. В одном должно храниться расписание сеансов, а в другом – схема зала с перечнем Рисунок 5.-Иерархическая схема описания системы с использованием dfd-диаграмм Поставщик информации Процесс P Процесс P1 A DFD0 Потребитель информации B A Процесс P2 Процесс PN B C D E … Процесс P21 C Процесс P21 Процесс P2L D F G H … DFD1 DFD2 Информация о сво- бодных местах Рисунок 6.-Фрагмент DFD-диаграммы для системы бронирования билетов Список сеансов Заявка Зритель 1 Места на сеанс 2 Список сеансов Обработать заявку 1 Проверить наличие мест 2 Выписать билет 3 Информация о занятых местах Электрон- ный билет Запрос на поиск мест Инф. о сво- бодных ме- стах Инф. о вы- бранных местах занятых и свободных мест. Потоки данных, соединяющие процессы, храни- лища и внешнюю сущность (покупателя), представлены именованными стрелками. Они последовательно передают информацию в различной фазе обработки до формирования конечного результата – электронного билета, подтверждающего бронь. На рис. 7 представлена dfd-диаграмма для системы поддержки продажи продукции. Как видно из схемы, поддерживается три хранилища данных: принятых заказов, зарегистрированных клиентов и выставленных счетов. Информацию в этих хранилищах используют и изменяют процессы, отвеча- ющие за обработку заказов клиентов, контроля оплаты счетов и доставки продукции клиентам. Клиенты выступают внешними сущностями модели. Редкая многопользовательская программная система сегодня обходится без подсистемы аутентификации/регистрации пользователей. На рис. 8 при- ведена возможная dfd-диаграмма работы этой подсистемы. Диаграмма на рис. 8 детализирует процесс входа пользователя в про- граммную систему, разделяя его на аутентификацию уже зарегистрированно- го пользователей и регистрацию новых. Процесс регистрации детализирован более крупно, в нем выделены подпроцессы контроля корректности пред- ставленных пользователем данных (e-mail, телефон, используемые в имени символы, длина пароля и т.п.), проверки незанятости предложенного пользо- вателем имени регистрации и непосредственно сохранения данных в храни- лище пользователей. Еще одним хранилищем, используемым процессами на диаграмме, является журнал регистрации вошедших пользователей. Продукция Рисунок 7.-Фрагмент DFD-диаграммы продажи продукции Заказ Клиент 1 Заказы 2 Счета Обработать заказ 1 Доставка продукции 2 Контроль оплаты 3 Данные счета Инф-я о заказе Инф. о за- казе Инф. о клиенте 3 Клиенты Склад Клиент Продукция Инф. о клиенте Счета, платежные документы Данные счета Для более полного описания требований к программной системе dfd- диаграмму необходимо дополнять словарями данных и спецификациями процессов. Словари данных призваны описать формат и содержимое потоков данных. Обычно они содержат: 1. Имя элемента. 2. Псевдоним, альтернативное имя элемента. 3. Где и как используется элемент: перечень использующих его про- цессов, каким образом тот или иной процесс использует элемент (как входной или выходной поток, как элемент памяти). 4. Описание содержимого объекта: словесное описание смыслового содержимого элемента. 5. Дополнительная информация, описывающая типизацию, формат элемента. Язык формального описания словаря данных включает средства для определения имени потока, его типа и атрибутов. Подробнее с этим языком можно познакомиться в [2]. Фрагмент словаря данных для потоков данных «Информация о пользователя» и «Статус регистрации» приведен ниже. Ат- Аутентификатор зарегистрированного пользователя Рисунок 8.- DFD-диаграмма для подсистемы аутентификации пользователя Дата, время, иденти- фикатор пользователя Идентификатор Аутентификатор Пользователь 1 Пользователи 2 Журнал входа пользователей Аутетнтифици- ровать пользова- теля 2 Контролировать вход в систему 1 Регистрация пользователя 3 Инфор- мация о пользо- вателе разрешение/отказ во входе Инф. о поль- зователе верен/неверен аутентификатор статус реги- страции Проверка кор- ректности данных 31 Проверка нали- чия пользова- теля 32 Сохранение данных о поль- зователе 33 Основная си- стема Список зареги- стриро- ванных рибут БНФ для элемента словаря предназначен для описания множеств зна- чений внутренней структуры потока (или хранилища) в нотации БНФ. @Имя=Статус регистрации @ Тип=ПРОСТОЙ, ВНУТРЕННИЙ, ДИСКРЕТНЫЙ ПОТОК ДАННЫХ @Описание=Передает статус заверешния процесса регистрации нового пользователя в системе 1- успех, 0 – отказ @ Процессы=@Регистрация пользователя (выход), @Контролировать вход в систему(вход) @ БНФ=[“0” ! ”1”] @Имя=Информация о пользователе @ Тип=СОСТАВНОЙ, ВНУТРЕННИЙ, ДИСКРЕТНЫЙ ПОТОК ДАН- НЫХ @Описание=Информация о регистрируемом пользователе системы @ Процессы=@Регистрация пользователя (вход), @Контролировать вход в систему(выход) @БНФ=[@Идентификатор+@Пароль+@Полное имя+@Телефон+@E- mail] @ Имя=Идентификатор @Тип= ПРОСТОЙ, ВНУТРЕННИЙ, ДИСКРЕТНЫЙ ПОТОК ДАН- НЫХ @ Описание=Идентификатор пользователя системы @БНФ=[{«a»- «z», «A»- «Z», «_»}50] Для описания процесса используется спецификация, в которой описы- вается вход и выход процесса, алгоритм выполняемых преобразований. Оформление спецификации может быть выполнено с использованием струк- турированного естественного языка, FLOW-диаграммы или блок-схемы ал- горитма. Для описания структуры хранилищ данных используются диаграммы ERD (Entity-Relationship Diagrams, «сущность-связь»). Диаграммы "сущ- ность-связь" дополняют DFD-диаграммы детализируют описания хранилищ данных проектируемой системы включая идентификацию объектов (сущно- стей), свойств этих объектов (атрибутов) и их отношений с другими объекта- ми (связей). Для графического отображения ERD-диаграмм существует не- сколько нотаций: Чена, Баркера. Подробнее с системой обозначений и при- мерами диаграмм в этих нотациях можно ознакомиться, например, в [Венд- ров]. При создании ERD-диаграммы необходимо: идентифицировать сущно- стей системы, определить их атрибуты, выделить первичные ключи, иденти- фицировать отношения между сущностями («один-к-одному», «один-ко- многим», «многие-ко-многим») и избавится от отношений типа «один-ко- многим» путем введения дополнительных ассоциативных сущностей. Пример ERD-диаграммы в нотации IDEF1 (очень популярной для опи- сания баз данных в третьей нормальной форме) для системы бронирования билетов приведен на рис. 9. Для описания динамики поведения системы в структурном анализе ис- пользуются STD-диаграммы (State Transition Diagrams, диаграммы перехода состояний). Диаграммы этого типа отражают изменение состояния объекта с течением времени. Если стрелки на DFD-диаграмме отражают существова- ние взаимодействия и передачу данных между процессами в принципе, то STD- диаграмма призвана показать, как эти взаимодействия разворачиваются во времени. Базовыми понятиями, которыми оперируют диаграммы этого типа, являются состояние и переход. Под состоянием системы понимается набор ее характеристик, описы- вающих определенную устойчивую фазу обработки данных системой. Название состояния должно давать описание этой фазы: Клиент аутентифи- цирован, Место зарезервировано, Билет заказан, Клиенту отказано. Переход означает изменение состояния системы. Обычно он происходит под воздействием некоторого управляющего сигнала от внешней сущности или выработанного внутри системы. В этой связи необходимо сформулиро- вать условие перехода, которое также должно быть отображено на STD- диаграмме. Сама STD-диаграмм строится как граф, в узлах которого распо- ложены состояния, и направленные дуги соответствуют переходам и поме- чаются условием перехода и действием, осуществляющим переход. Для начального знакомства рассмотрим (рис.10) как будет выглядеть STD- диаграмма для процесса перехода через автодорогу (задача, конечно, не совсем компьютерная, но если пофантазировать, впоследствии подобная диа- грамма может быть использована для разработки управляющей программы самостоятельно передвигающегося робота). В качестве ограничений будем считать, что дорога не оснащена светофорами и пешеходными переходами и имеет по одной полосе в каждую сторону и на ней организовано привычное нам правостороннее движение. id Зрителя Логин Фамилия Имя Отчество Адрес эл. почты Льготы Hash пароля Зрители id Сеанса Дата Время id Фильма FK id Зала FK Свободных мест Сеансы id Фильма Название Продолжитель- ность Постер Описание id Зала Номер зала Количество мест Схема зала Фильмы Кинозалы id Места id Сеанса FK Статус места id Зрителя FK Места на сеанс Рисунок 9.-ERD-диаграмма для системы бронирования билетов Рассмотрим STD-диаграмму другого процесса, который уже происходит под управлением вычислительного устройства. Поддержание заданной тем- пературы системой климат-контроля можно описать диаграммой, изобра- женной на рис. 11. На рис. 12 представлен фрагмент возможной STD-диаграммы для си- стемы бронирования билетов. Рисунок 11.- STD-диаграмма для процесса поддержания заданной температу- ры системой климат-контроля Сравнение температур Охлаждение помещения Обогрев поме- щения T c Включить обогрев Проверка времени T c ≥T d Включить обогрев T c >T d Включить охлаждение T c ≤T d Выключить охлаждение t Истек квант времени Обозначения: T c - текущая температура T d – желаемая температура t – текущее время t off – время выключения Рисунок 10.- STD-диаграмма для процесса пересечения автодороги с двусто- ронним движением на участке без светофора и пешеходного перехода Стоим на исходной стороне дороги Стоим на се- редине дороги слева прибли- жается автомо- биль Стоим на месте Перемещаемся к другому участку дороги Полосы движения разделены сплош- ной линией Идем вдоль дороги Справа нет автомобилей Переходим полосу Находимся на противоположной стороне дороги Полосы не разделены сплошной линией Идем вдоль дороги Справа прибли- жается автомо- биль Стоим на месте Слева нет автомобилей И Полосы не разделены сплошной линией Переходим полосу Нотация STD-диаграмм близка математическому аппарату абстрактных автоматов, что позволяет эффективно формализовать их описание. Процесс анализа можно автоматизировать с использованием инстру- ментальных средств. В качестве примера можно привести CASE-средство AllFusion Process Modeler компании Computer Associates, которое предостав- ляет удобный интерфейс для создания диаграмм, позволяет автоматически проверять их целостность и согласованность. Рассмотренные средства структурно-системного анализа хорошо заре- комендовали себя при разработке сложных программных систем, ориентиро- ванных на процедурный стиль программирования. Разработка продуманной модели по рассмотренной технологии позволит существенно сократить время реализации проекта и уменьшить стоимости разработки за счет структурой декомпозиции задачи, которая позволяет избавиться от сложности решаемых задач, свести их до уровня совокупности простых, взаимосвязанных и эф- фективно практически реализуемых подзадач. Структурный анализ не лишен и недостатков, в частности он не может учесть все особенности поведения объектов бизнес-процесса, для очень сложных систем структурные модели становятся громоздкими, структурному подходу не хватает выразительных средств для описания многообразия типов объектов, характера их взаимодействия и динамики поведения. Преодолеть эти недостатки призван альтернативный – объектно-ориентированный под- ход к анализу, который будет рассмотрен в следующей лабораторной работе. Однако, современные тенденции анализа программных систем выражаются в интеграции структурного и объектного подхода [2]. Рисунок 12.-Фрагмент STD-диаграммы для системы бронирования билетов Верные аутен- тификацион- ные данные Выбор места Команда «Отмена» Выбран сеанс Пользователь вошел « гостем» Пользователь аутентифицо- рован Неверные аутентификаци- онные данные Изучение расписания сеансов Команда «Просмот- реть сеансы» Изучение схемы зала Команда «Выход» Выписан билет Команды «Сохра- нить», «Отмена» Контрольные вопросы 1. Перечислите основные этапы жизненного цикла программного обеспечения. 2. Какие модели жизненного цикла ПО вам известны, каковы их основные отличительные особенности? 3. Что характеризует структурный подход к анализу программных систем? Какие основные диаграммы описывают модель ПО при структурном анализе? 4. С какой стороны описывает программную систему DFD- диаграмма? Какие основные элементы она использует? 5. Что такое ERD диаграмма? Для каких целей она включается в общую модель структурного анализ программной системы? 6. Назначение STD-диаграммы. Структура STD диаграммы. 7. Расскажите о результатах анализа программной системы из свое- го варианта к лабораторной работе. 8. Варианты заданий к лабораторной работе Задание: провести структурный анализ и построить DFD- диаграммы для заданной предметной области. Одна диаграмма должна представлять обоб- щенную работу системы, одна – детализацию одного из процессов (обе диа- граммы должны включать 5-7 процессов). Построить STD-диаграмму систе- мы. 1. Система коллективного редактирования документов. Система должна предоставлять возможность группе зарегистрированных пользователей выполнять совместное редактирование текстового документа. Исправ- ления, внесенные каждым из пользователей (добавление, удаление, ис- правление фрагментов текста) отображаются отдельным цветом. Фик- сация изменений в окончательном или промежуточном варианте доку- мента разрешена одному из пользователей со статусом редактора. 2. Система резервного копирования файлов. Система должна по заданию пользователя осуществлять резервное копирование файлов из заданных папок в указанное хранилище по составленному расписанию. Система функционирует как многопользовательская, каждый пользователь мо- жет составить собственные список файлов и папок для копирования и расписание. 3. Система автоматизации обработки заявок клиентов на обслуживание средств IT. Клиенты имеют возможность оставлять заявки на обслужи- вание вычислительной техники, оператор принимает заявку, фиксирует ее в журнале, сообщают клиенту о результатах обработки заявки. Тех- ники принимают свободные заявки, делают отметки о выполнении по окончании работ. Система должна обеспечивать: фильтрацию, сорти- ровку заявок, формировать отчеты. 4. Система автоматизированного тестирования. Преподаватель имеет возможности: вести базу вопросов, сформировать из них тесты, под- твердить регистрацию студента, составить список группы, просмотреть результаты тестирования. Студент может: зарегистрироваться в систе- ме, пройти тест, просмотреть результаты тестирования. 5. Система электронных online-конференций. По инициативе одного из зарегистрированных пользователей создается конференция, в которой могут участвовать другие зарегистрированные организатором пользо- ватели. Организатор может продемонстрировать медиаконтент участ- никам конференции, а затем в режиме chat'а ответить на их вопросы. 6. Система электронных аукционов. Зарегистрированные пользователи могут выставить лот на продажу, назначив начальную стоимость и дату торгов. Лот может снять с торгов сам продавец или администратор. Любой зарегистрированный пользователь может записаться на участие в торгах по лоту. Торги идут по схеме повышения стоимости в автома- тическом режиме. Лот достается предложившему наибольшую цену. 7. Антивирус-ревизор. Система фиксирует состояние заданных пользова- телем папок и в случае изменения их состояния (количество файлов, размер, дата создания или модификации, атрибуты) отмечает изменен- ные элементы файловой системы как подозрительные. Проверка состо- яния папок осуществляется либо по расписанию, либо команде пользо- вателя. 8. Свободная электронная библиотеки. Зарегистрированный пользователь имеет возможность добавить новый файл-книгу в базу данных библио- теки, а также получить доступ к другим книгам. В случае платного до- ступа или в обмен на новую книгу пользователь может скачать файл с книгой, иначе – только читать с экрана. Библиотека предоставляет воз- можность поиска книг в библиотеке по различным критериям. 9. Планировщик задач. Система позволяет зарегистрированным пользова- телям формировать и редактировать список задач (исполняемых фай- лов, скриптов) на исполнение по расписанию. Система запускает зада- чи по расписанию и ведет отчет по запущенным задачам. Администра- тор имеет право полного доступа к расписаниям других пользователей. 10. Система проверки оригинальности текста. Система поддерживает биб- лиотеку проиндексированных документов. Операторы могут пополнять библиотеку новыми документами. Зарегистрированные пользователи могут проверить содержимое файлов на степень оригинальности со- держимого – насколько содержимое документа совпадает с содержи- мым документов из базы системы. Литература 9. Технологии разработки программного обеспечения: Учебник/ С. Орлов. — СПб.: Питер, 2002. — 464 с.: ил. 10. Теория систем и системный анализ: Учебное пособие / С.И. Ма- торин.,О.А. Зимовец. – Белгород: Изд-во НИУ «БелГУ», 2012. – 288 с. 11. Вендров, А.М. Проектирование программного обеспечения эко- номических информационных систем. - М.: Финансы и статисти- ка, 2000. – 352c. 12. Хомяков, П.М. Системный анализ: Краткий курс лекций. П.М. Хомяков. - М.: КомКнига, 2006. |