32. Можливість переглянути довідку по командам Нефункціональні вимоги:

37. Вимоги до зовнішнього інтерфейсу 37.1. Зовнішній інтерфейс користувача має бути командним 37.2. Застосування має бути консольним 38. Дані повинні зберігатись у файлах після виходу з програми.

39. Система має забезпечити правильність введених даних 40. Логічна структура даних 40.1. Інформаційний об'єкт категорія 40.2. Інформаційний об'єкт товар 40.3. Інформаційний об'єкт замовлення Замовник Сума замовлення 40.4. Інформаційний об'єкт замовник Спрощені вимоги до програмного збезпечення Функціональні вимоги:

33. Управління користувачами бібліотеки 33.1. Можливість додавати користувачів 33.2. Можливість видаляти користувачів 33.3. Можливість змінювати дані користувачів 33.4. Можливість переглянути дані конкретного користувача 33.5. Можливість переглянути список всіх користувачів 33.5.1. Можливість відсортувати список по імені 33.5.2. Можливість відсортувати список по прізвищу 33.5.3. Можливість відсортувати список по академічній групі 34. Управління документами бібліотеки 34.1. Можливість додавати документ 34.2. Можливість видаляти документ 34.3. Можливість змінювати дані документу 34.4. Можливість переглянути дані конкретного документу 34.5. Можливість переглянути список всіх документів 34.5.1. Можливість відсортувати список по назві 34.5.2. Можливість відсортувати список по автору 35. Управління видачами документів 35.1. На рахунок користувача можна видвати n документів n 35.2. Можливість переглядати яку які документи взяв конкретний 35.3. Можливість по заданому документу визначити, чи він знаходиться у бібліотеці. Якщо документ виданий, то котрому користувачеві.

35.4. Можливість повернути книжку в бібліотеку 36. Пошук 36.1. Можливість пошуку по ключовому слову серед документів 36.2. Можливість пошуку по ключовому слову серед користувачів 36.3. Можливість пошуку по всім даним по ключовому слову 36.4. Розширений пошук користувача (коли задається конкретний набір даних, наприклад призвіще та дата народження) 37. Можливість переглянути довідку по командам Нефункціональні вимоги:

41. Вимоги до зовнішнього інтерфейсу 41.1. Зовнішній інтерфейс користувача має бути командним 41.2. Застосування має бути консольним 42. Дані повинні зберігатись у файлах після виходу з програми.

43. Система має забезпечити правильність введених даних 44. Логічна структура даних 44.1. Інформаційний об'єкт користувач бібліотеки 44.2. Інформаційний об'єкт документ до виконання курсовой роботи з дисципліни «Об'єктно-орієнтоване програмування»

Вимоги до кодування

УЗГОДЖЕННЯ ЩО ДО КОДУВАННЯ ПРОГРАМ

Курсовой проект можно выполнять на языках С++ или С#.

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

Структура проекта Каждый проект должен располагаться в отдельном подкаталоге каталога решения. Не помещайте файлы проекта и файлы решения в один и тот же каталог;

Используйте подкаталоги для организации исходного кода проекта; пространства имен должны соответствовать структуре каталогов;

Структура файла исходного кода Файл исходного кода должен иметь следующую структуру (порядок элементов также имеет значение):

using - декларации;

Декларации пространства имен;

[Optional] Перечислители и вспомогательные структуры, нужные для данного класса. Поскольку это может помешать работе дизайнера форм, их можно отнести в отдельный файл;

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

Структура классов Классы и структуры должны объявляться в следующем порядке:

Конструктор(ы);

Свойства (сначала public, потом protected, потом private);

Методы (сначала public, потом protected, потом private);

Делегаты и события.

Форматирование кода Код должен быть отформатирован в соответствии со следующими правилами:

Опция “Tabs” должна быть установлена в положение “Keep tabs”;

Размер отступа по умолчанию должен быть 4 символа;

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

if (file.Exists(fileName)) file.Open(fileName);

for (int i = 0; i MAX_ELEMENTS; ++i) array[i] = i * MULTIPLY_FACTOR;

switch (workMode) case WorkMode.Add:

case WorkMode.Update:

Пустые строки используются для улучшения восприятия кода.

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

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

После последнего объявления “using” перед объявлением пространства имен;

Между методами;

Между объявлением локальных переменных метода и первой инструкцией метода;

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

Перед логически изолированной частью кода метода.

Пробелы также следует использовать для улучшения восприятия кода. Необходимо вставлять пробелы:

Перед круглыми скобками, следующими за ключевым словом:

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

