🚀 go-pugleaf

W dniu 2015-07-10 o 08:53, Borneq pisze:
> Chciałbym zapytać się osób mających doświadczenie w projektowaniu nowych
> aplikacji. Jak myślę, aplikację należy projektować od góry, najpierw
> podzielić funkcjonalnie na pakiety i klasy, potem wybrać metody tych
> klas a następnie będzie można wypełniać już kodem te metody?
> Tylko jak nie widząc jeszcze aplikacji ustalić te klasy?

Zaczynasz od analizy opisu aplikacji. Rzeczowniki to kandydaci na klasy. 
Najczęściej będą to klasy typu Entity czyli będące kontenerem danych. Na 
podstawie opisów przypadków użycia ustalasz klasy kontrolerów które są 
odpowiedzialne za logikę działania aplikacji. Dla punktów styku 
aplikacji z użytkownikiem lub innymi systemami ustalasz klasy boundary 
których rolą jest "dopasowanie" do konkretnego systemu. Np. jeśli Twoja 
aplikacja wysyła powiadomienia mailowe, możesz zbudować klasę boundary 
odpowiedzialną za komunikację z serwerem pocztowych.

Czasowniki w opisie tekstowym to kandydaci na metody/usługi kontrolera.

-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

W dniu 2015-07-10 o 09:04, Piotr Rezmer pisze:
> Najczęściej będą to klasy typu Entity czyli będące kontenerem danych. Na
> podstawie opisów przypadków użycia ustalasz klasy kontrolerów które są
> odpowiedzialne za logikę działania aplikacji. Dla punktów styku
> aplikacji z użytkownikiem lub innymi systemami ustalasz klasy boundary

Muszę jeszcze doczytać o klasach entity i boundary. Na razie znalazłem 
http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/OBPROG/io3.doc

W dniu 2015-07-10 o 09:19, Borneq pisze:
> Muszę jeszcze doczytać o klasach entity i boundary. Na razie znalazłem
> http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/OBPROG/io3.doc

A język UML? Słyszałem niepochlebne opinie, że wcale nie jest żadnym 
językiem.

W dniu 2015-07-10 o 09:33, Borneq pisze:

> A język UML? Słyszałem niepochlebne opinie, że wcale nie jest żadnym
> językiem.

UML na razie się nie przejmuj. To jest notacja której będziesz używać 
jak potrzebujesz np. zrobić schemat systemu.

Natomiast tak się składa, że często skrót UML pojawia się w szkoleniach 
dotyczących modelowania aplikacji.



-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

W dniu 2015-07-10 o 09:19, Borneq pisze:

> Muszę jeszcze doczytać o klasach entity i boundary. Na razie znalazłem
> http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/OBPROG/io3.doc


Entity:
- jej rolą jest przechowywanie danych
- nie definiujemy w niej metod (pomijając gettery i settery)

np.

Public class User {

	private String login;
	private String firstName;
	private String lastname;
	
public String GetLastName() {
	return lastName;
}
public String GetFirstName() {
	return firstName;
}
}

Boundary:
-rolą jest przyjęcie danych (np. formularze danych) lub wysłanie danych.

Oprócz tego jest jeszcze kilka prostych zasad dotyczących tworzenia 
architektury aplikacji. W momencie gdy zdefiniujesz już nazwy i role 
klas, umieszczasz je w odpowiednich warstwach, licząc od góry:

warstwa aplikacji - zawiera klasy specyficzne dla konkretnej aplikacji, 
zakładasz że te klasy nie będą używane w innych aplikacjach
warstwa obiektów biznesowych - zawiera klasy związane np. z logiką 
biznesową. Klasy z tej warstwy mogą się pojawić w przyszłości w innych 
aplikacjach. W tej warstwie pojawią się najprawdopodobniej klasy typu 
Entity.
warstwa usług - klasy które zapewniają np. odczyt/zapis pliku, 
komunikację z innymi systemami. Te klasy nie realizują żadnej logiki, 
Tutaj możemy umieścić np. część klas komunikacyjnych Boundary.

Klasy powinny być zaprojektowane tak by komunikowały się jedynie z 
sąsiednimi warstwami. Zależności powinny być tylko w jednym kierunku (z 
góry na dół).

  	

-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

On 2015-07-10 08:53, Borneq wrote:
> Chciałbym zapytać się osób mających doświadczenie w projektowaniu nowych
> aplikacji. Jak myślę, aplikację należy projektować od góry, najpierw
> podzielić funkcjonalnie na pakiety i klasy, potem wybrać metody tych
> klas a następnie będzie można wypełniać już kodem te metody?
> Tylko jak nie widząc jeszcze aplikacji ustalić te klasy?

Generalnie, jak masz już pomysł/potrzebę na aplikację, to najpierw 
dobrze jest ją opisać. Co ma robić, po co, jakie wejścia danych, jakie 
wyjścia. Najlepiej w zespole, jak jest, bo każdy widzi to nieco inaczej. 
Dopiero jak już mniej więcej wiadomo o co chodzi, to zaczyna się 
wyodrębnianie modułów/funkcjonalności, szukanie co jest podobne a co 
inne, co można zrobić gotowymi bibliotekami, a co jest zupełnie nowe.

Na tej podstawie można zrobić zgrubny schemat aplikacji, zadecydować o 
technologiach i bibliotekach jakie mają być użyte. Ile i jakie warstwy 
będą używane, i w jakich kierunkach. Kierunkach w sensie że jak masz 
jądro aplikacji, kod biznesowy, to jednym kierunkiem jest zachowanie 
danych (warstwy [w kierunku od środka] to np. serwis/klasa 
DAO/entity/persistence manager/baza danych), kolejnym jest UI (warstwy: 
kontroler/model widoku/widok), kolejnym możne być komunikacja sieciowa 
lub z urządzeniem, lub silnik wyszukiwania czy obliczania, etc. Ważne 
jest że warstwy z różnych kierunków nie rozmawiają ze sobą, a jedynie z 
warstwą pod/nad w tym samym kierunku, jedynie centralna logika biznesowa 
komunikuje się z górnymi warstwami każdego kierunku.

