I. Цел на настоящия документ


Дизайн на на високо ниво в програмирането (архитектура)



страница2/7
Дата08.06.2017
Размер385.9 Kb.
#23135
1   2   3   4   5   6   7

1.3.Дизайн на на високо ниво в програмирането (архитектура)


      • Какво означава дизайн на високо ниво? Какво включва архитектурата на една система? Какво не включва? Къде е границата между архитектура и детайлизиран дизайн?

      • Защо е необходим дизайнът на високо ниво (архитектура) в програмирането? В каква степен е застъпен той при различните процеси за разработка на софтуер?

      • Какво е структурен дизайн (Structured Design)? Какво е функционална декомпозиция на системата? Какви са подходите при структурния дизайн? Какво е top-down composition и bottom-up composition? Какви са стъпките в структурния дизайн?

      • Какво е обектно-ориентиран дизайн? Какви са неговите основни принципи? Как се използва той за дизайн на високо ниво? Защо обектно-ориентираният дизай е предпочитан?

      • Какви формални методи за дизайн има? Какви са техните основни принципи? Какви нотации се използват в дизайна? За какво служат те? Какво представляват диаграмите? Какви видове диаграми се използват? Какво е UML? За какво служи той? Каква роля има той в дизайна?

      • Какви други подходи има при дизайна на високо ниво? Какви са техните принципи, силни и слаби страни?

      • Кой от описаните методи за дизайн да използваме? В кои случаи е най-подходящ всеки от описаните методи? Какви са общите принципи в дизайна, независимо от метода, който се използва? Могат ли да се комбинират няколко от описаните методи за дизайн?

      • Как можем да бъдем сигурни, че когато е готов, дизайнът е направен добре? Какви са характеристиките на добрия дизайн? Лесно ли се различават добрият от лошия дизайн? Формален процес ли е дизайнът или евристичен? Итеративен процес ли е дизайнът? Защо? Може ли да се използва методът “проба-грешка”? Не е ли неефективен този метод?

      • Какво е Design Reviеw и има ли нужда от него?

      • Какво е дизайн документация и има ли нужда от нея?

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


      • Какво е необходимо да се направи преди да се започне с конструирането на кода?

      • Защо е важна подготовката за конструиране на кода? Не може ли без нея? В какво се състои тази подготовка? Какви стъпки включва? Зависи ли подготовката от големината на проекта?

      • Важно ли е да имаме ясно дефиниран проблем преди да започнем конструирането на кода? Необходими ли са ясни изисквания към системата и функционална спецификация? До каква степен те трябва да са ясни? Трябва ли изискванията да са строго формални? Има ли възможност за доизясняване на изискванията по време на конструирането на кода? Има ли такова нещо като “стабилни изисквания, които не се променят с времето”?

      • Важно ли е да има създадена архитектура (дизайн на системата на високо ниво) преди започване на конструирането на кода? Не може ли без архитектура? Колко детайлна трябва да е архитектурата?

      • Трябва ли да е избран езикът за програмиране преди започване на конструирането на кода? Не може ли този език да се избере и на по-късен етап? Може ли да се използват различни езици в една система?

      • Трябва ли конвенциите за проекта да са преварително дефинирани или те се изграждат по време на конструирането на кода?

      • Какви други условия е препоръчително да са изпълнени преди започването на конструирането на програмния код?

      • Кога може да се смята, че подготовката за създаване на програмен код е приключила и може да се започва конструирането на кода? Не може ли част от кода да се напише преди да е изяснена спецификацията и архитектурата на системата?

2.Препоръки за конструиране на висококачествен програмен код

2.1.Дизайн

2.1.1.Основни принципи и понятия


        • Какво е това детайлен дизайн? Какво включва детайлният дизайн на една програма или компонент на една система? Включва ли дизайн на модулите и взаимодействията между тях? Включва ли дизайн на подпрограмите в модулите и взаимодействията между тях? Включва ли вътрешния дизайн на подпрограмите?

        • Какво представляват нивата на абстракция? Какво ни дават те? Защо са толкова важни? Какво е абстракция на данните? Какво е абстракция на управлението? Има ли нещо общо с принципа за абстрактност в обектно-ориентираното програмиране? Какви са типичните нива на абстракция в една софтуерна система? Какво общо има принципът “information hiding”?

        • Какво е модулност (modularity) и каква е ползата от нея? Има ли тя връзка с нивата на абстракция?

        • Какво е функционална независимост? Какво общо имат с нея понятията “cohesion” и “coupling”?

        • Важна ли е простотата на дизайна (simplicity)? Има ли връзка тя с понятията cohesion, coupling и information hiding? Има ли отношение тя към леснотата на поддръжка на системата? Има ли връзка между нивата на абстракция и простотата на дизайна?

        • Какви са характеристиките на добрия детайлен дизайн? Каква връзка с качеството на дизайна имат следните понятия: modularity, simplicity, minimum redundancy, understandability, implementability, modifiability, maintainability, device-independency, internationality, extensibility, efficiency, reliability, stability, robustness, reusability, portability, longevity, completeness? Как можем да бъдем сигурни, че когато е готов, детайлният дизайн е направен добре?

