Контрольная работа - Основы алгоритмии и языки программирования

Подождите немного. Документ загружается.

Содержание

Введение...................................................................................................................3

1.Понятие проектирования программного обеспечения.....................................4

2.Виды проектирования..........................................................................................5

3.Пример применения основных методов структурного проектирования

программного обеспечения при разработке текстового редактора....................8

Заключение............................................................................................................14

Список использованной литературы...................................................................16

Введение

Актуальность темы. Существуют различные общие стратегии,

помогающие в проведении работ по проектированию. В отличие от общих

стратегий, методы проектирования более специфичны и, в основном,

предлагают и предоставляют нотации (или наборы нотаций) для

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

необходимо следовать в рамках используемого метода. Таким образом,

методы в данном контексте это не просто некие «слабоформализованные»

или просто частные практические подходы или техники. Методы здесь

являются более общими понятиями, это - методологии, сконцентрированные

на процессе (в частности, проектирования) и предполагающие следование

определенным правилам и соглашениям, в том числе – по используемым

выразительным средствам. Такие методы полезны как инструмент

систематизации (иногда, формализации) и передачи знаний в виде общего

фреймворка (то есть комплексного набора понятий, подходов, техник и

инструментов) не только для отдельных специалистов, но для команд и

проектных групп программных проектов.

Цель работы – рассмотреть методы и средства структурного анализа и

проектирования программного обеспечения.

Для решения поставленной цели, необходимо решить следующие

задачи:

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

- определить виды программирования;

- рассмотреть методы структурного программирования на примере.

1. Понятие проектирования программного обеспечения

Проектирование программного обеспечения - процесс создания

проекта программного обеспечения (ПО), а также дисциплина, изучающая

методы проектирования.

Проектирование подразумевает выработку свойств системы на основе

анализа постановки задачи, а именно: моделей предметной области,

требований к ПО, а также опыта проектировщика. Требования к ПО

определяют внешние (видимые) свойства программы, рассматриваемой как

чёрный ящик.

Определению внутренних свойств системы и детализации её внешних

свойств собственно и посвящено проектирование. Проектирование ПО

является частным случаем проектирования продуктов и проектирования

систем.В зависимости от класса создаваемого ПО, процесс проектирования

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

средствами его автоматизации. В процессе проектирования ПО для

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

схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат: - Архитектура ПО; - Устройство

компонентов ПО; - Пользовательские интерфейсы.

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

виде комплекса документов под названием «Эскизный проект»,

«Технический проект», в зарубежной - Software Architecture Document,

Software Design Document.

Структурным анализом принято называть метод исследования

системы, начинающийся с ее общего обзора, который затем детализируется,

приобретая иерархическую структуру со все большим числом уровней.

Истомин Е.П., Неклюдов С.Ю., Романченко В.И.Информатики и программирование: Учебник.- М.:

Наука, 2009.- с. 132.

Вендров А.М. Практикум по проектированию программного обеспечения.- М.: БЕК, 2009.- с. 110.

Истомин Е.П., Неклюдов С.Ю., Романченко В.И.Информатики и программирование: Учебник.- М.:

Наука, 2009.- с. 140.

Для таких методов характерно: - Разбиение системы на уровни с

ограничением числа элементов. - Ограниченный контекст, включающий

лишь существенные на каждом уровне детали. - Использование сторонних

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

результату.

Принципы структурного метода: - принцип «разделяй и властвуй»; -

принцип «иерархического упорядочивания»; - принцип абстрагирования -

выделение существенных аспектов системы и отвлечение от

несущественных; - принцип непротиворечивости; - принцип

структурирования данных.

2. Виды проектирования

Функционально-ориентированное или структурное

проектирование (Function-Oriented – Structured Design).

Это один из классических методов проектирования, в котором

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

функций и, затем, детальной разработке и уточнении этих функций “сверху-

вниз”. Структурное проектирование, обычно, используется после проведения

структурного анализа с применением диаграмм потоков данных и связанным

описанием процессов. Исследователи предлагают различные стратегии и

метафоры или подходы для трансформации DFD в программную

архитектуру, представляемую в форме структурных схем. Например,

сравнивая управление и поведение с получаемым эффектом.

Объектно-ориентированное проектирование (Object-Oriented

Design).

Представляет собой множество методов проектирования,

базирующихся на концепции объектов. Данная область активно

эволюционирует с середины 80-х годов, основываясь на понятиях объекта

(сущности), метода (действия) и атрибута (характеристики). Здесь главную

роль играют полиморфизм и инкапсуляция, в то время, как в компонентно-

ориентированном подходе большее значение придается мета-информации,

например, с применением технологии отражения (reflection). Хотя корни

