Software Architecture Lecture Slides PDF

Lecture 2 SENG 401 – SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ARCHITECTURE Dr. Ronnie de Souza Santos https://www.drdesouzasantos.ca/ SOFTWARE CRISIS & L A PERIOD IN THE HISTORY OF SOFTWAR...

Lecture 2 SENG 401 – SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ARCHITECTURE Dr. Ronnie de Souza Santos https://www.drdesouzasantos.ca/ SOFTWARE CRISIS & L A PERIOD IN THE HISTORY OF SOFTWARE DEVELOPMENT WHEN THE INDUSTRY FACED SIGNIFICANT CHALLENGES AND DIFFICULTIES IN CREATING AND MAINTAINING SOFTWARE SYSTEMS 1940 1970 1950 Today SOFTWARE ENGINEERING 1960-1970  SOFTWARE DEVELOPMENT Define : A SYSTEMATIC PROCESS THAT OUTLINES THE PHASES THAT A SOFTWARE PROJECT GOES THROUGH FROM ITS INITIATION TO ITS COMPLETION AND STRUCTURED COMMUNICATION MAINTENANCE. MOTIVATION Produce software that meets or exceeds customer expectations. MANAGEMENT  SOFTWARE DEVELOPMENT CORE TASKS ANALYSIS DESIGN CONSTRUCTION TESTING DELIVERY Core tasks · Analysis · Design Construction · testing · · delivery a MANAGEMENT SOFTWARE DEVELOPMENT CORE TASKS  & SOFTWARE ARCHITECTURE O The high-level structure of a software system, defining its components and their interactions, setting the foundation for both the design and the implementation phases of software development. ANALYSIS DESIGN What is the problem? How to fix the problem? THE ROLE OF SOFTWARE ARCHITECTURE · Long-term impacts on cost and quality since architecture decisions can influence the ease of future modifications and helps in managing complexity, especially in large systems. MOTIVATION PLANNING AND DESIGN BEHIND ARCHITECTURES HOW DIFFERENT PARTS OF THE CAN BE BAD! PROGRAM WORK TOGETHER, ENSURING THEY FUNCTION WELL. REFERENCE ARCHITECTURE WHAT FACTORS INFLUENCE A reference architecture is the set of THE DEVELOPMENT OF principal decisions that are SYSTEMS TODAY? simultaneously applicable to multiple related systems, typically within an application domain, with explicitly defined points of variation. apT Standardized guidelines and proven solutions for efficient, consistent, and reliable system architecture. DESIGN DECISIONS DESIGN DECISIONS ARE CHOICES WHAT KIND OF DECISIONS DO WE MADE DURING THE CREATION OR HAVE TO MAKE? PLANNING PHASE OF A SYSTEM. STRUCTURE BEHAVIOUR APPROACHES METHODS TECHNOLOGIES CONFIGURATIONS INTERACTION DESIGN DECISIONS PRINCIPAL TEMPORAL Critical or fundamental choices that Choices made/unmade over time influences the overall architecture, involve aspects related to periods functionality, or behavior of a system. within a system. TECHNOLOGIES DATA INTERFACE DESIGN DECISIONS: BANKING APP PRINCIPAL TEMPORAL OS BIOMETRICS PUSH ENGAGE OPTIMIZATION CLOUD STAKEHOLDERS WHO ARE THE STAKEHOLDERS OF SOFTWARE ARCHITECTURE? INDIVIDUALS OR GROUPS INTEREST IN, OR IMPACTED BY, THE DEVELOPMENT, DEPLOYMENT, OR UTILIZATION OF A SOFTWARE SYSTEM ARCHITECTS DEVELOPERS TESTERS ARCHITECTURE AND DESIGN. MANAGERS CLIENTS USERS DID YOU KNOW? SOFTWARE ENGINEERING MARGARET HAMILTON COINED THE TERM "SOFTWARE ENGINEERING" IN THE 1960S WHILE LEADING NASA'S TEAM THAT DEVELOPED THE APOLLO MISSION'S FLIGHT SOFTWARE. SHE INTRODUCED THE TERM TO EMPHASIZE THE RIGOROUS, SYSTEMATIC APPROACH NEEDED FOR SOFTWARE DEVELOPMENT, WHICH WAS THEN VIEWED AS LESS FORMAL THAN HARDWARE ENGINEERING. REQUIREMENTS ENGINEERING THE PROCESS OF GATHERING, DOCUMENTING, ANALYZING, PRIORITIZING, VALIDATING, AND MANAGING REQUIREMENTS THROUGHOUT THE PROJECT STAKEHOLDER NEEDS REDUCED RISKS LIFECYCLE MOTIVATION Ensures that a project delivers the desired outcomes, meets stakeholder needs, and aligns with organizational goals. CHANGE MANAGEMENT WHY DO WE CARE ABOUT REQUIREMENTS? WHAT HOW WHO COST TIME WHY DO REQUIREMENTS MATTER? TYPES OF REQUIREMENTS SOFTWARE REQUIREMENTS ARE SPECIFICATIONS THAT DEFINE WHAT A SOFTWARE SYSTEM SHOULD ACCOMPLISH AND HOW IT SHOULD BEHAVE. FUNCTIONAL NON-FUNCTIONAL MOTIVATION Ensures the foundation for designing, building, and testing software solutions. DOMAIN BASIC REQUIREMENTS FUNCTIONAL: DESCRIBE THE NON-FUNCTIONAL: DESCRIBE THE SPECIFIC TASKS AND BEHAVIORS AND FUNCTIONALITIES THAT THE CHARACTERISTICS THAT THE SOFTWARE SYSTEM MUST PERFORM. SOFTWARE MUST POSSESS.  NON-FUNCTIONAL REQUIREMENTS Ch Non-Functional Description Example Performance Specifies how quickly the system should respond or process tasks. The system should process 1,000 transactions per second. Scalability Defines the system's ability to handle increasing loads without performance The system should handle 10,000 concurrent users without degradation. degradation. Usability Focuses on the system's ease of use and learning curve for end users. The user interface should be intuitive and require minimal training. Security Ensures that the system is protected from unauthorized access or attacks. All data should be encrypted using AES-256 encryption. Reliability Specifies the system’s ability to perform consistently under expected The system should have 99.9% uptime. conditions. Availability Indicates how often the system should be available for use without The system should be available 24/7 with no more than 1 hour of downtime. downtime per year. Maintainability Describes the ease with which the system can be modified or updated. The system should be able to update features without downtime. Portability Ensures that the system can be easily moved or adapted to different The system should run on both Windows and Linux platforms. environments. Accessibility Focuses on making the system usable for people with disabilities (e.g., The website should support screen readers for visually impaired screen reader compatibility). users. Compliance Ensures that the system complies with laws and regulations (e.g., GDPR). The system must comply with the GDPR for data protection. Interoperability Describes how well the system interacts with other systems or components. The system should integrate with third-party payment gateways. Ethics Ensures that the system adheres to ethical standards (e.g., fairness, The system should ensure fairness in route suggestions without bias. transparency). REQUIREMENTS - EXAMPLES NON- FUNCTIONAL FUNCTIONAL 1. Create a profile 1. New profile is 2. Login into the system confirmed via SMS. 3. Add a photo to the 2. Login need email, profile password and 4. Send message to validation. contact 3. Photo is up to 2GB. 5. Delete profile 4. Message is 250 characters long. 5. Deleting profile is confirmed via call. REQUIREMENTS SPECIFICATION USER STORIES: SHORT AND SIMPLE USE CASES: A METHODOLOGY DESCRIPTIONS OF A FEATURE TOLD USED IN SYSTEM ANALYSIS TO FROM THE PERSPECTIVE OF THE IDENTIFY, CLARIFY, AND ORGANIZE PERSON WHO WILL USE IT. SYSTEM REQUIREMENTS. USER STORIES USER STORIES Informal, natural As a person I want to send language description of messages so that I can features of a software, interact with my contacts. written by or for users or customers to influence the functionality of the system being As a VIP user I want to back up developed. all of my messages so that I restore them whenever I need. USE CASE Users can use the system to send USE CASE messages and interact with contacts. Information Description A use case is a list of actions Precondition The user must be logged to send messages or event steps typically Actor User defining the interactions Main Scenario 1. From the home screen press the between a user (referred as option message actor) and the system 2. Select a contact. 3. Write the message and press send. actions (referred as use 4. Receive the confirmation status, e.g., case) using the Unified sending, sent, received. Modeling Language (UML). Alternative Scenario 1. 1. From the home screen press the option message 2. Select a contact. 3. Write the message and press cancel. 4. The system returns to the home screen. GOOD REQUIREMENTS UNAMBIGUOUS COMPLETE COHERENT VERIFIABLE FEASIBLE PRIORITIZABLE VALIDABLE REQUIREMENTS PRIORITIZATION MoScoW ?? QUESTIONS? LET’S PRACTICE: FUNCTIONAL OR NON- FUNCTIONAL? The app should allow users to search for products by name, category, or keywords. The app should load product pages in under 3 seconds, even during peak traffic times. Users should be able to register and log in using their email or social media accounts. The app must support multiple languages for global users. Users should have the ability to add items to a shopping cart and update quantities. The app must be available on both iOS and Android platforms. The user interface should be intuitive, requiring no more than 3 clicks to complete a purchase. The app must provide real-time order tracking after purchase. All user data, including payment information, should be encrypted using industry-standard methods. The system should have automatic daily backups with the ability to recover data within 30 minutes. Users should be able to create wish lists for future purchases. The app should be optimized for mobile devices with a responsive design on all screen sizes. The app should support users submitting return and refund requests for eligible items. The app must comply with data privacy regulations. Admins should be able to manage product inventory and receive alerts for low-stock products. The app should support screen readers and have high-contrast modes for visually impaired users. Push notifications should alert users about new products, discounts, or order updates. The app should be able to support up to 100,000 concurrent users during major sales events.