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:

o The structure of the development team.

o The needs of the business.
o Development cycle.
o 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:

o What will the system be used for?

o Who will be using the system?
o What quality matters to them?
o 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.Difference between JDK, JRE, and JVM

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

o It is a view that shows the functionality of the system as perceived by external

actors.
o It reveals the requirements of the system.
o 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

o It is a view that shows how the functionality is designed inside the system in terms
of static structure and dynamic behavior.
o It captures the vocabulary of the problem space and solution space.
o 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

o It is the view that represents the organization of the core components and files.
o It primarily addresses the configuration management of the system’s releases.
 o 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

o It is the view that demonstrates the concurrency of the system.

o It incorporates the threads and processes that make concurrent system and
synchronized mechanisms.
o It primarily addresses the system's scalability, throughput, and performance.
o 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

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

UML-Diagrams
The UML diagrams are categorized into structural diagrams, behavioral diagrams, and
also interaction overview diagrams. The diagrams are hierarchically classified in the
following figure:
1. Structural Diagrams
Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure
diagrams, component diagrams, deployment diagrams, object diagrams, and package
diagrams. It presents an outline for the system. It stresses the elements to be present that
are to be modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the
backbone of all the object-oriented software systems. It depicts the static structure
of the system. It displays the system's class, attributes, and methods. It is helpful in
recognizing the relation between different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts
within the class. It displays the relationship between the parts and their
 configuration that ascertain the behavior of the class. It makes full use of ports,
parts, and connectors to portray the internal structure of a structured classifier. It
is similar to class diagrams, just the fact it represents individual parts in a detailed
manner when compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point
in time. It can be used to test the accuracy of class diagrams. It represents distinct
instances of classes and the relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components
within the system. It is used for modeling execution details. It determines whether
the desired functional requirements have been considered by the planned
development or not, as it depicts the structural relationships between the elements
of a software system.
o Deployment Diagram: It presents the system's software and its hardware by
telling what the existing physical components are and what software components
are running on them. It produces information about system software. It is
incorporated whenever software is used, distributed, or deployed across multiple
machines with dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are
organized. It shows the dependencies between distinct packages. It manages UML
diagrams by making it easily understandable. It is used for organizing the class and
use case diagrams.

2. Behavioral Diagrams:
Behavioral diagrams portray a dynamic view of a system or the behavior of a system,
which describes the functioning of the system. It includes use case diagrams, state
diagrams, and activity diagrams. It defines the interaction within the system.

o State Machine Diagram: It is a behavioral diagram. it portrays the system's

behavior utilizing finite state transitions. It is also known as the State-
charts diagram. It models the dynamic behavior of a class in response to external
stimuli.
 o Activity Diagram: It models the flow of control from one activity to the other. With
the help of an activity diagram, we can model sequential and concurrent activities.
It visually depicts the workflow as well as what causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by utilizing actors
and use cases. It encapsulates the functional requirement of a system and its
association with actors. It portrays the use case view of a system.

3. Interaction Diagrams
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object
interactions and also depicts the flow between various use case elements of a system. In
simple words, it shows how objects interact with each other and how the data flows within
them. It consists of communication, interaction overview, sequence, and timing diagrams.

OOPs Concepts in Java

o Sequence Diagram: It shows the interactions between the objects in terms of

messages exchanged over time. It delineates in what order and how the object
functions are in a system.
o Communication Diagram: It shows the interchange of sequence messages
between the objects. It focuses on objects and their relations. It describes the static
and dynamic behavior of a system.
o Timing Diagram: It is a special kind of sequence diagram used to depict the
object's behavior over a specific period of time. It governs the change in state and
object behavior by showing the time and duration constraints.
o Interaction Overview diagram: It is a mixture of activity and sequence diagram
that depicts a sequence of actions to simplify the complex interactions into simple
interactions.

UML-Relationship
Relationships depict a connection between several things, such as structural, behavioral,
or grouping things in the unified modeling language. Since it is termed as a link, it
demonstrates how things are interrelated to each other at the time of system execution.
It constitutes four types of relationships, i.e., dependency, association,
generalization, and realization.
Dependency
Whenever there is a change in either the structure or the behavior of the class that affects
the other class, such a relationship is termed as a dependency. Or, simply, we can say a
class contained in other class is known as dependency. It is a unidirectional relationship.

