01 Definitions.pdf

Software Architecture EN University of Oviedo English Software Architecture...

Software Architecture EN University of Oviedo English Software Architecture Basic definitions School of Computer Science 2023-24 Jose E. Labra Gayo Software Architecture University of Oviedo Contents Definitions about Software Architecture About software architecture Stakeholders Quality attributes Constraints School of Computer Science Software Architecture University of Oviedo What is architecture? Ethimologically, from greek: Architecture = ἀρχιτέκτων ἀρχι- "chief" τέκτων "creator" Architecture = Process and the product of planning, designing, and constructing buildings or other structures. School of Computer Science Software Architecture University of Oviedo Vitruvius, "De architectura" Written between 30 to 15 BC 3 pillars of good buildings Utilitas (usefulness): Be useful and function well for the people using it. Firmitas (durability): Stand up robustly and remain in good condition Venustas (elegance/beauty): It should delight people Can be applied to software systems School of Computer Science Software Architecture University of Oviedo What is software architecture? (1) Architecture [ISO/IEC/IEEE 42010:2011, 3.2] Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution Architecture description Explicit work product expressing an architecture of a system, usually via models, text and graphics. Architecting: School of Computer Science Process of creating an architecture Software Architecture University of Oviedo What is Software architecture? (2) Fundamental structures of a system......which comprise: - software elements - relations among them - properties of both. School of Computer Science Software Architecture University of Oviedo Architecture vs Design The distinction is not always clear-cut Architecture focuses more on: High level structure of a software system Significant design decisions of a system that.......if you have to change them  High cost School of Computer Science "All architecture is design but not all design is architecture" G. Booch Software Architecture University of Oviedo Buildings architecture vs software architecture Some similarities Complex systems Developed by teams/organizations Used by people Both employ styles, patterns, tactics... School of Computer Science And are affected by trends Software Architecture University of Oviedo Buildings architecture vs software architecture Some differences Buildings architecture Software architecture More stable environment Environment changes very fast Physical product/service Virtual product/service Physical limits, difficult to change No physical limits, easier to change Long tradition and history Relatively new discipline Great examples to show and we can learn a lot from others School of Computer Science Software Architecture University of Oviedo Other similar disciplines Civil engineering Mechanical engineering Aeronautics... School of Computer Science Software Architecture University of Oviedo Other architectures Business architecture Enterprise architecture Systems architecture Information architecture Data architecture... Common things about all: Structure and vision School of Computer Science Software Architecture University of Oviedo Benefits of software architecture Provide a clear vision and roadmap for the team Technical leadership and better coordination Answer questions relating to significant decisions Quality attributes, constraints and other cross-cutting concerns. Identifying and mitigating risk. Consistency of approach and standards Leading to a well structured codebase. School of Computer Science Firm foundations for the product being built. A structure to communicate the solution At different levels of abstraction to different audiences. Software Architecture University of Oviedo Challenges of software architecture Architects at the ivory tower Lack of communication Centralization of all decisions Bottleneck Taking too many decisions Deferring decisions may be better than reversing them Big design up front School of Computer Science Too much unneeded diagrams and docs Delays caused by architecting process Software Architecture University of Oviedo Agile software architecture Architecture that can react to its environment Adapting to ever changing requirements Also known as evolutionary architectures Good architecture enables agility Better understanding of trade-offs and decisions Common anti-pattern: Adopting agile software development techniques that create School of Computer Science non-agile software architectures Caused by too much focus on delivering functionality Software Architecture University of Oviedo Laws of software architecture (*) 1st law: Everything in software architecture is a trade-off Corollary 1: If an architect thinks he has found something that is not a trade-off, more likely he just haven't identified the trade-off yet Corollary 2: All meaningful decisions have downsides 2nd law: Why is more important than how School of Computer Science Question everything Document architecture decisions (*) Fundamentals of Software Architecture, M. Richards, N. Ford Software Architecture University of Oviedo Architecture design Problem domain Solution domain Design Objectives Functional requirements Architect Quality attributes Design activity Constraints School of Computer Science Concerns Design of the architecture Architecture (output) drivers (inputs) Software Architecture University of Oviedo Architeture drivers Inputs of the software architecture process Design objectives Functional requirements Quality attributes Constraints Concerns School of Computer Science Software Architecture University of Oviedo Design objectives What are the business goals? Why you are designing that software? Some examples: Pre-sales proposal: rapid design of an initial solution in order to produce an estimate Custom system with established time and costs which may not evolve much once released School of Computer Science New increment or release of a continuously evolving system Software Architecture University of Oviedo Functional requirements Functionality that supports the business goals List of requirements as use cases or user stories Use cases User stories School of Computer Science Software Architecture University of Oviedo Quality attributes Measurable features of interest to users/developers Also known as non-functional requirements Performance, availability, modifiability, testability,… Also known as -ilities Can be specified with scenarios Stimulus-response technique “If an internal failure occurs during normal operation, the system resumes operation in less than 30seconds, and no data is lost” School of Computer Science ISO 25010: list of some non-functional requirements List: https://en.wikipedia.org/wiki/List_of_system_quality_attributes Software Architecture University of Oviedo Quality attributes Quality attributes determine most architectural design decisions If the only concern is functionality, a monolithic system would suffice However, it is quite common to see: Redundancy structures to increase reliability Concurrency to increase perfomance Layers for modifiability … School of Computer Science Quality attributes must be prioritized By the client to consider system’s success By the architect to consider technical risk Software Architecture University of Oviedo Constraints Pre-specified design decisions Very little software has total freedom May be technical or organizational May originate from the customer but also from the development organization Usually limit the alternatives that can be considered for particular design decisions Examples: School of Computer Science Frameworks, programming languages, DBMS,… They can act as “friends” Identifying them can avoid pointless disagreements Software Architecture University of Oviedo Concerns Design decisions that should be made Even if they are not stated explicitly Examples: Input validation Exception management and logging Data migration and backup Code styles… School of Computer Science … Software Architecture University of Oviedo Creativity vs Method Creativity Method Fun Efficient in familiar domains Risk Predictable result Can offer new solutions Not always the best solution Can be unnecessary Proven quality techniques School of Computer Science Architect Software Architecture University of Oviedo Types of systems Greenfield systems in novel domains E.g. Google, WhatsApp,… Less well known domains, more innovative Greenfield systems in mature domains E.g. “traditional” enterprise applications, standard mobile apps Well known domain, less innovative School of Computer Science Brownfield domains Changes to existing system Software Architecture University of Oviedo Software architect Discipline evolves Architect must be aware of New development techniques Styles and patterns Best tool = experience (no silver bullet) Self experience Experience from community School of Computer Science Architect Software Architecture University of Oviedo Role of software architect Objectives Functional requirements Stakeholders Quality attributes Constraints Concerns Architecture Software Community Principles Architect School of Computer Science Patterns Experience Styles Anti-patterns Tactics Technology