diagram przypadków użycia - stół

Witam,
Mam odrobinę praktyki którą nabyłem podczas studiów w tworzeniu przypadków użycia za pomocą UML. Jednak na pewnej rozmowie kwalifikacyjnej zostałem zaskoczony nietypowym pytaniem.
Dostałem zdjęcie stołu takiego składanego jak na zdjęciu w załączniku.

I poproszono mnie o rozrysowanie diagramu przypadków użycia tego stołu.

Za aktorów uznałbym np: Użytkownik i Konserwator ( naprawa usterki itp).
Problem mam z Użytkownikiem a mianowicie z konkretną kwestią tj: stworzyłem przypadek użycia "Korzystaj z powierzchni stołu" i stół w zasadzie może być całkowicie rozłożony, złożony lub częściowo złożony ( lewe lub prawe skrzydło). Pytanie brzmi czy umieszczam na diagramie przypadków użycia przypadki użycia jako np: "Rozłóż stół w całości" , "złóż stół w całości" , " rozłóż częściowo stół" czy to absolutnie pomijam na diagramie przypadków użycia. Czy koncepcja iż przypadek "Korzystaj z powierzchni stołu" a do niego skierowane są 3 przypadki rozszerzające <<extend>> typu "rozłóż stół w całości" jest zasadna czy jednak to kompletnie chybiony pomysł.

Ew. jak tę kwestię uwzględnić/pominąć w przypadkach użycia. Byłbym wdzięczny za jakiś komentarz.

Uprzejmie dziękuje za poświęcony czas :)

Zadanie postawione w ten sposób jest trochę głupie wg mnie. Zauważ, że nie podałeś żadnego kontekstu.

Realizacja jakich procesów biznesowych wspierana jest przez wspomniany "stół"?

Zamień "stół" na "foobar" i rozpisz przypadki użycia. Zamiast obrazka stołu może być obraz fraktalny, cokolwiek.

Nie czuję się specjalistą, więc liczę na to, że ktoś bardziej kompetentny oceni moje wymysły:

1. W stole nie zaimplementowano chyba żadnych funkcjonalności dla Konserwatora jako naprawiacza, więc nie widzę tu potrzeby powoływać takiego użytkownika
2. Choć faktycznie przydałby się jakiś Rurek, który by "ruszył dpsko po prostu" i ten "upir*olony stół" wyczyścił... (cytaty za: K. Durczok)
3. Myślę, że extend się tam nada
4. Użyłbym też include: rozłóż cały blat includuje rozłóż blat lewy i rozłóż blat prawy
5. Używaj stołu wydaje mi się nazbyt abstrakcyjne, użyłbym połóż przedmiot na blat i zdejmij przedmiot z blatu
6. A tak poza tym, to nie zapominaj o szufladach, one też są częścią stołu, choć nie są częścią blatu :)

Dziwne zadanie. Ja bym potraktował to jako warstwę domenową: rozpisał encje "Stół", "Użytkownik", ich metody, np. dla stołu "rozłóż", "dodajUżytkownika", do tego ValueObject "Obiad", wokół encji serwisy domenowe (usiądźPrzyStole, zjedzPrzyStole) itp.

Zgadzam się z quetzakubica, że to dziwne zadanie, nie wiem do czego ten stół ma służyć (w fabryce jest produktem, w magazynie się go przechowuje, w sklepie może być wyłożony na wystawie, w domu służy do spotkań rodzinnych czy jedzenia), a mam napisać przypadki użycia. Diagram przypadków użycia ma odpowiedzieć na pytanie, co aktor może zrobić w systemie, więc, bez opisania kontekstu, nie da się napisać dobrych przypadków użycia.
Co do encji, to nie dałbym metody "rozłóż" klasie Stół, bo stół sam się nie potrafi rozłożyć, do jakiejś nowej klasy przekazałbym stół i użytkownika i to ona by odpowiadała za rozkładanie stołu.

Trochę mnie dziwi wasze poszukiwanie kontekstu w tym przypadku (bo w ogólności to bardzo dobry mechanizm), ale to jest stół i on nie służy do tego, żeby go wyprodukować czy magazynować. Ja potraktowałem stół jak gotowy program oferujący użytkownikowi niewielkie, ale bardzo konkretne możliwości, które mamy rozpoznać i określić UC. To jest zadanie rekrutacyjne, sprawdzające jak potrafisz użyć swoich UMLowych zdolności do opisania pewnego (abstrakcyjnego z punktu widzenia programisty) problemu.