**Architecture**

Architecture involves managing different perspectives of a complex system to support its

visualization, specification, construction, and documentation throughout its life cycle. Different
stakeholders—such as end users, analysts, developers, system integrators, testers, technical writers,
and project managers—each have unique viewpoints and requirements. A system's architecture is
essential for managing these diverse viewpoints and guiding iterative and incremental development.

Architecture encompasses:
- **The organization of a software system**
- **The selection of structural elements and their interfaces**
- **The behavior of these elements in collaboration**
- **The composition into progressively larger subsystems**
- **The architectural style guiding organization, interfaces, collaborations, and composition**

Software architecture addresses not only structure and behavior but also usage, functionality,
performance, resilience, reuse, comprehensibility, constraints, trade-offs, and aesthetic concerns.

The 5 Interlocking Views of Architecture

1. Use Case View
This view describes the system's behavior from the perspective of end users, analysts, and
testers. It highlights the forces shaping the system's architecture. Static aspects are captured
in use case diagrams, while dynamic aspects are shown in interaction diagrams, statechart
diagrams, and activity diagrams.
2. Design View
This view focuses on the classes, interfaces, and collaborations forming the problem and
solution vocabulary, primarily supporting functional requirements. Static aspects are
depicted in class diagrams and object diagrams, while dynamic aspects are captured in
interaction diagrams, statechart diagrams, and activity diagrams.
 3. Process View
This view addresses the system's concurrency and synchronization mechanisms, focusing on
performance, scalability, and throughput. Both static and dynamic aspects are depicted using
diagrams similar to the design view, but with emphasis on active classes representing threads
and processes.
4. Implementation View
This view deals with the components and files used to assemble and release the physical
system, focusing on configuration management. Static aspects are shown in component
diagrams, while dynamic aspects are illustrated in interaction diagrams, statechart diagrams,
and activity diagrams.
5. Deployment View
This view covers the hardware topology on which the system operates, addressing
distribution, delivery, and installation. Static aspects are captured in deployment diagrams,
and dynamic aspects are represented in interaction diagrams, statechart diagrams, and
activity diagrams.
------------------------------------------------------------------------------------------------------------------------

Software Development Life Cycle

The software development life cycle (SDLC) is a process for developing software that is structured
around distinct phases, each with its own objectives, artifacts, and milestones. The Rational Unified
Process (RUP) and the Unified Software Development Process emphasize an approach that is use
case driven, architecture-centric, and iterative and incremental.
• Use case driven: Use cases serve as the primary artifact for defining system behavior,
verifying and validating architecture, testing, and facilitating communication between
stakeholders.
• Architecture-centric: The system's architecture is central to conceptualizing, constructing,
managing, and evolving the software.
• Iterative and incremental: This approach involves continuous integration, with each new
release focusing on reducing risks and making incremental improvements.
The SDLC can be broken down into four phases, which include:
1. Inception: This is the initial phase where the development idea is proposed and solidified
enough to move to the next phase. It lays the foundation for further work.
2. Elaboration: During this phase, the product vision and architecture are defined.
Requirements are prioritized and formalized, ranging from general vision statements to
specific evaluation criteria for functional and non-functional behavior.
3. Construction: The software is developed from an executable architectural baseline to a state
where it is ready to be released to the user community. During this phase, requirements are
re-evaluated based on business needs, and risks are actively mitigated.
4. Transition: The software is handed over to the user community in this phase. This phase
may include bug fixes, feature additions, and continuous improvements based on user
feedback.
A unique aspect of this process is the concept of iteration. An iteration is a defined set of activities
resulting in a release. The SDLC is thus a continuous process of executable releases of the system's
architecture, driven by a focus on architectural modeling.
----------------------------------------------------------------------------------------------------------------------
An attribute is a characteristic or property of a class that represents data that all objects in that class
share. For example, if you're modeling a class called "Wall," some attributes might be height,
width, and thickness, since every wall has these properties. Similarly, in a class called "Customer,"
attributes might include name, address, phone number, and date of birth, since every customer
has these details.
Attributes represent the kind of data that an object can hold. When you create an object from a class
(like a specific customer or wall), that object will have specific values for each attribute. For
instance, one wall might have a height of 10 feet, a width of 8 feet, and a thickness of 6 inches.
In diagrams, attributes are listed below the class name. They can be shown simply by their names,
without needing to display any specific values, just like you would label the characteristics of a
category (such as a label for all walls or customers). This helps identify the shared data of all
objects in that class without diving into specific details for each instance.
An operation is something you can do to an object of a class. It's like a task or action that every
object in that class can perform. For example, in a program, if you have a class called "Rectangle,"
you might be able to move it, resize it, or ask it for its properties like width or height. These actions
are the operations of the Rectangle class.
Every object in a class shares the same operations. So, whether you have one rectangle or ten, all of
them can be moved or resized in the same way. Sometimes, performing an operation on an object
changes its data or state. For instance, if you move a rectangle, its position changes.
In diagrams, the operations are listed below the attributes of the class (like height or width).
Usually, only the names of the operations are shown, just to indicate what actions the objects of that
class can perform.
---------------------------------------------------------------------------------------------------------------------

