Presentación de PowerPoint · 2021. 5. 28. · def reportWorkingHours(): String = { ... }} Financial department. Operations. Management . Responsible departments. There can be multiple

Software ArchitectureS

choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Modularity

Jose E. Labra GayoCourse 2020/2021


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Modularity

Decomposing the project in modules at development timeModules can be developed independently


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Big Ball of MudModularity definitionsModularity recommendations

SOLID, Cohesion, Coupling, Connascence, Robustness, Demeter, Fluid interfacesModularity styles

LayersAspect Oriented decompositionDomain based decomposition


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Big Ball of Mud

Big Ball of MudDescribed by Foote & Yoder, 1997

ElementsLots of entities intertwined

ConstraintsNone


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Big Ball of Mud

Quality attributes (?)Time-to-market

Quick startIt is possible to start without defining an architectureIncremental piecemeal methodology

Solve problems on demandCost

Cheap solution for short-term projects


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Big Ball of Mud

ProblemsHigh Maintenance costsLow flexibility at some given point

At the beginning, it can be very flexibleAfter some time, a change can be dramatic

InertiaWhen the system becomes a Big Ball of Mud it is very

difficult to convert it to another thingA few prestigious developers know where to touchClean developers run away from these systems


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Big Ball of Mud

Some reasonsThrowaway code:

You need an immediate fix for a small problem, a quick prototype or proof of concept

When it is good enough, you ship itPiecemeal growthCut/Paste reuse

Bad code reproduced in lots of placesAnti-patterns and technical debt

Bad smellsNot following clean code/architecture


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Definitions of modules

Module: Piece of software the offers a set of responsibilitiesIt makes sense at building time (not at runtime)Separates interface from body

Interface Describes what is a moduleHow to use it ≈ Contract

BodyHow it is implemented

Interface

Body(Implementation)

Module


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Modular decomposition

Relationship: is-part-ofConstraints

No cycles are allowedUsually, a module can only have one parent

Several representations

System

SubsystemA

SubsystemB

SubsystemB1

SubsystemB2

SubsystemA2

SubsystemA1


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Modularity Quality attributes

CommunicationCommunicate the general aspect of the system

MaintainabilityFacilitates changes and extensionsLocalized functionality

SimplicityA module only exposes an interface - less complexity

ReusabilityModules can be used in other contextsProduct lines

IndependenceModules can be developed by different teams


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Modularity challenges

Bad decomposition can augment complexityDependency management

Third parties modules can affect evolutionTeam organization

Modules decomposition affects team organizationDecision: Develop vs buy

COTS/FOSS modules


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Modularity recommendations

SOLID design principlesCohesionCouplingConnascenceRobustness: Postel’s lawDemeter's LawFluid interfaces


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo SOLID design principles

SOLID principles can be applied to clases and modulesSRP (Single Responsability Principle)OCP (Open-Closed Principle)LSP (Liskov Substitution Principle)ISP (Interface Seggregation Principle)DIP (Dependency Injection Principle)

Robert C. Martin

Source: Wikipedia


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (S)ingle Responsibility

A module must have one responsibilityResponsibility = A reason to changeNo more than one reason to change a module

Otherwise, responsibilities are mixed and coupling increases

vs

http://www.google.no/url?sa=i&rct=j&q=simple+black+compass&source=images&cd=&cad=rja&docid=J_ngjZgd28KFqM&tbnid=xHmynmLhSolfjM:&ved=0CAUQjRw&url=http://www.stanleylondon.com/WeemsCPlathCompasses.htm&ei=Xy51Uef2NqrV4gTS0YC4AQ&bvm=bv.45512109,d.bGE&psig=AFQjCNHmJBkO5wXKqmIC5BZJ-yYIihHgrA&ust=1366720477076178

http://www.google.no/url?sa=i&rct=j&q=simple+black+compass&source=images&cd=&cad=rja&docid=J_ngjZgd28KFqM&tbnid=xHmynmLhSolfjM:&ved=0CAUQjRw&url=http://www.stanleylondon.com/WeemsCPlathCompasses.htm&ei=Xy51Uef2NqrV4gTS0YC4AQ&bvm=bv.45512109,d.bGE&psig=AFQjCNHmJBkO5wXKqmIC5BZJ-yYIihHgrA&ust=1366720477076178


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (S)ingle Resposibility

http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

class Employee {def calculatePay(): Money = { ... }

def saveDB() { ... }

def reportWorkingHours(): String = { ... }

}

Financial department

Operations

Management

Responsible departments

