1. Tipuri de Structuri arhitecturale. Documentarea arhitectrurii
Ce este si ce nu este arhitectura software
Tipuri de vederi structurale
Documentarea arhitecturilor software
IEEE Standard : “Recommended Practice for Architectural Description of Software-Intensive Systems”
Notatii si limbaje utilizate pentru documentare

2. Ce este si ce nu este arhitectura software?
Exemplu: figura de mai jos intentioneaza sa descrie arhitectura unui sistem care simuleaza o problema de acustica subacvatica
Se utilizeaza pentru descriere o notatie informala foarte “populara” de tip boxes-and-lines
Ce se poate afla din aceasta figura ?
Sistemul consta din 4 elemente
Toate elementele prezinta relatii reciproce de o natura sau alta, diagrama este complet conectata
Trei dintre elemente au probabil ceva mai multe in comun decat al 4-lea
Bass – fig.2.1

3. Ce este si ce nu este arhitectura software? (cont)
Ce NU se poate afla din aceasta figura ?
Care este natura elementelor ?
Care sunt responsabilitatile fiecarui element ?
Care este semnificatia conexiunilor ?
Care este semnificatia alinierii ?
Concluzie: diagrama nu reprezinta o arhitectura software (sau cel putin nu e o reprezentare utila a unei arhitecturi software)

4. Arhitectura software - definitie
“The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them”
(Bass, Clements, Kazman)
Structure(s) – there’s more than one

5. Arhitectura software – definitia explicata
Elemente: (termenul element arhit. e de preferat celui de componenta arhit.)
Arhitectura este o abstractizare a sistemului
Arhitectura omite anumite detalii: se exclud acele proprietati ale elementelor care nu afecteaza modul cum elementele pot fi utilizate de alte elemente sau interactiunile intre elemente
Proprietati vizibile din exterior: servicii furnizate, caracteristici de performanta, utilizarea resurselor partajate de mai multe elemente, etc.
Structuri multiple: Arhitectura poate fi compusa din structuri (vederi structurale) multiple.
De exemplu:
O vedere structurala asupra unui sistem poate captura relatiile dintre modulele in care este impartit proiectul in faza de dezvoltare.
O alta vedere structurala poate captura relatiile dintre elementele care apar in timpul executiei programului
Implicatii: Termenii “Elemente” si “Relatii intre elemente” pot avea diferite semnificatii:
Elemente pot fi: obiecte, clase, functii, procese, programe, biblioteci, etc.
Relatii/Interactiuni intre elemente: subdivizare, sincronizare, apel de functie, etc.
Comportamentul elementelor (behaviour):
Partea observabila din exterior a comportamentului elementelor face parte din arhitectura

6. Care e diferenta intre arhitectura si design ?
“Architecture is design but not all design is architecture” (Clements&al)
Multe decizii privitoare la design nu sunt luate de arhitectura, ci sunt lasate la latitudinea proiectantului de detaliu si implementatorului
Ce decizii sunt ne-arhitecturale ?
Cele care se refera la elemente ale caror proprietati nu sunt vizibile din exterior
Exemplu:
prescriptie arhitecturala: Modulul M trebuie sa furnizeze apelantilor sai o modalitate de a salva si regasi date
decizii nearhitecturale: structurile de date (lista, tablou, etc) si algoritmii utilizati pentru implementare
Elemente arhitecturale vs Elemente nearhitecturale
Elemente nearhitecturale: ar putea fi acele elemente a caror existenta este necunoscuta in afara unui anumit context ?
Clements 22-23

7. Care e diferenta intre arhitectura si design ? (cont)
Elemente arhitecturale vs elemente nearhitecturale (cont): M M2
Exemplul 1: Modulul M -> M2 L1 L2 L3
Exemplul 2: arhitectura layered
Faptul ca existenta unui element “nu este cunoscuta in afara unui context redus” nu este un bun criteriu pentru ca acesta sa fie declarat element nearhitectural !
In exemplul 1, M2 este element nearhitectural ca urmare a deciziei proiectantului arhitecturii sistemului
Un modul de tip M2 poate fi atat element arhitectural cat si nearhitectural
Concluzie: (Clements&al): “Architecture is in the eye of the beholder”