2nd Unit

Behavioral Diagrams
Behavioral diagrams in UML (Unified Modeling Language) are used to represent the dynamic or
changing parts of a system. They focus on how the system behaves over time, like how different
components communicate or how objects interact as the system runs. Behavioral diagrams are
important because they help visualize, specify, and document these changes and interactions.
Here are the five types of behavioral diagrams in UML:

1. Use Case Diagram

• Purpose: To represent the interactions between users (or external systems) and the system
itself.
• Explanation: A use case diagram shows the various ways users interact with the system.
Each user is called an actor, and each action or service they perform with the system is
called a use case.
 • Example: Imagine an online shopping system. The actors might be Customer and Admin.
The use cases could be Browse Items, Place Order, and Manage Inventory. The use case
diagram shows how each actor is connected to different use cases.

2. Sequence Diagram
• Purpose: To show how objects interact with each other over time, focusing on the sequence
of messages exchanged.
• Explanation: Sequence diagrams show a time-ordered series of interactions between
objects. It lays out the flow of messages (calls, signals, etc.) sent between objects as the
system runs.
• Example: In an online ordering system, a sequence diagram could show how a Customer
object sends a message to an Order object to place an order, and how the Order object
interacts with a Payment object to process the payment.

3. Collaboration Diagram
• Purpose: To emphasize the structural organization of objects that interact and send
messages to each other.
• Explanation: Similar to sequence diagrams, but collaboration diagrams focus on how
objects are linked and their relationships. The emphasis is on which objects communicate,
rather than when messages are sent.
• Example: In the same ordering system, a collaboration diagram might show the Customer,
Order, and Payment objects with links between them, representing their interaction but
without focusing on the timing.

4. Statechart Diagram
• Purpose: To show the states an object or system goes through, typically driven by events.
• Explanation: Statechart diagrams model how an object changes its state in response to
different events or conditions. They are especially useful in modeling systems that react to
user inputs or other triggers.
• Example: In a login system, a User object might move between states like Not Logged In,
Logged In, and Locked Out depending on actions like entering a password, successfully
logging in, or making too many incorrect attempts.

5. Activity Diagram
• Purpose: To depict the flow of control or data from one activity to another within the
system.
• Explanation: Activity diagrams illustrate workflows or the progression of tasks and
decisions. They are similar to flowcharts, but used specifically to model business processes
or logic in a system.
• Example: In a bank loan approval system, an activity diagram could model the process from
receiving a loan application, reviewing the applicant's credit, and either approving or
rejecting the loan based on certain conditions.
Explanation of Dependency in UML (Unified Modeling Language)
A dependency in UML is a relationship where one element, often a class, relies on or uses another
element. If the specification of the element being used changes, it may affect the element that
depends on it. However, the reverse does not necessarily happen—the dependent element doesn't
affect the used element.
Think of dependency as a "using" relationship. One class depends on another because it needs
something from that class to work, but it doesn’t control the used class.

Example in Simple Terms

Imagine you have a class called Event and another class called Window.
• Window uses Event for some purpose, like displaying a message when something happens.
• If Event changes, for example, by changing its behavior or how it sends messages, Window
may also be affected since it relies on Event to display the right message.
• However, Window changing doesn't affect Event—it’s a one-way relationship.
In UML, this is represented graphically as a dashed line with an arrow pointing to the element being
depended on (in this case, Event).

Explanation of Generalization in UML (with Simple Examples)

In UML, generalization refers to the relationship between a more general concept (called the
parent or superclass) and a more specific concept (called the child or subclass). This is an "is-a-
kind-of" relationship. The child class inherits attributes and behaviors from the parent class, but it
can also add its own specific properties or modify the inherited ones.

Real-World Analogy
Think of generalization as the relationship between animals:
• Animal is a general category (the parent class).
• Dog and Cat are specific categories (the child classes).
A Dog is a kind of Animal, meaning that wherever an Animal is expected, a Dog can also be used,
but not the other way around.

Key Points of Generalization:

1. Inheritance: The child class inherits attributes and methods (operations) from the parent
class.
2. Polymorphism: The child class can override or extend the behavior of the parent class. This
allows for more specific behavior in the child class.
3. Substitutability: The child class can be used anywhere the parent class is used.
4. Graphical Representation: It’s represented by a solid line with a large open arrowhead
pointing towards the parent class.
Understanding Association in UML
An association in UML is a structural relationship that shows how objects of one class are
connected to objects of another class. It specifies that objects of one class interact or have a
relationship with objects of another class.
For example, in a Person and Company scenario, a Person might work for a Company. An
association exists between the two, indicating that instances (objects) of the Person class are linked
to instances of the Company class.

Key Elements of Association:

1. Binary Associations: Most associations involve two classes. For instance, a Person class is
associated with a Company class.
• Example: A person works for a company. This is represented by a solid line between
the two classes.
• Graphical Representation:

Aggregation in UML
Aggregation is a special type of association used in UML to model a "whole/part" relationship
between classes. It represents a "has-a" relationship, where one class (the whole) contains or is
composed of other classes (the parts). Aggregation indicates that the part is a component or
member of the whole, but the part can exist independently of the whole.

Key Concepts of Aggregation:

1. Whole/Part Relationship: Aggregation is used when you want to show that one object (the
whole) is made up of other objects (the parts).
• Example: A Library (whole) has Books (parts). The library consists of many books,
but the books are not dependent on the library for their existence. Each book can
exist independently of the library.
2. Graphical Representation: Aggregation is depicted as a plain association with an open
diamond at the end connected to the whole. The open diamond indicates the whole, while
the other end of the association points to the part.
• Example Diagram:
Classes and Their Attributes and Methods:
• Student: This class represents a student with attributes including id (an integer for
identification), name (a string for the student’s name), and email (a string for the student’s
email address). It has methods for registering the student (register()), updating their
email address (updateEmail(newEmail: String)), and calculating their GPA
(getGPA()).
• Subject: This class represents a subject with attributes like code (a string for the subject’s
code), name (a string for the subject’s name), and credits (an integer indicating the
number of credits for the subject). Its methods include adding a student to the subject
(addStudent(student: Student)) and removing a student from the subject
(removeStudent(student: Student)).
• Exam: This class represents an exam with attributes such as date (the date of the exam)
and score (the score obtained in the exam). It includes methods for scheduling the exam
(scheduleExam(date: Date)) and recording the score for a student
(recordScore(student: Student, score: float)).

• Relationships:
• Student to Exam: A student can take multiple exams, indicating a one-to-many relationship
from Student to Exam. This means that one student can be associated with many exams,
but each exam is associated with just one student in this diagram.
• Exam to Subject: Each exam is associated with a single subject, indicating a many-to-one
relationship from Exam to Subject. This means that each exam covers one subject, but a
subject can have multiple exams.
 • Student to Subject: Students can be enrolled in multiple subjects, and each subject can have
multiple students enrolled. This represents a many-to-many relationship between Student
and Subject.

Explanation:
1. CricketPlayer (Abstract Class):
• This is the base class representing a general cricket player. It has attributes for name,
age, and playerID. It also includes methods to get these attributes.
• Being an abstract class, it cannot be instantiated directly but provides a common
structure for other player types.
2. Batsman:
• Inherits from CricketPlayer.
• Has attributes runsScored and battingAverage, with methods to
scoreRuns() and get the battingAverage().
3. Bowler:
• Inherits from CricketPlayer.
• Has attributes wicketsTaken and bowlingAverage, with methods to
takeWicket() and get the bowlingAverage().
4. AllRounder:
• Inherits from CricketPlayer.
• Combines attributes and methods from both Batsman and Bowler, indicating that
an all-rounder can both bat and bowl. It has additional methods to manage runs and
wickets, and to get both batting and bowling averages.
5. Captain:
 • Inherits from Batsman, Bowler, and AllRounder, showing that a captain can
be any type of player.
• Includes an attribute leadershipSkills and methods to set and get these skills.
6. Relationships:
• The diagram shows that Batsman, Bowler, and AllRounder inherit from
CricketPlayer.
• Batsman, Bowler, and AllRounder all have the potential to be a Captain.

Instances of Players:
• Player1: Batsman is an instance of the Batsman class with specific values for name,
age, playerID, runsScored, and battingAverage.
• Player2: Bowler is an instance of the Bowler class with specific values for name,
age, playerID, wicketsTaken, and bowlingAverage.
• Player3: AllRounder is an instance of the AllRounder class with specific values
for name, age, playerID, runsScored, wicketsTaken, battingAverage, and
bowlingAverage.
• Player4: Captain is an instance of the Captain class with specific values for name,
age, playerID, and leadershipSkills.

• Relationships:
• The relationships show that each player instance is connected to the Captain instance,
representing a team where the captain manages the team members.
Classes:
• Department: A base class with attributes departmentID, name, and location, and
a method getDepartmentDetails() to get the department's details.
• HRDepartment: Inherits from Department and has attributes and methods specific to
HR functions, such as recruiting and managing employees.
• ITDepartment: Inherits from Department and has attributes and methods related to IT
support and system maintenance.
• FinanceDepartment: Inherits from Department and has attributes and methods for
financial processes like payroll and report preparation.
• MarketingDepartment: Inherits from Department and has attributes and methods
for marketing activities, including campaign development and market analysis.
• Employee: Represents an employee with attributes employeeID, name, and
position, and a method to get employee details.
• Campaign: Represents a marketing campaign with attributes campaignID, name, and
budget, and a method to get campaign details.

• Relationships:
• Inheritance: Each specific department class (HRDepartment, ITDepartment,
FinanceDepartment, MarketingDepartment) inherits from the Department
class, showing that these are specialized types of departments.
• Composition: The MarketingDepartment class manages Campaign instances, and
the HRDepartment and ITDepartment classes interact with Employee instances.
Object diagram

3rd unit