Creating an Architectural Design

What is software architecture?

It is like a blueprint of a building, a bridge, or any other kind of

structure, software architecture is used to organize and conceptualize
a system. It includes a definition of which elements and components
need to be in the system, which components need to interact with
each other, and what type of environment the software needs to
operate.

Software architecture defines the structure and constraints that the

software developers will need to work in. It includes the documentation,
charts, diagrams, and anything used to facilitate communications with
stakeholders.

Characteristics of software architecture

Architecture characteristics define the software’s requirements and

what it is expected to do. Some of the characteristics shared by
software architectures include:

A description of the overall system setup: This includes the structure

of the software you want to build. To make it easier for stakeholders to
understand, you might want to create a visual representation with
diagrams and charts. Visuals are a great way to show relationships
between components and subsystems. They give everybody involved
insight into the architecture and give you perspective as you analyze
the structure and look for ways to improve your structure or plan an
expansion to an existing system.

A definition of fundamental elements: Software architecture defines

the core set of elements and properties that are required to build the
system. It does not document every element in detail. It simply
identifies the structures that are required to build the software’s core
functionality. For example, a web browser and a web server describe
the core elements needed for a user to interact with the internet.

A description of high-level structures: The development teams need to

make decisions about the high-level structure that describe things like
the system availability, performance, ability to scale, system reliability
and fault tolerance, configuration and support, and monitoring and
maintenance.

A description of what is being built: You are likely building software or

a system to address the needs and requirements of stakeholders. But
you can’t always fully develop everything that the stakeholders ask for.
A description of what you are building can help you manage
stakeholder expectations. Use diagrams, flowcharts, and process
documents to keep stakeholders informed and to avoid feature and
scope creep.

Software Design Vs Software Architecture

Software design:

1
It is the first stage of the Software Design Lifecycle. It defines:

●​ How the individual modules and components of a system will be

designed
●​ Detailed software properties
●​ Specifications that will help developers implement the software
●​ How all components, modules, functions, and so on are being built

Software architecture:

It is the blueprint for a software system and the highest level of a software
design. It defines:

●​ Which elements and components need to be in the system

●​ Which components need to interact
●​ The type of environment the software needs to operate

Software architecture patterns

Developers often run into similar problems while working on a project.
Software architecture patterns give developers a way to solve these
problems whenever they come up.

Software architecture patterns are important because they help developers to be

more productive and efficient.
A software architecture can be defined in many ways −
UML
Architectural views
​ Functional and non-functional
Architecture Description Language (ADL) − ADL defines the software
architecture formally and semantically.

2
While there are several different software architecture patterns, we are going to
look at the following top-four:

●​ Serverless architecture
●​ Event-driven architecture
●​ Microservices Architecture
●​ Call and return Architecture
●​ Data Flow and Data Centered Architectures
●​ Hierarchical Architecture
●​ Component based architecture

Serverless architecture pattern

This pattern can be used to build software and services without managing the
infrastructure. A third-party is used to manage servers, the backend, and other
services. This lets you focus on fast, continuous software delivery. When you
don’t have to worry about managing the infrastructure and planning for
expansion, you have more time to look at the value that can be added to your
software and services.

Event-driven software architecture

This type of architecture relies on events to trigger actions, communications, and

other services in a decoupled system. An event can be anything that changes the
current state. Think about when a customer adds bank information to the
payment options section in their account on an e-commerce website. The event
can carry the state, like when a purchase is completed. Or the event can be an
identifier, like when a notification is sent that an order has been placed
successfully.

Event-driven architecture includes event producers and event consumers. The

producers detect events and transmit them to the consumer events. The

3
consumer event might process the event, or it might only be impacted by the
event.

Microservices software architecture

Microservices are multiple applications that work interdependently. These

microservices are developed independently and each is designed to solve
specific problems or to perform specific tasks. But their functionality is also
designed to communicate with each other and to be entwined so they can work
together to achieve business goals.

Because each microservice is developed separate from the others, development

is streamlined and deployment is easier. This also increases your ability to
quickly scale to meet customer expectations.

Call and Return Architecture

Hierarchical Architecture

Applications

​ Suitable for applications where reliability of software is a critical issue.

4
 ​ Widely applied in the areas of parallel and distributed computing.

Advantages

​ Faster computation and easy scalability.

​ Provides robustness as slaves can be duplicated.
​ Slave can be implemented differently to minimize semantic errors.
​ Easy to decompose the system based on hierarchy refinement.
​ Can be used in a subsystem of object oriented design.

Call and Return architecture vs Hierarchical architecture:

Call and return architecture is a specific type of hierarchical architecture that focuses
on managing control flow through function calls, while hierarchical architecture is a
broader organizational principle encompassing various layered structures.

Data Design

Data design in software engineering is the process of structuring and

organizing data within a software system to ensure efficient storage, retrieval,
and manipulation. It involves determining data types, relationships, and
constraints to effectively manage information for the application's functionality
and performance.

5
Key Aspects of Data Design:

