software architecture taxonomies - modularity

99
Arquitectura del Software Escuela de Ingeniería Informática Universidad de Oviedo Software Architecture Part II. Architecture classifications 3 - Modularity Jose Emilio Labra Gayo 2014 ES Españo l Universidad de Oviedo

Upload: jose-emilio-labra-gayo

Post on 17-Dec-2014

312 views

Category:

Technology


0 download

DESCRIPTION

Software Architecture Taxonomies - modularity Jose Emilio Labra Gayo Software Architecture Course

TRANSCRIPT

Page 1: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Software ArchitecturePart II. Architecture classifications3 - Modularity

Jose Emilio Labra Gayo

2014

ESEspañol

Universidad de Oviedo

Page 2: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modularity

Page 3: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modularity StylesBig Ball of MudHierarchical decompositionDependenciesGeneralizationLayersAspect Oriented decompositionDomain based decomposition

Page 4: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Big Ball of Mud

Big Ball of MudDescribed by Foote & Yoder, 1997

ElementsLots of entities intertwined

ConstraintsNone

Page 5: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Big Ball of Mud

AdvantagesQuick-start

It is possible to start without defining an architecture

Solve problems on demandCheap solution for short-term projects

It can be OK for some projects

Page 6: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Big Ball of Mud

ProblemsHigh Maintenance costsLow flexibility from a given point

At start 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

Page 7: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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 is reproduced in lots of placesAnti-patternsBad smells

Code/Architecture

Page 8: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decomposition

ElementsModules

Each module has an interface and a bodyRelationships "is part of" between modules

Page 9: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decomposition

DefinitionsModule:

Piece of software the offers a set of responsabilities

It makes sense at development time (no runtime)Separates interface from body

Interface Describes what is a moduleHow to use it Contract

BodyHow it is implemented

Interface

Body(Implementation)

Module

Page 10: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decompositionQuality attributes

CommnicationCommunicates the general aspect of the

systemMinimizes complexity

A module only exposes an interfaceExtensibility, maintenance

Facilitates changes and extensionsLocalized functionality

ReusabilityModules can be used in other contextsProduct lines

IndependenceModules can be developed by different teams

Page 11: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decomposition

ChallengesBad decomposition can augment complexityDecission: Develop vs buy

COTS modulesDependency management

Third parties modules can affect evolutionTeam organization

Modular decomposition can affect team development and organization

Page 12: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decomposition

ConstraintsNo cycles are allowedA module can only have one parent

System

Subsystem A

SubsystemB

SubsystemB1

SubsystemB2

Subsystem A2

SubsystemA1

Page 13: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modular decomposition

Some recommendationsHigh cohesionLow couplingSOLID principlesDemeter's LawFluid interfaces

Page 14: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modularity recommendations

High cohesionCohesion = Coherence of a module

Each module must solve one functionalityDRY (Don't Repeat Yourself) Principle

Intention must be declared in only one placeIt should be possible to test each module

separately

Page 15: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modularity recommendations

Low couplingCoupling = Interaction degree between

modulesLow coupling Improves modifiabilityIndependent deployment of each moduleStability against changes in other modules

Page 16: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Modularity recommendations

SOLID principlesThey can be used to define clases and

modules

SRP (Single Responsability Principle)OCP (Open-Closed Principle)LSP (Liskov Substitution Principle)ISP (Interface Seggregation Principle)DIP (Dependency Injection Principle)

Page 17: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 18: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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.

Page 19: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 20: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

(O)pen/Closed principle

Example: class SelectProducts { def filterByColor(products: List[Product], color: Color): List[Product] = { ???}

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

Another solution:

def filter(products: List[Product], predicate: Product => Boolean): List[Product] = { ???}

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

Page 21: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

(L)iskov Substitution

Subtypes must follow supertypes contractA type B is a subtype of A when:xA, if there is a property Q such that Q(x) then yB, 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

A

B

Page 22: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

(L)iskov Substitution

Duck

haceCuaktieneFormaPatorespira)

RubberDuckyDuckInPark

doCuakhasShapeDuckbreathes)

X

Example

Page 23: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

(I)nterface Segregation

Clients must not depend on unused methodsBetter to have small and cohesive interfacesOtherwise non desired dependencies

If a module depends on non-used functionalities and these functionalities change, the module can be effected

ClientA

ClientB

InterfaceA

methodA1

methodA2InterfaceB

methodB1

methodB2

Service

mehtodA1methodA2methodB1methodB2

...

<<uses>>

<<uses>>

Page 24: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

(D)ependency Inversion

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

modulesBoth should depend on abstractions

Abstractions should not depend upon details. Details should depend upon abstractions

Can 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

Page 25: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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.

Page 26: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Demeter's Law

Principle of less knowledgeModules only communicates with near

modulesGoal: low coupling

Lower number of invoked methodsTradeoff solution