8. Structura/Structurile unui sistem
Categorii de decizii pe care le implica proiectarea arhitecturala:
Cum se structureaza sistemul din punct de vedere al unitatilor de implementare (module) ?
Care este structura sistemului din punct de vedere al elementelor care se identifica in timpul executiei si al interactiunilor acestora ?
Care sunt structurile non-software (hw, retele, echipa de dezvoltare) ?
Un sistem este descris prin mai mult de o singura structura:
Structura modulelor - structura statica a sistemului, rezulta in faza de design
Structura interactiunilor – structura dinamica din timpul executiei sistemului
Structurile allocation/deployment
Fiecarei structuri ii corespunde un tip de vedere structurala (Viewtype)
In cadrul unui tip de vedere structurala, se definesc Elemente permise si Tipuri de Relatii intre acestea
Descrierea arhitecturii sistemului trebuie sa contina, pe langa structuri, si descrierea comportamentala (behavior)

9. Tipuri de vederi structurale (Viewtypes)
Module (Design/Functional Structure)
Component and Connector (Runtime)
Allocation (Deployment, Physical Structure, Team Structure)
Cum se descrie fiecare tip de vedere structurala ?
La ce serveste fiecare tip de vedere structurala ?
Cum selectez vederile relevante ?

10. Tipuri de structuri arhitecturale si vederi structurale
Module:
Decomposition
Uses (Layers)
Generalization
Component-and-Connector:
Datastream (Pipes-and-filters)
Call-return (Client-server, Peer-to-peer)
Shared-data (Blackboard, Repository)
Publish-subscribe (Implicit invocation, Event-only)
Communicating processes (Master-Slave)
Allocation:
Deployment
Implementation
Work assignement

11. The Module Structure: Elements & Relations
Elemente: module
Unitate de implementare pentru software, care reprezinta o entitate coerenta din punctul de vedere al functionalitatii
Relatii:
Is-part-of: A is part of B
Depends on (Uses or Allowed to use)
Is-a: A is a B
Proprietatile elementelor:
Nume: de obicei contine informatia primara din care se poate “banui” rolul sau. Numele pot fi supuse restrictiilor spatiilor de nume.
Responsibilitatile: rolul modulului trebuie descris in mai multe detalii decat simplul nume
Vizibilitatea interfetelor: in cazul submodulelor, se decide care dintre interfetele lor sunt sau nu vizibile din afara modulului care le contine
Informatii despre implementare: nu reprezinta neaparat informatii arhitecturale dar sunt utile la acest nivel:
Maparea module <-> unitati de cod de implementare (fisiere)
Test & management information
Implemention constraints
Clements 50-51

12. Module: Decomposition Structure
Relatia A is-part-of B: defineste o relatie intre submodulul A si modulul agregat B
Restrictii: un modul poate fi parte din cel mult un modul agregat
Arata cum sunt partitionate responsabilitatile sistemului intre mai multe module
Realizarea descompunerii si a modulelor: build, buy, or reuse?
Vizibilitatea submodulelor poate fi controlata prin prescriptiile arhitectului
Un submodul vizibil in exterior poate fi utilizat (relatia uses) de alte module
Utilizare:
Intelegerea functionarii sistemului si a implementarii
Planificarea proiectului si resurselor necesare, alocarea sarcinilor echipei de dezvoltare
De obicei este startul oricarui proces de proiectare -> corespunde stilului de abordare divide-and-conquer
Determina mare parte din proprietatea de modifiability a sistemului

13. Module: Uses Structure
Relatia depends-on, specializata in uses
Alte specializari ale relatiei depends-on: includes, inherits from
Stilul Uses specifica constrangeri asupra modului de implementare: pentru fiecare modul specifica modulele cu care e in relatie uses sau is-allowed-to-use
Ce se intelege de fapt prin relatia uses ?
P uses Q if P depends on Q for functional correctness
P uses Q nu este echivalent cu P calls Q:
P uses Q, dar NU si P calls Q: De exemplu, P se bazeaza pe valoarea unei variabile comune setata de Q; sau P este un proces in stare de sleep care asteapta un semnal de la Q
P calls Q, dar NU si P uses Q: Q este un exception handler pe care P il apeleaza in situatii de erori; Nu este relatie uses pentru ca functionalitatea lui P nu este afectata de ce anume face Q
Utilizare:
Planificarea dezvoltarii incrementale
Impact analysis
Clements 74-75

