UNIT-1

SYLLABUS:

Introduction to UML:

The meaning of Object-Orientation, object identity, encapsulation, information hiding,

polymorphism, genericity, importance of modeling, principles of modeling, object oriented
modeling, conceptual model of the UML, Architecture

Introduction to UML:

Object orientation is a programming paradigm that organizes data and behavior into reusable
units called objects. In object-oriented programming (OOP), the focus is on the object, rather
than the logic required to handle it.

Object-oriented programming aims to implement real-world entities like inheritance, hiding,

polymorphism, etc in programming. The main aim of OOP is to bind together the data and the
functions that operate on them so that no other part of the code can access this data except that
function.

Advantages of object orientation:

● Easier to understand: OOP makes it easier to understand complex software systems.
● Reduced maintenance: OOP can reduce maintenance requirements.
● Reusable components: OOP allows for the reuse of individual components.
● Problem detection: OOP allows for the detection and correction of problems in the
design phase.
● Lower development costs: OOP can lower development costs by reducing the need for
direct costs like maintenance and development

Key concepts in OOP include:

● Classes: User-defined data types that act as the blueprint for objects, attributes, and
methods.
● Objects: Instances of a class created with specifically defined data.
● Methods: Functions that objects can perform.
● Attributes: Represent the state of an object

OOPs Concepts:
1. Class
2. Objects
3. Data Abstraction
4. Encapsulation
 5. Inheritance
6. Polymorphism
7. Dynamic Binding
8. Message Passing

1. Class:
A class is a user-defined data type. It consists of data members and member functions, which can
be accessed and used by creating an instance of that class. It represents the set of properties or
methods that are common to all objects of one type. A class is like a blueprint for an object.
For Example: Consider the Class of Cars. There may be many cars with different names and
brands but all of them will share some common properties like all of them will have 4 wheels,
Speed Limit, Mileage range, etc. So here, Car is the class, and wheels, speed limits, mileage are
their properties.
2. Object:
It is a basic unit of Object-Oriented Programming and represents the real-life entities. An Object
is an instance of a Class. When a class is defined, no memory is allocated but when it is
instantiated (i.e. an object is created) memory is allocated. An object has an identity, state, and
behavior. Each object contains data and code to manipulate the data. Objects can interact without
having to know details of each other’s data or code, it is sufficient to know the type of message
accepted and type of response returned by the objects.
For example “Dog” is a real-life Object, which has some characteristics like color, Breed, Bark,
Sleep, and Eats.

Object
3. Data Abstraction:
Data abstraction is one of the most essential and important features of object-oriented
programming. Data abstraction refers to providing only essential information about the data to
the outside world, hiding the background details or implementation. Consider a real-life example
of a man driving a car. The man only knows that pressing the accelerators will increase the speed
of the car or applying brakes will stop the car, but he does not know about how on pressing the
accelerator the speed is increasing, he does not know about the inner mechanism of the car or the
implementation of the accelerator, brakes, etc in the car. This is what abstraction is.
4. Encapsulation:
Encapsulation is defined as the wrapping up of data under a single unit. It is the mechanism that
binds together code and the data it manipulates. In Encapsulation, the variables or data of a class
are hidden from any other class and can be accessed only through any member function of their
class in which they are declared. As in encapsulation, the data in a class is hidden from other
classes, so it is also known as data-hiding.
Benefits:

1. Improved security: Protects data from unauthorized access.

2. Reduced coupling: Minimizes dependencies between objects.
3. Increased flexibility: Easier to modify internal implementation.
4. Code reuse: Encapsulated code can be reused.
5. Easier maintenance: Simplifies debugging and testing.

Types of Encapsulation:
1. Data Encapsulation: Hides data attributes.
2. Method Encapsulation: Hides method implementation.
3. Behavioral Encapsulation: Hides object behavior.

Implementation Techniques:
1. Access Modifiers (public, private, protected).
2. Getter and Setter methods.
3. Encapsulated classes.
4. Interfaces.
5. Polymorphism:
The word polymorphism means having many forms. In simple words, we can define
polymorphism as the ability of a message to be displayed in more than one form. For example, A
person at the same time can have different characteristics. Like a man at the same time is a
father, a husband, an employee. So the same person posses different behavior in different
situations. This is called polymorphism.
Example