There can be multiple reasons to change the Employee class

Solution: Separate concerns

Gather together the things that change for the same reasons. Separate those things that change for different reasons.


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (O)pen/Closed principle

Open for extensionThe module must adapt to new changesChange/adapt the behavior of a module

Closed for modificationChanges can be done without changing the module

Without modifying source code, binaries, etc

It should be easy to change the behaviour of a module without changing the source code of that module

http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (O)pen/Closed principle

Example: List<Product> filterByColor(List<Product> products, String color) {

...}

If you need to filter by height, you need to change the source code

A better way:List<Product> filter(List<Product> products,

Predicate<Product> criteria) {. . .}

Now, it is possible to filter by any predicate without changing the module

redProducts = selector.filter(p -> p.color.equals("red"));biggerProducts = selector.filter(p -> p.height > 30);


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (L)iskov Substitution

Subtypes must follow supertypes contractB is a subtype of A when:∀x∈A, if there is a property Q such that Q(x)

then ∀y∈B, Q(y)

"Derived types must be completely substitutable by their base types"Common mistakes:Inherit and modify behaviour of base classAdd functionality to supertypes that subtypes don't follow


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (L)iskov Substitution

Duck

doCuakhasShapeDuckrespira)

RubberDuckyDuckInPark

doCuakhasShapeDuckbreathes)

X

Example


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (I)nterface Segregation

Clients must not depend on unused methodsBetter to have small and cohesive interfacesOtherwise ⇒ non desired dependenciesIf a module depends on non-used functionalities and these

functionalities change, the module can be effected

ClientA

ClientB

InterfaceA

methodA1methodA2

InterfaceB

methodB1methodB2

Service

mehtodA1methodA2methodB1methodB2

...

<<uses>>

<<uses>>


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (D)ependency Inversion

Invert conventional dependencies High-level modules should not depend on low-level modules

Both should depend on abstractionsAbstractions should not depend upon details.

Details should depend upon abstractionsCan be accomplished using dependency injection or

several patterns like plugin, service locator, etc.

http://www.objectmentor.com/resources/articles/dip.pdfhttp://martinfowler.com/articles/dipInTheWild.html


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo (D)ependency Inversion

Lowers couplingFacilitates unit testing

Substituting low level modules by test doublesRelated with:

Dependency injection and Inversion of ControlFrameworks: Spring, Guice, etc.


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Cohesion

Cohesion = Degree to which the elements of a module work together

It is recommended to have high cohesionEach module must solve one functionalityGranularity

Modules must be released and reused independentlyIt should be possible to test each module separately


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Cohesion metric LCOM

LCOM (Lack of cohesion of methods), Chidamber and Kemerer

Measure degree of similarity of methods in a classSeveral variants have been proposed LCOM 1-5

LCOM = � 𝑃𝑃 − 𝑄𝑄 𝑠𝑠𝑠𝑠 𝑃𝑃 − 𝑄𝑄 > 00 𝑒𝑒𝑒𝑒 𝑐𝑐𝑐𝑐𝑠𝑠𝑐𝑐 𝑐𝑐𝑐𝑐𝑒𝑒𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑠𝑠𝑐𝑐

𝑃𝑃 = Number of methods without common attributes𝑄𝑄 = Number of methods with common attributes

𝑚𝑚1()

𝑚𝑚2()

𝑚𝑚3()

a

b

c

𝑃𝑃 = 0, 𝑄𝑄 = 3LCOM=0

𝑚𝑚1()

𝑚𝑚2()

𝑚𝑚3()

a

b

c


𝑚𝑚1()

𝑚𝑚2()

𝑚𝑚3()

a

b

c


attribute

method


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Cohesion principles

REP - Reuse/Release Equivalence PrincipleCCP - Common Closure PrincipleCRP - Common Reuse Principle

Robert C. Martin

Source: Wikipedia


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo REP

Reuse/Release Equivalence PrincipleThe granule of reuse is the granule of release

In order to reuse an element in practice, it is necessary to publish it in a release system of some kindRelease version management: numbers/names

All related entities must be released togetherGroup entities for reuse


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo CCP

Common Closure PrincipleGather in a module entities that change for the

same reasons and at the same time Entities that change together belong together

Goal: limit the dispersion of changes among release modulesChanges must affect the smallest number of released

modulesEntities within a module must be cohesive

Group entities for maintenance

Note: imilar to SRP (Single Responsibility Principle), but for modules


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo CRP

Common Reuse PrincipleModules should only depend on entities they need

