Portal Społecznościowy Rowerzystów


Projekt konceptualny

Sformułowanie zadania projektowego

Postanowiono, że w ramach projektu z przedmiotu Zaawansowane Techniki Bazodanowe zostanie zrealizowany portal społecznościowy łączący zarejestrowanych w nim rowerzystów. Stwierdzono, że aktualnie brakuje na rynku lub jest ubogi wybór podobnego rozwiązania, które w swoim zbiorze funkcjonalności posiadało by możliwość kojarzenia rowerzystów na wspólne wycieczki lub wyprawy rowerowe. Można odnieść wrażenie że rynek podobnych rozwiązań jest aktualnie przesycony. Jednakże wszystkie dostępne w polskim Internecie rozwiązania posiadają funkcjonalności zbliżone do popularnych blogów, na których użytkownicy mają możliwość chwalenia się / prezentowania swoich wycieczek rowerowych wraz ze zdjęciami. Żaden z dostępnych portali nie posiada bardziej rozbudowanych funkcjonalności poza opisywaniem dotychczasowych wycieczek oraz prowadzenia statystyk.

Analiza stanu wyjściowego

Opis istniejących rozwiązań:

  • www.bikestats.pl – polska strona internetowa umożliwiająca użytkownikom tworzenie blogów przebytych wypraw, portal nie oferuje jednak możliwości kojarzenia rowerzystów pod względem preferencji oraz planów wycieczek.
  • www.mapmyrun.com – amerykańska strona internetowa umożliwiająca użytkownikiem logowanie swoich treningów biegowych. Strona oferuje również współprace z najnowocześniejszymi platformami mobilnymi takimi jak iOS oraz BlackBerry, co umożliwia przesyłanie śladu GPS na bieżąco do portalu.
Określenie scenariuszy użycia

Rejestracja w systemie

  1. Użytkownik nie jest zalogowany, klika na przycisk „Register”.
  2. Zostaje wyświetlony formularz wprowadzenia danych rejestracji (login, hasło, e-mail itp).
  3. Użytkownik wprowadza dane i zatwierdza je przyciskiem „OK”.
  4. Następuje walidacja wprowadzonych danych(dostępność loginu i e-maila, poprawność danych).
  5. Zostaje wyświetlone potwierdzenie rejestracji użytkownikowi.

Logowanie

  1. Użytkownik nie jest zalogowany, przechodzi do strony logowania.
  2. Użytkownik wpisuje swój login i hasło, a następnie klika przycisk „Login”.
  3. System sprawdza poprawność loginu i hasła.
  4. Jeśli wprowadzone dane są poprawne, następuje przekierowanie do strony głównej systemu.
  5. Jeśli login lub hasło są niepoprawne to system wyświetla użytkownikowi odpowiedni komunikat.

Edycja danych w profilu

  1. Użytkownik jest zalogowany, przechodzi do zakładki „User profile”.
  2. Zostają wyświetlone dane użytkownika.
  3. Użytkownik klika przycisk „Edit”.
  4. Użytkownik może edytować parametry swojego profilu, po edycji klika przycisk „Apply”.
  5. System aktualizuje zmiany wprowadzone przez użytkownika.„.

Zdefiniowanie nowej wycieczki

  1. Użytkownik jest zalogowany, przechodzi do zakładki „New trip”.
  2. Użytkownik wprowadza dane związane z wycieczką (nazwa, punkty: startowy, końcowy, pośrednie, swoje preferencje).
  3. System sprawdza poprawność podanych danych.
  4. Jeśli wprowadzone dane są poprawne, wycieczka zostaje dodana do systemu (wprowadzona do bazy danych),
  5. Użytkownika zostaje poinformowany odpowiednim komunikatem o powodzeniu operacji.

Przeglądanie własnych wycieczek

  1. Użytkownik jest zalogowany, klika na zakładkę „My trips”.
  2. System wyświetla listę wycieczek zdefiniowanych przez zalogowanego użytkownika, lista może być pusta, jeśli takich wycieczek nie ma.
  3. Użytkownik klika na jednej z wycieczek.
  4. Zostają wyświetlone szczegółowe informacje dotyczące wybranej wycieczki.

