Oprogramowanie narzędziowe (Software tools) – oprogramowanie wykorzystywane w trakcie opracowywania, poprawiania lub opracowywania innych programów: edytorów, kompilatorów, debugerów, pomocniczych programów systemowych, pakietów graficznych itp.

Obejmuje to języki programowania, zintegrowane środowiska programistyczne, systemy CASE itp.

Wybór języka programowania

Istniejące dziś języki programowania można podzielić na następujące grupy:

• uniwersalne języki wysokiego poziomu;
• specjalistyczne języki programistyczne;
• specjalistyczne języki użytkownika;
• języki niskiego poziomu.

W grupie uniwersalne języki wysokiego poziomu Niekwestionowanym liderem jest dziś język C++. Rzeczywiście ma wiele zalet:

• skalowalność. Język C++ jest używany do tworzenia programów dla szerokiej gamy platform i systemów;
• możliwość pracy na niskim poziomie z pamięcią, adresami, portami, które nieuważnie używane mogą łatwo przerodzić się w wadę;
• C++ ma potężny preprocesor odziedziczony z C, ale jak każde inne potężne narzędzie, należy go używać ostrożnie;
• umiejętność tworzenia uogólnionych algorytmów dla różnych typów danych, ich specjalizacji oraz obliczeń na etapie kompilacji z wykorzystaniem szablonów.

Jednocześnie język C++ ma szereg istotnych wad:

• podłączenie interfejsu modułu zewnętrznego poprzez wstawienie przez preprocesor pliku nagłówkowego (#include) poważnie spowalnia kompilację w przypadku podłączenia dużej liczby modułów;
• brak informacji o typach danych w czasie kompilacji;
• trudne do nauczenia i kompilacji;
• niektóre konwersje typów są nieintuicyjne. W szczególności operacja na liczbach bez znaku i znaku daje wynik bez znaku.

W przypadku C++ istnieje duża liczba bibliotek klas, które wspierają tworzenie interfejsu użytkownika, aplikacji klient-serwer, pracę z bazami danych itp., więc nie ma jeszcze alternatywy dla C++. W przypadku projektów drugorzędnych czasami używany jest Visual Basic. Język Java był uważany za alternatywę dla Basica, ale ze względu na brak narzędzia do tworzenia formularzy wizualnych pozostaje on mało przydatny. Współczesny Pascal obiektowy, podobnie jak Pascal, zaproponowany przez N. Wirtha w połowie lat 70. XX wieku, pozostaje najbardziej atrakcyjny do nauczania podstaw programowania ze względu na swoją prostotę, strukturę i wykrywanie przez kompilator dużej liczby nie tylko błędy składniowe, ale także semantyczne.

Dziś, inaczej niż w latach 60., języki programowania są rzadko tworzone. W ciągu ostatnich 15 lat można zauważyć tylko dwie nowości, które stały się powszechne - są to Java (Sun Microsystems, 1995), która stała się popularna w dużej mierze dzięki technologii jej wykorzystania w Internecie i pojawieniu się takiej koncepcji jak wirtualna maszyna Java oraz C# (Microsoft, 2000), oparty na C++.

Twórcą języka jest pracownik Microsoftu Andreas Hejlsberg. Zasłynął w świecie programistów na długo przed przyjściem do Microsoftu. Hejlsberg był jednym z czołowych deweloperów jednego z najpopularniejszych środowisk programistycznych - Delphi. W firmie Microsoft zajmował się tworzeniem wersji Java – J++, więc nie brakuje mu doświadczenia w pisaniu języków i środowisk programistycznych. Jak zauważył sam Andreas Hejlsberg, C# powstał jako komponentowy język programowania i jest to jedna z głównych zalet języka, mająca na celu możliwość ponownego wykorzystania stworzonych komponentów.

Inne zalety języka C#:

• zachowuje najlepsze cechy popularnych języków programowania C/C++, na których jest oparty. W związku z tym ułatwione jest przejście programistów z C++ do C#;
• jest prostszy i bardziej niezawodny niż C++. Prostota i niezawodność wynikają głównie z faktu, że C#, chociaż jest to dozwolone, nie zachęca do takich niebezpiecznych funkcji C++, jak wskaźniki, adresowanie, wyłuskiwanie, arytmetyka adresów;
• jest językiem całkowicie zorientowanym obiektowo, w którym nawet typy wbudowane w język są reprezentowane przez klasy;
• wdraża możliwości dziedziczenia i uniwersalizacji;
• uwzględnia wszystkie cechy Framework .Net, ponieważ C# powstał równolegle z tym środowiskiem;
• Dzięki frameworkowi .Net zbudowanemu na bazie systemu operacyjnego programiści C# uzyskują te same korzyści z maszyn wirtualnych, co programiści Java. Wydajność kodu jest nawet poprawiona, ponieważ CLR jest kompilatorem języka pośredniego, podczas gdy JVM jest interpreterem kodu bajtowego;
• potężna biblioteka framework wspiera wygodę budowania różnego rodzaju aplikacji w C#, pozwalając w łatwy sposób budować usługi WWW, inne typy komponentów, wystarczy zapisywać i pobierać informacje z bazy danych i innych magazynów danych;
• jest źródłem niezawodnego i wydajnego kodu.

Oprócz języków opisanych powyżej grupa języków uniwersalnych

należy również do Modula, Ada, COBOL, FORTRAN i kilku innych. Każdy z powyższych języków ma swoją własną charakterystykę i odpowiednio własny zakres. Obecnie uniwersalne języki programowania są wykorzystywane w wielu różnych obszarach ludzkiej działalności, takich jak:

• obliczenia naukowe (języki C++, FORTRAN, Java);
• programowanie systemowe (języki C++, Java);
• przetwarzanie informacji (języki C++, COBOL, Java);
• sztuczna inteligencja (LISP, Prolog);
• działalność wydawnicza (Postscript, TeX);
• zdalne przetwarzanie informacji (Perl, PHP, Java, C++);
• opis dokumentów (HTML, XML).

Z biegiem czasu niektóre języki rozwinęły się, zyskały nowe funkcje i pozostały na żądanie, inne straciły na aktualności i dziś są w najlepszym razie przedmiotem zainteresowania czysto teoretycznego (Focal, PL / 1 itp.). Wynika to w dużej mierze z następujących czynników:

• obecność środowiska programistycznego wspierającego tworzenie aplikacji w określonym języku programowania;
• łatwość utrzymania i testowania programów;
• koszt opracowania przy użyciu konkretnego języka programowania;
• przejrzystość i ortogonalność konstrukcji językowych;
• zastosowanie podejścia obiektowego.

Wyspecjalizowane języki programistyczne wykorzystywane do tworzenia określonych typów oprogramowania. Obejmują one:

• języki baz danych;
• języki do tworzenia aplikacji sieciowych;
• języki tworzenia systemów sztucznej inteligencji itp.

Wyspecjalizowane języki użytkownika są zwykle częścią profesjonalnych środowisk użytkowników, są wąsko skoncentrowane i nie są używane przez twórców oprogramowania.

Języki niskiego poziomu umożliwiają programowanie niemal z poziomu instrukcji maszynowych. Jednocześnie uzyskuje się najbardziej optymalne programy zarówno pod względem czasu wykonania, jak i wymaganej ilości pamięci. Ich wadą jest to, że nie wspierają zasad programowania strukturalnego.

Obecnie języki typu asemblerowego na ogół używają:

• podczas pisania stosunkowo prostych programów, aby uzyskać dostęp do środków technicznych, takich jak sterowniki;
• jako inserty do programów w językach wysokiego poziomu, na przykład w celu przyspieszenia transformacji danych w pętlach o dużej liczbie powtórzeń.

W większym stopniu o wyborze języka programowania decyduje doświadczenie programisty, wymagania organizacji prowadzącej programowanie, czy po prostu ugruntowana opinia.

Ogólnie technologia programowania, aw szczególności narzędzia wspierające rozwój oprogramowania, ewoluują tak szybko, że nawet prosta lista głównych systemów narzędziowych zajęłaby zbyt dużo miejsca w tej książce. Dlatego poniżej pokrótce skupimy się tylko na kilku projektach z zakresu technologii programowania, które są interesujące w kontekście tej publikacji.

Każdy opracowany system technologiczny musi obsługiwać wszystkie główne etapy tworzenia projektowanego pakietu oprogramowania. Aby osiągnąć ten cel w ogólnej strukturze typowy system wspomagania rozwoju technologicznego(Rys. 6.3) są zwykle izolowane baza projektów; podsystem automatyzacji projektowania i programowania; podsystemy debugowania, dokumentacji i utrzymania, a a także podsystem do zarządzania postępem projektu.

Ryż. 6.3. Ogólna struktura typowego systemu wspierania rozwoju technologicznego

Zaawansowane systemy wspierające rozwój bibliotek są obecnie wykorzystywane na całym świecie we wszelkich poważnych projektach programistycznych. Jednak w zdecydowanej większości przypadków takie systemy osiągnęły poziom wygody dla wykwalifikowanych programistów do pracy z nimi. Interesują nas przede wszystkim systemy i projekty, które mają tendencję do jawnego przedstawiania wiedzy technologicznej, nawet jeśli nie są oparte na pomysłach i metodach AI.

Jeden z takich projektów – Gandalf – koncentruje się na zautomatyzowanym generowaniu systemów tworzenia oprogramowania. Badania prowadzone w ramach projektu Gandalf dotyczą trzech aspektów wsparcia projektowania oprogramowania: zarządzania projektami, kontroli wersji i programowania przyrostowego oraz ich integracji w jednym środowisku. Zarządzanie w środowisku Gandalfa opiera się na założeniu, że tworzony projekt należy traktować jako zbiór abstrakcyjnych typów danych, na których można wykonywać tylko określone operacje. Narzędziem realizującym tę koncepcję był system SDC (Software Development Control), czyli zbiór programów pierwotnie zaimplementowanych w języku Shell w systemie UNIX, a później przetłumaczonych na język C.

Badania w zakresie kontroli wersji rozpoczął L. Kooprider na podstawie projektu FAFOS, gdzie wstępnie analizowano możliwości stworzenia rodziny systemów operacyjnych. Opracowano notację do opisu interakcji między podsystemami, do opisu różnych wersji podsystemów (kod źródłowy i obiektowy, dokumentacja itp.) oraz do opisu mechanizmów działających na etapie rozwoju (kompilacja, edycja linków itp.). Następnie powstał specjalny język Intercol, służący do opisu relacji i wersji modułów w systemie. I wreszcie, w system została wbudowana wiedza o tym, jak zbudować system z części bez zmuszania do tego użytkownika. W ramach kontynuacji tych prac powstał system SUCE, który śledził różnice między implementacjami (wersjami, które faktycznie dostarczają kod dla zestawu specyfikacji) i kompozycjami (wersjami, które definiują nowe podsystemy jako grupy istniejących podsystemów).

W systemie LOIPE (Language-Oriented Incremental Programming Environment) kompilacja przyrostowa jest wykonywana na poziomie pojedynczej procedury. Zaletą tego podejścia jest to, że gdy procedura jest poprawiana na poziomie lokalnych obiektów lub typów, tylko ona jest ponownie kompilowana. Jeśli specyfikacja ulegnie zmianie, wszystkie procedury, które od niej zależą, zostaną ponownie skompilowane. Interfejs użytkownika z systemem LOIPE oparty jest na podsystemie edycji zorientowanym składniowo ALOE (A Language-Oriented Editor). Celem opracowania tego podsystemu było zbadanie możliwości tworzenia i używania edytorów zorientowanych składniowo jako podstawy dla środowisk programistycznych.

Analiza literatury z ostatnich lat na temat technologii programowania wskazuje, że nowa gałąź w technologii rozwoju przemysłowego i wdrażania złożonych i znaczących systemów oprogramowania jest Technologia CASE(Inżynieria Oprogramowania Wspomaganego Komputerowo).

Początkowo technologia CASE pojawiała się w projektach tworzenia przemysłowych systemów przetwarzania danych. Ta okoliczność odcisnęła swoje piętno na narzędziach technologii CASE, gdzie największą uwagę, przynajmniej we wczesnych systemach CASE, zwracano na wsparcie projektowania przepływów informacji. Obecnie odchodzi się od koncentracji na systemach przetwarzania danych, a narzędzia technologii CASE stają się coraz bardziej uniwersalne.

Wszystkie narzędzia wsparcia technologii CASE są podzielone na dwie duże grupy: Zestawy narzędzi CASE oraz Stoły warsztatowe CASE. Dla tych terminów nie ma dobrych odpowiedników w języku rosyjskim. Jednak te pierwsze są często określane jako „skrzynie narzędziowe” (pakiety rozwojowe, pakiety technologiczne), a drugie jako „maszyny do produkcji programów” (linie produkcyjne).

A-prioryte CASE-Zestaw narzędzi- zbiór zintegrowanych narzędzi programowych, które zapewniają automatyczną pomoc w rozwiązywaniu problemów tego samego typu w procesie tworzenia programów.

Takie pakiety wykorzystują wspólne „repozytorium” dla wszystkich informacji technicznych i zarządczych dotyczących projektu (repozytorium), są wyposażone we wspólny interfejs użytkownika oraz ujednolicony interfejs pomiędzy poszczególnymi narzędziami pakietu. Z reguły CASE-Toolkit koncentruje się wokół wsparcia rozwoju jednej fazy produkcji oprogramowania lub jednego typu aplikacji.

Wszystko to dotyczy również CASE-WorkBench. Ale tutaj dodatkowo zapewnione jest zautomatyzowane wsparcie analizy zadań produkcyjnych oprogramowania do rozwiązania, które opiera się na ogólnych założeniach dotyczących procesu i technologii takich działań; wspierane jest automatyczne przenoszenie wyników pracy z jednego etapu na drugi, począwszy od etapu projektowania, a skończywszy na wyobcowaniu tworzonego oprogramowania i jego utrzymaniu.

Zatem, CASE-Stół roboczy jest naturalnym „zamknięciem” technologii tworzenia, wdrażania i utrzymywania oprogramowania.

Obecnie „typowy” system wsparcia technologii CASE ma funkcjonalność pokazaną na rys. 6.4.

Ryż. 6.4. Funkcjonalność typowego systemu wsparcia technologii CASE

Jak wynika z tego wykresu H, w środowisku CASE należy wspierać wszystkie główne etapy rozwoju i utrzymania procesów tworzenia systemów oprogramowania. Jednak poziom takiego wsparcia jest bardzo zróżnicowany. Jeśli więc na przykład mówimy o etapach analizy i projektowania, większość pakietów narzędzi obsługuje formularze ekranowe i raportowe, prototypowanie, wykrywanie błędów. Znaczna część tych środków przeznaczona jest na komputery PC. Wiele z nich wspiera szeroko stosowane metodologie, takie jak DeMarco lub Gane/Sarson Structural Analysis, Yourdan/Jackson Structural Design i kilka innych. Istnieją wyspecjalizowane pakiety programistyczne do tworzenia systemów informatycznych, takie jak Ana Tool (zaawansowane oprogramowanie logiczne) dla komputerów Macintosh; CA-Universe/Prototype (Computer Associates International) na PC. Dostępne są również środowiska CASE wspierające rozwój systemów czasu rzeczywistego.

Wśród programistów istnieją dwie oceny tego podejścia: jedni uważają, że technologia CASE radykalnie zmienia procesy tworzenia i eksploatacji oprogramowania, inni temu zaprzeczają i pozostawiają narzędziom CASE jedynie funkcję automatyzacji rutynowej pracy. Analiza literatury wskazuje jednak, że narzędzia CASE wciąż „przesuwają” technologie wytwarzania oprogramowania z zarządzania realizacją projektów w kierunku metody prototypowania. A ta zmiana, naszym zdaniem, jest niezwykle ważnym trendem w nowoczesnej technologii programowania.

Ministerstwo Kazachstanu Respublikasynyn

Gimnazjum Edukacji i Nauki Bilim zhane

Minister Lig Republiki Kazachstanu

D. Serikbaev w yndagy EKSTU

SZKMTU im. D. Serikbajewa

ZATWIERDZIĆ

Dziekan FITIB

M. Kylyshkanov

2015

BAҒDARLAMANS AZIRLEUDIN ҚҰRAL-SAYMANDARY

Zhұmys moduldіk oқu bagdarlamasy zhane sylabus

NARZĘDZIA ROZWOJU PROGRAMU

Liczba punktów dyscypliny: 3

Ust-Kamenogorsk

W Katedrze Systemów Informacyjnych i Modelowania Komputerowego opracowano działający modułowy program nauczania i program nauczania na podstawie Państwowego Standardu Kształcenia Obowiązkowego Republiki Kazachstanu GOSO RK 5.04.019 - 2011 Szkolnictwo wyższe. Studia licencjackie, program nauczania pracy, program nauczania modelowego i specjalność modułowa.

Omówiono na posiedzeniu Katedry Systemów Informacyjnych i Modelowania Komputerowego

Głowa oddział N. Denisova

Zatwierdzony przez radę pedagogiczną i metodyczną FITIB

Przewodniczący G. Uazirkhanova

Protokół nr ____ z dnia ____ ____________ 2015

Rozwinięty

Profesor nadzwyczajny Katedry T. Balova

starszy wykładowca wydziału I. Uvalieva

Kontroler I. Fazyłowa

1 CHARAKTERYSTYKA DYSCYPLINY, JEJ MIEJSCE W PROCESIE EDUKACJI

1.1 Podsumowanie badanej dyscypliny

Dyscyplina „Narzędzia do opracowywania programów” (dalej ISWP) odnosi się do obowiązkowego elementu cyklu głównych dyscyplin programu edukacyjnego specjalności 5B070400 - „Inżynieria komputerowa i oprogramowanie” i jest częścią modułu rozwoju programu modułowego programu edukacyjnego specjalności 5B070400 - "Inżynieria komputerowa i oprogramowanie".

Treść studiowanej dyscypliny ma na celu rozwijanie wiedzy studentów w zakresie nowoczesnych technologii programowania i narzędzi ich obsługi, przyczynia się do kształtowania specjalisty IT o szerokim spojrzeniu i kulturze myślenia, przygotowanego do wykorzystania w zakresie nowoczesne narzędzia CASE do projektowania oprogramowania.

1.2 Cele i zadania studiowania dyscypliny

Celem studiowania dyscypliny „Narzędzia rozwoju programów” jest zapoznanie studentów z wiedzą teoretyczną z zakresu technologii projektowania i zapewnienia cyklu życia systemów oprogramowania, a także nabycie praktycznych umiejętności korzystania z nowoczesnych technologii ukierunkowanych na modelowanie procesów biznesowych i projektowanie systemy oprogramowania wykorzystujące technologie CASE (Computer Aided Software/System Engineering, CASE). Cel dyscypliny jest zgodny z ogólnymi celami modułowego programu kształcenia specjalności.

Podejście kompetencyjne w nauczaniu dyscypliny „Narzędzia rozwoju programu” wyznacza jej główne zadania:

Utworzenie systemu wiedzy z zakresu inżynierii oprogramowania (inżynieria oprogramowania) i programowania (programowanie komputerów) wśród studentów;

Zapoznanie studentów z teoretycznymi podstawami modelowania procesów biznesowych, metodologiami projektowania i tworzenia oprogramowania oraz zestawem narzędzi zapewniających ich cykl życia;

Rozwijanie umiejętności korzystania z narzędzi CASE do modelowania strukturalnego i obiektowego oraz projektowania oprogramowania.

Zadania studiowania dyscypliny zapewniają realizację wymagań dotyczących przygotowania licencjata w programie edukacyjnym 5B070400-„Inżynieria komputerowa i oprogramowanie” ustalonych w charakterystyce kwalifikacji.

1.3 Wyniki badania dyscypliny

Efekty uczenia się są definiowane na podstawie deskryptorów dublińskich odpowiedniego poziomu edukacji i wyrażane za pomocą następujących kompetencji:

znać i rozumieć:

Modele cyklu życia oprogramowania i teoretyczne podstawy metodologii projektowania oprogramowania;

Zasady klasyfikacji nowoczesnych narzędzi programistycznych;

Podejścia do modelowania i restrukturyzacji procesów i systemów biznesowych;

umieć zastosować w praktyce narzędzia CASE, które wspierają:

metodyka modelowania funkcjonalnego IDEF0;

metodyka modelowania zdarzeń IDEF3;

Metodologia modelowania przepływu danych DFD;

metodyka semantycznego modelowania danych IDEF1X;

Metodologia obiektowego modelowania oprogramowania i metamodel UML;

być przygotowanym do formułowania osądów:

O wyborze modelu cyklu życia dla konkretnego projektu i projektu;

W kwestiach doskonalenia oprogramowania w korporacyjnych systemach informatycznych oraz dużych projektów rządowych (od modelu AS-IS do modelu TO-BE);

O znaczeniu i konsekwencjach swojej działalności zawodowej, z uwzględnieniem pozycji społecznych, zawodowych i etycznych;

rozwijać umiejętności komunikacyjne, w tym:

rozwijać umiejętności uczenia się, które przyczyniają się do:

Rozwój zawodowy i osobisty, rozwój zawodowy w zakresie międzynarodowych standardów inżynierii oprogramowania;

Samodzielne zdobywanie i wykorzystywanie w praktyce nowej wiedzy i umiejętności pracy z narzędziami CASE, w tym w nowych obszarach wiedzy niezwiązanych bezpośrednio z dziedziną działalności.

Edukacyjne i metodyczne wsparcie dyscypliny ma na celu pomyślne ukształtowanie tych efektów uczenia się.

1.4 Wymagania wstępne

Do pełnego przyswojenia materiału z dziedziny ISRP niezbędna jest wiedza z dziedzin związanych z algorytmizacją i technologią programowania.

1.5 Wymagania wstępne

Zdobyta wiedza jest niezbędna do jakościowego opanowania materiału dyscyplin: interfejsy systemów komputerowych i technologii internetowych; systemy i projektowanie osobistych baz danych; projektowanie systemów informatycznych i programowanie stosowane. Zdobyta wiedza jest niezbędna do skutecznego szkolenia w zakresie tworzenia oprogramowania.

2.1 Plan tematyczny

Nazwa tematu, jego treść	i inne źródła	pracowitość,
Moduł 1 „Narzędzia CASE do projektowania strukturalnego i funkcjonalnego narzędzi programowych”
Zajęcia wykładowe
Temat 1 „Wprowadzenie do dyscypliny”. Podstawowe koncepcje. Klasyfikacja nowoczesnych narzędzi programistycznych. Cel i zadania narzędzi do tworzenia oprogramowania. Historia rozwoju narzędzi.
Temat 2 „Metody projektowania oprogramowania”. Ogólne wymagania dotyczące metodyki i technologii projektowania oprogramowania. Przewodnik po wiedzy SWEBOK Software Engineering Body of Knowledge. Przegląd metod projektowania oprogramowania. Przegląd zestawu narzędzi do projektowania oprogramowania
Temat 3 „Podstawy metodologii projektowania oprogramowania”. Projektowanie programów jako złożonych systemów. Cykl życia oprogramowania. Główne procesy cyklu życia oprogramowania. Procesy pomocnicze cyklu życia oprogramowania. Procesy organizacyjne cyklu życia oprogramowania
Temat 4 „Modele cyklu życia oprogramowania”. Pojęcie modelu cyklu życia oprogramowania. Klasyczny model procesu wytwarzania oprogramowania. Prototypowanie. Strategia rozwoju przyrostowego. Model procesu spiralnego. Model rozwoju aplikacji RAD
Temat 5 „Metodologie tworzenia oprogramowania”. XP - programowanie procesowe lub ekstremalne. Metodologia Rational Unified Process (RUP). Elastyczne (zwinne) metodologie. Wybór modelu cyklu życia dla konkretnego projektu. Procedura tworzenia oprogramowania
Temat 6 „Nowoczesny CASE – technologie”. CASE - technologie i ich zastosowanie. Ogólna charakterystyka i klasyfikacja nowoczesnych narzędzi CASE. Technologie wdrażania i rozwoju narzędzi CASE. Ocena narzędzi CASE
Temat 7 „Modelowanie procesów biznesowych”. Pojęcie procesu biznesowego. Restrukturyzacja procesów biznesowych. Modelowanie procesów biznesowych. Metody modelowania procesów biznesowych
Temat 8 „Technologie CASE do analizy strukturalnej i projektowania oprogramowania”. Metodologia analizy i projektowania konstrukcji. IDEF0 Metodyka Modelowania Funkcjonalnego. Metodyka modelowania zdarzeń IDEF3. Symulacja przepływów danych DFD. IDEF1X Metodologia semantycznego modelowania danych
Badania laboratoryjne
Temat 1 „Opracowanie modelu funkcjonalnego IDEF0”
Temat 2 „Opracowanie modeli procesów informacyjnych IDEF3 i przepływów danych DFD”
Temat 3 „Metodologia semantycznego modelowania danych IDEF1X”
Temat 1 „Raporty i diagramy rodzeństwa model IDEF0”
Temat 2 „Narzędzia do kolektywnego opracowywania modeli funkcjonalnych w środowisku BPwin”
Temat 3 „Tworzenie raportów w ERwin”
Temat 1 „Tworzenie diagramów MES”
Temat 3 „Tworzenie relacji kategoryzacji w modelu IDEF1X”
Całkowity moduł 1
Moduł 2 „Narzędzia CASE do obiektowego projektowania oprogramowania”
Temat 9 „Podstawy modelowania obiektowego oprogramowania i metamodel UML”. Hierarchia opisów meta wykorzystywanych w wizualnym modelowaniu oprogramowania. Cel i poziomy modeli UML. Widoki w UML	21, 22, 23, 24, 25
Temat 10 „Ujednolicony język modelowania UML. Model UML. UML to zunifikowany język modelowania. Podmioty w UML. Relacje w UML	22, 23, 24, 25, 26, 27
Temat 11 „Ujednolicony język modelowania UML. Diagramy UML. Rodzaje diagramów UML. Ogólne diagramy UML. Specjalne diagramy UML	22, 23, 24, 25, 26, 27
Temat 12 „Ujednolicony język modelowania UML. Ogólne mechanizmy UML. Korzystanie z typowych mechanizmów UML. Ogólne właściwości modelu. Punkty semantyczne	22, 23, 24, 25, 26, 27
Temat 13 „Ogólny opis systemu z punktu widzenia reprezentacji UML”. Reprezentacje UML z punktu widzenia uogólnienia opisów. Ogólne mechanizmy UML. Ogólne właściwości modelu	22, 23, 24, 25, 26, 27
Temat 14 „Opis funkcjonalności wytwarzania oprogramowania”. Zarządzanie ryzykiem projektu. Procedura tworzenia oprogramowania. Dokumentacja oprogramowania. Zarządzanie wymaganiami
Temat 15 „Trendy w nauce i technologii oraz najszybciej rozwijające się segmenty na globalnym rynku IT”. Trzy platformy w ewolucji rynku IT. Nowe trendy IT: prognoza Gartnera. Światowe trendy rozwoju IT na najbliższe 3-5 lat
Badania laboratoryjne
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
	22, 23, 24, 25, 26, 27
Samodzielna praca ucznia pod kierunkiem nauczyciela (SROP)
Temat 4. „Budowa schematów strukturalnych UML”	22, 23, 24, 25, 26, 27
Temat 5. „Budowanie diagramów zachowania UML”	22, 23, 24, 25, 26, 27
Temat 6. „Generowanie kodu programu według modelu UML”	22, 23, 24, 25, 26, 27
Samodzielna praca studenta (SRO)
Temat 4. „Budowa schematów strukturalnych UML”	22, 23, 24, 25, 26, 27
Temat 5. „Budowanie diagramów zachowania UML”	22, 23, 24, 25, 26, 27
Temat 6. „Generowanie kodu programu według modelu UML”	22, 23, 24, 25, 26, 27
Całkowity moduł 2
Razem według dyscypliny, kredyt RK

2.2 Zadania do samodzielnej pracy (SROP, SRO)

		Czas realizacji, konto. tydzień	forma kontroli	Ostateczny termin (liczba tygodni akademickich)
Uzupełnij zadanie dla modelu SROP-IDEF0 o raporty i diagramy Node Tree. Uzupełnij zadanie dla modelu SRO-IDEF0 o diagram FEO.	Zapoznanie się z podstawowymi metodami kolektywnego tworzenia modeli funkcjonalnych w środowisku BPwin		Przem. zadanie i dodatkowe pytania podczas obrony. Zadania testowe
Zadanie dla SROP: Wykonaj podział modelu IDEF0 i Analiza ABC. Zadaniem SRO jest badanie elementów modelu symulacyjnego.	Zdobądź praktyczne umiejętności korzystania z narzędzi do tworzenia modeli współpracy z elementami analizy ABC
Zadaniem SROP jest zbudowanie szablonu raportu dla modelu IDEF1X. Przypisanie SRO - badanie pracy nad tworzeniem relacji kategoryzacyjnej w modelu IDEF1X	Dowiedz się, jak tworzyć szablony raportów za pomocą Kreatora raportów środowiska ERwin i opanuj procedury pracy z linkami kategoryzacyjnymi		Przem. zadania i pytania dodatkowe podczas obrony pracy laboratoryjnej Zadania testowe
Dotykowe wejście wielopozycyjne i zdarzenia WPF	Uzyskaj wprowadzenie do interakcji z aplikacją WPF przy użyciu ekran dotykowy do interaktywnej interakcji		Przem. zadanie i dodatkowe pytania podczas obrony pracy laboratoryjnej. Zadania testowe
WPF właściwości i wyzwalacze zdarzeń	Zapoznaj się z mechanizmem wyzwalania WPF do tworzenia efektu animacji		Przem. zadanie i dodatkowe pytania podczas obrony pracy laboratoryjnej. Zadania testowe
Korzystanie z interfejsu API pakietu Office i zestawów podstawowych. NetMicrosoft. gabinet. Interop	Opanować uproszczony mechanizm interakcji z COM w celu poszerzenia praktycznych metod organizowania interakcji między programami		Przem. zadanie i dodatkowe pytania podczas obrony pracy laboratoryjnej. Zadania testowe

2.3 Harmonogram realizacji i dostarczania zadań według dyscypliny

Główna literatura

1 Rambo J. Unified software development process / A. Jacobson, G. Butch, J. Rambo - St. Petersburg: Peter, 2002.-496 s.: il.

2 technologie CASE. Nowoczesne metody i środki projektowania systemów informatycznych / - M.: Finanse i statystyka, 1998.- 176 s.

3 Bachtizin, tworzenie oprogramowania: podręcznik. dodatek / , . - Mińsk: BSUIR, 2010. - 267 s. : chory.

4, Analiza i modelowanie komputerowe procesów i systemów informatycznych /, .- Dialog-MEPhI, 2009r. - 416 stron.

5 ISO/IEC 12207:2008. Inżynieria systemów i oprogramowania - Procesy cyklu życia oprogramowania [Zasoby elektroniczne]. - URL: http://www. izo. org/iso/catalogue_detail? numer cs=43447, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

6 GOST R ISO/IEC 12207-2010 Technologia informacyjna. Inżynieria systemów i oprogramowania. Procesy cyklu życia oprogramowania. - Wydawnictwo norm M., 2011r., 115p.

7 GOST R ISO/IEC 11179-2-2012 Technologia informacyjna. Rejestry metadanych (RMD). Część 2. Klasyfikacja [Zasób elektroniczny]. - URL: http:///Catalog/64/6430.shtml, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

8 GOST R ISO / IEC TO 12182 - 2002. Technologia informacyjna. Klasyfikacja oprogramowania. - Wejście. 2002 - 06 - 11. - Wydawnictwo M. Standards, 2002

9 Towarzystwo Komputerowe IEEE. SWEBOK [Zasób elektroniczny]. - URL: http://puter. org/web/swebok, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

10, Podręcznik do ćwiczeń praktycznych „Strukturalno-funkcjonalne podejście do projektowania i wykorzystania narzędzi CASE” / Perm. stan teściowa nie.-t. - Perm, 2005 r. - 245 pkt.

11 Metodologia Mark McGowan analizy strukturalnej i projektowania SADT [Trans. z angielskiego] / arch, akGowan - M .: MetaTechnology, 1993. -240 s.

12 DR 50.1.028-2001. Metodologia modelowania funkcjonalnego Dokument z wytycznymi IDEF0. Wydanie oficjalne. - M.: Wydawnictwo IPK Standards, 2000r. - 75 s.

13 Modelowanie i analiza systemów. Technologie IDEF: warsztat/S. Czeremnych, I. Semenov, V. Ruchkin - M.: Finanse i statystyka, 2006. -192 s.

14, Analiza strukturalna systemów. IDEF - technologie/S. Czeremnych, I. Semenov, V. Ruchkin - M.: Finanse i statystyka, 2001. – 208 pkt.

15 Strukturalne modele biznesowe: technologie DFD / A. Kalashyan, G. Kalyanov.- M.: Stosowane technologie informacyjne, 2009.- 256 s.

dodatkowa literatura

16 Standard IEEE 1320.2–1998. Standard IEEE dotyczący składni i semantyki języka modelowania koncepcyjnego IDEFIX97 (obiekt IDEF). - Wejście. 1998-06-25. – Nowy Jork: IEEE, 1998.

17 Efektywne modelowanie za pomocą AllFusion Process Modeler / V. Dubeikovsky.- M.: Dialog-MEPhI, -2007.- 384 s.

18 Modelowanie procesów biznesowych za pomocą AllFusion Process Modeler / S. Maklakov.- M .: Dialogue-MEPhI, -2004.- 240 s.

19 BPwin i Erwin. Narzędzia CASE do rozwoju systemów informatycznych / S. Maklakov. - Dialog-MEPhI, 2000. - 320 s.

20, IDEF0 Funkcjonalna Metodologia Projektowania. Podręcznik do kursu „Technologia tworzenia oprogramowania” dla studentów. specjalista. 40 01 01 Oprogramowanie informatyczne do edukacji stacjonarnej. - Mińsk: BGUIR, 2003. - 24 s.: ch.

21, Modelowanie UML. Teoria, praktyka, kurs wideo. - Petersburg, Literatura zawodowa, nauka i technika, 2010, 640 s.

22 język UML. Podręcznik użytkownika. Druga edycja. - DMK, 2006, 496 s.

23 J. Rambeau, M. Blaha, UML 2.0. Modelowanie i rozwój obiektowy - Peter, 2007, 544 s.

24. Martina Fowlera. UML. Podstawy. Krótki przewodnik po standardowym języku modelowania obiektów. Symbol-Plus, 2011., 192p.

25 The Unified Modeling Language (UML) [Zasoby elektroniczne]. - URL: http://www. uml. org/, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

26 wprowadzenie do UML: [Zasób elektroniczny] - Otwarte kursy Internetowej Wyższej Szkoły Technik Komputerowych (INTUIT). - Tryb dostępu http://www. intuicja. ru/studia/kursy/1007/229/info (data dostępu: 30.10.2015)

27 modelowanie wizualne w środowisku IBM Rational Rose 2003: [Zasób elektroniczny] - Kursy otwarte Internetowej Wyższej Szkoły Technik Informacyjnych (INTUIT). - Tryb dostępu http://www. intuicja. ru/studia/kursy/14/14/info (data dostępu: 30.10.2015)

28 Sympozjum Gartnera/ITxpo [Zasoby elektroniczne]. - URL: http://www. /technologia/sympozjum/japonia/katalog-wystawców. jsp, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

29 Przegląd i ocena perspektyw rozwoju światowego i rosyjskiego rynku IT / Blog Moskiewskiej Giełdy, standardy IT, infrastruktura IT [Zasoby elektroniczne]. - URL: http://habrahabr. ru/firma/moex/blog/250463/, za darmo. - Zagl. z ekranu (data dostępu: 30.10.2015)

4 OCENA WIEDZY

4.1 Wymagania instruktora

Wymagania nauczyciela:

Uczestnictwo w wykładach i zajęciach laboratoryjnych, SIWT zgodnie z harmonogramem jest obowiązkowe;

Obecność uczniów w klasie sprawdzana jest na początku zajęć, w przypadku spóźnienia uczeń musi po cichu wejść do sali i zaangażować się w pracę, a podczas przerwy wyjaśnić prowadzącemu przyczynę spóźnienia;

Prace laboratoryjne oceniane punktowo należy składać w ustalonych terminach, do egzaminu śródsemestralnego dopuszczani są studenci, którzy obronili co najmniej jedną pracę laboratoryjną o aktualnej ocenie;

Powtórne zaliczenie przez studenta kontroli śródokresowej, w przypadku uzyskania oceny niedostatecznej, jest niedopuszczalne;

Podczas zajęć telefony komórkowe muszą być wyłączone.

Studenci muszą przychodzić na zajęcia w strojach biznesowych.

4.2 Kryteria oceny

Ocena wszystkich rodzajów zadań odbywa się według systemu 100-punktowego.

Kontrola bieżąca przeprowadzana jest co tydzień i obejmuje kontrolę uczęszczania na wykłady, zajęcia praktyczne oraz samodzielną pracę.

Kontrola graniczna wiedzy przeprowadzana jest w 7 i 15 tygodniu semestru w formie sprawdzianów. Ocena składa się z następujących rodzajów kontroli:

Egzamin z dyscypliny odbywa się podczas sesji egzaminacyjnej w formie sprawdzianu.

Ocena końcowa wiedzy studenta w dyscyplinie obejmuje:

40% wyniku uzyskanego na egzaminie;

60% wyników aktualnych wyników w nauce.

Wzór na obliczenie oceny końcowej:

gdzie P1, P2 są odpowiednikami cyfrowymi odpowiednio pierwszej i drugiej oceny; E jest cyfrowym odpowiednikiem oceny z egzaminu.

Ostateczna ocena literowa i jej cyfrowy odpowiednik w punktach:

4.3 Materiały do ​​kontroli końcowej

4.3.1 Moduł 1 „Narzędzia CASE do projektowania strukturalnego i funkcjonalnego narzędzi programowych”

Zgodnie z międzynarodową normą ISO i IEC (Międzynarodowa Komisja Elektrotechniczna), technologia programowania jest

A) jedna z czynności wchodzących w skład cyklu wytwarzania oprogramowania

