Midterm-Reviewer-IT109.pdf

1. System’s architecture is a representation of a system in which there is a definition of functionality onto hardware and software components, and a concern for the human interaction with these components. 2. A structure are elements in the software or hardware. Structures are not indepen...

1. System’s architecture is a representation of a system in which there is a definition of functionality onto hardware and software components, and a concern for the human interaction with these components. 2. A structure are elements in the software or hardware. Structures are not independent. For example, a module in a decomposition structure may be manifested as one, part of one, or several components in one of the component-and- connector structures, reflecting its runtime alter ego. Three kinds of structure: i. Module – defines how the system will be organized into various code or data units that need to be built or obtained. Each module is given a specific function or responsibility, with less focus on how the software will actually run when it's being used. Structures under Module: o Decomposition – Modules are decomposed into smaller modules. Making it easier to understand. Decomposition Steps: a) Identify the Top-Level/Main Project b) Decompose the main component into its major subsystems, modules, or functional components. What are the major steps involved in completing the task? c) Continue to decompose the sub-functions and sub- processes until you reach a level of detail that is appropriate for your needs. d) Identify the inputs and outputs of each function or process. What data does each function or process need to complete its task? What data does it produce as output? o Uses – Illustrates the dependencies or "uses" relationships between modules. It shows which modules rely on the services or functionalities of other modules. o Layer – Organizes the system into layers, where each layer depends on the one below it and provides services to the one above it. o Class – often used in object-oriented systems, this structure defines the relationships between classes or objects, such as inheritance, associations, and aggregations.  Class Diagram – a class diagram in software engineering is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. Components of Class Diagram:  Upper section – contains the name of the class. This section is always required, whether you are talking about the classifier or an object.  Middle section – contains the attributes of the class. Use this section to describe the qualities of the class. This is only required when describing a specific instance of a class.  Bottom section – includes class operations (methods). Displayed in list format, each operation takes up its own line. The operations describe how a class interacts with data. Member Access Modifier All classes have different access levels depending on the access modifier (visibility). Here are the access levels with their corresponding symbols: a. Public (+), b. Private (-), c. Protected (#), d. Package (~), e. Derived (/), f. Static (underlined) Multiplicity  The number of objects for each class that will take part of the relationship:  a. Exactly one - 1 b. Zero or one - 0..1 c. Many - 0..* or * d. One or more - 1..* Relation/Interaction  Inheritance (Generalization) – represents is-a relationship. SubClass1 and SubClass2 are specializations of Super Class. A solid line with a hollow arrowhead that point from the child to the parent class.  Simple/Bidirectional Association – A structural link between two peer classes which are aware of each other and their relationship with the other. This association is represented by a straight line between two classes.  Unidirectional (One way) Association – One class is aware of the other and interacts with it. Unidirectional association is modeled with a straight connecting line that points an open arrowhead from the knowing class to the known class.  Aggregation – represents a part of relationship (Class2 is part of Class1). Many instances (denoted by the *) of Class2 can be associated with Class1. A solid line with an unfilled diamond at the association end connected to the class of composite.  Composition – A special type of aggregation where parts are destroyed when the whole is destroyed (Class2 cannot stand by itself). A solid line with a filled diamond at the association connected to the class of composite.  Dependency – Exists between two classes if the changes to the definition of one may cause changes to the other (but not the other way around). Class1 depends on Class2. A dashed line with an open arrow.  o Data Model – describes the static information structure in terms of data entities and their relationships. For example, in a banking system, entities will typically include Account, Customer, and Loan. Account has several attributes, such as account number, type (savings or checking), status, and current balance. ii. Component and Connector – defines how the system is organized into elements that perform actions during runtime (components) and how these elements interact with each other (connectors). o Runtime components are the main units that perform computations, and they can be services, peers, clients, servers, filters, or other elements that work during runtime. o Connectors are the tools that allow components to communicate with each other, such as methods like call- return, process synchronization, or pipes. Structures under Components and Connector: o Service – The units here are services that interoperate with each other by service coordination mechanisms such as SOAP (Simple Object Access Protocol). It helps to engineer a system composed of components that may have been developed anonymously and independently of each other. o Concurrency – Illustrates how components are executed concurrently, including threads, processes, and synchronization mechanisms. This structure is key for understanding how the system handles parallelism and concurrency. iii. Allocation – defines how the system will interact with non-software elements in its environment, like CPUs, file systems, networks, and development teams. Structures under Allocation: o Deployment – shows how software is assigned to hardware processing and communication elements. Relations are allocated-to, showing on which physical units the software elements reside, and migrates-to if the allocation is dynamic. o Implementation – shows how software elements (usually modules) are mapped to the file structure(s) in the system’s development, integration, or configuration control environments.  o Work Assignment – assigns responsibility for implementing and integrating the modules to the teams who will carry it out. This structure will also determine the major communication pathways among the teams: regular teleconferences, wikis, email lists, and so forth. 3. A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them. 4. Layered Architecture – independent parts of the system that each have their own distinct and specific responsibilities.  Closed architecture – can only call the next layer immediately down.  Open architecture – can call any of the layers below it. Changes in one layer does not affect the others, so each layer can be modified without potentially harmful side effects in the application Types of Layers:  Presentation Layer – external interface where user interacts. Components:  HTML/CSS  Bootstrap  Flutter  React  Angular  Application Layer – Indicate how the app functions based on the user’s interaction in the presentation layer. Components:  Application Services (i.e. OrderPaymentService, UserAuthService)  Use Cases (i.e. AddToCart, UpdateUserInfo)  Business Layer – implements the business logic and rules that determine the data exchange. It is the most independent part of the system and should be unaware of external concerns like databases or UI. Components:   Entities/Objects (i.e. Student, Customer, Product)  Domain Services (i.e. Pricing Services, Customer Services)  Business Policies (i.e. Student discounts, Customer points)  Persistence Layer – handles the actual interactions with external resources such as databases, file systems, and APIs. It is responsible for storing and retrieving data from DB. Components:  SQL CRUD ops in PHP  Object-Relational Mappers (i.e. Eloquent like Laravel, SQLAcademy)  External Service Clients (i.e. Third-party APIs, Email Services)  Database Layer – actual database that stores the data. Components:  Database Systems (i.e. PostgreSQL, Firebase)  Procedures/Triggers  Cloud Storage 5. Monolithic Architecture – single-tiered applications where multiple components are combined into a single application. These apps are tightly coupled and all the various components are modules are directly connected to each other. Components:  Single Codebase – have all the body of the source code and file into one codebase.  Tight Coupling – components are tightly integrated and interdependent.  Shared Memory Space – all parts run in the same memory and usually on one server or machine.  Single Database – uses a single database.  Layered Structure – usually have separate layers for different tasks (presentation, business logic, data access) but it can create dependencies between layers.  Inter-component Communication – all functions/components can directly call each other.   Limited Scalability – becomes harder to isolate and scale individual components independently as the app grows (i.e. traffic handling, memory allocation). Advantages:  Development and Deployment – an app built with one codebase is easier to develop and deploy.  Performance – in a centralized codebase and repository, one API can perform the same function that many APIs perform with microservices.  Simplified Testing – easier to manage and test as a single unit, simplifying deployment, monitoring, and troubleshooting processes.  Easy Debugging – straightforward debugging which simplifies logging, configuration management, monitoring, and other development concerns. Disadvantages: Scalability and Updates – devs have to rebuild and redeploy the whole app even if one part has been changed. Reliability – if there’s an error or bug in any module or component, it could affect the entire application. Barrier to technology adoption – any changes in the framework or language can be challenging and time-consuming. Slower Development and Redeployment – large monolithic apps make development more complex and slower. A small change requires redeployment of the entire app. 6. C4 Model – a diagram that uses “abstraction- first” method to create a detailed map of the code in a similar way how Google Maps works to zoom in and out of an area. This helps software dev teams to easily describe and communicate software architecture. Using all four (4) diagrams is not necessary, only those that add value. Diagram Levels: i. Context or System Context – provides starting point to outline your software system’s scope, and interactions with users and other systems. ii. Container – represents an application or a data store. It something that needs to be running in order for the whole system to work. iii. Components – are individual elements within each container. This layer is about understanding how these components interact.  iv. Codes – an optional layer where it shows how components are implemented. Provides a detailed view of the system's building blocks, showcasing the classes and interfaces that underpin the components. 7. Microservices – splits large system into smaller modules to better facilitate implementation. Each component or microservice focuses on a specific task or functionality within the app.  Originated by Ken Thompson based on the philosophical approach to minimalist, modular software development. Microservices approach is based on the philosophy of UNIX, which can be reduced to three aspects:  One program should only fulfil one task which should do really well.  Programs should be able to work together.  A universal interface should be used (which is provided by text streams in UNIX). Why Microservices?  Legacy Application – microservice can act on specific requests while leaving others to legacy system.  Time-to-Market – can be brought into production on a one-by-one basis. Each microservice can be scaled independently of other services.  Free Choice of Technologies – can test a new technology within a single microservice without affecting other services, thereby reducing the risk of a newly introduced tech.  Continuous Delivery – microservices are small and can be deployed independently of each other. It also allows different versions of microservices to run simultaneously. Challenges?  Data Management – management can be difficult as the microservice grow. The autonomy of each microservice complicates data management when multiple services need to access or share related data.  Refactoring is Difficult – improving internal structure or design of existing code could be challenging on multiple microservices that are deployed across different environments, servers, or data centres. Example: If you need to change the data model of a service, all other services consuming that data may need to be updated, making the refactoring process much more involved than in a monolith.  Domain Architecture is Important – must correctly identify bounded contexts and separate services along business domain lines. Example: If the Order Service places an order but the Payment Service fails to process the payment due to network issues, rolling back the changes and keeping the systems in sync is much more complex than in a monolithic  architecture.  Running Microservices is Complex – dealing with multiple services is complex when each of them needs to be deployed, versioned, scaled, and updated independently. Size of Microservices  Distributed Communication – microservices run within independent process; therefore, communication between them is distributed communication via the network.  Team Size – a team has to be able to implement features independently of the other teams.  Infrastructure – each microservice has to be deployed independently.  Replaceability – replacing a microservice can be sensible when it’s outdated or its code is of such a bad quality. Transactions and Consistency Transactions possess the so-called ACID characteristics:  Atomicity – indicates that a given transaction is either executed completely or not at all which, in case of an error, all changes are reversed.  Consistency – means data are consistent before and after the transaction – validations for instance are not violated.  Isolation – indicates that the operations of transactions are separated from each other.  Durability – indicates permanence which means changes to the transaction are still available after a crash. 8. Service-Oriented Architecture (SOA) – allows for independent, reusable services that interact through interfaces. It focuses on larger, coarser-grained services to reduce dependencies. Characteristics of a SOA service  A service should comprise a domain functionality and can be used independently.  Network availability.   Can be used with different programming languages and platforms.  Services have interfaces that allow communication across platforms.  Services are coarse-grained, meaning larger in scope and able to function independently. Team Structure in SOA  Different teams manage each system and portals.  A separate team manages integration and orchestration to ensure smooth communication between services. For the systems to be able to call each other there is an integration platform. This platform allows for the communication between the services. The Orchestration is responsible for coordinating the different services. The portal is responsible for providing the users with an interface for using the services. Users interact with SOA services via portals or apps (web, mobile, etc.). Difference between SOA and Microservice  SOA focuses on entire enterprise's IT. Different teams work on specific areas, such as backend services, while another team might handle the user interface (UI).  Microservices allow each team to work on both backend and frontend within a single project, which improves communication and speeds up feature development.