Modular software

IT1901 Fall 2021 - 12th Lecture

Overview

  • Group deliverable 2 (GD2)

  • Architectural styles

  • Modular projects with Maven and Java

GD2 - modularisering

  • kodingsprosjektet skal deles opp i egnede moduler med avhengigheter

  • bygging styres (fortsatt) av maven og hver modul har hensiktmessig konfigurasjon

  • maven-moduler er et krav, mens Java-moduler er ikke (men i utgangspunktet anbefalt)

  • mer om modularisering senere

GD2 - arkitektur

  • kjernelogikken (domenelaget) og ui (brukergrensesnittlaget) skal skilles fra hverandre

  • persistens med JSON vha. egnet bibliotek, f.eks. Jackson

    • definere/dokumentere (?) filformat for brukerdata og evt. innstillinger

  • reflektere over og velge mellom dokumentmetafor (desktop) og implisitt lagring (app)

  • alle tre lagene spiller sammen

GD2 - kodekvalitet

  • tester skal skrives for alle modulene

  • testdekningsgrad og (annen) kodekvalitet skal sjekkes av egne maven-tillegg (f.eks. jacoco, checkstyle og spotbugs)

  • rimelig god testdekning av alle lagene

GD2 - dokumentasjon

  • generell dokumentasjon må holdes oppdatert

  • arkitektur med minst et diagram (bruk PlantUML) i tillegg til teksten i readme

  • valg knyttet til arbeidsvaner, arbeidsflyt, testing, bruk av verktøy for sjekking av kodekvalitet (f.eks. innstillinger)

GD2 - arbeidsvaner

  • kodingsoppgaver skal være utgangspunktet for alt arbeid

  • greiner (branch) samler arbeid for hver kodingsoppgave (?)

    • se alternativet trunk based development

  • bruk milepæl (milestones) knyttet til innleveringen

  • dere jobber i par og bytter på å kode

  • "produktiv" kode og tester må holde tritt

GD2 - lær (i smidig ånd)

  • hva virker bra og ikke så bra

  • hva er en god oppdeling i og fordeling av arbeidsoppgaver

  • ikke lur dere selv eller andre

GD2 - leveranse

  • prosjektet må være gitpod-klart med Gitpod-knapp i gitlab eller merkelapp i README-fila

  • maven skal brukes til kjøring, testing og sjekk av kodekvalitet

  • kode må ligge i master-greina av standard kodelager for gruppa

  • på Blackboard leveres en enkel tekst om at kodelageret er klart for vurdering

  • det er også nå "flytende/anbefalt" frist, så hold kontakt med lærerassistenten om fremdrift

Architectural styles

An architectural style is a conceptual specification of how a certain system will be structured and function.

Architectural styles

  • monolithic applications

  • 3-tier applications

  • REST

layers vs. tiers

  • sometimes the terms are used interchangeably

  • there is a difference

    • layers - logical separation

    • tiers - physical separation

monolithic applications

monolithic applications (1)

  • All the functionality is packed in a single software unit

    • ui

    • logic

    • data

  • designed without modularity

  • also called single-tiered application

3-tier applications

3-tier applications (2)

  • application where the various functions are separated

    • presentation tier (UI / frontend)

    • logic tier (business tier)

    • data tier (data storage + data access)

  • also called 3-layer

  • application is modular

3-tier applications (3)

  • ability to update / replace just parts of the application

  • ability to independently scale the layers

  • ability to re-use layers

REST

REST

  • Representational state transfer (REST)

  • architectural style involving use of Web Services

  • set of constraints are applied

    • client server

    • statelessness (no client context is stored on the server side)

    • cacheability (responses state if they can be cached or not)

    • uniform interface

    • layered system (adding layers like proxy or load balancer)

REST (cont.)

  • Web services that implement REST are called RESTful APIs

  • a base URI, example: https://gitlab.stud.idi.ntnu.no/api/v4

  • standard HTTP methods (e.g., GET, POST, PUT, PATCH and DELETE);

  • data formats for requests and responses (json, xml, etc)

Modularity

Modularity

  • means for splitting a large problems into parts

    • distribute and isolate work

    • distribute artifacts for use and reuse

  • more or less supported by tools and languages

    • maven - modular build

    • java - strong encapsulatation

Modularity with maven

Modular projects with Maven

  • main "parent" module with common configuration

  • sub-modules with dependencies

    • libraries (and plugins) are modules

    • own modules follow architecture

  • manages build tasks

    • sequenced according to dependencies

    • execute in appropriate context e.g. classpath

Modular projects with Maven

  • use of inheritance

  • parent pom has configuration that is inherited by modules' pom

  • the descendent pom can override inherited configuration elements

  • descendant pom inherits most elements with the exception of things like artifactid, name which are used to identify the parent pom

Modular projects with Maven (2)

  • reduce complexity and size of individual build files

  • reliably use consistent versions for dependencies and plugins

Parent pom example

<?xml version="1.0" encoding="UTF-8" ?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>it1901.todolist</groupId>
    <artifactId>parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
               ...
            </dependency>
            ...
        </dependencies>
    </dependencyManagement>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
      				...
                </plugin>
                ...
            </plugins>
        </pluginManagement>
    </build>

    <modules>
        <module>core</module>
        <module>fxui</module>
    </modules>
</project>

Descendant pom example

<?xml version="1.0" encoding="UTF-8" ?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>it1901.todolist</groupId>
        <artifactId>parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </parent>

    <artifactId>fxui</artifactId>

    <dependencies>
		<dependency>
			...
		</dependency>
		...
    </dependencies>

    <build>
        <plugins>
            <plugin>
                ...
            </plugin>
            ...
        </plugins>
    </build>
</project>

Modularity with Java

Java modules

  • corresponds to a set of packages

  • strong encapsulation

    • explicitly export packages

    • explicitly state dependencies

    • also enforced during runtime

  • advantages

    • avoid relying on internals

    • build lighter apps

  • disadvantages…​

core - module-info.java

module todolist.core {
    requires transitive com.fasterxml.jackson.databind;

    exports todolist.core;
    exports todolist.json;
}

core - module-info.java

  • module name

    • how to get (guess) name of libraries

  • requires - what this module needs

    • transitive - others will need this too

    • exports - what others may use

fxui - module-info.java

module todolist.ui {
    requires com.fasterxml.jackson.databind;

    requires java.net.http;

    requires javafx.base;
    requires javafx.controls;
    requires javafx.fxml;

    requires todolist.core;
    requires fxutil;

    opens todolist.ui to javafx.graphics, javafx.fxml;
}

fxui - module-info.java

  • opens …​ to - allow getting runtime info about classes using so-called reflection

    • fxml

    • REST frameworks

    • test frameworks

  • --add-opens command line option

    • support unmodularized mode

Norwegian University of Science and Technology