the architect work closely with the analyst to understand the functional & non functional requirments

of the project ( l buisness analyst yahki maa l client w yfasar l wadh3iya lil architect so l architect
yadapti l fikra fil projet puisque yefhem fil les contraints techniques)

yinteracti maa l ness lkoll

ki l analyst yjib haja kesha ml client yhawel l architect yadaptiha keni compliqué ybadel fiha wil
analyst yirja3 lil client b feedback

zeda ykounas ladvisor lil project manager, project manager y9olo al goals w howa ykolo ala kifé
yrakah l planning ,iteration,risk and prevention

yinteracti maa l developer puisque larchi ando fikra kbira al projet donc yguidi l developer kifé
yimplimenti l conception ken fama haja complex mosh fehimha yfasarhélo ,yaamlo code review ken
mizel fi nafs l context wéla hrab

maa l tester les exigences ykouno ma39oulin ( exmple projet mte3 app sghira mosh y9olo nheb tasti
ala trafic 99999)

testeur yirja3 b retour lil architect ala les NFR mte3 l projet b reporting

architect + security exp

l expert yaaml security assesment ychouf les vulnerabilities mte3 l architecture wil system + yassisti fil
raffinage mte3 l conception bich tkoun more secure

l architect yintegri ladvice li 9alo l expert

achit + software operation

l software operation the manage the system ( jme3t l infra ) donc yi9tarho operational framework li
ukoun béhi ( béhi maanéha ala 9ad l budget w ala 9ad l charge mte3 l projet )

wil software architect puisque khtar technology w concept so ymanagi l configuration wil deplo

task of architect

1- define buisness case ( sprint time ,l buget wil planning )

2-understand requirments chnowa yheb l client ( kima l product owner fil scrum )

3-select architecture selon requirments ( meyjich architecture mte3 banka w méhéch scalable )

4- puisque fil select khtar w customazéha fil create bich ydefiniha ( mvc , mvvm ...) baad he will design
it from scratch ( ydefini les components , interactoins data flow ..)

5-yverifi les interactions li amlhom fil 4 ( yverifi ken l couplage fort wéla lé yverifi l scalabilité wil
maintanibilité wil extensibilité)

6-documentation mte3 l conception

7-implimentation ( code)
8-cohhérence de l'architecture

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

what is software architecture :

Structures ( défini l structure ,modules componenets and other building blocks)

decision (choix technologique, choix language , architectural style , design patern ..)

concepts (principles , methodes , spearation es concers modularity scalability ..)

clarify requirments ( li jéyin mil client par exemple ) --- design software archi

| |

| |

| |

| |

review architecture-----------------------------------------------Communicate software archi

avantages documentation : overview on the system ( exemple fil passation li yji baadek yifhem fisa3 )

locate errors and problems

estimationét séhil bich taamlhom puisque tajm treféri al ticket li hia teb3a l haja héki

the new changes ykouno simple bich tala3hom

Quality attributes : assess the archi against NFR kima l performance security scalab , verifi l archi
adequately adress these attribute

view types :

view context : overview of the entire system within the context ot it external envir

show the interactions with external systems , stakeholders and the flow of data between them
it helps stakeholders ( client ) understand how the system fits into their ecosystem

building block view : focus on the static structure of the system

decomposi l system into subsystems , componenets modules wél abuilding blocks w twari l relationét
w les dependences

view tfasar kifé l system is organized & the interactions between les componenets

runtime view : tfaser l behavior mte3 l system fil execution twari kifé les diff compo interact &
communicate during runtime ( aghlabiyt l wakt definie avec un diagramme de séquence )

tfaser kifé l system ydour selon diff scenarios

Deployment view :

focus on the physical aspects of the system , such as hardware & netwrk compo

descibes kifé l repartition mte3 les compo distribué al hardware

black boxes : show eternal interfaces ( kima fil test & validation ) tchouf kén milfou9 métdourich bil
code

donc tfaser les functionalité li accessible lil user

white box : code + dependencies

HIERARCHICAL REFINEMENT : tfarek les architecture complex into more detailed & specific subviews (
high levl views ywaliw low lvl )

high lvl views - decomposition - detailing - consistency - documentation

