CSC3003S ASD-2

WEEK- 1
4 major principles of Object Oriented Programming
• Inheritance -Deriving subclasses from a super class in order to inherit the methods and
shared attributes
• Polymorphism -The ability of a method to have more than one form
▪ Static polymorphism by overloading
▪ Dynamic Polymorphism by overriding
• Encapsulation - Keeping data and methods of an object together including getters and
setters to ensure information hiding
• Data Abstraction - Hiding low level details to reduce complexity

SOLID Design principles

1. Single Responsibility Principle (SRP):
A class should have only one reason to change, meaning it should have only one job or
responsibility. This principle ensures that a class is focused on a single task, making it easier
to maintain, test, and understand.
2. Open Closed Principle (OCP):
Software entities such as classes, modules, and functions should be open for extension but
closed for modification. This means that you should be able to extend the behavior of a class
without modifying its existing code. Instead of changing a component like a class or interface
that doesn’t quite fit your needs, create a subtype and extend it to add the necessary
functionality. This encourages the use of inheritance and polymorphism.
3. Liskov Substitution Principle (LSP):
Subtypes must be substitutable for their base types without altering the correctness
of the program. This principle ensures that derived classes extend base classes
without changing their behavior. For example, given a base class like Assessment,
subclasses like PromotionAssessment and StaffAssessment should be able to
substitute Assessment without affecting the correctness of the program. A real-world
example is that an Executive should be substitutable for a SalariedEmployee.
4. Interface Segregation Principle (ISP):
No client should be forced to depend on methods it does not use. It’s better to have many
small, specific interfaces rather than a large, general-purpose one. For example, with Coffee
Machines, EspressoMachine and FilterCoffeeMachine should extend from a common
CoffeeMachine interface but be independent of each other. More complex classes like
VersatileCoffeeMaker might implement multiple interfaces but should not be forced to
implement methods it doesn’t need. The document also touches on modeling multiple
inheritance by using interfaces to capture similarities among unrelated classes.
5. Dependency Inversion Principle (DIP):
High-level modules should not depend on low-level modules. Both should depend on
abstractions, such as interfaces or abstract classes, reducing the coupling between
components. For example, in a layered architecture, like a Burger ordering system, the
higher level module (how to build the burger) relies on interfaces, while the lower-level
module (the burger database) provides specific implementations. The principle ensures that
high-level modules, like a business logic layer, depend on abstractions rather than concrete
classes.
General Object-Oriented Principles
Interfaces versus Subclasses:
Interfaces provide loose coupling and allow multiple implementations, whereas
subclasses create tight coupling. Interfaces define methods that classes must implement,
enabling polymorphic behavior and multiple inheritance in languages like Java.
Polymorphic Behavior:
Interfaces enable classes to reveal their programming interface without revealing their
internal implementation, allowing for polymorphic behavior.
Example Scenarios:
Single Responsibility Principle:
A class should only have one job or reason to change, preventing it from becoming overly complex.
Open Closed Principle:
Instead of modifying an existing class, create a new subclass to extend
functionality.
Liskov Substitution Principle:
Subclasses should be able to replace their base class without altering the correctness of
the program.
Interface Segregation Principle:
Classes should implement only the interfaces they need, ensuring they are not burdened
with unnecessary methods.
Dependency Inversion Principle:
High-level modules should depend on abstractions rather than concrete implementations to
reduce coupling and increase flexibility.
WEEK 2
Dependable systems
Software failure is usually caused by:
• Business disruption
• Loss of trust
• Failure costs
• Information loss
• User rejection

• The cost of dependability is exponential , the greater the dependability , the greater the cost
• All aspects simply take more money and time

Socio Technical Systems

• Changes in society affect the computing system s
• The same way people and values are changing affects how people will receive it
• A new/different community means a change in the computing systems

Redundancy and Diversity

• To avoid a lot of component failures , its best to use diverse and redundant
components and testing methods
Dependable process
To ensure that a process is dependable, it should
be: • Auditable: Understandable and checkable.
• Diverse: Able to handle various situations.
• Documented: Clearly written down.
• Robust: Able to recover from failures.
• Standardized: Follows agreed-upon rules.
Software Quality
• Runtime Qualities:
◦ Availability: The system is running and accessible.
◦ Security: Protects against malicious threats.
◦ Functionality: System performs its tasks.
◦ Usability: Easy to use by end-users.
◦ Performance: System speed and efficiency.
• Non-Runtime Qualities:
◦ Reusability: Components can be reused in other systems.
◦ Portability: System can run on different environments.
◦ Integrability: Easy to integrate with other systems.
◦ Testability: Easy to test for bugs or issues.
◦ Modifiability: Can be modified with minimal effort.