B) proces tworzenia programu (struktury informacji) przez programistę (człowieka) przeznaczonego do późniejszego wykonania (przez komputer)

C) zbiór wiedzy uogólnionej i usystematyzowanej, czyli nauka o najlepszych sposobach prowadzenia procesu programowania, który w danych warunkach zapewnia uzyskanie oprogramowania o zadanych właściwościach

D) zestaw metod i narzędzi pozwalających na ustalenie procesu produkcyjnego tworzenia oprogramowania

E) algorytm napisany w języku programowania

F) sekwencja poleceń (operatorów, instrukcji) komputera, których wykonanie prowadzi do wyniku rozwiązania problemu

Narzędzia programowe to:

A) przeglądarki, zapewniające interfejs graficzny do interaktywnego wyszukiwania, wykrywania, przeglądania i przetwarzania danych w sieci

B) oprogramowanie dla przedsiębiorstw, którego funkcje zapewniają zarządzanie finansami, system relacji z konsumentami, zarządzanie personelem itp.

C) linkery i debugery

D) oprogramowanie używane do projektowania, rozwoju, modyfikacji lub rozwoju innych produktów oprogramowania;

E) oprogramowanie umożliwiające dostęp do treści lub zasobów cyfrowych bez ich edycji, przykładami są odtwarzacze multimedialne, przeglądarki internetowe itp.