The classic example is of the Shape class and all the classes that are inherited from it, such as:

● Rectangle
● Triangle
● Circle

Types of polymorphism
● Compile time polymorphism
 ○ Example: Method overloading
● Runtime polymorphism
○ Example: Method overriding

Advantages of polymorphism:
● It helps programmers reuse code and classes once written, tested, and implemented.
● A single variable name can be used to store variables of multiple data types (float,
double, long, int, etc).
● It helps compose powerful, complex abstractions from simpler ones.

Inheritance

Inheritance is the mechanism that permits new classes to be created out of existing classes by
extending and refining its capabilities. The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived classes/child classes/subclasses.
The subclass can inherit or derive the attributes and methods of the super-class(es) provided that
the super-class allows so. Besides, the subclass may add its own attributes and methods and may
modify any of the super-class methods. Inheritance defines an “is – a” relationship.

Example

From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc.
Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In addition, each
has its own particular characteristics. It can be said that a cow “is – a” mammal.

Types of Inheritance

​ Single Inheritance − A subclass derives from a single super-class.

​ Multiple Inheritance − A subclass derives from more than one super-classes.
​ Multilevel Inheritance − A subclass derives from a super-class which in turn is derived
from another class and so on.
​ Hierarchical Inheritance − A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
​ Hybrid Inheritance − A combination of multiple and multilevel inheritance so as to
form a lattice structure.

The following figure depicts the examples of different types of inheritance.

ENTITY OBJECT:

In Object-Oriented Analysis and Design (OOAD), an entity object represents a real-world object
or concept that has its own identity, properties, and behavior.

Characteristics of Entity Objects:

1. Identity: Unique identifier.

2. Properties: Attributes or data members.

3. Behavior: Methods or actions.

4. Persistence: Retains state.

5. Relationships: Interacts with other entities.

Types of Entity Objects:

1. Tangible Entities: Physical objects (e.g., Car, Book).

2. Intangible Entities: Concepts or abstract ideas (e.g., Account, Order).

3. Event Entities: Represent significant events (e.g., Payment, Shipment).

Entity Object Properties:

1. Attributes: Data members (e.g., name, address).

2. State: Current values of attributes.

3. Identity Attributes: Unique identifiers (e.g., ID, SSN).

Entity Object Behavior:

1. Methods: Actions performed on/by the entity.

2. Operations: CRUD (Create, Read, Update, Delete) operations.

3. Business Rules: Validate data, enforce constraints.

Example:

Entity Object: Customer

- Properties:
 - Attributes: name, address, phone

- State: current values

- Identity Attributes: customer ID

- Behavior:

- Methods: placeOrder(), updateAddress()

- Operations: createCustomer(), readCustomer(), updateCustomer(), deleteCustomer()

- Business Rules: validate phone number, check credit limit

Benefits of Entity Objects:

1. Improved modeling accuracy.

2. Clearer understanding of system requirements.

3. Better organization of code.

4. Enhanced maintainability and scalability

Genericity:
The concept of Generalization in OOAD is a powerful mechanism that enables abstraction,
reusability, and the creation of flexible and maintainable software architectures. Generalization is
the process of extracting common characteristics from a set of classes and abstracting them into a
more general superclass or interface.
What is Generalization?
Generalization is the process of extracting common characteristics from a set of classes and
abstracting them into a more general superclass or interface. It embodies the "is-a" relationship,
where a subclass is said to be a specialized version of its superclass, inheriting its attributes and
behaviors while potentially adding or modifying its own.
Importance of Generalization in OOAD
● Code Reusability: Generalization enables the reuse of code by allowing common
attributes and behaviors to be inherited by multiple classes.
● Abstraction: Generalization promotes abstraction by identifying commonalities
among classes and abstracting them into a higher-level superclass.
● Ease of Maintenance: By defining common characteristics in a superclass, changes
made to those characteristics propagate to all subclasses, reducing the need for
redundant modifications.
● Polymorphism: Generalization facilitates polymorphism, allowing objects of
different subclasses to be treated interchangeably through their common superclass
interface.
● Hierarchical Organization: Generalization provides a structured way to organize
classes into hierarchies, making the system easier to understand and maintain.