Association
Association is a structural relationship that represents how two entities are linked or
connected to each other within a system. It can form several types of associations, such
as one-to-one, one-to-many, many-to-one, and many-to-many. A ternary association
is one that constitutes three links. It portrays the static relationship between the entities
of two classes.

An association can be categorized into four types of associations, i.e., bi-directional,

unidirectional, aggregation (composition aggregation), and reflexive, such that an
aggregation is a special form of association and composition is a special form of
aggregation. The mostly used associations are unidirectional and bi-directional.

Aggregation
An aggregation is a special form of association. It portrays a part-of relationship. It forms
a binary relationship, which means it cannot include more than two classes. It is also
known as Has-a relationship. It specifies the direction of an object contained in another
object. In aggregation, a child can exist independent of the parent.

Composition
In a composition relationship, the child depends on the parent. It forms a two-way
relationship. It is a special case of aggregation. It is known as Part-of relationship.

Aggregation VS Composition relationship

 Features Aggregation relationship Composition relationship
Dependency In an aggregation relationship, a child In a composition relationship,
can exist independent of a parent. the child cannot exist
independent of the parent.
Type of It constitutes a Has-a relationship. It constitutes Part
Relationship of relationship.
Type of It forms a weak association. It forms a strong association.
Association
Examples A doctor has patients when the doctor A hospital and its wards. If the
gets transfer to another hospital, the hospital is destroyed, the wards
patients do not accompany to a new also get destroyed.
workplace.

Generalization
The generalization relationship implements the object-oriented concept called
inheritance or is-a relationship. It exists between two objects (things or entities), such that
one entity is a parent (superclass or base class), and the other one is a child (subclass or
derived class). These are represented in terms of inheritance. Any child can access, update,
or inherit the functionality, structure, and behavior of the parent.

Realization
It is a kind of relationship in which one thing specifies the behavior or a responsibility to
be carried out, and the other thing carries out that behavior. It can be represented on a
class diagram or component diagrams. The realization relationship is constituted between
interfaces, classes, packages, and components to link a client element to the supplier
element.

UML Association vs. Aggregation vs. Composition

In UML diagrams, relationships are used to link several things. It is a connection between
structural, behavioral, or grouping things. Following are the standard UML relationships
enlisted below:

o Association
o Dependency
o Generalization
 o Realization

Association
Association relationship is a structural relationship in which different objects are linked
within the system. It exhibits a binary relationship between the objects representing an
activity. It depicts the relationship between objects, such as a teacher, can be associated
with multiple teachers.

It is represented by a line between the classes followed by an arrow that navigates the
direction, and when the arrow is on both sides, it is then called a bidirectional association.
We can specify the multiplicity of an association by adding the adornments on the line
that will denote the association.

Example:History of Java

1) A single teacher has multiple students.

2) A single student can associate with many teachers.

The composition and aggregation are two subsets of association. In both of the cases, the
object of one class is owned by the object of another class; the only difference is that in
composition, the child does not exist independently of its parent, whereas in aggregation,
the child is not dependent on its parent i.e., standalone. An aggregation is a special form
of association, and composition is the special form of aggregation.

Aggregation
Aggregation is a subset of association, is a collection of different things. It represents has
a relationship. It is more specific than an association. It describes a part-whole or part-of
relationship. It is a binary association, i.e., it only involves two classes. It is a kind of
relationship in which the child is independent of its parent.

For example:

Here we are considering a car and a wheel example. A car cannot move without a wheel.
But the wheel can be independently used with the bike, cycle, or any other vehicle. The
wheel object can exist without the car object, which proves to be an aggregation
relationship.

Composition
The composition is a part of aggregation, and it portrays the whole-part relationship. It
depicts dependency between a composite (parent) and its parts (children), which means
that if the composite is discarded, so will its parts get deleted. It exists between similar
objects.

As you can see from the example given below, the composition association relationship
connects the Person class with Brain class, Heart class, and Legs class. If the person is
destroyed, the brain, heart, and legs will also get discarded.
Association vs. Aggregation vs. Composition

Association Aggregation Composition

Association relationship is Aggregation relationship is The composition

represented using an arrow. represented by a straight line with relationship is represented
an empty diamond at one end. by a straight line with a
black diamond at one end.

In UML, it can exist between It is a part of the association It is a part of the

two or more classes. relationship. aggregation relationship.

It incorporates one-to-one, It exhibits a kind of weak It exhibits a strong type of

one-to-many, many-to-one, relationship. relationship.
and many-to-many
association between the
classes.