14. Module: Generalization Structure
Relatia A is-a B: defineste o relatie de generalizare intre un modul specific A (element child) si un modul mai general B (element parent). Elementul child poate fi utilizat in orice context unde este utilizat elementul parent.
Variante:
Interface inheritance
Implementation inheritance
Utilizare:
Suport pentru extinderea si evolutia arhitecturii
Suport pentru re-use
OOD

15. Module Structure: Concluzii
La ce e bun tipul de vedere Module:
Construction blueprints
Analysis
Impact analysis: prezice efectul modificarilor aduse sistemului; se bazeaza in special pe relatiile de dependenta
Traceability to functional requirements: cerintele functionale sunt suportate de responsabilitatile modulelor
Communication
Explain functionality
Relationships of system parts
La ce NU e bun tipul de vedere Module:
Comportamentul sistemului in timpul executiei
Runtime qualities: performance, reliability, etc. => pentru analiza lor sunt necesare vederi din tipul Component-and-Connector
Maparea vederilor din tipul Module pe vederi din tipul Component-and-connector
Rareori este de tip one-to-one
Destul de frecvent este de tip one-to-many
Pot apare si cazuri complexe in care fragmente de module corespund unor fragmente de componente

16. Component-and-Connector: Overview
Reprezinta entitati care apar in timpul executiei programului
Nu reprezinta unitati de implementare
Analogie modelare UML:
Module Viewtype <-> Class Diagrams
Component&Connector ViewType <-> Object (Collaboration) Diagrams
Elementele sunt numite componente si conectori
Ambele categorii au semantici bine definite
Conectorii NU pot fi redusi la o subcategorie de componente

17. Component-and-Connector: Elements& Relations
Elemente: Componente – Unitati de procesare si Unitati de stocare de date
Se manifesta in timpul executiei, sub forma de: procese, obiecte, clienti, servere, baze de date, etc.
Porturi: “interfata” componentei la executie; puncte de (potentiala) interactiune cu mediul
Tipul unei componente: defineste functionalitatea generala a acesteia, numarul si tipul porturilor, proprietatile cerute; de exemplu, o componenta de tip “filter” proceseaza fluxuri (stream) de intrare primite pe porturile de tip “input”, rezultand fluxuri de iesire la porturile “output”.
Conectori – mecanisme de interactiune intre componente
Se manifesta sub forma de apeluri de procedura, mesaje, evenimente, pipes
Interactiunile pot fi si protocoale de comunicatie complexe, necesitand suportul infrastructurii precum middleware, sisteme de operare, etc.
Roluri: “interfetele”; de exemplu, un conector pipe poate fi descris avand 2 roluri, “writer” si “reader”.
Tipul unui conector: defineste natura interactiunilor, numarul si tipul rolurilor, proprietatile cerute
Relatii – attachment: definesc topologia sistemului
specifica ce porturi ale componentelor se leaga la anumite roluri ale conectorilor

18. Exemplu: structura C&C
Clements 102

19. Informatii aduse de vederea C&C
Care sunt elementele care apar in timpul executiei sistemului si interactiunile dintre ele ? Care este dinamica acestui aspect in cursul executiei ?
Care sunt principalele surse de date ?
Exista parti replicate in sistem ?
Care sunt fluxurile de date prin sistem ?
Ce protocoale de comunicatie utilizeaza elementele sistemului ?
Ce categorii de proprietati ale sistemului pot fi analizate pe baza vederii C&C ?
Reliability
Performance
Resource requirements
Functionality
Security

