Introduction.pdf
Document Details
Full Transcript
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é