int result = Calculate(argumentOne, argumentTwo);

Между бинарным оператором и его операндами:

int result = argumentOne + argumentTwo;

Между частями инструкции “for”:

for (int i = 0; i MAX_ELEMENTS; ++i) Аргументы унарных операторов никогда не отделяются пробелами:

Все длинные строки должны быть свернуты. Рекомендуется ограничить длину строки 78 символами. При сворачивании длинных строк старайтесь следовать следующим правилам:

Переносите строку после запятой;

Переносите строку перед оператором;

«физическому»;

Делайте дополнительный отступ перед «свернутой» частью строки:

// Here comes a long line.

DEFAULT_SCALE

- correctionFactor;

Длинный список параметров метода также должен быть свернут, равно как и список аргументов в инструкции вызова метода:

// The method declaration.

public float DoSomethingFromManyArguments( decimal argumentThree, string argumentFour) // The calling code.

float result = DoSomethingFromManyArguments( Не объявляйте несколько переменных в одной строке, используйте отдельную строку для каждой переменной:

string customerName;

Рекомендуется одинаково выравнивать связанные строки кода, особенно это касается объявлений переменных. Например:

Position _position;

string _customerName;

_customerName = “John Doe”;

_salary += SALARY_BONUS;

_position = Position.Supervisor;

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

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

Имена локальных переменных и аргументов методов должны записываться в нотации «верблюд»:

string customerName;

private int DoSomething(int firstArgument, float secondArgument);

Имена закрытых полей класса должны следовать нотации «верблюд» с подчерком перед первым символом:

private string _customerName;

Имена открытых полей класса должны следовать нотации «Паскаль»:

public int CustomerID;

Имена свойств и методов класса должны следовать нотации «Паскаль»:

public bool ValidateAmount();

public bool FileExists Имена классов, структур и нумераторов должны следовать нотации «Паскаль»:

public class CustomerAccount private enum WorkMode Имена методов должны следовать шаблону «глагол» + «существительное» - например, “UpdateAccount”;

Используйте единственное, а не множественное число в именах перечислителей. Иными словами, “WorkMode” - это правильное имя, а “WorkModes” - нет;

Используйте значимые имена даже для закрытых методов, свойств, типов и т.д. Избегайте использовать короткие имена, такие как “a”, “b”, “n” за исключением общепринятых имен для переменных цикла “i” и“j”.

Общие принципы разработки Культура кодирования Дублирование кода в программе строго запрещается.

Не применяйте функциональную декомпозицию. Для повторного использования кода применяйте средства ООП, например, наследование;

Обязательна замена числовых и строковых литералов символическими константами. Исключение можно сделать для самоочевидных констант, таких как 0 и 1. Давайте символическим константам значимые имена;

Рекомендуется объединять связанные между собой константы целых типов в перечислители, а не целых типов – в абстрактные классы с открытыми статическими константными членами;

Разделяйте общеупотребительные константы, перечислители и вспомогательные классы посредством System Frameworks проектов;

Максимально следуйте практике ООД/ООП. Максимально используйте шаблоны проектирования, но делайте это в правильном контексте, как это описано в секции “Applicability” данного шаблона;

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

Всегда обращайте внимание на предупреждения компилятора.

Добивайтесь, чтобы их не было.

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

Текст комментария отделяйте от слэшей одним пробелом.

Первая буква предложения должна быть прописной, в конце предложения должна стоять точка;

// This is a sample comment. This is yet another comment sentence.

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

Комментарии к методам, свойствам, классам, интерфейсам и другим конструкциям языка должны иметь XML-формат для возможной генерации программных документов в дальнейшем;

Не используйте комментарии в стиле C: /* … */ Комментарий не должен перефразировать то, что написано в коде. Старайтесь давать содержательные пояснения. Например, комментарий “Increment i by one” к коду “i++;” это плохая практика, а комментарий “Update the number of customer accounts processed” – хорошая.

Специфика Windows Forms Следуйте Microsoft User Interface Guidelines, если к вам не предъявляют других требований.

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

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

Используйте нотацию «верблюд» для наименования экземпляров управляющих элементов на формах и пользовательских управляющих элементах, например, “optionsHeading”;

Используйте нотацию «Паскаль» для наименования классов форм и управляющих элементов, например, “ ProductList ”;

Стремитесь к повторному использованию UI и исходного кода. Делите ваш интерфейс на элементы; смело наследуйте формы и управляющие элементы.

Источник информации http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpgenref/html/cpconnetframeworkdesignguidelines.asp