They shouldn't depend on things they don't needOtherwise, a consumer may be affected by changes

on entities that is not usingSplit entities in modules to avoid unneeded releases

Note: This principle is related with the ISP (Interface Seggregation Principle)


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

REP: Reuse/Release Equivalence PrincipleCCP: Common Closure PrincipleCRP: Common Reuse Principle

Tension diagram between component cohesion

REPGroup for

reuse

CCPGroup for

maintenance

CRPSplit to avoid

unneededreleases

Too many componentsto change

Hardto reuse

Too many unneeded releases


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Coupling

Coupling = Degree of interdependence between software modulesLow coupling ⇒ Improves modifiability

Independent deployment of each moduleStability against changes in other modules


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Coupling principles

ADP - Acyclic dependencies principleSDP - Stable dependencies principleSAP - Stable abstractions principle

Robert C. Martin

Source: Wikipedia


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

ADP - Acyclic Dependencies Principle

The dependency structure for released modules must be a Directed Acyclic Graph (DAG) Avoid cyclesA cycle can make a single change very difficult

Lots of modules are affectedProblem to work-out the building order

NOTE: Cycles can be avoided using the DIP (Dependency Inversion Principle)

http://wiki.c2.com/?AcyclicDependenciesPrinciple

http://wiki.c2.com/?AcyclicDependenciesPrinciple


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo SDP Stable Dependencies Principle

The dependencies between components in a design should be in the direction of stabilityA component should only depend upon components

that are more stable than it isStability = fewer reasons to change

Component X is stableOnly depends on itself

Component Y is less stable It has at least 3 reasons to change


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Stability metrics

Fan-in: incoming dependenciesFan-out: outgoing dependenciesInstability 𝐼𝐼 = 𝐹𝐹𝐹𝐹𝐹𝐹−𝑜𝑜𝑜𝑜𝑜𝑜

𝐹𝐹𝐹𝐹𝐹𝐹−𝑖𝑖𝐹𝐹 + 𝐹𝐹𝐹𝐹𝐹𝐹−𝑜𝑜𝑜𝑜𝑜𝑜Value between 0 (stable) and 1 (instable)

I(Cc)= 13+1

= 14

I(Ca)= 20+2

= 1

I(Cb)= 10+1

= 1

I(Cd)= 01+0

= 0

Stable Dependencies Principle states that the dependencies should be from higher instability to lower

http://wiki.c2.com/?StableDependenciesPrinciple

http://wiki.c2.com/?StableDependenciesPrinciple


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo SAP - Stable Abstractions Principle

A module should be as abstract as it is stablePackages that are maximally stable should be

maximally abstract. Instable packages should be concrete

Abstract

Concrete

Stable Unstable

Zone of pain

Zone of uselessness - Abstract/stable = Interfaces with lots of

dependant modules- Concrete/Unstable = Implementations without dependant modules- Zone of pain = DB schema- Zone of uselessness = interfaces without implementation

http://wiki.c2.com/?StableAbstractionsPrinciple

http://wiki.c2.com/?StableAbstractionsPrinciple


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Connascence

Things that are born and grow togetherA change in one requires others to be modified to

maintain the system correctIndicates problems to change - affects modifiabilityIt is a vocabulary to talk about coupling

Combines coupling and cohesion

More info: https://connascence.io/

https://connascence.io/


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo 3 properties of connascence

DegreeNumber of elements affected by connascence

LocalityDistance between those elements

Same function?, same class?, same package? ...Strength

Easy with which it can refactored


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Types of connascence

StaticCan be detected

with static analysis

Of name

Of Type

Of meaning

Of position

Of algorithm

DynamicDetected at

runtime

Of execution

Of timing

Of value

Of identity

Strength

-

+


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Static connascence

Of nameSeveral components must agree on the same name

Of typeSeveral components must agree on the same type

Of meaning Several components must agree on a meaningExample: magical constants

Of positionSeveral components must agree on a positionExample: arguments with same type

Of algorithmSeveral components must agree on an algorithmExample: Same hash function to encrypt/decrypt

public class Time {int _hour; int _min; int _sec;

public Time(int hour, int min, int sec) {_hour = hour ;_minute = minute ;_second = second ;

}

public String display() {return _hour + ":" + _min + ":" + _sec ;}

}

public class Client {val noon = Time(12,0,0);. . .

}


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Dynamic connascence

Of executionThe order of execution is important

Of timingWhen the timing is importantExample: race conditions

Of valuesSeveral values must change together

Of identityMultiple components must reference the

