Temat: Czy przypadki użycia definiują system informatyczny ?

Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia zawierają w sobie wszystkie informacje potrzebne do stworzenia systemu IT ?

Jeśli tak - jak zdefiniować grę w snookera za pomocą jednego przypadku użycia (uderzenie w bilę).

Jeśli nie - jakich informacji nie zawierają (i z definicji zawierać nie mogą).

Pomijamy stronę biznesowo (ilość pieniędzy i czasu) / logistyczną (jakość zespołu realizującego) zagadnienia :)

Osobiście przychylam się do odpowiedzi twierdzącej i mam pomysł na zdefiniowanie gry w snookera za pomocą opisu 'uderzenia w bilę' :)

Ale ciekaw jestem zdania innych forumowiczów....

Temat: Czy przypadki użycia definiują system informatyczny ?

Przypadki użycia, choćby zostały stworzone ściśle według specyfikacji UML, nigdy nie będą zawierały wszystkich inf., ponieważ z definicji opisują jedynie behawioralną stronę systemu. Są bardzo przydatne w zapisie wymagań funkcjonalnych, jednak struktury systemu w ten sposób nijak nie opiszesz.

Z drugiej strony, chętnie odpowiedziałbym słowami mojego nauczyciela matematyki z liceum, który na podobnie stawiane pytania: "czy można...?" odpowiadał: "można zawsze, ale po co" :) Można przez wiele godzin głowić się jakich sztuczek użyć, aby zawrzeć jak najwięcej informacji na takim diagramie, jaki proponujesz, ale ja jestem zwolennikiem czytelności rozwiązań. Przy okazji zazwyczaj właśnie to drugie rozwiązanie w dłuższym czasie okazuje się bardziej opłacalne.

Ale chętnie poznałbym Twój pomysł na zdefiniowanie gry w snookera za pomocą jednego przypadku użycia.

pozdrawiam serdecznie,
Sławek

Temat: Czy przypadki użycia definiują system informatyczny ?

Sławomir Plamowski:
Przypadki użycia, choćby zostały stworzone ściśle według specyfikacji UML,

UML nie specyfikuje jak tworzyć przypadki użycia i do czego one służą.
UML opisuje sposób pewnego przedstawienia UC na diagramach.

nigdy nie będą zawierały wszystkich inf., ponieważ z definicji opisują jedynie behawioralną stronę systemu.

Czy system to coś więcej niż 'zachowanie' :) ?

Są bardzo przydatne w zapisie wymagań funkcjonalnych, jednak struktury systemu w ten sposób nijak nie opiszesz.

Ale czy można wnioskować o strukturze na podstawie wymagań funkcjonalnych ?
Czy mając formalnie zdefiniowane UC i odpowiednie kompetencje, jestem w stanie stworzyć strukturę ?

Jeśli nie - na podstawie czego ma powstawać struktura? :)

Z drugiej strony, chętnie odpowiedziałbym słowami mojego nauczyciela matematyki z liceum, który na podobnie stawiane pytania: "czy można...?" odpowiadał: "można zawsze, ale po co" :)

Skoro można ... ale przed chwilą pisałeś, że nie można ... :>

Można przez wiele godzin głowić się jakich sztuczek użyć, aby zawrzeć jak najwięcej informacji na takim diagramie, jaki proponujesz, ale ja jestem zwolennikiem czytelności rozwiązań.

Diagram ma za zadanie przedstawić pewne cechy UC a nie je definiować :>
Dokumentacja to nie jest 'zbiór diagramów' :)

Ale chętnie poznałbym Twój pomysł na zdefiniowanie gry w snookera za pomocą jednego przypadku użycia.

... uderzanie kijem bili białej w taki sposób, aby pozostałe bile w odpowiednim porządku wpadły do kieszeni. Można uderzać kijem jedynie w białą bilę. Gracz, który uzyska więcej punktów, gdy na stole nie zostaną już żadne bile, wygrywa. :)

To tak w ogromnym uproszczeniu... :)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:
Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia zawierają w sobie wszystkie informacje potrzebne do stworzenia systemu IT ?

Nie

Jeśli tak - jak zdefiniować grę w snookera za pomocą jednego przypadku użycia (uderzenie w bilę).

Jeśli nie - jakich informacji nie zawierają (i z definicji zawierać nie mogą).

Pomijamy stronę biznesowo (ilość pieniędzy i czasu) / logistyczną (jakość zespołu realizującego) zagadnienia :)

Osobiście przychylam się do odpowiedzi twierdzącej i mam pomysł na zdefiniowanie gry w snookera za pomocą opisu 'uderzenia w bilę' :)

Ale ciekaw jestem zdania innych forumowiczów....