объектно-ориентированного проектирования лежат в абстракции данных (к

которым добавлены поведенческие характеристики), так называемый

responsibility-driven design или проектирование на основе функциональной

ответственности по SWEBOK (такое противопоставление – достаточно

спорный вопрос, так как функциональная ответственность столь же близка

принципам современного объектно-ориентированного проектирования, сколь

и абстракция данных. Это вопрос эволюционирования взглядов и степени их

консерватизма) может рассматриваться как альтернатива объектно-

ориентированному проектированию.

Проектирование на основе структур данных (Data-Structure-

Centered Design). В данном подходе фокус сконцентрирован в большей

степени на структурах данных, которыми управляет система, чем на

функциях системы. Инженеры по программному обеспечению часто вначале

описывают структуры данных входов (inputs) и выходов (outputs), а, затем,

разрабатывают структуру управления этими данными (или, например, их

трансформации).

Компонентное проектирование (Component-Based Design).

Программные компоненты являются независимыми единицами,

которые обладают однозначно-определенными (well-defined) интерфейсами и

зависимостями (связями) и могут собираться и развертываться независимо

друг от друга. Данный подход призван решить задачи использования,

разработки и интеграции таких компонент с целью повышения повторного

использования активов (как архитектурных, так и в форме кода).

Камаев В.А. Технологии программирования: Учебник для ВУЗов- М.: Приор, 2009.- с. 200.

Кирин М.Н. Программирование. Учебник для начинающих.- СПб.: Питер, 2009.- с. 133.

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

наиболее динамично развивающихся концепций проектирования и может

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

подхода (Service-Oriented Architecture, SOA) в проектировании, не

рассматриваемого, к сожалению, в SWEBOK, но все более активно

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

организации связи интерфейс-реализация к обмену информацией на уровне

интерфейс-интерфейс (то есть – межкомпонентному взаимодействию). По

мнению автора книги, уже наступил тот момент, когда необходимо вводить

отдельную тему, посвященную сервисно-ориентированному подходу в

проектировании и сервисно-ориентированным архитектурам, как моделям. В

частности, нотация UML 2.0 уже позволяет решать ряд вопросов, связанных

с визуальным представлением соответствующих архитектурных решений,

где сервисы (службы) могут рассматриваться как публикуемая

функциональность одиночных компонентов и групп компонентов,

объединенных в более «крупные» блоки, обеспечивающие предоставление

соответствующей сервисной функциональности.

Другие интересные, но менее распространенные подходы, в основном,

представляют собой формальные и точные (строгие) методы, а также, методы

трансформации.

3. Пример применения основных методов структурного

проектирования программного обеспечения при разработке текстового

редактора

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

применение на этапе программирования модульного и структурного

программирования.

Ковалёв С. Программирование на алгоритмическом языке mql4: Учебник.- М.: Логос, 2009.- с. 88.

Липаев В.В. Проектирование программных комплексов.- М.: Статут, 2009.- с. 93.

В конкретной организации и конкретном проекте вырабатывается

стандарт анализа и проектирования (это особенно актуально при

коллективной разработке ПО большим количеством групп специалистов).

Стандарт должен устанавливать: набор необходимых моделей (диаграмм) на

стадиях анализа и проектирования и степень их детализации; правила

фиксации проектных решений на диаграммах, в том числе правила

именования объектов (включая соглашения по терминологии), набор

атрибутов для всех объектов и правила их заполнения на каждой стадии,

правила оформления диаграмм (включая требования к форме и размерам

объектов) и т. д.; требования к конфигурации рабочих мест разработчиков,

включая настройки операционной системы, настройки CASE-средств и т. д.;

механизм обеспечения совместной работы над проектом, в том числе правила

интеграции подсистем проекта, правила поддержания проекта в одинаковом

для всех разработчиков состоянии (регламент обмена проектной

информацией, механизм фиксации общих объектов и т. д.), правила анализа

проектных решений на непротиворечивость и т. д.

Под моделью понимается полное описание системы ПО с оп-

ределенной точки зрения. Модели представляют собой средства для

визуализации, описания, проектирования и документирования архитектуры

системы. Моделирование является центральным звеном всей деятельности по

созданию качественного ПО. Модели строятся для того, чтобы понять и

осмыслить структуру и поведение будущей системы, облегчить управление

процессом ее создания и уменьшить возможный риск, а также

документировать принимаемые проектные решения. Очевидно, что конечная

цель разработки ПО - это не моделирование, а получение работающих

приложений (кода). Диаграммы в конечном счете - это всего лишь наглядные

изображения.

Цели анализа и формирования требований к ПО . Анализ является

первым этапом создания ПО , на котором требования заказчика уточняются,

