system is a depic(on of the system that aids in the understanding of how the system will behave. So(ware architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be carried out by design and implementaFon teams. The architecture is the primary carrier of system quali(es such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an arFfact for early analysis to make sure that a design approach will yield an acceptable system. SEI SoAware Engineering Ins(tute
a structured solu(on that meets all of the technical and opera(onal requirements, while op(mizing common quality aCributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the applicaFon. MSDN
in PracFce, Second EdiFon The so(ware architecture of a program or compuFng system is the structure or structures of the system, which comprise soAware elements, the externally visible proper(es of those elements, and the rela(onships among them. “Externally visible” properFes are those assumpFons other elements can make of an element, such as its provided services, performance characterisFcs, fault handling, shared resource usage, and so on. —Len Bass, Paul Clements, and Rick Kazman, So(ware Architecture in PracFce, Second EdiFon
its environment [IEEE]. The architecture of a so(ware system (at a given point in Fme) is its organiza(on or structure of significant components interac(ng through interfaces, those components being composed of successively smaller components and interfaces
can be recursively decomposed into parts that interact through interfaces, rela(onships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.
Philippe Kruchten, Grady Booch, Kurt BiZner, and Rich Reitman derived and refined a definiFon of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definiFon is: SoAware architecture encompasses the set of significant decisions about the organizaFon of a so(ware system including the selecFon of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboraFon among those elements; composi(on of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organizaFon. So(ware architecture also involves funcFonality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aestheFc concerns
PracFce (2nd ediFon), Bass, Clements, and Kazman define architecture as follows: “The so(ware architecture of a program or compuFng system is the structure or structures of the system, which comprise so(ware elements, the externally visible properFes of those elements, and the rela(onships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementaFon—are not architectural.”
decisions about the organiza(on of a soAware system, the selecFon of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collabora(ons among those elements, the composiFon of these elements into progressively larger subsystems, and the architectural style that guides this organizaFon -‐-‐ these elements and their interfaces, their collaboraFons, and their composiFon. [Kruchten]4
when explaining architecture. He idenFfies these themes as: “The highest-‐level breakdown of a system into its parts; the decisions that are hard to change; there are mulFple architectures in a system; what is architecturally significant can change over a system's lifeFme; and, in the end, architecture boils down to whatever the important stuff is.”
look in your system, you can tell that the design is part of the same overall design style, theme, mood …is about Design and Style Consistency in all dimensions of the system Fed Brooks: “It is be0er to have a system...reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas” User interface, technologies, coding styles, naming convenBons, directory structures, classes, components, interfaces, internal and external behavior, deployment… Conceptual Integrity tries to limit the system complexity Conceptual Integrity simplifies collaboraFon when creaFng so(ware The Mythical Man-‐Month
on the noFon of a "file” (e.g. directories, devices, filesystems, named pipes and sockets are all sort-‐of files) • Smalltalk • "everything is an object", and the small set of other accompanying principles • SQL • "all data is in tables", with keys and constraints • Lisp • "everything is a list” h0p://c2.com/cgi/wiki?ConceptualIntegrity
must be created Process Dimension Deployment Dimension Logical Dimension External Dimension Implementation Dimension Solu%on Vision Classes, Modules, Design Components, Interfaces, Interac%ons So:ware Mechanisms Use Cases / User Stories UX Guidelines Run%me Processes, Threads Protocols, Inter-‐process Communica%on, Integra%ons Implementa%on Structure and Components Frameworks, Libraries Base Technologies, Programming Languages So:ware Mechanisms Infrastructure, Hardware and Network Topology Data Dimension Environment Dimension Environments Tools Development Process, Methods and Prac%ces Data En%%es Data Messages Logical Physical *STRUCTURE and BEHAVIOUR
each part/element is narrowed focused in its primary task Low Coupling each part is self-‐contained/orthogonal achieved thru separaFon of concerns and encapsulaFon Conceptual Integrity there is a consistent design* and style across all so(ware dimensions (*) programming is design Source: “The Art in Computer Programming”, By Andrew Hunt and David Thomas
is the set of significant decisions and their implementa(on in the 7 realizaFon dimensions of the so(ware system considering structure and behaviour dimensions in each one with the purpose of achieving conceptual integrity, low coupling and high cohesion
soluFons to common problems: persistence, IPC, … System Skeleton (interfaces, base components, deployment mechanisms ) Prototypes, Reference soluFons and Proof of Concepts (soluFons to significant user stories or technical problems) Base frameworks and technologies Base Guidelines and Styles …
• Keeps Conceptual Integrity and Unity across the system and teams, while limiFng complexity • Retains the final say in technical disputes or arguments within the team(s) Small teams with resonant minds could not need an specific tech leader
Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Initial team Agile Project Kickoff Management team Architecture team time Initial project team Prototyping team I1 I2 I3 Feature 1 Team Feature2 Team Infraestructure Team I4 I5 Prototyping team • IntenFonal harmony (architecture) is explicitly idenFfied and then implemented • Accidental harmony (architecture) emerges from the mulFtude of individual design decisions that occur during development, only a(er which can we name that architecture Process Dimension Deployment ( Dimension Logical( (Dimension External Dimension Implementation Dimension Classes,'Modules,'Design'' Components,'Interfaces Use'Cases'/'User'Stories' UX'Guidelines' Run=me'Processes,'Threads'' Protocols,''InterAprocess' Communica=on' Implementa=on'Structure' and'Components' Frameworks,'Libraries' Base'Technologies,' Programming'Languages Infrastructure,'Hardware'and' Network'Topology' Data Dimension Environment Dimension Environments' Tools' Development'Process,' Methods'and'Prac=ces' Data'En==es' Data'Messages' INTENTIONAL EMERGENT GROWING
Architecture=Harmony is created as set of subopFmal design decisions that can be re-‐factor later on SP1 SP2 SP3 SP4 SP5 SP6 SP7 SP8 Sprint0 SP9 Building the Harmony Using Building ….. Using IntenFonal Emergent IntenFonal Emergent
_rubengb
suzukihoge
tasshi
afilina
manfredsteyer
little_rubyist
oniak3ibm
.png){kind=avatar}
yuriko1211
javiergs
watanave
tkikuc
ysk8hori
seike460
kastner
scottboms
holman
swwweet
akosma
ammeep
ufuk
lara
samanthasiow
rasmusluckow
shlominoach
mongodb
![About So(ware Architecture Ruben Gonzalez Blanco [email protected]](https://files.speakerdeck.com/presentations/e98c05202a0b0132c5354231f97fa3b9/slide_0.jpg){kind=link}