Kompilator to:

A) program, który konwertuje kod źródłowy napisany w języku programowania wysokiego poziomu na wykonywalny kod programu, który może być używany na innych komputerach bez dodatkowych przekształceń

B) zestaw narzędzi do tworzenia oprogramowania w określonym języku programowania, w tym edytor kodu źródłowego, tłumacz lub interpreter, linker, debugger, biblioteki standardowych podprogramów itp.

C) pakiet oprogramowania przeznaczony do tworzenia oprogramowania i integrujący edytory źródeł i zasobów, kompilator lub interpreter, linker itp.

D) moduł systemu programowania lub samodzielny program, który składa program wynikowy z modułów obiektowych i standardowych modułów bibliotecznych

E) program, który zapewnia wykonanie programu krok po kroku, przeglądanie aktualnych wartości zmiennych, obliczanie wartości dowolnego wyrażenia programu i innych funkcji

Główne zalety narzędzi CASE to:

A) Wzrost kosztów rozwoju

B) Zmniejsz koszty rozwoju

C) Komplikowanie dostępu do danych

D) Wydłużony czas rozwoju

E) Ułatwienie modyfikacji systemu

F) Możliwość przechowywania danych

Według projektu ICAM (Integration of Computer and Industrial Technologies) metodyka modelowania funkcjonalnego środowiska produkcyjnego lub systemu jest powiązana z notacją

