Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #32551
| From | heby <heby@poczta.onet.pl> |
|---|---|
| Newsgroups | pl.comp.programming |
| Subject | Re: Ada Tutorial - w Instytucie Lotnictwa |
| Date | 2019-05-10 20:33 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qb4g5e$4s8$1@dont-email.me> (permalink) |
| References | (4 earlier) <b177541d-5a3c-4d33-bf62-b05209ff7d12@googlegroups.com> <qav3qi$qv$1@dont-email.me> <0f4d8931-97a9-458d-9f80-49c2e268f195@googlegroups.com> <qb1ju2$hsi$1@dont-email.me> <d1f69133-f9dd-4896-b27c-74684ecc846e@googlegroups.com> |
On 10/05/2019 08:03, Maciej Sobczak wrote: >> Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write >> once, debug endlessly"". Problem w tym że to jest walidne w każdym >> języku a w c++ z roku na rok o dziwo coraz mniej. > Tak. Oczywiście potrzeba, żeby programiści z roku na rok też robili postępy w tym, jak korzystają z tego języka. O tym piszę od początku jako elemencie niezbędnym obok bezpiecznego języka. >>> Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej ścieżki. >> Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga >> się pokrycia określonego procentu. > Co to jest "typowy system"? Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to bardzo drogie narzędzia do kontrolowania procesu produkcji. Zacznij od pojęcia "test plan". https://en.wikipedia.org/wiki/Test_plan > Bo w konteście całej ludzkiej aktywności programistycznej, w ogóle wymaganie weryfikacji czegokolwiek jest niszowe. Jeśli to coś miga diodą to masz rację. Ale jak już steruje czymkolwiek to przegapiłeś rewolucję. Nie wejdziesz na rynek aplikacji krytycznych bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega regorystycznej weryfikacji. > A jak jesteśmy w niszach, to trudno mówić o "typowym systemie". Typowy system critical safe. Nikt tu nie mówi o pisaniu migania diodą i narzekania że wyjątki są do tego kiepskie. > W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia. Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware. >> Ba, wymaga się pokrycia nie tylko >> ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych. > Też w procentach? Tak. Np. ze wszystkich 2^32 adresów IP przetestowaliśmy 5% i wydają się działać w duperelowatym kawałku kodu do migania diodą jak przyjdzie pakiet broadcast. >> Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100% > No to może za dużo jest tych linii? Albo ktoś je napisał a dopiero potem zorientował się, że warto by zrobić jakąś weryfikację. To niedobrze. Nie, weryfikacja powstaje *zanim* napiszesz kod. Tylko że ludzie piszący wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia itd itp. Zarządza się ryzykiem. > Trochę się motasz. Przedsionek serca to system krytyczny. Miganie diodą też nim może być, zależy co to za dioda. > A jeśli masz system, w którym ktoś napisał kilkaset tyś. linii a potem się zorientował, że nie może ich pokryć Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym punkcie systemu inaczej. Ryzyko mikrokernela jest wysokie i tam stopień pokrycia i wymagania co do jakosci są wyższe. Dla sterownika wentylatora nie są tak wyśrubowane a do sterownika poświetlenia klawiatury są niskie. >, to może jednak ten system od samego początku nie był tak bardzo krytyczny i tylko ludzie sobie dodają fasonu twierdząc, że jest. Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod bardzo restrykcyjne zasady. W nich samego pisania jest mało, znacznie więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji, odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj całosć procesu jest automatyzowana w miarę możliwości w całości. >> Do testowania pokrycia stosuje się automatykę. >> Ona widzi wyjątki tak samo jak logjmp. > Nie. Nie widzi. > Cytat ze standardu do F-35 (bo tam zaczęliśmy): > " > AV Rule 208: > C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.) > Rationale: Tool support is not adequate at this time. To trzeba zmienić tool. > Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie. Mało porawdopodobne. Standardy tego typu powstają kiedy obecni użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10 lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do weryfikacji i to zaskakującej jakości jak na projekt "akademicki". > Zmartwię Cię. Wymaganie pokrycia dotyczy kodu obiektowego a nie źródłowego. Na tym poziome nie ma już wiedzy o tym, który kawałek kodu był generyczny a który nie. I źródłowego, i wynikowego i każdego innego który ma wpływ na bezpieczeństwo. Przykładowo narzędzia do weryfikacji potrafią powiązać dowolną linijkę kodu źródłowego z wymaganiem formalnym i śledzić zmiany. >> Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a >> i tak ktoś rzuci wyjątkiem > Nie rzuci, bo jest zakaz. Właśnie po to. Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może ktoś pogroził paluszkiem. >> w przemyśle >> nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99% > A dlaczego nie dało się pokryć tego brakującego 1%? Bo wymaga to 99% czasu więcej? Szacujący ryzyko ocenia na ile chce mieć system działający vs system w wiecznej fazie produkcji. >> System w którym lata milion wyjątków jest do dupy. Ale narzekanie że >> funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek >> jest absurdalne. > A kod obiektowy, w którym jest milion nieprzetestowanych rozgałęzień jest OK? Ale co to ma wspólnego z fukcją generyczną? Kod obiektowy w którym jest milion nieprzetestowancyh rozgałęzień ma milion miejsc do poprawienia na weryfikacji. Zakasujesz rękawy i pokrywasz albo masz w zespole człowieka który nie dopuści do takiego dziadostwa. Ale spokojnie, autoamty do weryfikacji też nie odpuszczą a na samym końcu ktoś się pod tym podpisuje i to jego złapią za jaja w razie wypadku.
Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-17 10:41 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-17 20:43 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-18 06:01 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-19 19:24 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:46 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-20 15:02 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 16:20 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa slawek <x.y@org.org> - 2019-04-23 21:27 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-04-24 00:11 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Borneq <borneq@antyspam.hidden.pl> - 2019-08-04 18:11 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:43 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-22 11:51 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-07 12:15 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-05-07 21:38 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-07 22:52 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-07 22:54 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:31 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:04 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:19 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:03 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 20:33 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:29 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-08 06:32 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:51 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:21 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:34 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:21 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 21:00 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:40 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-13 09:27 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 03:05 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-14 00:53 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 23:51 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-15 21:25 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-15 23:55 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 00:55 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Adam M <amorawski@magna-power.com> - 2019-05-14 06:25 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 23:09 -0700
Re: Ada Tutorial - w Instytucie Lotnictwa Roman Tyczka <noemail@because.no> - 2019-05-09 11:32 +0200
Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-09 10:29 -0700
csiph-web