same entity

Email email = new Email();email.setRecipient("[email protected]");email.setSender("[email protected]");email.send();email.setSubject("Hello World");


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Reducing connascence

Refactor code according to the 3 axes

StrengthName, type, ...

Locality

DegreeNumber of elements


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Robustness Principle, Postel's law

Postel’s law (1980), defined for TCP/IPBe liberal in what you accept and conservative in

what you sendImprove interoperability

Send well formed messagesAccept incorrect messages

Applications to API designProcess fields of interest ignoring the restAllows APIs to evolve later

https://en.wikipedia.org/wiki/Robustness_principlehttps://devopedia.org/postel-s-law

Jon Postel

https://en.wikipedia.org/wiki/Robustness_principle

https://devopedia.org/postel-s-law


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Demeter's Law

Also known as Principle of less knowledgeNamed after the Demeter System (1988)

Units should have limited knowledge about other unitsOnly units “closely” related to the current unit.

Each unit should only talk to its friends "Don’t talk to strangers"

Symptoms of bad designUsing more than one dot...a.b.method(...)a.method(...)

The Law of Demeter improves loosely coupled modulesIt is not always possible to follow

≈


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Fluent APIs

Improve readability and usability of interfacesAdvantages

Can lead to domain specific languagesAuto-complete facilities by IDEsProduct p = new Product().setName("Pepe").setPrice(23);