Głównymi elementami modelu IDEF3 są:

B) linki (linki)

C) podmioty zewnętrzne

D) Połączenia

E) przepływy danych

F) magazyny danych

G) podmioty zewnętrzne

H) procesy lub prace (działalność)

4.3.2 Moduł 2: Narzędzia CASE do obiektowego projektowania oprogramowania

Ryzyko związane z przekroczeniem budżetu, negatywną reakcją klienta lub słabą komunikacją z użytkownikami:

A) ryzyko techniczne

B) ryzyko kalendarzowe

C) ryzyko zarządcze

D) ryzyko handlowe

Stosowana przez UML zasada modelowania, zgodnie z którą model powinien obejmować tylko te elementy projektowanego systemu, które są bezpośrednio związane z realizacją jego funkcji lub jego przeznaczeniem, inne elementy są pomijane, aby nie komplikować procesu analizy i studiowanie modelu nazywa się

A) dziedziczenie

B) hermetyzacja

C) polimorfizm

D) abstrakcja

E) wielomodelowy

F) konstrukcja hierarchiczna

Diagram wykorzystania UML wykorzystuje następujące typy jednostek:

B) Przypadki użycia

C) Aktorzy

D) Interfejsy

F) Państwa

G) Przedmioty

Jaka jednostka strukturalna UML znajduje się poza modelowanym systemem i bezpośrednio z nim współdziała

Klasa

B) interfejs (interfejs)

C) aktor

D) przypadek użycia

E) artefakt

F) węzeł

5 PODSTAWOWYCH FORM I METOD SZKOLENIA

W celu zwiększenia motywacji uczniów do opanowania wiedzy w dyscyplinie stosuje się:

Nauka kontekstowa, która pozwala zidentyfikować powiązania między konkretną wiedzą a jej zastosowaniem w praktyce;

Interaktywny model uczenia się, który przewiduje publiczną obronę pracy laboratoryjnej w formie prezentacji, przekazu na temat SROP i SIW;

Oprogramowanie pozwalające podczas wykonywania prac laboratoryjnych tworzyć grupy programistów, zarządzać procesami złożonego debugowania, testowania i programów, co zwiększa aktywność twórczą studentów, stymuluje teoretyczne rozumienie wiedzy i samodzielne poszukiwanie rozwiązań problemów jednostki zadanie;

Technologia projektowa, która obejmuje indywidualne lub zbiorowe działania w celu usystematyzowania wiedzy w pokrewnych dyscyplinach (moduły do ​​projektowania baz danych i projektowania IS), sugerujące rzeczywisty temat produkcji;

Szkolenie oparte na doświadczeniu naukowym i przemysłowym nauczycieli, co umożliwia aktywizację studentów poprzez skojarzenie własnych doświadczeń z przedmiotem studiów;

Technologia nauczania na odległość.

Do formowania poszczególnych zadań z elementami badań naukowych w wykonywaniu prac laboratoryjnych wykorzystuje się wyniki badań naukowych prowadzonych przez naukowców z wydziału.

6 CZAS KONSULTACJI

Konsultacje odbywają się zgodnie z harmonogramem prowadzącego.

1. Narzędzia do tworzenia oprogramowania.

W procesie opracowywania narzędzi programowych, w takim czy innym stopniu, wykorzystywane jest komputerowe wsparcie rozwoju PS.

Odbywa się to poprzez prezentację przynajmniej niektórych dokumentów programowych PS (przede wszystkim programów) na komputerowych nośnikach danych (np. dyski) i udostępnienie twórcy PS specjalne PS lub dołączone do komputera urządzenia specjalne stworzony do dowolnego przetwarzania takich dokumentów.

Jako taki specjalny PS możesz określić kompilator z dowolnego języka programowania.

Kompilator chroni programistę PS przed koniecznością pisania programów w języku komputerowym, który byłby wyjątkowo niewygodny dla programisty PS - zamiast tego pisze programy w dogodnym dla niego języku programowania, który odpowiedni kompilator automatycznie tłumaczy na język komputerowy .

Jako specjalne urządzenie wspierające proces tworzenia PS może służyć emulator dowolny język.

Emulator pozwala na wykonywanie (interpretację) programów w języku innym niż język komputera, który wspiera rozwój PS, na przykład w języku komputera, dla którego ten program jest przeznaczony.

PS, które mają wspierać rozwój innych PS, będą: wywołać oprogramowanie do tworzenia PS, a urządzenie komputerowe specjalnie zaprojektowane do wspierania rozwoju PS zostanie nazwane narzędzie do tworzenia oprogramowania sprzętowego.

Narzędzia programistyczne PS mogą być używane przez cały cykl życia PS do pracy z różnymi dokumentami programowymi. Tak więc edytora tekstu można użyć do opracowania prawie każdego dokumentu programu.

Z punktu widzenia funkcji, jakie narzędzia pełnią w tworzeniu oprogramowania, można je podzielić na następujące cztery grupy:

redaktorzy,

analizatory,

konwertery,

narzędzia wspomagające wykonywanie programów.

Redakcja wspierać projektowanie (tworzenie) niektórych dokumentów programowych na różnych etapach cyklu życia.

Jak już wspomniano, do tego możesz użyć jednego z uniwersalnych Edytor tekstu.

Można jednak zapewnić silniejsze wsparcie wyspecjalizowani redaktorzy: Każdy typ dokumentu ma swój własny edytor. W szczególności, na wczesnych etapach rozwoju, graficzne środki opisu (schematy, schematy itp.) mogą być szeroko stosowane w dokumentach. W takich przypadkach może się to bardzo przydać edytor graficzny.

Na etapie programowania (kodowania) zamiast edytora tekstu może być wygodniej edytor sterowany składnią A, który jest specyficzny dla używanego języka programowania.

Analizatory wykonywać statyczne przetwarzanie dokumentów, przeprowadzanie różnego rodzaju ich kontroli, identyfikowanie niektórych ich właściwości i gromadzenie danych statystycznych (np. sprawdzanie zgodności dokumentów z określonymi normami), lub dynamiczną analizę programów (np. w celu określić rozkład czasu programu według modułów programu).

Konwertery umożliwiają automatyczne przenoszenie dokumentów do innej formy prezentacji (na przykład formaterów) lub tłumaczenie dokumentu jednego typu na dokument innego typu (na przykład konwertery lub kompilatory), syntezę dokumentu z osobnych części itp.

Narzędzia wspierające wykonywanie programów, pozwalają na wykonywanie na komputerze opisów procesów lub ich poszczególnych części, przedstawionych w formie innej niż kod maszynowy lub kod maszynowy z dodatkowymi możliwościami jego interpretacji.

Przykładem takiego narzędzia jest kod emulatora innego komputera. Do tej grupy narzędzi należy również zaliczyć różne debuggery.