Specialization

Specialization is the reverse process of generalization. Here, the distinguishing features of groups
of objects are used to form specialized classes from existing classes. It can be said that the
subclasses are the specialized versions of the super-class.

The following figure shows an example of generalization and specialization.

In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.

The Bank Account class serves as the generalized representation of all types of bank accounts,
while the subclasses (Current Account, Savings Account, Credit Account) represent specialized
versions that inherit and extend the functionality of the base class.
Generalization vs. Specialization
Below are the differences between Generalization and Specialization:

Aspect Generalization Specialization

It identifies commonalities It creates new classes based on

among classes and abstracts an existing superclass, adding
Definition
them into a higher-level additional attributes or
superclass. behaviors.

It represents an "is-a-kind-of"
It represents an "is-a"
relationship, where subclasses
Relationship relationship, where subclasses
are more specialized versions
are types of the superclass.
of the superclass.

It moves from a general

It moves from specific classes
Direction superclass to more specific
to a more general superclass.
subclasses.

Promotes code reusability by Enhances code reusability by

Code allowing common attributes inheriting attributes and
Reusability and behaviors to be inherited behaviors from a superclass
by multiple classes. while adding new features.
 Provides flexibility in defining Provides flexibility in
Flexibility common characteristics shared extending the functionality of
by multiple classes. existing classes.

Modeling in OOAD
While creating software, imagine using blueprints to design a house that's what models do in
Object Oriented Analysis and Design (OOAD). Just like blueprints help us understand how a
house will be built, models in OOAD help developers visualize and plan out software before they
start coding. These models focus on identifying the objects or components of the software, how
they interact, and how they come together to make the software work.
What is OOAD?
Object-Oriented Analysis and Design (OOAD) is a structured approach used in software
engineering for planning, designing, and implementing software systems. OOAD uses the
principles of object-oriented programming to model a system based on real-world objects, their
properties, behaviors, and how they interact with each other. This approach is beneficial for
system design because it allows developers to break down complex systems into manageable
components, making the development process more efficient and the systems more scalable and
maintainable.
● Analysis in OOAD: During the analysis phase, the focus is on understanding the
problem domain, identifying the requirements of the system, and modeling the
system's functionality without deciding on how the system will be implemented.
● Design in OOAD: The design phase takes the outcomes of the analysis phase and
plans how the system will achieve its requirements. This involves defining the
software architecture, choosing data structures and algorithms, and detailing the
design of the system's objects and their interactions.

Importance of Models in OOAD

Models in Object-Oriented Analysis and Design (OOAD) serve as the cornerstone for
understanding, designing, constructing, and documenting a software system. Their importance in
the OOAD process cannot be enhanced, as they bring numerous benefits to the development
lifecycle. Here’s why models hold such significance in OOAD:
● Blueprint for Development
○ Models serve as blueprints, giving stakeholders and developers a
conceptual and visual road map.
○ Software developers use models to build software systems, just as
architects use blueprints to build buildings.
○ Before any code is written, these blueprints aid in visualizing the
system's behavior and structure, ensuring that everyone is aware of
the project's direction.
● Facilitates Communication
 ○ For developers, analysts, and non-technical stakeholders, models
act as a common language.
○ They ensure that all parties involved in the development process
have a common understanding of the goals, features, and
limitations of the system by assisting in closing the
communication gap between them.
● Simplifies Complex Systems
○ Complex systems are broken down into manageable parts, or
objects, using object-oriented models.
○ This breakdown facilitates system analysis, design, and
implementation by allowing individual components to be
developed and tested independently before being integrated into
the overall system.
○ The system is also more flexible due to its modular design.
● Promotes Reusability
○ Design patterns and component reuse are encouraged by OOAD
models.
○ Through the identification of shared patterns and objects between
various system components or even projects, developers may
utilize these elements, thereby substantially cutting down on
development duration and cost.
● Aids in System Analysis and Design
○ Models assist in requirements analysis and system architecture
design through the use of schematics and diagrams.
○ They make it possible to identify any problems and obstacles early
in the development process, enabling changes to be made before
large sums of money are spent.