class Product {...public Product setPrice(double price) { this.price = price;return this;};

It does not contradict Demeter's Law because it acts on the same object

Trick: Methods that modify, return the same object


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Other modularity recommendationsFacilitate external configuration of a module

Create an external configuration moduleCreate a default implementationGRASP Principles

General Responsibility Assignment Software Patterns

DRY (Don't repeat yourself)Intent is declared in one place

YAGNI (You ain't gonna need it) andKISS (Keep it simple stupid)

Do the Simplest Thing That Could Possibly Work”


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Module Systems

In Java: OSGi

Module = bundleControls encapsulationIt allows to install, start, stop and deinstall modules

during runtimeUsed in EclipseModules = Micro-servicesSeveral implementations: Apache Felix, Equinox

Jigsaw Project (Java 9)In .Net: Assemblies


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Module Systems

In NodeJsInitially based on CommonJsrequire imports a moduleexports declares an object that will be available

person.js

const VOTING_AGE = 18const person = {

name: "Juan",age: 20

}function canVote() {

return person.age > VOTING_AGE}module.exports = person;module.exports.canVote = canVote;

const person = require('./person');

console.log(person.name);console.log(person.canVote());


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Module Systems

In Javascript (ES6), it requires Babel in Nodeimport statement imports a moduleexport declares an object that will be available

person.jsconst VOTING_AGE = 18;export const person = {

name: "Juan",age: 20

};export function canVote() {

return person.age > VOTING_AGE}

import { canVote, person} from './person';console.log(person.name);console.log(person.canVote());


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Divide software modules in layersLayers are orderedEach layer exposes an interface that can be used

by higher layers

Layer N

Layer N - 1

. . .

Layer 1


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

ElementsLayer: set of functionalities exposed through an

interface at a level NOrder relationship between layers

Layer N

Layer N - 1

. . .

Layer 1


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

ConstraintsEach software block belongs to one layerThere are at least 2 layersA layer can be:

Client: consumes services from below layersServer: provides services to upper layers

2 variants:Strict: Layer N uses only functionality from layer N-1Lax: Layer N uses functionalities from layers N - 1 a 1

No cycles


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Example

Presentation

Business

Persistence

Database


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Layers ≠ ModulesA layer can be a module......but modules can be decomposed in other modules

(layers can't)Dividing a layer, it is possible to obtain modules


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Layer: conceptual separation Tier: physical separation

Presentation

Persistence

Business

3-Layers

ExternalApplications

Legacysystems

Database

Businesslogic

Firewall

Thinclient

RIA

3-tiers

Presentation Business Data

Layers ≠ Tiers


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

AdvantagesSeparates different abstraction levelsLoose coupling: independent evolution of each

layerIt is possible to offer different implementations of a

layer that keep the same interfaceReusability

Changes in a layer affects only to the layer that is above or below it.

It is possible to create standard interfaces as libraries or application frameworks

Testability


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

ChallengesIt is not always possible to apply it

We don't always have different abstraction levelsPerformance

Access through layers can slow the systemShortcuts

Sometimes, it may be necessary to skip some layersIt can lend to monolithic applications

Issues in terms of deployment, reliability, scalabilitySinkhole antipattern

Requests flow through layers without processing


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Example: Android


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Layers

Variants: Virtual machines, APIs3-layers, N-layers


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Virtual machines

Virtual machine = Opaque layerHides a specific OS implementation

One can only get Access through the public API

Program

Virtual Machine

API

OperatingSystem


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi


AdvantagesPortabilitySimplifies software development

Higher-level programmingFacilitates emulation

ChallengesPerformance

JIT techniquesComputational overload generated by the new layer


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi


ApplicationsProgramming languages

JVM: Java Virtual MachineCLR .Net

Emulation software


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo 3-layers (N-layers)

Technical partitioningEach layer requires different technical capabilities

Presentation

Persistence

Business


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Aspects: Modules that implement crosscutting features

Presentation

Data

Business

Secu

rity

Mon

itor

izat

ion

Logg

ing

AspectsIn

tern

tion

aliz

atio

n


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Elements: Crosscutting concern

Functionality that is required in several places of an application

Examples: logging, monitoring, i18n, security,...Generate tangling code

Aspect. Captures a crosscutting-concern in a module


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Aspect OrientedExample: Book flight seats

Several methods to do the booking:Book a seatBook a rowBook two consecutive seats...

En each method:Check permission (security)Concurrence (block seats)Transactions (do the whole operation in one step)Create a log of the operation...


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Traditional solutionclass Plane {void bookSeat(int row, int number) {// ... Log book petition// ... check authorization// ... check free seat// ... block seat // ... start transition// ... log start of operation// ... Do booking// ... Log end of operation// ... Execute transaction or rollback // ... Unblock}...public void bookRow(int row) {// ... More or less the same!!!!...

Concurrence

LoggingSecurity

Transaction


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Structure

CoreApplication

Logic

CrosscuttingconcernCrosscutting

concernCrosscutting

concern(aspect)

Aspectcompiler

(weaving)

Final application


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

DefinitionsJoin point: Point where an aspect

can be insertedAspect:

Contains:Advice: defines the job of the aspectPointcut: where the aspect will be

introducedIt can match one or more join points

Pointcut

RunningProgram

Join points

Advice


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Aspect example in @Aspectj

@Aspectpublic class Security {

@Pointcut("execution(* org.example.Flight.book*(..))")public void safeAccess() {}

@Before("safeAccess()")public void authenticate(JoinPoint joinPoint) {// Does the authentication

}

}

Methods book*

It is executed beforeto invoke thosemethods

It can Access to information of thejoinPoint


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

Constraints:An aspect can affect one or more traditional modulesAn aspect captures all the definitions of a

crosscutting-concernThe aspect must be inserted in the code

Tools for automatic introduction


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

AdvantagesSimpler design

Basic application is clean of crosscutting concernsFacilitates system modifiability and maintenance

Crosscutting concerns are localized in a single module

ReuseCrosscutting concerns can be reused in other systems


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

ChallengesExternal tools are needed

Aspects compiler. Example: AspectJOther tools: Spring, JBoss

Debugging is more complexA bug in one aspect module can have unknown

consequences in other modulesProgram flow is more complex

Team development needs new skillsNot every developer knows aspect oriented

programming


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Aspect Oriented

ApplicationsAspectJ = Java extension with AOPGuice = Dependency injection FrameworkSpring = Enterprise framework with dependency

injection and AOPVariants

DCI (Data-Context-Interaction): It is centered in the identification of roles from use casesApache Polygene


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Domain basedDomain driven designHexagonal architectureData centeredNaked Objects


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Technical vs domain partitioning

Technical partitioning Organize system modules

by technical capabilities

Domain partitioningOrganize modules by domain

Presentation

Persistence

Business

Database Database

Catalogcheckout

Updateinventory

Ship tocustomer

Reporting

Analytics

Updateaccounts


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Data model vs domain model

Data modelsPhysical:

Data representationTables, columns, keys, ...

Logical: Data structureEntities and relationships

Domain modelsConceptual model of some

domain Vocabulary and context

Entities, relationshipsBehavior

Business rules


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

Centered on the domain and the business logicGoal: Anticipate and handle changes in domainCollaboration between developers and domain experts


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

ElementsDomain model: formed by:

ContextEntitiesRelationships

ApplicationManipulates domain elements


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

ConstraintsDomain model is a clearly identified module

separated from other modulesDomain centered application

Application must adapt to domain model changesNo topological constraints


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

Advantages:Facilitates team communication

Ubiquitous languageReflects domain structure

Address domain changesShare and reuse models

Reinforce data quality and consistencyFacilitates system testing

It is possible to create testing doubles with fake domain data


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

Challenges:Collaboration with domain expertsStalled analysis phase

It is necessary to establish context boundariesTechnological dependency

Avoid domain models that depend on some specific persistence technologies

SynchronizationSynchronize system with domain changes


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Domain based

VariantsDDD - Domain driven designHexagonal styleData centeredN-Layered Domain Driven DesignNaked Objects


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo DDD - Domain Driven Design

General approach to software developmentProposed by Eric Evans (2004)Connect the implementation to an evolving domainCollaboration between technical and domain experts Ubiquitous language

Common vocabulary shared by the experts and the development team

http://ddd.fed.wiki.org/view/welcome-visitors/view/domain-driven-design


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi


ElementsBounded context

Specifies the boundaries of the domainEntities

An object with an identityValue objects

Contain attributes but no identityAggregates

Collection of objects bound together by some root entityRepositories

Storage serviceFactories

Creates objectsServices

External operations


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi


ConstraintsEntities inside aggregates are only accessible

through the root entityRepositories handle storageValue objects immutable

Usually contain only attributes


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo DDD - Domain driven design

AdvantagesCode organization

Identification of the main partsMaintenance/evolution of the system

Facilitates refactoringIt adapts to Behavior Driven Development

Team communication

Problem spaceDomain experts

Solution spaceDevelopment teamUbiquitous language


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo DDD - Domain driven design

ChallengesInvolve domain experts in development

It is not always possibleApparent complexity

It adds some constraints to developmentUseful for complex, non-trivial domains


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Hexagonal style

Other names:ports and adapters, onion, clean architecture, etc.

Based on a clean Domain modelInfrastructures and frameworks are outsideAccess through ports and adapters

ApplicationAdapter

Adapter

Adapter

Adapter

Adapter

Domainmodel

http://alistair.cockburn.us/Hexagonal+architecturehttp://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

port

port

Adapter


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Hexagonal style

Example Traditional application in layers

Incorporates new servicesTesting DB

ApplicationAdapter UI

DBMySQL

Adapter DB2

AdapterREST

Adapterprinter

Adapter DB1

ExternalApplication

DomainModelA

PI p

ort

data

por

t

DBMongoDB

AdapterDB testing


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Hexagonal style

ElementsDomain model

Represents business logic: Entities and relationshipsPlain Objects (POJOs: Plain Old Java Objects)

PortsCommunication interfaceIt can be: User, Database

AdaptersOne adapter by each external elementExamples: REST, User, DB SQL, DB mock,...


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Hexagonal style

AdvantagesUnderstanding

Improves domain understandingTimelessness

Less dependency on technologies and frameworksAdaptability (time to market)

It is easier to adapt the application to changes in the domain

TestabilityIt is possible to substitute real databases by mock

databases


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Hexagonal style

ChallengesIt can be difficult to separate domain from the

persistence systemLots of frameworks combine both

Asymmetry of ports & adaptersNot all are equalActive ports (user) vs passive ports (logger)


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

EntitiesEntitiesEntities

Clean architectureAlmost the same as hexagonal architecturePresented by Uncle Bob - Clean architecture book

Entities

Use cases

Controllers

Externalinterfaces

DBUI

Web

Depends

Enterprise business rules

Application business rules

Interface adapters

Frameworks & drivers


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Data centered

Simple domains based on dataCRUD (Create-Retrieve-Update-Delete) operations

Advantages: Semi-automatic generation (scaffolding)Rapid development (time-to-market)

ChallengesEvolution to more complex domainsAnemic domains

Classes that only contain getters/settersObjects without behavior (delegated to other layers)

Can be like procedural programming

Anemic Models: https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Naked Objects

Domain objects contain all business logicUser interface = Direct representation of domain

objectsIt can be automatically generated

Automatic generation of:User interfaces REST APIs

DomainObject

DomainObject

DomainObject

persistence

services

REST

UI

remoting


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo Naked Objects

AdvantagesAdaptability to domainMaintenance

ChallengesIt may be difficult to adapt interface to special cases

ApplicationsNaked Objects (.Net), Apache Isis (Java)


choo

lof C

omp

ute

rS

cien

ceU

niv

ersi

tyof

Ovi

edo

Documents

Presentación de PowerPoint · 2021. 5. 28. · def reportWorkingHours(): String = { ... }} Financial department. Operations. Management . Responsible departments. There can be multiple