Zasadniczo każdy system programowania zawiera podsystem programu wykonawczego, który wykonuje najbardziej typowe fragmenty programu dla języka programowania i zapewnia standardową reakcję na wyjątki występujące podczas wykonywania programu (taki podsystem nazwiemy wsparciem wykonawczym), - można również uznać za instrument tej grupy.

2. Środowiska narzędziowe do tworzenia i utrzymania oprogramowania.

Obecnie każdy system programowania związany jest nie z osobnymi narzędziami (np. kompilatorem), ale pewien logicznie powiązany zestaw narzędzi programowych i sprzętowych, które wspierają rozwój i utrzymanie systemu oprogramowania w danym języku programowania lub skupiają się na dowolnym konkretnym obszarze tematycznym. Nazwiemy taką kolekcję środowisko narzędziowe do rozwoju i utrzymania PS.

Dla takich instrumentalnych środowisk jest to typowe

po pierwsze, korzystanie zarówno z narzędzi programowych, jak i sprzętowych, oraz

po drugie, pewna orientacja albo na określony język programowania, albo na określony obszar tematyczny.

Środowisko instrumentalne niekoniecznie musi funkcjonować na komputerze, na którym PS opracowany za jego pomocą będzie musiał być używany. Często taka kombinacja jest dość wygodna (jeśli tylko moc używanego komputera na to pozwala): nie ma potrzeby zajmowania się komputerami różnych typów, komponenty samego środowiska narzędziowego można włączyć do opracowanego PS.

Jeśli jednak komputer, na którym ma być używany PS, nie jest dostępny dla twórców tego PS (na przykład jest stale zajęty inną pracą, której nie można przerwać lub jest nadal w fazie rozwoju) lub jest niewygodny dla rozwijanie PS, lub moc tego komputera jest niewystarczająca do zapewnienia funkcjonowania wymaganego środowiska instrumentalnego, to tzw. podejście instrumentalno-celowe.

Jego istota tkwi w PS jest rozwijany na jednym komputerze, zwanym instrumentalnym, i zostanie zastosowany na innym komputerze, zwanym celem (lub obiektem).

Wyróżnić trzy główne klasy środowisk narzędziowych do rozwoju i utrzymania PS

(Rys. 16.1): ·

środowiska programistyczne,

prace związane z technologią komputerową,

systemy instrumentalne technologii programowania.

Środowisko programistyczne jest przeznaczone

głównie do wspomagania procesów programowania (kodowania), testowania i debugowania PS.

Miejsce pracy technologii komputerowej skupia się na wspieraniu wczesnych etapów rozwoju PS (specyfikacji) i automatycznym generowaniu programów według specyfikacji.

System narzędzi technologii programowania ma na celu wspieranie wszystkich procesów rozwoju i utrzymania przez cały cykl życia oprogramowania i koncentruje się na wspólnym opracowywaniu dużych systemów oprogramowania o długim cyklu życia.

W przypadku takich systemów koszt utrzymania zwykle przewyższa koszt rozwoju.

Ryż. 16.1. Główne klasy środowisk narzędziowych do rozwoju i utrzymania PS.

3. Środowiska programowania narzędzi.

Środowiska programistyczne zawierać przede wszystkim

Edytor tekstu, który pozwala na projektowanie programów w danym języku programowania, narzędzia pozwalające kompilować lub interpretować programy w tym języku, a także testować i debugować powstałe programy.

Ponadto mogą istnieć inne narzędzia, na przykład do statycznej lub dynamicznej analizy programu.

Narzędzia te współdziałają ze sobą za pośrednictwem zwykłych plików przy użyciu standardowych funkcji systemu plików.

Są następujące klasy środowisk programistycznych(patrz rys. 14.2): ·

środowiska ogólnego przeznaczenia,

środowiska zorientowane językowo.

Środowiska programistyczne ogólnego przeznaczenia zawierają zestaw narzędzi programowych, które wspierają tworzenie programów w różnych językach programowania (na przykład edytor tekstu, edytor linków lub interpreter języka komputera docelowego) i zwykle stanowią pewne rozszerzenie możliwości używany system operacyjny. Aby programować w takim środowisku w dowolnym języku programowania, będziesz potrzebować dodatkowych narzędzi zorientowanych na ten język (na przykład kompilatora).

Rys.16.2. Klasyfikacja środowisk narzędzi programistycznych.

Zorientowane językowo środowisko narzędziowe programowanie ma na celu wspomaganie rozwoju systemu oprogramowania w dowolnym języku programowania, a wiedza o tym języku została w znacznym stopniu wykorzystana przy budowaniu takiego środowiska. Dzięki temu w takim środowisku mogą być dostępne dość rozbudowane funkcje, które uwzględniają specyfikę tego języka.

Takie środowiska dzielą się na dwie podklasy:

środowiska interpretacyjne,

środowiska sterowane składnią.

Interpretacyjne środowisko programowania zapewnia interpretację programów w danym języku programowania, tj. zawiera przede wszystkim interpreter języka programowania, na który zorientowane jest to środowisko. Takie środowisko jest niezbędne dla języków programowania typu interpretacyjnego (takich jak Lisp), ale może być używane dla innych języków (takich jak na komputerze instrumentalnym).

Środowisko programistyczne sterowane składniowo opiera się na znajomości składni języka programowania, na który jest zorientowany. W takim środowisku zamiast edytora tekstu wykorzystywany jest edytor oparty na składni, co pozwala na korzystanie z różnych wzorców konstrukcji składniowych (dzięki temu tworzony program zawsze będzie poprawny składniowo). Równolegle z programem taki edytor formuje (w pamięci komputera) swoje drzewo składniowe, z którego mogą korzystać inne narzędzia.

4. Pojęcie technologii komputerowej do tworzenia oprogramowania i jej zadania.

Istnieją pewne trudności w opracowaniu rygorystycznej definicji technologii CASE (technologia komputerowa do rozwoju PS).

CASE to skrót od Computer-Aided Software Engineering (inżynieria programowania wspomaganego komputerowo). Ale bez pomocy (wsparcia) komputera PS od dawna nie były rozwijane (przynajmniej jest używany kompilator).

W rzeczywistości pojęcie to nabiera węższego (specjalnego) znaczenia, które stopniowo się zaciera (jak to zawsze bywa, gdy pojęcie nie ma ścisłej definicji).

Początkowo CASE rozumiano jako inżynierię wczesnych etapów tworzenia oprogramowania (definicja wymagań, opracowanie zewnętrznego opisu i architektury oprogramowania) z wykorzystaniem wsparcia oprogramowania (narzędzia programowe).

Obecnie CASE można również rozumieć jako inżynierię całego cyklu życia oprogramowania (w tym jego utrzymania), ale tylko w przypadku, gdy programy są częściowo lub całkowicie generowane zgodnie z dokumentami uzyskanymi na wskazanych wczesnych etapach rozwoju. W tym przypadku technologia CASE zasadniczo różni się od ręcznej (tradycyjnej) technologii wytwarzania oprogramowania: zmieniła się nie tylko treść procesów technologicznych, ale także ich całość.

Obecnie można scharakteryzować technologię komputerową rozwoju PS

Wykorzystanie wsparcia programowego do opracowania wymagań graficznych i specyfikacji graficznych PS,

Automatyczne generowanie programów w dowolnym języku programowania lub w kodzie maszynowym (częściowo lub całkowicie),

Wsparcie oprogramowania dla prototypowania.

Mówi się również, że technologia komputerowa do rozwoju PS jest „bez papieru”, tj. przeznaczony do komputerowej reprezentacji dokumentów programowych.

Jednak dość trudno jest śmiało odróżnić technologię ręcznego tworzenia oprogramowania od technologii komputerowej opartej na tych cechach. Oznacza to, że nie zostały wyróżnione najważniejsze w technice komputerowej.

Naszym zdaniem główna różnica między technologią ręcznego tworzenia oprogramowania a technologią komputerową jest następująca.

Technologia ręczna koncentruje się na opracowywaniu dokumentów, które są jednakowo rozumiane przez różnych programistów PS, podczas gdy technologia komputerowa koncentruje się na zapewnianiu semantycznego zrozumienia (interpretacji) dokumentów z obsługą oprogramowania dla technologii komputerowej.

Komputerowa reprezentacja dokumentów nie oznacza jeszcze takiego ich rozumienia. Natomiast semantyczne rozumienie dokumentów pozwala na automatyczne generowanie programów przez obsługę oprogramowania, a konieczność zapewnienia takiego rozumienia powoduje, że pożądane są różne formy graficzne dokumentów wejściowych. To właśnie umożliwia racjonalną zmianę samego zestawu procesów technologicznych dla rozwoju i utrzymania oprogramowania.

Z omówienia istoty technologii komputerowej można zrozumieć związane z tym zmiany w cyklu życia oprogramowania.

Jeśli podczas korzystania z technologii ręcznej główne wysiłki w zakresie rozwoju PS podjęto na etapach rzeczywistego programowania (kodowania) i debugowania (testowania), to w przypadku korzystania z technologii komputerowej było to na wczesnych etapach opracowywania PS (określanie wymagań i specyfikacja funkcjonalna).

Jednocześnie istotnie zmienił się charakter dokumentacji: zamiast całego łańcucha nieformalnych dokumentów skoncentrowanych na przekazywaniu informacji od klienta (użytkownika) do różnych kategorii programistów, powstaje prototyp PS obsługujący wybranego użytkownika interfejs i formalne specyfikacje funkcjonalne wystarczające do automatycznej syntezy (generacji) programów PS (lub przynajmniej znacznej ich części).