Models in OOAD
In Object-Oriented Analysis and Design (OOAD), models are used to visualize, specify,
construct, and document the design of software systems. These models provide various
perspectives of the system, enabling developers to see the big picture, as well as the finer details
of the design. Below are the key models in OOAD, each serving a distinct purpose in system
design.

1. Use Case Model

To identify the interactions between external actors, users or other systems and the system itself,
detailing the system's functional requirements.

Components:

● Actors: systems or users that communicate with the system.

 ● Use Cases: Descriptions of the system's behaviors from an actor's perspective. Each
use case represents a specific functionality or goal the system can perform.
● Use Case Diagrams: Visual representations of the use cases and their interactions
with actors.

2. Object Model (Class Model)

To describe the structure of the system in terms of objects (instances of classes), their attributes,
and relationships.

Components:

● Classes: Templates that define the properties attributes and behaviors methods of
objects.
● Attributes: Characteristics or properties of classes.
● Operations Methods: Functions or behaviors that can be performed by an object.
● Associations: Relationships between classes indicating how instances of one class
connect to instances of another.
● Class Diagrams: UML diagrams that depict the classes, their attributes, operations,
and the relationships among them.

3. Interaction Model (Sequence and Collaboration Diagrams)

To detail how objects within the system interact with each other over time to carry out specific
functions.

Components:
● Sequence Diagrams: Focus on the time sequence of message exchanges between
objects. They show how objects interact in a particular scenario of a use case.
● Communication Diagrams: Highlight the way in which objects that transmit and
receive messages are structured. Collaboration diagrams offer a more comprehensive
perspective of the object organization, even though they are identical to sequence
diagrams.

4. State Diagram (Statechart Diagram)

To model the dynamic behavior of a single object, showing how the object changes state in
response to events.

Components:
 ● States: Different conditions in which an object can exist.
● Transitions: The movement from one state to another, typically triggered by events.
● Events: External occurrences that can affect the state of an object.
● Actions: Activities that result from a state change.

5. Activity Diagram

To model the workflow of a system or a method, showing the sequence of activities and their
conditions of execution.

Components:

● Activities: Tasks or operations of the system.

● Transitions: The flow from one activity to another.
● Decision Points: Branching points where the flow of control is based on conditions.
● Swimlanes: Organizational units responsible for different activities.

6. Package Diagram

To reduce interdependencies, divide system components into related categories.

Components:
● Packages: Groupings of classes, interfaces, or other packages that are related or work
together.
● Dependencies: Relationships between packages indicating that changes in one
package may affect another.

7. Component and Deployment Diagram

To model the physical aspects of the system, detailing the software components (pieces of code or
modules) and the physical hardware that hosts or executes them.

Components:
 ● Component Diagrams: Show the organization and dependencies among a set of
components.
● Deployment Diagrams: Show the actual physical deployment of the software by
concentrating on the setup of runtime processing nodes and the components that are
located on them.

Each of these models plays a crucial role in providing a comprehensive view of the system from
different perspectives, ensuring that the system is well-understood, properly designed, and ready
for implementation. By utilizing these models, developers can address both the functional and
non-functional requirements of the system, leading to a more robust, maintainable, and efficient
software solution.

Principles of Modeling

1. Abstraction: Focus on essential features and behaviors, ignoring non-essential details.

2. Encapsulation: Hide internal implementation details and expose only necessary information.
3. Modularity: Break down complex systems into smaller, independent modules.
4. Separation of Concerns: Divide responsibilities among different models, views, or aspects.
5. Single Responsibility Principle (SRP): Assign each model or module a single, well-defined
responsibility.
6. Cohesion: Ensure that related elements are grouped together, making the model more
understandable.
7. Coupling: Minimize dependencies between models or modules to improve flexibility and
maintainability.
8. Consistency: Establish a consistent modeling style, notation, and terminology.
9. Reusability: Design models and modules to be reusable in different contexts.
10. Readability: Create models that are easy to understand, navigate, and communicate.
11. Scalability: Design models to accommodate growth, change, and complexity.
12. Flexibility: Create models that can adapt to changing requirements and assumptions.

Additionally, consider the following modeling principles specific to OOAD:

1. Class-Responsibility-Collaboration (CRC) Cards: Use CRC cards to identify classes,