It can associate one more In an aggregation relationship, the In a composition

objects together. associated objects exist relationship, the associated
independently within the scope of objects cannot exist
the system. independently within the
scope of the system.
 In this, objects are linked In this, the linked objects are Here the linked objects are
together. independent of each other. dependent on each other.

It may or may not affect the Deleting one element in the It affects the other element
other associated element if aggregation relationship does not if one of its associated
one element is deleted. affect other associated elements. element is deleted.

Example: A tutor can Example: A car needs a wheel for its Example: If a file is placed in
associate with multiple proper functioning, but it may not a folder and that is folder is
students, or one student can require the same wheel. It may deleted. The file residing
associate with multiple function with another wheel as well. inside that folder will also
teachers. get deleted at the time of
folder deletion.

UML- Association
Association is the semantic relationship between classes that shows how one instance is
connected or merged with others in a system. The objects are combined either logically
or physically. Since it connects the object of one class to the object of another class, it is
categorized as a structural relationship. Following are the constraints applied to the
association relationship are enlisted below:

a. {implicit}: As the name suggests, the implicit constraints define that the
relationship is not visible, but it is based on a concept.
b. {ordered}: It describes that the set of entities is in a particular way at one end in
an association.
c. {changeable}: The changeable constraint ensures that the connections between
several objects within a system are added, improved, and detached, as and when
required.
d. {addOnly}: It specifies that any new connection can be added from an object
located at the other end in an association.
 e. {frozen}: The frozen constraint specifies that whenever a link is added between
objects, it cannot be altered by the time it is activated over the connection or given
link.

Reflexive Association
In the reflexive associations, the links are between the objects of the same classes. In other
words, it can be said that the reflexive association consists of the same class at both ends.
An object can also be termed as an instance.

Let's have a look at its example of a class vegetable. The vegetable class has two objects,
i.e., onion and eggplant. According to the reflexive association's definition, the link
between the onion and eggplant exist, as they belong to the same class, i.e., vegetable.

Directed Association
The directed association is concerned with the direction of flow inside association classes.
The flow of association can be shown by employing a directed association. The directed
association between two classes is represented by a line with an arrowhead, which
indicates the navigation direction. The flow of association from one class to another is
always in one direction.

Prime Ministers of India | List of Prime Minister of India (1947-2020)

It can be said that there is an association between a person and the company. The person
works for the company. Here the person works for the company, and not the company
works for a person.

UML-Dependency
Dependency depicts how various things within a system are dependent on each other. In
UML, a dependency relationship is the kind of relationship in which a client (one element)
is dependent on the supplier (another element). It is used in class diagrams, component
diagrams, deployment diagrams, and use-case diagrams, which indicates that a change
to the supplier necessitates a change to the client. An example is given below:

Types of Dependency Relationship

Following are the type of dependency relationships, keywords, or stereotypes given
below:

o <<derive>> -It is a constraint that specifies the template can be initialized by the
source at the target location utilizing given parameters.
o <<derive>> -It represents that the source object's location can be evaluated from
the target object.
o <<friend>> -It states the uniqueness of the source in the target object.
o <<instanceOf>> -It states that an instance of a target classifier is the source
object.
o <<instantiate>> -It defines the capability of the source object, creating instances
of a target object.
o <<refine>> -It states that the source object comprises of exceptional abstraction
than that of the target object.
o <<use>> -When the packages are created in UML, the use of stereotype is used
as it describes that the elements of the source package can also exist in the target
package. It specifies that the source package uses some of the elements of the
target package.
o <<substitute>> -The substitute stereotype state that the client can be substituted
at the runtime for the supplier.
o <<access>> -It is also called as private merging in which the source package
accesses the element of the target package.
o <<import>> -It specifies that target imports the source package's element as they
are defined within the target. It is also known as public merging.
o <<permit>> -It describes that the source element can access the supplier element
or whatever visibility is provided by the supplier.
o <<extend>> -It states that the behavior of the source element can be extended
by the target.
o <<include>> -It describes the source element, which can include the behavior of
another element at a specific location, just like a function call in C/C++.
o <<become>> -It states that target is similar to the source with distinct roles and
values.
o <<call>> -It specifies that the target object can be invoked by the source.
o <<copy>> -It states that the target is an independent replica of a source object.
o <<parameter>> -It describes that the supplier is a parameter of the client's
actions.
o <<send>> -The client act as an operation, which sends some unspecified targets
to the supplier.