​ Data Types:​
Defining the types of data (e.g., integers, strings, dates) to be stored and
manipulated.
​ Data Relationships:​
Establishing how different data elements relate to each other (e.g., one-to-one,
one-to-many).
​ Data Constraints:​
Implementing rules to ensure data integrity and consistency (e.g., primary keys,
foreign keys, validation rules).
​ Data Structures:​
Choosing appropriate data structures (e.g., arrays, linked lists, hash tables) to
optimize performance.

6
​ Database Design:​
Transforming the data model into a database schema, considering factors like
normalization and performance.

Levels of Data Design:

●​ Program Component Level: Designing data structures and algorithms for

individual software components.
●​ Application Level: Converting the data model into a database structure.
●​ Business Level: Designing data warehouses for data mining and analysi

7
Assessing Alternative Architectural Designs
There are basically 2 types of assessments

Iterative approach → to analyze Design Trade-offs

Pseudo Quantitative approach → To assess Design Quality

Assessing alternative architectural designs in software engineering involves

evaluating
​different architectural styles and
​patterns
to determine the most suitable design for a specific project.
This process typically involves considering various factors like
●​ system requirements,
●​ quality attributes, and
●​ potential trade-offs.

8
The Software Engg Institute has developed an Architecture Trade off
Analysis Method (ATAM) that establishes an iterative evaluation process
for software Architectures.

I.ATAM
The design analysis that follow are performed iteratively to evaluate the
processes:
1.​ Collect scenarios
2.​ Elicit requirements, constraints and Environment description
3.​ Describe the architectural patterns that hav been chosen to address the
scenarios and requirements.
The following are architectural views:
●​ Model View
●​ Process view →Analyses of performance
●​ Data flow view → Analyses of he degree to which the architecture
meets the functional requirements

4.​ Evaluate the quality attributes by considering by considering each

attribute in isolation
5.​ Identify the sensitivity of the quality attributes to various architectural
attributes for a specific architectural style
6.​ Critique candidate Architectures (as developed in step-3)
using sensitivity analysis conducted as in step -5

Using the results of steps - 5 & step-6 some of the architectural alternatives
may be eliminated.
Also, one or more of the ATAM steps are modified and re-applied to the
ATAM processes.

Next Alternate assessing technique is :

Architectural complexity. It is a technique to assess the overall complexity
of the architecture.

9
II. Architectural complexity
proposed by zoho. There are 3 dependencies
Sharing dependencies - ex : 2 consumers share the same data.
Data is a dependency
Flow dependencies - The representation of dependent relationship between
producers and consumers
Constraint dependencies - It represents the constraints on the relative flow
among a set of activities.
for ex. 2 components can not execute at the same time. The
execution of one component depends on the other component

III.Architectural Description Language

(A D L)
It provides Semantic and syntactic describing the s/w architecture

10
Mapping Data Flow into a Software Architecture

11
12
Efferent : "To carry away from".
Afferent: "To carry to".

13
14
15
16
Data gets into the system. Transformed

17
Data flows into the system.
Data gets transformed into a format required by the system
Data flows out of the system after the process - world data

18
19
●​ Step 2: Review and refine the data flow diagrams for the s/w

20
Modeling Component-Level Design
The foundation of any software architecture is component-level design
— you break a system into its component parts and define how they
interact. Done well, component-level design facilitates reuse, reduces
complexity, and enables parallel development.
Component-based architecture focuses on the decomposition of the design
into individual functional or logical components that represent well-defined
communication interfaces containing methods, events, and properties.

The primary objective of component-based architecture is to ensure

component reusability. A component encapsulates functionality and
behaviors of a software element into a reusable and self-deployable
binary unit. There are many standard component frameworks such as
COM/DCOM, JavaBean, EJB, .NET, web services, and grid services.
These technologies are widely used in local desktop GUI application
design such as graphic JavaBean components, MS ActiveX
components, and COM components which can be reused by simply
drag and drop operation.

Component-oriented software design has many advantages over the

traditional object-oriented approaches such as −

What is a Component?
A component is a software object, intended to interact with other
components, encapsulating certain functionality or a set of functionalities. It
has an obviously defined interface and conforms to a recommended behavior
common to all components within an architecture.

A component is a modular, portable, replaceable, and

reusable set of well-defined functionality that encapsulates
its implementation and exports it as a higher-level
interface.

21
A software component can be defined as a unit of composition
with a contractually specified interface and explicit context
dependencies only. That is, a software component can be
deployed independently and is subject to composition by third
parties.

Characteristics of Components
​ Reusability − Components are usually designed to be reused in
different situations in different applications. However, some
components may be designed for a specific task.
​ Replaceable − Components may be freely substituted with other
similar components.
​ Not context specific − Components are designed to operate in
different environments and contexts.
​ Extensible − A component can be extended from existing
components to provide new behavior.
​ Encapsulated − A component depicts the interfaces, which allow the
caller to use its functionality, and do not expose details of the internal
processes or any internal variables or state.
​ Independent − Components are designed to have minimal
dependencies on other components.

Conducting Component-Level Design

