Module 1
Module 1
ARCHITECTURE
Module 1: Introduction to software architecture and software
product life cycle.
Levels
a) change in requirement with time: with the passing of time, the organization’s needs
and modus operandi of working could substantially be changed so in this frequently
changing time the tools(software) that they are using need to change for maximizing the
performance.
b) environment change: as the working environment changes the things(tools) that enable
us to work in that environment also change proportionally same happens in the software
world as the working environment changes then, the organizations need to reintroduction of
old software with updated features and functionality to adapt the new environment.
c) errors and bugs: as the age of the deployed software within an organization increases their preciseness or
impeccability decreases and the efficiency to bear the increasing complexity workload also continually
degrades. so, in that case, it becomes necessary to avoid the use of obsolete and aged software. all such
obsolete softwares need to undergo the evolution process in order to become robust as per the workload
complexity of the current environment.
d) security risks: using outdated software within an organization may lead you to at the verge of various
software-based cyberattacks and could expose your confidential data illegally associated with the software that
is in use. so, it becomes necessary to avoid such security breaches through regular assessment of the security
patches/modules are used within the software. if the software isn’t robust enough to bear the current occurring
cyberattacks so it must be changed (updated).
e) for having new functionality and features: in order to increase the performance and fast data processing
and other functionalities, an organization needs to continuously evolute the software throughout its life cycle
so that stakeholders & clients of the product could work efficiently.
🠶Laws used for software evolution:
1. Law of continuing change:
this law states that any software system that represents some real-world reality undergoes continuous
change or becomes progressively less useful in that environment.
2. Laws of increasing complexity:
as an evolving program changes, its structure becomes more complex unless effective efforts are made to
avoid this phenomenon.
3. Law of conservation of organization stability:
over the lifetime of a program, the rate of development of that program is approximately constant and
independent of the resource devoted to system development.
4. Law of conservation of familiarity:
this law states that during the active lifetime of the program, changes made in the successive release are
almost constant.
Software Architecture:
The 5 Patterns You Need to Know
🠶 Layered Pattern
🠶 The layered pattern is probably one of the most well-known software architecture
patterns. Many developers use it, without really knowing its name. The idea is to split up
your code into “layers”, where each layer has a certain responsibility and provides a
service to a higher layer.
🠶 There isn’t a predefined number of layers, but these are the ones you see most often:
🠶 Presentation or UI layer
🠶 Application layer
🠶 Business or domain layer
🠶 Persistence or data access layer
🠶 Database layer
🠶 Layer Responsibility
🠶 As mentioned, each layer has its own responsibility. The presentation layer contains the graphical
design of the application, as well as any code to handle user interaction. You shouldn’t add logic that is
not specific to the user interface in this layer.
🠶 The application layer sits between the presentation layer and the business layer. On the one hand, it
provides an abstraction so that the presentation layer doesn’t need to know the business layer. In
theory, you could change the technology stack of the presentation layer without changing anything else
in your application (e.g. change from WinForms to WPF). On the other hand, the application layer
provides a place to put certain coordination logic that doesn’t fit in the business or presentation layer.
🠶 The business layer is where you put the models and logic that is specific to the business problem you
are trying to solve.
🠶 Finally, the persistence layer contains the code to access the database layer. The database layer is the
underlying database technology (e.g. SQL Server, MongoDB). The persistence layer is the set of code
to manipulate the database: SQL statements, connection details, etc.
Advantages
🠶 It is possible to understand and satisfy the requirements of customers through
architecture.
🠶 Once a developer knows the architecture and its development fully, the
organization’s market position is improved because who will say no to a supplier that
understands customers very well.
🠶 All the use cases are understood and solved in the architecture by knowing the
scenarios. This helps the developers to boost their confidence and morale in and
around them. Work satisfaction and thus, the revenue of the company is improved.
The Software Product Life Cycle: Views
🠶 Depending on the project, the result of the first phase could be:
🠶 Problem statement
🠶 first use case (20% completed)
🠶 market research results
🠶 financial prognosis
🠶 risk assessment
🠶 project plan
🠶 corporate or business model
🠶 prototypes
🠶 Phase 2: elaboration
🠶 During the elaboration phase, the system’s requirements and its required
architecture are assessed and analyzed. This is where the project begins to take
shape. the objective of the elaboration phase is to analyze products and lay a
foundation for the future architecture. results of the elaboration phase include:
🠶 use case (80% completed)
🠶 description of the feasible architecture
🠶 project development plan
🠶 prototypes for tackling risks
🠶 user manual
Advantages:
🠶 It provides good documentation, it completes the process in itself.
🠶 It provides risk-management support.
🠶 It reuses the components, and hence total time duration is less.
🠶 Good online support is available in the form of tutorials and training.
Disadvantages:
🠶 Information architecture − defines the logical and physical data assets and data
management resources.
🠶 A software architecture can be defined in many ways −
🠶 UML (Unified Modeling Language) − UML is one of object-
oriented solutions used in software modeling and design.
🠶 Any design activity can be seen from many points of view: Psychological
🠶 Systematic
🠶 Organizational
🠶 From the psychological view, design is a creative process that requires knowledge in the appropriate
disciplines such as software engineering, computer science, logic, cognitive science, linguistics,
programming languages, and software design methodologies as well as application domain-specific
knowledge. HCI approaches software development and use from the psychological aspect.
🠶 From the systematic view, design is seen as an architecting or engineering activity that involves finding
optimized solutions to a set of objectives or problems while balancing competing obstacles or forces.
🠶 The organizational view considers essential elements of the application or system life cycle. Application
development begins with a market need or a new product idea. Application design (or, more generally,
product design) starts with planning and ends when the product reaches its end of life (in software this
means executing an end-of-life strategy and implies that a product is no longer maintained or
supported). There may be some recycling of software elements to be reused in other products.
Takeaway Questions:
1. Define Software Architecture
2. Distinguish Between software architecture and software engineering
3. Differentiate between component and deployment diagram.
4. challenges in Software Architectural Design.
5. Advantages and Disadvantages of Software Architecture and Software Engineering
6. Explain the n need and significance of Software Architecture in detail
7. Draw Activity diagram on Banking System
8. Draw Usecase diagram Airline Booking System
9. Explain SDLC phases
10. Explain the Rational Unified Process model with its phases in detail.
11. State the Scope of design
12. List types of software architecture