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

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

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

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

2. Функция. Определяется, что делает модуль, когда он вызван, а также его назначение. Этот элемент спецификации не должен содержать сведения о том, как функция реа­лизуется.

3. Список параметров. Определяются число и порядок пара­метров, передаваемых модулю.

4. Входные параметры. Подробно описываются все входные параметры (указываются атрибуты, формат, размер, единицы измерения).

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

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

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

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

2. Проектирование внешних спецификаций модуля. Это процесс определения внешних характеристик каждого модуля.

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

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

5. Оформление начала и конца будущего модуля. Предусмат­ривается оформление модуля в соответствии с требованиями принятого языка программирования.

6. Объявление всех данных, используемых в качестве па­раметров. Записываются соответствующие операторы объяв­ления.

7. Объявление оставшихся данных. Записываются операторы объявления всех оставшихся данных, которые должны быть использованы в модуле.

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

9. Окончательное оформление текста программы. Текст модуля проверяется еще раз. При этом вставляются дополнительные комментарии, поясняющие текст программы,

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

11. Компиляция модуля. Этот шаг отмечает переход проекти­рования к тестированию модуля. Работа над созданием модуля завершена. После компиляции на основе полученной информации про­веряется правильность интерпретации компилятором намере­ний программиста по объявленным данным.

4. Налогообложение физических лиц. Транспортный налог и налог на операции с ценными бумагами: плательщики, объект обложения, система льгот, особенности формирования налоговой базы, ставки, особенности исчисления и уплаты налога, ответственность плательщиков за нарушение законодательства

Плательщики: лица, на которых зарегистрировано транспортное средство, признаваемое объектом обложения в соответствии со статьей 358 Налогового Кодекса.

Объект: наземное транспортное средство на пневматическом и гусеничном ходу, самолеты, вертолеты, водные транспортные средства, снегоходы, мотосани и др.

Не являются объектом: весельные лодки и моторные лодки с двигателем не более 5 л.с.; легковые автомобили, специально оборудованные для использования инвалидами; легковые автомобили с мощностью до 100 л.с., полученные через органы социальной защиты; транспортные средства, принадлежащие федеральным органам исполнительной власти, где предусмотрена военная или приравненная к ней служба; транспортные средства, находящиеся в розыске при наличии документа об угоне.

Налоговая база: для транспортных средств, имеющих двигатели – это мощность двигателя (л.с.); для несамоходных (водных) судов – валовая вместимость в регистровых тоннах; для всех остальных водных и воздушных транспортных средств – это единица транспортных средств.

Налоговый период – календарный год.

Налоговые ставки устанавливаются законами субъектов РФ соответственно в зависимости от мощности двигателя или валовой вместимости транспортных средств, категории транспортных средств в расчете на одну лошадиную силу мощности двигателя транспортного средства, одну регистровую тонну транспортного средства или единицу транспортного средства в размерах, прописанных в статье 361 НК.

Налог на операции с ценными бумагами

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

Объект налогообложения: доход, полученный налогоплательщиками.

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

- купли-продажи ЦБ, обращающихся на организованном рынке ценных бумаг;

- купли-продажи ЦБ, не обращающихся на организованном рынке ценных бумаг;

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

- купли-продажи инвестиционных паев паевых инвестиционных фондов, включая их погашение.

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

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

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

Доход (убыток) по операциям купли-продажи ценных бумаг, обращающихся на организованном рынке ценных бумаг, уменьшается (увеличивается) на сумму процентов, уплаченных за пользование денежными средствами, привлеченными для совершения сделки купли-продажи ценных бумаг, в пределах сумм, рассчитанных исходя из действующей ставки рефинансирования Центрального банка Российской Федерации.

Налоговая база по операциям купли-продажи ценных бумаг (погашения инвестиционных паев паевых инвестиционных фондов) определяется как доход, полученный по результатам налогового периода по операциям с ценными бумагами.

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

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

5. Этап даталогического проектирования. Правила перехода от модели «Сущность-связь» к реляционной.

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

1) выбор подхода к моделированию данных;

2) проектирование логической схемы БД.

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

Основные требования к формализованному представлению данных были сформулированы Э.Коддом:

1) простота понимания и использования. Формализ. представление д/б настолько простым, насколько это возможно.

2) должно иметь серьезную теоретическую основу;

3) эффективность реализации.

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

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

По эффективности реализации в начальный момент появления реляционной модели иерархические и сетевые СУБД превосходили реляционные. В настоящее время наиболее эффективные СУБД - это реляционные.

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

2) Рассмотрим проектирование логических схем при выборе реляционного подхода к моделированию данных. Задача проектирования заключается в построении схем отношений. При проектировании логических схем отношений реляционной базы данных существуют различные подходы. В каждом из них вначале получают набор исходных схем, который затем подвергают анализу на соответствие требованиям нужной нормальной формы в соответствии с теорией НФ.

Рассмотрим метод проектирования схем, основанный на анализе инфолог. модели, модели ER. Для ER существует алгоритм однозначного преобразования в реляц. модель данных. Это позволило разработать САПР баз данных или Case-системы (PowerDesigner, ER-Win, Silverrun). Во всех этих системах существуют средства описания инфологической модели, разрабатываемой БД с возможностью генерации даталог. модели – реляц. В некоторых системах происходит генерация физ. модели, т.е. ориентированной на применение конкретной реляционной СУБД. В нек. (Silverrun) системах происходит построение даталог. модели без привязки к конкретной СУБД, а затем генерация схем для конкретной СУБД. При формировании схем отношений учитываются такие хар. атрибутов, как единичные или множественные, обязательность или необязательность атрибута (при генерации Null-значений), а также тип связи, ее обязательность или необязательность.