Recognizes all design classes that correspond to the problem domain as
defined in the analysis model and architectural model.

●​ Recognizes all design classes that correspond to the infrastructure

domain.
●​ Describes all design classes that are not acquired as reusable
components, and specifies message details.
●​ Identifies appropriate interfaces for each component and elaborates
attributes and defines data types and data structures required to
implement them.
●​ Describes processing flow within each operation in detail by means of
pseudo code or UML activity diagrams.

22
 ●​ Describes persistent data sources (databases and files) and identifies
the classes required to manage them.
●​ Develop and elaborate behavioral representations for a class or
component. This can be done by elaborating the UML state diagrams
created for the analysis model and by examining all use cases that are
relevant to the design class.
●​ Elaborates deployment diagrams to provide additional implementation
detail.

●​ Demonstrates the location of key packages or classes of components

in a system by using class instances and designating specific hardware
and operating system environments.
●​ The final decision can be made by using established design principles
and guidelines. Experienced designers consider all (or most) of the
alternative design solutions before settling on the final design model.

Designing Class-based Components

23
Principles

Cohesion High
Coupling Very low or minimu . Loosely coupled

24
25
Object Constraint Language (OCL)

The Object Constraint Language (OCL) is an expression language.

It describes constraints on object-oriented languages and other modelling
artifacts.
A constraint can be seen as a restriction on a model or a system.
OCL is part of Unified Modeling Language (UML) and it plays an important
role in the analysis phase of the software lifecycle.

OCL is a typed, declarative and side-effect free specification language. Typed

means that each OCL expression evaluates to a type (either one of the predefined OCL
types or a type in the model where the OCL expression is used) and must conform to
the rules and operations of that type. Side-effect free implies that OCL expressions
can query or constrain the state of the system but not modify it.

Object Constraint Language (OCL), is a formal language

26
 Users of the Unified Modeling Language and other
languages can use OCL to specify constraints and other expressions
attached to their models.

Why OCL
In order to write unambiguous constraints, so-called formal
languages have been developed. The disadvantage of traditional formal
languages is that they are usable to persons with a strong mathematical
background, but difficult for the average business or system modeler to
use.

To understand OCL, the component parts of this statement should be

examined. Thus, OCL has the characteristics of an expression language, a
modeling language and a formal language.

●​ Expression language
OCL is a pure expression language. Therefore, an OCL expression is
guaranteed to be without side effects. It cannot change anything in the model.
This means that the state of the system will never change because of an OCL
expression, even though an OCL expression can be used to specify such a state
change (e.g., in a post-condition). All values for all objects, including all links, will
not change. Whenever an OCL expression is evaluated, it simply delivers a
value.

●​ Modeling language
OCL is a modeling language, not a programming language. It is not possible to
write program logic or flow-control in OCL. You especially cannot invoke
processes or activate non-query operations within OCL. Because OCL is a
modeling language in the first place, not everything in it is promised to be directly
executable.
As a modeling language, all implementation issues are out of scope and cannot
be expressed in OCL. Each OCL expression is conceptually atomic. The state of
the objects in the system cannot change during evaluation.

27
 ●​ Formal language
OCL is a formal language where all constructs have a formally defined
meaning. The specification of OCL is part of the UML specification.

Why a formal language?

In object-oriented modeling, a graphical model, like a class model, is not enough for a
precise and unambiguous specification. There is a need to describe additional
constraints about the objects in the model. Such constraints are often described in
natural language. Practice has shown that this will always result in ambiguities. To write
unambiguous constraints so-called formal languages have been developed.

The above Figure gives an overview of the OCL type system in the form of a feature
model. Using a tree-like description, feature models allow describing mandatory and
optional features of a subject, and to specify alternative features as well as conjunctive
features. In particular, the figure pictures the different kinds of available types.

28
Applications of OCL

OCL can be used for a number of different purposes:

●​ To specify invariants on classes and types in the class model
●​ To specify type invariant for Stereotypes
●​ To describe pre- and post conditions on Operations and
Methods
●​ To describe Guards
●​ As a navigation language
●​ To specify constraints on operations

29
Key Words

Context

30
Self

Invariant

31
32
33
34
35
Example

36
User Interface
User interface is the first impression of a software system from the user's
point of view. Therefore any software system must satisfy the requirements
of the user. UI mainly performs two functions −

​ Accepting the users input

​ Displaying the output

​ UI has its syntax and semantics. The syntax comprises

component types such as textual, icon, button etc. and
usability summarizes the semantics of UI. The quality of UI
is characterized by its look and feel (syntax) and its usability
(semantics).
​
​ There are basically two major kinds of user interface
​ a) Textual
​ b) Graphical. Menu based & Direct manipulation
​
​ Software in different domains may require different style of
its user interface for e.g. calculator need only a small area
for displaying numeric numbers, but a big area for
commands, A web page needs forms, links, tabs, etc.

37
Golden Rules

38
Interface types

UI Design Process

39
UI Analysis

40
Interface Design Steps

UI Design patterns

41
UI Design Issues & Challenges

UI Design Evaluation

42
43