2.1.2.Модули и класове


        • Какво е представляват модулите и каква е ползата от тях? Какви са причините за създаване на модули? Как се реализират модулите в съвременните езици за програмиране (пакети в Java, namespaces в C#)?

        • Какво представлява интерфейсът на един модул? Какво трябва да включва? Какво не трябва да включва? Какво представлява интерфейсът на един клас в обектно-ориентираното програмиране? Какво е “information hiding”? Кога и защо трябва да се прилага и каква е ползата от тази техника? Коя информация трябва да се скрива и коя не трябва? Има ли връзка скриването на информация с концепцията за разделяне на програмата на нива на абстракция?

        • Какво представляват класовете в обектно-ориентираното програмиране? Какви средства за модулност ни дава обектно-ориентираното програмиране?

        • Какво е абстракция на данните и скриване на информация? Какво е енкапсулация?

        • Какво гласят принципите за здравина на модулите (module cohesion) и слаба модулна свързаност (module coupling)? Как се пренасят тези принципи в обектно-ориентираното програмиране? Какво са “interface object coupling”, “internal object coupling” и “object cohesion”? Как се реализират тези принципи на практика? Виниги ли трябва да се спазват? Винаги ли е възможно да се спазват?

        • Как се постига лесна преносимост (portability) и лесна повторна употреба на кода (reusability)?

        • Какви са конкретните стъпки в дизайна на един модул (клас)? Какво се случва на всяка от тези стъпки? Кога може да се счита, че дизайнът на един модул (клас) е добър?

        • Какво е “добро име” на модул? На какви изисквания трябва да отговарят имената на модулите?

        • Какво е “добро име” на клас? На какви изисквания трябва да отговарят имената на класовете?

2.1.3.Обектно-ориентиран дизайн


        • Може ли да се каже, че обектно-ориентираното програмиране е следващата стъпка от еволюционното развитие на модулното програмиране като концепция?

        • Какво представлява и какви действия включва обектно-ориентираният дизайн на класовете, които изграждат даден компонент от една софтуерна система?

        • Какво е йерархия от класове? Каква роля има това понятие в дизайна на модулите в една система? Кога трябва да се използва? Какво е множествено наследяване и има ли полза от него?

        • Какво е полиморфизъм и има ли той някаква роля в дизайна на една система?

        • За решаването на какви дизайн проблеми може да се използват наследяване и полиморфизъм?

        • Какво е “operator overloading” и каква е ролята на тази техника? Какво представляват шаблоните (templates) и кога трябва да се използват? Какви други техники предоставя обектно-ориентираното програмиране и за какво се използват те?

        • Какво представляват шаблоните за дизайн (Design Patterns)? Какво ни помагат тези шаблони? Кога трябва да се използват?

        • Какво е UML и какво отношение има той към обектно-ориентирания дизайн? Какво представляват клас-диаграмите и с какво могат да бъдат полезни?

        • Какво представляват следните отношения между обектите: aggregation, association, composition, generalization, delegation? Каква роля играят те в обектно-ориентирания дизайн?

2.1.4.Подпрограми


        • Какво е подпрограма? Защо трябва да се използват подпрограми? С какво използването на подпрограми подобрява качеството на кода? Кога трябва да се използват подпрограми? Какви видове подпрограми има? Какво е процедура? Какво е функция? Какво е метод в обектно-ориентираното програмиране?

        • Какво е здравина на подпрограма (routine cohesion)? Какви типове routine cohesion има? Кои от тях трябва да се предпочитат и кои да се избягват?

        • Какво е свързаност на подпрограма (routine coupling)? Какви типове routine coupling има? Кои от тях трябва да се предпочитат и кои да се избягват?

        • Колко дълги трябва да бъдат подпрограмите? Има ли строго ограничение за дължината?

2.1.5.Техники за създаване на подпрограми


        • Какво представлява процесът на създаване на подпрограма? Какви са стъпките? Какво се случва на всяка от тези стъпки? Защо процесът е евристичен и итеративен, а не строго формален?

        • Какво е “добро име” на подпрограма? На какви изисквания трябва да отговарят имената на подпрограмите, в частност на процедурите, на функциите и на методите в класовете?

        • Какви са препоръките при дефиниране и използване на параметрите в подпрограмите? Какви трябва да бъдат имената на параметрите? Трябва ли read-only параметрите да са изрично декларирани като такива (с const при C++ и Pascal и final при Java)? Какви са съветите за избор на механизъм за предаване на параметрите (по адрес, по стойност и т.н.)?

        • Какво е псевдокод? За какво служи той? Кога трябва да се използва и кога не?

        • Какво представлява процесът за създаване на подпрограми чрез псевдокод (PDL-to-code process)? От какви стъпки се състои и какво се случва на всяка от тези стъпки? Кога трябва да се използва този процес и кога не се препоръчва?

        • Какви други методи за създаване на подпрограми има? Защо не може строго да се формализира процесът за създаване на подпрограма?


Сподели с приятели:
1   2   3   4   5   6   7




©obuch.info 2024
отнасят до администрацията

    Начална страница