Performance testing
• Load Testing checks how well the app works with normal user traffic. It helps find any slowdowns
before the app is launched.
• Stress Testing pushes the app to its limits with very heavy traffic. It shows when and where the
app breaks under pressure.
• Spike Testing checks how the app handles sudden jumps in user activity. It ensures the app can
manage sudden surges in usage.
• Soak/Endurance Testing makes sure the app can handle normal user traffic over a long time
without slowing down or crashing.
• Volume Testing adds a large amount of data to the app’s database to see how it performs with
lots of information. Database is populated .
Availability and Failure Metrics
•MTBF (Mean Time Between Failures): The average time the system works without failing.
Higher MTBF = More reliable.
• MTTR (Mean Time to Repair): How long it takes to fix a system after it fails. Lower MTTR
= Faster recovery.
• MTTF (Mean Time to Failure): Time before the system completely fails (for systems that
cannot be repaired).
Software Lifecycle Stages
• Design: Planning and creating the system’s structure.
• Development: Writing code and building the system.
• Testing: Checking for bugs, vulnerabilities, or issues.
 • Change Management: Handling updates, improvements, or repairs to the system.

Software team structure:

• Product Owner: Decides what the software should do and makes sure it meets user
needs.
• Project Manager: Keeps the project organized, on time, and ensures everything runs
smoothly.
• Developers/Engineers: Write the code to build the software and make it work.
• UX/UI Designers: Design how the software looks and how easy it is to use.
• QA Testers: Test the software to find and fix any problems before it’s released.
• DevOps Engineer: Manages the servers and helps launch the software smoothly.
• Business Analyst: Understands the business needs and turns them into tasks for the
team.
• Scrum Master (if Agile): Helps the team stay on track, solves problems, and improves the
way they work.
• Security Engineer: Ensures the software is safe and protects user data.

WEEK 3
Architectural Design
• This refers to the set of principal design decisions about the system
• A software architecture simplifies the system by focusing on key details, leaving out
unnecessary information. It provides just enough insight to support analysis, decision
making, and reducing risks.
• Also this is the key decisions about how a software system is structured, how its parts
interact, and how they are combined into larger subsystems, guided by a specific
architectural style.
• Internal implementation is not architectural
Architectural thinking
• The translation from problem domain to solution concepts
Architecture and system characteristics (MAPSS)
• Performance
• Security
• Safety
• Availability
• Maintainability
RUP "4+1" View of Architecture (Kruchten)
This model organizes architecture into five main views to address various concerns and
ensure that all stakeholders' perspectives are considered. The 4+1 model includes:
1. Logical View
• Focuses on the functional requirements of the system.
• Typically represented by Communication Diagrams.
 • Deals with how the system's components communicate and interact.
2. Development View
• Looks at the system from a programmer's perspective.
• Depicted using Component & Package Diagrams.
• Organizes the system into modules and shows the dependencies among them.
3. Process View
• Deals with the dynamic aspects of the system, such as concurrency, performance, and
scalability.
• Represented through Activity Diagrams.
• Focuses on how processes communicate and how the system behaves during
execution.
4. Physical (Deployment) View
• Shows how the system is deployed in the physical environment.( Maps to hardware)
• Illustrated by Deployment Diagrams.
• Details where the software runs on hardware and how different hardware components
communicate.
5. Scenarios (Use Cases, User Stories)
• Represents how the system interacts with its environment or users.
• Use cases and user stories are used to validate the architecture against its
requirements.
Type and Lollipop
1. «type» Stereotype: In UML, when you see the word "«type»," it means the class is an
interface or a virtual class. Interfaces are like blueprints for a class, specifying what
functions or methods must be implemented without detailing how they should work.
2. Lollipop Notation: Instead of drawing the full interface class in a diagram, UML lets us
use a "lollipop" symbol (a small circle on a stick) to represent that an interface is
being implemented by a class. This makes the diagram simpler.
• In short, a lollipop means that a class uses or implements an interface, without
showing the detailed connections or full structure of the interface class itself. It's just
a visual shortcut.