best practice : avoid redundancy when refine blocks

stop refinement when a block have the same description

use white box ken 2 lback box have a strong dependence ( couplage fort )

check reusing components

RULES FOR DOCUMENTATION

1. Write from the perspective of the reader

2. Avoid unnecessary repetition

3. Avoid ambiguity

4. Use a standardized organizational structure

5. Keep reasons as written

6. Perform regular updates

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

architecture design yreferi l avancement lil customer

customer yhib changes donc new requirements

l requirments yirj3o lil architect w yaaml change fil envir

l change héka infulencing factors kima l wakt wil budget

li yinfulenciw l architect

wéla l client wféwlo flouso wéla tizreb donc influ factors yokhrjo minaando toul

architectures organizations and systems infulences each other

customers and stakeholders can change the requirments and influencing factors

architecture design and decisions should be modified iteratively ( mosh fama change nibdewh toul
next planning )

so it will prevent problms milowl

w yconsidéri l requirments ala bekri

process overview

collect information---- >tawdhi7 requirements ---------- >design structure ----------------->|

develop ideas and influencing factors & tech concepts

|

^ | |

| | |
 | | |

| | |

| architecute< ---- impliment monitoring<------ communicate

achitecture

| review

| |

end system delivery<----------------------

ORGANIZATIONAL FACTORS

organization & structure :

project team

organiz if customer

decision maker

patnership & cooperation

ressources :

time plan

function scope

release plan

budget

team members

organ standards :

process model

quality standards

tools

test

approval & release process

legal factors :

liability issues

data protection

proof obligations
intenational legal issues

principe of decompositions

design in iterations

approaches

consider point of views

identify & assess strength & weakness

reuse

decompostion approaches :

top down : decomposition into sub problems ( analysis )

starting point : vision of overall system

buttom up : assembly of sub solutions (synthesis)

starting point : librairies & sub functions

both process models are compelemntary to each other ( ykamlo baadhhom )

advant disad

top down good understanding of the prblm critical integration

clean interface overlook partial solutions

late detection of prblms serious design

changes

buttom up high rate of reusablity begin with suspected sub prblm

high reliability focus on technical aspects

gradual integration rather than user requirements

risk of premature optimization

wild grown system structure

DIVIDE AND IMPERA ("Divide and Conquer")

break down complex problems into smaller, more manageable sub-problems and solve them
independently

-Horizontal decomposition in layers

Offer clearly defined interfaces.

Use services of underlying layers

-Vertical decomposition in functional module

Decomposition criteria can be functional or technical

Too much dependencies = degenerated design

-Changes in one place cause unexpected errors in other locations = Fragility

- Modifications are difficult (number of dependent components) = Rigidity

- Components can not be reused separately (too much dependencies) = Poor reuse

gang of four ( houma 3patterns éma li amlouhom 4 3béd xD )

Creational Patterns: deal with the process of object creation, encapsulating it to make the system
more flexible and less dependent on how objects are created, composed, and represented.

exemple : singleton , factory , abstract , builder

Structural Patterns:focus on how objects are composed to form larger structures, such as class
composition or object aggregation, while keeping the structure flexible and efficient.

exemple : adapter ,bridge , composite , facade , decorator

Behavioral Patterns: deal with communication between objects, focusing on how objects interact and
distribute responsibilities in a system.

exemple : observer pattern , strategy pattern , command pattern , state , COR chain of responsibility

ARCHITECTURAL PATTERNS :

MVC : separate the concerns

model , view , controller

It is a compound pattern consisting of the Observer, Strategy and Composite patterns.

KNOWN USES

- Interactive systems.

- It is a well-known approach for UI-centric

frameworks:

- Swing.

- Struts.

- QT

THE LAYERS PATTERN: Structures the system on the base of services offered

by underlying layers Abstraction increases with the number of underlying layers

KNOWN USES

-Virtual Machines.

-APIs.

-Information systems.

-Some operating systems – Windows NT.

BENEFITS

Layers are independent

Reuse of layers.

Reduces the amount of possible dependencies between

components.

LIABILITIES

Cascades of changing behavior

Lower efficiency

Too few layers: less benefits

Too many layers: complexity and overhead