UML do niedawna składał się z 13. diagramów (niedawno doszedł 14.). Są to różne perspektywy i aspekty działania systemu, który docelowo (w domyśle) będzie realizowany w obiektowym języku programowania. UML nie służy do definicji struktury danych (ale niektórym to się udaje :)). UML nie służy do definicji algorytmów (jest ogólniejszy od tego). Aczkolwiek kiedyś czytałem, że jest chyba ze 32 klasy diagramów czynności, które przekładają się jednoznacznie na kod.

To pytanie jest w rodzaju "Czy się da jedynie z cegieł zbudować dom?"

Temat: Czy przypadki użycia definiują system informatyczny ?

Aleksander Olszewski:

Jakub Wojt:
Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia zawierają w sobie wszystkie informacje potrzebne do stworzenia systemu IT ?

Nie

Jakich informacji nie można przedstawić w ten sposób ? :)

Ale ciekaw jestem zdania innych forumowiczów....

UML do niedawna składał się z 13. diagramów (niedawno doszedł 14.). Są to różne perspektywy i aspekty działania systemu, który docelowo (w domyśle) będzie realizowany w obiektowym języku programowania.

Zgadzam się. Diagram służą do opisu systemu z pewnej perspektywy w celu pokazania pewnych jego kluczowych (z punktu widzenia twórców UML) aspektów.

UML nie służy do definicji struktury danych (ale niektórym to się udaje :)).

Dlaczego nie ?
Wydaje mi się, że taki diagram klas dość dobrze się do tego nadaje.
Ostatecznie w systemie będą tylko klasy a system musi dobrze modelować strukturę danych :)

To pytanie jest w rodzaju "Czy się da jedynie z cegieł zbudować dom?"

Raczej: Czy precyzyjny opis cech domu jaki inwestor chce posiadać, pozwoli kwalifikowanemu inżynierowi na jego zaprojektowanie (domu) ?

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Aleksander Olszewski:

Jakub Wojt:
Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia zawierają w sobie wszystkie informacje potrzebne do stworzenia systemu IT ?

Nie

Jakich informacji nie można przedstawić w ten sposób ? :)

Na wymagania systemu składają się wygania funkcjonalne oraz niefunkcjonalne (ograniczenia). Sam diagram przypadków użycia nie zawiera chronologii. Tak więc z diagramu nie wynika czy mamy najpierw rozbić bile, czy następuje zmiana itd. Ja osobiście słabo kojarzę Snookera. Zadasz się na moje doświadczenie i profesjonalizm oddając w moje ręce realizację takiego systemu? Brakuje tu co najmniej diagramu procesów biznesowych, tak aby nie wchodzić w inne diagramy. Ale one również nie są w stanie w pełni opisać systemu.

Ogólna zasada podczas analiz jest taka: przyszły użytkownik w sposób słowno-ustny opisuje to co chce, my to później modelujemy UCD, po to by nawiązać pierwszą nić porozumienia między klientem a programistami.

UML nie służy do definicji struktury danych (ale niektórym to się udaje :)).

Dlaczego nie ?
Wydaje mi się, że taki diagram klas dość dobrze się do tego nadaje.
Ostatecznie w systemie będą tylko klasy a system musi dobrze modelować strukturę danych :)

System to nie tylko klasy, to też baza danych. Dobrze zaprojektowana baza danych przeżyje nie jedną wersję systemu. Dlaczego się nie da? Bo UMLowe narzędzia CASE tworzą beznadziejne skrypty generujące bazę. Bo OMG nie zajmuje się relacyjnymi bazami, jak już to współuczestniczy w pracach nad specyfikacją obiektowych baz danych. Bo bazy nadal zawierają strukturalne elementy programowania. Bo w bazach występują trigery, których nie przechowamy w ramach obiektowego narzędzia CASE. Wystarczy?

Temat: Czy przypadki użycia definiują system informatyczny ?

Na wymagania systemu składają się wygania funkcjonalne oraz niefunkcjonalne (ograniczenia). Sam diagram przypadków użycia nie zawiera chronologii.

Diagram jest tylko pewnym ergonomicznym i jednocześnie formalnym zapisem pewnych faktów jakie zachodzą między UC a aktorami.

Diagram w żadnym razie nie definiuje UC.
Definicja UC: 'A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.'

Tak więc z diagramu nie wynika czy mamy najpierw rozbić bile, czy następuje zmiana itd.

Zgadza się :)

Ja osobiście słabo kojarzę Snookera. Zadasz się na moje doświadczenie i
profesjonalizm oddając w moje ręce realizację takiego systemu?

Tak, ale tylko pod warunkiem, że samemu uda mi się przygotować dokumentację która pozwoli Ci na ' przepisanie / przetłumaczenie jej ' na program komputerowy :)

Brakuje tu co najmniej diagramu procesów biznesowych, tak aby nie wchodzić w inne diagramy. Ale one również nie są w stanie w
pełni opisać systemu.
Ogólna zasada podczas analiz jest taka: przyszły użytkownik w sposób słowno-ustny opisuje to co chce, my to później modelujemy UCD, po to by nawiązać pierwszą nić porozumienia
między klientem a programistami.