Przeglądanie innych wycieczek w systemie

  1. Użytkownik jest zalogowany, klika na zakładkę „Other trips”.
  2. System wyświetla listę wycieczek zdefiniowanych przez wszystkich użytkowników portalu oprócz zalogowanego użytkownika, lista może być pusta, jeśli takich wycieczek nie ma.
  3. Użytkownik klika na jednej z wycieczek.
  4. Zostają wyświetlone szczegółowe informacje dotyczące wybranej wycieczki.

Przystąpienie do wycieczki

  1. Użytkownik jest zalogowany, klika na zakładkę „Other trips” lub „My trips”.
  2. System wyświetla listę wycieczek zdefiniowanych w portalu, lista może być pusta, jeśli takich wycieczek nie ma.
  3. Jeśli lista nie jest pusta to użytkownik klika na jednej z wycieczek.
  4. Zostają wyświetlone szczegółowe informacje dotyczące wybranej wycieczki.
  5. Użytkownik klika przycisk „Participate”.
  6. System dopisuje zalogowanego użytkownika do uczestników wybranej wycieczki.

Edycja parametrów wycieczki

  1. Użytkownik jest zalogowany, klika na zakładkę „My trips”.
  2. System wyświetla listę wycieczek zdefiniowanych przez zalogowanego użytkownika, lista może być pusta, jeśli takich wycieczek nie ma.
  3. Jeśli lista nie jest pusta to użytkownik klika na jednej z wycieczek.
  4. Zostają wyświetlone szczegółowe informacje dotyczące wybranej wycieczki.
  5. Użytkownik klika przycisk „Edit”.
  6. Użytkownik może edytować parametry wycieczki, po edycji klika przycisk „Apply”.
  7. System aktualizuje zmiany wprowadzone przez użytkownika.

Wyszukanie wycieczek wg nazw

  1. Użytkownik jest zalogowany, klika na zakładkę „Search trip”.
  2. System wyświetla formularz z możliwością wyboru strategii wyszukiwania wycieczek.
  3. Użytkwonik wybiera wybieranie wg nazw, wpisuje nazwę i klika przycisk „Search”.
  4. System wyszukuje wycieczek pasujące do zapytania, a następnie wyświetla okienko z rezultatem wyszukiwań.

Wyszukanie wycieczek wg lokalizacji

  1. Użytkownik jest zalogowany, klika na zakładkę „Search trip”.
  2. System wyświetla formularz z możliwością wyboru strategii wyszukiwania wycieczek.
  3. Użytkownik wybiera wybieranie wg lokalizacji, wpisuje nazwę i klika przycisk „Search”.
  4. System wyszukuje wycieczek pasujące do zapytania, a następnie wyświetla okienko z rezultatem wyszukiwań.

Polubienie wycieczki na portalu PB poprzez przycisk „Like it”

  1. Użytkownik jest zalogowany, klika na zakładkę „Other trips” lub „My trips”.
  2. System wyświetla listę wycieczek zdefiniowanych w portalu, lista może być pusta, jeśli takich wycieczek nie ma.
  3. Jeśli lista nie jest pusta to użytkownik klika na jednej z wycieczek.
  4. Zostają wyświetlone szczegółowe informacje dotyczące wybranej wycieczki.
  5. Użytkownik klika przycisk „Like it” („Lubię to”).
  6. Zostaje wywołany odpowiednie zdarzenie łączące się z portalem Facebook.
Identyfikacja funkcji
  1. Przechowywanie informacji o użytkownikach.
  2. Składowanie informacji o hasłach.
  3. Magazynowanie i udostępnianie informacji wycieczkach.
  4. Przechowywanie i dzielenie informacji związanych z trasami wycieczek.
Analiza hierarchii funkcji projektowanej aplikacji

Budowa i analiza diagramu przepływu danych

Top proces

1. Rejestracja

2. Logowanie

3. Edycja profilu