Jednocześnie stało się możliwe automatyczne generowanie części dokumentacji potrzebnej programistom i użytkownikom. Zamiast ręcznego programowania (kodowania) - automatyczne generowanie programów, co sprawia, że ​​samodzielne debugowanie i testowanie programów nie jest konieczne: zamiast tego dodaje się raczej głęboką automatyczną kontrolę semantyczną dokumentacji.

Charakter konserwacji PS również ulega znacznym zmianom: wszystkie zmiany są wprowadzane przez opiekuna tylko do specyfikacji (w tym prototypu), inne zmiany w PS są wprowadzane automatycznie.

Powiedziawszy to Cykl życia PS z wykorzystaniem technologii komputerowej można przedstawić na poniższym schemacie (rys. 16.3).

Ryż. 16.3. Cykl życia narzędzia programowego wykorzystującego technologię komputerową.

prototypowanie umożliwia zastąpienie pośredniego opisu interakcji między użytkownikiem a PS technologią ręczną (przy określaniu wymagań dla PS i opisu zewnętrznego PS) przez bezpośredni wybór przez użytkownika metody i stylu tej interakcji z mocowaniem wszystkie niezbędne szczegóły.

Zasadniczo na tym etapie sporządzany jest dokładny opis interfejsu użytkownika, zrozumiały dla obsługi oprogramowania technologii komputerowej i przy odpowiedzialnym udziale użytkownika: programista pokazuje użytkownikowi na monitorze różne opcje, a użytkownik wybiera opcje które są dla niego akceptowalne, użytkownik z pomocą programisty wprowadza oznaczenia przetwarzanych przez siebie obiektów informacyjnych i operacji na nich, wybiera sposób dostępu do nich i kojarzy je z różnymi oknami, menu, wirtualnymi klawiaturami itp. .

Wszystko to opiera się na obecności w oprogramowaniu obsługi technologii komputerowej konfigurowalnej powłoki z obszerną biblioteką pustych miejsc dla różnych fragmentów i szczegółów ekranu. W wyniku tych działań określana jest powłoka PS - górny poziom kontroli PS. Ten rodzaj prototypowania wydaje się być najlepszym sposobem na pokonanie bariery między użytkownikiem a deweloperem.

Opracowanie specyfikacji rozkłada się na kilka różnych procesów.

Jeżeli wykluczymy początkowy etap opracowywania specyfikacji (określanie wymagań), wówczas procesy te wykorzystują metody, które prowadzą do powstania sformalizowanych dokumentów, czyli używane są sformalizowane języki specyfikacji. Jednocześnie szeroko stosowane są graficzne metody specyfikacji, prowadzące do tworzenia różnych schematów i diagramów, które dość formalnie definiują strukturę środowiska informacyjnego i strukturę zarządzania PS. Do takich struktur dołączane są fragmenty danych i opisy programów, prezentowane w algebraicznych językach specyfikacji (na przykład z wykorzystaniem semantyki operacyjnej lub aksjomatycznej) lub w językach specyfikacji logicznej (oparte na logicznym podejściu do specyfikacji programu). Takie specyfikacje umożliwiają generowanie programów w dużej mierze lub całkowicie automatycznie.

Automatyczna kontrola specyfikacji

Systemy narzędziowe technologii programowania.

Do komputerowego wsparcia rozwoju i utrzymania dużych systemów oprogramowania o długim cyklu życia wykorzystywane są systemy narzędziowe technologii programowania.

System narzędzi technologii programowania to zintegrowany zestaw narzędzi programowych i sprzętowych, który obsługuje wszystkie procesy tworzenia i utrzymywania dużych systemów oprogramowania przez cały cykl życia w ramach określonej technologii.

Z definicji tej wynikają następujące główne cechy tej klasy obsługi komputera: ·

złożoność, ·

postaw na rozwój zespołu,

pewność technologiczna,

integracja.

Złożoność obsługi komputera oznacza, że ​​obejmuje ona wszystkie procesy rozwoju i utrzymania oprogramowania, a produkty tych procesów są skoordynowane i wzajemnie połączone. Dzięki temu system jest w stanie zapewnić co najmniej kontrolę nad kompletnością (kompletnością) tworzonej dokumentacji (w tym zestawu programów) oraz spójnością jej zmiany (wersjonowanie). Fakt, że obsługa komputera obejmuje również fazę obsługi PS oznacza, że ​​system musi obsługiwać jednocześnie pracę z kilkoma wariantami PS, zorientowanymi na różne warunki użytkowania PS i różne urządzenia z nim związane, tj. powinien zapewniać zarządzanie konfiguracją PS.

Koncentracja na wspólnym rozwoju oznacza, że ​​system musi wspierać zarządzanie (zarządzanie) pracą zespołu i dla różnych członków tego zespołu zapewniać różne prawa dostępu do różnych fragmentów produkcji procesów technologicznych.

Pewność technologiczna pomoc komputerowa oznacza, że ​​jego złożoność jest ograniczona do ram konkretnej technologii programowania. Systemy narzędziowe technologii programowania są wystarczająco duże i drogie, aby w jakiś sposób uzasadnić przeciążenie ich narzędzi. Dlatego zestaw narzędzi w nich zawartych jest starannie dobierany z uwzględnieniem potrzeb tematu, używanych języków i wybranej technologii programowania.

Zintegrowana obsługa komputera to:

integracja danych,

Integracja interfejsu użytkownika

Integracja przez akcje (funkcje),

Integracja danych oznacza, że ​​narzędzia działają zgodnie z ustalonym schematem informacyjnym (modelem) systemu, który określa zależność różnych fragmentów danych (obiektów informacyjnych) wykorzystywanych w systemie od siebie.

Integracja interfejsu użytkownika oznacza, że ​​wszystkie narzędzia są połączone jednym interfejsem użytkownika.

Integracja działania oznacza, że ​​po pierwsze, w systemie znajdują się części wspólne wszystkich narzędzi, a po drugie, niektóre narzędzia, wykonując swoje funkcje, mają dostęp do innych narzędzi.

Biorąc pod uwagę omawiane właściwości systemów instrumentalnych technologii programowania, możemy wyróżnić t ri ich główne składniki:·

rozwojowa baza danych (repozytorium),

zestaw narzędzi, ·

interfejsy.

Repozytorium – centralny komputerowy magazyn informacji związanych z projektem (rozwojem) PS przez cały cykl jego życia.

Toolkit - zestaw narzędzi, który definiuje możliwości, jakie system zapewnia zespołowi programistycznemu. Zwykle zestaw ten jest otwarty: oprócz zestawu minimalnego (narzędzia wbudowane), zawiera środki jego rozszerzenia (narzędzia importowane) oraz ustrukturyzowany, składający się z jakiejś wspólnej części wszystkich narzędzi (rdzeń) i strukturalny (czasami hierarchicznie powiązane) klasy narzędzi.

Interfejsy są podzielone na

1) niestandardowe

2) systemowe.

Interfejs użytkownika zapewnia programistom dostęp do narzędzi (języka poleceń itp.), implementowanych przez powłokę systemu.

Interfejsy systemowe zapewniają interakcję między narzędziami i ich wspólnymi częściami. Interfejsy systemu wyróżniają się jako elementy architektury ze względu na otwartość systemu - muszą być wykorzystywane przez nowe (importowane) narzędzia zawarte w systemie.

Najbardziej ogólną architekturę systemów instrumentalnych technologii programowania pokazano na rys. 16.4.

Wyróżnić dwie klasy systemy narzędziowe technologii programowania:

1) systemy narzędzi wsparcia projektu i

2) systemy instrumentalne zależne od języka.

System narzędzi wsparcia projektu- jest to system otwarty, który może wspierać rozwój PS w różnych językach programowania po odpowiednim jego rozszerzeniu o narzędzia programowe zorientowane na wybrany język. Taki system zawiera rdzeń (zapewniający w szczególności dostęp do repozytorium), zestaw narzędzi wspomagających zarządzanie (zarządzanie) rozwojem PS, niezależne od języka programowania narzędzia wspierające rozwój PS (tekstowe i graficzne). edytory, generatory raportów itp.), a także narzędzia do rozbudowy systemu.

System narzędzi zależny od języka- jest to system wspomagający tworzenie oprogramowania w dowolnym języku programowania, który zasadniczo wykorzystuje specyfikę tego języka w organizacji swojej pracy. Ta specyfika może wpływać zarówno na możliwości jądra (w tym na strukturę repozytorium), jak i na wymagania dotyczące powłoki i narzędzi.

Przykładem takiego systemu jest Ada Programming Support Environment (APSE).

Ryż. 16.4. Ogólna architektura systemów instrumentalnych technologii programowania.

Narzędzia programistyczne to zestaw narzędzi sprzętowych i programowych, które umożliwiają pisanie i debugowanie programów dla systemów mikroprocesorowych o wysokim stopniu niezawodności ich działania w rzeczywistych systemach.

Obejmują one:

Emulatory w obwodzie;

Symulatory oprogramowania;

Monitory debugowania;

Rady rozwojowe (komisje ewaluacyjne);

emulatory ROM;

Zintegrowane środowiska programistyczne.

Emulator w obwodzie- najpotężniejsze i najbardziej wszechstronne narzędzie do debugowania. Jest to narzędzie programowo-sprzętowe, które może zastąpić procesor w rzeczywistym systemie i sprawia, że ​​proces funkcjonowania debugowanego kontrolera jest przejrzysty, tj. łatwo kontrolowany, dowolnie kontrolowany i modyfikowany na wolę twórcy.

Funkcjonalnie emulatory w obwodzie dzielą się na te podłączone do zewnętrznego komputera i działające autonomicznie.