Nie wiem, czy dobrze zrozumiałem UCD ale wydaje mi się że przypadki użycia graja w nim kluczową rolę w procesie tworzenia dokumentacji systemu. W linkowanym dokumencie nie znalazłem odniesień do innych 'bytów / artefaktów' które byłyby do tego potrzebne.
(http://en.wikipedia.org/wiki/User-centered_design)

... user centered design, mainly: persona, scenarios, and essential use cases.

Przy czym 'scenario' rozumiem jako use case 'do daily work' :)

UML nie służy do definicji struktury danych (ale niektórym to się udaje :)).

Dlaczego nie ?
Wydaje mi się, że taki diagram klas dość dobrze się do tego nadaje.
Ostatecznie w systemie będą tylko klasy a system musi dobrze modelować strukturę danych :)

System to nie tylko klasy, to też baza danych.

Trzeba przynać - w SQL dość fajnie można tworzyć modele danych ale IMHO notacja 'obiektowa' jest po prostu praktyczniejsza a w porównaniu z surowym SQL można w niej wyrazić więcej.

Na 'klasach' dużo łatwiej np. zdefiniować typ bazowy dla np. 'samochodów' (BaseCar, później typy Truck, Van, Sedan ... )

Jeśli wykluczyć powyższe wydaje mi się, że notacja strukturalna jest równoważna obiektowej...

Coraz częściej baza danych jest traktowana jako tylko i wyłącznie warstwa persistance dla modelu domeny wyrażonego 'w klasach' i myślę, że trend się utrzyma.

[...] Bo w bazach występują
trigery, których nie przechowamy w ramach obiektowego narzędzia

a zdarzenia typu: afterSave i beforeSave ? ;)Jakub Wojt edytował(a) ten post dnia 17.06.11 o godzinie 10:54

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Trzeba przynać - w SQL dość fajnie można tworzyć modele danych ale IMHO notacja 'obiektowa' jest po prostu praktyczniejsza a w porównaniu z surowym SQL można w niej wyrazić więcej.

Na 'klasach' dużo łatwiej np. zdefiniować typ bazowy dla np. 'samochodów' (BaseCar, później typy Truck, Van, Sedan ... )

Jeśli wykluczyć powyższe wydaje mi się, że notacja strukturalna jest równoważna obiektowej...

Coraz częściej baza danych jest traktowana jako tylko i wyłącznie warstwa persistance dla modelu domeny wyrażonego 'w klasach' i myślę, że trend się utrzyma.

[...] Bo w bazach występują
trigery, których nie przechowamy w ramach obiektowego narzędzia

a zdarzenia typu: afterSave i beforeSave ? ;)

Co do różnicy między podejściem obiektowym a relacyjnym trzeba zwrócić uwagę na jedną podstawową różnicę:

podejście relacyjne - dane
podejście obiektowe - zachowanie

W podejściu obiektowym ważne jest zachowanie obiektów, nie ich stan (który powinien być z resztą ukryty), natomiast w podejściu relacyjnym ważne są dane - triggery oraz procedury są tu umniejszone tylko do roli okazyjnego manipulowania nimi.Wojciech Soczyński edytował(a) ten post dnia 17.06.11 o godzinie 11:05

Temat: Czy przypadki użycia definiują system informatyczny ?

W podejściu obiektowym ważne jest zachowanie obiektów, nie ich stan (który powinien być z resztą ukryty),

Ale zachowanie istnieje tylko i wyłącznie w kontekście stanu.
Tzn. zachowanie ma ten stan zmienić albo udostępnić.
Tak mi się przynajmniej wydaje.

Temat: Czy przypadki użycia definiują system informatyczny ?

Parafrazując pytanie:

Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia telewizora zawierają w sobie wszystkie informacje potrzebne do jego stworzenia?

Moim zdaniem odpowiedź nasuwa się sama: nie .... po drugie słowa precyzyjnie i formalnie oznaczają różne rzeczy:

precyzja: dokładność ścisłość

formalny: dotyczący formy; wymagany dla zachowania formy, przepisowy, legalny.

Metody formalne (ang. formal methods) - w informatyce tym terminem określa się oparte na matematyce podejścia do specyfikacji, projektowania i weryfikacji oprogramowania lub systemów informatycznych.

Jednym ze sposobów bardzo nawet "precyzyjnego" ale nadal nie "formalnego" sposobu użycia przypadków użycia jest metoda (metody) opisane przez A.Cockbourna. Rzecz w tym, że przypadki użycia, nawet najdokładniej opisane, opisują TYLKO czarną skrzynkę, której wnętrze należy zaprojektować by ją wykonać.... i ktoś to musi zrobić....

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

W podejściu obiektowym ważne jest zachowanie obiektów, nie ich stan (który powinien być z resztą ukryty),

Ale zachowanie istnieje tylko i wyłącznie w kontekście stanu.
Tzn. zachowanie ma ten stan zmienić albo udostępnić.
Tak mi się przynajmniej wydaje.