responsibilities, and collaborations.
2. Unified Modeling Language (UML): Apply UML notation and diagrams to create a
standardized model.
3. Object-Oriented Principles (OOP): Incorporate OOP principles, such as inheritance,
polymorphism, and encapsulation.

By applying these principles, you'll create effective models that accurately represent complex
systems and facilitate successful OOAD projects.
Types of Models in Object Oriented Modeling and
Design
Intention of object oriented modeling and design is to learn how to apply object -oriented
concepts to all the stages of the software development life cycle.Object-oriented modeling and
design is a way of thinking about problems using models organized around real world concepts.
The fundamental construct is the object, which combines both data structure and behavior.
Purpose of Models:
1. Testing a physical entity before building it
2. Communication with customers
3. Visualization
4. Reduction of complexity

Types of Models:
There are 3 types of models in object oriented modeling and design are: Class Model, State
Model, and Interaction Model. These are explained below.
1. Class Model:
The class model shows all the classes present in the system. The class model shows
the attributes and the behavior associated with the objects.
The class diagram is used to show the class model.The class diagram shows the class
name followed by the attributes followed by the functions or the methods that are
associated with the object of the class.Goal in constructing class model is to capture
those concepts from the real world that are important to an application.
2. State Model:
State model describes those aspects of objects concerned with time and the
sequencing of operations – events that mark changes, states that define the context for
events, and the organization of events and states.Actions and events in a state diagram
become operations on objects in the class model. State diagram describes the state
model.
3. Interaction Model:
Interaction model is used to show the various interactions between objects, how the
objects collaborate to achieve the behavior of the system as a whole.
The following diagrams are used to show the interaction model:
● Use Case Diagram
● Sequence Diagram
● Activity Diagram

Conceptual model of UML

The conceptual model of UML contains the UML’s vocabulary and rules.
The conceptual model of UML contains the fundamentals of UML. The conceptual model
consists of three parts. They are:
1) Building blocks of UML (syntax / vocabulary)
2) Rules (semantics)
3) Common Mechanisms

Building blocks of UML (Conceptual model

of UML)

These are the fundamental elements in UML. Every diagram can be represented using these
building blocks. The building blocks of UML contain three types of elements. They are:
1) Things (object oriented parts of uml)
2) Relationships (relational parts of uml)
3) Diagrams

Things

A diagram can be viewed as a graph containing vertices and edges. In UML, vertices are
replaced by things, and the edges are replaced by relationships. There are four types of things in
UML. They are:
1) Structural things (nouns of uml – static parts)
2) Behavioral things (verbs of uml – dynamic parts)
3) Grouping things (organizational parts)
4) Annotational things (explanatory parts)

Structural things
Represents the static aspects of a software system. There are seven structural things in UML.
They are:
Class: A class is a collection of similar objects having similar attributes, behavior, relationships
and semantics. Graphically class is represented as a rectangle with three compartments.

Graphical representation:

Example:

Interface: An interface is a collection of operation signatures and/or attribute definitions that

ideally define a cohesive set of behavior. Graphically interface is represented as a circle or a
class symbol stereotyped with interface.

Graphical representation:

or
Use Case: A use case is a collection of actions, defining the interactions between a role (actor)
and the system. Graphically use case is represented as a solid ellipse with its name written inside
or below the ellipse.

Graphical representation:

Example:

Collaboration: A collaboration is the collection of interactions among objects to achieve a goal.

Graphically collaboration is represented as a dashed ellipse. A collaboration can be a collection
of classes or other elements.
Graphical representation:
Example:

Component: A component is a physical and replaceable part of a system. Graphically

component is represented as a tabbed rectangle. Examples of components are executable files, dll
files, database tables, files and documents.

Graphical representation:

Example:
Node: A node is a physical element that exists at run time and represents a computational
resource. Graphically node is represented as a cube. Examples of nodes are PCs, laptops,
smartphones or any embedded system.

Types of Models in Object Oriented Modeling and

Design
Intention of object oriented modeling and design is to learn how to apply object
-oriented concepts to all the stages of the software development life
cycle.Object-oriented modeling and design is a way of thinking about problems using
models organized around real world concepts. The fundamental construct is the
object, which combines both data structure and behavior.