20. Component-and-Connector: Datastream Structure
Exemplu de specializare a structurii Datastream: stilul Pipes-and-Filters
componentele comunica prin intermediul unor asynchronous, buffered data streams
Adecvat sistemelor a caror comportament poate fi descris in mod natural sub forma unui graf de transformari, unde nodurile sunt unitati procesatoare iar arcele indica fluxurile de date intre acestea
Elemente: Filter: componente procesatoare de date, au 1 sau mai multe porturi de intrare si 1 sau mai multe porturi de iesire
Conectori: Pipe: conector binar unidirectional, transmite fluxul de date de la un port de iesire al unui filtru spre un port de intrare al altui filtru
Caracteristici:
Deoarece conectorii pipe buffereaza datele, filtrele pot opera asincron si concurent; Un filtru nu trebuie sa cunoasca identitatea filtrelor de la care primeste sau la care transmite date
Utilizare:
Analiza functionala
Analiza performantelor sistemului (input-output latency, schedulability)

21. Component-and-Connector: Shared-data Structure
Elemente:
Data repositories
Data accessors
Componentele de tip data accessor citesc date de la componentele de tip repository, efectueaza calcule si scriu rezultatele in repository
Componentele repository indeplinesc functiile de: asigura acces comun la date, persistenta datelor,accesul concurent la date
Conectori: de tip read data si write data
Relatii: definesc ce data accessors sunt conectati la ce data repositories
Substiluri:
Repository
Blackboard
Utilizare:
Analiza performantelor sistemului: performance, security, privacy, reliability
Asigurarea integritatii datelor

22. Component-and-Connector: Publish-subscribe Structure
Elemente: componente independente care interactioneaza prin evenimente.
Componentele sunt decuplate: nici o componenta nu stie care sunt alte componente au subscris la evenimentele sale
Conectori: de tip publish-subscribe.
Necesita o infrastructura care sa asigure faptul ca un eveniment produs ajunge la toate componentele care au subscris la el
Relatii: ce tipuri de evenimente publica fiecare componenta si la ce tipuri de evenimente subscrie fiecare componenta
Substiluri:
Implicit invocation
Event-only
Utilizare:
Exprima comunicarea prin mesaje (evenimente) intre participanti necunoscuti
Decuplarea permite intarzierea legarii producatorilor de evenimente de consumatorii de evenimente pana in momentul executiei
Vezi si POSA 339; Observer Pattern

23. Component-and-Connector: Call-return Structure
Componentele interactioneaza prin faptul ca solicita servicii de la alte / furnizeaza servicii pentru alte componente.
Interactiunile=invocarea de servicii
in mod tipic, au loc sincron (solicitantul se blocheaza pana primeste raspunsul)
reprezinta o generalizare a apelului de functii din lb de programare
Substiluri:
Client-server
Peer-to-peer

24. Client-Server / Peer-to-Peer Style
Tipuri de componente:
Client: solicita servicii de la alte componente
Server: furnizeaza servicii altor componente
Peer: Componenta care inglobeaza atat comportament de Client cat si de Server
Proprietati: numarul si tipul clientilor care se pot conecta, proprietati de performanta (de ex nr tranzactii pe secunda)
Tipuri de conectori:
Request-reply: operatie (sincrona) de invocare de servicii de la client la server
Proprietati: protocolul de interactiune: un conector poate defini unul sau mai multe tipuri servicii invocate. In cazul in care prin acelasi conector se invoca mai multe servicii, este nevoie de un protocol care sa stabileasca ordinea in care acestea pot fi invocate
Relatii: attachments: determina ce clienti pot solicita anumite servicii
Model computational: clientii initiaza activitatile, solicitand servicii de la servere, apoi asteapta rezultatele acestor cereri.
Topologie: se pot specifica posibile constrangeri privitoare la:
Numarul de legaturi(attachments) pentru anumite porturi/roluri
Relatii intre servere
Tiers => N-tiered client server model
POSA 323: Client-Dispatcher-Server
POSA: Broker

25. Component-and-Connector: Process Structure
Componente: unitati concurente (task, proces, fir de executie)
Proprietati: daca este sau nu preemptabila; prioritatea pentru planificarea in mediu de executie multitasking; , which influences scheduling; parametrii de timp (periodicitate, deadlines)
Conectori: comunicare intre unitati concurente “synchronizes with”, “starts”, “communicates with”, “wait for”)
Proprietati: Modul de comunicare sincron sau asincron; protocolul de comunicare.
Substiluri:
Watchdog
Resource synchronisation
Utilizare:
Identificarea locurilor in care apare competitia pebtru resurse partajate
Identificarea imprejurarilor in care firele de executie (procesele) sunt create sau distruse