It is not always possitiveIt can augment number of methods in modules

Symptoms of bad design:Using more than one dot...a.b.method(...)

Page 27: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Fluent APIs

Improve readability and usability of interfacesAdvantages

Can lead to domain specific languagesAuto-complete facilities by IDEs

Page 28: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Fluent APIs

Methods that modify return the same object

Several methods can be chainedExample:

Product p = new Product(). setName("Pepe"). setPrice(23);

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

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

Page 29: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Other modularity recommendationsFacilitate external configuration of a

moduleCreate an external configuration module

Create a default implementationGRASP Principles

General Responsibility Assignment Software Patterns

Page 30: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module SystemsIn Java:

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

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

EquinoxJigsaw Project (Java 9)

In .Net: Assemblies

Page 31: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module Dependencies

Page 32: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module Dependencies

Relationship "uses"One module uses (depends on) other

module

Page 33: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module Dependencies

ElementesModulesRelationships "depends on" between

modulesConstraints

Module M1 depends on M2 if correct behavior of M1 depends on correct behavior of M2

Page 34: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module Dependencies

Advantages:Incremental development

Implement part of the functionalityDebugging, testingFacilitates impact analysis upon changes

Page 35: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Module dependencies

ChallengesDependency management

Avoid cyclic dependenciesModules that depend on a lot of modules

Limits incremental development

Bad separation of concerns

Page 36: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Generalization/Specialization

Page 37: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Generalization/specialization

ElementsModulesRelationships (is-a) between

modulesConstraints:

Parent is more general than children

Page 38: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Generalization/Specialization

AdvantagesFacilitates extensión and architecture

evolutionNotion of inheritance in OO designCaptures common parts with variations =

childrenChange and local variation

Reuse

Page 39: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Generalization/Specialization

ChallengesComplexity to identify relationshipsExceptionsMultiple inheritance implications

Page 40: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Generalization/Specialization

ApplicationsApplication frameworks

Page 41: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

Page 42: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

Divide software modules in layersOrder between layersEach layer exposes an interface that can be

used by higher layers

Layer N

Layer N - 1

. . .

Layer 1

Page 43: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 44: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Capas

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 1

to N - 1No cycles

Page 45: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

Example

User interface

Application

Domain

Infrastructure

Page 46: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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 posible to obtain

modules

Page 47: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

Layer: conceptual separation Tier: physical separation

Presentation

Data

Business

3-Layers

ExternalApplications

Legacy systems

Database

Businesslogic

Firewall

Thin client

RIA

3-tiers

Presentation Business Data

Layers ≠ Tiers

Page 48: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 49: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

ChallengesIt is notalways possible to apply it

Not always do we have different abstraction levels

PerformanceAccess through layers can slow the system

ShortcutsSometimes, it may be necessary to skip some

layers

Page 50: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

Example: Android

Page 51: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Layers

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

Page 52: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Virtual machine

Virtual machine = Opaque layerHides a specific OS implementation

One can only get Access through the public API

Program

Virtual Machine

API

Operating System

Page 53: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Virtual machines

AdvantagesPortabilitySimplifies software development

Higher-level programmingFacilitates emulation

ChallengesPerformance

JIT techniquesComputational overload generated by the

new layer

Page 54: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Virtual machine

ApplicationsProgramming languages

JVM: Java Virtual MachineCLR .Net

Emulation software

Page 55: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

3-layers (N-layers)

Conceptual decompositionPresentationBusiness logicData

Presentation

Data

Business

Page 56: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect Oriented

Page 57: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect Oriented

Aspects: Modules that implement crosscutting features

Presentation

Data

Business

Secu

rity

Mon

itori

zati

on

Log

gin

g

AspectsIn

tern

tion

ali

zati

on

Page 58: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect Oriented

Elements: Crosscutting concern

Functionality that is required in several places of an application

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

Aspect. Captures a crosscutting-concern in a module