Purpose of Models:

1. Testing a physical entity before building it

2. Communication with customers
3. Visualization
4. Reduction of complexity

Types of Models:
There are 3 types of models in object oriented modeling and design are: Class Model,
State Model, and Interaction Model. These are explained below.
 1. Class Model:
The class model shows all the classes present in the system. The class model
shows the attributes and the behavior associated with the objects.
The class diagram is used to show the class model.The class diagram shows
the class name followed by the attributes followed by the functions or the
methods that are associated with the object of the class.Goal in constructing
class model is to capture those concepts from the real world that are
important to an application.
2. State Model:
State model describes those aspects of objects concerned with time and the
sequencing of operations – events that mark changes, states that define the
context for events, and the organization of events and states.Actions and
events in a state diagram become operations on objects in the class model.
State diagram describes the state model.
3. Interaction Model:
Interaction model is used to show the various interactions between objects,
how the objects collaborate to achieve the behavior of the system as a
whole.
The following diagrams are used to show the interaction model:
● Use Case Diagram
● Sequence Diagram
● Activity Diagram

Behavioral Things
Represents the dynamic aspects of a software system. Behavior of a software system can be
modeled as interactions or as a sequence of state changes.

Interaction: A behavior made up of a set of messages exchanged among a set of objects to

perform a particular task. A message is represented as a solid arrow. Below is an example of
interaction representing a phone conversation:

State Machine: A behavior that specifies the sequences of states an object or interaction goes
through during its’ lifetime in response to events. A state is represented as a rectangle with
rounded corners. Below is an example of state machine representing the states of a phone
system:
Grouping Things

Elements which are used for organizing related things and relationships in models.

Package: A general purpose mechanism for organizing elements into groups. Graphically
package is represented as a tabbed folder. When the diagrams become large and cluttered,
related are grouped into a package so that the diagram can become less complex and easy to
understand.

Graphical representation:

Example:
Annotational Things

Note: A symbol to display comments. Graphically note is represented as a rectangle with a dog
ear at the top right corner.

Graphical representation:

Relationships

The things in a diagram are connected through relationships. So, a relationship is a connection
between two or more things.

Dependency: A semantic relationship, in which a change in one thing (the independent thing)
may cause changes in the other thing (the dependent thing). This relationship is also known as
“using” relationship. Graphically represented as dashed line with stick arrow head.

Graphical representation:
Example:

Association: A structural relationship describing connections between two or more things.

Graphically represented as a solid line with optional stick arrow representing navigation.

Example:

Generalization: Is a generalization-specialization relationship. Simply put this describes the

relationship of a parent class (generalization) to its subclasses (specializations). Also known as
“is-a” relationship.

Graphical representation:
Example:

Realization: Defines a semantic relationship in which one class specifies something that another
class will perform. Example: The relationship between an interface and the class that realizes or
executes that interface.

Graphical representation and Example:

Diagrams

A diagram is a collection of elements often represented as a graph consisting of vertices and

edges joining these vertices. These vertices in UML are things and the edges are relationships.
UML includes nine diagrams:

1) Class diagram

2) Object diagram

3) Use case diagram

4) Component diagram
5) Deployment diagram

6) Sequence diagram

7) Collaboration diagram

8) Statechart diagram and

9) Activity diagram.

Rules (conceptual model of UML)

The rules of UML specify how the UMLs building blocks come together to develop diagrams.
The rules enable the users to create well-formed models. A well-formed model is self-consistent
and also consistent with the other models.

UML has rules for:

Names – What elements can be called as things, relationships and diagrams

Scope – The context that gives a specific meaning to a name

Visibility – How these names are seen and can be used by the other names

Integrity – How things properly relate to one another

Execution – What it means to run or simulate a model

UML- Architecture
Software architecture is all about how a software system is built at its highest level. It is needed to
think big from multiple perspectives with quality and design in mind. The software team is tied to
many practical concerns, such as:

○ The structure of the development team.

○ The needs of the business.
 ○ Development cycle.
○ The intent of the structure itself.

Software architecture provides a basic design of a complete software system. It defines the elements
included in the system, the functions each element has, and how each element relates to one another.
In short, it is a big picture or overall structure of the whole system, how everything works together.