Oczywiście, że jakiś stan być musi, natomiast najlepiej żeby był on jak najbardziej ukryty, tak żebyśmy nie musieli nim martwić.

Najlepszym przykładem w świecie rzeczywistym będzie samochód. Wykonujemy na nim tylko metody "przyspiesz, zatrzymaj się, skręć etc", nie interesuje nas żaden konkretny stan, który za nimi stoi. Gdyby ktoś wymienił nam silnik spalinowy na elektryczny, to jeżeli nam o tym nie powie to w zasadzie nie zauważymy różnicy.

W paradygmacie obiektowym dane są środkiem do osiągnięcia celu a nie celem jak paradygmacie relacyjnym....Wojciech Soczyński edytował(a) ten post dnia 18.06.11 o godzinie 22:13

Temat: Czy przypadki użycia definiują system informatyczny ?

Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia telewizora zawierają w sobie wszystkie informacje potrzebne do jego stworzenia?

Myślę, że trzeba zapytać o to twórcę pierwszego telewizora ;)

Moim zdaniem odpowiedź nasuwa się sama: nie .... po drugie słowa precyzyjnie i formalnie oznaczają różne rzeczy:
precyzja: dokładność ścisłość

formalny: dotyczący formy; wymagany dla zachowania formy, przepisowy, legalny.

Miałem na myśli formalność w sensie 'notacji matematycznej'.
"Jeśli coś wiesz, to zapisz to 'matematycznie'. Notacja 'matematyczna' nie jest trudna pod warunkiem, że się wie co chce się zapisać.".

Metody formalne (ang. formal methods) - w informatyce tym terminem określa się oparte na matematyce podejścia do specyfikacji, projektowania i weryfikacji oprogramowania lub systemów informatycznych.

I właśnie o to mi chodzi :)
Tzn. o zapis przypadków użycia w sposób możliwie 'matematyczny'.
I nie chodzi o 'formę' a o to, że taki zapis wymusza precyzję.

Jednym ze sposobów bardzo nawet "precyzyjnego" ale nadal nie "formalnego" sposobu użycia przypadków użycia jest metoda (metody) opisane przez A.Cockbourna.
Rzecz w tym, że przypadki
użycia, nawet najdokładniej opisane, opisują TYLKO czarną skrzynkę, której wnętrze należy zaprojektować by ją wykonać.... i ktoś to musi zrobić....

Zgadza się, ale na podstawie czego powstaje skrzynka którą trzeba zaprojektować ?
Według mnie - przypadków użycia.

Temat: Czy przypadki użycia definiują system informatyczny ?

Ale zachowanie istnieje tylko i wyłącznie w kontekście stanu.
Tzn. zachowanie ma ten stan zmienić albo udostępnić.
Tak mi się przynajmniej wydaje.

Oczywiście, że jakiś stan być musi, natomiast najlepiej żeby był on jak najbardziej ukryty, tak żebyśmy nie musieli nim martwić.

Dlaczego ma być 'ukryty' ?
'My' czyli kto ? :)

Najlepszym przykładem w świecie rzeczywistym będzie samochód. Wykonujemy na nim tylko metody "przyspiesz, zatrzymaj się, skręć etc", nie interesuje nas żaden konkretny stan, który za nimi stoi.

Na prostej drodze nie zakręca się 'w lewo'.
Na czerwonym świetle nie powinno się przyspieszać. :)

Według mnie - interesuje nas kontekst stanu a nie sam stan.

Gdyby ktoś wymienił nam silnik spalinowy na elektryczny, to jeżeli nam o tym nie powie to w zasadzie nie zauważymy różnicy.

Myślę, że jak na prostej drodze samochód skręci 'w lewo', to bez względu na to jaki ma silnik, wyląduje w rowie / polu / lesie / budynku / słupie...

Może trochę wolniej albo trochę szybciej - ale 'wyląduje'.

W paradygmacie obiektowym dane są środkiem do osiągnięcia celu a nie celem jak paradygmacie relacyjnym....

A co jest celem wykonywania jakiejkolwiek akcji na procesorze?
... No może poza NOP ;)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Czy precyzyjnie (formalnie) zdefiniowane przypadki użycia telewizora zawierają w sobie wszystkie informacje potrzebne do jego stworzenia?

Myślę, że trzeba zapytać o to twórcę pierwszego telewizora ;)

jako inżynier elektronik odpowiem: nie, z tą informacją niczego nie zbudujemy, ktoś musi opracować projekt ideowy, elektryczny itp.

Miałem na myśli formalność w sensie 'notacji matematycznej'.
"Jeśli coś wiesz, to zapisz to 'matematycznie'. Notacja 'matematyczna' nie jest trudna pod warunkiem, że się wie co chce się zapisać.".

problem w tym, że nie wszystko co robi człowiek da się matematycznie zapisać a mimo to dzieje się...