26. Allocation Structure Deployment: Work assignement: Implementation:
Descrie modul de mapare a elementelor software pe elemente hardware
Elemente:
Componente software, definite in C&C
Elemente de mediu: procesoare, elemente de stocare, de retea, etc.
Relatii:
Allocated-to, arata pe ce elemente de mediu sunt localizate elementele software
Migrates-to, copy-migrates-to, execution-migrates-to
Utilizare: analiza: performance, availability, security; estimare costuri.
Work assignement:
Software: module
Elemente de mediu: persoana, echipa, subcontractor, etc
Relati: Allocated-to
Utilizare: project management
Implementation:
Descrie maparea modulelor pe fisiere
Utilizare: Configuration control, integration, build testing

27. Relatia Module – C&C
Acelasi modul poate fi executat in mai multe componente
Aceeasi componenta poate executa cod din mai multe module
[Clements] – fig.3.5

28. Relatia C&C - Allocation
Exemplu: Vedere Combinata:
3-Tiers combina
Client-Server cu Deployment
[Clements] – fig.6.16

29. Documentarea arhitecturii software
Rolul documentatiei arhitecturii:
Baza de comunicare intre stakeholders
Permite analiza:
Quality attributes
Behavior
Evolution and extension
Ce informatii trebuie sa cuprinda documentatia arhitecturala?
Structuri arhitecturale diferite => Vederi (Views) diferite
Informatii diferite urmarite => selectia vederilor documentate se face in functie de acestea
Categorii diferite de stakeholders => selectia vederilor documentate se face in functie de acestea

30. Informatii aduse de diferite vederi structurale
[Bass] – Tab.2.1.
Module
C&C
Allocation

31. Utilizari ale descrierii arhitecturale
[Bass] – Tab.9.1.

32. Caror stakeholderi se adreseaza diferite vederile structurale
[Bass] – Tab.9.2.
Bass table 9.2

33. IEEE Standard 1471
IEEE Standard : “Recommended Practice for Architectural Description of Software-Intensive Systems”
Architectural Description: colectie de produse care sunt utilizate pentru documentarea unei arhitecturi
Ce NU impune IEEE 1471: NU impune un anumit format, limbaj sau formalism pentru descrierea arhitecturala
Ce Recomanda IEEE 1471: recomanda un anumit continut (o anumita structura a continutului si anumite aspecte documentate)

34. IEEE 1471 – Main Concepts
Stakeholder: has interests in, or concerns relative to the system
View: a representation of a concrete system from a single perspective
an architectural description is organized into several views. A view addresses certain concerns of the stakeholders.
Viewpoint: a pattern (template) for representing a set of concerns relative to architecture. The viewpoint establishes conventions by which a view is created, depicted and analyzed.
A view conforms to a viewpoint. The viewpoint determines the languages (notation, models) to be used to describe the view
Putem considera ca un viewpoint este formalizarea unui viewtype
Architectural description: selects one or more viewpoints for use
IEEE nu impune un anumit set de vederi: acesta se determina in functie de interesele celor carora li se adreseaza documentatia

35. IEEE 1471 - Model for Architectural Description
System
has an
Architecture
has
1..*
described by 1
Stakeholder
identifies
Architectural
Description
is important to
1..*
organized by
1..*
selects
1..*
has
1..*
Concern
used to cover
Viewpoint
conforms to
View

36. Descrierea arhitecturala
Viewpoints:
Module
C&C
Allocation
Notatii:
Notatii informale
boxes-and-lines
UML
Diferite diagrame
ADL’s (Architectural Description Languages)
Diferite limbaje

37. Exemplu descriere Module UML
Module: Class, Package
Relatii: Class diagrams

38. Descriere C&C Ce trebuie sa descrie?
Elemente:
Componente , Porturi
Conectori, Roluri
Relatii: attachement
componenta.port <-> conector.rol