To form an architecture, the software architect will take several factors into consideration:

○ What will the system be used for?

○ Who will be using the system?
○ What quality matters to them?
○ Where will the system run?

The architect plans the structure of the system to meet the needs like these. It is essential to have
proper software architecture, mainly for a large software system. Having a clear design of a complete
system as a starting point provides a solid basis for developers to follow

Each developer will know what needs to be implemented and how things relate to meet the desired
needs efficiently. One of the main advantages of software architecture is that it provides high
productivity to the software team. The software development becomes more effective as it comes up
with an explained structure in place to coordinate work, implement individual features, or ground
discussions on potential issues. With a lucid architecture, it is easier to know where the key
responsibilities are residing in the system and where to make changes to add new requirements or
simply fixing the failures.

In addition, a clear architecture will help to achieve quality in the software with a well-designed
structure using principles like separation of concerns; the system becomes easier to maintain, reuse,
and adapt. The software architecture is useful to people such as software developers, the project
manager, the client, and the end-user. Each one will have different perspectives to view the system
and will bring different agendas to a project. Also, it provides a collection of several views. It can be
best understood as a collection of five views:

1. Use case view

2. Design view
3. Implementation view
4. Process view
5. Development view
Use case view
○ It is a view that shows the functionality of the system as perceived by external actors.
○ It reveals the requirements of the system.
○ With UML, it is easy to capture the static aspects of this view in the use case diagrams,
whereas it?s dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Design View
○ It is a view that shows how the functionality is designed inside the system in terms of
static structure and dynamic behavior.
○ It captures the vocabulary of the problem space and solution space.
○ With UML, it represents the static aspects of this view in class and object diagrams,
whereas its dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.
Implementation View
○ It is the view that represents the organization of the core components and files.
○ It primarily addresses the configuration management of the system's releases.
○ With UML, its static aspects are expressed in component diagrams, and the dynamic
aspects are captured in interaction diagrams, state chart diagrams, and activity diagrams.

Process View
○ It is the view that demonstrates the concurrency of the system.
○ It incorporates the threads and processes that make concurrent system and synchronized
mechanisms.
○ It primarily addresses the system's scalability, throughput, and performance.
○ Its static and dynamic aspects are expressed the same way as the design view but focus
more on the active classes that represent these threads and processes.

Deployment View
○ It is the view that shows the deployment of the system in terms of physical architecture.
○ It includes the nodes, which form the system hardware topology where the system will be
executed.
○ It primarily addresses the distribution, delivery, and installation of the parts that build the
physical system.

Graphical representation:

Example:
Active Class: A class whose objects can initiate its own flow of control (threads) and work in
parallel with other objects. Graphically active class is represented as a rectangle with thick
borders.

Graphical representation:

Example:

Behavioral Things

Represents the dynamic aspects of a software system. Behavior of a software system can be
modeled as interactions or as a sequence of state changes.
Interaction: A behavior made up of a set of messages exchanged among a set of objects to
perform a particular task. A message is represented as a solid arrow. Below is an example of
interaction representing a phone conversation:

State Machine: A behavior that specifies the sequences of states an object or interaction goes
through during its’ lifetime in response to events. A state is represented as a rectangle with
rounded corners. Below is an example of state machine representing the states of a phone
system:

Grouping Things
Elements which are used for organizing related things and relationships in models.
Package: A general purpose mechanism for organizing elements into groups. Graphically
package is represented as a tabbed folder. When the diagrams become large and cluttered,
related are grouped into a package so that the diagram can become less complex and easy to
understand.
Graphical representation:

Example:

Annotational Things

Note: A symbol to display comments. Graphically note is represented as a rectangle with a dog
ear at the top right corner.
Graphical representation:

Relationships
The things in a diagram are connected through relationships. So, a relationship is a connection
between two or more things.
Dependency: A semantic relationship, in which a change in one thing (the independent thing)
may cause changes in the other thing (the dependent thing). This relationship is also known as
“using” relationship. Graphically represented as dashed line with stick arrow head.
Graphical representation:

Example:

Association: A structural relationship describing connections between two or more things.

Graphically represented as a solid line with optional stick arrow representing navigation.

Example:

Generalization: Is a generalization-specialization relationship. Simply put this describes the

relationship of a parent class (generalization) to its subclasses (specializations). Also known as
“is-a” relationship.
Graphical representation:
Example:

Realization: Defines a semantic relationship in which one class specifies something that another
class will perform. Example: The relationship between an interface and the class that realizes or
executes that interface.

Graphical representation and Example:

Diagrams
A diagram is a collection of elements often represented as a graph consisting of vertices and
edges joining these vertices. These vertices in UML are things and the edges are relationships.
UML includes nine diagrams:

1) Class diagram
2) Object diagram
3) Use case diagram
4) Component diagram
5) Deployment diagram
6) Sequence diagram
7) Collaboration diagram
8) Statechart diagram and
9) Activity diagram.

Rules (conceptual model of UML)

The rules of UML specify how the UMLs building blocks come together to develop diagrams.
The rules enable the users to create well-formed models. A well-formed model is self-consistent
and also consistent with the other models.
UML has rules for:
Names – What elements can be called as things, relationships and diagrams
Scope – The context that gives a specific meaning to a name
Visibility – How these names are seen and can be used by the other names
Integrity – How things properly relate to one another
Execution – What it means to run or simulate a model

UML- Architecture
Software architecture is all about how a software system is built at its highest level. It is needed to
think big from multiple perspectives with quality and design in mind. The software team is tied to
many practical concerns, such as:

○ The structure of the development team.

○ The needs of the business.
○ Development cycle.
○ The intent of the structure itself.
Software architecture provides a basic design of a complete software system. It defines the elements
included in the system, the functions each element has, and how each element relates to one another.
In short, it is a big picture or overall structure of the whole system, how everything works together.

To form an architecture, the software architect will take several factors into consideration:

○ What will the system be used for?

○ Who will be using the system?
○ What quality matters to them?
○ Where will the system run?

The architect plans the structure of the system to meet the needs like these. It is essential to have
proper software architecture, mainly for a large software system. Having a clear design of a complete
system as a starting point provides a solid basis for developers to follow

Each developer will know what needs to be implemented and how things relate to meet the desired
needs efficiently. One of the main advantages of software architecture is that it provides high
productivity to the software team. The software development becomes more effective as it comes up
with an explained structure in place to coordinate work, implement individual features, or ground
discussions on potential issues. With a lucid architecture, it is easier to know where the key
responsibilities are residing in the system and where to make changes to add new requirements or
simply fixing the failures.

In addition, a clear architecture will help to achieve quality in the software with a well-designed
structure using principles like separation of concerns; the system becomes easier to maintain, reuse,
and adapt. The software architecture is useful to people such as software developers, the project
manager, the client, and the end-user. Each one will have different perspectives to view the system
and will bring different agendas to a project. Also, it provides a collection of several views. It can be
best understood as a collection of five views:

1. Use case view

2. Design view
3. Implementation view
4. Process view
5. Development view
Use case view
○ It is a view that shows the functionality of the system as perceived by external actors.
○ It reveals the requirements of the system.
○ With UML, it is easy to capture the static aspects of this view in the use case diagrams,
whereas it?s dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Design View
○ It is a view that shows how the functionality is designed inside the system in terms of
static structure and dynamic behavior.
○ It captures the vocabulary of the problem space and solution space.
○ With UML, it represents the static aspects of this view in class and object diagrams,
whereas its dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Implementation View
 ○ It is the view that represents the organization of the core components and files.
○ It primarily addresses the configuration management of the system's releases.
○ With UML, its static aspects are expressed in component diagrams, and the dynamic
aspects are captured in interaction diagrams, state chart diagrams, and activity diagrams.

Process View
○ It is the view that demonstrates the concurrency of the system.
○ It incorporates the threads and processes that make concurrent system and synchronized
mechanisms.
○ It primarily addresses the system's scalability, throughput, and performance.
○ Its static and dynamic aspects are expressed the same way as the design view but focus
more on the active classes that represent these threads and processes.

Deployment View
○ It is the view that shows the deployment of the system in terms of physical architecture.
○ It includes the nodes, which form the system hardware topology where the system will be
executed.
○ It primarily addresses the distribution, delivery, and installation of the parts that build the
physical system.