I właśnie o to mi chodzi :)
Tzn. o zapis przypadków użycia w sposób możliwie 'matematyczny'.
I nie chodzi o 'formę' a o to, że taki zapis wymusza precyzję.

co mi z tego, że ktoś "matematycznie" zapisze "czynność zmiany kanału w telewizorze" jeśli nadal nie ma tu krzty tego co jest potrzebne by ten telewizor powstał... po drugie cel jest inny: użytkownik opowie "tak jak rozumie", że chce "zmieniać kanały", ktoś musi to zamienić na "wymagana jest możliwość łatwej zmiany częstotliwości odbieranego sygnału"....

Zgadza się, ale na podstawie czego powstaje skrzynka którą trzeba zaprojektować ?
Według mnie - przypadków użycia.

tak jak w telewizorze: opis tego co ma się stać nijak się nie ma do opisu jak to się dzieje.

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Ale zachowanie istnieje tylko i wyłącznie w kontekście stanu.
Tzn. zachowanie ma ten stan zmienić albo udostępnić.
Tak mi się przynajmniej wydaje.

Oczywiście, że jakiś stan być musi, natomiast najlepiej żeby był on jak najbardziej ukryty, tak żebyśmy nie musieli nim martwić.

Dlaczego ma być 'ukryty' ?
'My' czyli kto ? :)

co obchodzi użytkownika konstrukcja skrzyni biegów? Kierowca (typowy czyli np. nie Kubica) musi umieć zmieniać biegi nie mając pojęcia jak działa skrzynia biegów.

Najlepszym przykładem w świecie rzeczywistym będzie samochód. Wykonujemy na nim tylko metody "przyspiesz, zatrzymaj się, skręć etc", nie interesuje nas żaden konkretny stan, który za nimi stoi.

Na prostej drodze nie zakręca się 'w lewo'.
Na czerwonym świetle nie powinno się przyspieszać. :)

to powyżej to przepisy ruchu drogowego, samochód na czerwonym świetle może przyśpieszyć, to kierowca "raczej" nie powinien tego robić...samochód nie może mieć blokady na czerwone światło ani na "brak asfaltu"... bo byłby niebezpieczny, samochód ma reagować na naciskane pedały i na ruchy kierownicy.

Według mnie - interesuje nas kontekst stanu a nie sam stan.

absolutnie nie, patrz samochód wyżej: ani projektant ani producent samochodu nie jest ograniczany kodeksem drogowym, nie licząc wymaganego wyposażenia (światła mijania itp.). W tym kraju (i nie tylko) maksymalna dopuszczalna prędkość jest znacznie mniejsza niż możliwa do osiągnięcia przez większość samochodów...

A co jest celem wykonywania jakiejkolwiek akcji na procesorze?
... No może poza NOP ;)

normalni użytkownicy nie wykonują akcji na procesorze tylko piszą, oglądają firmy, piorą (w pralkach także są procesory)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Ale zachowanie istnieje tylko i wyłącznie w kontekście stanu.
Tzn. zachowanie ma ten stan zmienić albo udostępnić.
Tak mi się przynajmniej wydaje.

Oczywiście, że jakiś stan być musi, natomiast najlepiej żeby był on jak najbardziej ukryty, tak żebyśmy nie musieli nim martwić.

Dlaczego ma być 'ukryty' ?
'My' czyli kto ? :)

My czyli konsumenci jakiegoś API.

Najlepszym przykładem w świecie rzeczywistym będzie samochód. Wykonujemy na nim tylko metody "przyspiesz, zatrzymaj się, skręć etc", nie interesuje nas żaden konkretny stan, który za nimi stoi.

Na prostej drodze nie zakręca się 'w lewo'.
Na czerwonym świetle nie powinno się przyspieszać. :)

Według mnie - interesuje nas kontekst stanu a nie sam stan.

Gdyby ktoś wymienił nam silnik spalinowy na elektryczny, to jeżeli nam o tym nie powie to w zasadzie nie zauważymy różnicy.

Myślę, że jak na prostej drodze samochód skręci 'w lewo', to bez względu na to jaki ma silnik, wyląduje w rowie / polu / lesie / budynku / słupie...

Nie jest z pewnością odpowiedzialności obiektu klasy samochód sprawdzanie czy może wykonać jakiś manewr - od tego jest obiekt klasy kierowca.

Może trochę wolniej albo trochę szybciej - ale 'wyląduje'.

W paradygmacie obiektowym dane są środkiem do osiągnięcia celu a nie celem jak paradygmacie relacyjnym....

A co jest celem wykonywania jakiejkolwiek akcji na procesorze?
... No może poza NOP ;)

Rezultatem wykonania operacji przez procesor są albo dane albo operacja I/O. Nie mowie wcale, że stan nie jest potrzebny i że dane nie krążą pomiędzy obiektami, natomiast nie są celem samym w sobie tak jak w przypadku bazy danych, która jest na nich skupiona.