Page 59: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 60: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect OrientedTraditional solutionclass Plane { void bookSeat(int row, int number) { // ... Log book petition // ... check autorization // ... 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

Page 61: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect Oriented

Structure

Core Application

Logic

Crosscutting

concern

Crosscutting

concern

Crosscutting

concern(aspect)

Aspect compiler (weaving)

Final application

Page 62: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 63: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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 before to invoke those methods

It can Access to information of the joinPoint

Page 64: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 65: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Aspect Oriented

AdvantagesSimpler design

Basic application is clean of crosscutting concerns

Facilitates system modifiability and maintenanceCrosscutting concerns are localized in a single

moduleReuse

Crosscutting concerns can be reused in other systems

Page 66: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 67: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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 cases

Page 68: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain basedDomain based

Domain driven designHexagonal architectureData centeredPatterns

CQRSEvent sourcingNaked Objects

Page 69: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Data model vs domain model

Data modelsPhysical: Data representation

Tables, columns, keys, ...

Logical: Data structure

Entities and relationships

Domain modelsConceptual model of a

domain Vocabulary and context

Entities, relationshipsBehavior

Business rules

Page 70: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain based

Centered on the domain and the business logicGoal: Anticipate and handle changes in

domainCollaboration between developers and

domain experts

Page 71: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain based

ElementsDomain model: formed by:

ContextEntitiesRelationships

ApplicationManipulates domain elements

Page 72: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain based

ConstraintsDomain model is a clearly identified module

separated from other modulesDomain centered application

Application must adapt to domain model changes

No topological constraints

Page 73: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 74: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain basedChallenges:

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

Page 75: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain basedVariants

DDD - Domain driven designHexagonal styleData centeredN-Layered Domain Driven DesignRelated patterns:

CQRS (Command Query Responsibility Segregation)

Event SourcingNaked Objects

Page 76: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 77: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

DDD - Domain Driven Design

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 entity

ServicesExternal operations

Page 78: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

DDD - Domain Driven Design

ConstraintsEntities inside aggregates are only

accessible through the root entityValue objects contain only attributes

(immutables)

Page 79: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

DDD - Domain driven design

AdvantagesCode organization

Identification of the main partsMaintenance/evolution of the system

Facilitates refactoringIt adapts to Behaviour Driven Development

Team communication

Problem spaceDomain experts

Solution spaceDevelopment team

Ubiquitous language

Page 80: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 81: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Hexagonal styleOther names:

ports and adapters, onion, clean, etc.Based on a clean Domain model

Infrastructures 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

port

Adapter

Page 82: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Hexagonal style

Example Traditional application in layers

Incorporates new servicesTesting DB

ApplicationAdapter

UI

DBMySQL

Adapter DB2

AdapterREST

Adapterprinter

Adapter DB1

External Applicati

on

DomainModelA

PI

port

data

port

DBMongoDB

logging port

AdapterDB testing

Page 83: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Hexagonal style

ElementsDomain model

Represents business logic: Entities and relationships

Plain Objects (POJOs: Plain Old Java Objects)Ports

Communication interfaceIt can be: User, Database

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

Page 84: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Page 85: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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)

Page 86: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Data centered

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

operationsAdvantages:

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

ChallengesEvolution to more complex domainsAnemic domains

Classes that only contain getters/settersObjects without behaviour (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/

Page 87: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Domain based styles

3 patterns relatedCQRSEvent SourcingNaked Objects

Page 88: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

CQRS

Command Query Responsibility SegregationSeparate models in 2 parts

Command: Does changes (updates information)Query: Only queries (get information)

Application

Model

UserInterfac

e

DataBase

Page 89: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

CQRS

Command Query Responsibility SegregationSeparate models in 2 parts

Command: Does changes (updates information)Query: Only queries (get information)

Application

Query

UserInterfac

e

DataBase

Command

Page 90: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

CQRS

AdvantagesScalability

Optimize queries (read-only)Asynchronous commands

Facilitates team decomposition and organization1 team for read access (queries)1 team for read/write access (command)

Page 91: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

CQRS

ChallengesHybrid operations (both query and

command)Example: pop() in a stack

ComplexityFor simple CRUD applications it can be too

complexSynchronization

Possibility of queries over non-updated data

ApplicationsAxon Framework

Page 92: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Event Sourcing

All changes to application state are stored as a sequence of eventsEvery change is captured in an event store

It is possible to trace and undo changes

Write

----------------------------------------------------------------------

Event store

EventDriver

Read

snapshots

Page 93: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Event SourcingElements

Events: something that has happened, in the pastEvent store: Events are always added (append-

only)Event driver: handles the different eventsSnapshots of aggragated state (optional)

Write

----------------------------------------------------------------------

Event store

EventDriver

Read

snapshots

Page 94: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Event Sourcing

AdvantagesFault toleranceTraceability

Determine the state of the application at any time

Rebuild and event-replayIt is possible to discard an application state

and re-run the events to rebuild a new stateScalability

Append-only DB can be optimized

Page 95: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Event Sourcing

ChallengesEvent handling

Synchronization, consistencyComplexity of development

It addes a new indirection levelResource management

Event granularityEvent storage grows with time

Snapshots can be used for optimization

Page 96: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Event Sourcing

ApplicationsDatabase systems

Datomic EventStore

Page 97: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

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

Domain

Object

persistence

services

REST

UI

remoting

Page 98: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

Naked Objects

AdvantagesAdaptability to domainMaintenance

ChallengesIt may be difficult to adapt interface to

special casesApplications

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

Page 99: Software Architecture Taxonomies - modularity

Arquitectura del SoftwareE

scu

ela

de I

ngen

ierí

a I

nfo

rmáti

ca

Un

ivers

idad d

e

Ovi

edo

End of Presentation