WEEK 4
Architecture Patterns Overview
1. Model-View-Controller (MVC):
• Model: Manages the data and logic of the application.
• View: Displays data to the user in a specific format.
• Controller: Manages user input and updates the model and view accordingly.
• Example: A temperature app with two views (Fahrenheit and Celsius) that updates both
views when one changes.
2. Layered Architecture:
• Organizes software into layers that handle specific aspects (UI, Business Logic,
Services). • UI Layer: Handles user interaction (e.g., web pages).
• Application Layer: Manages business rules, workflows.
• Service Layer: Provides high-level services like persistence and logging.
• Foundation: Includes low-level technical utilities like data structures and networking.
• Benefits: Easier to understand, replace, and modify.
3. Client-Server Architecture:
• Client: Requests services.
• Server: Provides services.
• Often used in web services where a client interacts with a server to fetch data.
4. Repository Architecture:
• Used for data-heavy systems where data is stored in a central repository.
• Example: Blackboard pattern where different agents access the same repository to perform
tasks.
5. Pipe and Filter Architecture:
• Data is passed through multiple stages (pipes) and transformed at each stage (filters).
• Example: Processing a burger where each step (adding bun, patty, toppings) represents a
filter.
Additional Concepts:
• System Architecture vs. Design:
◦ Architecture: High-level structure and skeleton of the system.
◦ Design: Focuses on lower-level details, like how the code is structured.
• Key Principles:
◦ Cohesion: High communication within modules.
◦ Coupling: Low communication between modules (aim to minimize it).

LAST WEEK
1. Component-Based Software Engineering (CBSE)
• Background: Traditional object-oriented approaches failed to support effective reuse
because developers needed to know too many details about the classes, including the
source code.
• Solution: Components provide abstraction at a higher level. Components are stand-alone
service providers that are bigger than single classes and hide their implementation.
• Characteristics of Components:
◦ Composable: Interact through publicly defined interfaces.
◦ Deployable: Can be self-contained and operate on a platform that implements the
component model.
◦ Documented: Fully documented to help users understand if the component meets their
needs.
◦ Independent: Can be composed and deployed without specific dependencies.
◦ Standardized: Conform to a standard component model, including metadata,
documentation, and deployment guidelines.
2. Introduction to Service-Oriented Architecture (SOA)
• Definition: SOA is an architectural pattern that designs software systems based on loosely
coupled, reusable service components that encapsulate specific business or operational
procedures. Services can represent business functions and are accessible through protocols
like REST or SOAP.
• Key Advantages of SOA:
◦ Scalable & Flexible: Easy to add or drop services over time, enabling scalability and
adaptability.
◦ Fault Tolerance & Redundancy: Allows for robust systems by adding redundancy and
diverse services.
3. Web Services and Service Independence
• Web Services: Defined as reusable software components that can be distributed and
accessed over the internet using standard protocols (e.g., XML).
• Service vs. Component:
◦ Services are independent and do not rely on a 'requires' interface, unlike components.
◦ Communication relies on message-based exchanges.
4. Service-Oriented Software Engineering
• Need for Evolution: Traditional software engineering approaches have to evolve to align
with service-oriented principles.
• Service Engineering: Developing dependable, reusable services that can be used across
different systems. This involves:
◦ Developing for Reuse: Creating services intended for use across various applications.
◦ Developing with Reuse: Building software using existing services as core
components.
5. Service-Oriented Architectures (SOA)
• Principles: Building distributed systems using stand-alone services that can execute on
different computers provided by various providers.
• Key Protocols for Service Communication:
◦ SOAP (Simple Object Access Protocol): A message exchange
protocol.
◦ WSDL (Web Service Description Language): Defines service
interfaces.
◦ WS-BPEL: A workflow language for service composition.
6. Services as Reusable Components
• Definition of a Service: A loosely coupled, reusable software component that can be
distributed and accessed programmatically.
• Platform Independence: Services are platform and language-independent, focusing on
providing a 'provides' interface without requiring dependency declarations.
7. Examples and Use Cases of SOA
• In-Car Information System: A service-based system providing drivers with information
(e.g., weather, traffic) linked to GPS. The system uses service discovery to find appropriate
services.
• Key Benefits of SOA in this Case:
◦ Flexibility to bind to services based on location.
◦ Translation services allow movement across regions.
8. Key Standards and Technologies in SOA
• SOAP: Supports communication between services.
 • WSDL: Specifies what operations a service supports and how it is