Temat: Czy przypadki użycia definiują system informatyczny ?

Myślę, że trzeba zapytać o to twórcę pierwszego telewizora ;)

jako inżynier elektronik odpowiem: nie, z tą informacją niczego nie zbudujemy, ktoś musi opracować projekt ideowy, elektryczny itp.

Na podstawie czego tworzy się projekt ideowy / elektryczny ?
Czy jeśli klient nie poda wystarczająco dużo i wystarczająco precyzyjnych informacji, można taki projekt stworzyć ?

problem w tym, że nie wszystko co robi człowiek da się matematycznie zapisać a mimo to dzieje się...

z chęcią poznam jakieś przykłady :)

I nie chodzi o 'formę' a o to, że taki zapis wymusza precyzję.

co mi z tego, że ktoś "matematycznie" zapisze "czynność zmiany kanału w telewizorze" jeśli nadal nie ma tu krzty tego co jest potrzebne by ten telewizor powstał...

Pod warunkiem, że osoba, która ten telewizor tworzy, nie zna się na budowie telewizorów.

Jeśli osoba się zna na budowie telewizorów – ze zbioru ‘wszystkich telewizorów jakie może zmontować ;)’ wybierze tylko te, które pozwalają na taką zmianę kanału, jak opisał to użytkownik.

po drugie cel jest inny: użytkownik opowie "tak jak rozumie", że chce "zmieniać kanały", ktoś musi to zamienić na "wymagana jest możliwość łatwej zmiany częstotliwości odbieranego sygnału"....

Zgadzam się. Ale czy tworzeniu tych wymagań, autor ma prawo dodać coś ‘od siebie’ tzn. Dodać coś, co nie zostało wcześniej określone przez klienta ?

Czy podczas tworzenia wymagań należy bazować na własnych domysłach czy też pomóc klientowi w precyzyjnym zdefiniowaniu( szczególny przykład opisu ;) przypadków użycia ? A następnie, tak uzyskaną informacje ‘przetłumaczyć’ na system informatyczny ?

Ostatecznie każdy diagram, schemat, każda linia kodu wywodzi się z jakieś wcześniej ustalonej informacji. Według mnie tak informacja powinna pochodzić od klienta a najłatwiejszym sposobem na jej wydobycie jest wymuszenie precyzyjnego opisu UC systemu.

Z resztą, co więcej może powiedzieć klient niż to, jak system ma działać (UC)?

Zgadza się, ale na podstawie czego powstaje skrzynka którą trzeba zaprojektować ?
Według mnie - przypadków użycia.

tak jak w telewizorze: opis tego co ma się stać nijak się nie ma do opisu jak to się dzieje.

Więc trzeba molestować klienta, żeby to powiedział (tzn jak to się dzieje), ale 'w swoim języku'. Takie szczegółowe opisy tez będą przypadkami użycia. Klient (i nie ma w tym nic złego) tylko tak potrafi opisywać system.

Według mnie, projekt informatyczny jest ‘tłumaczeniem’ informacji od klienta na program komputerowy.

Żeby tłumaczyć – trzeba znać co najmniej dwa języki ... i mieć co tłumaczyć :)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

Myślę, że trzeba zapytać o to twórcę pierwszego telewizora ;)

jako inżynier elektronik odpowiem: nie, z tą informacją niczego nie zbudujemy, ktoś musi opracować projekt ideowy, elektryczny itp.

Na podstawie czego tworzy się projekt ideowy / elektryczny ?
Czy jeśli klient nie poda wystarczająco dużo i wystarczająco precyzyjnych informacji, można taki projekt stworzyć ?

ktoś musi zaprojektować "obwody wewnętrzne" o czym klient nie ma bladego pojęcia...elektronik montujący telewizor musi mieć projekt a tego mu nie da "oglądacz filmów"

problem w tym, że nie wszystko co robi człowiek da się matematycznie zapisać a mimo to dzieje się...

z chęcią poznam jakieś przykłady :)

inaczej, gdyby prawdą było, że wszystko co człowiek robi da się matematycznie zapisać, nie mi byśmy pisać na tym forum :), dam bardzo prosty przykład: niczego co robi prezes firmy czy kierownik projektu albo np. prawnik, nie za da się zapisać matematycznie, zwracam uwagę, że nie chodzi o zapis tego "co ktoś zrobił" bo to jest historia i da się ją zapisywać na niezliczone sposoby, mam na myśli to "jak się to robi" a jak wiemy sztuczna inteligencja nadal nie jest w stanie powstać...

I nie chodzi o 'formę' a o to, że taki zapis wymusza precyzję.

co mi z tego, że ktoś "matematycznie" zapisze "czynność zmiany kanału w telewizorze" jeśli nadal nie ma tu krzty tego co jest potrzebne by ten telewizor powstał...

Pod warunkiem, że osoba, która ten telewizor tworzy, nie zna się na budowie telewizorów.

