Въведение

Всеки стадий от системното разработване - планиране, необходими анализ и спецификация, системно проектиране, изпълнение, оценяване и техническа експлоатация – може да бъде поддържан и подобряван с помоща на запас от софтуерни средства.

Софтуерните дейности  за общи цели, които могат да се използват във всички видове разработване включват редактиране, компилиране, стартиране на програма, езици за програмиране, текстови редактори и др. Ние ще разгледаме по-подробно дейностите проектирани специално за поддържане на ЧМИ (човеко-машинен интерфейс).

Ще се спрем върху взаимодействащи си системи за изпълнение, които са комплексни по две причини :

1. Включват много преобразувателни дейности : да се конфигурира множество от входни и изходни устройства, да се програмират серии от операции и взаимодействия, да се свържат обектите на изчисление.
2. Има несъответствие между начина  на мислене на хората за проекта и пътя на заработване на  програмата. Това е така наречената дупка между спецификацията (какво да се направи) и изпълнението (как да се направи).

Този процес може да  бъде подпомогнат  по два начина :

• да се стесни областта от дейности. Това е възможно  чрез автоматизиране на някои от тях, но е трудно и често завършените технически решения са неуловими или незадоволителни.
• да се опрости всяка дейност поотделно. Изглежда по-лесно, тъй като винаги е възможно по някакъв начин да се намали сложността на преобразуванията.

Софтуерните средства не само правят софтуер, но и управляват процеси, анализират програми и ги тестват. Всяка програма, която проектира, прави, поддържа, управлявя или тества софтуерен продукт може да се нарече софтуерно средство. Грубата работна дефиниция е, че софтуерните средства са програми, които подпомагат дизайнерите и програмистите в някоя точка от разработването на софтуерния продукт.

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

Модел на обектно-ориентираното разработване (ООР)

ЧМИ и ООР споделят много обща история. При конвенционалното разработване се набляга на процедура. Процедурните аспекти на приложението са смесени с обработката на данните. В ООР ударението пада върху дефиниране на свойствата и поведението на обектите .

Обектите групират данните и операциите в свързана област. Смята се, че ООР е по-естествено, доколкото обектите представени в софтуера могат да се свържат директно с обекти от реалния свят. ООР се базира на 4 основни понятия :

1. Капсулизация – скриване на данните. Отнася се до практиката за разделяне външното представяне на обекта, което е достъпно за другите обекти, от вътрешните детайли, недостъпни за останалите обекти. В общи линии това означава, че не е необходимо обектите да знаят как се представя дадено задание, ако знаят как да изискат  то да се изпълни.
2. Класификация  - всеки обект принадлежи на определен клас (абстракция ) и всички обекти от даден клас имат общи структура на данните и поведение.
3. Наследственост  - всички обекти от даден клас наследяват  свойствата на класа и същевременно всеки обект има някакво уникално качество, по което се различава от останалите.
4. Полиморфизъм – позволява една и съща команда да се интерпретира различно, в зависимост от приемника й.