39. Exemplu descriere C&C Notatie Informala – Boxes-and-lines
Notatiile informale pot fi utile, cu conditia sa existe o intelegere clara (o legenda) a simbolurilor folosite
[Clements] – fig.4.2

40. Exemplu descriere C&C UML : optiunea 1 : Class-Object
Component Type
Class
Component
Instance
Object
Port
?? Variante: None, Interface, Annotation, Class
Connector type
?? Variante: Associations, Class
Connector instance
?? Variante: Links, Object
Nu ofera suport adecvat pentru reprezentarea porturilor si conectorilor
[Bass] – Fig. 9.10

41. Exemplu descriere C&C UML 2.0 : optiunea 2: UML Components
Component Type
Component
Instance
Component Instance
Port
Connector type
?? Class
Connector instance
?? Object
Introduce reprezentare pentru porturi.
Nu reprezinta conectorii.
[CMU/SEI-2004-TR-008]

42. UML 2.0 new concepts: Interfaces
Provided Interfaces: descriu operatiile publice (features) care constituie un serviciu furnizat
Required Interfaces: nou din UML 2.0: descriu features care constituie un serviciu de care depinde serviciul furnizat
Element cu o interfata provided si una required
Realization relation: provided interface
Dependency relation: required interface

43. UML 2.0 new concepts: Port
Port: concept asemanator cu interface – descrie cum un element interactioneaza cu mediul
Diferenta fata de interface: fiecare port reprezinta un punct de interactiune distinct
Fiecare port are un tip
Poate fi asociat cu descrieri comportamentale (protocol state machines)
Fiecare port poate fi asociat cu un numar de interfete de tip provided si/sau requested

44. UML 2.0 new concepts: Component
Component: a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment
Subtype of class in the UML metamodel
Permite: subtyping through generalization, behavioral description, internal structure, ports, interfaces, instantiation
In plus fata de class: mai multe tipuri de elemente decat class: packages, use cases; deployment specifications
Vedere externa a unei componente cu porturi
Vedere interna a unei componente cu porturi

45. UML 2.0 new concepts: Connector
Connector: communication link between two or more instances
NU poate fi asociat cu descrieri comportamentale sau atribute
Tipuri de conectori:
Assembly connector: leaga o provided interface de o required interface sau doua porturi externe a doua componente
Delegation connector: leaga un comportament extern (port) de realizarea sa interna

46. Exemplu descriere C&C Architectural description languages
Architectural description language: o notatie grafica sau textuala pentru descrierea unui sistem software in termenii de elemente arhitecturale si relatii intre acestea
Diferite ADL’s:
ACME
Wright

47. Exemplu descriere C&C Acme ADL
Acme: limbaj de descriere arhitecturala
Family PipeFilter = {
Port Type OutputPort;
Port Type InputPort;
Role Type Source;
Role Type Sink;
Component Type Filter;
Connector Type Pipe = {
Role src : Source;
Role snk : Sink;
Properties {
latency : int;
pipeProtocol: String = ; } };

48. Exemplu descriere C&C Acme ADL – Continuare exemplu
System simple : PipeFilter = {
Component Splitter : Filter = {
Port pIn : InputPort = new InputPort;
Port pOut1 : OutputPort = new OutputPort;
Port pOut2 : OutputPort = new OutputPort;
Properties {. . . } };
Component Grep : Filter = {
Port pOut : OutputPort = new OutputPort;
Component MergeAndSort : Filter = {
Port pIn1 : InputPort = new InputPort;
Port pIn2 : InputPort = new InputPort;
Representation {
System MergeAndSortRep : PipeFilter = { … }
}; /*end Representation */
Connector SplitStream1 : Pipe = new Pipe;
Connector SplitStream2 : Pipe = new Pipe;
Connector GrepStream : Pipe = new Pipe;
Attachments {
Splitter.pOut1 to SplitStream1.src;
Grep.pIn to SplitStream1.snk;
Grep.pOut to GrepStream.src;
MergeAndSort.pIn1 to GrepStream.snk;
Splitter.pOut2 to SplitStream2.src;
MergeAndSort.pIn2 to SplitStream2.snk; };
}; /* end System simple */

49. Exemplu descriere Allocation UML Deployment diagram