🚀 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

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-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.