4. Obsługa wycieczek

  • 4.3 Przeglądanie listy wycieczek

5. Wyszukiwanie

Wybór encji (obiektów) i ich atrybutów

Encje i ich atrybuty:

  • Użytkownik
    • login
    • hasło
    • e-mail
    • płeć
    • lokalizacja
    • rower
    • data urodzenia
  • Wycieczka
    • tytuł
    • opis
    • użytkownik
    • trasa
  • Trasa
    • początek
    • koniec
    • punkty pośrednie
Projektowanie powiązań (relacji) pomiędzy encjami

Projekt diagramów STD (State Transition Diagram – diagramy przejść pomiędzy stanami)

Projekt logiczny

1. Projekt modelu danych w oparciu o diagram ERD

Kod SQL do stworzenia tabel:

CREATE TABLE trip
(
  tripid bigint NOT NULL,
  coordinates bytea,
  description character varying(255),
  distance double precision NOT NULL,
  title character varying(255),
  createuser_userid bigint,
  path bytea,
  CONSTRAINT trip_pkey PRIMARY KEY (tripid ),
  CONSTRAINT fk27e8454601a496 FOREIGN KEY (createuser_userid)
      REFERENCES usertable (userid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
CREATE TABLE usertable
(
  userid bigint NOT NULL,
  bike character varying(255),
  dateofbirth timestamp without time zone,
  email character varying(255),
  location character varying(255),
  login character varying(255),
  password character varying(255),
  sex character varying(255),
  CONSTRAINT usertable_pkey PRIMARY KEY (userid )
)
WITH (
  OIDS=FALSE
);
CREATE TABLE trip_user
(
  userid bigint NOT NULL,
  tripid bigint NOT NULL,
  CONSTRAINT trip_user_pkey PRIMARY KEY (tripid , userid ),
  CONSTRAINT fke846ffa54e519652 FOREIGN KEY (tripid)
      REFERENCES trip (tripid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fke846ffa55013341e FOREIGN KEY (userid)
      REFERENCES usertable (userid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
2. Słownik danych
  • trip - tabela przechowująca dane o zdefiniowanych wycieczkach
    • tripid - klucz główny tabeli - bigint NOT NULL,
    • coordinates - tabela współrzędnych geograficznych wycieczki - bytea,
    • description - opis wycieczki - character varying(255),
    • distance - dystans wycieczki - double precision NOT NULL,
    • title - nazwa wycieczki - character varying(255),
    • createuser_userid - klucz obcy wskazujący na użytkownika, który stworzył wycieczkę - bigint.
  • usertable - tabela przechowująca dane użytkowników systemu
    • userid - klucz główny tabeli - bigint NOT NULL,
    • bike - model roweru użytkownika - character varying(255),
    • dateofbirth - data urodzenia - timestamp without time zone,
    • email - adres e-mail użytkownika - character varying(255),
    • location - miejsce zamieszkania - character varying(255),
    • login - login użytkownika - character varying(255),
    • password - hasło - character varying(255),
    • sex - płeć użytkownika - character varying(255).
  • trip_user - tabela kojarząca wycieczki z uczestniczącymi w nich użytkownikami
    • userid - identyfikator użytkownika - bigint NOT NULL,
    • tripid - identyfikator wycieczki - bigint NOT NULL.
3. Analiza zależności funkcyjnych i normalizacja tabel

1NF

  • spełniona - każda składowa w każdej krotce jest atomowa (nie daje podzielić się na mniejsze wartości).

2NF

  • spełniona - bo jest 1NF oraz żaden atrybut wtórny relacji nie jest w pełni funkcyjnie zależny od wszystkich kluczy tej relacji.

3NF

  • spełniona - bo jest 2 NF oraz każdy atrybut wtórny jest tylko bezpośrednio zależny od klucza głównego.
4. Projekt operacji na danych

Aplikacja korzysta z frameworka JPA do mapowania danych między modelem relacyjnym i obiektowym. Zdefiniowano następujące encje JPA:

Encja User:

package entities;
 
import java.util.Date;
import java.util.Set;
 
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.Table;
 
@Entity
@Table(name="UserTable", schema="public")
public class User {
 
	@Id @GeneratedValue(strategy = GenerationType.TABLE)
	private long userId;
	private String login = null;
	private String password = null;
	private String email = null;
	private String sex = null;
	private String location = null;
	private String bike = null;
	private Date dateOfBirth = null;
	@ManyToMany(fetch = FetchType.EAGER)
	@JoinTable(name = "trip_user", joinColumns = { @JoinColumn(name = "userId") }, inverseJoinColumns = { @JoinColumn(name = "tripId") })
	private Set<Trip> participantInTrips = null;
 
 
	public long getUserId() {
		return userId;
	}
 
	public void setUserId(long userId) {
		this.userId = userId;
	}
 
	public String getLogin() {
		return login;
	}
 
	public void setLogin(String login) {
		this.login = login;
	}
 
	public String getPassword() {
		return password;
	}
 
	public void setPassword(String password) {
		this.password = password;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
	public String getSex() {
		return sex;
	}
 
	public void setSex(String sex) {
		this.sex = sex;
	}
 
	public String getLocation() {
		return location;
	}
 
	public void setLocation(String location) {
		this.location = location;
	}
 
	public String getBike() {
		return bike;
	}
 
	public void setBike(String bike) {
		this.bike = bike;
	}
 
	public Date getDateOfBirth() {
		return dateOfBirth;
	}
 
	public void setDateOfBirth(Date dateOfBirth) {
		this.dateOfBirth = dateOfBirth;
	}
 
	public String toString() {
		return this.login;
	}
 
	public Set<Trip> getParticipantInTrips() {
		return participantInTrips;
	}
 
	public void setParticipantInTrips(Set<Trip> participantInTrips) {
		this.participantInTrips = participantInTrips;
	}
 
}

Encja Trip:

package entities;
 
import java.util.Set;
 
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.ManyToOne;
 
import org.hibernate.annotations.Type;
import org.postgis.LineString;
import org.postgis.Point;
 
@Entity
public class Trip {
 
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)
    private long tripId;
 
    private String title = null;
 
    private String description = null;
 
    @ManyToOne
    private User createUser = null;
 
    @ManyToMany(fetch = FetchType.EAGER)
    @JoinTable(name = "trip_user", joinColumns = { @JoinColumn(name = "tripId") }, inverseJoinColumns = { @JoinColumn(name = "userId") })
    private Set<User> participants = null;
 
    private LineString path;
 
    @Type(type = "org.hibernate.GeometryType")
    @Column(name = "path", columnDefinition = "LineString")
    public LineString getLocation() {
        return path;
    }
 
    private double[] coordinates = null;
 
    private double distance = 0;
 
    public long getTripId() {
        return tripId;
    }
 
    public void setTripId(long tripId) {
        this.tripId = tripId;
    }
 
    public String getTitle() {
        return title;
    }
 
    public void setTitle(String title) {
        this.title = title;
    }
 
    public String getDescription() {
        return description;
    }
 
    public void setDescription(String description) {
        this.description = description;
    }
 
    public User getCreateUser() {
        return createUser;
    }
 
    public void setCreateUser(User createUser) {
        this.createUser = createUser;
    }
 
    public Set<User> getParticipants() {
        return participants;
    }
 
    public void setParticipants(Set<User> participants) {
        this.participants = participants;
    }
 
    public double[] getCoordinates() {
        return coordinates;
    }
 
    public void setCoordinates(double[] coordinates) {
        this.coordinates = coordinates;
 
        if (coordinates != null) {
            Point[] points = new Point[coordinates.length / 2];
            for (int i = 0; i < coordinates.length / 2 - 1; i++) {
                points[i] = new Point(coordinates[2 * i], coordinates[2 * i + 1]);
            }
            path = new LineString(points);
        }
    }
 
    public double getDistance() {
        return distance;
    }
 
    public void setDistance(double distance) {
        this.distance = distance;
    }
 
}

Zapytania SQL

Sprawdzenie, czy istnieje użytkownik z podanym loginem:

SELECT COUNT(*) FROM User u WHERE u.login = ?1;

Sprawdzenie, czy istnieje użytkownik z podanym adresem e-mail:

SELECT COUNT(*) FROM User u WHERE u.email = ?1;

Logowanie użytkownika - pobranie danych z bazy:

SELECT u FROM User u WHERE u.login = :login AND u.password = :password;

Pobranie wycieczek założonych przez użytkownika:

SELECT t FROM Trip t WHERE t.createUser = ?1;

Pobranie wszystkich wycieczek:

SELECT t FROM Trip t;

Pobranie wycieczek założonych przez innych użytkowników:

SELECT t FROM Trip t WHERE t.createUser != ?1;

Pobranie danych wybranej wycieczki:

SELECT t FROM Trip t WHERE t.tripId = ?1;

Wyszukanie wycieczek założonych przez innych użytkowników według nazwy:

SELECT t FROM Trip t WHERE t.title like ?1 and t.createUser != ?2;

Raport końcowy

1. Implementacja bazy danych (utworzenie bazy, implementacja obiektów) (realizacja struktury pustej bazy; w oparciu o diagramy ERD i SQL)

Sekwencje bazy danych

CREATE TABLE public.hibernate_sequences
(
  sequence_name character varying(255) NOT NULL,
  next_val bigint,
  CONSTRAINT hibernate_sequences_pkey PRIMARY KEY (sequence_name )
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.hibernate_sequences
  OWNER TO postgres;

Dane PostGIS

CREATE TABLE public.spatial_ref_sys
(
  srid integer NOT NULL,
  auth_name character varying(256),
  auth_srid integer,
  srtext character varying(2048),
  proj4text character varying(2048),
  CONSTRAINT spatial_ref_sys_pkey PRIMARY KEY (srid ),
  CONSTRAINT spatial_ref_sys_srid_check CHECK (srid > 0 AND srid <= 998999)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.spatial_ref_sys
  OWNER TO postgres;

Użytkownik

CREATE TABLE public.usertable
(
  userid bigint NOT NULL,
  bike character varying(255),
  dateofbirth timestamp without time zone,
  email character varying(255),
  location character varying(255),
  login character varying(255),
  password character varying(255),
  sex character varying(255),
  CONSTRAINT usertable_pkey PRIMARY KEY (userid )
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.usertable
  OWNER TO postgres;

Wycieczka

CREATE TABLE trip
(
  tripid bigint NOT NULL,
  coordinates bytea,
  description character varying(255),
  distance double precision NOT NULL,
  title character varying(255),
  createuser_userid bigint,
  path bytea,
  CONSTRAINT trip_pkey PRIMARY KEY (tripid ),
  CONSTRAINT fk27e8454601a496 FOREIGN KEY (createuser_userid)
      REFERENCES usertable (userid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);

Relacja: Użytkownik-Wycieczka

CREATE TABLE public.trip_user
(
  userid bigint NOT NULL,
  tripid bigint NOT NULL,
  CONSTRAINT trip_user_pkey PRIMARY KEY (tripid , userid ),
  CONSTRAINT fke846ffa54e519652 FOREIGN KEY (tripid)
      REFERENCES public.trip (tripid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fke846ffa55013341e FOREIGN KEY (userid)
      REFERENCES public.usertable (userid) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.trip_user
  OWNER TO postgres;
2. Zdefiniowanie interfejsów do prezentacji, edycji i obsługi danych (formularze; należy zaprojektować strukturę każdego formularza oraz powiązania między nimi; w oparciu o diagramy FHF, DFD i STD).
  • Logowanie

<logowanie.png>

  • Rejestracja

  • Tworzenie nowej wycieczki

  • Przegląd wycieczek

  • Wyszukiwanie wycieczek

  • Wyniki wyszukiwania

  • Edycja profilu

  • Wycieczki innych użytkowników

  • Wylogowywanie się

3. Zdefiniowanie dokumentów do przetwarzania i prezentacji danych (raporty; informacje generowane w raportach i ich struktura powinna odpowiadać dokumentów wymaganym w danej firmie.).

W tworzonym projekcie nie istniała potrzeba tworzenia dokumentów, ani raportów.

4. Zdefiniowanie panelu sterowania aplikacji (należy pamiętać o dostosowaniu do potrzeb użytkownika; realizacja w oparciu o diagram STD).

W tworzonym projekcie nie istniała potrzeba tworzenia panelu sterowania.

5. Zdefiniowanie makropoleceń dla realizacji typowych operacji; (określonych dla panelu sterowania i ew. innych formularzy; realizacja w oparciu o diagram DFD i FHD).

W tworzonym projekcie został wykorzystany mechanizm mapowania obiektowo-relacyjnego JPA2, w związku z czym niepotrzebne było definiowanie funkcji związanych z obsługą bazy danych. Cała reużywalna logika aplikacji została zaimplementowana w dwóch ziarenkach EJB ( TripEJB oraz UserEJB ).

6. Uruchamianie i testowanie aplikacji (on-site, przy współpracy użytkownika).

Aplikacja była testowana w środowisku lokalnym oraz za pomocą sieci WWW. Testy aplikacji odbywały się z wykorzystaniem serwera aplikacji JBoss Application Server w najnowszej dostępnej podczas realizacji wersji 7.1.1 oraz bazy danych PostgreSQL w wersji 9.1.

7. Wprowadzanie danych (ręczne, automatyczne, import, on-line).

W tworzonym projekcie nie istniała potrzeba migracji dotychczasowych danych. Wszystkie dane jakie zbiera aplikacja są wprowadzane przy pomocy interfejsu WWW przez użytkowników.

8. Wdrażanie systemu do użytkowania (stopniowe, modułami, z możliwością wycofania się, z dublowaniem danych i obliczeń).

Wdrażanie aplikcji polega na instalacji serwera baz danych oraz serwera aplikacyjnego. Następnym etapem jest konfiguracja bazy danych oraz DataSource Pool w serwerze aplikacji zgodnie z wymaganiami aplikacji. Po skonfigurowaniu odpowiedniej puli połączeń do bazy danych należy skopiować plik war do katalogu deployment serwera aplikacji oraz uruchomić interfejs www przy pomocy przeglądarki internetowej. Podczas pierwszego uruchomienia aplikacji zostanie automatycznie stworzony cały niezbędny schemat bazy danych.

9. Przeprowadzenie szkolenia użytkowników.

W przypadku naszej aplikacji szkolenie użytkowników nie jest potrzebne. Aplikacja jest bardzo intuicyjna i każda osoba korzystająca na co dzień z dobrodziejstw internetu nie powinna mieć najmniejszych problemów z rozpoczęciem korzystania z aplikacji. W newralgicznych punktach systemu został stworzony system powiadomień poprzez „dymki” informujący użytkownika o zachowaniach systemu.

10. Zapewnienie dokumentacji technicznej i użytkowej (ten wymóg powinien postawić użytkownik!).

Niniejsza dokumentacja spełnia wszystkie wymagania klienta pod względem wdrożenia oraz późniejszej obsługi aplikacji.

11. Zapewnienie obsługiwania systemu po wdrożeniu (jest to jeden z najbardziej kosztownych procesów w realizacji projektów informatycznych).

Jedyną czynnością związaną z administracją aplikacji jest okresowe tworzenie backupów bazy danych, z czym każdy administrator systemów nie powinien mieć najmniejszych problemów.

12. Rozwijanie i modyfikowanie aplikacji (możliwości rozwijania i adaptacji należy uwzględnić we wczesnych fazach projektowania).

Projekt aplikacji pozwala na w miarę bezproblemowe dodawanie funkcjonalności do naszej aplikacji. Podczas realizacji projektu pojawiło się kilka ciekawych pomysłów, jakie w kolejnych fazach projektu można by było zaimplementować oraz wdrożyć do naszego projektu.

Jako potencjalne pomysły na rozwój naszej aplikacji wyszczególniono:

  • stworzenie / zintegrowanie z zewnętrznym API do automatycznego wyznaczania tras między zaznaczonymi na mapie punktami,
  • rozszerzenie aplikacji o możliwość transmisji live wycieczki z platform mobilnych, a'la portal sportowy Endomondo,
  • stworzenie funkcjonalności historycznych wycieczek,
  • możliwość importu / eksportu do formatów *.gpx / *.tcx,
13. Opracowanie doświadczeń wynikających z realizacji projektu (czas, koszty; dane te posłużą do oszacowania kosztów i nakładów przy realizacji przyszłych projektów).

Realizowany projekt dostarczył autorom wiele doświadczeń na temat zastosowanych technologi. Żaden z członków zespołu nie posiadał do tej pory doświadczenia z projektowaniem aplikacji internetowych od strony front-endowej, w związku z czym zdecydowaliśmy się na użycie front-endowego frameworka bazującego na GWT, co w połączeniu ze znajomością technologi Swing przez każdego z członków zespołu umożliwiło szybkie „wejście” w świat nowej technologi.

Implementacja strony front-endowej projektu w wysoko poziomowym frameworku bazujących na automatycznej generacji kodu xHtml oraz JavaScript na podstawie kodu Javowego spowodowało również wiele nieprzewidzianych zachowań oraz ciężkich do rozwiązania błędów.

Strona back-endowa aplikacji została zaimplementowana zgodnie ze standardem J2EE w technologi EJB. Jako mechanizm mapowania obiektowo-relacyjnego wykorzystano technologie JPA. Realizacja strony back-endowej pozwoliła członkom zespołu lepiej zapoznać się z tymi dwoma technologiami oraz lepiej poznać nowy mechanizm adnotacji dostępny dopiero od wersji J2EE 6.0. Wszyscy członkowie zespołu mieli doświadczenie w technologi Hibernate, więc realizacja projektu pozwoliła dostrzec różnice między „czystym” JPA oraz frameworkiem Hibernate w wersji 3.x.

Kolejnym ciekawym doświadczeniem był styczność z nowym serwerem aplikacji od strony konfiguracji ( serwer JBoss począwszy od wersji 7.0 udostępnia nowy mechanizm dodawania bibliotek poprzez moduły, rozwiązanie zbliżone do systemu budującego aplikację Javowe Maven ). Dodanie jednej z bibliotek nastręczyło ogromnej ilości problemów jednemu z członków zespołu i zmusiło do dwudniowego przeszukiwania dokumentacji oraz archiwum forum StackOverFlow.

Podczas prac nad projektem nie prowadzono monitorowania czasu pracy poszczególnych członków zespołów, lecz w poniższej tabelce przedstawiono szacunkowe wartości czasu ( w man-daysach ) jakie pochłonęły poszczególne zadania.

ZadanieKoszt
Research pod względem technologicznym2 md
Wdrożenie w framework Vaadin3 md
Wdrożenie w EJB1.5 md
Wdrożenie w JPA1.5 md
Wdrożenie w PostGis1 md
Konfiguracja serwera JBoss2 md
Projektowanie aplickacji3 md
Implementacja back-end2 md
Implementacja front-end8 md
Projekt bazy danych3 md
Stworzenie dokumentacji3 md
Zadania organizacyjne / spotkania3 md
33 md

Realizacja projektu z wykorzystaniem nowych technologi dla każdego z członków zespołu była bardzo rozwijająca pod względem dobrego projektowania oraz programowania obiektowego.

14. Wykaz literatury, załączniki (przykłady def. formatu, reguł, poprawności, masek, kwerend SQL, wydruki, itp.)
  • Richard M. Reese „EJB 3.1 Cookbook”
  • Mike Keith, Merrick Schincariol „Pro JPA2: Mastering the Java Persistence API
  • Marko Grönroos „Book of Vaadin”
  • Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford „Patterns of Enterprise Application Architecture”
  • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides „Wzorce projektowe”
 
pl/dydaktyka/ztb/2012/projekty/biker.txt · ostatnio zmienione: 2019/06/27 15:50 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0