musi na podstawie "oczekiwań" klienta dopiero go zaprojektować a potem dopiero wykonać...

Jeśli osoba się zna na budowie telewizorów – ze zbioru ‘wszystkich telewizorów jakie może zmontować ;)’ wybierze tylko te, które pozwalają na taką zmianę kanału, jak opisał to użytkownik.

to jest "tłuczenie historii:" a nie tworzenie.... ktoś jednak kiedyś zaprojektował ten pierwszy telewizor...

po drugie cel jest inny: użytkownik opowie "tak jak rozumie", że chce "zmieniać kanały", ktoś musi to zamienić na "wymagana jest możliwość łatwej zmiany częstotliwości odbieranego sygnału"....

Zgadzam się. Ale czy tworzeniu tych wymagań, autor ma prawo dodać coś ‘od siebie’ tzn. Dodać coś, co nie zostało wcześniej określone przez klienta ?

zależy co...

Czy podczas tworzenia wymagań należy bazować na własnych domysłach czy też pomóc klientowi w precyzyjnym zdefiniowaniu( szczególny przykład opisu ;) przypadków użycia ? A następnie, tak uzyskaną informacje ‘przetłumaczyć’ na system informatyczny ?

na domysłach absolutnie nie, model rozwiązania należy testować własnie "przypadkami użycia"...

Ostatecznie każdy diagram, schemat, każda linia kodu wywodzi się z jakieś wcześniej ustalonej informacji. Według mnie tak informacja powinna pochodzić od klienta a najłatwiejszym sposobem na jej wydobycie jest wymuszenie precyzyjnego opisu UC systemu.

informacje od klienta "chce wiedzieć kiedy pracownicy wchodzą i wychodzą z pracy" nie implikuje struktury danych bazy wejść i wyjść... w przeciwnym wypadku to klient rysował by diagramy ERD.

Z resztą, co więcej może powiedzieć klient niż to, jak system ma działać (UC)?

dlatego potrzebny jest projektant... a projektowanie jest procesem twórczym a nie automatycznym deterministycznym ...

Zgadza się, ale na podstawie czego powstaje skrzynka którą trzeba zaprojektować ?
Według mnie - przypadków użycia.

tak jak w telewizorze: opis tego co ma się stać nijak się nie ma do opisu jak to się dzieje.

Więc trzeba molestować klienta, żeby to powiedział (tzn jak to się dzieje), ale 'w swoim języku'. Takie szczegółowe opisy tez będą przypadkami użycia. Klient (i nie ma w tym nic złego) tylko tak potrafi opisywać system.

chciał bym zobaczyć jak ktoś z mojej mamy wyciągnie informacje na temat przestrajania obwodów wejściowych telewizora, który ma w pokoju ..._

Według mnie, projekt informatyczny jest ‘tłumaczeniem’ informacji od klienta na program komputerowy.

Żeby tłumaczyć – trzeba znać co najmniej dwa języki ... i mieć co tłumaczyć :)

myślę, że tu tkwi różnica w podejściach, bo moim zdaniem program komputerowy to narzędzie jakie dostanie do ręki jego użytkownik, a narzędzie to należy zaprojektować, ktoś kto zażyczy sobie kalkulator i dokładnie opisze co będzie liczył raczej nie opisze algorytmu potęgowania czy pierwiastkowania jakiego wszystkie małe kalkulatory używają z prostego powodu: nie potrafi tego i po to mu ten kalkulator...

Temat: Czy przypadki użycia definiują system informatyczny ?

Na podstawie czego tworzy się projekt ideowy / elektryczny ?
Czy jeśli klient nie poda wystarczająco dużo i wystarczająco precyzyjnych informacji, można taki projekt stworzyć ?

ktoś musi zaprojektować "obwody wewnętrzne" o czym klient nie ma bladego pojęcia...elektronik montujący telewizor musi mieć projekt a tego mu nie da "oglądacz filmów"

oczywiście że nie ma. Klient dla mu tylko informacje które w połączeniu z wiedzą elektronika pozwolą ma na zaprojektowanie danego urządzenia.

... mogłem w temacie dopisać - 'i przy założeniu, że współpracują specjaliści w swojej dziedzinie'

problem w tym, że nie wszystko co robi człowiek da się matematycznie zapisać a mimo to dzieje się...

z chęcią poznam jakieś przykłady :)

inaczej, gdyby prawdą było, że wszystko co człowiek robi da się matematycznie zapisać, nie mi byśmy pisać na tym forum :),

może inaczej - każdy 'model czegoś' można zapisać matematycznie.
Jeśli mamy model możemy go wyrazić 'matematycznie' albo - precyzyjnie.
Zapis 'matematyczny' to tylko notacja :)

dam bardzo prosty przykład: niczego co robi prezes firmy czy kierownik projektu albo np. prawnik, nie za da się zapisać matematycznie,

