Week5-SoftwareArchitecture.pdf

SMU Classification: Restricted Software Project Management – IS212 Visualising Software Architecture & Code IS212 Visualising Software Architecture & Code 1 ...

SMU Classification: Restricted Software Project Management – IS212 Visualising Software Architecture & Code IS212 Visualising Software Architecture & Code 1  SMU Classification: Restricted when user stories need to be reopened: 1. when stakeholders change business requirements 2. testing fails in later sprints 3. DoD change (that means all user stories have to be re-opened and re-tested) test cases - can choose to either ss or write in words AC for indirect user stories will be diff from that of direct user stories. test cases can be written even before ur user stories are written Announcements  SMU Classification: Restricted Announcement – Start Sprinting! 🏁 If you haven’t started sprinting yet, please do so this week If you don’t, and you’re aiming for three 2-week sprints, then you will have limited buffer time before the Friday Week 12 due date The classes in Weeks 1–4 have covered the essential content on running a scrum process The remaining classes will help you to augment your process and deliver higher-quality software - Incorporate the content from the later classes into your later sprint(s) - Don’t worry about being ‘perfect’ from the start 😊 SMU Classification: Restricted Recap  SMU Classification: Restricted Week 4 Recap – Agile Testing & Test Cases How does testing fit into an agile software development process? Which tests to cover in the agile testing quadrant? How do we derive test cases from ACs? What’s a happy, negative, and boundary test? When do we write tests in scrum? IS212 Visualising Software Architecture & Code 5  SMU Classification: Restricted Week 4 Recap – Git git clone git pull git add git commit git push  SMU Classification: Restricted Today: Visualising Software Architecture & Code Objectives On completing this class, you will be able to: Explain the rationale for visualising software architecture Model the context, containers, and components of a system using the C4 notation lowest level of C4 is code level, which is OO way OR ER diagram (if u got relational db) Model object-oriented relationships in code using UML class diagrams Outline Visualising Architecture – Software architecture, C4 model, examples Visualising Code – UML class diagrams, abstraction, encapsulation, association, inheritance, polymorphism IS212 Visualising Software Architecture & Code 7  SMU Classification: Restricted Software Architecture  SMU Classification: Restricted looks good, let’s code! Developer  SMU Classification: Restricted Diving into coding… without a blueprint  SMU Classification: Restricted Diving into coding… without a blueprint “big ball of mud”  SMU Classification: Restricted Software Architecture Software architecture is the high-level structure of the system used by scrum team & possibly external parties too - Defines the major components, their relationships, and interactions - The principles guiding their design and evolution Like a “blueprint” for the system and project C4 is very simplified (fastest and easiest to represent things) - Builds a shared understanding for the team - Ensures the team understands the context of the components they build Agile projects favour code over documentation, but this doesn’t mean that there should be no documentation - We need “just enough” software architecture design - i.e. architectural models that are lightweight and accessible to different stakeholders IS212 Visualising Software Architecture & Code 12  SMU Classification: Restricted No Architecture in Mind Chaos…the result of no architecture…over decades… Winchester Mystery House by Www78. Licensed under Creative Commons Attribution-Share Alike 3.0 Unported. IS212 Visualising Software Architecture & Code 13  SMU Classification: Restricted Too Much Architecture in Mind Order…the result of architecture…but still going after more than a century… Basilica de la Sagrada Familia by Jose Ramirez. Licensed under Creative Commons Attribution-Share Alike 2.0 Generic. IS212 Visualising Software Architecture & Code 14  SMU Classification: Restricted Architecture Represents Significant Design Decisions All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. – Grady Booch, On Design, Handbook of Software Architecture blog, March 2006 IS212 Visualising Software Architecture & Code 15  SMU Classification: Restricted Examples of Significant Design Decisions Recall the software architectural patterns you encountered in other courses – these are good examples of significant design choices For examples, monolithic vs. microservices architectures: What makes this choice significant? an choose either or for project but microservice sleeker, but more complicated should keep backend as simple as possible for this project IS212 Image Source: https://www.openlegacy.com/blog/monolithic-application 16  SMU Classification: Restricted Examples of Significant Design Decisions You have also encountered architectural patterns regarding the separation of GUIs from business and backend logic For example, Model-View-Controller vs. Model-View-ViewModel IS212 Visualising Software Architecture & Code 17  SMU Classification: Restricted C4 Model a lean graphical modelling approach for software architecture notation (how arrows are drawn, what dotted lines mean etc ) is up to your team but the 4 levels of C4 need to stay  SMU Classification: Restricted C4 Model – an “abstraction-first” approach “Abstraction over notation” what exactly is abstraction? https://www.youtube.com/watch?v=x2-rSnhpw0g IS212 Visualising Software Architecture & Code 19  SMU Classification: Restricted Aside – What is Abstraction? This is abstract… but “arbitrary” - The “yellow box” notation appears to mean many things… - high level: does the app interact with anyone else? high level then u drill into the lower levels like bedroom IS212 Credit: Simon Brown, Agile on the Beach 20  SMU Classification: Restricted Aside – What is Abstraction? “The purpose of abstracting is not to be vague… …but to create a new semantic level in which one can be absolutely precise.” What do we want to be precise about in software architecture? Edsger Dijkstra IS212 Visualising Software Architecture & Code 21  SMU Classification: Restricted C4 Model (Context, Containers, Components, Code) Context (environment in which the system operates) dn to know what is inside, but need to know how my system will interact with external systems (dn to care how external systems do things, just need to know what my system System (the ‘thing’ that operates) pumps out / receives from other systems) high level blocks Containers (the ‘parts’ that make up the system) what apis we use Components (the ‘building blocks’ that make up a container) how to build things Code (inside components) IS212 Concept: Simon Brown, C4 (context, container, component, class) approach to visualising software 22  SMU Classification: Restricted C4 Model (Context, Containers, Components, Code) The C4 model is a framework for visualising the architecture of a software system via a hierarchical set of diagrams - Each diagram is at a different abstraction level, and is intended for different stakeholders - C4 diagrams are supported by draw.io (search for ‘C4’ in the shapes catalogue) * for project: C1, C2 is compulsory. C3, C4 do as what u need (not compulsory cuz our system not supposed to be very big) C1 (Context) – high-level overview of the environment the system operates in (e.g. users, other systems, external services) including external microservices C2 (Containers) – what are the major containers (applications, services, databases, …) that make up the system , frontend, microservices C3 (Component) – optional diagram showing the internal structure of a container (e.g. the structure of a single application) C4 (Code) – optional diagram visualising the implementation of a component, e.g. the classes and methods of object-oriented code IS212 Visualising Software Architecture & Code 23  SMU Classification: Restricted Running Example – Integrated Billing for Hospitals Suppose you are working for a hospital that has multiple completely separate legacy systems for different patient costs, e.g. - A legacy pharmacy billing system - A legacy ward billing system Your team is developing a modern web application that allows all of these costs to be retrieved and consolidated in a single place What might the software architecture look like in C4? Source: https://www.healthcareittoday.com/2018/05/04/medical-billing-cartoons-fun-friday/ IS212 Visualising Software Architecture & Code 24  SMU Classification: Restricted C1 (Context) Diagrams oni 1 Your system is a single box - “Zoom out” and see the big picture - Focus is on the users and (other) systems that it interacts with High level of abstraction; accessible for non-technical team members this is the only level that non-tech ppl can rlly use Scope: A single software system Primary elements: The software system in scope Supporting elements: Users (actors, roles or personas) and systems (external dependencies) that are directly connected to the software system in scope. Typically, these other systems sit outside the scope or boundary of your own software system and you do not have responsibility or ownership of them Intended audience: Everybody, both technical and non- technical, inside and outside of the software development team Recommended for most teams: Yes  SMU Classification: Restricted C2 (Container) Diagrams “Zoom in” to your system (the dotted line) mainly for technical ppl also cuz and depict the containers it’s made up of customers wont care how u build it Containers are (potentially) separately running processes that execute/store data C2 depicts the “high level shape” of the system, and major technology choices Scope: A single software system Primary elements: Containers within the software system in scope Supporting elements: People and software systems directly connected to the containers Intended audience: Technical people inside and outside of the software development team, including software architects, developers, operations and support staff Recommended for most teams: Yes each component will branch out into MULTIPLE diagrams in C3 will have a lot of this if u have a microservice architecture  SMU Classification: Restricted C3 (Component) Diagrams “Zoom in” to a container (the dotted line) and depict its internal structure for technical ppl The components are typically packaged together (e.g. a single Python/Flask application) api endpoints C3 is optional – only needed if it adds value (e.g. visualising the structure of a particularly complex container/app) Scope: A single container Primary elements: Components within the container in scope Supporting elements: Containers (within the software system in scope), people and software systems directly connected to the components Intended audience: Software architects and developers Recommended for most teams: No. Only create component diagrams if you feel they add value  SMU Classification: Restricted C4 (Code) Diagrams We can “zoom in” even further to visualise the structure of the code making up a specific component At this level, we can utilise existing notations, e.g. - Unified Modelling Language (UML) for modelling code - Entity-Relationship (ER) Diagrams for modelling relational databases Agile teams create such models more sparingly, e.g. focusing on particularly complex relations among object-oriented classes We will explore some in the second part of this class! IS212 Visualising Software Architecture & Code 28  SMU Classification: Restricted UML Class Diagrams for Object-Oriented Design – a code-level graphical notation –  SMU Classification: Restricted Visualising Code Suppose your code is object-oriented (recall IS113, IS213) Person id: int name: str title: str is a Doctor reg_num: str hourly_rate: int u can use a controller to control the number of attributes inherited but that's advanced OO for our project, not advised to do this, better to just create separate classes (otherwise will be messy) Python/Flask code A model of the code IS212 Visualising Software Architecture & Code 30  SMU Classification: Restricted Unifed Modelling Language (UML) Notations Category Diagram Usage Structural Class diagram Describes the static structure of object-oriented software. The static structure is built from classes and relationships between them. Object diagram Used to characterize a class diagram, usually represents the object combinations of a specific class diagram. Component diagram Depicts the physical organization of software assets that would provide the needed functionality. Deployment diagram Shows how the software is to deployed in production. Behavioural Use case diagram It depicts the actors, use cases and their relationships. Use cases are descriptions of system functionality. Sequence diagram Models the dynamic aspects of classes. It depicts the objects and their interactions through time-ordered messages. This is a temporal view. Collaboration diagram Essentially the same as sequence diagram, but it emphasizes the structural organization of objects. Statechart diagram Expresses the lifecycle of an object (or a system). Activity diagram Is an elaborate form of flow chart diagrams. Depicts the flow of activities in a system. IS212 Visualising Software Architecture & Code 31  SMU Classification: Restricted UML for Object-Oriented Code We will look at (UML) class diagrams, which describe the static structure of object-oriented code For instance, the attributes/methods of classes, and the relationships between objects In particular, we will use class diagrams to visualise: - Data abstraction and encapsulation - Association relationships - Inheritance and polymorphism https://www.youtube.com/watch?v=m_MQYyJpIjg IS212 Visualising Software Architecture & Code 32  SMU Classification: Restricted Data Abstraction Data abstraction is the concept of simplifying complex systems by modelling classes based on essential characteristics while hiding unnecessary details Chris Hemsworth object a1 name: ‘Chris Hemsworth’ date_of_birth: ‘1983-08-11’ abstract to… nric: ‘HEMMY1983’ a1.name == ‘Chris Hemsworth’  SMU Classification: Restricted Abstraction is Implemented through Classes Actor a class is just name: str a “template” date_of_birth: str nric: str an object is an “instance” of the template object a1 object a2 object a3 name: ‘Chris Hemsworth’ name: ‘Judi Dench’ name: ‘Maggie Smith’ date_of_birth: ‘1983-08-11’ date_of_birth: ‘1934-12-09’ date_of_birth: ‘1934-12-28’ nric: ‘HEMMY1983’ nric: ‘MB0ND007’ nric: ‘MINERVA1’  SMU Classification: Restricted Encapsulation Encapsulation is the bundling of data and functions (methods) that operate on it within the same class everything is within the object, as long as i know what the class template looks like, i will know what the object looks like. (dn to know how the methods work, just know u can call it) object a2 Actor name: ‘Judi Dench’ name: str date_of_birth: ‘1934-12-09’ attributes (data) date_of_birth: str nric: ‘MB0ND007’ nric: str get_age(): int get_age(self): … methods (functions that operate on the data) a2.get_age() == 89 Demo!  SMU Classification: Restricted Encapsulation The special method __init__ is (roughly) a “constructor” python syntax for constructor Actor name: str date_of_birth: str nric: str __init__(name: str, date_of_birth: str, nric: str) get_age(): int a4 = Actor(‘Michelle Yeoh’, ‘1962-08-06’, ‘LANGKAWI88’) a4.get_age() == 62  SMU Classification: Restricted Example – Bank Account Class Name of the class that represents the characteristics of all bank Account objects Attributes (Data) In Python, all attributes are public Account balance: float name: str overdraft_limit: int __init__(balance: float, name: str) get_interest(rate: float): float Methods (functions) In Python, all methods are public Return values __init__ is (roughly) a constructor Parameters (if any) (inputs) IS212 Visualising Software Architecture & Code 37  SMU Classification: Restricted Association Relationships In class diagrams, associations represent the connections between classes, e.g. the ways in which their objects may interact: Multiplicity – one-to-one, one-to-many, many-to-many, …? got zero to many oso - E.g. a Doctor has many Patients, but a Patient has one Doctor Directionality – is the association uni- or bidirectional? - E.g. Lesson → Classroom (one-way), Doctor ↔ Patient (mutual awareness) IS212 Visualising Software Architecture & Code 38  SMU Classification: Restricted Association Relationships Multiplicity Course Instructor 1..* A Course is taught by one or code: str name: str more Instructors taught_by Course Instructor 0..* An Instructor teachers zero or code: str teaches name: str more Courses assign_course(course: Course) take note of the syntax!! (will be tested in exam) Course Instructor 0..* 1..* (Bi-directional relationship) code: str name: str teaches taught_by assign_course(course: Course) can change according to business requirements Demo! IS212 Visualising Software Architecture & Code 39  SMU Classification: Restricted Aggregation and Composition There are two special types of association concerning “whole-part” relationships between objects: # one to many self.pets = [ ] #one to one self.pets = pet Aggregation – “x has a y”, but x and y can exist independently - E.g. “a Person has a Pet” The Person and the Pet u can create person and pet separately then u link them tgt if person dies, pet can still be alive can exist independently the relationship between them can be "removed" but the 2 can still exist independently Composition – “x consists of y”; y cannot exist independently - E.g. “the House consists of Rooms” The Room cannot exist if house is destroyed, room will also be destroyed without the House must create the house then u can create the room. room will be included as an attribute of house (and defined in house's constructor also) IS212 Visualising Software Architecture & Code 40  SMU Classification: Restricted Aggregation and Composition Demo! needs to be developed before coding Multiplicity take note of the cardinalities (see if the values returned ToolBox Tool are wrong) 0..1 0..* brand: str name: str tools size: str Aggregation (has-a) House Room 1 1..* floors: int rooms purpose: str Composition (Consists-of) IS212 41  SMU Classification: Restricted Inheritance Inheritance is a concept that allows a new class (subclass) to derive attributes/methods from an existing class (superclass) - “is-a” relationships, e.g. “a Doctor is a Person” - Allows for code reuse and the creation of hierarchical relationships a Manager is a staff and a SalesStaff is also a staff Staff but this doesn't directly to translate one name: str table each in ER diagram department: str can have 2 tables oni, 1 table date_of_joining: datetime Manager and SalesStaff base_salary: int objects ‘inherit’ the same attributes get_salary(): int and methods as Staff ==> code re-use! Demo! is a Manager SalesStaff  SMU Classification: Restricted Polymorphism Polymorphism allows for many forms of inheritance is a pre-requisite of polymorphism the same method, depending on the Staff type of the object (i.e. which class in the hierarchy it was instantiated from) name: str department: str overriding date_of_joining: datetime base_salary: int if there is a scenario where a person can be both a Manger and SalesStaff, then question urself, should ur structure still be like this? Or should Manager be a child of SalesStaff? get_salary(): int Three definitions of get_salary() Python automatically executes the correct is a one for the object’s specific type Manager SalesStaff Demo! bonus_perk: int sales_amount: int commission_rate: int if u duplicate this instance it might not be normalised? get_salary(): int get_salary(): int  SMU Classification: Restricted Putting it all Together Customer Briefing —> C4 Models —> Code  SMU Classification: Restricted Example Briefing (partial) – GP Surgery System … All charges will be handled electronically. Each patient will have an “e-wallet” that they can top up and use to spend on consultations. … During a consultation, the doctor enters details such as the diagnosis and prescription. At the end of the consultation, the details are submitted, and the patient’s e-wallet is deducted according the consultation length and the doctor’s hourly rate. … 4 parties: patient, doctor, legacy system, stripe IS212 Visualising Software Architecture & Code 45  SMU Classification: Restricted Initial C1 (Context) Diagram user stories should easily map to this Doctor Patient Create / view Top-up e-wallet consultation records … … GP Surgery External System Card payment Stripe API for top-ups NB: context diagram likely to “evolve” later as more of the brief is studied IS212 Visualising Software Architecture & Code 46  SMU Classification: Restricted Initial C2 (Container) Diagram Doctor Patient Create / view consultation records … Top-up e-wallet GP Surgery System … NB: containers can be deployed separately :80 Front-End App HTML / Vue REST APIs :3306 :5000 Card payment SQLAlchemy API App for top-ups External MySQL (ORM) Python / Flask Stripe API set of apis IS212 Visualising Software Architecture & Code 47  SMU Classification: Restricted Initial C3 (Component) Diagram Front-End App HTML / Vue API Application API API Container Calls Calls Authentication NB: components are uses uses NOT separately deployable Consultation e-Wallet Management Management this is a bit high level, u can go lower External MySQL Stripe API IS212 48  SMU Classification: Restricted Example Briefing (partial) – GP Surgery System … All charges will be handled electronically. Each patient will have an “e-wallet” that they can top up and use to spend on consultations. … During a consultation, the doctor enters details such as the diagnosis and prescription. At the end of the consultation, the details are submitted, and the patient’s e-wallet is deducted according the consultation length and the doctor’s hourly rate. … Bold noun = candidate “domain class” or attribute IS212 Visualising Software Architecture & Code 49  SMU Classification: Restricted As a User Story? As a doctor, I want to create a consultation record so that the patient’s diagnosis / prescription are captured and charges are deducted Ensure that the doctor can: Select a registered patient by name Pink = better as an attribute? Select the consulting doctor Enter the diagnosis and prescription Enter the appointment length in minutes do u need a class for this thing? (we decide): Create a consultation record and deduct charges - got impt attributes in the class - what methods u need to call from this class? Only create a record if patient’s e-wallet balance is sufficient IS212 Visualising Software Architecture & Code 50  SMU Classification: Restricted Possible Class Diagram? Person in project, keep it as simple as possible. dun create inheritance for the sake of it name: str title: str (i.e. within the Consultation inheritance is a Management Component) Doctor Patient Demo! reg_num: str contact_num: str hourly_rate: int ewallet_balance: str calculate_charges(mins: int): int ewallet_withdraw(amt: int): str 1 doctor_id 1 patient_id NB: if using Flask-SQLAlchemy, “data access objects” are NOT association required (it uses the ORM instead) If using PHP, you may need them ConsultationRecord (e.g. a PersonDAO class) diagnosis: str C4 diagram DOESNT show deployment, just show design architecture prescription: str charge: int IS212  SMU Classification: Restricted Reminder – Reflections Please start filling in your weekly reflections now Complete them by two days after this class so that we have time to read them before we next meet ☺ https://smu.sg/is212-reflections-2024-t1  SMU Classification: Restricted Exercise Try sketching the C1 (Context) and C2 (Container) diagrams for your IS212 project Try modelling any interesting class relationships implied by this year’s IS212 Customer Briefing (Feel free to use our Python/Flask application as a template) IS212 Visualising Software Architecture & Code 53