формализуются и документируются. Фактически на этом этапе дается ответ

на вопрос: «Что должна делать будущая система?». Именно стадия анализа и

формирования требований к ПО определяет успех всего проекта.

Необходимо на более ранних стадиях разработки понять, что будет

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

недоработки, что, в свою очередь, облегчит работы на последующих этапах

ЖЦ и понизит стоимость разработки.

Целью анализа является преобразование общих, расплывчатых знаний

об исходной предметной области в точные определения и спецификации, а

также генерация функционального описания системы.

В случае создания ПО для информационной системы управления

предприятием (совокупность средств, методов и персонала для обработки,

хранения и выдачи информации) структурный анализ начинается с

исследования того, как организована система управления предприятием, с

обследования функциональной и информационной структуры системы

управления. По результатам обследования аналитик строит модель «как

есть»: обобщенную логическую модель исходной предметной области,

отображающую ее функциональную структуру, особенности основной

деятельности и информационное пространство, в котором эта деятельность

осуществляется. Далее создают модель «как надо»: усовершенствованную

обобщенную логическую модель, отображающую реорганизованную

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

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

стадия планирования реорганизованной деятельности предприятия,

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

лишь крупные, специализированные консалтинговые фирмы, способные

подключить к работе специалистов-экспертов в той области деятельности,

которая подлежит автоматизации. В большинстве случаев модель «как есть»

улучшается системным аналитиком за счет устранения очевидных

несоответствий и узких мест, а полученный таким образом вариант модели

рассматривается в дальнейшем в качестве модели «как надо».

На этапе анализа и формирования требований к ПО необходимо

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

требования не зафиксированы и не сделаны доступными для участников

разработки, то они вроде бы и не существуют вовсе. При этом язык, на

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

и понятен заказчику. Поэтому модели создаются в соответствии с

общеупотребительными стандартами. Результаты отражаются в

«Техническом задании» на проект (разработку) в соответствии с ГОСТ

34.602-89. Информационная технология. Техническое задание на создание

АС. Техническое задание содержит общие сведения, назначение и цель

создания, требования к системе в целом, к информационному,

программному, техническому обеспечению, т.д.

Проектирование ПО - это следующий этап ЖЦ ПО, на котором

вырабатывается, как реализуются требования пользователя, которые

порождены и зафиксированы на этапе анализа. На этапе проектирования ПО

рассмотренные модели расширяются, уточняются и дополняются

диаграммами, отражающими структуру ПО. Осуществляется построение

модели реализации, или физической модели проектируемой прикладной

системы (без технических подробностей).

Компоненты модели реализации: диаграммы потоков данных; модель

данных (определение в ER-диаграммах всех необходимых параметров для

приложений); модель пользовательского интерфейса (иерархия диаграмм

последовательности экранных форм); структурные схемы программ (модели

межмодульных и внутримодульных взаимодействий с использованием

техники структурных карт).

Павловская Т.А. Технологии программирования: Учебник для вузов.- 2-е изд., перераб. и доп..-

СПб.: НЕВА, 2008.- с. 150.

Модель пользовательского интерфейса определяется следующим

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

(т.е. тех которые не имеют детализации в виде диаграмм) выделяются

интерактивные (диалоговые) и не интерактивные процессы, например, в виде

списка. После этого строят диаграммы последовательности форм (FSD -

Form Sequence Diagram). FSD показывает, какие формы появляются в

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

экранных форм. Диаграммы последовательности форм образуют иерархию,

на вершине которой находится главная форма приложения, реализующего

систему/подсистему. На втором уровне находятся формы, реализующие

процессы нижнего уровня на диаграммах потоков данных. Показывается

взаимосвязь между каждой формой и определенным процессом, взаимосвязь

между каждой формой и одной или более сущностями в ER-диаграммах.

Описание экранных форм и отчетов должно содержать: описание назначения

формы (что делает); данные навигации (откуда вызвана, что может вызвать

сама); список ошибок, которые генерируются в процессе обработки формы и

реакция на них; ограничения доступа к форме (каковы привилегии,

разрешающие действия над формой и ее элементами, каковы привилегии,

запрещающие эти действия).

По сути, получается прототип экранов, отчетов, диалогов. Поэтому до

начала этапов проектирования и реализации необходимо определиться со

стандартом интерфейса пользователя . Описание интерфейса пользователя

включается в Техническое задание.

Правильность интерфейса должен проверять и утверждать только

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

практике реализация интерфейса пользователя является наиболее часто

изменяемой частью исходного кода. Много проблем в интерфейсах

пользователей создают сами проектировщики, если они неправильно

выбирают макет и не учитывают разницы поведения системы на макете и на