accessed.
• WS-BPEL: Allows defining complex service compositions.
9. RESTful Web Services
• REST (Representational State Transfer): A simpler architectural style that focuses on
transferring resource representations from server to client.
• Characteristics:
◦ Stateless Communication: Each request contains all necessary
information. ◦ Lower Overhead: Efficient and suitable for mobile applications.
◦ Uses Standard HTTP Methods: GET, POST, PUT, DELETE.
10. Pro and Cons of RESTful
Approach
• Advantages:
◦ Simple and easy to implement.
◦ Lower overhead compared to SOAP.
• Disadvantages:
◦ Designing complex services can be challenging.
◦ Lack of formal standards for describing interfaces.
11. Service Engineering and Development
Process
• Stages of Service Engineering:
1. Service Candidate Identification: Understanding business processes to identify
potential services.
2. Service Design: Defining logical interfaces and service interactions.
3. Implementation & Deployment: Developing, testing, and deploying the services.
12. Task and Entity-Oriented Services
• Task-Oriented Services: Linked to specific activities.
• Entity-Oriented Services: Similar to objects, linked to business entities (e.g., forms).
• Classification of Services: Utility, Business, and Coordination services.
13. Service Interface Design
• Design Considerations:
◦ Minimize the number of messages exchanged.
◦ Include service state information in messages if necessary.
◦ Design logical interfaces, specifying operation names and parameters.
14. Service Composition and Workflows
• Service Composition: Combining existing services to create new applications.
• Workflow Design: Creating logical sequences of activities to implement coherent business
processes.
15. Microservices Architecture
• Comparison to SOA: Microservices are more fine-grained, reducing dependencies. They
emphasize “share-as-little-as-possible,” while SOA promotes “share-as-much-as possible.”
• Advantages of Microservices:
◦ Easy deployment and scaling.
◦ Quick to develop and deploy.
◦ Better suited for smaller, well-defined tasks.
16. SOA vs. Microservices
• SOA: Ideal for complex, enterprise-wide systems requiring integration with various
applications and services.
• Microservices: Suitable for smaller systems, enabling agility and fast deployments without
heavy dependencies.
17. Use Cases for Microservices
• Best for smaller web-based applications and systems that require quick deployment,
scalability, and independent functionality.
18. Service Testing Challenges
• Testing Issues:
◦ Services are black boxes, so internal source-based testing methods cannot be used.
◦ External service modifications can invalidate previous tests.
◦ Dynamic binding and unpredictable non-functional behavior complicate testing.
19. Deployment and Management
• Service Deployment: Services are made available by publicizing their details, enabling
service discovery and binding.
• Legacy Systems: SOA allows integration with legacy systems, offering a modern interface
for existing functionalities.
20. Conclusion and Key Takeaways
• SOA & Microservices Evolution: Both are essential for modern software development,
offering reusable, scalable, and flexible solutions.
• Choosing the Right Approach: The choice between SOA and microservices depends on
the scale, complexity, and specific needs of the system being developed.

1. Application Architecture Patterns

• Definition: Application architectures define the common structures for specific types of
software systems. These architectures are adaptable to meet particular organizational
needs.
• Benefits:
◦ Serve as a starting point for architectural design.
◦ Act as a checklist for design elements.
◦ Organize development work.
◦ Aid in assessing reusable components.
◦ Provide a common vocabulary for discussing application types.
2. Types of Application Architectures
• Data Processing Systems:
◦ Purpose: Process data in batches without user intervention.
◦ Examples: Billing systems, payroll systems.
 ◦ Components: Typically include input, process, and output components that validate,
compute, and format data, respectively.
• Transaction Processing Systems:
◦ Purpose: Manage user requests for database information or updates in a transactional
manner.
◦ User Perspective: Transactions involve sequences of operations meeting a specific
goal, e.g., checking flight times.
◦ Operation: Users submit asynchronous requests processed by a transaction manager.
◦ Examples: E-commerce systems, reservation systems.
• Event Processing Systems:
◦ Purpose: Execute actions based on interpreted events from the system environment.
◦ Examples: Real-time games, word processors.
◦ Structure: Often object-oriented, with components such as screens, event handlers,
and command processors.
• Language Processing Systems:
◦ Purpose: Interpret user intentions in formal languages to perform specific tasks.
◦ Examples: Compilers, command interpreters.
◦ Components: Typically include a lexical analyzer, syntax analyzer, semantic analyzer,
and code generator.
◦ Architectures:
▪ Repository Architecture: Stores information centrally for processing.
▪ Pipe and Filter Architecture: Sequentially processes data through stages (e.g.,
lexical analysis, syntax analysis).
3. Key Models and Architectural Components
• Layered Architecture: Often used in information systems where layers represent distinct
stages, such as data handling, processing, and user interaction.
• Repository Architecture: Utilized in language processing, where central storage supports
analysis and processing.
• Pipe and Filter Model: Common in compilers, where each phase (e.g., lexical analysis,
parsing) sequentially processes the input data.
4. Important Concepts
• Lexical Analysis: Converts high-level code into tokens.
• Syntax Analysis: Constructs a parse tree to ensure the syntactic validity of input.
• Semantic Analysis: Checks for logical consistency based on syntax tree and symbol
table.
• Code Generation: Transforms syntax into executable machine code.
5. Usage of Application Architecture Models
• Understanding Applications: Helps in assessing system designs and reusability of
components.
• Comparing Architectures: Facilitates comparisons and evaluations of different system
designs.
• Design Validation: Aids in verifying that a system meets design requirements effectively.