Stosunkowo często technologie/biblioteki wymuszą pewne rozwiązania, 
pewien określony szkielet aplikacji. Sam z siebie taki Spring robi w 
zasadzie za szkielet, dostarczając mnóstwa bloków do budowy aplikacji, 
tudzież wyznacza sposób tworzenia pozostałych bloków.

Teraz z funkcjonalności które nie są zapewniane z gotowców trzeba 
porobić bloki funkcjonalności, pamiętając że każdy blok działa tylko w 
jednej warstwie aplikacji. Trzeba opisać co on ma robić, i jeśli to 
istotne, to jak ma to robić. Trzeba także opisać jakie dane i jak będą 
wymieniane, jaką kontrolę mają jedne bloki nad innymi, i inne metody 
komunikacji.

I teraz dopiero można zacząć projektować klasy, jak to Piotr już opisał. 
W każdym bloku skupiaj się tylko na nim, i na blokach które będą z nim 
współdziałały, w sensie że API tego współdziałania jest wspólne. 
Generalnie dobrze jest zacząć od podstawowej funkcjonalności, o ile nie 
została już dostarczona bibliotekami.

Jak już masz klasy to można je powoli zacząć wypełniać kodem. Ale dobrze 
jest zacząć od unit testów, bo będziesz musiał pomyśleć o szczegółach 
działania klas, jak ich się używa, czy wygodnie, czy może jednak API 
jest uciążliwe i warto by je zmienić. Pomyślisz też o edge case'ach, 
limitach, możliwych błędach i ich obsłudze. Po czymś taki sam kod klas 
to często jest "pikuś" ;-).

Wielu programistów tego nie docenia, ale tak naprawdę samo klepanie kodu 
to nie więcej jak 1/5 czasu pracy nad aplikacją. Często mniej.

-- 
Arivald

W dniu 2015-07-10 o 22:07, Arivald pisze:
> Na tej podstawie można zrobić zgrubny schemat aplikacji, zadecydować o
> technologiach i bibliotekach jakie mają być użyte. Ile i jakie warstwy
> będą używane, i w jakich kierunkach. Kierunkach w sensie że jak masz

Przykładowy projekt: edytor MIDI
To prostsze w porównaniu z jakimiś rozbudowanymi problemami, widzę na 
razie dwie warstwy: obsługa midi i GUI.
Więc będę miał pakiety:
com.borneq.midedit.midi
com.borneq.midedit.gui
Ale z drugiej strony, dobrze było by mieć kod wielokrotnego użytku, a 
więc może zrobić projekt-bibliotekę do midi dołączaną do programu. Wtedy 
nazwy pakietów były by krótsze - z nazwy biblioteki wypadło by 
'midedit', a z nazwy programu 'gui'

W dniu 2015-07-11 o 07:32, Borneq pisze:
> Ale z drugiej strony, dobrze było by mieć kod wielokrotnego użytku, a

Na przykład dla znacznie prostszego playerka MIDI, poza tym player ten 
można szybciej wykonać i przetestować w nim obsługę czytania Midi zanim 
weźmiemy się za edytor.

On 2015-07-11 07:32, Borneq wrote:
> W dniu 2015-07-10 o 22:07, Arivald pisze:
>> Na tej podstawie można zrobić zgrubny schemat aplikacji, zadecydować o
>> technologiach i bibliotekach jakie mają być użyte. Ile i jakie warstwy
>> będą używane, i w jakich kierunkach. Kierunkach w sensie że jak masz
>
> Przykładowy projekt: edytor MIDI
> To prostsze w porównaniu z jakimiś rozbudowanymi problemami, widzę na
> razie dwie warstwy: obsługa midi i GUI.

Samą obsługę MIDI warto podzielić na warstwy, górna realizuje protokół 
MIDI, dolna odwołuje się do sprzętu.

I zainteresuje się pakietem javax.sound.midi, bo to co próbujesz zrobić 
może być już zrobione.

Co do GUI, to są rożne metody, ale generalnie dobrze jest mieć warstwę 
lub warstwy pośrednie, poczytaj o MVC, i innych.

https://pl.wikipedia.org/wiki/Model-View-Controller

I znowu warto użyć gotowca, np. http://wiki.eclipse.org/JFace

-- 
Arivald

On 2015-07-10 08:53, Borneq wrote:
> Chciałbym zapytać się osób mających doświadczenie w projektowaniu nowych
> aplikacji.

Zacznij od dowolnej ksiązki z zakresu inżynierii oprogramowania. Każda 
aplikacja wymaga podejścia indywidualnego do etapu projektowania. W 
ektremalnym przypadku może w ogóle go nie być.

> Jak myślę, aplikację należy projektować od góry

Nie. Nalezy ją projektować tak jak jest w danym wypadku lepiej. 
kryterium "lepiej" jest szerokie.

> Tylko jak nie widząc jeszcze aplikacji ustalić te klasy?

Jest specyfikacja 100% i implementujesz bo są ustalone, albo brak 
specyfikacji i jakieś metody zwinne z okolic Agile. Przy takiej 
rozciągłości potencjalnej specyfikacji nie ma jak wskazać palcem dobrej 
metody ustalania "tych klas". W skrócie: pytanie jest na tyle ogolne że 
każda odpowiedź, wliczając złośliwe, jest na miejscu.