Introduction.pdf

Introduction to Software Architecture and Design © S. Somé  The need for design Would you build without blueprints ? © S. Somé  Potential consequence.. © S. Somé  Why Design? Mitigate Risks © S. Somé ...

Introduction to Software Architecture and Design © S. Somé  The need for design Would you build without blueprints ? © S. Somé  Potential consequence.. © S. Somé  Why Design? Mitigate Risks © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high- quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high- quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high- quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high-quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high-quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high-quality software systems within cost, time, and other constraints © S. Somé  Software Engineering Solving customers problems, in teams, by the systematic development and evolution of large, high- quality software systems within cost, time, and other constraints © S. Somé  Key Risks understanding problems large systems ensuring qualities team work evolution of systems © S. Somé  Design Is.. “The creative process of transforming a problem into a solution” © S. Somé  IEEE Definition Software Design is... “The process of defining the architecture, components, interfaces, and other characteristics of a system or component" and "the result of [that] process.” IEEE610.12-90 © S. Somé  Design Provides “tools” to help Build the right software for its purpose Cope with complexity Ensure software evolution... © S. Somé  Design... Produces abstract representations, that help Cope with complexity Evaluate construction alternatives Assess requirements satisfaction Assess feasibility © S. Somé  Need to know what to design for – The Problem © S. Somé  How is the problem described? As a Customer I want to be able to list books by category As an Administrator I want to be able to add books to the Store by specifying relevant information © S. Somé  Use Cases A Customer wants to browse books in order to eventually select for purchase Use case name: Browse Catalog Actor: Customer Precondition: Customer is visiting the Bookstore main page Steps: 1.The Customer selects to browse the bookstore catalog 2.The System asks for search criteria 3.The Customer specifies search criteria 4.The System lists all the books satisfying the criteria Alternatives A1. Occurs at step 3 if no books corresponding to the criteria is found 1. The System displays a message notifying the Customer and asking to specify another search criteria 2.... © S. Somé  Non Functional Requirements The Online Bookstore application shall ensure the confidentiality of Customer's data The Online Bookstore shall be implemented in the Java platform © S. Somé  Specifications change however.. © S. Somé  Lehman's laws of evolution A software system becomes progressively less satisfying to its users over time, unless it is continually adapted to meet new needs A software system becomes progressively more complex over time, unless explicit work is done to reduce its complexity © S. Somé  Evolution Cost per line of code over time (R. Martins) © S. Somé  Evolution Productivity per Release (R. Martins) Design needed to support “smooth” evolution © S. Somé  Software Design Process Solution Postulation Solution Representation Solution Elaboration © S. Somé  Postulation Problem (Requirements, Constraints,..) alt1 Diversification alt2 Convergence enumeration of choice of the alternative alternatives altn that better satisfies requirements © S. Somé  System Context Higher-level view of the system Context Diagram Shows system in context System as “black-box” Environment of system Data-flows between environment and system © S. Somé  Context Diagram Email System sends email System notifications to Users notification Client access through emails Browser users’ registration Users’ requests Registrar Course Registration requests System UI Device Workstations registration System information system’s responses classroom To check students’ availability availability registration status requests data Information about Classroom classrooms Management System © S. Somé  Design Strategies Decompositional Compositional Template-based © S. Somé  Design Strategies Decompositional PROBLEM © S. Somé  Design Strategies Decompositional PROBLEM © S. Somé  Design Strategies Compositional PROBLEM © S. Somé  Design Strategies Compositional PROBLEM © S. Somé  Design Strategies Template-based PATTERN © S. Somé  The “Design” Representation of Design Decisions Code Text Modelling Language © S. Somé  Models Abstraction © S. Somé  Why Model ? Capture Ideas Decomplexify Share Validate A month of coding can save an hour of modelling – Gregor Hohpe Track © S. Somé  Architectural Design Addresses architectural significant requirements Fundamental Structure Includes multiple views Modules View Concurrency View Deployment View © S. Somé  Module View Organization as Modules and Relations Subsystems, Layers, Components, Classes,... Decomposition, Use, Inheritance,... Developers, Managers concerns Modifiability, Testability, Schedule,... Component, Package, Class Diagrams © S. Somé  Clean Architecture Modular Structure Supports evolution Protected domain Entities: generic business rules Use Cases: application business rules © S. Somé  Concurrency View Runtime view of the system Processes, Threads, Services, Peers, Clients, Servers, Peers,... Run with, Preempt,... Calls, messages, events, shared memory,... Integrators, Operators Integrity, Fault-tolerance, Performance,... Component, Interaction, Activity Diagrams © S. Somé  Deployment View Topology and Deployment Physical/Virtual Nodes Physical/Virtual Links System Engineers, Operators Availability, Reliability, Performance, Scalability,... Deployment Diagrams © S. Somé  How much design? Big Design Up Front (BDUF) + Issues found before implementation - Commits too early - Produces heavy documentation © S. Somé  How much design? Emergent Design + Simpler, Just enough design + Adapts to changing requirements - Technical debt © S. Somé  Technical Debt The implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time Cost for deferred proper design Refactoring cost © S. Somé  How much design? Rough Up-Front Design (RUFD) + Avoids issues with BDUF and Emergent Design - Based on good requirements prioritization © S. Somé Not all requirements can be known before the design Assumption: we know “enough of the” requirements for the problem at hand © S. Somé