A można jakkolwiek zapisać ?
Notacja matematyczna ma tylko to do siebie, że wymusza precyzję.
Jeśli nie da się zapisać 'precyzyjnie' to nie ma szans na napisanie programu który będzie to coś realizować. Program musi być precyzyjny.

zwracam uwagę, że nie chodzi o zapis tego "co ktoś zrobił" bo to jest historia i da się ją zapisywać na niezliczone sposoby,

Ale to nie szkodzi. Chodzi tylko o to, żeby model (wyrażony np. równaniami 'matematycznymi') spełniał oczekiwania klienta. Przez 'oczekiwania klienta' rozumiem zrealizowane przypadki użycia.
Jeśli można 'oczekiwania klienta' zapisać jakoś inaczej, tzn. nie jako 'przypadki użycia', to proszę o nazwę tego czegoś :)
[i]Podobnie jak w fizyce - opis (model) grawitacji stworzony przez Newtona całkowicie zaspokajał potrzeby żyjących wtedy np. inżynierów. Nikt nie narzekał na to, że siłę grawitacji można modelować inaczej :)[i]

Jeśli osoba się zna na budowie telewizorów – ze zbioru ‘wszystkich telewizorów jakie może zmontować ;)’ wybierze tylko te, które pozwalają na taką zmianę kanału, jak opisał to użytkownik.

to jest "tłuczenie historii:" a nie tworzenie.... ktoś jednak kiedyś zaprojektował ten pierwszy telewizor...

Ciekawe czy estymował czas i koszty na zasadzie '300%' ;)

Zgadzam się. Ale czy tworzeniu tych wymagań, autor ma prawo dodać coś ‘od siebie’ tzn. Dodać coś, co nie zostało wcześniej określone przez klienta ?

zależy co...

np. zmodyfikować przepadek użycia albo coś do niego dodać ? Jakkolwiek zmienić jakąkolwiek informację udzieloną przez klienta.

informacje od klienta "chce wiedzieć kiedy pracownicy wchodzą i wychodzą z pracy" nie implikuje struktury danych bazy wejść i wyjść... w przeciwnym wypadku to klient rysował by diagramy ERD.

Implikuje pewną klasę diagramów ERD. I to tylko dla osoby która zna ERD.
Uważam, że im precyzyjniejszy opis - tym ta klasa jest coraz 'mniejsza'.
Precyzyjny opis to taki, który pozwala na bezpośrednie 'przetłumaczenie' go na diagramy ERD (albo jakieś inne) i eliminuje sztukę z procesu tworzenia systemu IT.

Z resztą, co więcej może powiedzieć klient niż to, jak system ma działać (UC)?

dlatego potrzebny jest projektant... a projektowanie jest procesem twórczym a nie automatycznym deterministycznym ...

Aktualnie tak, ale...
Uważam, że jeśli jest twórczy, to tylko dlatego, że klient nie potrafi precyzyjnie zdefiniować wymagań. I w związku z tym należy mu w tym pomóc a nie go w tym wyręczać.

Sztuka to tworzenie czegoś z niczego.
Realizacja projektu IT polega na 'tłumaczeniu' wymagań klienta.
Uprawianie, w ww. kontekście, sztuki jest według mnie czymś bardzo szkodliwym.

Więc trzeba molestować klienta, żeby to powiedział (tzn jak to się dzieje), ale 'w swoim języku'. Takie szczegółowe opisy tez będą przypadkami użycia. Klient (i nie ma w tym nic złego) tylko tak potrafi opisywać system.

chciał bym zobaczyć jak ktoś z mojej mamy wyciągnie informacje na temat przestrajania obwodów wejściowych telewizora, który ma w pokoju ..._

Hm..
Realizacja projektu polega na 'projektowaniu' wymagań klient, przez 'pryzmat' wiedzy projektanta / wykonawcy na 'ekran' systemu IT :)
W tym procesie jest dokładnie tyle miejsca na sztukę ile 'nie-precyzji' w opisie klienta.

Temat: Czy przypadki użycia definiują system informatyczny ?

W paradygmacie obiektowym dane są środkiem do osiągnięcia celu a nie celem jak paradygmacie relacyjnym....

A co jest celem wykonywania jakiejkolwiek akcji na procesorze?
... No może poza NOP ;)

Rezultatem wykonania operacji przez procesor są albo dane albo operacja I/O.

Czyli jakaś operacja na danych, prawda ?

Nie mowie wcale, że stan nie jest potrzebny i że dane nie krążą pomiędzy obiektami, natomiast nie są celem samym w sobie tak jak w przypadku bazy danych

Sam stan nie. Ale jego - porządana - zmiana.
Ew. prezentacja wyniku zmiany.

która jest na nich skupiona.

Diagram klas UML może 'wyrazić' więcej niż diagram ER.
Jeśli ktoś ma problem z czytaniem UML - ER jest jego rozwiązaniem. Jeśli ktoś nie ma problemów z UML - nie widzę powodu, żeby ta osoba tworzyła diagram ER.