Dokowanie z debugowanym systemem odbywa się za pomocą specjalnego kabla z głowicą emulującą, którą wkłada się zamiast debugowanego lub równoległego do niego mikrokontrolera. W tym drugim przypadku mikrokontroler musi mieć tryb debugowania, w którym wszystkie jego wyjścia są przenoszone do trzeciego stanu.

Główne bloki funkcjonalne emulatora:

Debuger;

Węzeł emulacji mikrokontrolera;

pamięć emulacyjna;

Podsystem punktu przerwania.

Dodatkowe bloki:

procesor punktu przerwania;

kreślarz;

Profiler (analizator wydajności kodu);

Zegar czasu rzeczywistego;

Firmware, które zapewnia możliwość odczytu i modyfikacji emulowanego procesora;

Oprogramowanie układowe zapewniające synchroniczne sterowanie wymagane do emulacji w systemach wieloprocesorowych.

Debuger wykonuje:

Zarządzanie procesem emulacji (symulacji);

Wyświetlanie stanu i zawartości wszystkich rejestrów i pamięci na monitorze oraz w razie potrzeby ich modyfikacja (zmiana ich zawartości).

Debuger pozwala jednocześnie monitorować postęp programu i widzieć zgodność między tekstem źródłowym, obrazem programu w kodach maszynowych oraz stanem wszystkich zasobów emulowanego mikrokontrolera.

pamięć emulacji może być używany zamiast pamięci ROM debugowanego systemu, a także umożliwia debugowanie programu bez rzeczywistego systemu lub jego układu. (Nie ma potrzeby przeprogramowywania pamięci ROM.) Emulacja jest możliwa w całości lub w blokach.

kreślarz to analizator stanów logicznych, który pracuje synchronicznie z procesorem i rejestruje przepływ wykonywanych instrukcji oraz stan wybranych sygnałów zewnętrznych.

Procesor punktu przerwania umożliwia zatrzymanie wykonywania programu lub wykonanie innych czynności, np. uruchomienie lub zatrzymanie tracera w przypadku spełnienia określonych przez użytkownika warunków (o dowolnym stopniu złożoności) bez wychodzenia ze skali „czasu rzeczywistego”.

profiler umożliwia uzyskanie następujących informacji na podstawie wyników działania debugowanego programu:

Liczba wezwań do różnych sekcji programu;

Czas spędzony na realizacji poszczególnych odcinków programu.

Analiza informacji statystycznych dostarczonych przez profilera ułatwia identyfikację „martwych” lub przeciążonych sekcji programów, a w rezultacie optymalizację struktury debugowanego programu.

Zintegrowane środowisko programistyczne to zestaw narzędzi programowych, który obsługuje wszystkie etapy tworzenia oprogramowania — od pisania kodu źródłowego programu po kompilację i debugowanie go — oraz zapewnia prostą i szybką interakcję z innymi narzędziami (programowy debugger-symulator i programista).

Obecność wbudowanego edytora tekstu, kierownika projektu i systemu zarządzania bardzo pomaga programiście, oszczędzając mu wielu rutynowych czynności. Granica między pisaniem, edycją i debugowaniem programu jest zatarta.

Istnieją emulatory przeznaczone do emulacji mikrokontrolerów z rodzin Intel MCS 8051, MCS-196, Microchip PIC.

Symulator oprogramowania- narzędzie programowe symulujące działanie mikrokontrolera i jego pamięci. Zawiera debugger, model procesora i pamięci. Bardziej złożone symulatory zawierają również modele wbudowanych urządzeń peryferyjnych (timery, przetworniki ADC i systemy przerwań). Po załadowaniu programu do symulatora użytkownik może uruchamiać go w trybie krok po kroku lub ciągłym, ustawiać warunkowe lub bezwarunkowe punkty przerwania, kontrolować i dowolnie modyfikować zawartość komórek pamięci i rejestrów mikrokontrolera. Dzięki niemu możesz szybko sprawdzić logikę wykonania programu oraz poprawność operacji arytmetycznych.

Obecność interfejsu środowiska zewnętrznego pozwala oszczędzić programiście konieczności ręcznego ustawiania i zmiany zawartości rejestrów wejściowych, tj. możliwe jest tworzenie i elastyczne korzystanie z modelu środowiska zewnętrznego mikrokontrolera, który działa i współdziała z debugowany program zgodnie z zadanym algorytmem.

Cechą symulatorów programowych jest to, że wykonanie programów wczytanych do symulatora odbywa się w innej skali czasu niż rzeczywista. Jednak niższa cena, możliwość debugowania nawet w przypadku braku debugowanego układu urządzenia sprawiają, że symulatory oprogramowania są bardzo skutecznym narzędziem do debugowania.

Monitor debugowania- specjalny program ładowany do pamięci debugowanego systemu i zmuszający procesor do wykonywania, oprócz zadania aplikacji, również funkcji debugowania:

Ładowanie kodów aplikacji do pamięci bez monitora;

Ustawianie punktów przerwania;

Uruchamiaj i zatrzymuj załadowany program w czasie rzeczywistym;

Przechodzenie przez program użytkownika;

Przeglądanie, edycja zawartości pamięci i rejestrów kontrolnych.

Program monitorujący musi być podłączony do zewnętrznego komputera lub monitora w celu wizualizacji procesu debugowania.

Główną zaletą korzystania z monitora jest niski koszt przy zachowaniu możliwości debugowania w czasie rzeczywistym na mikrokontrolerze na płytce. Wadą jest rozproszenie zasobów mikrokontrolera na procedury debugowania i komunikacji (pamięć, przerwania, kanał szeregowy).

Tablice rozwojowe, czyli płytki ewaluacyjne, są rodzajem konstruktorów do prototypowania systemów aplikacyjnych. Wypuszczenie płytek ewaluacyjnych to nowoczesne podejście do promowania mikrokontrolerów na rynku. Zazwyczaj cały niezbędny sprzęt jest zainstalowany na płytce drukowanej w celu zademonstrowania możliwości mikrokontrolera, zapewniona jest komunikacja z komputerem i zapewnione jest pole do montażu obwodów zastosowanych przez użytkownika. Takie tablice można wykorzystać do montażu w urządzeniach małoseryjnych (5 - 20 szt.).

Dla wygody debugowania płyty rozwojowe są wyposażone w najprostsze narzędzia debugowania oparte na monitorze debugowania dla mikrokontrolerów z zewnętrzną magistralą i bez niej.

W pierwszym przypadku monitor debugowania jest dostarczany jako układ ROM, który jest instalowany w gnieździe (kołysce) na płycie. Płytka posiada również pamięć RAM dla programów użytkownika oraz kanał komunikacji z komputerem. Przykładem jest płytka INTEL dla mikrokontrolera 8051.

W przypadku mikrokontrolerów bez zewnętrznej magistrali, płytka rozwojowa ma wbudowane wewnętrzne obwody programujące ROM mikrokontrolera sterowane z zewnętrznego komputera. Aplikacja musi udostępniać wywołania funkcji debugowania i sam monitor. Po pobraniu i uruchomieniu programu wprowadzenie zmian wymaga skasowania pamięci ROM i nadpisania nowej wersji programu użytkownika.

Gotowy program uzyskuje się przez usunięcie monitora i wszystkich wywołań funkcji monitora. Przykładami są płytki rozwojowe firmy MICROCHIP do ich kontrolerów PIC, a także płytki rozwojowe do debugowania ich kontrolerów 80C750 Philips i 89C2051 Atmel.

Generalnie możliwości tego podejścia (płytka deweloperska + monitor) nie są tak uniwersalne, jak możliwości emulatora wewnątrzukładowego i należy wziąć pod uwagę przekierowanie zasobów kontrolera do trybu debugowania. Niemniej jednak kompletny zestaw narzędzi programowych i sprzętowych, które pozwalają rozpocząć instalację i debugowanie systemu aplikacji bez straty czasu, jest w wielu przypadkach czynnikiem decydującym, biorąc pod uwagę niższy koszt w porównaniu z uniwersalnym emulatorem.

emulatory ROM- są to narzędzia programowe i sprzętowe, które pozwalają na wymianę pamięci ROM na debugowanej płycie i zastąpienie pamięci RAM, gdzie program jest ładowany z komputera przez jeden ze standardowych kanałów komunikacyjnych. W takim przypadku starają się uniknąć wielokrotnych cykli przeprogramowania pamięci ROM. Metoda jest odpowiednia dla mikrokontrolerów, które mają dostęp do zewnętrznej pamięci programu. Pod względem złożoności i kosztów metoda jest porównywalna do korzystania z płytek rozwojowych, ale jest bardziej wszechstronna, ponieważ może być używana z dowolnym rodzajem mikrokontrolerów.

Obecnie istnieją modele „inteligentnych” emulatorów ROM, które pozwalają zajrzeć do wnętrza mikrokontrolera, czyli działają prawie jak emulator w obwodzie ze względu na szybkie przełączanie magistrali. Efekt powstaje tak, jakby monitor debugowania był zainstalowany na płytce użytkownika i jednocześnie nie pobierał żadnych zasobów sprzętowych z mikrokontrolera, poza niewielką strefą kroków programowych, około 4K. Takie urządzenie zostało opracowane przez FITON dla wszystkich istniejących i przyszłych mikrokontrolerów z rdzeniem MK 8051, ale dodatkowo nasycone różnymi urządzeniami wejścia/wyjścia. Obsługuje wiele mikrokontrolerów firm „PHILIPS”, „SIEMENS”, „OKI”.

Zintegrowane środowiska programistyczne(Integrated Development Environment, IDE) umożliwia programiście:

Korzystaj z wbudowanego edytora plików tekstowych, specjalnie skoncentrowanego na pracy z tekstami źródłowymi programu;