Week-1

Understanding Software Development

1. Development of a Software Product or an Application

• Multifaceted nature
• Fusion of creativity and precision
• Solve a real-world problem

2. Dance of dual nature - Art & Science

• Artistic expression and creativity
• Systematic methodologies & Scienti c rigor

Artistic Perspective

1. Creative Problem-Solving
• Approach challenges with creativity
• Foster innovative solutions beyond conventional approaches

2. Aesthetics & User Experience

• Prioritise intuitive and visually rich user interfaces
• Emphasise the role of individual expression in design choices

The Scienti c Perspective

1. Systematic Design & Development Methodologies

• Structured approach to software design & development
• Levels of development & phases of development

2. Process of Design & Development

• Systematic process - V-Model, Agile
• Phases - A Life Cycle
• Well documented

Balancing Act

• Collaborative environment with diverse perspectives

• Ongoing learning of new technologies

• Dynamic interaction between art and science

• Ever-evolving nature of software

• Unique contribution of each perspective

Software Requirements of Software Products

• Express the needs and constraints placed on a software product that contributes to the solution of some
real- world problem.

• Crucial to the success of the software projects - if done poorly, the projects are critically vulnerable.

• Alternate term used is “requirements engineering" to denote the systematic handling of requirements.
fi
fi
 Software Requirements Knowledge Areas

- It is concerned with the elicitation, analysis, speci cation and validation of software requirements as
well as the management of requirements during the whole life cycle of the software product.
• Process
• Practical Considerations
• Tools

- Elicitation
• Origin of SW Requirements & How the software engineer collects them

- Analysis
• Detect & resolve con icts
• Discover bounds of SW
• Interact with organisational and operational environments
• Elaborate system requirements to derive software requirements

- Speci cation
• Documented Software Requirements

- Validation
• Verify adherence to standards
• Ensure understanding of the stated requirements by stakeholders

- Fundamentals
• Veri able requirement which ultimately solve a real-world problem

- Process
• Complete process cycle

- Practical Considerations
• Actual document
• Traceability
• Change Management

- Tools
• Models (UML) & Managing Requirements

Related closely with other KA

• Software Design
• Software Testing
• Software Maintenance
• Software Con guration Management
• Software Engineering Management
• Software Engineering Process
• Software Engineering Models & Methods
• Software Quality

Video transcript:

Let's take a look at all those related to software design. In fact, requirements are taken into design and
what happens in design by the engineers and developers also provides a feedback and validation to
software requirements that are documented. Software testing for sure, software maintenance comes later
once the software is deployed or released. But during the process, one needs to ensure that enough
attention is provided to build the basis for software maintenance in terms of user manual, maintenance
manuals, and supporting documentation, training and all of it. Software con guration management, all
these changes need to be tracked virginized. Software engineering management, the entire process needs
to be managed. Software engineering process we will be dealing with a choice of a process and the entire
steps that are taken which form part of the process. Also is another knowledge area where variety of
fi
fi
fi
fl
fi
fi
 processes can be employed for developing the software. So requirements may drive it or the process may
drive some part of requirements.

Needless to say, software engineering models and methods will form part of a knowledge area that
intersects or has crossroads with software requirements, and ultimately, software quality. All, in fact, nearly
all these knowledge areas intersect with software requirements. In summary, we explored the software
requirements knowledge area. We have understood the details of the software requirement knowledge
area and its relation with other knowledge areas, and through the entire discussion we have developed an
appreciation for importance of this knowledge area. Thank you.

Introduction to Software Design

- What is Software Design?

• Process of de ning the architecture, components and interfaces
• Characteristics of system and/or component
• The Result of that process

- Outcome of Software Design

• Software Architecture Description- decomposed and organised into components
• Interfaces between those components

Software Design KA

- Software Structure and Architecture

• Software elements, relationships among them and their properties

- User interface Design

• E ective operation and control

- Software Design Strategies and Methods

• Top-down, bottom up, Function- Oriented, Object-Oriented and more

Software Design Fundamentals

• Key issues in Software Design

• Software Design Quality Analysis and Evaluation
• Software Design Notation
• Software Design Tools

Software Structure and Architecture:

• Architectural Styles
• Design patterns
• Architecture Design Decisions

User Interface Design:

• General UI Design Principles
• Design of User Interaction modalities
• Design of Information Presentation
• Localisation and Internationalisation

Related closely with other KA:

• Software Requirements
• Software Construction
• Software Engineering Management
• Software Engineering Models and Methods
• Software Quality
• Computing Fundamentals KA
ff
fi
Introduction to Software Construction

- What is Software Construction?

• Detailed creation of working software
• Comprises of activities of design, coding, veri cation, unit testing, integration testing, and
debugging

- Outcome of Software Construction

• Running code (software) on the system
• Artefacts from the process of construction

Software Construction KA

- Practical Considerations:
• Deal with sometime chaotic and changing real-world constraints

- Construction Technologies:
• State of the art and scienti c ways of construction

- Software Construction Fundamentals

- Managing Construction
- Software Construction Tools
- Practical Considerations:
• Construction Design
• Construction Languages
• Coding
• Construction Testing
• Construction for Reuse
• Construction Quality
• Integration

- Construction Technologies:
• API Design & Use
• Object-Oriented Runtime Issues
• Error handling, Exception handling, and Fault Tolerance
• State-Based and table-Driven
• Construction Techniques
• Runtime Con guration and
• Internationalisation
• Performance Analysis and Tuning
• Test-First programming

Related closely with other KA:

• Software Design
• Software Testing
• Software Con guration Management
• Software Quality
• Computing Fundamentals KA

Video transcript:

Numerous APIs, libraries or at times you're developing everything from scratch. There would be variety of
considerations for the design. If you're using a library, or if you're actually developing the software
and designing the software afresh, there would still be newer APIs that will be designed and constructed
for use within that particular software product. We're going to deal with runtime issues related to object
oriented software, error handling, exception handling, fault tolerance, construction techniques, which may
fi
fi
fi
fi
be state based or table driven construction techniques, run time con gurations and internationalization. If
you really put all of these together and take any example, one starts looking at design of APIs, design of
libraries, when you look at any application, a mobile application, for example, got to look at error
handling, exception handling, does it really take care of numerous things that the user is going to do while
saying, interacting with the software, is it fault tolerant? During runtime, are there any con gurations that
need to be handled? Is this software going to be used by people world over or probably only a section
of the geography where this software is going to be released? Variety of things. Ultimately, we want to
make sure that the constructed software, is high performance. Thus, while building all this as a set of
components into a product, each of them need to go through a performance analysis and ultimately
tune this performance to build a robust and high performance software product. To make this happen,
many are times, you would nd that test rst programming is used as a step. So testing is
actually integrated as a process step as a part of construction, which allows course correction, tuning then
and there. As always, construction is also related to other knowledge areas, which are these?

Introduction to Software Testing

- What is Software Testing?

• Dynamic veri cation that a program provides expected behaviour on a nite a set of test cases,
suitably selected from the usually in nite execution domains

- Outcome of Software Testing

• Prevention of problems
• Provide information about the functionality and quality of software

Software Testing KA

- Testing Techniques
• Systematically "break" the program
• Based on how test cases are generated
• Based on information of development

- Test-Related Measures
• Measure to optimise planning and execution
• Measures around the detected faults

- Software Testing Fundamentals

- Test Process
- Test Levels
- Software Testing Tools

Video transcript:
Other pieces related to the testing fundamentals, the test processes and levels, test process followed
would mean the exact end to end process that is followed during the entire testing phase in a particular
software product development life cycle. Levels could be unit integration, system related test
cases. Ultimately, all of this needs to be managed using software testing tools, tools which would manage
test cases, tools that would really log all the results which allow test related measures to be employed in a
particular way, in a measurable way.

- Test Techniques:
• Engineer's intuition
• Input Domain-based
• Code-Based
• Fault-Based
• Usage-Based
• Model-Based
• Nature of Application
• Select and Combine
fi
fi
fi
fi
fi
fi
fi
 Video transcript:

What these test techniques are based on? Let's take a look at those. First, knowing a particular product or
knowing a particular type of a product, engineers can de nitely use their intuition to develop these test
cases. Based on the input domain based, what kind of inputs are going to come to the system? Based on
code based, if code and related details are available for testing team or test as an organization. Fault
based. You may look at system actually generating faults. There would be indications that would be
provided, and those are expected. So we base the test cases on faults. Usage based. How is the software
going to be used? Model based. Maybe there are certain algorithms. Maybe an architectural pattern is
used, which actually forms a model, and to that model, there's a standardized mechanism of applying a
technique to get the testing done. It may be with the nature of the application. An application in the
healthcare, application in the nance domain or application in the gaming industry could be dealt with
di erently. While we do all these, we also want to make sure we select and combine the test
cases. Remember the de nition. We ultimately are going to select from a large number of possible test
cases

- Test-Related Measures:
• Evaluation of the Program Under Test
• Evaluation of the Tests Performed

- Criteria:
• How much testing is enough for stated objective (Test Adequacy)?
• Which test cases should be selected for achieving the objective (Selection)?

Video Transcript:

When we look at test related measures, we want to really evaluate the program under test by number of
tests performed, the pass fail, the untestable. Sometimes you would nd that test cases are designed, but
they are not testable. You want to look at why they were so, or why did they fail. When test cases pass, at
times, you would want to further see if we need to break them down into units to see if we could do any
further detailed testing. This can only happen when you really put in those measures which are speci cally
test related. In testing, since it's all to do with de ning, selecting, and we are basing it on ultimately a
subset of all the possible theoretical test cases. We want to come up with a criteria where we would want
to build test adequacy. How much testing is enough for the stated objective? There needs to be a method
to it. The second, which test cases should be selected for achieving that objective? Selection comes into
play. In fact, this test adequacy and selection at times form a mix of art and science to be brought in. We
don't want the users to see the defect at all, but the defect may still exist, and it might require numerous
steps before the defect gets uncovered, so the selection criteria can be user based.

Introduction to Software Maintenance

- What is Software Maintenance?

• Totality of activities required to provide cost-e ective support to software (pre- delivery and post-
delivery)

- Outcome of Software Maintenance

• Customer satisfaction
• Maintenance procedures and manuals

Software Maintenance KA

- Key Issue in Software Maintenance

• Unique challenges - technical and management

- Techniques for Maintenance

• Generic strategies like reengineering, migration and reverse engineering
ff
fi
fi
fi
ff
fi
fi
fi
Video Transcript:
What are the key issues in software maintenance? In fact, if one looks at the maintenance of any kind
of software product or an application, it poses with unique challenges of both technical nature and
management nature. Technical would mean because there are a variety of components that come into
play, and each component manufacturer could be di erent. It could be developed by multiple people,
multiple companies, and it comes together or multiple people, and it is brought together as a part of
integration. Ultimately, management of software. There could be a variety of issues that come in in
terms of release of that particular software into multiple products, for example, software is same, but the
system changes. Software is same, but the target market changes. These issues are very unique to
software maintenance phases. Some can become requirements. However, as software gets released far
and wide, they become unique and they become unique post delivery. What would be the techniques of
maintenance? Primarily, pre delivery, while the software is being developed, the strategies are about
engineering, understanding the engineering, documenting the engineering from a maintenance
perspective. What would be required to maintain? What would be required to make sure that preventive
maintenance is done on the system for software, maybe patches are released. Post delivery, when
personnel change or depending on the documentation that is available, one would start looking at reverse
engineering of certain areas. In fact, as a part of maintenance, one would also want to look at re-
engineering of certain areas due to technological advancement or probably some components being
obsolute, or newer components are being available, which are better than the previously used
components. With these key issues and the techniques, we have our supporting areas within software
maintenance, which is to do with the maintenance process, maintenance techniques that are followed, as
well as maintenance tools.

- Maintenance Process
- Maintenance Techniques
- Software Maintenance Fundamentals
- Software Maintenance Tools
- Key Issues in Software Maintenance:
• Technical Issues
• Management Issues
• Maintenance Cost Estimations
• Software Maintenance Measurement

- Techniques for Maintenance:

• Program Comprehension
• Reengineering
• Reverse Engineering
• Migration
• Retirement

Video Transcript:
Let's get into a bit detail in terms of key issues in software maintenance. Technical issues. Primarily related
to technology, related to engineering, related to design, as well as might be related to testing. You made a
choice of certain test cases, but did not choose certain test cases, that led to uncovering certain technical
issues. Management issues. As we already spoke, it's about release of software or managing it through
the deployment process. Software that works on platform A tested on a platform A, B, C, and D.
However, it might provide maintenance issues related to one or more platforms out of the A, B, C, and D.
All of this is going to be done based on certain cost estimations. You want to make sure that as a part of
business, maintenance costs are kept as low as possible. To do all this, one will have to measure the
software maintenance. Maintenance measurement in terms of time, maintenance, measurement in terms
of cost. If you have tools which are further licensed, license fees are paid to manage the
software. Techniques for maintenance. In fact, some of these techniques for maintenance become very
evident as the software lives longer. In fact, the cycles of software for 2-3 years or 3-6 years. Or the long
term supports that are provided for certain software demand speci c ways in which the maintenance crew
or the maintenance team looks at this particular software. They would want to understand the program. At
times, provide re-engineering of the components. Maybe reverse engineer it as a system when it is
ff
fi
released. Deal with migration. No changes to the product. But where the product is actually being
executed, you want to have the migration happen. Or maybe at times, certain scripts, certain
programs, certain areas need to be retired. Thus, we explored the software maintenance knowledge area.

Applications-Oriented Software Description

• Imagine teaching your grandmother remotely how to a use a smartphone.

• Can you help her learn some operation anew on the phone she is talking on with you?

• Can you help her try some operation on the phone she is talking on with you, without hanging up?

Operating the Systems and Operating Systems

• Workers, operators, cooks operate systems - lathes, engines, ovens.

• Medicos use systems by operating software interfaces for investigations.

• CNC operators program CNC lathes.

• Chefs use in-built cooking programs available with smart ovens.

• Intensivists organise monitors and online alerts and paramedics to keep abreast of critical patients'
conditions and stay prepared before potential emergencies.

Design Goals

• Lathes, engines, ovens are designed to be operated by workers skilled in manual operations.

• Medical instruments are designed to mimic visual operating modes that medicos are used to work in.

• CNC lathes, smart ovens, ICU systems are programmable and recon gurable.

• Chefs use in-built cooking programs available with smart ovens.

• Anyone heard the phrase plug and play?

Design Speci cations

• Manual or CNC lathe design needs specifying sizes, weights and shapes of tools and of raw materials.

• Engine design needs power and load demand speci cations.

• Ovens, manual or smart, are designed for ranges of temperature and weight of raw materials.

• Medical instruments and ICU systems are designed according to the needs of doctors and paramedics
of condition monitoring, accessibility and response.

• For all these, the speci cations are software, though not necessarily computer software. And not all are
programmable and/or recon gurable.

Adaptation v/s Adoption

• Adopting a tool requires training on it to acquire techniques for which it is designed.

• Adapting a tool for an application di erent from the tool's design goals requires an adapter that is more
versatile than the tool.
fi
fi
fi
ff
fi
fi
 Week-2
Software Lifecycles

Software Engineering Process

Engineering process consists of a set of interrelated activities that transform one or more inputs into
outputs while consuming resources to accomplish the transformation.

SDLC & SPLC

• Distinguish between software Product and Development
• Development: Target is the Software Product
• Product: Target is Software Product plus additional processes for:
• Deployment
• Maintenance
• Support
• Evolution
• Retirement
• An SPLC may include multiple SDLCs
• A life cycle provides:
• Temporal ordering among individual software
processes.
• Emphasis on the the key processes within the
model.
• Temporal and Logical Interdependence.
• Relationships.
• Entry and Exit Criteria.

• Co-located & distributed

• Teams and Subteams

Video Transcript:
Now, every life cycle has a temporal ordering among its individual software processes. What we call as the
activity one, two, three, and four shown on the diagram. And our emphasis is on the key processes within
such a model which would mean, are we doing requirements analysis as a part of software
requirements? Are we exploring the details of design? Or are we in a process where we want to look at
testing as our main activity? If you see that all these activities have an interdependence, there is a
temporal interdependence which would mean that there is a sequence to it. Activity two cannot be started
o without the closure of activity one. That is, activity one feeds into activity two, whereas you would see
that activity four and activity two can be done in parallel, because the output of activity one actually kicks
o the start of activity four and two, whereas the activity three, if it requires both outcome of activity two
and four, then there is a dependence. Otherwise, activity three can take input of activity two or activity four
and then one can continue the sequence. Of course, feedback within that particular activity or within the
particular phase, within the particular state, we are using these terms interdependently. We'll clarify those
as we go along. Each of these become interdependent and such interdependent actually leads
to relationships, and gives rise to what we referred to as entry, and exit criteria. What would it take for me
to start an activity is the entry criteria. What would it take for me to close the activity becomes the exit
criteria for that activity. One of the large motivational factors to divide some of the activities is the co-
location of the teams or distributed, that is geographically distributed or how the teams and the subteams
are organized.
Ultimately, there are going to be a set of team set of human beings who are going to work on these
projects which ultimately lead to a product or a part of the product.
ff
ff
Software Design Process

• It is viewed as "Problem-Solving".
• Generally, a two-step process:
• Architectural Design
• Detailed Design
• Architectural design provides a high-level and top-level design components.
• Detailed design describes the desired behaviour of the components.
• Leads to:
• Design decisions
• Description of design

Video Transcript:
Primarily, we view it as a problem-solving process. We look at it from two steps; the architectural design
and a detailed design. Architectural design will be at a high level, whereas the detailed design will be the
behavior of components, but at a lower level. By lower level, we mean it would become much detailed. At
an architectural level, it would start giving us major blocks which make up the particular application or the
software. Whereas in the detailed design, we start looking at each of the components that make up the
larger blocks at the architecture level, and we look at the behavior or the desired behavior of each of these
components. Just to take an example, if it is UI at the architectural level that we are looking at UI, we start
looking at speci cs of UI in terms of navigation in the details of it. Further detailing at a code level or a
user-experience level may be related to color. Or if you look at architectural design that we would use a
library for a purpose, at a detailed level, we would want to specify the behavior of that particular
library. Thus, this process will lead to two things. One, design decisions, and second, the description of
design, which would mean that all of this comes together as a package. As we looked earlier, this would
become an input to the next level or activity, which would be construction.

Software Design as Problem Solving

• "Wicked problem" is a problem with no de nitive solution.

• It is interesting in terms of limits of design.
• Without design one cannot guarantee an outcome of the entire process.
• Look for constraints and alternatives to meet the goal.
• If you think good architecture is expensive, try bad architecture. (Brian Foote & Joseph Yoder)

Video Transcript:
When we look at design as problem-solving, we really look at it from a perspective of a wicked problem; a
problem with no de nitive solution. If we really start from that level, we start getting into interesting limits
of design. These limits of design come in from a perspective that a problem can be explored to a very high
level, very larger level, but we now need to complete with nite resources of time, energy, and
money. Now, this can only be guaranteed when you go through the design process with its due
importance and details. Without such a design, one cannot guarantee an outcome of the entire
process. We got to look into the constraints, alternatives, ultimately, to meet the goal. As these two say, "If
you think good architecture is expensive, try bad architecture." Thus, it would be key to ensure that we
look at good design.

Software Process Adaptation

• The idea is to better serve the local needs.

• Adapt to local needs (tailored):
• Organisational context
• Innovations in technology
• Project size
• Regulatory requirements
• Industry practices

• Ways to adapt:
• Adding di erent details and procedures
• Alternative set of activities
• Omitting some of the processes or steps
ff
fi
fi
fi
fi
 Software Design Process

• Viewed as "Problem-Solving"
• Let's ask a set of questions:
• App on what platform?
• User operations?
• Storage locations?
• Sync contacts?
• UI Navigation?
• Interaction with other applications?
• Limits of storage?
• Rich content (pictures)?
• Communication between other apps?

Software Design Process (High Level)

Video Transcript:
Here let's look at a high level design, a high
level design which allows us to put certain
boxes together, and we call these as
boxes. Each of them are representing a
functionality. So on the screen what you have is
at the top level, the user interface. You would
see that the user interface is actually going to
interact very clearly with the application
logic. The application is going to work with,
de nitely the storage framework. All of this is going to interact with the application framework. And
imagine the services that would be utilized from the platform for all these operations. Needless to say, we
also might be talking about some of the features that we would require from the operating system.
Thus, for a variety of use cases, we would nd that these layers, if you will, are actually going to
communicate with each other, and each of these layers then are going to send messages. These
messages go from one point to the other, layer by layer, actually making certain applications happen. All
these individual calls will lead to what is shown to the user.
Ultimately as a part of the user interface, one would start re ning these with every question that you
ask. Even at a high level.

Software Design Process (Low Level)

• Platform APIs and Services:

• Design Patterns
• Storage APIs:
• Use of Database
• Use of Filesystem
• UI Framework
• UI Flows and Navigation
• Interaction with other Apps
• Behavior during particular scenarios

Video Transcript:
What would be low level then? The low level for us is now going to get into the behaviors of the
components. What would these behaviors entail to? Well, what exact APIs, what services? What are the
design patterns that would be used? Storage APIs? Is the storage going to be in a database? If it's going
to be database then we need to design queries.
If it's a le system, which we may need, de nitely yes. When we are going to store rich content. So the
database will only have the location as to where this particular rich content in the le system is located. UI
is going to be an extremely important component. Remember we gave it the top level large box there. That
would be UI framework. What are the UI ows and navigation? Now as we look at the interactions
and behaviors, so let me look at the entire application.
fi
fi
fl
fi
fi
fi
fi
Software Lifecycles & Phases

Software Development Phases

• A phase provides focus on a particular aspect of software development.

• It makes end result predictable and can provide a measure to progress.
• It increases the chances of success.
• It provides a checkpoint for course correction.

Phases in Life Cycle

• Life Cycles can be:

• Linear
• Iterative
• Agile

• Design as a Phase
• Phases in the Design Activity

Software Development - Terminology

• Lifecycle: A "start to nish" view of software or software product

• Phases (aka stages): Focus on particular aspect
• Levels: High and low level
• Activity: Focus on the actions to be taken for successful deliveries from a KA

Life Cycle Details

• Life Cycles can be:

• Linear: phases & stages
• Iterative: feedback loops
• Agile: working software

• Lifecycle of a particular focus area:

• Software Development Life Cycle
• Product Development Life Cycle or Software Product Life Cycle.

Video Transcript:
Life cycle, phases or stages, levels, and activity. Let's get into life cycle and phases and activities. We
looked at three kinds of life cycles, at least named them, linear, iterative, and agile. What would linear
primarily mean? Linear would mean it moves from requirements, design, implementation, or development
or construction, test, and probably gets into maintenance phase. Iterative would provide us the feedback
loops, so each of these phases in a circular manner would allow us to build the software, so we iterate up
if we call it as iterating up. Agile, primary focus of every sprint is going to be to get working
software. Slowly, from one sprint to the other within the larger life cycle, we go on building the
software and expanding it with respect to features, with respect to what the software can do, and the
capabilities of the software. All of these form part of the entire life cycle. We'll look at two, the software
development life cycle and a product development life cycle or a product life cycle, the SDLC, and the
SPLC. With the outcomes of SDLC being the product, and for SPLC, being the entire cycle, even
maintenance and retirement of the product would be included, thus it's a larger view that we have. Now,
all of these life cycles can be tailored, we'll look at it from how and what phases we would have, and
within linear iterative, and agile, we could have a mix of these in a larger scheme of things, with respect to
the entire product. Let's take an example. Say we have a software which is going to be developed over a
period of 18 months and with a team of about 250 engineers, geographically distributed. The local
software process could be agile, the overall software process could be linear, the life cycle could be
linear, and within this framework, you may have certain areas which become iterative. Iterative at a
level because we know what exactly needs to be developed. Agile, at a level of team, because we need
working software to be integrated together in an iterative manner ultimately to release the product. You
can see that even within linear iterative and agile, you could have a mix and match or tailor it for your
purpose. While we look at the entire life cycle for product or for software development, we could even
fi
 de ne a life cycle of a particular focus area. Say, secure development life cycle. We're looking at the
secure aspects of a particular software or a software product, or a product testing life cycle. A completely
ready release comes in and there's a product testing life cycle with its own phases, activities, levels. In
general, if you really look at it, life cycles give you a tremendous amount of framework, very predictable,
end to end to build the software.

Importance of Life Cycle

• De ne the Life Cycle at the beginning of the project.

• Feedback at regular intervals to make it better.
• Each phase, activity, and level de nition helps build a "road" to destination.
• Provides a communication method among team members.
• Clarity of the path!

Video Transcript:
How do we now deal with a life cycle? It is important that such a life cycle, which is appropriate for the
project at hand be decided at the beginning of the project. Make it a point to review the entire life
cycle, and bring in feedback to make it better. Of course, you don't want to take too frequent feedbacks
that ultimately the team is confused or it leads to chaos. Look at reasonable intervals to get the most
appropriate feedback where project managers and the management team should closely look at what
is being deployed and how e ective the current processes are. De ne phase, activity, and level, which
ultimately will provide a road to destination. You want to take your software from point A to point B to be
successful. While all this gets de ned, it does a very primary purpose, allows superior, accurate, precise
communication among the team members. What phase you are in? What stage you are in? What kind of
life cycle have we chosen? They provide an entire working framework for the team. In general, it provides
clarity of path to move ahead.

Software A "Living" Entity

• Software: like a "living" entity undergoes a dynamic lifecycle inception, growth, maturity, and evolution
(end of life too).
• Phases: structured progression of essential phases, each playing a distinctive role in the development
journey.

Life Cycle and Phases

• Similar to the intricate life cycle of organisms, software undergoes structured phases from inception to
maturity.
• For instance, in the design phase, the software blueprint is meticulously crafted, resembling the
architectural planning crucial for the subsequent stages of its dynamic life cycle.

Importance of Life Cycle

The software life cycle unfolds as an orchestrated symphony, where each phase plays a crucial role.
Design acts as the guiding conductor, shaping a harmonious a melody of functionality and elegance that
resonates seamlessly throughout the dynamic stages of software development.

Elements & Levels of Software Design

Elements of Software Design

• Architecture:
• Conceptual level that de ne structure, behaviour, and views of a system.

• Components:
• Provide a particular function or group of related functions.

• Modules:
• Typically handle one speci c task in a system.
fi
fi
fi
fi
ff
fi
fi
fi
 • Interfaces:
• Shared boundary across which components exchange data/information.

• Data:
• Flows between Modules and Components.

Software Design Activities

• Architectural Design
• Interface Design
• Detailed Design
• Component
• Module
• Data
• Top-Down
• Bottom-Up

Video Transcript:
Here, design in our discussion for this slide would actually mean that it is a verb, you're in the activity of
design. It's not the document or the outcome, but architectural design, the act of putting those blocks
together, the act of looking at a pattern, something that worked in the past. We have an experience of
it, so you draw from that architecture and prepare an architecture for the problem at hand. By enlarge, you
would nd all the contacts applications may look similar. All applications which are about calling app on
the phone would look similar. By enlarge, you would see that all word processor would look similar. Now,
that's where architecture comes into play. There's an anticipation of what it can look like, and in fact, they
start looking similar because that is how you would want the user experience to remain consistent. The
interface design. Most of the time, the interfaces will be practically hidden, other than the interaction of the
user with the system. These interfaces will be those APIs, ways and means of one module, one
component connecting with the other module and the other component to exchange data to get services
to make things happen. Breaking these down in terms of functionality, how and what these interfaces
would look like, like we mentioned about updates to the contacts, or we are saving a document either
locally or we are saving it on the Cloud. All of these would start requiring certain interfaces. To make all
this happen, there is detailed design of component module, and even the data, format of the
data, function and behavior of the module, functions and behaviors of the components. All of this needs to
work in a symphony to make things happen. We have looked at those examples of a contacts
application, or maybe an IoT system, or we looked at the orange as an application. Now, one of the key
aspects is all these design activities can be done, either top down or bottom up. Top down would mean
that we take up the entire one box, break it down into manageable pieces in terms of its functionality and
how do we really provide responsibility to each of the boxes, and then keep on drilling deeper and making
each of the boxes in detail, providing its own interfaces and data. Or it could be bottom up. We pull these
available components together, piece them together and start building the entire application. We could go
top down or bottom up or maybe as one would call it a sandwich approach. But all said and done, you
would start building an application, a piece of software, either top down or bottom up, considering all
these elements and activities which put all of them together.

Levels of Software Design

• Classically, the High Level Design, and

• Low Level Design
• HLD: "blocks"
• LLD: "details"
• HLD: components as organised
• LLD: behaviour of components
fi
 Architectural Structures & Viewpoints

• Views: Di erent high-level facets of software design.

• A view represents a partial aspect of software architecture that shows speci c properties of a software
system or product.

• Logical View: satisfying the functional requirements

• Process View: concurrency issues

• Physical View: distribution issues

• Development View: how design is broken into implementable units?

• Architectural style:
• A specialisation of elements and relation types. a together with a set of constraints on how they can be
used.

• General structures providing software’s high-level organisation.

• Examples:
• Layers
• Pipes & Filters
• Model-View-Controllers

Software Design Principles

Abstraction:
O View of an object that focuses on the
information relevant to a particular purpose
and ignores the remainder of information.

Coupling and Cohesion:

Measure of interdependence among the
modules in software.

Decomposition and Modularisation:

Large software divided into smaller.
manageable, and well-de ned parts that
interact well with each other.

Encapsulation and Information Hiding:

O Grouping and packaging the internal
details.

Separation of Interface and

Implementation:
Provide a public interface and hide the
implementation.

Su ciency, completeness, and primitiveness:

o Covers all important characteristics
• Easy to implement

Separation of concerns:
Concern is "an area of interest"
• Separation provides focus for
stakeholders
ffi
ff
fi
fi
Video Transcript:
What is abstraction? It's a view of an object that focuses on the information relevant to a particular
purpose and ignores the remainder of the information.

It's a focus that we bring in and in fact, things abstract to a certain level. Abstraction related to, say, lists,
for example. Coupling and cohesion is a measure of interdependence among the modules in
software. While we de nitely don't want full dependence, de nitely they're going to be interdependent and
how they function together to make something happen. And a healthy interdependence is required for
high-performance software. Decomposition and modularization, here, large software is divided into
smaller, manageable, well de ned parts, and once they are in parts, you want to make sure that they
interact with each other. And this decomposition and modularization not only provides help to manage it
technically, but also managerially because it could be distributed among team members. And really, in that
virtual sense, you could have these teams which are associated with each of these components and
modules which ultimately interact with each other. Encapsulation and information hiding, right out of our
object-oriented programming concepts, or object-oriented design methodologies.

We want to group and pack things together in such a way that I provide an interface to connect. But how I
do it is hidden. So it allows me to change the implementation whenever I want it without really changing
the entire method to access. That's one, the second, the only way to access information is through these
methods. Hence, I have hidden other information. I only expose what I would like to expose to the
application that is going to look for information.

And lastly, separation of interface and implementation, which is about what would be a public interface,
completely available for anybody who uses this particular module or a component. And the information is
either encapsulated or it is abstracted and the implementation is entirely hidden. Su ciency,
completeness, and primitiveness. We want all our designs, at a method level, at a module level, at a
component level, to be su cient and complete, covering all important characteristics. And again,
primitiveness would be easy to implement. That is what we need to get at. Easy to implement, easy to
implement, easy to maintain. That becomes a way in which we move forward. When we look at the
SPLCs, the software product life cycles, we also want to build in separation of concern. Concern in this
context is an area of interest, and once you separate these in manageable areas, it provides a focus for
stakeholders.

Say one of the concerns is security, data interfaces. Each of these could become concerns and area of
interest and can be dealt with by those experts, stakeholders, developers, business people, all of them
coming together. You would have seen that there is a variety of things top down, and we have also looked
at the design principles now.

So with these design principles, when you apply the views and elements and levels for a particular
application, you would see that it becomes a complete methodology for us to not only create the
design. But also to evaluate the design and provide that feedback from one activity to the other. And while
we did this, we also learned to apply all of these in a software design

Learn with Examples

fi
ffi
fi
fi
ffi
 Week-3

Object Oriented Design Fundamentals

What is Object-Orientation?

• Design and programming focused on things that are programmable.

• Possible only after Problem-Solving.
• Like detailing of windows, doors, plumbing, electrical ttings, ventilation and lighting.

Why Object-Orientation?

• Not one application, but all possible applications.

• Modularity.
• Readability.
• Maintainability.
• Reusability.

Video Transcript:
Why object orientation? Mainly because we are not designing for one application, even though the
problem solving that we did might have been done for one application. But the detailing that we did told
us that all these building blocks can give you many di erent solutions to many di erent problems, but all
of them will be built on the same foundation. So this socket that you are seeing, this is a universal
adapter. This can take in any kind of a plug pin that is used in any country, anywhere. So this is what we
want to build, such objects which have those versatile properties, then modularity. Because once we
design in an object oriented fashion, the modules will be independent of each other. And that means they
can also be developed as well as maintained by diverse teams who may not be even communicating with
each other. And because the software also becomes more readable and that's why it is readily
maintainable and then the same component, the same objects can be reused or re ned for another
application easily. The design approach will be bottom up. That is once problem solving is done, we have
all the wherewithal put on the table.

OO Design Approaches

• Bottom-up: Once problem-solving is done, design the things needed as parts of the solution.
• Object behaviour is designed by the "contracts".

• Class Model.
• State Model.
• Interaction Model.

Video Transcript:
What are the di erent things that are needed as building blocks of the solution? Then these objects or
things, their behavior is designed by the contracts. That means what is expected of each of them in
response to certain inputs and certain triggers or events. To make this design, we make a class model that
means basically the di erent properties of the di erent kinds of objects that we are building up from. Then
the state model which will give us the overall system state, depending upon the states of these di erent
objects. The changes in their behavior or mode and then the interaction between these objects and then
the larger system components built up over them, these will be for designing in an object-oriented fashion.

OO Design and OOP

• Using an OOP Language is not necessarily OOP.

• De nitely it is not OOD.
• OO Thinking must be underlying both design and programming.
• The design guides the programming, and not the other way around.

Video Transcript:
The relation between object oriented design and object oriented programming is many times
confusing. Using an object-oriented programming language is not necessarily object oriented
fi
ff
ff
ff
ff
fi
ff
fi
ff
programming, this is one thing. That is you may program in a very haphazardous or chaotic manner,
but you are using an op language. That doesn't mean it is op as in object oriented programming. De nitely
object oriented programming, whether done well or badly. Still it is not object oriented design. Object-
oriented thinking must be underlying both design and programming. The design guides the programming
and not the other way around.

OO Design Modelling

• UML
• Class diagrams
• Use-case diagrams
• Links and associations
• Concerns and aspects
• Contracts

VIdeo Transcript:
So to use di erent models to make di erent models for object oriented design, we have UML universal
modeling language. Of course, UML itself is so growing, so evolving and it is not a very xed set of
rules. So you can have your own adaptated UML for modeling your software as long as the visual
representation and the interpretation is obvious and it is like consistent with the typical interpretations
prevailing in the eld of software development, then there are class diagrams. Within UML, you have class
diagrams which will give you the hierarchy and di erent relationships between di erent classes of
objects. There are use case diagrams which basically tell us the control ow of the application, of course,
with interaction with end users or with the external entities or the di erent networking entities that are
involved in the application, then there will be links and associations between objects. We are not talking of
now the networking entities, their links and associations. We are talking of the links and associations in the
design, in the object oriented design. So there will be di erent objects, they are linked to each other. For
example, if a student is registering for a course, then there will be links to other courses which are
prerequisites. There are links to other courses which will be then obviated. That means the student cannot
take two courses at the same time of some certain kind. So if one course is chosen, the other course will
be then not available for the same student. So if you are designing an ERP system, academic ERP system
for a university, then there will be links and associations between di erent courses and students and their
students eligibility, their earlier courses taken, and all that. Then there will be modeling of concerns
and aspects which will grow across di erent objects, di erent subsystems, di erent components of the
system and so on and there will be contracts. That means what each object and the components, they are
supposed to do, behave, respond in certain situations and events and triggers.

Languages

• Java, C++
• Python, C-LOS Common Lisp Object System
• C/C++ for Systems Programming

What is Abstraction and Encapsulation?

• Identify what is "programmable" in a thing or an idea.

• Bundle the content (structure) and form (behaviour) together into data and operations (members and
methods).
• Thought experiment: sorting books and student records.

Example

• UG students can be teaching assistants.

• Teachers can become (graduate) students.
• Graduate students can be teachers elsewhere.
• Personal attributes and role attributes.
ff
fi
ff
ff
ff
ff
ff
ff
ff
fl
ff
ff
fi
fi
Why Abstraction?

• Generalization and Specialization: complementary

• Cleanliness and clarity
• Consistency
• Readability, Reusability, Maintainability

Video Transcript(topics covered till now):

What is abstraction encapsulation? You identify what is programmable in a thing or an idea, and bundle
the content, which we can call structure and form, that means behavior together of, say, a type of things
into data or attributes and operations, which are also called members and methods. Do this thought
experiment sorting books on a shelf and sorting student records in a document. Books will be sorted on
their titles, which are visible on the spine of the book and student records will have keys, which are roll
numbers, for example, which will appear on the left-hand side of each record and in the document, they
are occupying one row each. What is common in sorting each of these? You're sorting books on the
shelf, you're sorting student records in the document. You do these experiments, you'll understand
now what is the abstract idea of sorting, and then can you encapsulate it? Think of this. Another example,
UG students can be teaching assistants then teachers can become graduate students graduate
students can be teachers elsewhere, not in the place where they have enrolled as students. That means
the same person can have di erent roles in di erent situations in the same place or di erent places and if
you are building an ERP system in which each person will be assigned a role according to the
situation, whether the person is enrolled in a course as a student there or the person is assisting in
teaching or teaching such a course, depending upon that rules, and accordingly, their authority, their
accessibility, duties, rules in di erent actions, all these will be decided and then facilitated or allowed in
the ERP system. Personal attributes and the di erent attributes of those di erent roles, you will have to
separate and to separate rst, you have to encapsulate. You have to abstract them away. Why do we do
abstraction? Because without this generalization and specialization, these two complementary
concepts, we cannot actually make the design clear and consistent. Becomes readable, reusable,
maintainable. These are the key attractions why we do object design in the rst place. This is possible only
with abstraction. Look at this universal adapter. This encapsulates the idea of in general, plug pins being
inserted in the socket. This allows di erent kinds of pins that can be inserted in this. This encapsulates the
idea of plug pin and socket connection for electrical power transfer.

Polymorphism: What?

• The same object takes "di erent forms".

• The class model characterizes all the possible forms.
• Particle and wave duality.
• This is not like life stages (caterpillar, cocoon, butter y).
• Scope rules and data hiding.

Why Polymorphism?

• Modularity at a ner level.

• Clarity and consistency.
• When in Rome, do as Romans do.

When to Encapsulate and Specialize?

• If many objects share form and behaviour, encapsulate.

• If many objects di er from many other objects in a common way, specialize.

Video Transcript(topics covered till now):

What is polymorphism? The same object taking di erent forms. That means a student can become a
teacher in a di erent situation, even though the object that started the record for that particular person is
the same. The class model, that means the di erent classes and the interrelationships, the hierarchy or
even interaction between them. This model will characterize all the possible forms that any object can take
and some objects when they are taking one form, then they will not be allowed to take another
form unless the situation is changed. The mode of operation, not only of the object of the system is
changed. All this will require basically allowing the same object to take di erent forms depending upon, of
ff
fi
ff
fi
ff
ff
ff
ff
ff
ff
ff
ff
fl
ff
ff
fi
ff
 course, some kind of interaction and triggers. You can think of this particular wave duality in which light
rays can behave either as particles for example, this happens in a photo tech cell or they can behave as
waves that happens in, for example, interference in physics. But this is not like live stages. Caterpillar,
cocoon, butter y, these are sequential stages, and you cannot reverse those stages. Again, we have to
think of scope rules and data hiding in polymorphism, because in di erent forms in di erent situations, the
attributes of the objects that can be visible will not be the same. Certain things will be hidden and certain
things will be revealed in the di erent forms, in the di erent situations, in the di erent modes of operation.
Why do we do this? Because we cannot achieve modularity at a nal level without this. More clarity, more
consistency can be obtained, and winning room do as Romans do is not possible without
polymorphism. When do we start generalizing and when do we start specializing? If many objects share
form and behavior, then we encapsulate them into one class. We say this concept is it. If many objects
di er from many other objects, otherwise, sharing some other properties, but then there is a discernible
di erence between two groups within the same class. We specialize, we call them two subclasses or it is
also possible that only one subclass in a given larger class will di erentiate themselves, will distinguish
themselves. Again, we specialize. These are all the key concepts regarding object-oriented design

Why OO Languages?

• They give sca olding for OO design and development.

• Pattern-oriented design and development is facilitated by such paradigmatic languages.
• This guidance and patterns help us learn standard practices and reduces the chances of inadvertent
errors.

C++

• The program is entirely made up of global functions and modular classes.

• O ers a lot of exibility in typing.
• Encapsulation of generic operations is implicit.
• Allows multiple inheritance.
• Produces less portable binary executables.

Java

• The program is entirely made up of global classes.

• Every function is a method of some class.
• Compiles classes to bytecodes.
• Needs a native virtual machine to run.
• This allows more portability.
• Has no multiple inheritance but has interfaces.

Python

• Combines many features of C++, Java, Lisp.

• Functional OO.
• Evolved from scripting.
• Typing is dynamic.
• Evolving irregularly and often without downward compatibility.
• Easy to learn to begin, but hard to learn to use professionally.

Comparison: Java and C++

• Java discourages implicit type coercion, C++ encourages.

• No two implementations of the same type possible in one program. C++ allows.
• Java has no diamond problem, C++ has.
• Memory management is implicit in Java, C++ needs explicit memory management.
ff
ff
ff
ff
fl
fl
ff
ff
ff
fi
ff
ff
ff
 Choice Criteria

• C++ is most suitable for systems programming and compute-intensive iterative applications.
• Java is most suitable for human-interactive applications.
• Python is used mostly for scripting at the deployment level: integration.

Video Transcript(covering from comparison topic):

Comparison between Java and C Plus Plus. Java will discourage implicit type coercion and C Plus Plus
actually encourages. Typing in C Plus Plus is more dynamic, more exible. No two implementations of the
same type possible in one programing Java, whereas C Plus Plus allows that. Java has no diamond
problem. C Plus Plus has. The diamond problem is when you have multiple inheritance from some one
base class again. Several derived classes of one base class can again become base classes for further
derived classes. Then there will be this question of which base class object they will defer to because
there can be several at a time copies. This problem Java is not there. Memory management is implicit in
Java. It is done by the virtual machine, whereas C Plus Plus will need explicit memory management if you
are using too much memory. Python compared to both Java and C Plus Plus is di erent in mainly
typing. Types are to values not variables. There is this idea of duck typing. That means basically if it
quacks like a duck, if it swims like a duck, then it is a duck. That means types are inferred, not
declared. We look at an object and then ask questions of that object. That means we will try to call
methods or we'll ask whether this method is available with you. Then it says, I can quack like a duck. Then
we say, you are a duck. We don't bother what type name it was given in the beginning when it was rst
de ned or instantiated. That is the material anyway, because there are no declarations of that kind, and
functions themselves can be objects in Python. Now, how to choose, C Plus Plus is most suitable
for system programming and compute intensive iterative applications. Iterative means you are
running them each time millions of times. You are having an interface to a large data set, and then you are
just trying to search and then extract something, lter out something, and this is done again and
again, again and again in some application. Then C Plus Plus is most suited. It is basically most e cient
also. Java is not that e cient, so it is suitable for human interactive applications, and it is portable
also. You can write the same program simultaneously that will work for mobile phones, small screen, a
tab, and also a laptop, and a large screen. Java is most suitable for such applications. Python is used
mostly for scripting at the deployment level. That means you already have di erent software packages and
the services available. Some of them are online, some of them are native to your machine. You can write a
Python script and you can have an integration of all of them into one application on top of them. Python is
still used like a scripting language, but of course, with more sophistication, because you can organize the
same integrated system much better. You can also repeatedly use it. You must have used those python-
ipy in the notebooks for machine learning on Google Colab. Then you know what I mean by this
integration, and you can use them repeatedly. This is all for object orient programming languages.

Software Design: An Object Oriented View

Why Learn Design Principles?

Brooks: "the hard part of software development is the manipulation of its essence, owing to the inherent
complexity of the problem, rather than the accidents of its mapping into a particular language.”- The
Mythical Man-Month, Chapter 16.

The Objectives of SDP

• Exploiting the mass market to avoid constructing what can be bought.

• Using rapid prototyping as part of a planned iteration in establishing software requirements.
• Growing software organically, adding more and more function to systems as they are run, used, and
tested.
• Identifying and developing the great conceptual designers of the rising generation.

Video Transcript:
This is why we should learn design principles. Because we want to design, then we need some principles
also to guide us. Brooks who wrote this Mythical Man-Month book, he says, "The hard part of software
development is the manipulation of its essence, owing to the inherent complexity of the problem, rather
than the accidents of its mapping into a particular language." He's di erentiating between essence and
accidents. Accidents, he means that are the contingencies of the situation. Like for Konkan Railway for
fi
ffi
fi
fl
ff
ff
ff
ffi
fi
alignment, they couldn't send out large vehicles and also they couldn't have the equipment spread
everywhere across the route. So they used bikes and modi ed those bikes. These are accidents in the
sense that they are contingencies, solutions to problems which just arise out of the situation. But that is
not the essence. When we want to design something, we don't consider all possible accidents or
contingencies. Before that, we rst focus on what is the essence. This essence can be then identi ed as
objectives of software design principles rst. Exploiting the mass market to avoid constructing what can
be bought. Railways were building bridges and they were also building tracks in di cult terrain like
Konkan Railway. But then you should also be able to source from what is available o the shelf rst and
then you meet the challenges which are not already solved, solutions to which are not already
available. Using rapid prototyping as part of a plan iteration in establishing software requirements. This is
one of the important objectives. Because when we say development, we are talking of manufacturing-like
production of software. We need that production of several copies of some uniform object. This is where
rapid prototyping comes in. Now, we have to also then let that software grow organically. That is, it's not
only making uniform copies of something that is trivial. Again, we also want it to be functionally really
much more complex, much more e cacious. That means it can do many things, not just some ordinary
trivial thing repeatedly. We want that software to grow organically.

Then we need to identify and develop designers who are conceptual designers. That is, those who go
through these processes. Initially, they may be mundane processes, but then this will make them think
over what is essential and how to abstract it away and so that they can become again, conceptual
principles for further designs, such that many of the earlier iterations of trial and error can be avoided, and
we can directly go to some predictable standard reliable design. That will be the last objective. This
process also itself is it iterative.

The Challenges

• The Essential: the di culties inherent in the nature of the software.

• The accidental: those di culties that today attend its production but that are not inherent.

The Essential

• Construction of interlocking concepts: data sets, relationships among data items, algorithms, and
invocations of functions.
• Uniformity and diversity: The conceptual construct is the same under many di erent representations yet
highly precise and richly detailed.

The Tension

• The hard part of building software is the speci cation, design, and testing of this conceptual construct,
not the labor of representing it and testing the delity of the representation.

Video Transcript:
The challenges to this will be how to separate the essential, the di culties inherent in the nature of
software, depending also on the applications that are sought and the accidentals. Those di culties that
today attend its production, but they are not inherent. They may change when the way we produce or the
tools, the technology is available to us, hardware changes. Then the challenges will of course
change. These are the accidentals. When I studied C++ for the rst time, the time needed to compile one
program used to be half an hour. We don't have that challenge now. The essential will be identi ed as
construction of interlocking concepts. In software data sets, relationship among data elements, data
items, algorithms, and invocation of functions, these are the di erent interlocking concepts, and they will
appear in object oriented as well as other programming paradigms. Or even if you are doing assembly
language programming, these concepts will still be there, and you have to consider the interaction
between them. Uniformity and diversity will arise because the conceptual construct is, again, even though
it is the same under many di erent representations, but it is precise and ritually detailed. That is, you can
achieve the same thing in many di erent ways with many di erent languages and paradigms. You have to
again, consider the essential also in all its various forms in which it will appear. The hard part of building
software is that speci cation, design, and testing of this conceptual construct, not the labor of
representing it or testing the delity of the representation. That means, there may be many ways of
representing each time, which representation to choose and then testing whether the representation
ffi
fi
ffi
ff
fi
fi
ff
ffi
fi
fi
fi
fi
ff
ff
fi
ffi
ff
ffi
ff
ffi
fi
fi
fi
 obtained is indeed what was expected or what was designed. That is not really the main part or the hard
part. That becomes the heart part only for the beginners who are not yet adept and whose habits have not
become standard practice. But the hard part in design is the speci cation and testing of the conceptual
construct. That is the beginning of software design principles.

Conceptual Clarity

• Consider the scenario when you are in a team sorting all the shelves in a library.
• And another wherein you are planning the library's stocktaking procedure.
• and then drawing up a set of instructions for the team that will carry out the procedure.
• Suppose you only explain the idea of what is stocktaking to the team.
• They are on their own, dividing the task by shelves per person.
• You plan a division of labour by tasks: while (a) is sorting books on each shelf, (b) scans the barcode,
telling (c) to mark on the online catalogue.

Conceptual Integrity: Which of the two DoLs is

• Less error-prone?
• Faster to execute?
• Easier to "debug" or rectify errors in?
• Easier to train the team for?
• Easier to manage by having team members getting replaced by others or interchanged in shifts?
• Less costly in terms of "person-hours"?
• Less dependent on the team size?

Video Transcript:
Consider the scenario when you are in the team sorting all the shelves in the library. Now, this is for stock-
taking. You are planning the stock-taking procedure, and you want to draw up a set of instructions for the
team that will carry out the procedure. This is what is called software and software design. Suppose you
only explain the idea of what is stock-taking to the team this is like having a conceptual integrity with
everyone in the team, and then they are on their own dividing the task by shelves per person. Each person
will carry out the sorting for each shelf, independent of others. There is another scenario or another way of
doing this. You plan a division of labor by tasks. One person is sorting books on each shelf, another
person scans the barcode and tells a third person to mark on the online catalog so you have this division
of labor by tasks. Which of these two divisions of labor is less error-prone, faster to execute, and easier to
debug or rectify errors in? This will be for each person who is given each task. Then for the whole
team, easier to train the team for, easier to manage by having team members getting replaced by others
easily or interchanged in shifts, less costly in terms of total amount of labor time, that means each person
say works for some n hours, then n into the number of persons will be your person-hours and which one
of them is less dependent on the team size such that you can increase or decrease the team depending
upon your contingencies and need, and yet you can be sure of how much time it will take and how it will
go, whether it is error prone or you can rectify the errors easily, and so on. So for these questions,
now, you have to be able to capture the essence of your task and the ultimate procedure such that you
really know that there is conceptual integrity and consistency. You have to give emphasis on
everything, and then what breaks under its weight is a shell or a covering the hard nut, which is the
essence or the kernel inside.

The How Questions-1

• How to capture the essence of anything? “Give emphasis on everything, and, what breaks under its
weight is a shell or a cover; the hard nut is inside."

• Emphasis: measured, guided by semantics of the labour.

• How to achieve conceptual integrity? "Ease of use is enhanced only if the time gained in functional
speci cation exceeds the time lost in learning, remembering, and searching manuals.”
fi
fi
The How Questions-2

• Occam's Razor: "if you have two competing ideas to explain the same phenomenon, you should prefer
the simpler one.'
• Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of
system design.
• But: Neither function alone nor simplicity alone de nes a good design.
• Achieving the balance is abstraction, maintaining it is design planning.

The Tests

• For a given simplicity level, achieving the "maximum function" is a design goal.
• For a given function, the design that is most simple to explain to the implementers and users alike
("straightforward") is the best.
• In Maths-like disciplines, this is like “postulates are the most obvious to everyone”.

Video Transcript:
Now, what is this emphasis? It is a measure which is guided by semantics of the labor, of the task. That
means you have to really understand the task before you formulate it for the team's instructions. How to
achieve this conceptual integrity. Here is the test. Ease of use is enhanced only if the time gained in
functional speci cation exceeds the time lost in learning, remembering, and searching manuals. That
means if the team is asking you supplementary questions during the process when you are explaining to
the team giving instructions or later when they are carrying out the task or they keep making errors, and
you have to go and explain them again and again, you have to train them again and again then there is no
ease of use in your instructions. Here is the test expressed in again, an abstract way Occam's Razor. It is
attributed to one 14th-century William Ockham researcher. If you have two competing ideas to explain the
same phenomenon, you should prefer the simpler one. Now, because ease of use is the purpose, the ratio
of function to conceptual complexity is the ultimate test of system design but neither function nor
simplicity alone will de ne a good design. Achieving the balance is abstraction maintaining it is design
planning. The test also can be given in another term. For a given simplicity level, achieving the maximum
function is a design goal. But for a given design, then, the design that is most simple to explain to the
implementers and users alike, we can call it straightforward is the best. Implementers and users, like the
team who is doing the stock taking and for example, your boss asking you, is the stocktaking done? Have
you really satis ed yourself that it is done correctly? No errors are there in it, and so on. If it is easy to
explain, then it is simple enough. In disciplines like maths this is expressed like postulates are the most
obvious to everyone. That means they don't need any explanation further. If your essence is captured in
those primitives, which are most obvious to everyone, then that is another test of its simplicity and
consistency. In summary, conceptual integrity is achieved only through abstraction and simplicity, and
economy of language. That means you don't have to explain too much is the hallmark of a good
abstraction. A good abstraction leads to a better plan for maintaining conceptual integrity.

Balancing

• To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing
minds.
• Separation of architectural e ort from implementation is a very powerful way of getting conceptual
integration on very large projects.

Maintaining Conceptual Integrity

• If a system is to have conceptual integrity, someone must control the concepts.

• That means leadership roles are clearly de ned.
• Even if the same persons are in leadership roles and implementing teams, the roles must be separated
and sequenced in time.
• "Alter-egos" can be considered.
fi
fi
fi
ff
fi
fi
 Communication-1

• Much of software architecture, implementation, and realisation can proceed in parallel. Hardware and
software design can likewise proceed in parallel. But coordination and planned communication are keys.
Feynmann's Computing Team at Los Alamos.

Communication-2

• Early and continuous communication can give the architect good cost readings and the builder
con dence in the design, without blurring the clear division of responsibilities.
• The builder has the creative responsibility for implementation; the architect only suggests.
• Alternatives should be sought and discussed; each choice should be an informed decision.
• Each deviation or change of choice must be discussed before and after.

Communication and Cohesion

• The design choices must be reduced to writing by one or two, in order that the mini-decisions be
consistent.
• Explicitly de ne the parts of an architecture that are not prescribed as carefully as those that are.
• Give a formal de nition of a design, for precision, and a prose de nition for comprehensibility. One of
them must be standard, and the other derivative. Either de nition can serve in either role.

Discipline

• Direct incorporation is a very clean technique for enforcing an architectural standard in software.
• In architecture, the de nition will be cleaner and the discipline tighter if at least two implementations are
built initially.
• Communicate or discuss informally, but log and record everything formally.
• Veri cation must be independent of design and implementation.

Modular Design Strategies

Layering-1

• De ne the abstraction criterion for grouping tasks into layers.

• Determine the number of abstraction levels accordingly.
• Name the layers and assign tasks to each of them.
• Specify the services: The most important implementation principle is that layers are strictly separated
from each other, in the sense that no component may spread over more than one layer.
• Re ne the layering by iterating over the previous steps.
• Specify an interface for each layer.

Layering-2

• Structure individual layers.

• Specify the communication between adjacent layers.
• Decouple adjacent layers: top-down and bottom-up communication.
• Design an error-handling strategy.
• Specify an interface for each layer.

Typical Examples

• Virtual Machines.
• APIs.
• Web Portals of large organisations: multiple services from multiple servers and service providers
presented In one web address.
fi
fi
fi
fi
fi
fi
fi
fi
fi
Video Transcript:
how do we de ne this together? All these tasks together is a layer. We need that abstraction
criterion. Taking the analogy of sorting again, we need to look at what is sorting of books and what is
sorting of data, what are the keys, and then what is the sorting process? In that, there will be di erent
layers of tasks. Determine the number of abstraction levels accordingly, name the layers and assign tasks
to each of them. This naming is important because then the tasks will be called by those names, and
people who are carrying out di erent tasks also maybe then assigned, they will have those labels
according to the tasks. For them, also, when they change their roles, it will be very easy to go into the
groove, and specify the services. The most important implementation principle is that layers are strictly
separated from each other in the sense that no component may spread over more than one layer. Re ne
this layering by iterating over the previous tapes. Re ne means that if there is some ambiguity, some
vagueness between di erent layers or the abstraction seems to be overlapping, then again, try to
separate, and that means re ning this layering. The previous four steps have to be done in some cyclic
manner until you are satis ed that the separation and re nement is now no more needed than it is, and
then specify an interface for each layer. This is the most important criterion to decide that layering is
now done well and with the required nesse.

Then structure the individual layers. That is, all implementation cannot be completely independent, even
though the layers themselves are independent and abstractions are quite separated from each other, still,
there can be and there needs to be many times some structure which is common to all of them, the way
implementation will happen. If you're sorting books and you are doing them in place, then even the
scanning of the barcode and then marking in the catalog, there have to be clues to the shelf and to the
person who is actually handing the shelf movement. Now, specify the communication between adjacent
layers. When they are to be closed, we say, that means you are specifying how they are going to
communicate to each other. In the library, for example, is it by gestures, is it by a xed procedure, or they
have to call out each time. Decouple adjacent layers. That it's top-down and bottom-up communication
has to be decided very clearly. Now, top-down communication means basically how services will be
obtained from lower layers. Bottom-up communication means there will be callbacks. That is when, for
example, we have asked somebody to carry out a sub-task, and then we are also carrying out some other
tasks at a higher level. Then the lower level will wake you up saying, this task is complete, now you can
ask me the next, or you can go towards the next step in your higher level task. Design an error-handling
strategy. Otherwise, the separation between the layers will not work. Then specify an interface for each
layer. This speci cation is like documentation. Typical examples of such a layered systems will be virtual
machines, which present you some a view of a machine and the programmability of that machine will
be what is o ered as primitives from that machine, not the actual hardware on which it is implemented. Or
you can even present a virtual machine that is actually obtained from several di erent machines in a
network. Then there are APIs, application programming interfaces. They also give layered interface to a
layered system. Web portals of large organizations. Multiple services from multiple servers and service
providers are presented in one wave address. Sometimes they even warn you when you click on a
particular service, this is actually taking you to another website. That actually means that those servers
are not in the control of the main wave address where you started, so there is the separation of roles and
responsibilities.

Dividing to Conquer

• Each level must be simpler than the lower ones, and more rigorous than the higher ones.
• Identify common tasks in the lower levels, thus, the division need not be tree-like.
• Composability: Each level and each task at each level must have an integral identity and interface Of its
own. Complex interdependence and interaction must be planned at higher levels.

Stepwise Re nement

• For each level, focus on the tasks bottom-up.

• For delegating tasks to any lower level, focus on the top-down design.
• Interface and testing criteria ("contract") should be provided to both higher and lower levels-to the
former as a promise and to the latter as a requirement.
ff
fi
fi
fi
ff
fi
fi
ff
fi
fi
fi
ff
fi
ff
fi
 Video Transcript:
Divide to conquer, each level must be simpler than the lower ones and more rigorous, that means more
detailed than the higher ones. Only then we can call it a layering in levels up and down. Identify common
tasks in lower levels, and thus the division need not be tree like, and there has to be composability. Each
task at each level must have an integral identity, unique identity, and interface of its own. Complex
interdependence and interaction must be planned at higher levels, and if they reach some overlap, then
we should again go back to the abstraction task and see that each task will have a unique place in a
unique layer.

Then to actually implement for each level, focus on the tasks bottom-up. For delegating tasks to any lower
level, focus on the top-down design, but interface and testing criteria should be provided to both higher
and lower levels. To the higher levels as a promise and to the latter as a requirement, and these both
should be called contracts.

Why Hide?

• Complications of applications.
• Hierarchic systems are usually composed of only a few di erent kinds of
subsystems in various combinations and arrangements.
• Thus, OOAD is natural.
• We need to nd and exploit the extent of decomposability in complex
systems.
• We design by divide & conquer and implement by stepwise re nement
and integrate by unite & govern.

How to Decompose?

• Separation of concerns: Intracomponent linkages are generally stronger than

intercomponent linkages.
• Helps in separating the high-frequency dynamics of the components: involving
the internal structure of the components.
• From the low-frequency dynamics: involving interaction among components.

Video Transcript:
how to actually encapsulate, why hide information in the rst place? So there are
applications which are as complex. Here is one example shown in which there are so many di erent
components at various levels interacting with each other, and they also interact within themselves within a
subsystem or a bigger component, and then the bigger components also interact with each other at
higher levels. This obviously leads to a complex hierarchic system. Such systems are usually composed of
only a few di erent kinds of subsystems. That is, the each subsystem may be somewhat similar to other
subsystems, but they have di erent roles. And then they, of course, combine in di erent
arrangements. And that's why object oriented analysis and design. OOAD is a natural methodology to
decompose and then develop and implement such systems. So we need to nd and exploit then in the
design and development, the extent of decomposability in such complex systems. Otherwise we cannot
just make a headway. So we design by that divide and conquer, then implement by stepwise re nement
and integrate by unite and govern. How to decompose? So you can see that there will be basically
systems subsystems which are connected by fewer of those connections, whereas within themselves they
are very tightly coupled, connected, and too many connections are there. We call this modular design,
modularity. You can see that the blue, black, yellow, red, and green modules in this diagram, they are
highly connected within themselves, but to each other, they are connected sparsely. Okay, so we have to
separate concerns, and this will help us separating the high frequency dynamics of the
components, because internally they are so interacting, so rapidly and in so many di erent ways, so many
di erent modes of operation. That dynamics is high frequency and that will also relate to the internal
structure of the components, whereas that is separated from the low frequency dynamics. That involves
interaction among the components, among the subsystems, which is sparse and not so dynamic. So the
encapsulation process will proceed like this.
ff
fi
ff
ff
ff
fi
fi
fi
ff
ff
ff
fi
 Encapsulation Process

• Identify objects that interact and perform to carry out the desired tasks.
• Identify their commonalities and di erences and thus design the class hierarchy.
• Get a story detailing the various roles each object performs, the states it is in so as to perform those
roles, and its behavioural traits during those performances.
• Separately specify the states, the behaviour.

Encapsulation & Data Hiding

• Once the connection between the states and the behavioural patterns of an object is clear, give
meaningful names to the methods.
• Give getter and setter methods for direct handles on the state of an object without creating anomalies.

Example: Sorting (Books or Data)

• The relevant common property is that of being comparable.

• The key eld(s) used to compare depend on the kind (subclass): catalogue records and other records.
• The sorting behaviour is of the collections.
• Movement of records and books is not an inherent property of any of the two kinds of objects.
• But record integrity is.

Video Transcript:
You rst identify the objects that interact and perform the task at hand. Right. That is how you have the
top level object oriented design, identify their commonalities and di erences, and thus design the class
hierarchy. Once you have the class hierarchy, then you have a story that tells you the various roles that
those objects will perform, will serve each other. And then that's why they will also change in their states
and they will perform the task. There will be a behavioral pattern emerging for each of them, separately
specify the states and the behavior. This is very important for the encapsulation process.

Now, once the connection between the states and the behavioral patterns is apparent, then give
meaningful names to the methods. Methods will tell you the actual behavior to the user, whoever is going
to use these objects. That means, of course, other components or other pieces of code in your system.

And give getter and setter methods. You will see in detail when you actually study object oriented
programming. But what essentially they mean is that they can also give information about the object state,
internal state, to the extent that the object and objects own consistency allows. Okay, all the security
concerns, everything will be taken care of by the method itself. Similarly, setter method, that is, we want
the object to change something internally in response to some demand or request. Now, you should not
be able to do that without going through the setter method that is provided with the objects. So these are
direct handles on the state of an object without creating anomalies. This is important. So, example is
sorting again books or data. The relevant common property is that of being comparable. Books are
comparable to each other by their titles or whatever, there may be a call number, there may be some other
eld, but there will be a key and you compare. Similarly, data records will have a key, and you compare on
that key. The key elds that are used to compare depend on the kind the subclass, catalog records or
other records. The sorting behavior is belonging to the collections. You have a collection of books sorted,
not one book that is sorted, right. It's not a property of the book or the data record. It is a property of a
collection of them. So movement of records and books is not an inherent property of any of these
two kinds of objects, books or records. But the record integrity is the record has to be together. If you
change some part of it, then it ceases to be that record. It ceases to be that book. So, if you remove the
cover, the dust jacket of a book, then its title may not be apparent on the spine and something else
appears there. You cannot sort the book based on that, what appears on the blurb, right? So you have to
keep that record integrity. And that is what we call information hiding.

In summary, identify and separate the states and behavior of objects during classi cation. Then allow only
objects own methods to change the state consistent with the internal and external information and
behavior history, the interaction that is expected of the system and the idea of contracts. Again, but now
o ered by crisis, a class o ers a contract that this is what I am and this is how I will behave if you send me
these messages and those requests. This contract is crucial to the guarantee of integration without
implosion and that's the essence of encapsulation.
fi
ff
fi
fi
fi
ff
ff
ff
fi
 Why Separate?

• Any interface is a moving target.

• If the sorting technique depends on the ordering key type, we need to build many assemblies for sorting.
• If each book has a di erent kind of and a di erent place for the barcode, then the scanner will hold up
the stocktaking team.
• If each di erent application seeks di erent e ects of setter methods for a class, we cannot reuse it- in
fact, each is a distinct class.

Kinds of Interfaces: What's Separation?

• Object-object interfaces: getter and setter methods, event-triggered callbacks, etc.

• Module-object and module-module interfaces.
• User interfaces, e.g., web portals of large organisations: multiple services from multiple servers and
service providers presented in one web address.

Video Transcript:
Why separate? To understand this, rst, we have to understand that any interface is a moving target. It's
never complete and then crystallized. For example, this sorting system I have given in this picture, if the
sorting technique depends on the ordering key type, we need to build many assemblies for sorting. This
assembly is for sorting meal. Or you're sorting books, suppose. If each book has a di erent kind of and a
di erent place for that bar code that is stuck on the label, then the scanner will hold up the stock taking
team. If your procedure is dependent on the way you are using the di erent tools, the interfaces, then of
course, your procedure design will be redesigned every time you change anything in the particular
tools, techniques, or even the raw materials. If each di erent application seeks di erent e ects of setter
methods for a class, that means each time it tries to modify something in the instance, an object. The
expectation is that the behavior should change in di erent ways depending upon some application or
some situation. Then we cannot reuse it. In fact, then each of these expected behaviors should be a
distinct class. Here again, we need that separation. Otherwise, we cannot actually exploit. We cannot
make use of the reusability object oriented code. The kinds of interfaces we will need to consider so that
we know what is exactly this separation. There are object-oriented interfaces or object interfaces, which
will be through getter and setter methods or event triggered callbacks, etc. Here again, you need the
separation between the code that actually does the imperative part and the signatures of those methods
or the what part where we express the interface between them. Then there will be module-object and
module-module interfaces. These interfaces will basically give us that hierarchy or delegation of
tasks. Each module will require things to be done by objects. Then each module may even have some
parallel equals to other modules. These will require interfaces between them. Then there will be user
interfaces like web portals of large organizations. Multiple services from multiple servers and service
providers are presented in one web address. In each of these, the separation of the what and how or the
function and the implementation will have to be considered in di erent ways. But there will be still some
common principles.

Separation Process

• Identify the "what" (the known name or description of the service).

• Identify the options for the "how" part (implementation) that present the same “what" view.
• Give the descriptive prototypes (the technical "what").
• Provide the prescriptive prototypes for the implementors.

Example: Search String vs Query

• When you start typing a "query", the search engine may make autocomplete suggestions, often like
interrogative sentences.

• At the backend, the search engine passes keywords from the search string (including the autocomplete
option chosen, if any) to the "database" services.
ff
ff
ff
fi
ff
ff
ff
ff
ff
ff
ff
ff
ff
ff
 Separation, Independence, Modularity

• Modular design is about separation of tasks-that is, of implementation components.

• Separation of interface from implementation is independence between the form and the content, the
what and the how, the function and the structure.
• The latter separation can be within a module or an object: at any level of granularity.

Video Transcript:
Separation process goes through these steps. Identify the what. That is very important. When we say the
what, that means the expressive label or name of that service, which we can call description of the
service, but it should be again in the pity manner. Identify the options for the how part. Options means
what are the di erent kinds of implementations again. There will be design choices in a sense, design
strategies, design patterns. Which will present the same what view to each level's end user. End user may
be object, end user may be another module, or it may be the users themselves. Give those descriptive
prototypes. The technical what is expressed in terms of the prototypes or signatures of the methods of the
interfaces. Then provide prescriptive prototypes for the implementers. Prescriptive means what kind of
implementation, strategy, and even technique, the particular nitty-gritty of it. That should be prescribed to
the implementers so that you have both of them in sync, the what and how part, but at the same
time, there is separation between them, independence between them. Example is search string versus just
a proper query. When you start typing a query to a search engine like Google, the search engine will
make autocomplete suggestions, often interrogative sentences. You feel like you are actually typing in a
query, but it is not a query really. At the backend, it will pass keywords only from that search string, which
looks like a full question. The database services will be then giving reply to that search string, which are
keywords again. Here, there is a separation between the interface and the implementation part, and you
are shielded from the implementation by making a facade of a complete natural language-looking
interface. Modular design is about separation of tasks, that is, of implementation components. You broke
the problem in hierarchy of subproblems. But separation of interface from implementation is independence
between the form and the content, the what and the how. These two are two di erent things. You have to
understand. Modularity is not the same as just this independence between what and how. This latter
separation can be within a module or within an object as well. At any level of granularity, you have to keep
this principle intact, independence between form and content, what and how. In summary, you have
to identify and separate the what and the how, and this is at all levels. Describe the what to the user and
prescribe the constraints on the how part to the implementer so that they are together, but at the same
time independent. The idea of contracts o ered by classes, module, systems, subsystems, this is again,
crucial to achieving this independence, and that's the crux of it.

Modularity and Integration

Why these SDPs?

• Common to all stakeholders.

• So many sources, surveyed in four iterations in three decades by the IEEE: matured.
• The iterative design process is seen in the design and development of SDPs as well.
• Development of SDPs means:
• Identi cation and formulation.
• Dissemination and practice.
• Revision and re nement.

A Ready Reckoner of SDPs

• Conceptual Integrity.
• Do not assume any early choice to be a permanent decision: iterative re nement.
• Thus, do not nalise the design decisions early on.
• Modularity: Independence of components and separation of concerns as much as possible at each
level.
• Object-oriented design.
• Two-way communication at all levels.
• Progressive re nement: Skeleton to esh. incremental build.
fi
fi
fi
ff
fi
fl
ff
fi
ff
 Video Transcript:
Why these SDPs the ones that we have seen so far, but there is rst of all, some recall of SDPs we need to
do. But most importantly, if you just recall any of them, you will see that they are common to all
stakeholders. When I say all stakeholders, it includes not you as perhaps potential software designers and
developers, but also you and others as users of software. That is even in order to choose and then adopt a
software, adapt to your needs. You need to be aware of the design principles behind the software
design, not all design aspects or the details, but principles. Many sources which are surveyed in four
iterations in three decades by the triple in that saybox software engineering body of knowledge,
compendium. That have basically proposed and used and re ned these SDPs. They are matured. The
iterative design process is seen in the design and development of the software design principles as
well. This seen here, development of SDPs is rst identi cation and formulation of principles, then
dissemination and practice, revision and re nement, and that goes in a cyclic way. The most prominent
example of this is another book, which is not actually a disciplined textbook, but it has been referred to by
all the textbooks on the subject of software engineering, software design, software architecture, and so
on. That is the Brooks Book, the Mythical Man Month. It's a delightful book and after 20 years of that
book. That means in 1975 to 1995, he has surveyed at the end of it, what was then changed? What was
negated, and what is now retained or we can say it has longevity and stability in that book? He has tried to
identify some design principles in the beginning, and then he has surveyed later, and some of them, he
has even changed or modi ed. Already recon here for our recall. Conceptual integrity is the most
important core principle in software design principles. Do not assume any early choice to be a permanent
decision, that means iterative re nement, you have to always keep in mind. Do not nalize the design
decisions early on. That means, modularity which leads to independence of components and separation
of concerns, should be made a design principle as much as possible at each level. Each time you are
designing any component at that granularity level, again, you seek modularity. That also means you have
to use object oriented design principles again at each level. Of course, that doesn't mean object
programming each time, but design principles. Two-way communication at all levels between objects,
between modules, between di erent subsystems, all this is very important. Progressive re nement. That
is, this is di erent from iterative re nement. Progressive re nement means skeleton to esh. That is you
rst make a skeleton of a software system, and then you start lling up the details inside. This is of
course, in parallel to the top down design, problems subproblems and so on, and the build has to be
incremental. This is very important. That you have a skeleton of software that compiles. It may not carry
out the task. In fact, in the beginning, it will not carry out the task for which it is designed. But you know
how it builds, and each time you ash it out, you build it again, and that is progressive re nement. What
are not software design principles? If something is found prudent and useful at a certain time, which is like
a compromise sometimes, it's a hack. It doesn't automatically become principle with longevity. I have
actually seen that most of those who are excelling at those coding competitions, wherein they have to
hack at those very complex problems and solve them before everybody else, that kind of
competition. They actually are poor software designers and developers, because they always are looking
for one hacker that will do the trick. Software design is actually not done by tricks. It is done on the basis
of principles, then a standard practice, and so many things on the way, which will in fact prescribe any
tricks. We do not want tricks there. No shortcuts.

What are not SDPs?

• If something is found prudent and useful at a certain time, it doesn't automatically become a principle
with longevity.
• It must not be forgotten as a temporary idea obsoleted soon.
• Each choice is not between two mutually exclusive and contradictory ideas.
• Overlapping doesn't always warrant merging.

What can be Elevated to be a Principle?

• An idea that recurs and is also noticed distinctly in other overlapping or encompassing ideas, such that
each contrast and contraction leads to a jump in productivity and/or quality.

• It keeps coming from independent sources involved in the vigour and rigour of development, with or
without seeding.
fi
ff
fi
ff
fi
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
Simplicity, Economy

• No redundancy?
• What stabilises is most e cient in terms of interconnected human-machine systems?
• HCI Development: VM/CMS and MULTICS to Unix, desktop PC, mouse, GUI and touchscreen WIMP to
holographic devices.

Video Transcript:
But yet, it must not be forgotten, as any temporary idea cannot be obsoleted quickly. It will have its utility
somewhere. It may become part of some principle that has longevity and relevance. Each choice is not
between two mutually exclusive and contradictory ideas. Each time you choose a programming
language, say C for object oriented programming, which is doable, which is done in most of the systems,
programs, operating systems, which also include graphical user interfaces. C is used in an object oriented
fashion, but that doesn't mean that you necessarily write procedural programs in C. When you choose a
paradigm, that doesn't mean automatically all your choices about tools, techniques are decided by
that. Because, each idea is not mutually exclusive of other ideas. There will be some overlap, and you
have to go by the needs of the software project. Overlapping doesn't always warrant merging also. When
you see overlapping ideas, you don't have to each time unify them into one single principle, and condense
them. It will, most of the times, break both of those ideas and make them unusable or irrelevant. What can
be elevated to a principle? An idea that recurs and is also noticed very discernibly in other overlapping or
encompassing ideas. You always identify that idea recurring, but in other ideas or in more complex
treatments, and each contrast between di erent ideas and each contraction from some vague and larger
idea to a smaller state of ideas, it leads to a jump in productivity or quality, because of that idea. That
becomes a principle. It keeps coming from independent sources then, because each one will talk about it
when they discover it independently in their work, when they try to better a design. Those people who are
involved in the vigor and rigor of development, with or without knowing that idea beforehand, then that's a
test, that it's a principle because it is universal. But it will also come from users. I'm saying it should be
common to all stakeholders. The simplicity and economy of these principles is very di cult notion to
practice. Of course, it is very easy to understand you must have known this Newton's anecdote. I don't
know whether it is true, but he made two holes, one for the mother cat and the other for the
kitten. Whereas anybody can see that the larger hole can su ce for both of them. But actually, I saw
advertisements for di erent cat aps for large as well as small cats. It's commercial, it is viable, it is silly.

We have to see whether there is any redundancy, and if there is redundancy, then really merging or
perhaps mixing some of the ideas, will be the direction. That will ensure simplicity and economy of our
thought and ideas. What stabilizes is most e cient in terms of interconnected human machine
systems. An example is the WIMP interface. You can see the world development of human computer
interfaces. WIMP means windows, icons, mouse, pointers, menus, and so on.

There was initially some interactive system, and then MULTICS was not really usable for playing games,
for example. They developed Unix, but Unix also was not that user-friendly compared to desktop PC. You
can see with the desktop PC came the idea of mouse, GUI, and then that also led to a touch screen, and
now we have holomorphic devices. You can see this side. The band on the wrist actually projects some
screen on the wrist. Actually it is just a projection. It's an image projected. Then you can choose from that
image. You can use that like a menu driven GUI. Principles, in summary, are common to all
stakeholders. They are validated in practice. Conceptual integrity is most crucial, and this conceptual
integrity is achieved and tested by the criterion of economy of language, and universal appeal.

Why Separate?(Separation of concerns)

• Reduce redundancy.
• Increase reusability and modularity.
• Achieve better information hiding ("need to know" basis dissemination, "need to do” basis delegation).
• Design iterations are less disruptive and more modular.
• Timing of design decisions can be realistic and economical.
ff
ffi
fl
ff
ffi
ffi
ffi
 What can be Separated?

• A concern is a particular set of information a ecting design or development.

• Two di erent concerns that intermingle in the same section of code are called "highly coupled" e.g.,
object selection and command selection in an interface.
• Loosely coupled concerns can be separated e.g., selection and visibility.
• Highly coupled concerns can be further broken down into components that may be separable.

Video Transcript:
Why separate? The basic reason is reducing redundancy. Increase modularity, reusability, and then
achieve better information hiding. That is why information hiding, again, can be answered in the same
way. These ideas are basically interchangeable. But the basic principle behind this is, dissemination of
information on a need to know basis, whereas delegation, that means responsibility and authority
delegation, on a need to do basis. Design iterations become less disruptive and more modular. Because
everyone is not knowing everything or every module, every object is not concerned with every other
object and every other module, then any changes done at one place to a module, will not immediately
a ect everyone else. Because concerns, basically, are that. Timing of design decisions can be realistic and
economical because of this. The iterations, then also the teams that work on di erent modules or di erent
components can also make their decisions without discussing with everyone else. What can be
separated? A concern is a particular set of information a ecting design or development at any stage, any
piece of code or any module or any subsystem at any granularity level. Two di erent concerns that
intermingle in the same section of code are called highly coupled. For example, you want to select an
object using a mouse, putting the cursor and clicking, and you want to also select a command in a
graphical user interface or on a touch screen. In the beginning, I have always used this example of
teaching your grandmother while talking on phone, how to use some app on the same phone that she's
talking on with you.

Such highly coupled concerns cannot be easily separated, whereas, loosely coupled concerns can be
separated. Selection and visibility, that means when you select by the mouse using the cursor and a
click, and then you want to make that icon visible, it should come forward. It should have the most forward
visibility. Well, that happens easily, and that is a loosely coupled concern. You can separate selection
and visibility as two di erent subsystems. Highly coupled concerns can be further broken down into
components that may be separable. That we should always seek. When we want to have object selection
and command selection simultaneously, then what we try to do is, that object selection will be done by the
mouse, and command selection can be done by either a keyboard shortcut, or maybe another menu, so
the mouse can use the right click to select the object, as well as give a menu immediately, and then you
can select by another click from the menu that appears near the object on the screen. This separation,
again, can be done further down, but for that, we have to break down the highly coupled concerns.

What Cannot be Separated?

• Cross-cutting concerns: horizontal.

• Example, Logging, event callbacks, commands associated with mouse clicks, pull-down menus, and
keyboard shortcuts.
• Ever got your browser or le manager hung on preview of images or videos?
• This course and your respective occupations.

How to Separate?

• Nearly all programming languages provide support for separation of concerns.

• First identify the concerns. Data- ow and data- dependency diagrams, use-case diagrams, etc. (UML).
• Use simple graph inspection to mark forks and joints.
• Match with class hierarchy.

Video Transcript:
What cannot be separated? Again, cross cutting concerns, which are horizontal. Horizontal means, it's
not a vertical top down problems to subproblems to subproblems division. But many of those
components which are at one level, which should be separated in that hierarchy of problems and
subproblems, again, they also have some shared concern. Then that is called a horizontal concern. That is
a cross cutting concern. It cannot be separated. We need a di erent approach than the simple modular
ff
ff
ff
fi
fl
ff
ff
ff
ff
ff
ff
 and object oriented approach to handle this. An example is logging. You want to log every activity done
by every object in every module, and those modules are basically interacting with each other and
collaborating to carry out some complex task, then what to be logged by whom, when, and in response to
which trigger or event, that becomes a cross cutting concern. Even callbacks are another such
example, and it is like logging only. Because each callback reports to a customer or client, what a server
has completed done or failed to do. Now, commands associated with mouse clicks and pull down menus
and keyboard shortcuts. Together, they are again cross cutting concerns. Because, all of them can try to
do the same thing on the same object and actually the user intends to do only one of these things,
once. Ever got your browser or le manager hung on preview of images or videos? That is your mouse is
hovering on icons, and then your le manager or the browser, maybe you are browsing YouTube. They are
programmed to give you a preview of what the mouse is hovering on. That preview leads to the browser or
that le manager going into some kind of waiting loop. It shows the clock all the time. Then really the
whole system can hang because of this. You cannot do anything else, also you cannot move away from
that window. You have to kill the window. That is only possible. You have to kill the application that is
holding everything up. This actually is an example of a cross cutting concern coming in the way of smooth
operation, and somewhere it is not addressed in the software design. This course and your respective
occupations are cross cutting concerns, aren't they? We want this course to be useful to you even without
changing your occupation to software design and development. It's a cross cutting concern. How to
separate now? If we have known, identi ed the concerns that are to be separated and separable, then
how to separate. Nearly all programming languages will provide support for separation of
concerns, modularity and even object rented programming, you can do in every language. It's not that it is
con ned to Java and [inaudible] and so on. First, identify the concerns, and make data ow data
dependency diagrams. They will basically give you most of the separability view. What can be separated,
what cannot be separated. Use case diagrams also help. In general, UML modeling helps you in
identifying concerns and separating the separable and non separable concerns or cross cutting
concerns. Use simple graph inspection to mark those forks and joints, and match with class
hierarchy, because your class hierarchy may have to be redesigned when you identify those concerns that
can be separated and should be separated. You may have to redesign the class hierarchy. All the UML
diagrams together, you have to inspect. In summary, identify and separate the what and the how. Again, it
remains the same. Describe the what to the user, that is, whoever is going to use the services. Then
prescribe the constraints on how to the implemented. Here, the constraints will be the concerns. The idea
of contracts again o ered by all these classes, modules, systems, components, that is crucial to achieving
this separation and independence.
fi
fi
ff
fi
fi
fi
fl
Week-4

Fundamentals of Designing for Change

Bottom-Up Design

• Object-oriented design is bottom-up.

• The building blocks are designed rst (typically they are built already or obtained prefabricated o -the-
shelf).
• The building blocks are reusable but that doesn’t mean what we build with them is reusable by default.

Is Bottom-Up 00 Design Always Reusable?

• If you use nails and rivets to couple and bind furniture parts together, can you ever reinforce, redesign,
even re nish the furniture without damage and irreversible change?
• If you use nut-bolts that rot under Goa weather conditions and thus get "welded" to the wood, can you
reuse the furniture later?
• Without designing for change, one cannot repurpose or reuse old furniture.
• Software becomes old furniture too sooner than wooden furniture.

Video Transcript:
To the bottom up design actually means object oriented design, it is inherently bottom up. The one that
is the opposite direction is top down in which you look at the top level problem and divide it up into sub
problems without thinking of how the base level problems, most elementary solutions will coupled
together. Bottom up design, we actually look at the elementary problems rst and the building blocks are
designed rst. Typically, they are built already in the sense that we already have some experience with all
the needed building blocks. They are available as components. Then we start building up from there.

Those blocks themselves are reusable. But that doesn't mean that what we build with them is reusable by
default. I will give you an analogy. If you have old furniture, this is a typical we can say heritage house in
Goa, India. There are so many di erent pieces of wood and furniture here. They are exquisite and the
wood used is like it lasts for centuries, without any trouble, without any termite or other men. But of
course, any furniture will get old and you will need to sometimes repair, sometimes even repurpose it. If
you use nails and rivets to couple and bind those parts together of the furniture, then you cannot
reinforce parts which have weakened or damaged. You cannot redesign. You cannot even re nish that you
cannot make the outer nish more glossy, without any damage or some irreversible change to the furniture
itself. The jigs and xtures themselves have to be exible and they should be modular, they should be
removable and then re- xable. If you use nut-bolts, but they also rot under the weather conditions, and so
they get welded to the wood. Then again, you cannot reuse. You have to also choose the right materials
and right kinds of those nut-bolts. Now, if you don't design for change already in the beginning itself, and
this furniture is like centuries old. One cannot repurpose or reuse old furniture. Most of the times it will
have an expiry date and you will have to just throw it out or just break it into rewood. Software also
becomes old furniture like this, and it becomes old furniture too sooner than wooden furniture. Here, the
most important point is that software is for software design, and then the paradigms, like bottom up
design. These are for human beings so that we can not only write and use software, but we can also
maintain it. We can modify it, we can re ne it. We can customize it to our needs. For that, you also have to
design for reuse and change as well. That is the exibilities that you want to be available. You have to
design them from the beginning.

What Cannot be Reused?

• Charles Scalfani on Medium.com, "Goodbye, Object Oriented Programming":

• Banana Monkey Jungle Problem: There's a great quote by Joe Armstrong, the creator of Erlang:
• "The problem with object- oriented languages is they've got all this implicit environment that they
carry around with them. You wanted a banana but what you got was a gorilla holding the banana and
the entire jungle.”
fi
fi
fi
fi
fi
ff
fi
fi
fl
fl
fi
fi
fi
ff
Contain and Delegate

• Banana Monkey Jungle Solution:

• Don't make unnaturally deep class hierarchies.
• A subtask that is not an inherent property of this class can be delegated an instance of another,
unrelated class contained as a member in this class.
• A property that is shared with varied semantics can be delegated to a specialist class.

Video Transcript:
What cannot be reused? There is this banana monkey jungle problem as formulated by one veteran object
oriented programming expert. The problem with object oriented languages is that they have got all this
implicit environment such that it is always around them, but you don't see that. You wanted a banana.
That means you basically wanted some component which is reusable, you know its purpose, and you
have very well designed it. But what you got instead of just that banana, is the gorilla holding the banana
and the entire jungle. That means, basically, even to reuse something, you need again the whole system
back again. You are not reusing the component, the building block or some bigger composite that is built
on that. You need the whole system again and again. If that is how it is going to be then, it is not
reuse. You want to do a diploma and you have to enroll into a university full-time, you would not have
come to this course. Now there is this plexity available. We can use it. The solution to this problem is
contained and delegate. Don't make unnaturally deep class hierarchies. That means when you make
design decisions, don't make them with rivets and nails such that now you cannot take them apart again
and join them again. That will be a deep decision. Then a subtask that is not an inherent property of this
class that you're designing, that is this component. It can be delegated to an instance of another unrelated
class contained as a member in this class. Try to use basically o the shelf components instead of
redesigning everything from scratch each time, completely embedded or woven into your new
design. Only then it will have those exibilities, removable, easily replaceable, and all that. A property that
is shared with varied semantics, that means it is there for every situation, but in a di erent way, it will be
used in a di erent role. Then it can be delegated to a specialist class, instead of having it as part of this
class, which doesn't have this particular property as an essential property. What is not essential to this
class, but useful to it, you delegate it. Well, being adept at all kinds of jobs is ne, but you don't have to do
it and you cannot do it every day. You cannot also be at o ce and keep your house clean. You will need to
engage some janitor. That is how we have to do containment and delegation. In summary, conceptual
integrity is more important than standardizing nut-bolts and plumbing. But compromising on nut-bolts
and plumbing must be a temporary choice, maybe just for prototyping, just for testing an idea, and not in
the design. The idea of contracts again o ered by di erent classes. This also allows us this contain
and delegate solution for enhancing reuse. This is the takeaway.

What's Refactoring?

• We want a change made to the internal structure of software to make it easier to understand and
cheaper to modify without changing its observable behaviour.
• It is neither removing syntax errors nor debugging (i.e. removing semantic errors).
• Typically, it is done in response to re nement or upgrade or modi cation requests and needs.
Sometimes, it is also done at the behest of the developers who nd the messiness a big impediment.

Can we Anticipate and Plan for Change?

• Kent Beck's metaphor of two hats. When using refactoring to develop, divide your time between adding
function and Refactoring.
• Adding function is not changing existing code, measuring progress by adding tests and getting the tests
to work.
• Refactoring makes a point of not adding function; you only restructure the code.
• You don't add any tests (unless you nd a case you missed earlier);
• Perhaps change tests to cope with a change in an interface if any.
ff
fl
fi
fi
ff
ff
ffi
fi
ff
fi
fi
ff
 When to Refactor (or Factor in Refactoring)?

• The rule of three:

• Three strikes and you refactor.
• When adding a function.
• While debugging - if you can't just x it just like that (but just debugging is not refactoring).
• During a code review.

Adaptivity is a Strength that Needs Exercise

• Solving a particular problem at a time is easy, often e cient for the unit solving it.
• The redundancy and repetition costs are counted only at a higher level.
• Designing for reuse means lower-level ine ciencies but amortised savings at all higher levels and during
the rest of the SDLC.
• The main two additional costs of this adaptivity are: higher skilled labour costs and time management
costs. e.g., linear vs binary search.

If you Factor in Refactoring…

• It improves:
• the design.
• readability.
• reliability and reduces errors.
• maintainability.
• time scheduling.
• programmer productivity.
• The disadvantages are similar to those of designing for reuse.

Video Transcript(from Adaptivity topic to if you factor):

Adaptivity is a strength that needs exercise. The pictures, it will be clear what they are soon. Solving a
particular problem at a time is easy. Usually, it is e cient for the unit that is solving that subproblem. But
the redundancy and repetition cost, that is so many people solving the same problem in di erent contexts
in di erent situations without consulting or without reusing each other's code or solutions. These costs will
be counted only at a higher level. If there is a manager who is looking at all of them, then they can see the
costs of repetition redundancy. Designing for reuse means lower level ine ciencies because they have to
solve the problem not quickly and not only for that situation for themselves, but they have to solve it for a
larger set of situations and people. But there will be amortized savings that is total savings over a period in
the software design development life cycle. At all higher levels mainly. The main two additional costs of
this adaptivity are one, higher skilled labor cost and time management costs. Here is an example, linear
versus binary research. You can see the picture at the top on the right. That looks like just smattering of
some blobs of paint. If you are asked to, say, count the dots of a particular color or nd the largest blob of
any color or some particular color, it will be very hard to do this. Even if you take this image and
write image processing program to nd that, it will take a long time. It will have to really go through all the
dots there. And then you see the picture of our library. Now, the shelves, the almirahs, the racks, they have
also. You can see there are papers pasted there, and they will have certain numbering and classi cation
there, and each shelf on the racks also has a particular set of books belonging to a particular section, and
they will have serial call numbers. You know that the topic starts with, say, M, so it will come somewhere in
the middle. In the middle, again, there you will use the other letters in the name of the book and go to that
shelf in the same almirah and so on. This is called binary search. You rst look where it will be vis-a-vis the
two ends. Then after that, each time, you go to the middle of it. This way, the number of times you need to
go through the search process is, in fact, much less. It is called basically logarithmic time. That is, if you
have 100 di erent items there to search, you will need only 10 searches, whereas if you are looking up in
the picture above, then you will need 100 searches. That's the di erence. If you really factor in refactoring,
readability, readability reduces errors, maintainability, and time scheduling also. This is the point of
contention. In the linear and binary search example that I just gave, it was actually a situation in a
company where they had to maintain database in the backend and keep the query engine ready
for customers to be able to query the database. Now, one of the engineers, our student, he had just
graduated, he o ered to keep the database sorted and then do binary research whenever a query
comes. That would have saved a lot of time for the customers as well because each time they re a
query, the answer would come something like 10 times or sometimes even more than that, faster. Then the
ff
ff
ff
fi
fi
ffi
ffi
ffi
ff
fi
ffi
fi
ff
fi
fi
team and even the project lead, they refused to wait for that. Why? Because they thought that it will mess
up the time scheduling. They had to deliver the product as soon as possible and if they were not up to
it, then they would have to either take more skilled people there or just delay the project. They didn't want
to do that and that led to total ine ciency of that project for its lifetime. This is the important choice. It's
not really di cult choice, but sometimes it feels tough because of the challenges of the moment. This will
increase program of productivity, but that team that time refused to see that. They thought that it will
actually burden them all, and what if that engineer who was con dent and skilled at it leaves the
company, then they thought all that will fall on their head, they did want. The disadvantages are similar
to those of designing for reuse in this sense, but they are more notional than actual.

Sometimes Ordering Disobeys us but…

• Indirection may increase.

• Occam's Razor comes to the rescue.
• Still, it enables sharing of logic.
• Function and structure are better separated, intention and implementation better explainable.
• Isolates change.
• Isolates independent components by incorporating conditional logic.

When not to Refactor?

• Be careful when there is a temptation or a request to refactor.

• Databases: a lot hangs on schemas.
• Interfaces: changing the behaviour, not structure: Don't publish interfaces prematurely. Modify your
code ownership policies for smooth refactoring.
• Often, nothing but reboot works.

Video Transcript:
But sometimes ordering that is restructuring is not really that attractive. Indirection may increase, that is
there will be more pieces and more chaos between the di erent components and di erent people handling
those components. Then Occam's Razor comes to your rescue. You have to really plan to divide so
wisely. Still, it will enable sharing of logic, function, and structure are better separated so that you can
explain intention and implementation to even the customer. It isolates change. When change comes, you
don't have to do everything again. It isolates independent components by incorporating conditional
logic. If you restructure, then you understand now in di erent situations, di erent things are to be
done, you do them conditionally. When not to refactor, mainly when there are databases because a lot
hangs on the schemas. If you change something there, it just ripple through to all the customers and all
the middleware as well. That becomes sometimes way di cult to handle, so be careful. Interfaces, when
you're changing the interfaces between components, between modules, between di erent
systems, subsystems, you are changing the behavior, not structure, remember. This is not refactoring and
it's not that easy. Don't publish interfaces prematurely. Modify your code ownership policies for smooth
refactoring. You will understand this better when you actually develop some code in object [inaudible]
programming, but this [inaudible] is very important. Often, nothing but reboot works. That is, in that
case, don't go for refactoring. Start from scratch. The ideas are with you, the conceptual integrity will still
remain, but the design will be done earlier. In that case, don't say it is refactoring. Don't wait for refactor. In
summary, there are advantages and disadvantages of reuse and refactoring, of course, but designing for
reuse and rechange and being careful while refactoring, it is always guaranteed to pay o . If you don't plan
for it and then the refactoring is falling on your head, that may be di cult. Remember to change the hats
consciously when adding a function or xing a bug or reviewing code. The two hat metaphor, you have to
remember. That's all.

Diagnosis-Detecting the Need for Refactoring

When to Change the Hat

• No precise criteria to decide when a refactoring is overdue. No set of metrics rivals informed human
intuition.
• What's this intuitive, aesthetic or olfactory sense?
ffi
ffi
fi
ff
ffi
ff
fi
ffi
ff
ff
ff
ff
 • Can the aesthetic principles of Grouping, Contrast, Isolation, Selective Enhancement, Enigma,
Orderliness, Symmetry, Abhorrence of Silly Predictability, Metaphorical Expression be applied to
"smelling code”?

Heuristic Aesthetics-1

• No Encapsulation: No grouping of duplicated code.

• Verbose or Metaphoric? Long methods, long signatures (parameter lists), large classes.
• Lack of contrast leading to local ills becoming viral infection: each small change becomes disruptive.
• Things that change together are not together.

Heuristic Aesthetics-2

• Switches for more than on-o actions, unused variables, message chains, unnecessary interfaces and
lazy classes clutter code : lack of orderliness.
• Parallel inheritance hierarchies: abhorrent coincidences.
• Speculative generality reduces specialisation: lack of contrast and selective enhancement.

Heuristic Aesthetics-3

• Inappropriate and misplaced intimacy between classes: lack of contrast.

• Library classes not reused e ectively: verbosity.
• Data classes are antitheses of perceptual problem solving.

Video Transcript(from heuristic 1 to 3):

So these are heuristics, that means thumb rules, they are not xed rules. Again, again and again I have to
remind you that there are no xed set of rules, there are no hard and fast rules. So if there is no
encapsulation in your code, and that means there is no grouping of code and the code looks duplicated,
then de nitely the design somewhere was not the design, but the structure somewhere was bad. If the
code looks too verbose, it is not metaphoric. That means that things which should be expressed in a pithy
manner, they are not long methods, long signatures, long parameter release of functions, and large classes
which you cannot just read and understand what they are doing and why they are there. That surely recipe
for refactoring. Recipe means it's a place, it's a signal that you should refactor lack of contrast, leading to
local else becoming really widespread. That means you, if you have written the code in such a way that a
change anywhere will have to be propagated to many places everywhere, then that's like a bad structure.

Then things that change together are not actually placed together. So again, whenever you make a change
at one place, you have to recall and make sure that change re ects wherever it should. That becomes too
much of hassle and it is more likely that someone will make a mistake somewhere that's a bad structure.

Then if you have switched statements, typically they should not be there in object oriented coding
because more than on o actions are there. Then you should use polymorphism, you should delegate, you
should have hierarchies and all that. You should not have all that choice in one place. If you have long
switches, you have unused variables. That means then you thought that something is going to be useful
and having some kind of expressive property, but then it is nowhere there. Then that means your design
structure has something not really good. Then you have message change, that means one calls another,
and then another and so on.

That means too much of delegation and that too not for di erent tasks, but for the same task. Then there
is something again wrong with the structure. Unnecessary interfaces are there, so you have created too
many middle men. Then that's a bad structure and there are lazy classes. You have some class which
looks like having so many properties, methods and everything, but then its methods are not used by
anyone else but your test routines only. Then again that means the in the design that class
became obsolete or irrelevant, all these clutter code. So there is a lack of orders and you can easily smell
it. Or you look at the code and you, you cringe with that kind of repulsion key. What is this? I just can't
make head or tail of this. Typically these will be lurking somewhere.

Then there are parallel inheritance hierarchies. That means one class hierarchy, which is quite similar to
another class hierarchy, except that they have di erent functions, di erent roles, but at the same time they
have to remain parallel. So that means if you are making change to one class hierarchy for some reason,
fi
ff
ff
ff
fi
ff
ff
fi
fl
ff
 then you will have to make a similar change to the other class hierarchy in order to maintain that
symmetry. But that symmetry itself is not natural. You will have to really make e orts to maintain it. That is
a contrived symmetry, which is now also called abhorrent coincidences in aesthetic pair sequence,
something that really is too good to be true and that is too good also to be repeated. Very soon you
become really nauseated.

Speculate generality, that means basically you thought something will be useful and you start giving those
properties to some class in such a way that it will cater to everything that is imaginable. And actually then
it is not used that part. So this reduces specialization also you try to make every class general list of
everything, and it leads to lack of contrast and selective enhancement. And that's a bad design that is also
typically visible on inspection. Then inappropriate and misplaced intimacy between classes. That is again
lack of contrast. That is, those classes should not huddle together, or they should not be part of one
family, but you made them because of some kind of design thinking. Now you see that when the code is
looking really badly structured then you can go back and look at that library classes if they are not reused
e ectively, and that means you just copy a library class and then you try to extend or whatever adapted to
your use. But then that may not be really needed. You could have easily tweaked or locally extended that
class and used it only there instead of having a copy of it.

So that's verbosity, again, it will be visible. Why can't you just use that library thing? That will be on
inspection, anyone's reaction. Then there are data classes. That means basically a class that only contains
information which other classes use by those getter setter methods, nothing else. So there is again
somewhere you didn't do perceptual problem solving enough in structuring the code. Maybe the design
didn't have it, but then in development implementation you didn't recognize where should be di erent
delegations of di erent classes. In summary, even though there are no hard and fast rules for identifying
the times and then places for refactoring, intuition guided by aesthetics and object oriented paradigm
does work. We will have to practice in order to see that we need to make a compendium of problems that
we have faced and recti ed earlier by refactoring.

Why Think of Testing During Design?

• This is not contradictory to changing hats- development and refactoring.

• Designing for testing means thinking of tests (and coding them) needed for any feature that we are
adding, while or before adding.
• If we design and code tests while developing, and keep testing incrementally (while developing
incrementally), the total time for debugging gets minimised.

Heuristic Aesthetics-1

• Doing this repeatedly:

• Write some long code frantically
• Run it to test it once in long while to see whether it works
• Try to gure out why it didn't, try to x those bugs while trying not to introduce new bugs
• In the process, end up with losing sleep and track of what is what.

Where to Locate the Tests?

• Ideally, each class should test itself (i.e. have methods to test its features).
• Else, develop a separate test class hierarchy and framework.
• Input validations can be put into exception handlers.
• Existing non-self- testing code needs to be made self-testing before refactoring can be undertaken.

Video Transcript:
If you don't actually think of testing during design, then you do this repeatedly. Write some long code,
frantically type, type, type, and then run it to test it once in a long while, like once in a day to see
whether it works and then try to gure out why it didn't work, try to x those bugs. Then all the while you
are also worried that I'm not introducing some new bugs while xing the earlier bugs because there is no
design thinking, and there is no testing in that thinking. In this process, you end up losing your sleep and
you also lose track of what is what, you lose track of what is happening, and nally, you give up and
instead of refactoring, you start doing it from scratch again. That's a lot of waste of time, so that's why you
should incorporate testing in the design itself. Now, where and how where to locate the tests. Ideally, each
ff
fi
ff
fi
fi
fi
fi
fi
fi
ff
ff
class should test itself. Ideally means, again, nothing here is a xed hard and fast rule. But if possible, let's
try to locate testing where the code is. You can have methods to test each class features in the class
itself. Otherwise, if that is too much cumbersome or there are some other constraints, especially when
those methods will be called repeatedly, then develop a separate test class hierarchy and framework. It
will be somewhat like a parallel class hierarchy, but not exactly mimicking these classes, but testing these
classes. Which will not be bundled up with the shipped code that is when the software is developed and
tested what you ship will not have these classes test classes, but you always have them with your
development framework. Input validations, that means you make sure that the program doesn't fail
because of wrong inputs. It will detect and then just give an error message or something or silently ignore
those inputs. You can have exception handlers for that. Those exception handlers can also be part of your
testing framework. Existing non-self testing code, which is not developed according to the rst point on
this slide. That code has to be made self testing before you can start refactoring. When you are at a
stage, when you are refactoring existing code. Not designing for refactoring, but you are now actually
starting to refactor, you will have to make that self testing. That means you have to add those tests in that
code and that also again, you have to use the same principles to locate the tests.

How are Testing Frameworks Built? - 1

• Run your tests frequently. Localize unit tests whenever you compile ever test at least every day. (Use
JUnit).
• Functional tests are written to ensure the software as a whole works; they typically treat the whole
system as a black box as much as possible.
• When functional tests exhibit a bug, start writing unit tests to locate the bug.

How are Testing Frameworks Built? - 2

• It is better to write and run incomplete tests than not to run complete tests.
• Think of the boundary conditions under which things might go wrong and concentrate your tests there.
• Don't forget to test that exceptions are raised when things are expected to go wrong.

Video Transcript:
Now, how actually we do this incorporation of testing that is building, testing frameworks. Run your test
frequently. That should be a general practice, incremental and iterative testing and development. Localize
unit tests. Unit tests are those where we say that we test the code where it is. That means in the class, we
have methods for testing the features. With each feature, there will be some test there. We call them unit
tests. Whenever you compile, localize the unit tests and every test, at least every day you have to run. And
there is this J unit available for Java. There are not so integrated and open source framework for other
languages, but you can create your own always. Every development team can have their own testing
framework on the lines of J unit. Studying J unit any way pays o . Functional tests. These are di erent
from those unit tests. They are to ensure that the software as a whole, the whole package works. They will
treat the whole system like one black box and wherever possible, that it's like you just give the expected
inputs or unexpected inputs to the system and see the response and whether it ts in the expected
output. When functional tests exhibit a bug, you realize that, okay, the output is not exactly what was
expected. Now you have to start locating unit test somewhere to locate the bug. You write unit tests
everywhere where they were not there, and then again, run the testing framework so that you can locate
the bug, which was revealed in the functional test. It is always better to write and run incomplete test than
not to run complete test. When you are doing functional testing, you think that, oh, then I have to wait for
the whole system to be in place and after that, I have to wait for the whole testing framework to be
in place because I'm testing the whole system as a black box. Well, no, that also doesn't work because
again, it will have the same problem as we described earlier in the non-testing thinking during design. You
have to always keep developing the testing framework also incrementally. Incomplete, incomplete. But at
the same time, when it shows an error, well, that's an error. It is one way guaranteed. When it fails to show
an error, that doesn't guarantee that the error is not there. But it is always useful and e cient to nd the
error as early as possible, so run them again and again and think of the boundary conditions, especially
because under them, things will go wrong really like Murphy's Law. If it can go wrong, it will, so
concentrate your test there. Always be on the lookout for those boundary conditions. Don't forget to test
that exceptions are actually raised when things are not as expected. When you write exception handlers,
now, either give an input or create a condition in the code itself such that there will be some exception that
will actually happen. The condition will happen, and then you see whether the exception handler is
called. Otherwise, it will be just there, but it is not guarding anything. It may be guarding a wall, not a
fi
ff
fi
ffi
fi
ff
fi
 door. In summary, testing must be incorporated into the design thinking itself, and it must be
done incrementally with incremental design. Then for units, there are local test, they are called unit test,
and they will be with each class and each feature. Functional test on the contrary, will be whole framework
test and they will actually require complete frameworks. Then once they detect bugs, unit tests are again
used. That's all about design for testing.

Prognosis- Catalogue of Refactorings

Summary of rst video

Di erent ills demand di erent remedies, and we need to study each refactoring rst in an isolated manner.

Refactoring of Methods

• Too long methods are troublesome: Lots of information gets buried under complex logic: Extract
Method, which takes a clump of code and turns it into its own method.

• If multiple extractions result in methods no longer essential or warrant reorganising the way methods are
broken down: Inline Method, take a method call and replace it with the body of the code.

Summary of second video

• Refactoring methods cleans up the clutter resulting from procedural thinking habits and restores object-
orientation. This achieves better conceptual integrity.

VIdeo transcript:
. In fact, it's one method, and we can see that this method itself seems to be having two di erent main
actions there in two big loops. Such long methods are troublesome, lots of information gets buried under
complex logic. Reading this itself becomes formidable. For this, the remedy is extract method, which will
take a clump of code and it will turn it into its own method. At least two methods we should make out of
these. In fact, I would prefer something else. If multiple extractions result in methods that are not
essential, then you can see that they demand reorganizing the way methods are there broken down, then
you can do in-line method. That means you take a method call and replace it with the body of the
code, because this method is private, if you notice. Then if it is a private method anyway, it won't be called
by anybody else. Then in that case, just put it where it belongs. Instead of a call, it should be the body of
the code. But now the code is long, so it will make that method longer. I have a remedy here, you can
see. I will just call the draw method for each shape. Of course, there has to be such a method. But what
I'm going to do is, I will move the code which was there in that second for loop and the rst for loop as
well, to the shapes method. Of course, the two loops are doing the same thing, except that the rst for
loop was doing it for the shapes that had fallen down already. Then the second loop in the previous slide
was actually doing it for the current falling shape. That shape is moving. Now, that shape retains its
integrity, and the shapes which have fallen down already, they have lost their integrity as objects. They've
become just the bricks because now once the bricks become one line, the one line vanishes, and that
doesn't respect the shapes. Shapes have been broken there also. Now, let us move all this action to a
method for the shape class itself. That is all the refactorings that we had seen on the previous slide. This is
the answer or remedy. In summary, refactoring methods will clean up the clutter resulting from procedural
thinking habits, and it will restore object orientation.

Refactoring Objects - 1

• When distribution of responsibilities amongst objects appears "unfair", Move Methods and/or Move
Fields.
• When classes become bloated with too many responsibilities, use Extract Class to separate.
• If that makes a class too irresponsible, use Inline Class to merge it into another class.

Video Transcript:
Here, when distribution of responsibilities amongst objects appears unfair, that means it is not really good
or there is something awkward about it, then you can move methods or move elds or you can do both
also sometimes. What I aim to do when I refactor the method, that means the long method was then
turned into a method of the shape class. I'm moving also the method. I'm moving from the board class to
the shape class. For this, of course, I will have to do much more work as well. That is, I will have to
handle the temporary variables and many other things. But fundamentally, what I'm seeking to do is
ff
fi
ff
fi
fi
fi
ff
fi
distribution of responsibilities is reorganized because the board class is only showing its own view. It is
displaying itself. Now, the shape has to tell the board where it is showing itself. The responsibility of
showing itself should be with the shape, and then the board will show itself not the shape. Now this board
will know what is to be shown in that shape from the shape instance itself. This is basically reorganizing
the responsibilities. When classes become bloated with too many responsibilities, use extract class to
separate. Already, we have a shape class, and here the responsibility was not properly placed. That's why
we moved it. But if that shape class had not been there because shape anyway is used as data by the
board class in this current design, we could have made a new class, a shape class, or maybe even one
class each for each shape, which may be a subclass. But for that, we would have to extract that from the
board class. If then that makes a class too irresponsible, this is actually a slang here. That means basically
the class doesn't have much role, then you can make it inline class. That is the class. For example, the
board class, if gradually we start delegating the responsibilities elsewhere and then it does nothing
much, then we can make it into an inline class for the Tetris class itself, the main game engine, where
board is just one feature, one data feature with some properties. In that case, it would become an inline
class there for the Tetris class. Otherwise, we can also merge it. That means all the responsibilities of the
board class would go to the Tetris class, and the ones that we were already reorganizing, they had gone to
the shape class. Then the board class ceases to exist in that case. Of course, this is not the only way we
are going to do it, but this could be a way.

Refactoring Objects 2

• If another class is being used, it often is helpful to hide this fact with Hide Delegate.
• If hiding the delegate class results in constantly changing the owner’s interface, use Remove Middle
Man.
• To move responsibilities to an unchangeable (source inaccessible) class, Introduce a Foreign Method or
two, or, if more, Introduce Local Extension.

Video Transcript:
Then we can also see that the relation between the Tetris and the board class is equally awkward. It only
initializes a new board, adds a board, and you are initializing a new board, and then again adding the
board. What does that mean? Adding where? It's add method for the Tetris class, but then the board was
anyway created uniquely. There is only one board for one game station. Then the Tetris class calls the start
method of the board class. These three lines are highlighted in the core here. You can see that this is
actually unnecessarily referring to the board class and doing nothing much there. You can hide
delegate. Basically, you can have this not in the game engine's main method. Instead, you could have it
somewhere hidden in such a way that what started the game would be the Tetris class and the board
class would be not even visible to anyone who is trying to modify the game engine's main code. Then all
those other things set title, and set size, and all those methods. These things become basically irrelevant
to the logic of the game. We should have some high delegate refactoring done there. If that hiding
results in constantly changing the owner's interface, then we should remove middleman. Here again, the
board class stands as the middleman. We should consider, again, dissolving that board class into the
other two classes or perhaps more classes. To move responsibilities to an unchangeable, that means a
class that doesn't have the source accessible to you, you cannot change the source of that class, so that
becomes an unchangeable class. Then introduce a foreign method or just one or two foreign methods you
can introduce. If there are too many such methods to be introduced, then introduce a local extension to
the class. Make a subclass that only does some delegation of responsibilities. Nothing else. In summary,
refactoring objects will tighten the object implementation by achieving better division of labor, that is the
responsibilities, and better encapsulation. Thereby, consolidating conceptual integrity.

Refactoring of Data - 1

• When direct access to private elds within the class seems awkward, Self-Encapsulate Field.
• To turn dumb primitive data into articulate information, Replace Data Value with Object; to make it into
knowledge, Change Value to Reference.
• An array acting as a data structure is made clearer with Replace Array with Object.

Video Transcript:
We can see that the three nal members, one only is highlighted here. Then there are many elds which
seem to be initialized here, and we don't know whether they also will change later. They are needed to be
changed or what. But when direct access to private elds within the class seems awkward, you should
fi
fi
fi
fi
 self encapsulate the eld. So we have the nal elds which actually come in the way of exibility. If we
want to make them changeable, then they become private members that need to be accessed
directly. But why then we make them accessible like that instead? And even within the class or to the
subclasses, we should not just make them exible without any checks between them. Because board size
also has to be some, we need a rectangular board in that. Again, the height should be more than the
width. Otherwise, the game is not playable, because you cannot move the pieces longer, the left and right,
and you should get enough time before they fall down to the bottom to move them. So now all these
constraints and all these interchecks, they can be maintained only if we self encapsulate the eld. That
means we make it not accessible directly, but we give a getter and setter method on each eld, and those
setter methods will keep that integrity. The relations between di erent elds, maybe instead of giving the
width and height as two di erent elds, we should give it as a rectangle. It should be one single
thing, because we have to maintain the relation between the width and height. Right, there will be some
aspect ratio also. So all these things can be done if we self encapsulate that eld, and then we can make it
exible as well, because now it's a eld with its methods, okay? And we can even make it into the
instance of which will be a member here. Okay, and now you can see there are so many other elds also
here. Many of them actually don't change during the course of the game. Or if they change, they are
changing in response to a certain algorithmic increment or step or some such deterministic and
predictable sequence. So in that case, we should have an object instead of the primitive type eld,
okay? Because then it gets a meaning and you can give it a name, meaningful name, and its role also will
be clear, the way it will be used. The methods of that object will be called, and you will now know why that
object is there and what it is doing, what role it is playing in the overall progress of the game. Okay, and
this is like make making the data value information. And now if we want to make it into knowledge, then
change that value to a reference. That means it will not be now just an instance of an object, but it will
have a speci c named role, and it will always refer to one unique instance created only once, right? So
that it will have memory of its own role. And whatever is the state of the game. Also the global state of the
game, also it will remember and it will act accordingly. So you have to reorganize just primitive, dumb data
into more smarter and smarter objects and references. Then an array, which is acting as data, it is better
made into an object again.

Refactoring of Data 2

• Hard-coded numbers with special meaning become timebombs; better Replace Magic Numbers with
Symbolic Constants.
• Links between objects can be unnecessarily bidirectional, or restrictively unidirectional. Change
Directionality of Associations as and when warranted.

Refactoring of Data - 3

• Public data or data collection must be Encapsulated, and "naked" records should be Replaced with
Data Classes.
• Informative type code numbers like enumerations, static nal constants etc. should trigger Replace Type
Code with Class: if they are e cacious, Replace Type Code with Subclasses if simple, or State/Strategy
if complicated.

Video Transcript:
Then refactoring of data will have another ill hard coded numbers. Already we have handled some of them,
but those with special meanings become time bombs. This is very important. So replace magic numbers
with symbolic constants. If they are really unchangeable, then make them symbolic constants. If, for
example, you want to make the board size a parameter at the start of the game, you are passing them as
parameters to the main method. In that case, you should have some symbolic constants and some way of
initializing them at the beginning only once, okay? And if we organize code in such a way that names
symbolically ferred only uniquely everywhere, then in that case, it will clean up the code and make it
basically predictable integral. Links between objects can be unnecessarily bidirectional or restrictively
unidirectional. That means sometimes there is no association that is two way, and sometimes the
association should be two way, but it is shown as only one way. So the board and tetris, these two
objects, these two classes here are basically with this confusion between them, because the board
appears to be the global state, indicating everything that is there in the game, whereas the Tetris class is
for the game engine. Now, why are they separate? Or if they are separate, then what is the relationship
between them or to the association?
fl
fi
fi
ff
ffi
fi
fi
fi
fl
fi
fi
ff
fi
fi
fl
fi
fi
fi
fi
 So you have to rethink on the directionality of the associations, and then you can reorganize them. Then
public data, that means data which must be available in the sense global data, available to every class
every, at every instant.

And data collection also may be there, which is public data collection. Many times in data pipelines when
you are using machine learning, then collections are basically public collections, and they don't have a
xed value throughout the program. But what you are referring to will be some kind of a stream, okay,
but it is accessible in a public way. These must be encapsulated, make them into smart classes, and then
access them only through very smart methods of those classes. Naked records, that means records
for which every eld has to be accessible to everyone. They should rather be replaced with data
classes. Data classes are basically those classes which do nothing. They will not have methods, but they
will only give you getter and setter methods so that you can just access them, read them and change
them. And then the integrity or the consistency between di erent instances of the same data class that
can be maintained like a relational database.

Informative type code numbers like enumerations, enumerated data types, then static nal constraints that
we saw just now two slides before. All these should trigger replace type code with class refactoring. So
that is we suggested just now. If they are playing some important role, they are e cacious in the overall
scheme. Then replace type code with subclasses, because then they will have di erent interactions,
message passing between them, di erent roles if they are still in a simple hierarchy, possible. Or
otherwise, make them into state or strategy if they are too complicated. So in Tetris game they are slightly
more complicated and you should treat then di erent aspects of the board class and the Tetris game
engine as state parameters, and they should make for a class of that kind.

In summary, refactoring data is like recollecting the powder fallen from broken capsules and then making
better capsules from it. This is better encapsulation, nothing else. The main aim is to restore data hiding
and encapsulation, and it removes all the threads to conceptual integrity of data.

Refactoring Conditional Expressions-1

• Tricky conditionals can be broken down into pieces by Decompose Conditional.

• Use Consolidate Conditional Expression when several tests have the same e ect.
• Use Consolidate Duplicate Conditional Fragments to remove any duplication within the conditional code.

Refactoring Conditional Expressions-2

• Replace Nested Conditional with Guard Clauses to clarify special case conditionals.
• Remove Control Flag to get rid of awkward control ags if they clutter code for a single exit.
• Switches are proscribed in OOP, so Replace Conditional with Polymorphism.
• For boundary checks Introduce Null/Sentinel Obiects.

Summary

• Refactoring conditional seeks to identify cluttered decisions and pulls or sums them up into a cleaner
and more readable framework.
• This is for readability and conceptual integrity.

Video Transcript:
You can see that most of the statements are conditionals and many of them are repetitive
conditionals. They are checking the same thing again and again and most of the times they're also
checking whether it's an empty shape or it is a non empty shape. Such tricky conditionals can be
broken down into pieces by decomposed conditional and you can consolidate the expression
when several tastes have the same e ect. Both the Ls we can see in this code. Actually, this is not a
contiguous piece of code. I have collected di erent pieces, but all of them are connected with the shape
class, and there will be some conditions on them. Then you can also consolidate, duplicate conditional
fragments such that the code looks more readable, and moreover, whenever there is a change in the way
the conditional is used or the consequences of the condition. It can be then done uniformly at one place
so you replace most of those statements by a method call and a decision on that. Then if there are nested
conditionals, which we have not seen in this code, but you know there can be switch statements also. A
switch statements should not be there. Switch case statement should not be there in object oriented code
fi
fi
ff
ff
ff
ff
fl
ff
ff
ffi
ff
fi
 so you should replace them by guard clauses. Okay. The spatial case conditionals should be moved to the
guard clauses. And then control ags are sometimes used for indicating such spatial cases. And they
actually become awkward most of the time. So if they are awkward, if they clutter code and you are
basically aiming for a single exit, that's why you're using them, either special case conditionals or control
ag. And they are award, then remove them, and how to remove them, how to go to single exit instead
of using some location where you go for an exit, you can have a written statement each time, and atten
statement will depend upon, again, only the same conditional that is used everywhere. Conditional means
conditional expression. Then switches are de nitely prescribed in object programming so replace them
with polymorphism. That is basically what you do. You make a single method call. But now which of the
subclasses Will the call go to? That will depend upon, of course, some of those conditions which
are incorporated the objects instance itself so that is easy to read also, and it will also make the intended
consequence very clear. Otherwise, reading a switch statement, understanding the di erent
consequences is really hard. That's why we don't want it in the OP and then for the extreme conditions,
boundary conditions. You can introduce a special null object for the null shape, for example, there was in
the Tetris game code that I showed, there was this check on whether the shape is empty or non
empty. You can have centinal objects for other extremes. It doesn't have to be always null, but something
like a maximum also you want to see, then there can be centinal objects, they're called. In summary,
refactoring conditioners will seek to identify cluttered decisions. It will pull them up or sum them up into a
cleaner and more readable framework. Again, what we are looking for is conceptual integrity with
readability.

Refactoring Method Callings - 1

• Rename Methods (or variables and classes too) to help them express the "what".
• Add/Remove Parameter as and when suited after review.
• Preserve Whole Object if available, or make one with Introduce Parameter Object instead of passing
several parameters. Eliminate parameters with Replace Parameter with Method if available.

Refactoring Method Callings - 2

• Combine several similar methods by adding a parameter with Parameterize Method.

• Avoid modifying state in response to query with Separate Query from Modi er.
• To cover up methods that can be hidden, use Hide Method and Remove Setting Method.

VIdeo Transcript:
Sometimes the methods are named in such a way that they don't express the what they are doing. You
should rename them rst of all, for that. Then if we think that a parameter should be added because that
will make the method more exible and it will actually indeed represent all the what that it is expected to
do with that name, then you should do that. Sometimes what happens is you want Method 1, Method
2, Method 3 doing similar things to di erent parameters. Now, you have to think whether you want to
clump them together into one method. Then for the conditional, again, you can use the earlier conditional
refactoring. But naming them Method 1, Method 2, with that method part expressing the what, is more
cumbersome. Instead, parameterize it. You can add a parameter. But if there are too many parameters
which do not actually make the decisions clear, remove a parameter. You have to basically con ne the
method's name and a signature to what it is intended to do. It should be expressive enough, and readable
means it should immediately be clear by reading the name and the signature. Then if available for those
parameters which are just cluttering, but they are not changing anything in the expressivity of that method
signature, you can have preserve whole object refactoring. Or you can just make one whole object, which
then becomes a parameter. By using the refactoring, introduce parameter object, instead of passing
several parameters. This is like basically encapsulating then some signature into one object that becomes
one single parameter to a method, which may be a method of another object, and the association
between these two objects also will be then very clear, and we can call it conceptually integral to the
design. Whereas if there are several parameters, then that integrity is not visible. It is lost in the
clutter. Now, if needed, eliminate parameters with replace parameter with method, if one method is
available. Instead of having, again, several parameters having changing values, you can replace the
parameter with method, and that means it will be a composed method, a nested call, which will make it
more exible, at the same time, more readable. Then you can have several similar methods combined by
adding a parameter with parameterized method. This already I have mentioned in the previous slide. Then
avoid modifying the state in response to query. This happens when you have something like a method that
is supposed to only give information out. But before doing that, it changes what it is reporting
fl
fl
fi
fl
fl
ff
fi
fi
ff
fi
 on. Therefore, you have to separate the query from the modi er. You should have two methods, one query
method, one modi er method. Then if you want to return the current value or the current state from the
modi er method, then call the query method. At the end of it, straighten. To cover up those methods that
can be hidden, use hide method and remove setting method refactorings. Now, actually, in the Tetris game
code that we have seen, we want to do the opposite. The private methods that are there in the board, we
want to either move them to the Tetris game engine class or we want to just delegate that delegate
method to some other classes like shape. We don't have that case in the Tetris code.

Refactoring Method Callings 3

• Knowing the class via a constructor can be prevented with Replace Constructor with Factory Method.
• To avoid making the user of a class do downcasting contain it elsewhere by using Encapsulate
Downcast.
• Replace Error Code with Exception wherever possible, or Replace Exception with Test wherever
prudent.

VIdeo Transcript:
We can provide a constructor, and constructors are basically public. But then that may make the class
more visible than we want to allow. In that case, we can prevent that with replace constructor with factory
method. Now, this is a di erent setting which we will have to learn when we do professional level
coding. But what it means is that you can have basically a library that is compiled into binary, and that has
the meat of the work done. Whereas what you provide in the API visible to the user, that means a
programmer who is using your library, you provide a stub. That doesn't reveal any of the internal details of
the class. You have another class, and that will internally instantiate the object using the factory method,
which is in the library. Then you do not want the user of a class do downcasting so that it wants to know
superclass from a subclass. You can have the encapsulate downcast refactoring. This basically
reorganizes a class hierarchy, such that it is not possible to directly access what is there in the
superclass. Then you can replace error code with exception wherever possible, such that the error code
itself doesn't become an entry or exit point or better. You can replace exception with taste if it is
prudent. What this will achieve is that the entry and exit points of di erent methods will not
become, basically, hidden and unpredictable. If you have a test for that, then it is always possible to
write test cases in such a way that you always know consistently when which method will exit where, and
that should not get cluttered in the exception handling calls. In summary, refactoring of method calls is like
cleaning up hasty naming and division of labor decisions. It seeks to restore the designed separations
between the what and the how that get cluttered during implementation. Again, to regain conceptual
integrity.

Refactoring of Hierarchies 1

• Pull Up Field and Pull Up Method both promote function up a hierarchy, and Push Down Method and
Push Down Field push function downward.

• Pull Up Constructor Body deals with issues of constructors awkward to pull up. Instead of pushing
down, use Replace Constructor with Factory Method.

Refactoring of Hierarchies 2

• Use Form Template Method to separate the di erences from the similarities of methods with a similar
body but di erent details.
• Extract Subclass, Extract Superclass, and Extract Interface change an hierarchy by forming new
elements out of various points.

Video Transcript:
We have to use Pull Up Field or Pull Up Method to promote a function up a class hierarchy. Or we want to
actually push it downward in the hierarchy, then you have to use Push Down Method and Push Down Field
refactoring. These are basically just trying to take one method or one eld in a subclass in a hierarchy, and
move it to superclass or the other way around from superclass to a subclass. Why would we do
that? Because then in that case, that is when we move from a subclass to a superclass, it becomes more
general. But at the same time, it should allow overwriting so that specialization happens in subclasses. If
we move something from a superclass to a subclass, then what it means is that now it becomes a special
fi
ff
fi
ff
ff
fi
ff
fi
 property of that subclass and it was not as general as it was originally supposed to be. This will reorganize
the hierarchy. Then you can have a constructor body itself to be pulled up. It is not really prudent to just
pull up a constructor, and that means moving it from one class to another class in the hierarchy. But if you
want to push it down, then you should replace constructor with factory method. That means you basically
want the code to be executed at a lower level but in such a way that it is always hidden and
unchangeable, then you make it into a binary and then it is o ered only as an API call or an instantiation
but from a binary code. Then you have to separate the di erences from the similarities in methods that
have a similar body but di erent details. You have several methods of that kind. Then you have to use the
Form Template Method refactoring. This actually we don't have an example to discuss, but we will see
when we write complex code or we look at somebody else's project, which has a complicated
hierarchy and it's a heavy duty application, we can nd examples for this. But in the Tetris game, for
example, we don't have di erent methods of di erent classes that have a similar body or similar
function, but with some details di erent. Then you can do similar to extract method. You can do Extract
Subclass, Extract Superclass, and Extract Interface to change an hierarchy and you can form new
elements out of various points. This will be basically making the hierarchy cleaner, better to read, better to
manage, make it more maintainable. But this depends on, of course, whether you nd the current
hierarchy either awkward or in some cases, restrictive, that it is basically not giving the freedoms, the
exibilities that are sought.

Refactoring of Hierarchies 3

• To remove unnecessary classes in an hierarchy, use Collapse Hierarchy.

• Using delegation or interface is di cult choice, during refactoring only we can decide to Exchange
Interface/Delegation.

Summary

• Refactoring hierarchies entails some design thinking but more a bird's eye view of the current
implementation of the design.
• It is more like bringing the implementation to align with the design.
• Restoring conceptual integrity.

Video Transcript:
Then there may be some unnecessary classes usually turning up after some refactoring that we do to the
hierarchy. Because we have moved methods up and down, and then some class becomes basically
without any methods, it's not doing much, then you can just remove that label itself from the hierarchy and
it can even lead to a lot of classes in an hierarchy becoming then empty or useless and they become
unnecessary. Then you can have the collapse hierarchy refactoring. Then using delegation, that means you
have some method that you want to be executed for this class instance, but you are actually doing it
via another class object or interface. These choices are di cult. They are not always straightforward. After
we implement, we can look at it again and see whether it is gelling well with the rest of the code, the rest
of the hierarchy also. In refactoring perhaps, then we would want to exchange interface or
delegation, whether it is delegation or interface so that again, there is no xed rule each time we
implement and then look back at it and see whether we want to refactor. It's either way. You can have
interface change to delegation or vice versa. In summary, refactoring hierarchies will mean some design
thinking of course. But it's more a bird's view of the current implementation of the design. You want to
bring up the implementation to align with the design. Again, we are restoring conceptual integrity.

Big Refactorings - 1 (Overhauling)

• Overhauling is less clear to prescribe and takes time.

• It requires a degree of agreement among the entire team (not with the smaller refactorings).
• It sets the direction for many, many changes.
• The whole team has to recognize that one of the big refactorings is "in play" and make their moves in
unison.

Big Refactorings - 2

• Tease Apart Inheritance deals with a tangled inheritance hierarchy.

• Convert Procedural Design to Objects when you see procedural code.
fl
ff
ff
ff
ffi
ff
fi
ff
ffi
ff
fi
fi
 • Use Separate Domain from Presentation when you want to isolate business logic from user interface
code.
• Extract Hierarchy simpli es an overly-complex class by turning it into a group of subclasses.

Summary

• Big refactoring are not redesign, but yet require both design thinking and refactoring of ideas and
implementation both.
• Communication and unity within the team and in the overhauling process is crucial.
• Conceptual integrity is emphasised again.
• Di erent ills demand di erent remedies, and we apply each refactoring in an isolated manner.
• All refactorings are applied in a sequential manner to the latest refactored version. Big refactorings are
done at the very last.
• That is conceptual integrity all over again.
ff
ff
fi
Week-5

Motivation for Software Architecture

Structures, Buildings and the Rooms

• Structures - Types and Uses:

• Bridges
• Monuments
• Buildings - Types, Uses and Sizes:
• Government
• Academic
• Commercial
• Residential
• Sports Complex

Designs and Patterns that Work

• Elements used in the patterns

• Air/Breeze
• Light
• Natural View
• Utility of the structure and pattern
• How it makes one "feel"
• Designs that can be repeated • probability of success
• Each design and implementation provides feedback to improve
• Established patterns

Patterns are the Key

• Patterns capture proven solutions.

• Constitute a "grass roots" e ort to build on the collective experience of skilled designers and software
engineers.
• Solutions to many recurring design problems.

How are Problems Solved

• Primary step: de ne the problem.

• Designers solve problems by recollecting a similar problem they have already solved and reuse the
essence of its solution.
• A expert behaviour
• A problem-solution pair

What is a Pattern?

• Three-part rule:
• Context
• Problem
• Solution
• Each pattern is a relationship between,
• A certain context
• A set of system forces that occur in that context
• A certain con guration which allows those forces to resolve themselves
fi
fi
ff
Model-View-Controller - Architectural Pattern

• Consider an application with a Human Interface (UI).

• UI demands exibility as changes occur frequently.
• Separate the functional core from UI.
• Model: Core data and functionality.
• View: Display information, obtains data from the Model.
• Controller: Receive input from user. A view is associated with it.

Architecture Pattern

• Component
• Relationship:
• Aggregation
• V Inheritance
• Association
• Views:
• state view
• communication view

Video Transcript:
look at architecture pattern from another perspective. What would it have, a set of components or a
component, relationships and views. Relationships like aggregation, inheritance, and association. With
these, you really can form a variety of combinations which allow you to build a pattern which not only is
repeatable, but satis es a particular behavior and a function. We looked at the model view controller. And
now you start going deeper into the model or the view or the controller, and you start looking at the
components that this pattern would be made up of or sub-components that would be required to get that
functionality done. Here, we also see the two views. There is a state view and then there is a
communication view. The state view is about how things progress, how each of these components
or objects move from one state to the other. Some object has data, some object now data is
manipulated. Some object, now the data is further computed, and another additional eld has got
added. States keep changing. Or a communication view. This data that is stored in the model is now being
asked for by the view because the user expected the data to be shown based on an input that came in
from the controller. These things start working in unison. It's like a symphony of component relationships
like aggregation, inheritance, association to provide certain views, and these views could have an internal
perspective, how they operate, and also the external perspective, like when view is looked at from a model
view controller perspective.

Architecture Pattern - Views

• Conceptual architecture: components, connectors

• Module architecture: sub-systems, modules
• Code architecture: les, directories, libraries
• Execution architecture: tasks, threads, processes
• One can draw a parallel between these and views speci ed as Logical view, Process view, Physical view
and Development view.

Video Transcript:
So let's take another look at views per se. Views become very important when you're looking at variety
of architectural patterns because that's how one starts learning about them. And in fact, one
starts building newer patterns based on these building blocks, and views is one of the core building
blocks. It's conceptual architecture, which has components, connectors between them. Module
architecture, which would have subsystems, modules within it. The other two are important and really talk
about how we implement things, the code architecture, and the execution architecture. Code architecture
is about les. How do we distribute these les? If it's C++ as a programming language, or Python as a
programming language, or Java as a programming language, how the les will be distributed? Would they
be distributed, with modules or components in a particular folder, how the folder structure will be, how the
directories will be organized, which libraries will be used, how the libraries would be included. Execution
architecture, how many tasks, threads, processes. If it's a server type of code, how will the tasks help in
processing all the requests that come to the server. These four views classically form a de nitive method
fi
fl
fi
fi
fi
fi
fi
fi
fi
 of thinking in a pattern perspective, as a software engineer. You start looking at things from a concrete
manner, from a construction manner, if you will, to make sure that you are able to build the
architecture pattern to serve a purpose. Here, one can draw a parallel between these and views speci ed
in another manner, which is logical view, process view, physical view, and development view. Again, there
is a variety of literature that talks of this with di erent terms and terminology. One can refer to any one of
them, but the moment you look at it in depth, you will understand that all are saying the same thing. Our
base line reference will always be software engineering body of knowledge. This time we are referring to
Version 3 with Version 4 in the making. Views in the architecture pattern is another in depth way of
thinking how things would really be implemented from architecture [inaudible] onwards.

Architecture Pattern - Properties

• Functional and Non-functional properties

• Functional:
• Directly visible to users
• Aspect but known - algorithm
• Non-functional:
• Interoperability
• Reliability
• E ciency
• and more…

World of Patterns

What is a Pattern?

• A repeated decorative design

• A model or design used as a guide in a craft
• Decorate with repeated design
• Give a regular or intelligible form

Attributes & Characteristics of a Pattern

• Repetition
• Order
• Predictable
• Regular
• "Apply" patterns

Video transcript:
Let's look at some more attributes and characteristics of a pattern. Repetition is one of them. What we
are looking at here is a heartbeat, classically known as the PQRS complex. We have repetition, we have
order. Also, there is predictability. Certain beats per minute are de nitely going to happen, and it is
regular. Repetition, order, predictable and regular, four prime characteristics of a pattern. The moment we
note that a software, the way we have built the solution is repeatable, it provides certain order, gives us
predictable result, and of course, there is enough amount of regularity in occurrence across application
domains, we land up calling it a pattern. Generally, you will nd that for a solution to become a pattern, it
needs to really exhibit some of these characteristics. Ultimately, we got to apply these patterns to
furthermore solutions. In fact, application of these patterns builds the value of the pattern and also
adds value to the pattern itself in terms of one, its usage, it re nes the pattern. The process that would be
followed is, you nd that one solution is applicable at multiple places that becomes a pattern, so the
pattern gets de ned, pattern gets described. The more and more you use it, you land up getting
into de nition and re nement of the pattern. You understand the de nition better, but you re ne the
pattern as you get along with all kinds of implementations.
ffi
fi
fi
fi
fi
ff
fi
fi
fi
fi
fi
fi
Patterns for Design

• Need of a guideline:
• Start with "someone's" experience
• Need to accelerate

Video Transcript:
We need a guideline. All these patterns ultimately are going to add onto someone else's experience into
our design because we would be driving from a pattern that already exists. It's like starting with someone
else's experience. With that, you certainly have been accelerated into producing a better software to begin
with. While we do all this, we look at patterns, we look at solutions. A very custom solutions along with a
pattern mixes together and ultimately becomes a pattern plus something else. That pattern plus
something else can actually become a pattern of patterns. These patterns really are built by underlying
patterns that come together to ultimately solve a problem. Just to take an example, we will use certain
software and certain design patterns and architecture patterns to say monitor re safety equipment in a
building. But monitoring re safety equipment in a building itself can become a pattern because
at application level, they become repeatable. Hence, it is important to make sure that you keep an eye on
these patterns, where they come from, what have they become, and where we can take them.

Patterns is Just the Beginning

• Only patterns are not expected to solve the complete problem; it never does.
• Patterns are templates.
• A pattern or a combination of patterns is a start.

Using Patterns

• Start with "the" goal.

• Goal must be based on the requirements of software product.
• Review the pattern catalogue and pick the relevant one; you may nd more than one.
• Modify the pattern or mix and match to bring out what you need.

Patterns - Reuse the Experience

• Use <> Reuse

• Repeated solutions become patterns

• Patterns have "experience" and proven patterns are the best

• Using patterns builds the expertise sooner

Video transcript:
The use-reuse is primarily from a perspective that we have a pattern, we use the pattern, we land up
reusing the pattern. As we reuse the pattern, make sure that we want to have value added or failures or
lacunas from the previous use are de nitely re ned by the time we want to reuse. So that's one way of
looking at it. The second way of looking at it is we use the pattern and we know that we can keep on
reusing it. And many a times in a platform platform like a mobile phone platform, like a personal computer,
or a platform which has applications related to nance or related to industrial automation, there will be use
and reuse of patterns even without blinking. The reason is these become our proven methodology to
actually ultimately develop applications or apps on it, if you will. So these repeated solutions start
becoming patterns. On a mobile phone itself, if one looks at multiple platforms today, you look at Android
and you look at iOS, the two popular ones, there is still a pattern in which the entire development is
approached. It's not very di cult to maneuver applications or to go through both the phones, iOS or an
Android phone, it's not di cult at all. So these are repeated solutions that have now become
patterns. And these patterns have practically been copied in many areas, the way the GuI is laid out, the
way the apps are laid out. Thus patterns have known to take experience, that is, patterns themselves have
experience, and proven patterns become the best to reuse. They guarantee, no, practically guarantee the
success, practically guarantee from a technical perspective. And many a times using such products or
using such software applications becomes very easy because they follow a pattern. If you need to change
fi
ffi
ffi
fi
fi
fi
fi
fi
the trend, it de nitely takes an e ort to do so because users are used to a pattern to such an extent that
the people who are used to driving with steering wheel on the left hand side or the right hand side will
have an issue when they need to change. Also, from a designer perspective, it is very easy and a good
route to use patterns because it ultimately builds expertise. At this point, one important aspect is as you
reuse or use the pattern, make sure that you get to know what that pattern does. Where does it come
from? Related clearly with the context, related clearly with what kind of solution it is providing. Go to the
details of the pattern itself, so that the application itself can be better designed or the applying of the
pattern becomes better and easier and well, much appreciated.

Thinking Patterns

• One part of using the available patterns

• Other is "thinking patterns" - it is a competency which is key and can be developed
• Interdisciplinary

Video Transcript:
One is reuse, which we speak so much about. Draw from the available patterns. The other is thinking the
pattern way, or thinking patterns. There seems to be how we break down the entire architecture in a
particular way. Or we start looking at a design pattern, can I modify it and make another design pattern
itself? So here we look at thinking the pattern way itself as a competency.

And this competency can be utilized not only in design and architecture, pattern creation and usage,
but also the entire process of designing itself becomes very pattern oriented. You start looking at the
repetitiveness, you start looking at building a hierarchy, maybe. So if you're used to hierarchy the top
down, then one would know that I want to start with a bigger box, break it down into boxes, break it
further down into manageable boxes. This work itself becomes pattern. Now, the need to go outside of the
box of only software design is because ultimately, software is not going to stand on its own. Software
ultimately, in many, many, many application areas, is related to other disciplines, healthcare, nance. Lot of
these interact with other domains, thus it is going to be interdisciplinary. And those boundaries which exist
between the software and where the boundary of the other discipline begins, we want to de nitely blur
it, because software needs to be really part of that particular solution. And the interdisciplinaryness of
patterns and thinking in that way will help us more. This might appear to be a philosophy, but think about
it, dwell on it, and you will understand that when you start looking at software in a particular area, like
healthcare and diagnostics, or maybe all the software and technology that is going in sports today, you
would start realizing that there is a pattern and those patterns can actually lead to solutions. And these
patterns are way beyond the architecture and design patterns, they are like solution patterns itself.

Pattern Orientation and Principles

Fundamental Principles of Design

Emphasis
• Designs focal point and importance of each element

Balance & Alignment

• Balance in composition

Contrast
° Space and distinction between elements

Repetition
• Occurrence of similar elements

Proportion
• Size and weight of parts and their
correlation

Movement
• Using movement to transfer information to the audience
White Space
fi
ff
fi
fi
• Helps organise

Video Transcript:
We want to bring all the elements that are required to be emphasized because those become really
elements that stand out. They may have a purpose. Certain structures provide a great facade or a great
elevation.

Certain structures look good as well as they provide security. Certain structures will not only look great,
but they also provide foundational aspects to the design. Certain structures are elegant, but they
ultimately converge into bringing a lot together, like the Ei el Tower, for example. So emphasis, and we
want to make sure that this emphasis is laid down as a part of design. May be visible to the user, may not
be visible to the user, or at times visible to the user. So what are we emphasizing on? That's the
question. What we would want the user to emphasize on. The next one is balance and alignment.

Balance in composition, and alignment of all the elements that we are talking of.

Of course, this is not that we are just going to get things lined up. It's not about putting all of it in a line
and making similar boxes. It's always about the balance. Balance could be between a large aspect on one
side and a collection of many smaller on the other. There could be a visual balance. There could be
balance of elements that we look at. One can take it to handling data and data structures too. How do we
want to balance and align them in totality right from their smallest element to how they get built to a larger
one? So we need that balance, a balance that can be easily understood and appreciated by ultimately
development team members, as well as the architects or managers or customer who really would
understand internals as well as how it looks. The next one is contrast, space and distinction between
elements. So we want things spaced out and we want distinction between elements. By and large, this
clearly looks at visual aspect. .But let's look at how this can be a non-visual within the design aspect. We
start looking at compare and contrast. When you start looking at compare and contrast, and throughout
the development cycle, you would see that high level design and low level design at times are at
loggerheads. A high level design expects something, but low level design says that, no, it may or may not
be achieved, or it may be achieved in a completely di erent way.

At times you will start looking at error scenarios versus functionality.

Sometimes the functionality is way too little, but the number of error scenarios will be huge.

Input validation for a number eld will have to go through numerous amount of checks so that either it fails
gracefully, or tells the user that you need to enter a number. So many are times, functionality the way it
looks, maybe in contrast. We need to build that contrast. The next one is repetition. I think repetition is
fairly understood easily, very easily that way, because repetition is something that humans are dealing with
day in and day out. Similar elements, similar forms, similar way of design, similar things that are happening
allow an acceleration to be built and to become skilled. It could be at architecture, design, construction
level. But repetition is about seeking repetition too. Can I build something that becomes a repetitive
process? Can I build something where I will be able to repeat certain ways of doing things? I may not
repeat the code, but I'm repeating the execution. Say I use a library, which I use everywhere, it's repetitive
use. But that's what we really look forward to. Proportion, size, and weight of parts and their correlation.

We have all these elements which need to start correlating with each other. They start working with each
other.

High level design or a low level design. Architecture or a design. It starts putting in components
together. And each of these components have size and weight.

They would provide functionality, maybe large amount of functionality. To take an example, there may be a
library which does all computation related to time zones, and we probably need only little portion of it. We
are dealing with, say, two time zones, but it can do a lot many time zones.

The weight of that library is heavy based or compared with the usage that we have. However, it will still go
together because it provides scalability and also will be able to add time zones pretty easy.

The next one is movement. Using movement to transfer information to the audience. Animations, graphics,
that comes in rst to the mind.
fi
fi
ff
ff
In fact, here we could look at even data that moves concurrency that we are looking at. So you start
correlating these as elements and principles that come in into software design. And the last here is white
spaces. Well, well, well, there should be spaces which do nothing. In fact, we always think about white
space as they do nothing. But in fact those are also important to provide that distance, to provide the gap,
to allow that order to happen. Elements organized with gaps or those spaces, the spaces are part of the
design. Spacing things out either in time complexity or we are looking at data complexity or we are looking
at concurrency. A lot can be really put in together.

Borrow from the Real World

Humans create tools; tool create a tool

Nature - forests/living-beings/sea

Man Made structures

Uniqueness to software

Borrow from the Real World

• Foundations
• Abilities
• Maintainability
• Scalability
• Testability
• Usability
• Security
• Evolution of software
• Life-cycle

Video Transcript:
We borrow a lot of things from the real world. If I connect it with software, we really have borrowed a lot
of foundations from the world around us. The way we built speci cally all the civil structures, all the man
made structures which have been built, either the dwellings or monuments or statues, The physics of it
amazingly built in a particular way and amazingly inspiring software. All the abilities, for example, the
maintainability, we got to have things built in such a way that we'll be able to maintain them for a longer
period of time. In fact, maintainability is really a oxymoron in case of some of the applications of
today. Barely you get to maintain till the time the application probably dies. You have something
completely new replacing it, or you yourself with a newer version killing the previous
version. Maintainability? Well, one has to think about how one looks at maintainability, if we look at from a
nature's process of maintainability. Scalability, the growth, the scale at which the software can
fundamentally serve or operate. Testability. Once built, what are my test points? What are those points that
allow me to understand better if the software is functioning in every component in every sub
component, in every module, the way it is exactly required to be. There are aspects related to time,
behavior and functionality. Want it to be usable at all times. Security all the more important in terms of data
in terms of exposing only the required data with the allowed methods, a lot of it. Thus, one would see that
software not only changes in versions. We also notice that there is a complete evolution of software. We
use this term evolution rightfully inspired from the way we have seen the world around us evolve. Though
the nature's evaluation cycles are huge, whereas software evolves pretty quickly for that matter of
fact. The last point is about the life cycle. Things begin, things end, and all that is in between that they
go through a complete transformational mechanism. If we look at a cycle and look at a top view of the
cycle, one would see that there is a spiral that really takes it up, and at times this spiral comes
down, which we'll talk of how some things becomes better and something probably does not remain as
better every time we iterate through it. Software is no di erent.
ff
fi
 Software Processes

• Good and apt process is a must for a good design.

• Rigidity of process: process rst is a bad idea and a liability.
• Enforced waterfall can lead to issues.
• Too much agility and iteration can lead to postponement of decisions.
• High quality delivery is the goal.

Video Transcript:
Fundamentally, one thing is very clear. We always require a very good an apt process to ultimately get to a
good design. Why good? We want a great design? Processes and the choice of processes at times build
certain rigidity. The rigidity comes in from the structure of the process. Waterfall has its own ways. Agility
has its own way. V model would have another way. Iterative would have its own unique way of how it is
deployed. But primarily, we want to make sure our approach is that the process is for software design, and
we don't want to use software design to prove that the process was great or not. In fact, if you want
keep process at test or process under test, then I think our goal is getting the process understood rather
than the design done. We want to make sure that we use a process to get a good design done and no
longer maintain that rigidity. What do we mean by rigidity? If we enforce waterfall in such a way that we
move from requirements to design, and from design, we do not even allow anything to be done in
requirements, we de nitely would have an issue. Simply because now you no longer can revisit
requirements. As such, sometimes the choice of process will depend on how each of the artifacts like
requirements based on that design, how they can be created or how well de ned each of these are before
the next step begins. When requirements are not really de ned well and they're going to evolve and if
they're going to evolve by choice, then maybe waterfall is not the process. On the other hand, if you land
up with too much agility, a lot can change, experiment, you're allowing changes to happen, iteration
comes into play. This can lead to really postponement of decisions, postponement of decisions and
keeping things in check that we are moving from one release to the other in a very systematic manner. We
de nitely do not want that. Thus, too much agility without a goal is also going to be a pitfall. Thus, we
want to arrive at a vital process, tailored right process to deliver high quality of software. That's our goal.

How can Patterns Help?

• Patterns into incremental delivery process

• Sometimes cyclic way of delivery process
• Restriction of re-design to only well-de ned parts
• Use patterns at all times
• Initial <> Boxes to visualise
• High-Level <> Architectural
• Mid-Level <> Architecture well de ned
• Low-Level <> Get to the most detail

Video Transcript:
Patterns typically allow good incremental delivery process. I pick patterns, I can actually prototype, or I
can get a release done with the pattern to a certain level and then make a decision, this works, or I need a
modi cation to it, so it helps iterative process. At times, I know exactly what I want. If I'm building another
Word processor with a completely new target application that I'm looking for, then I'm really concerned if I
get the right pattern, and probably my entire process may not need incremental mechanism. I might just
go by waterfall. I know the requirements. I'll use a pattern and get my design done. Thus, you may have
incremental or straightforward one step after the other. The other way could be cyclic. I'm looking at, I'm
going to go through cycles. Cycles of either iteration or major releases that I would want to make. It is
always possible that by design, the version 1 of a software may be released in a variety of regions with
di erent con gurations, maybe. I'm going to go through multiple cycles for my delivery process. While we
do this, one of the strategies would be that we restrict redesign of anything in any of these cyclic
processes to only well de ned parts. Well de ned parts actually help create better designs. In fact, well
de ned also means that it has been thought through. All feedback has gone in, and then you know that
design is fairly xed. Requirements are fairly xed. Any iteration on that redesign will only better it, of
course, with the right goals. But primarily what we are advising here is we will use pattern at all
times. That's our learning, and patterns come in at four levels here. Initial or the highest level here is all
boxes which will help us visualize. That's the architectural style. We just want to put some things together
and get a visual as to how things would be. Then the high level design, which is architectural
ff
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 and architecture is delivered. Again, a high level. The middle level really is the well de ned architecture into
components. Not so de ned that it will get to the next level, which is get to the most detail. The lowest
level is really the code. We ended up de ning practically ve levels. Four are what we have considered
right now, the fth is really the code.

Levels of Patterns

Architecture Style <> Patterns

• Architecture Style Highest Level

• Architectural Style:
• De nes family of software systems in terms of structural organisation
• Fundamental structure

• Speci ed by:
• When to use it
• Describes invariants & specialisations
• Consequences
• Describe overall structural frameworks

Video Transcript:
So what is architectural style and how does it compare with patterns? Architectural style is primarily the
highest level of de nition of how a system would look like its highest level of boxes being put
together. And in fact, at this highest level, it may be so that you do not even want the interfaces to be
de ned. You may have only boxes that come together. Like in a classical IoT system, you would identify a
device, a gateway, a server, and a database. That would be the highest level. How they get
interconnected, how they work with each other, gets into the lower levels. So such kind of a architectural
style really de nes a family of software system in terms of structural organization, how they would look
like, how they would be put together. Maybe there are lines joining them, but the arrows may or may not
make sense at that level. It's just that they're going to be connected and they're going to be
communicating with each other. In fact, many a times you would nd that there are boxes which are
drawn. For example, there would be multiple devices. And we would put a box which says device
management as one area. And we do not even know how that would happen. But we need that device
management pictorially represented if you are managing numerous devices, say, as a part of IoT
solution. Thus, architectural style is going to provide us a very fundamental structure, but that's the place
to begin.

Requirements, product the way we discuss the system with the users or with the customer is what will
lead us to this particular fundamental structure.

In fact, this is like the back of the envelope or a drawing on a paper napkin that people generally do. This
is where it begins. Again, we are not trying to look at it as a drawn and thrown out, but we want to draw it
and better it.

So all these architectural styles will primarily come in and bring variety of advantages with it. Architectural
styles actually talk about when would you use those boxes, how all of those structures would come
together.

It would describe invariants and specializations. What is it that we are deriving out of each of these? Say,
when it's a database, we are looking at a MySQL-like database, or we are looking at a document
database, NoSQL database, for example. So variety of things can still be de ned at an architectural style
level. And even at that level, when the architecture and the architectural style is put together, one can start
evaluating and analyzing the consequences of it. Presence of a box, absence of a box. Presence of a box
and interconnection, how would it really operate?

Ultimately, such rst document or an artifact like a diagram and some description is required to describe
the overall structural framework of the system.
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 Frameworks

• A complete software (sub)-system.

• Framework:
• De nes architecture for a family of (sub)-systems.
• Provides basic building blocks to create them.
• De nes places where adaptations for speci c functionality.
• Example: In an OO environment a framework has abstract and concrete classes.

Video Transcript:
A framework is a software subsystem, and in fact both architectural style and software framework, which
is a subsystem or a system. At times one would like to call every system as a subsystem, because
ultimately delivers into a larger system. So there may be all these subsystems, and then there is a larger
subsystem, and then there is a larger subsystem. But what does a framework do? Framework really
de nes architecture for a family of subsystems. Say we have a framework, which is a UI framework, we
have a applications framework. So each of these frameworks ultimately allow creation of something
speci c, but they provide all the building blocks to make it happen. In fact, if it's a UI framework, it would
provide all the methods, all the architectural blocks within it, to ultimately create variety of UI elements. If
it's an application framework, it will allow instantiation of an application. The navigation and the ow, the
events that would come in those will have to be handled and ultimately exiting or closing the
application. So these become really frameworks for us. And within a framework one would also de ne
exact places where adaptation for speci c functionality can happen. And that is where the users of the
framework can get their own creativity. In fact, frameworks can become very rigid, like a security
functionality on a mobile phone, pretty rigid. The system does not allow certain data to be shared without
user permission, but uI, for example, or navigation within the user space. Go ahead, de ne the way you
want it and make it cool. So frameworks have their own way of dealing with things. Architectural style and
frameworks are two concepts which allow fundamental start to any discussion of larger software. We can
take another example related to any object oriented environment, a framework that has abstract and
concrete classes, both. We would repeat the example that we gave, security in a mobile phone versus UI.
All of it can be done in a particular way, and this is what frameworks allow you to do.

Design Patterns

• Medium-scale patterns
• Strong in uence on the software sub-system
• In uences/de nes
• Structure
• Organisation
• Access Control
• Handle Objects
• Communications

Video Transcript:
So design patterns are really medium scale patterns. The lowermost scale can be much detailing,
detailing down to method level and what kind of algorithms and ultimately the code. But these are medium
scale patterns. Primarily, much detailed than architecture. However, do not have the rigidity in terms of
how do you need to implement it. For example, patterns are always associated with object orientation
because we always talk about objects. But necessarily, you don't need an object-oriented language. You
could have a language like c in which you can de nitely implement all these patterns. So what do these
design patterns in uence? They in uence or de ne structure, how the whole thing will be structured, the
organization, who works with whom, in what way, access control, how things are accessed within
that particular structure, how the objects are handled, and nally, how do they communicate with each
other. All of these really ultimately form a entire blob with all these internals of this particular blob, which
can be reused. So I can take it from one place and use it in the other. That's the primary use of a design
pattern.
fl
fi
fi
fi
fi
fl
fi
fl
fl
fi
fi
fi
fi
fi
fi
fl
fi
 Week-6

Cross-Cutting Concerns

• Cross-cutting Concerns (C3) are not easy to

separate.

• They a ect more than one class.

• They go across module boundaries.

• The use-cases are most common examples.

Video Transcript:
Now, there are some concerns which are not easy to separate. These are cross-cutting concerns. These
are not easy to separate because they a ect more than one class. Sometimes they go across modules,
not just class or subsystems. Also, they can completely pervade the whole system design itself. So in that
case, we have to look for not separation of concerns, but then separation of solutions which will go hand
in hand, simultaneous solutions, but then the implementation of that or even low level design for those
concerns which go hand in hand together can be still done independently in di erent modules by di erent
teams, and so on. Use cases are most common examples of cross cutting concerns. Typically, use cases
will tell you that a customer comes to a system, then the customer will engage with the system in the
beginning with some login or some such process of identi cation. After that the particular task that the
customer has brought to the system will be communicated, and after that the system will also then o er
di erent services, di erent options, menus and so on. And all these use cases will tell you things that go
across so many di erent modules, subsystems. Sometimes even one portal is actually acting as a front
end to so many di erent web servers which are independent sites in themselves. And if now the portal is
handling those services from one single point of entry, then these use cases are most complicated
and they will be cutting across so many di erent subsystems. So these are always leading to these cross
cutting concerns.

MultiPlayer Tetris Use-Case Diagram

Cross-Cutting Concerns in MulTetris

•Server-client communication.

•The server is supposed to control the game pace.

•It also should assure that each client gets the

same stones, especially in the same order.

•All clients have the same conditions.

• The server also keeps track of the di erent clients scores.

Why C3 are Important

• Keeping concerns separate is a concern: modularity and components help partially.

• Modularity and components not su cient to handle C3.

• Observe this refactored class diagram for the MulTetris.

ff
ff
ff
ff
ff
ffi
ff
ff
ff
fi
ff
ff
ff
When are the C3 Worrisome?

• Infrastructure concerns to meet nonfunctional requirements: e.g. logging, distribution and transaction
management.

• Functional requirements that concern multiple components.

• Localisation requirements.

• Peers: Equally important modular concerns dependent in real-time; leading to tangling and scattering.

• Extensions: Overlapping concerns when an extension in one module warrant modi cation to another.

Video Transcript:
So when are these cross-cutting concerns worrisome? That is, they are a serious challenge such that you
have to start considering them from the beginning in the design process itself. So there are infrastructure
concerns. This client-server communication is an infrastructure concern, but they usually meet non-
functional requirements, right? So for example, logging, distribution, distribution is what our client-
server communication does, transaction management. That is also a concern for this client server
communication. These are infrastructure concerns. They are, of course, worrisome with railway reservation
or airline reservation systems wherein you have to ensure fairness across di erent clients. Again, similar
concerns occur. That is what we were considering for multiple layer territories. The same thing happens
there also. Functional requirements also can cause some cross-cutting concerns.

These are related to, for example, bank transactions in which you have to make sure that as soon as an
amount is withdrawn from an account, correspondingly that account's balances should be updated. Not
only that, if the account is in fact a joint account or it's a corporate account, then all the other taxation
and other triggers should also start immediately. For example, if it is a cash withdrawn, then
correspondingly the cash credit accounts also should be updated and then the interest calculations and
so many things will also get triggered. And all this has to be done in real time so that no one gets the
advantage of the gap between the updates or even disadvantage also should not happen. The bene ts
should be immediately accrued. So these become functional requirements that create serious
cross cutting concerns. Then there are localization requirements. That means, for example, I am traveling
and say within six hours I go from one continent to another continent. The time zone has changed, so
many things have changed and my mobile phone apps are still running. I didn't switch up the mobile
phone along the way as soon as I land there. Now the phone has to keep serving me in the way I can use
it, for example in the language that I am using it in. At the same time, it should also give me the latest
updates of the locale in which I am. For example, if it shows the names of the places I am in in my native
language, I may end up pronouncing those names incorrectly, and that may lead to buying wrong tickets
or reaching wrong destinations. So all these requirements will create again very serious cross cutting
concerns. There are two types of such concerns. That is, even though the variety comes from the real
world applications, there are two types, peers concerns. Basically they lead to tangling and scattering of
concerns because of equally important modules. They are dependent in real time in the use cases,
but they are not dependent on each other in that software development. So this will lead to scattering and
tangling. And then there are some extensions which require again updates to many di erent classes in
many di erent modules. So extension is not separable easily.
ff
ff
fi
ff
fi
 Peer Pressure

• Two concerns are connected at runtime: the green shape and its shadow
below.

• They are peers but not independent.

• No one peer is more important than another.

• To implement them in the same system, their overlap is a hurdle.

• In this example, shapes, their “shadows" and the board are tangled together.

Video Transcript:
Suppose that we want in the Tetris game the shadow of the piece that is falling currently, such that the
player always will see where that piece is going to land at the bottom. Now, this shadow will not always be
on a at surface. For example, if this green piece on the right had been only one column to the left. Then
its rst brick would land on the white brick at the bottom. That means the remaining bricks would remain
hanging in air, and there would be a gap in the line below. The player would want to actually take it to the
extreme right where it is now. That means the player can be guided by the shadow that is shown at the
bottom, so that the gaps are not left there. Now, if we want to give this additional service, this is an
extension in a sense, but it is not an extension in software necessarily. You may implement it as an
additional service. That's all. Now where to look at this service, this becomes a cross-cutting
concern. These concerns are connected at run time. The green shape and its shadow below, they are
connected. They are peers and in a sense, they are independent, but they are not exactly independent
because of their real time connection. No one is more important than the other. To implement them in the
same system, there is this overlap between them, and that is a hurdle one is that whenever the actual
piece moves, the shadow should move. But now the shadow doesn't move in the same way as the
piece, it of course moves left and right, if the piece moves left, the shadow moves to the left. But it also
rises up because there are hurdles. If now this green piece moves left, the shadow has to climb up by one
level. Then it moves one more column left, then the shadow has to climb up one more row. Then it goes all
the way to the left, it will remain at that level because now the shadow cannot fall through. Now, all these
things are cross-cutting concerns. The overlap in the di erent behavior of these two di erent entities. They
are peers, and their behaviors are at once connected to each other, they are linked to each other, they are
associated, but at the same time, the association is not straightforward. We cannot just mirror them,

we can call this entanglement. The shapes, the shadows and the board because what is there on the
board at the bottom, at any given point in time, that will decide how the shadow modes. Then when the
piece is near the bottom, the piece also may be restricted by the bricks. The shadow is restricted only by
the piece itself. In that case, if the piece has reached the second roof from the bottom, then the shadow
cannot actually move even if the piece moves. Then at some point, the shadow has to disappear and the
piece just settles down. All this creates this entanglement of the shadow, the shape and the board
together. Now, if we choose to associate an additional shadow class, which is just an extension of the
shape class, or rather it can be even a mirror of the shape class with an additional property. That the color
is always a shadow color. Otherwise, it has the same movements and all that. But now, the peers
concerns are shattered across the shapes and the board, because the board has to also consider where
the shadow can move, and the piece can move. They have to move in unison, but at the same time, their
behavior of movement will not be the same. As I explained, that is the shadow can climb up and
down, whereas the piece has to continuously fall down, and all this has to happen in that real time.

Video Transcript:
Now there are the shattered concerns across the shape, the
board, and the shadow. When there is a left to right movement
of the shape, you can see that the board has to update both the
shape and the shadow, and both shape and shadow have to
communicate with the board in the two way
communication. Shape and shadow are linked together, and
they are also linked to the board, and all the three will have a
tightly coupled communication between each pair. Similarly,
when the shape rotates again, the board will get updates from
both of them, and then the falling will only have a connection
fi
fl
ff
ff
 between the shape and the board, the shadow is not involved in that. Once the shape falls down, it is laid
down, then the merging operation and the collapsing of the shadow will update the board again
together. These are shattered concerns because of this peer entanglement.

Extended Agony

• It is the inability to keep extensions separate.

• Suppose we extend Shapes to include their Shadows too.
• This would require changes to the Board.
• It will require the Board and each falling shape to communicate with each other to update the shadow
height.

Video Transcript:
Here, we have now, again, the same example of a shape and its shadow in the Tetris game. There is this
inability to keep extensions separate when we want to extend shapes to include their shadows too. So
what we are now going to do is not have shape and shadow as two di erent classes, but we extend the
shape class itself to include the shadow too. This will of course require updating the board's
implementation as well. It will also require the board and each falling shape to communicate with each
other to update the shadow height. That means the row in which the shadow is lying. This already we have
discussed earlier in the video on peer concerns. But here, even when we are trying to extend the shape
class so that there are no two peer shape and shadow that are entangled, now there are these shattered
concerns still there between the board and the shadow
extended class. This is basically saying that the extension
is intrusive, it cannot be separable. The extension to one
class will require changing or updating another class is
shown in this diagram, that there will be some glue code
that you would require in the shape class in order to be
able to extend with the addition of the shadow or inclusion
of the shadow in the class. The extension is on the
right. But now you will also have to design that glue code
in the board class, which is at the below. That will require
basically either a redesign or an update to the class. If you
have not already designed this possibility of an
extension in the board class in the original design. This is
an example of intrusive extensions.

Aspect-Oriented Design: Design Principles

Recap

• We want to keep concerns separated as far as possible, and when we cannot, we want to design in
such a way that the cross-cutting concerns are designed, implemented and maintained in a coordinated
and consistent yet modular fashion.

• C3 a ect multiple classes or modules or subsystems.

• Peers: Equally important modular concerns dependent in real-time; leading to tangling and scattering.

• Intrusive Extensions: Overlapping concerns when an extension in one module warrant modi cation to
another.

Attacking the Problem with Aspects

• Aspect orientation provides a mechanism to compose additional behaviours from outside a class into
the class itself.

• Moreover, it also provides a way to separate implementing di erent concerns into separate modules.

Video Transcript:
there is this mechanism, aspect orientation or aspect oriented programming. It's a conscious approach
and that is more recent. It provides a mechanism to compose additional behaviors. Additional means,
ff
ff
ff
fi
 whatever we have already thought about the class or the module that we are designing, independent of
other things. We already have thought about what is the role? What are the di erent capabilities
or expectations from this class or module. So all those things are we can say, default and natural behavior
of that class or module. But now we want to compose additional behaviors than that. Those additional
behaviors are coming from outside that class or the module into itself. So aspect orientation will provide
you a mechanism to compose that. When you are designing the class, you are still thinking of that class or
that model. But then aspect orientation will also give you a way to incorporate those other cross cutting
concerns also into this design without disturbing the design of the class in itself. Moreover, it will also
provide a way to implementing di erent concerns into separate modules. In fact, we are not treating
classes and modules di erently here. It's only a level of granularity or organization. What is an aspect,
ultimately? So a concern is any code related to a goal, a feature, a concept, or a kind of functionality.

What is an Aspect?

• A concern is any code related to a goal, feature, concept, or "kind" of functionality.

• An aspect is a concern whose functionality is triggered by other concerns, and in multiple situations.

• Aspects provide active support, not just textual code manipulation, for separating concerns in source
code.

Hows and Whys of Aspects-1

• Aspects manifest in requirements as behaviour that is described as being triggered by many other
behaviours.

• Desirable: seamless traceability between the design and code.

• This requires special support for aspects in analysis and modelling of design.

Hows and Whys of Aspects-2

• Intertype declarations allow you to compose new features (attributes, operations, and relationships) into
existing classes.

• Advices provide the means to extend existing operations at extension points designated by pointcuts in
AOP.

• Aspects are a kind of building block used to organise intertype declarations and advices. Aspects can
generalise other aspects.

Cross-Cutting Concerns in Tetris-4

• The fairness requirement is to be maintained by the Engine, but this is ne as long as the pieces are of
xed kinds.

• What if we want the set of shapes to be extensible?

• This extension is intrusive because it requires the Engine class to know how many subclasses or kinds
of the Shape class are there.

Cross-Cutting Concerns in Tetris-5

• The speed requirement also is to be maintained by the Engine.

• But it requires the board to update the Engine about emerging

events such as a piece nally ceasing to fall.

• The speed set by the Engine also governs how and when the
board updates itself and the falling piece.
fi
fi
ff
ff
fi
ff
 Aspect-Oriented Design for Tetris-1

Video Transcript:
So now, how we actually do incorporate these
concerns in aspect oriented design. And here is
the coding, basically. This is a pseudocode, that
incomplete code basically, but this is how that
code will be. So we begin with a declaration, an
explicit declaration of the aspect that this is
going to be an aspect that means this is
something that is cross cutting, this is the
identi cation and we name it. So moving of the
shape is one of these concerns, cross-cutting
concerns. Moving of the shape will require the
board and the engine both to be involved. And the movement can be left right also, and the pieces falling
continuously, and nally, ceasing to fall. So all these come together into one aspect and then we have
some repetitive code and other things around. But the main important part here is wherever we have the
shape dot move method. Now it is, we can say wrapped into this aspect. Now this method is not just
there in the shape class, but it is wrapped into this aspect declaration. So you actually have the imperative
code that does the movement left, right, up, down, whatever it is. And, but the wrapper tells the compiler,
and later on the virtual machine also that this is something that is having some kind of cross cutting
concerns, some triggers will go to other classes. So there is this together, wrapped in the same
aspect, update of the board, okay? And then you have the code to update, engine update, again, wrapped
in the same aspect. And after this you have all the wind up code and that nishes the whole aspect. So
you can see that we are just bringing together the tangled and scattered concerns because of peer
tangling and scattering. The cross-cutting concerns across peers we have brought together in one
aspect. This is a simple solution for the peer level problems. So keeping peers with aspects, this is the
solution part one.

Cross-Cutting Concerns in Tetris-6

Video Transcript:
Another, the intrusive extensions that we have
seen, those concerns, how to address them. So
here is a diagrammatic representation. Again,
this is a extended UML type representation. We
can see that if there is a new shape, and this is
basically engine is generating a new piece, new
piece of some shape. One of the shapes
available. But if it is a new shape, that means it
is a shape that the engine has not seen so
far. Then one the shape list has to be
updated. That means the engine has to also
keep a shape list. So whenever a new piece
arrives, engine checks whether it is a new kind or
not. So, of course, you have to provide that self-identi cation in the shape class as well. If you are making
subclasses for each kind of a shape, then also or otherwise also if it is directly dependent on the
values, that means the arrangement of those bricks in the shape and the shape class is just one class
without hierarchy. Even in that case, you will have to have some self identi cation, internal identi cation of
the type, and you can use enumerated types, you can use some numbered coding, magic numbers
type. But all that has to be done together, shapes and engine both, similarly with board also. Now, so
update shape list and update the probabilities because you want the fairness to go across all the
types. That is, you should not make it fair only for a certain types of shapes and the other types may be
even left out. They will not appear much at all. Then in that case your model is not fair, so you have to
update that. Otherwise, if it is not a new shape, it is a shape that has already been seen. That means in the
probability model, it is already incorporated. The fairness applies to that kind of a shape as well. So then
generate new piece from one of those available shots, that's it. So this is the way we represent the
concern, okay, to handle intrusive extensions.
fi
fi
fi
fi
fi
fi
 Aspect-Oriented Design for Tetris-2

Video Transcript:
Now here, we have the expression in aspect
oriented language, AspectJ. So again we have to
declare it as an aspect explicitly. And now we
introduce a point cut. So if you look at the slide
there, we have the point cut as a decision, the
diamond. So we have that point cut expressed
here explicitly. GettingNewPiece will get cut into
two di erent branches. So you execute
NewPieceInstant call, whatever is the method
for the engine that introduces a new piece in the
game. And after this you have to give this advice
after throwing. You are doing this execution before
throwing ShapeNotFoundAssertionException. So if that shape is a new shape, it was not found in the
engine's knowledge base, then it will throw an exception. And now you are giving an advice just after this
execution. Advice what to do after throwing that exception. So if that happens, then GettingNewPiece will
update engine shape probability distribution rst. And then this pointcut will also nish because then
whatever happens after that has to continue in the same manner. The point cut was only regarding
whether it's a new shape or not. This is how we keep intrusive extensions handled by this

Aspect Orientation in Design: Summary

• The Aspect-Oriented design primitives in AspectJ are:

• Pointcuts (for the intrusion or pervade points for extensions)
• Execution, after throwing and Proceed advices
• Call advice
• These handle peer separation and intrusive extension challenges.

Designing for Services on Networks

Distributed Systems

• Collections of physically separate, possibly heterogeneous networked systems.

• Providing access to various resources maintained in the system.

• Issues in addition to usual software construction issues in distributed software design are concurrency,
communication, and fault tolerance.

Video Transcript:
Distributed systems is a general answer. That is the common framework or common backbone of all such
services will be distributed systems, which are collections of physically separate, possibly heterogeneous
networked systems. This is important, networking, now we take for granted. In fact, if one is not on social
media, doesn't have an email ID, and the phone number is not known to so many people, then in fact we
assume and sometimes the persons themselves also assume that they don't exist.

Now, on these networks, we have services or systems providing access to various resources that are
maintained in the overall network system. I'm talking of subsystems or systems connected entities
connected on the network, they maintain resources, and then they are o ered on the network-integrated
system. This integration, again, we'll look at in more detail. But roughly we take it for granted that there is
some network when my phone somehow is not connecting because say perhaps I have moved away from
my usual circle of networking, then I will request somebody else and I can still get into the network, and
my identity in the network somehow can be accessed also. I can again access the resources by that
identity even if the device that I have may not connect. We have so many di erent entities and they
have the di erent services o ered in an accessible way. Now, here, the issues in software construction for
these services or such systems, and these are not systems designed by one, the components are
designed, then the component's integration is designed by so many di erent entities, so many di erent
people, so many di erent commercial as well as public organizations. In this sense, when we are talking
ff
ff
ff
ff
fi
ff
ff
ff
fi
ff
 of software construction for these services on a distributed system, which all may not be in your
hands, and it will most probably not be in your hands, then the issues, in addition to the usual issues will
be concurrency, communication, fault tolerance. This is the main thing that we have to consider as
something spatial in software design for distributed systems.

Architectures for Distributed Software

• Client-server
• 3-tier architecture
• n-tier architecture
• Distributed objects
• Loose coupling
• Tight coupling

Video Transcript:
The architectures typically will be client server in which there are clients which are seeking services and
servers which are o ering services available on the network again with some identity. Clients also have
identi cation, you log in with your email ID and whatever, and servers have their identi cation like
google.com for search. It's a server. It's a search engine, it's a server, and we are clients, we connect to
Google for search. Three-tier architecture is another option in which there will be a middleware, there will
be a server, but that will be more or less transparent or not seen. There will be middleware that will
o er di erent services from di erent servers maybe or some uni ed services identi ed as something
commonly understood, common since naming of that to clients and client and server both in each such
situation may be unknown to each other. Then there are n-tier architectures in which, well, there are many
more layers, and all the layers except for the top and the bottom or the application layer, the front end to
the user, and the actual server at the bottommost level. Apart from them, everything else is
middleware, but the middleware also has layers. Then we can have everything o ered as distributed
objects, objects o ering services. They may not be even named entities, except for what they are
doing. Something like we don't have a postman, if you have seen from old times who wears that uniform
of the post o ce, but there are so many couriers who can just carry the letters and other objects for
you. Similarly, we have distributed objects. There can be loose or tight coupling between all these di erent
entities involved in the di erent architectures. There may be loose coupling in which the entities involved
are coming together without any central control, so we call it distributed system with a distributed
control. Whereas, there can be tight coupling in which the system is distributed, the entities are distributed
in geography and other ways, but they are controlled by some central entity, so there is a tight coupling in
that case.

Concurrency and Communication in MulTetris

• The server is supposed to control the game pace.

• It also should assure that each client gets the same stones, especially in the same order.

• Hence all clients have the same conditions.

• The server also keeps track of the di erent clients scores.

Video Transcript:
Now here, there will be obviously this concurrency and communication issues. The server is supposed to
control the game pace. That means in Chase also, for example, there are times. Both the players have
timers, they have to be real time. Sometimes it happens that the connection is either slowed down or
interrupted in between. I don't see the update of the move that my opponent has already played. But on
my app on my screen, I see still that I'm waiting for the opponent to make the move, and the opponent is
still thinking, the clock is ticking. But then suddenly, everything gets updated. The move is now updated
on my screen also, and the timers are readjusted. All these are supposed to be handled by the server, and
the server also must make sure that each client gets the same pieces in this case or in chase, for example,
the beginning state, and then there cannot be any cheating, no fault play between. I cannot reverse my
move unless my opponent also agrees to it, and so on. Similarly, in Tetris there will be the fairness
requirements. Then all clients have the same conditions. That is what the server has to ensure. That means
server will keep track of these di erent clients scores, sessions, states of their games. If they have
ff
fi
ff
ffi
ff
ff
ff
ff
ff
ff
fi
ff
fi
fi
ff
paused, then what do they resume with whatever has happened with the other players in between. Will
they resume at that pace or they resume where they had paused, and so on, these policies. These are all
concurrency and communication issues for this particular example.

Fault Tolerance in MulTetris

• If a client disconnects or a client game session is disrupted or paused, other clients’ experience must
not be altered.

• For instance, fairness requirements should not be applicable to the non-playing client.

Video Transcript:
Fault tolerance. If a client disconnects or a client game session is disrupted or paused. Then other clients
should not even get a ected by that. This is fault tolerance. Otherwise, the system will just break
down. One client's connection goes o and the system breaks down. In the case of Chase in which it is
one to one connection between two clients. They are playing together, but they are playing through the
server. This is very important. The connection is snapped on one player's end, and if say the time runs out
of the whole game, but that is known only later, what happens to the client, which remain connected. That
policy, the server has to make and execute, that is fault tolerance. Fairness requirements should not be
applicable to the non playing client in that case, for example. If, for example, some client disconnects on
their own, and that's possible, they just go o the network on their own. Now, if you give them some
concision because of that, you give them a time quantum that they missed, assuming that they missed
it, not because of their choice. In that case, it will be unfair to the other clients. In any case, for any
reason, if a client cannot be connected, now the server cannot make other clients pay for it or su er
because of it. Now, that will be fault tolerance in this case. In bank transactions, for example, fault
tolerance will be related to record keeping, tallying all the records. Di erent lasers have to come to the
same agreement of the transaction at the same time. It cannot happen that one transaction is recorded
in one laser at one place before it is updated at the other place, and then the two lasers are not agreeing
with each other. That cannot happen. This will be again, false tolerance. That if the transaction is not
through and through, then there should not be faulty records, inconsistent records across the network. The
whole system has to agree.

Service-Orientation

• Service-oriented architecture is a way to build distributed software using web services executed on
distributed systems.

• Services used may be from di erent providers because diverse standard protocols (such as HTTP,
HTTPS, SOAP) support service communication and service information exchange.

Client-Server Systems 1

• The relationship between two subsystems can be client-server or peer-to-peer.

• In a client-server relationship, the client calls on the server, which performs some service and replies
with a result.

• The client must know the server's interface, but the server need not know its clients’ interfaces because
clients initiate all interactions.

Video Transcript:
There will be client server systems as I mentioned in multiple player Tetris and chess. In this case, the
relationship between the substance, the di erent subsystems will be client-server or peer-to-peer. So peer
to peer is not the same as my playing game with someone else using an app because that app is my
server connection and I am actually connected to the server. I am not connected to the opponent directly
when I am playing chess online on an app. So peer to peer network is when I can directly connect to the
device of the opponent. That is a peer to peer connection. There is no server in between.

These are two di erent types. In the client server architecture or relationship, the client will seek the
service calls on the server and that server will then perform an o ered service which is already available at
ff
ff
ff
ff
ff
ff
ff
ff
ff
the click of a button or something like that. Or even a text mode command can be sent to a server and we
can get, if you are not used, you can even make it a point to try using the wget command line browser. It's
a browser, it's a downloader and of course you cannot use it easily because there is no screen with a
graphical user interface. The front end is cryptic. Whatever is the server's response will come to you like
one HTML page. And if you cannot interpret that or you don't have any renderer to show it on the
screen, you perhaps will not be able to make sense of it by your simple naked eyes.

Now the reply is in the form of again some kind of information exchange and that result will be then
rendered to you, o ered to you by your browser or whatever is your front end, your app, like in chess
game, there will be a board and that will be shown. It is information exchange, but then presented to you
by the front end in di erent forms, that is, di erent forms that are easy for humans. The client has to know
the servers interface, that is protocol, then how to locate the server each time. Because each transaction,
even though it is like a continuous session, actually it is broken into so many di erent tiny components
which are continuously exchanged information pieces which are continuously exchanged, that is
interface. But the server need not know the clients interfaces. That means the front end, all that because
clients will send commands, demands, requests and so on, they will initiate all interactions and they will
have to follow the server's particular API, application programming interface that will be satis ed by the
clients. The server doesn't even bother about how the clients are doing that on the front end or how they
are interpreting or visualizing the received information from the server. So these two things are completely
separated.

Client-Server Systems - 2

• In a message-passing (distributed) model, all computers run some programs that collectively achieve
some purpose.

• This model can be further classi ed into client-server (C/S), browser-server (B/S), and n-tier models.

• In the B/S model, the server provides services, and the client is the browser.

Video Transcript:
Now in another setting, client server systems can have a distributed message passing model. All
computers will run some programs, that is all the computers involved in that transaction, that service, that
station, each one will be executing some program. Collectively those programs will collaborate to achieve
some purpose. This model can be client server as we have seen earlier, or there can be browser server
model. Your Google search or any other search engine that you use is a browser server type model. And
then there can be n tier models in which there are di erent layers of servers and clients. Each layer is a
client to its lower layer and it is also a server to the layer higher up, that is an NTR model. In the browser
server model, the server will provide the services. Client is the browser itself. At the BlueGate is also a
browser in that sense, even though it doesn't give you a screen to browse easily.

Client-Server Systems 3

• In the n-tier model, each tier provides services to the tier immediately above it and requests services
from the tier immediately below it.

• In fact, the n-tier model can be seen as a chain of client-server models.

B/S Model:

• Using the Google search protocol is as simple as requesting a page from a web server. The Google
search request is a standard HTTP GET or POST command, which returns results in either XML or HTML
format, as speci ed in the search request.

• The search request is a URL that combines the following:

• Your Google Search Appliance host name or IP address, which were assigned when the search
appliance was set up.
• Search interface port (default HTTP serving port: 80 for HTTP and 443 for HTTP over SSL/TLS).
• A path describing the search query. The path starts with "/search?" and is followed by one or more
name-value pairs (input parameters) separated by the ampersand (&) character.
fi
ff
ff
fi
ff
ff
ff
fi
 Division of Labour and Locating Computation

• "Who" does autocompletion of your query?

• Who gives the suggestions?

Practical Examples of Designing for Complex Service Software Systems

Requirements - 1

• The goal of aspect-oriented programming is to keep concerns separate.

• Correctly identify and structure concerns early in the life cycle of the project rather than as an
afterthought during design and implementation.

• Separation of concerns must start during requirements.

• This does not mean capturing every detailed requirement for each concern at the beginning of the
project.

• Instead, systematically organize stakeholder concerns to scope the system.

Requirements - 2

• Piece-movement and board interaction must be disentangled.

• Take a dirty, procedural implementation to nd out the entangled concerns.

• Must pieces be members of the board or independent objects?

• Check collision:
• self.board,
• self piece,
• (self.piece_x, self.piece_y)

Video Transcript:
We want to give peace movement and that has to interact with the board, and the board interacts with the
end user, the player through the engine, which also has a UX component. They have to be
disentangled because when they are entangled, we cannot easily separate the concerns. If you take a
dirty procedural implementation, which is available on the Internet, many Python programs are available
on the Internet to play Tetris. You can also modify them. They are customizable, source code is
available. But we look at them to nd out the entanglement. This is where the concerns or the design
choices at the beginning stage will appear. The question is, must pieces be members of the
board? Members means they are just components in the board class, or they are independent
objects which interact with the board? That is the concern here. The requirement of checking
collision. When a piece is falling, it may hit some of the blocks which are already there at the bottom. The
bottom also rises when pieces are falling on top of it. When the collision occurs at which low level is not
xed beforehand, it will be only when the current state of the board is known to the piece or the other way
around, the board gives a message to the piece that you cannot move here and there. There is this
interaction involved in checking collision. One implementation takes the board as a member of the
engine. Then piece as a member of the engine, the current piece that is falling. Once it has fallen, then it
ceases to be a piece, it becomes just so many bricks, which are spread. Then in this implementation, we'll
need to also give the x and y coordinates the shapes boundaries in the check collision method. Now the
check collision method will have to take the di erent details of the board, the details of the current
piece, and the position of that piece, vis-a-vis the board itself. These three become three di erent
parameters to the check collision method in this dirty procedural implementation. Whereas in object
oriented implementation, rst, you would need the board and the piece to be independent objects, and
they interact, they pass messages to each other, or the engine will regulate the communication between
fi
fi
fi
fi
ff
ff
them too. That means the engine can send messages to both of them and also receive updates from both
of them.

Requirements - 3

• The detailing and re nement of the requirements for each concern can be prioritised and allocated
across the project life cycle in an iterative manner.

• The use-case technique provides the means to systematically model stakeholder concerns by walking
through meaningful interactions between end users and the system:
• Overlaps, inclusions, extensions, and generalisations.

Video Transcript:
The detailing and re nement of these requirements for such concerns, especially the cross cutting
concerns, it can be prioritized and allocated across the project life cycle in an iterative manner. If we
recognize that these are crosscutting concerns and their importance we recognize, then we can keep
reminders or markers for each stage in the project life cycle to see that they are taken care of
adequately. There is this use case technique that will provide the means to systematically model these
concerns. Early on, as well as it will give us the appropriate markers or reminders at the later stages as
well to verify and to also make sure that this is what indeed the stakeholders want or would need. Here we
take care of the overlaps, the entanglements, inclusions, that is whether one is a slave of the
other. Extensions that is when we want to modify one class, but that modi cation will indeed concern or
involve other classes, packages, and modules and generalizations, that is we want to now make
it reusable by keeping these concerns separate and the modi cations or the extensions and
generalizations to be independent, as well as properly informed, incorporated into the di erent aspects
that are cross cutting. Use case diagrams is the way and here we have two options that we have already
considered.

Use-Case Diagrams

• Either the board contains each falling piece as a slave (with

player interaction only with the board).

• Or, the player, the board and the falling piece form a message
passing network.

Video Transcript:
Use case diagrams is the way and here we have two options
that we have already considered. One is, the board
contains each falling piece as a slave with player
interaction, happening only with the board. This is the use case
diagram in not a very formal way, but visualizable
representation of the use case. In which the player clicks
or uses those arrow keys in order to give rotate or move left and right commands. The command goes to
the piece and it goes to the board. But actually, the piece is controlled by the board. Whatever the user is
clicking or giving keys, they are actually passed through the board or by the board to the piece. If, for
example, the piece cannot move, in the desired direction or cannot rotate because of some possible
collision, then the board will check that. Board will check collision. Then the user also interacts with the
board directly by the start, pause and resume instructions again, using keys and keyboard. The other
option is the board and the falling piece, they are independent and the player interacts with both of
them, and they also interact with each other. It becomes a message passing network together. This is the
corresponding diagram representation in which now the ow is from player to the piece, the player to the
board because now the keyboard and mouse events will also go to both the falling piece and the board as
well. Then the piece informs the board about its position, and the board informs the piece about possible
collisions. It's a network in which they communicate. The user of course gets direct feedback on the
screen, so there is no message passing in software itself. But the use case diagram basically indicates
that no one is slave of the other except that the end user, nally, the player is having the controls.
fi
fi
fl
fi
fi
fi
ff
 Aspects, not Functional Decomposition

• A use case is just a special case of classi ers or a stereotype

of classi ers.

Video Transcript:
Here we are representing in the use case diagram aspects. This
is not functional decomposition. We are talking of the di erent
actions by di erent actors independent but synchronizing
coordinating among themselves for the same function. The
overall function is of the system and each actor is having their
di erent roles in that. A use case is a special case of
classi ers, that is a representation of a class or a stereotype of
classi ers. A classi er is anything that is class like. It can be
instantiated and it can be generalized also. When we represent
aspects in a use case, we have to remember that we are treating
that aspect, which is a concern, and that also means it's a
functional requirement, but not as a method of a class. It is
something that goes across classes and modules or packages.

The "Networked" Aspects Use-Case

• Use cases, like classes, are generalisable elements, and their ows can be
either concrete or abstract.

• A ow is concrete when the steps that constitute the ow are de ned, that is,
you have all the text that describes ow.

• A ow is abstract when you have given the ow a name, but the ow itself is
unspeci ed. The actual speci cation is de ned as a child use case.

• A use case is actually just a special case of classi ers or a stereotype of

classi ers.

• A classi er in UML is a class-like thing. It can be instantiated, and it is

generalisable.

• You can denote a use case using the standard rectangle notation for classi ers with an ellipse icon in the
upper right-hand corner of the rectangle with optional separate list compartments for its contents.

Video Transcripts:

The network aspects use case is represented here in a more descriptive form, less diagrammatic, but
more descriptive with text representing di erent details of that. Like classes then because we are now
treating use cases like class like things. They are generalizable. There will be ows. Instead of calling them
methods, we call them ows, and they can be either concrete or abstract. Concrete when we give the
steps also in the ow. Otherwise, we just name it and that what is expressed in the name itself, then it is
an abstract. But the detailing the concretization, that will be in a sub ow or something that is now at a
lower level of detail. That we can call a child use case. Here is the top level, use case for moving
shape. The aspect is moving shape, and it cuts across the UI, which is, again, the user's own role
there, the player's role, the board and the piece, which are now network together. They are all having equal
importance in this system. It is not a master slave system. It is a special case of classi ers, and that's why
we are showing it in this way. We have both the ellipse that tells us that it is a use case, but then the
rectangular form and then the name at the top, which is the abstract, what representation and the details
at the bottom. They are like members and methods, but they are not exactly members and methods
here. Their role in representation here is like that. That's why this notation is introduced. This actually tells
us how to go from use cases to aspect oriented programming because you can see that those
slots, which we're also having the tags of board and UI and shape. Here they are represented by again,
the shape. The piece is shape, board is board, and UI is engine. The user is represented by the engine
because engine is the one that actually does the interaction. This is the way we can go from use cases to
ff
fl
fl
fi
fi
fi
fi
fi
fi
ff
fl
fi
fl
fi
fl
fi
ff
fi
fl
fi
fl
ff
fl
fi
fl
fl
fi
fl
fi
 aspect oriented programming. In summary, we saw the use case technique. It is already a common
widespread technique, and it is adaptable. They are units of functionality that the system provides to its
actors. Now, we are looking at aspects which go across actors. This use space speci cation will contain
di erent ows. Verifying that the ows, the use cases captured all the stakeholder concerns, especially the
cross cutting concerns, is done by walking through the ows with the stakeholders. I showed visualizable
diagram as well as something that was textual and more detailed, which can be easily concretized
with again more detail, lower level. These are small enhancements we do to UML to help us capture
aspects and represent them accurately and timely such that we can get stakeholders on board with that
representation. We cannot show code to the stakeholders, but we can show them use case diagrams.

Use-Cases to AOP

The Original (Bad) Design

• A tetromino is instantiated by the board in a method.

• The engine doesn't know or participate.

• The engine controls the board.

• The board controls the falling piece until it is falling.

Why it was Bad?

• Cross-cutting concerns not considered as such.

• Modularity is hampered as a result.

Solution

• Cross-cutting concerns to be considered as such: as Aspects.

• Modularity achieved by moving the concerns from all the entangled classes into the Aspects.

Video Transcript:
The original bad design that we already have seen, I'm just helping you recall, a tetromino is instantiated
by the board in a method so it is neither a member, of course, it cannot be because each instance will be a
new tetromino coming in so it cannot be a member. You cannot have an unlimited number of
members, and you can also have it in an array. It has to be an instance in a method. Then the engine
doesn't know or it doesn't even participate in this instantiation and the action of falling that piece. The
engine controls the board. That means the engine will tell the board what to do, what not to do, and so on
the events, the triggers coming from the player with the mouse, with the keyboard, and all. The board will
control the falling piece because when, for example, the player will try to move the piece left, right, or tries
to rotate, then the board gets that event signal from the engine and the board sends the same to the
falling piece. The falling piece is not a member. Remember, it's an instance in a method and this has to
happen only until the piece is falling. Again, the board only knows when the piece stops falling because it
has hit the bottom somewhere and it will rest there. This is all the complication. Why this design is bad, of
ff
fl
fl
fl
fi
 course, the cross-cutting concerns are not considered as cross-cutting concerns or as aspects. The
modularity is obviously hampered as a result, and we already have seen why cross-cutting concerns are
bigger concerns. The solution here, they have to be considered explicitly as aspects, and the modularity is
achieved by moving the concerns from all the entangled classes into the aspects. That is our solution.

Aspect-Oriented Design

• The particular devices (aspects) used are (underlined in

blue):
• Observers
• pointcut
• changes
• call
• after

• updateObserver can do collision checks too.

Video Transcript:
Let us look at it. Here is the design. The particular devices that are used here, this is from Aspect J, but
there are other frameworks with Java or other than Java as well. We can have even bindings which
are taken from the aspect J into C++ as well because ultimately the aspect-oriented programming is
something like a set of advice, which will be pre-processed into, again, the native code, either Java or C+
+, whatever your target language. Here, what we are looking at is a high-level design advice or design
speci cations in a say. Remember, what we are doing now is pre-programming or pre-coding, before we
go to the implementation details. In fact, before we go to more detailed low-level design, we are looking at
what may trouble us later in the implementation so we are putting it at a higher level at the outset, and this
maybe even a requirement stage. Now we express it in almost our daily language of transactions in which
one project leader can tell the subordinates that this is what you have to take care of. These are the
concerns you have to take care of today. This is how we express it aspect, and then we name it. What is
the name? Piece Observing. There is something called a concern that everyone is involved in engine
board and piece and the ideas of observing the piece. It creates observers and it creates pointcut, so you
can see line number nine is a pointcut, and the point cut is related to changes. The pointcut declares
that the concern is now whenever the piece P changes. What is the concern about? The target is P that
means the particular instance, and for each instance, wherever there is a call to the setter methods
because that will change the piece, then the move methods, any of them, and rotate methods. Which will
change again the piece. For all of them, there will be an advice after. What it will do, it will update the
observers and this will help us, for example, check collisions in the board and this is done with both the
piece and the board together. They are peers. They are working together. They are communicating with
each other through this aspect advice.

The Beginning of an Service Oriented Architecture

What's di erent about SOA?

The Chronology

A Common SOA Template

The Service Endpoint Interface

• @WebService
• @SOAPBinding (style = Style. DOCUMENT)
• The Interface Body:
• @WebMe thod String get<interfacename>AsString(String name)

Video Transcript:
So the beginning of an SOA will be a common SOA template. That is, we have to choose a template
and we have to now start thinking of a web service. It can be either a document-based approach or it can
be remote procedure called RPC approach. In both the cases, what we are looking at will be a network
of di erent hosts and each host having di erent processes. Each process connecting with processes
ff
fi
ff
ff
 either on the same host or the other hosts on the network via di erent protocols. Even when they are
connecting to processes on the same host, they are connecting via the same networking protocols. As if
they are di erent independent processes happening at two di erent locations or on two di erent hosts. So
that is the lead motive. Now the web service will have a binding, right? So this is a particular framework
available with Java implementations. So there will be a binding and the style of that binding will be either
document or RPC style. So that only changes with the two approaches. The di erence in the two
approaches is with the kinds of services and the kinds of guarantees with those services. Basically
transactions, or just we can say document level exchanges. So a transaction, for example in a bank
account for example, that is not a document, but we create a document at the end of the transaction, and
each step in the transaction is an atomic step. But at the same time the whole transaction is accepted or
rejected and then it may be recorded, but at the same time it is not a ected depending upon whether all
the steps go through. Whereas a document style will be looking at di erent units as old documents, which
are themselves indivisible, they are not like transactions, that will be the di erence. So document
exchanges are not like procedures. There are more or less like mail, right? Paper mail, so we bundle them
up, put in envelope, seal them and then given address and send. Whereas transactions are like a bank
counter that's the main, we can say analogy.
And then there will be the interface body. Interface are basically those Java concept of interfaces, which is
also called as abstract classes in other object oriented or object oriented and functional programming
languages and so on. There may be di erent terminologies, but the main point here is that it's a class that
doesn't instantiate anything, but it encapsulates certain operations. Because we are dealing with
transactions or exchanges services on the web, which are basically exchanging either strings, data or
whole documents units. So there will be an interface name and then it, you have to provide a method that
converts that into a string. Typically that string will become HTML document. It will become an HTML
document produced as a result of the user interaction. But we will typically treat it like a string because
what goes on the net actually, or what comes as a response from the server, both will be HTML
documents which are coming like a stream, like a single string.

The Publisher Endpoint Interface

• Endpoint. publish ("http://localh

ost: 7779/ws/hello", new
<InterfaceImpl>()) ;

• wsgen …<InterfaceImpl>

Video Transcript:
So we will have such an interface and it will have methods which handle string transactions. The strings
are complex. So this is like having a wire. And on the wire you are sending a current, a string is a current
and you have a publisher which is like a plug socket in which you put your pin, okay? And this will have
some kind of registry. Basically when you show a plug pin anywhere on a wall, you are saying that you are
o ering power there. You have to specify where is the source of that power, what kind of a power it is. Is it
110 volts or is it 230 volts? Because if you plug in a di erent pin that is connected to an instrument that
doesn't take 230 volts but takes 110 volts, then of course it will blow up. So you have to have some kind
of registration, some kind of identi cation, some kind of interoperability compatibility speci cations with
the publication of it. That is when you are showing it up as a public utility, you have to give all these
things. So that is the publisher interface. And then you have to generate the web service using all these
things together. All the interface implementations are brought together using the web service
generation. The particular code snippets that I have shown are related to the Java web services
framework, j a x, jax. But the implementation or the templates will be similar with some di erent
nomenclature. For Python for example, and others, we will take such examples in the actual practical
auditorial contact sessions. But here I am just giving a gentle introduction. Each of these services,
whenever we are organizing, will need a lot of top-level design, architectural design of this kind.
ff
ff
fi
ff
ff
ff
ff
ff
ff
ff
ff
ff
ff
fi
 All Together

Video Transcript:
For example, when we put it all together, there will
be a client, there will be server, and there will be
some kind of registry, some registrar which helps
us establish the contract between the client and
server. And the publisher will make it available to
the client even if the server doesn't know that the
client is seeking it. So what is more important is
that the servers contract o er has to be available
to clients without them also knowing the server's
particular address. So what is published, the what
part of it, what is the service that is being
o ered. And of course, there has to be a standardization of that, because when the client is trying to nd a
server for a particular service, the service itself has to be standardized. All servers should be o ering that
service in the same interface, the same, we can say face okay? Otherwise, how will the client
recognize? For example, if somebody o ers a search engine but calls it something else, like nding
service, they call it, then is it nding an app or it is like a Google search engine. So there has to be
standard nomenclature also there. That's why we need a registry and publisher. So this is all it. But then of
course there can be more complex architectures. There can be intermediaries also, which will make the
particular servers idiosyncrasies or details oblivious. And the client will see again some standardized
interface or maybe handling internationalization. The server is o ering the services in an interface that is in
a particular language, human language. And then what the client is seeking may be o ered again through
some kind of a translation interface. So there can be more network nodes and more intermediaries
here. But overall the architecture is like this. So in summary, this service-oriented architecture will need
registrars, registry registration for that registration to happen and also for the clients to be able to
connect. Discovery and request response protocols have to be there, and there will be polling, waiting or
waking servers and clients that can handle sessions. When you connect to say Google search
engine, what you get as an output, you should be able to see it even after Google itself has sent the
response and forgotten about your client. So both of them have to be there with some kind of retention
sustenance.
ff
ff
fi
ff
ff
ff
fi
ff
fi
Week-7

Let's Design

Characteristics

• Making of and use of tools

• Producing any tool or using a tool to produce any form of an artefact is an act that implicitly incorporates
some kind of design activity
• Additionally, design activity involves communication - translating a "design" into a "product"; designer's
ideas to the development team
• Communication plays another di erent and vital role in design.
• Experience and expertise is transferred from "expert" to "novice".
• Shared among community of experts.

Video Transcript:
In this whole process, there is certain activity which we call as design activity that takes place. Many a
times, this design activity is implicit. You probably do not call anything as an explicit design phase, but you
go through that process. That process really brings out the artifact, ultimately to produce something that is
useful. Additionally, this design activity really involves communication. Now, in our context, we use
communication a bit di erently than in general how we understand communication. Communication is
about translating a design into a product, wherein a designer communicates the ideas to the development
team. Through this mechanism, such a design, such a communication, such a designer's method of
design to product and ultimately, that product being used as a base ultimately to build something more
forms that whole chain of evolution, which ultimately has communication at its foundation. Thus,
communication really plays a vital role in the world of design. How does it do that? Variety of
mechanisms. Like we see, system models are built, sketches. Certain things which are imaginary are
put into visualization through block diagrams, pictures, photographs, ways of demonstrating something as
an analogy. All of this really forms part of the communication. As this happens, the experience of design or
the expertise built through this process is really transferred from an expert to a Novice. The Novice starts
building his or her own expertise while the expert becomes more and more expert. Shared community of
all these edit. A such information models, artifacts as design documents, or any mechanism of a physical
way in which such a design is actually communicated from one to the other actually has formed
community of experts, community of designers. Such an exchange of information ultimately leads to its
growth because ideas multiply. Ideas multiply, experiences multiply, and expertise gets shared
for ultimately more and more expertise to be built. This forms a complete chain of events to make things
happen. Thus, in this video, we understood the meaning of design. We learned the design and
communication as a crucial part of the design activity itself, and the aspect of expert to Novice sharing of
experience and expertise has communication at its core.

Two Methods of Design

• In a "classical" form the problem-solving is about observing the characteristics of a phenomenon,

making measurements, building a theory and then seek to verify.
• For us, engineering is to create a thing - thus design to create to achieve a goal.
• Thing created by Engineering solves the problem.

Path of Science & Engineering

Video Transcript:

There are two paths that we can see, a science and

engineering path. The path of engineering and the path of
science, that is what we primarily look at. This diagram
clearly depicts what we are really wanting to talk about.
The path of science, which is about study, study things
classically. All the areas of astronomy, biology, chemistry,
physics, all the phenomenons that you look at, you observe,
measure, experiment, and ultimately you're going to be better
at understanding it.
ff
ff
 The path of engineering is about making new things. Pyramids, ships, cars, telephones,
smartphones, superior applications on smartphones. All this is about constructing something, doing
something, then evaluating, and then ultimately you get to tools. And maybe based on that, you really
again observe what is going on while you build it, or after you have built it. And then you get to your path
of science where you want to observe it further and make it better. But really, these are two separate
paths. Attitudes and approaches taken need to be understood for one, to be a better designer two, to
make sure that while you become a better designer, you don't only repeat things, but you also look at
what phenomenon, what is the kind of observation, what are the kind of measurements to make it better
and evolve.

Scienti c Method

• For a "classical" or "Scienti c" approach to problem-solving, expectation is to converge to a solution -

scienti c method reduces the problem at every step to lead to a simpler and thus to a solution.
• If this fails, one can try a di erent method.
• Say a problem that deals with motion in 3 coordinate system can be ultimately solved by simplifying and
using scienti c equations.

Engineering Method

• Process of producing a design is much tedious

• Starts with Initial model on which designer makes the choices, and the consequence of this and further
choices makes it complicated to resolve
• Worst case scenario is that the design will turn out to be inadequate
• Real-time system may ultimately become inadequate to handle the events

Video Transcript:
Now, what's this engineering method?
Engineering is about creation. We create something that doesn't even exist.
If you look at the beginning of mankind, even agriculture did not exist. Today, the mankind, the human
beings who lived in a particular way, and today's living, there is a vast di erence. And one big thing that
stands between the human beings of the past and the human beings of today is tremendous amount of
engineering and engineering methodology to create new things.
Now, this process of producing a design is very tedious. It's tedious, time consuming, requires, hell, a lot
of patience. You're going to look at variety of knowledge areas that need to come together for you to solve
a problem. Primarily, you would nd that it starts with an initial model.
There is a model, designers make some choices. Each choice has a consequence, and then further
choices are made to get to a design. But by and large, as the design goes ahead, the design itself gets
complicated because things start getting added understanding simpli es it. But remember, our view is the
design itself gets complicated, but as we understand more, we nd it to be easy. It's like cycling.

While learning the bicycle, it appears to be a huge task, but as you practice, as you go through the
process and you master it, it becomes second nature. And if you start thinking from the physics of balance
equations, it further gets complicated. Of course, you can write equations to it, but it de nitely gets more
and more complicated.

So, for us, the design part, designers choices make things complicated, but ultimately, all of them have to
resolve to a version of creation. Now, at the end of this activity, you may nd that what we came up was
inadequate. Inadequate in such a manner that you got to either start again or you probably are going to
make it better by changing some parts of it again, going through the process of design. So, an example of
system inadequacy that we can get to is a real time system.

Real time system, you begin with something in terms of the number of events, kind of inputs that we are
going to get to the system. And then components that would make up the system, and you come up with
the system. But ultimately, as you go along, the entire process system may become inadequate if it is not
able to handle the number of events that happen to be more than what you really designed it for. That can
increase a lot of complexity. So engineering method has its own nuances, which one needs to really keep
in mind.
fi
fi
fi
ff
fi
fi
fi
fi
ff
fi
fi
 Wicked Problem

• Rarely convergent and potentially unstable

• No de nitive formulation is possible
• No stopping rule, so choose the "best" one at one point in time
• Iteration, a process method - at times can be expensive
• No speci c ultimate solution

Video Transcript:
Now, all of this points us to software development, software
design, and the entire process of coming up with software. We call
it a wicked problem. Why a wicked problem? Let's look at
characteristics of a wicked problem. A wicked problem is rarely
convergent and potentially unstable. So it's not going to be the scienti c mode and potentially unstable
like the engineering. You got to keep on trying, keep on getting to building things.

To begin with, there is no de nitive formulation that is possible. As you gain experience, expertise, release
after release. Yes, you get better at it, which I think today mankind is better at it, but inherently there is no
de nitive formulation. And again, just to remind you, I'm looking at it from software perspective. And you
can't really stop and say that, now I've arrived at the ultimate solution, so there is no stopping rule. So you
make choices. At that point in time, you pick the best and you move on. You move into an iterative
methodology, but iterative at times comes with its own cost. Iterations are expensive. I wish we were able
to start with something and end with what we wanted to get to, but we go through iterations in fact, one
can look at that. We have designed our process to be iterative, to be more predictable, but remember, it is
expensive when you compare it to a straightforward process that we start and we nish.
And ultimately, for any software, small, medium, large, complex, complicated, there is no speci c ultimate
one solution. There are many. And when you look at such a phenomenon of software design, with many
solutions available, choices and design decision really decide the destiny of that particular software.

Process of Design

• Postulate a solution
• Create and build a model of the solution
• Evaluate the model against the original requirements
• Elaborate the model to produce a detailed description of the design speci cations

• As design progresses,unforeseen di culties crop up or better alternatives are required; at times the
entire pattern may change so much that a designer is back to square one!

Video Transcript:
What is this process of design? It starts with, want to create something, want to build something, want to
build a X, or want to build a compiler, or want to build a contacts application for a mobile phone, or would
like to solve a problem. What does one do? Postulate a solution? That's the rst step. Then create
and build a model of the solution, work at it. Look at what the postulation gets you to, create and build this
solution. It could be built on paper or it could be a prototype. Now, this solution is then evaluated against
the original requirements. If it's X, you built it with iron and a piece of wood. Ultimately, does it really cut
wood? Are you able to slice the logs of wood? Beyond that, when this needs to be built really, built for
maybe usage of another person or to be mass produced. Whatever the case may be, one needs to
elaborate the model to produce a detailed description of the design and design speci cations, which will
ultimately really get you to that version of design, which when used to build, there is a usable product. No
one can see that as design progresses, unforeseen di culties crop up, or better alternatives are
required. At times, the entire pattern may change so much that a designer is back to square one. This
happens. Hence, this is the toughest part from an engineering perspective. Today, when you start looking
at software and take pieces from here and there and probably use what is available. Are you really in a
compilation process, or are you in a design process? That's one question to always ask yourself. If you're
compiling things together, the probability that it will work, not because of your contribution, your
contribution is just putting it together, but they're working things which are put together, then it's a easy
predictable way that it will work. Or it will actually work for certain use cases, and maybe we have to be
debugged, or certain smaller design needs to be done to satisfy the remaining use cases. This is the
process of design that a designer would follow.
fi
fi
fi
fi
ffi
ffi
fi
fi
fi
fi
fi
fi
 Designer's Strategies

• Use of knowledge gained from scienti c research

• Apply scienti c knowledge, experiences and expertise from
other disciplines
• Reuse - standardising components
• Real-time system may ultimately become inadequate to handle
the events
• Communication

Video Transcript:
What are the strategies that a designer would put to use to make
things happen? If you really see it's really a culmination of there
are requirements speci cation. Yes, we need a product, we need
a software application to do something. Then we look at
constraints. Constraints could be it needs to work on a mobile
phone, or it needs to work on a computer. It could be of the
environment. It could be of the user that it needs to have certain accessibility functions. It is going to be
used by di erently-abled people. And then inputs are the design knowledge, which ultimately will get you
to the design. So where is all these strategies coming from, if you have to list them? It's use of
knowledge. This comes in from gained from scienti c research, prior experiences, or consulting
experts. You draw on those energies related to the knowledge that one could gain. Now, apply this
scienti c knowledge, experiences, and expertise. From software as a discipline, and even from other
disciplines to put something together. In fact, you would start using components which are already
available. We call it reuse, which are really standardized components from prior experiences, and done by
the experts. All of this ultimately needs to get to communication. You've got to have designers strategies
lined up, solution created, and ultimately communicated. We've already looked at what communication
means in our context.

Design as a Problem-Solving Process

• Produce a solution to a problem

• Evaluate options and make choices/decisions
• Use tools, design methods and patterns
• Representation - building models and evaluations
• Abstraction - use critical features in our models from large systems; and build a logical model

Video Transcript:
For us, design becomes a problem-solving process. Idea is produce a solution to a problem. For this, one
would always look at options and then make the choices and make those decisions. While doing so, there
is tools which are used, certain design methodologies are used and patterns are used. Now if you relate
these three steps that we spoke about software, we'll de nitely look at making decisions as to how the UI
is going to be. What is the rst release, and how is it de ned from a functionality perspective? We would
use tools. We would use a computer, development environments. We'll start using design methods and
certain patterns which are already available to get to the nal goal. We start looking at
representations, building models, and evaluations. Model and its evaluation ultimately represents a set
that works for a particular purpose. What we do out of all this is abstraction. Use critical features in our
models. We use this from larger systems or systems at large where experience is available, and we
ultimately build a logical model. We can abstract it, and ultimately that abstraction becomes useful as a
design method or a pattern. Design ultimately is a problem-solving process.

Decades in a Page!

• Building binary to execute to today's software

• Expressed in higher level languages - primary motivation iS for faster delivery and maintenance
• Design - Architectural style born out of the need to get things done "faster" and to build predictable
implementations
• Quest for software and its design to stand independent of other things!
fi
ff
fi
fi
fi
fi
fi
fi
fi
fi
Properties of Software

• Complexity - No two parts are alike, many states during execution - designer drives the complexity.
• Conformity Needs to be "inline" with other components like hardware and other software.
• Changeability - (Almost) su ers constant need for change; perceived ease of making changes and poor
techniques.
• Invisibility - It is "invisible" (lacks a visual link). Hinders communication!

Video Transcript:
But let's also look at properties of software. Software has also been that very di erent kind of engineering
aspect, especially to software. Brooks summarizes this in his book very aptly with four properties that
we're going to look at right now. Complexity, no two parts are alike, and there are many states to
execution. That is how software can be looked at. Too many things can be done. Who drives this
complexity? The designer drives the complexity. Then there is conformity, needs to be in line with other
components like hardware and other software. If you're using a library, you've got to fall in line and
align with usage of that library. Or if it is to work on a particular hardware, you've got to make sure that
software actually is able to work on that hardware platform. The next is changeability, where software
almost su ers a constant need for change. Perception is that it's so easy to build software, it's easy to
change it. Oh, it's just a matter of changing few lines. There is a perceived ease of making changes. Of
course, making changes and what those changes mean then take us in the area of are we doing it
right? The techniques to make a change, which will not impact, are not easily understandable. The
techniques become poor. Changes techniques are poor. You can design it for extensibility, but then make
that change and make sure that the earlier piece runs while your extended piece also runs is not easy. The
last one is invisibility. Software is invisible, software and the electrical current that ows, two invisible
things. Since this invisibility as a property comes up, for a human mind, there is no visual to look at, and
this has hindered communication many times. Those notations, diagrams exist, but it is still di cult. The
reality on the ground is it's not easy to communicate design, especially for it to be implemented directly by
a engineering team or a software development team.

High-Level Design

What is High Level Design

• Architecture: Boxes, Arrows & Interfaces

• Arrows/Interfaces depict communication
• Architecture is recursive:
• One designer's system is another designer's component
• HLD = Architecture (nouns) + Requirements (verbs):
• Sequence Diagrams
• Static/Dynamic views

Video Transcript:
In our example, it's the device D1 which actually senses one
of the environmental parameters, processes it, and is able to
send that data to the gateway. Thus, we have got this as a
box, a complete box with its own functionality.

Each of these arrows, as they depict interface, they also would depict communication. So if it is only one
system, one physical computer, then it would be across only software modules. However, if it is a IoT
system, you would typically have physically separate device and a gateway are really separate, and each
of them will have a method of communication, either wired or wireless. Within the gateway itself, you may
have further sub components, so you will have within the server or the device. Thus, architecture or the
HLD itself can be recursive. That is, the designer of device and gateway would talk about the architecture
for device and gateway respectively. As a architect of the entire IoT system, one would talk about
architecture of the IoT system. But each of these architectures are feeding into each other. That is, device
and gateway feeds into the architecture of the IoT system. Thus, one can say one designer's system is
another designer's component. Thus an HLD really would be made up of boxes, which are nouns and
requirements, which are verbs. The action words. These are the words that really give a meaning and an
action to each of the boxes. So what do we see here? We see a static view, that is device connected to
ff
ff
ff
fl
ffi
 gateway, to the server and to the database. Or a dynamic view, we would want to show how the data is
going back and forth, and that is done using the sequence diagrams. So let's dig into it a little deeper.

Let's take an example. Here we have a entire IoT system, and let's consider that this entire system is
installed in a data center. So this is at a data center, and the d one is actually collecting data pertaining to
the temperature. D2 is the humidity. Both these devices are going to collect these parameters through
sensors, process them in their respective boxes, and actually transmit that to the gateway. At the gateway,
both these would typically be uni ed d one data and d two. These would be put together and sent across
to the server over the interface, which then is further processed to be stored into the database.

You can see that the data travels from the entire environment in the data center to a database which
probably is going to be located at another physical location. Thus each box has its functionality and it
does a job and you can see that all of these boxes work together to form a particular use case of
collecting temperature and humidity for the data center. Now let's look at the dynamic view. There is
certain data that moves from one box to the other box, one component to the other component. So here
we have the device that sends the data, there is data that is sent and the gateway actually provides an
acknowledgement. Similarly, once the data is successfully received at the gateway, the data will be further
transmitted to the server, which is again acknowledged by the server server. Once the server receives the
data processes, it would then send the data to the database in its required form through a query
and ultimately would get an acknowledgement from the database. And we know that what is collected
from the device has ultimately gone into the database. This provides a dynamic view of the data. Each
levels at each of these we would see that transmission of data and its acknowledgement there is a
bidirectional communication happening. But this dynamic view provides everything in action for our high
level design to be evaluated for certain use cases.

Characteristics of Good HLD

• Choice of components
• Component characteristics
• Component tment and development

Video Transcript:

Let's look at what are the characteristics of a good

HLD. A good HLD really depends on its components
and its arrangements. In fact, all the good
characteristics are derived from the best of the
characteristics of the components and their
interactions. You may choose the best components, but if
their interactions are not in line with the goal, then it doesn't
make sense. Then you will probably have a very bad
architecture, good components, and bad architecture, which
itself is a not great combination. We got to look at the
tment of components. Of course, these components could
be already available. That is, you're not going to build
them. You probably are going to buy them or license
them, as we call as build or buy. There may be certain
components which you will build. Those will be
built speci cally for the work or the goal at hand. Thus, our
characteristics of a good HLD will revolve around primarily
the components. Of course, when you look at the entire
architecture, which we can call a system architecture. It will
have its own attributes related to functionality, working,
reliability, and the coolness of it. A lot of abilities with respect to scalability, extendability, and
maintainability. However, it all boils down to what kind of components are being used within such a
HLD. Let's explore this a little bit. What we have is for a component, there are three things that happen to
be very important. One, the functional speci cation, what this component does, what does it do? What are
the typical things that it can accomplish? Or what it cannot do. Or probably there is an ambiguity. We
don't want ambiguities, but you may land up with some. Such a component will always have a component
interface. Ultimately, this is what connects with the rest of the world. Thus, we have a very clear functional
fi
fi
fi
fi
fi
 speci cation. A speci cation of dependencies. This component itself may depend on something. Maybe
there is another component that you would use, say C1 ultimately for this one component to work. There
could be a speci cation related to dependencies. It could be of another component. It could be of the
environment in which this works. So maybe there is an environment in which this works. Ultimately, you
make use of the component with the interface. There is going to be the interface. Really, when you see
from a coding perspective, from a development perspective, interface would be something. Those are the
methods that would be used to make use of the component, maybe initialize, transfer data, look for output
from the component. Thus, component is really a most important measure in HLD. Now, what do we have
here? We have an architecture of a system. We're going to call it a system, which is composed of, say
three components each. Here, we have component 1, 2, and 3. Each of these components provides
certain functionality, and that's the system functionality depicted over here.
As you can see that there is certain functionality over here, which is a overlap. Closely, if you see, there
is a overlap that component 1 and 2 has, it's not desirable when it comes to systems architecture. Can
you avoid it all the time? Probably not. You may have to make a choice of component 1 and 2 because it
brings you the rest of the pieces. This piece. This is what you're really looking for. Hence, you're okay to
get that overlap and make a decision as to what you would use from one and what you would use from
two when it comes to the functionality, which is a overlap. But it's not desirable. Well, you never
should have components like the component four, ve, and six. Here, where there is a missing
functionality. Now, this is de nitely going to cause an issue where there is no component addressing that
functionality. That does mean the software application is going to fall short of what it is going to be used
for. This de nitely is not desirable, and missing functionality should never ever happen. Redundant
functionality. This is one of the most interesting thing that happens. We land up collecting
components. Oh, let's bring this, let's bring this. But at the end of it, you end up having certain
functionality that never gets used. When this certain functionality is never used, you land up calling it
redundant functionality. Sometimes, it is not easy to get rid of it. The 789 components. They may or may
not have a overlap. They may be perfect components, but they come up with certain functionality that
ultimately is redundant. While you don't want this situation, this situation may arise, and then there are a
variety of things that one could do that you may look at 78 and nine to be refactored, or you may look at
some of the functionality that needs to be brought in in a combination of how really you would want to use
78 and nine together. The last one here is architectural mismatch. This is a pure complete mismatch where
component 10, 11, and 12 are completely mismatched. They're not even meant to form the software
application. Now, this is absolutely not desirable. However, in the larger scheme of things, when you start
looking at some of the functionality, this may happen for a system as a whole. Of course, it never happen
by design. Thus, when you look at the overall architecture diagram, which is made up of boxes and those
interfaces and arrows. This is what necessarily it means. Ultimately, we need all the boxes coming
together. Having the correct the appropriate interfaces, and actually such a system that every bit of it is
utilized. Now, there lies a pitfall that many a times generalization of something, you may have looked at
abstracting the functionality and trying to make it generalized, you land up getting some unwanted
functionality when you really want to put it to use. You got to become very speci c and customized, then
you end up having to develop all by yourself, accurately and exactly what you want.

Architectural Views

• "A view represents a partial aspect of a a software architecture that

shows speci c properties of a software system".
• The logical view: satisfying the functional requirements.
• The process view: concurrency issues.
• The physical view: distribution Issues.
• The development view: how the design is broken down into
implementation units with explicit representation of the dependencies
among the units.

Video Transcript:

The four views that we look at are logical view, process view, physical view, and a development view. The
logical view satis es the functional requirements of the software, the process view, the concurrency
issues, number of tasks, priority of tasks, how events are going to arrive at the system. In what order they
would be processed, all that would be process view. Physical view, how are these components
distributed, how are they connected? Development view, how is this design broken down into
implementation units with explicit representation of the dependencies among the units. So you split them
fi
fi
fi
fi
fi
fi
fi
fi
fi
out, each can be implemented separately, but you also bring in representation of dependencies so that
when you put them together it all makes sense.
Architectural views are a brilliant way of communication. One is you document it well. It actually
communicates the entire architecture so brilliantly and so easily that the implementation team or a
construction team or a development team can just take it up.

Architectural Design Decisions

• Architectural Design is a Creative Process

• Numerous fundamental decisions are required to be taken
• Software
• Development Process
• Impact on Quality Attributes and Tradeo
• Document the decisions along with the details
• Document the reason for the choice and ascertain the impact.

Video transcript:
So we have called them as architectural design decisions. The ADD, overall architecture is a very creative
process.
We have seen numerous steps of creation while doing this when creating, you got to take decisions,
decisions from a software angle, from the development process angle. What needs to be there, what
needs to be removed, what needs to be brought in new? Is the process okay or not? A lot of these
decisions happen to be taken.
Each decision so taken impacts one thing or the other.
You may remove the excess, but this excess that you remove may be appropriate for the current
release. But maybe to get to the next release as per the next release, to get to the roadmap, we may have
to include that in our development cycle in the next iteration.
There are numerous such examples where your decisions need to be really accurate and appropriate.
While we say decisions need to be accurate and appropriate, there would be wrong decisions or there
would be those half baked decisions which probably do not help you completely. And you do not get to
know them till the time sometimes construction happens and you actually test it, but you land up taking
those trade o s no matter what.
The key is to document the decisions along with the details and all the supporting data, all the supporting
information and probably domain knowledge that allows to justify that decision. And if we need to trace
back or backtrack, we are able to do so. Design decisions will happen at all time. And as you can see, you
can't really include everything, you can't really exclude the crucial, but you've got to just pick the
appropriate one.

User Interface Design

• UI Design Principles
• Learnability
• User familiarity
• Consistency
• Minimal Surprise
• Recoverability
• User Guidance
• User Diversity
• Information Presentation
• Navigation and Flow

Video Transcript:
As we move ahead, one of the key areas in today's world especially is UI design. In fact, design has
become so synonymous to user interface and user experience that whenever someone says design, it is
assumed that it is going to be UI to begin with. In fact, there are many times in conversations I have
noticed that people talk of design and software design, where design necessarily means UI design. For us,
design has been a generic word which separates into software design and interface design. Each of the UI
if we look at the classic two diagrams that we have over here, pictures that we have, we have amazing
systems that really have been built to depict. One is the windowing system, you have these overlapping
windows that come into play.
ff
ff
 They give a lot of exibility to how a functionality can be achieved to such an extent that you can actually
move objects from one window to the other.

You can actually right click on this and get a menu which can do certain things to that particular entity or
object on the screen. Overlaps overlaps between screen one, screen two and screen three. Rather window
one, window two and window three. You can pick which one appears on the top or where there is focus.

While all this is being shown, you could necessarily even get a noti cation over here which comes in and
pops up and shows something during the operation. A lot has happened from the earlier computer
systems and UI systems to what we see today. Hence, UI design principles need to be employed, which
are learnability, user familiarity, consistency, provide minimal surprise. There needs to be a pattern and
when you start looking at such a system, especially when it has a windowing logic. You would nd that it
is very easy for a user who is used to the windowing system to ultimately use the application for his or her
own nal goal.

All of our UI as it needs to provide minimal surprise but maybe there is a noti cation that comes in
surprisingly, and we would want the user to easily recover.

Keyboard has the escape key, but probably there is another mechanism to escape from these
things. Thus, all our system inherently provide guidance to the user as the navigation comes through and
the user learns, you would have seen in your own methods of using the application. You start using the
application and in about few minutes you kind of master the application and using it. Last ut a very
important topic, in fact it would deserve a subject of its own, is user diversitby. We would want to design
our applications software, which essentially runs on a lot of hardware and systems, to be accessible. We
will always have di erently abled people use our system and many a times you would want our systems to
be welcoming di erently abled users. Those who are visually impaired, hearing impaired, you will de nitely
want to design for them. Thus, taking care of user diversity is very very very important.

While we say this, we have not really treated diversity as one of our topics when we are looking at design.

While UI design or a speci c application for a speci c purpose, when you get to it, it is important for
taking care of user diversity.

Finally, we want to de nitely look at the information presentation. We start looking at how the entire
information gets presented along with the navigation and ow to get to something, start to nish, addition
of a contact into the phone book or deletion of a contact. Or adding some attribute or a characteristic to
that particular record. Maybe I'm adding a picture, maybe I add or change the email address of the
person. Maybe I update the phone number or I add another phone number. I have the work phone, now I
add the home phone number. A lot of these become navigation ows for us to nish a particular
activity. And that forms a very, very crucial aspect of the navigation and ow, which is to do with user
interface, and ultimately that leads to user experience.

You would also see that there are primarily three areas that one would look at, which is a human using the
hardware and the software. All of this primarily is going to interface with each other back and forth to get
the job done.

This getting the job done is based on the senses, classically the sensory organs, and of course the
brain. Hardware will start looking at its own input and output in terms of input mechanism, using a
keyboard or mouse.

And you will see that a lot of this works together to make things happen.

On top of this, you have the software that works together, and ultimately the entire system works together
to make a use case happen or bring a use case to reality.

While we looked at user diversity as a subject in itself, user interface design and user experience is also a
subject in itself.
fi
ff
fl
ff
fi
fi
fi
fl
fl
fi
fl
fi
fi
fi
fi
fi
 Low-Level Design

What is Low Level Design

• Detailed design - Speci es the detailed description of all modules

or functional blocks within the components
• Audience is the development team
• Detailed design description
• Classes/Objects
• Algorithms
• Data structures
• Detailed ow
• Interfaces
• Structure and Behaviour

Video Transcript:
Low-level design is really a detailed design. It gets into further details, further depth of how the system
really is going to be implemented. In architecture, we look at walls. But here, we look at exactly what
bricks we are going to use, what type of material it would be, or is it going to be a brick and concrete
wall, or it is going to be a wall that is constructed using maybe wood. A lot of details happen to be done in
the low-level design. What necessarily does is speci es the detailed description of all modules or
functional blocks within the components. Now, we have a component and within that, we break it down
further. We get to those details which ultimately a development engineer can implement and be sure that
when all of it is put together, it will all work. Thus, it has to be consistent and completely in line with what is
expected when everything is put together. Primarily, the audience of the low-level design is the
development team. They are going to use it to develop it. Well, in today's world, you would actually have
maybe project managers. Maybe at times customers get involved in low-level design. However, the
primary user of the low-level design is the development team. They not only develop it, they use it, and in
fact, they probably are the only users of it. Other than that, there is a test team that might pick it, but I'm
including test and development engineers all within the development team. What does this low-level
design entail? It has a detailed description related to classes, objects, algorithms, data structures, detailed
ow, and interfaces. If you imagine, again, a contacts application, what classes and objects would it
have? How would updates happen? What kind of services would be provided? How would changes
propagate? We would use data structures of what nature? If I want to show a list of contacts, I would
de nitely have a list. A ow that would take the entire object from being created, from being updated to
actually stored in the le system or in the database. A lot of these things would happen using multiple
components or within one component but di erent functional blocks. As they get developed, you will also
nd that each one of them provide very clear interfaces. What we're seeing here is a detailed but
simple change propagation mechanism for an observer.

Changes from application data are actually updated to the observer. But you see this becomes the
detailed design where a lot of ultimate implementation details are being documented.
While objects, their speci cations are done in detail, at a certain level, one needs to also build a state
diagram. A simplistic state diagram is shown of a turnstile. Classic turnstile you nd at the airports or
metro stations, where a coin when it is inserted would actually move it from locked to unlocked. Once the
person passes by or the turnstile is operated, it would move to the locked state. But such systems will
de nitely need a detailed design, so you move from one state to the other, and while doing so, you do
not get locked up in one of those states. When it is locked, without inserting the coin, you may
push. When you push without inserting the coin, it needs to stay in the locked state. This is exactly how
you would want to make sure that the system operates. When it is in the unlocked state, inserting another
coin would also keep it in the unlocked state. State machines really need to be built out, and such
object, details and state machines will provide enough detailed information for the implementation team or
the development team.
fl
fi
fi
fi
fl
fi
fl
fi
fi
ff
fi
fi
Characteristics of Good LLD

• Choice of design strategy and methods:

• General Strategy
• Function-Oriented (Structured)
• Object-Oriented Design
• Data-Structure Centered Design
• Component-Based Design (CBD)

• Component characteristics:
• Detailed to translate to code
• Behavior details for implementation
• Details of scenarios
• Error handling

Video Transcript:
When it comes to good low level design, it really forms two main areas which need to be looked at in
detail. One is the choice of design strategy and methods. And the second, all that component that is built
using any of these design strategy and methods will ultimately give rise to certain characteristics of that
particular component. And ultimately such characteristics form the characteristics of the system, because
it is going to really contribute into the characteristics of the system. So let's look at it a bit more in detail.

So, design strategy and methods, these have been existing since decades. If you look at today, the most
popular one is object oriented design. And in fact, with a lot of focus on data and data manipulation.

With data as the center of the universe, a lot of software is being built today to compute, to manipulate, to
visualize. A lot happens around the data.

So object oriented and data are most popular. However, other strategies like the function oriented or the
structured component based design general strategy to come up with software. They still exist and are
used in many areas where probably the sizes of the software are small or large. So a general strategy
could de nitely get into software that is built for, for example, microwave ovens or software for certain
type of refrigerators or simple air conditioning control.

Thus, you would nd that each of these strategy and methods nd their way into low level design. When
you look at function oriented or structured design or structured strategy, it translates into typically a
language like c or c. Yes, you can do structured programming, even using c.

If you look at object oriented design, it might translate into say, Java or python. You build a component,
the entire component may be built using structured language or a structured design. And a combination of
object oriented design, so structured and functional can come together. And ultimately you would have the
component created. Structured and object oriented can come together so that the entire component can
be created.

This gives rise to certain characteristics.

What are the characteristics of a good LLD?

Ultimately, they lead to the component characteristics too.

A good LLD is detailed enough that it can just be translated into code. You get the LLD, give it to a
development engineer, typically a programmer who can get the low level design and create a program.

The LLD needs to specify the behavior of that particular component. What does that component or what
does that implementation do? What does the method ultimately take care of? Is it adding a contacts in an
application, or deleting or updating details of the scenarios, the entire scenario of that particular
application, maybe it is being executed on a mobile phone or the same is being executed on a personal
computer. So the scenarios would di er. So will the environment. At all times, we would want to make sure
that we build error handling in the entire low level design. Every bit of movement of control from point a to
point b, or one line to the other line. We want to make sure that error handling is taken care of for certain
scenarios.
fi
fi
ff
fi
 Let's look at it in a bit more detail in terms of the object orientedness of things. Here the class description
has encapsulated information. All the information that the object is going to store is all over here. This
information is accessed using an external interface or what we call as public methods. It will provide the
information and the state of the object. For example, if it is age of the dog or color of the dog, age
and color, which would never change, would be information. But state if this particular object represent a
turnstile, then is it open or is it closed, would be the state of the object any given point in time. Such an
object may use other methods, other methods or other objects to ultimately deliver the behavior. Hence,
you would see that a detailed speci cation like this will ultimately help the development engineer actually
write code.
Thus you have seen that detailedness of the LLD actually de nes its goodness, detailedness from strategy
and the method chosen, and also the characteristics to the level that you can go. That one has gured out
everything at the lowest possible level.

Characteristics of a Good LLD

• Details are the key ‘Devil/Angel lies in the detail"

• Choice of implementation and decisions - "Nuts and bolts”
• Implicit and Explicit requirements - “The unsaid and the assumed”
• Pay attention to internals - "The anatomy of components"
• How it works - "The exact function and working"

Video Transcript:
Let's look at characteristics of a good LLD, a very di erent angle to stating these characteristics. When
we say details, as detailed as you can be, because Devil or Angel lies in the detail, down to the
variable, down to the number of variables, down to the construct that is required, to such a level that at
times you want to specify if the code construct needs to be a ifels or a switch case. Got to be as detailed
as possible. Maybe that algorithm, maybe choice of algorithms is made based on certain characteristics
that you expect that make use of these two. Keep provision for these two so that we'll be able to make a
choice later, maybe at run time. Choice of implementations and decisions, exactly what language would
you use? What kind of constructs? Why this method versus another method? The classes, the choice of
classes, how would objects be organized? All these becomes part of a good low-level design. These are
the nuts and bolts that you need to put together. Most of the time, in a detailed design, all the
requirements are explicit. As one looks at a high-level design, details it out, comes to a low-level
design. All the unsaid needs to still be speci ed and it needs to become explicit. But that is from a LLD
point of view delivered by the HLD. But when it comes to LLD itself, the focus needs to be from
implementation perspective, which I believe that many a times, you would nd that explicitness may not
come in in the LLD, and it is demanded by the implementation and that is where implicit requirements
come into play, and those are driven by the language or the implementation. We want to make sure that
the unsaid and the assumed is all clari ed. Pay attention to internals, the anatomy of the
components, how things are organized, how things are going to interact with each other. Becomes very,
very crucial for the success of the component from a behavior perspective. Ultimately, we want the
component or the object and its methods to deliver the exact function. It's working is very, very crucial,
how it works. Not that it just delivers what it is supposed to be, but how is it exactly built makes the most
di erence. Because at times, you would nd the software methods, objects, classes, components that
deliver what is required, but they don't remain maintainable. They are not scalable. We're looking at the
internals to that level of detail.

Programming/Coding Decisions

• Programming/Coding is a Creative Process.

• Numerous fundamental decisions are required to be taken.
• Exact constructs
• Control ow
• Error handling
• Impact on Quality Attributes (maintainability, testability).
• Comments in the code and design description.

Video Transcript:
Ultimately, it comes down to programming or coding decisions. Programming or coding is a creative
process. During this creation, there are numerous fundamental decisions that need to be taken, exact
ff
fl
fi
fi
fi
fi
ff
fi
fi
fi
 code constructs, how the control ow will be organized, how you will have the conditions
stated, conditions in the if, or conditions in the els. What will be checked rst? What would be passed as a
parameter? What would be returned? The error handling, what happens when bounds are crossed? What
happens when an error occurs? How would the error travel? Should the error be shown to the
user? Should it be taken care of? Should the system make a decision based on that error? A variety of
things need to happen.

Impact on quality attributes. You code in certain manner and it impacts the quality attributes
like maintainability or testability. Spaghetti code may work. It will be functional. It may even be
reliable. However, is it maintainable? Is it testable? Ultimately, comments in the code and the design
description will also matter. When you want to take a re-look at that particular piece of code, that piece of
program, comments come to help. That becomes a part of good LLD. These are the decisions that one
needs to take while developing, using a good LLD and programming.

Levels, Phases & Best Practices

Levels & Phases of Design

• Goal is great software

• The Levels High & Low:
• Ensure consistency across both
• Toggle between both; one feeds into another

• Phases:
• User de ned
• As many as required

Video Transcript:
Great software is hard to build, and our goal is great software. What we have here is the HLD and the
LLD. High level design feeds into the low level design. For us, both these levels ultimately start moving
from a broad to a detailed de nition. But in reality, when you're actually developing it, what may be the
scenarios that one would go through? Let's explore those on this diagram. Primarily, HLD feeds into the
LLD. We use the HLD to work on the LLD. HLD itself can be divided into two phases, so this is phase 1
and phase 2. Maybe in some cases, you may divide it into multiple phases, wherever it serves the purpose
right. Even within LLD, you may have multiple phases, each of which will do certain activity in a certain
way. Now, HLD version 1 done delivered for a LLD version 1. One starts getting feedback when LLD
reviews what HLD has done, and probably there is a feedback that comes in in terms of how the LLD
needs to be structured. Or if you will, there is a bug in the HLD or some requirements is missed, or
something is not done properly, then there is a feedback that comes in. Thus, you would see that this
circle starts realizing create software. That's why this circle ultimately comes in, and this spiral builds the
quality of the software. Each of these levels, this level, and this level, start building higher quality reliable
software through phases. Use these phases as many as you want across HLD and LLD. Many a times,
you would also nd that over and above the HLD and the LLD, you may introduce a system architecture
phase where you build the entire system architecture. This complete system architecture really would
mean that there are large components which are part of that architecture, and ultimately, you would have
HLD and LLD per component within the part of that super architecture, if you will, which is the system
architecture. Thus it is going to be a hierarchy of all these components which come together to form the
ultimate system. The idea is that you use these levels and phases, tailor it to the need. In fact, many a
times, you've got to gure out how this tailoring would happen and this will also relate with the process
that you follow. Maybe it's an agile process or a
waterfall process. You follow any process, but you
would nd that levels and phases have to be correlated
and linked with everything that needs to work like a
well oiled machinery.

Software Process

Agile
Waterfall
V Model
fi
fi
fi
fi
fi
fl
fi
Video Transcript:
For us, we look at three representative process models. We are very well aware that we are not going to
discuss software processes in detail. However, these three representative processes will actually tell us a
lot more about how we can do with levels and phases while using these processes.

So let's look at the classic characteristics of each of these processes. First, one that we have is agile. In
the agile, we land up getting a incremental software every time. So we are going to have more number
of iterations called sprints in waterfall. Straight away we are going to get to start to nish, and our version
1 will be ready. While we look at V model, we start looking at the two classic arms which allow parallelism
of certain tasks. But ultimately allow us to have these two arms feed into each other from a feedback
perspective.

Three di erent characteristics that we see now when you look at levels and phases. So when you start
looking at levels and phases, each of these processes will have their own methods because the software
processes themselves are going to drive how levels and phases will be implemented within their
framework. For example, levels and phases do occur pretty linearly when it comes to requirements that
within requirements I may have phases or within implementation I may have phases.

In the V model, similar thing could happen that in one of the areas I still separate it out and within each of
these I may have levels over here. Similarly I would have levels over here. So this is phase 1234, this would
be level one, two, three. Now when it comes to the scrum methodology, we may de ne levels and phases
in a manner that each of them are brought out per sprint. So sprint number 1 and sprint number 2, actually
the software that I come in from version 0.1 to version 0.2, I build up. And while from version 0.1 to 0.2 it is
built up, each operate at a di erent level every time and each of these could be split into its own phases
as we go along into development. So my levels and phases could really mean a lot of exibility when I'm
looking at any of these software processes.

Thus three representative software development processes and you can utilize levels and phases in a
particular way. Important part is to tailor these. Key is to look at a feedback as you move into iterative
mode. Use phases within each of the main areas and main functions liberally use levels to go from higher
level to a lower level of detail. Levels provide you zooming in functionality. Phases provide you with a
mechanism to do it in piecemeal from one phase to the other. These two are really very strong when it
comes to processes, but they are not just processes, they are also what technical focus do you have in a
level in a phase. And it can build rich and richer software as you move from one phase to the other, from
one level to the other.

Levels, Phases & Knowledge Areas

• Knowledge areas bring their focus:

• V Requirements
• V Construction
• Testing
• Quality
• Engineering
• As the projects "unfolds" over a period of time, more is understood to get to a solid design.

Video transcript:
While we looked at processes, you can look at levels, phases and knowledge areas. Swebok talks about
the knowledge areas. The knowledge areas that we are talking about in the context of software design are
requirements, construction, testing, quality, engineering and of course at the center of this universe there
is the design knowledge area. Each of these other knowledge areas actually feed into design, and from
design a lot of details get fed into these areas while you look at design. As you start designing, you start
asking more questions related to requirements or start giving inputs for construction. The entire design
becomes useful for de ning what kind of testing would happen and ultimately would reach to quality goals
or not with respect to performance and behavior.
The engineering, the way certain things are engineered, form an input into all of the knowledge
areas. While you can really draw a graph which is crisscross connecting all of these knowledge areas with
design at the center you would nd that the other knowledge areas feed into it. And as the project unfolds
over a period of time, it could be in waterfall, in agile, that is scrum, or maybe in the v model a lot of things
ff
fi
ff
fi
fi
fi
fl
unfold and as more and more is understood in terms of details, you would nd that the design becomes
more and more solid. Ultimately, one knowledge area feeds into the other.

Generic Best Practices

• Look for opportunities to simplify

• Work on as much detail as possible
• Break it down to workable pieces
• Each programming language has its best practices - use them
• Explore, experiment, seek feedback, and use that in next iteration

Video Transcript:
In fact, some of these best practices are by and large approaches and attitudes. The rst one talks of look
for opportunities to simplify. Simpli cation is very important, and constantly need to look for it. Is this
complicated? Is this large? Can I break it down further? Work on as much detail as possible. Get to the
detailed level. Don't leave it at a higher level box than code. Maybe get it down to speci cs, especially
where they matter in algorithms, in certain code constructs, in certain data structures that are chosen, in
certain methods that are chosen, that detail is important because the purpose is known to the
architects, known to the system designers, more than the people who have written those generic best
practices. It's about applying those. Break it down into workable pieces. A large piece broken down into
many manageable and distributable. If it's a team of four, maybe you start building those eight pieces one
at a time, complete the four, and then build the other four for all eight to come together, but make those as
workable pieces. Remember, there is going to be interdependence too. Maybe there is a sequence to the
whole thing, and levels and phases will help us do that. Each programming language has its best
practices. All those experiences of the past years have come in in those best practices and at least at a
code level, programming level, one should always draw on all those best practices. Finally, explore
experiment, seek feedback, and use all of that in the next iteration. All of this becomes possible when you
use the software process levels and phases, methodically, systematically in such a way that all of it helps
the design portion of it, and in fact, as you work in a variety of knowledge areas, various knowledge areas
from a process angle, from creating angle, these best practices and the approaches to best
practices indeed will help you. The ve bullets on the screen currently that we have are applicable
practically to each of the knowledge area more so for the design.
fi
fi
fi
fi
fi
Week-8

Mud to Structure - Category

• Patterns in this category help you avoid a “sea" of components or objects.

• Support controlled decomposition.
• More than just a working system - portability, maintainability, understandability and more.

Video Transcript:
So what is this Mud to Structure? And where does this Mud to Structure terminology come from? Primarily
as requirements were gathered from customers at the beginning of the project. All of that appeared to be
narratives, answers to some questions, some answered, some unanswered, some that needed to be
explored. So it apparently became a sea of variety of requirements, which led to thinking in terms of
objects, a sea of components and objects. How do you really organize them? How do you really make
them work together? So this led to what is called as controlled decomposition. And Mud to Structure
allows that controlled decomposition. So you get to certain architecture patterns which allow you to
organize these components, ultimately from unstructured to really structured form. While we do this, more
than just a working system, we were also looking at portability, maintainability, understandability, and
many more such abilities.

Mud to Structure - Architectural Patterns

• Layers - It helps It to structure applications that can be decomposed into groups of subtasks; subtasks
at a particular level of abstraction.
• Pipes and Filters - It provides structure for systems to process stream of data.
• Blackboard - It is useful for problems with no deterministic solution (Come from Al).

Video Transcript:
So let's explore further in the Mud to Structure area. Primarily, there are three patterns which exist in this
category. Layers, pipes and lters, and blackboard. The layers architecture helps to structure
applications that can be decomposed into groups of sub tasks and subtasks at a particular level of
abstraction. And these layers happen to be really horizontally imagined. And each of them perform a
particular task or a sub task. Pipes and lters provides a structure where there is a stream of data, data
that comes in, it needs to be acted upon. And as it is acted upon, it gets transformed into another form
and then is an input to another block which processes it further. So these are all lters and they are
interconnected with pipes. That is how it can be imagined. Blackboard, right from Mud to Structure, there
was an imagination of blackboard. Useful for problems with no deterministic solution. So you really landed
up arranging things in such a way that the problem would be solved. You landed up getting a
pattern. However, you started o with no deterministic solution. In the early days, this really came in from
the world of AI then. Even today, one can imagine as to is this really the pattern that we are looking at
when it comes to AI?

Mud to Structure Layered Pattern

• Context: A large system requires decomposition.

• Problem: A typical patterns requires communication across levels-
request<>answers from high<>low level.
• Solution: Build the systems with layers.

Video Transcript:
So let's take a high level look at the layered pattern. And we look at context, problem and solution as our
trio to describe the architecture pattern. Context is a large system requires decomposition. And what's the
problem that we are solving? A typical pattern requires communication across levels. So there is a request
that comes in and then the answers are given out. That could be the analogy between the high and the
low levels. And what solution we came up with? Build the system with layers. At this point in time, we are
going to look at it at a high level and then later we will get into depth of the layered pattern. The picture
there depicts the three layers. Well, we are not restricted by three layers alone. We could probably have
seven layers or eight layers. Again, we need to have manageable number of layers. Typically, the
networking uses the OSI layering seven layers.
fi
ff
fi
fi
 Mud to Structure Pipes and Filters

• Pipes and Filters - Provides structure for systems to process stream of data.
• Context: A large system requires decomposition.
• Problem: A typical patterns requires communication across
levels-request<>answers from high<>low level.
• Solution: Build the systems with layers.

Video Transcript:
So here we look at pipes and lters, provides a structure for systems to process a stream of data. As you
can see on the diagram, we are moving from one lter to the other. Filter 1 to Filter 2 to Filter 3, and it is
connected with pipes.

Reminds me of a puri cation plant. Again, some motivation that can be got from maybe other streams of
engineering, mechanical and civil and water treatment plants, probably.

So again, we look at the trio, the context problem solution trio. What's the context here? We should be
able to process streams of data.

Problem, building exibility in processing of such data from one stage to another. We would want to make
sure we are able to process the data.

Every stage needs to be individually addressable from features or from what that stage does. Maybe we
would want to modify Filter 2 to make things better. And since it's organized in a structured form as Filter
1, Filter 2 and Filter 3, you can individually modify Filter 2. That provides real exibility.

So you can see how the solution has come up. There is a lter which becomes a processing units
connected with pipelines, and one could have as many number of those. Of course, you would want to
make sure that the amount of time it requires, the level at which each of these lters process, how the
process model is going to be for such architecture. That becomes part of engineering and design.

But this is an architecture pattern, which is very useful when you are talking about data and data
processing. Especially in applications like IoT, one can see that pipes and lters become very useful for
preprocessing processing data, further analyzing it.

Mud to Structure - Blackboard

• Blackboard - Useful for problems with no deterministic solution (Comes from Al). Several subsystems
assemble their knowledge.
• Context: A large system requires decomposition.
• Problem: A typical patterns requires communication across levels- request<>answers from high<>low
level.
• Solution: Build the systems with layers.

Video transcript:
Blackboard. This is useful for problems with no deterministic solution. In fact, this comes in from a area
which may be an immature domain. The problem statements are not very clear. All components which
participate in making the solutions are not yet mature enough. But the key is that we will keep trying to
gure out certain things through such research. It could be academic, or it could be industry or a
domain that needs certain computing attention. Things will always begin in a Blackboard manner. I think
rightly named as, it's a clear cut Blackboard on which you start drawing the lines to bring in clarity for that
particular domain. AI is one area that really began in this manner. With not real fast and super computing
available, but this was still envisioned that there will be such problems which we need to solve. Numerous
areas, even in health care, especially in diagnostics, where you see imagery. Those problems began in a
Blackboard manner, a lot of unknowns, a lot of new technology that needs to come together. The context
is always mature domain from a domain perspective, but immature from software and applications of
software in that domain perspective. There is no closed approach to a solution, which is known or even
feasible. You're really trying to do something which is not even feasible, or is not even known.
fi
fl
fi
fi
fi
fi
fi
fl
fi
What does this problem entail? What are the forces that come together which we need to really
resolve? The problem really crops up, like there are numerous steps that one needs to take. At every
step, we're trying to generate several solutions, maybe pick one of those and apply it. Thus, you would
see that you take one step several solutions, pick one of them, chalk out a course. You'll get several
solutions. Pick one of them, chalk out a cores. It's a matter of selection and choices that keeps on
happening. Hence, tremendous amount of research potential. One could make A choice, and the other
one could make a B choice and see how the choices pan out. What does this solution
become? Ultimately, with such kind of steps being taken in a context, especially immaturity new
domain, we do not know the solution yet. It becomes a collection of independent programs that ultimately
have to work cooperatively. You want them to work together to really go towards the solution. I think that's
really what Blackboard is. In many areas, when we start building something, even as a prototype, start
building hardware, embedded software. Start looking at some of the computer systems. All of these come
together to solve something. Classically, the way IoT would have begun, and in many areas, in many
domains where IoT gets deployed or worked on, it really turns out to be in reality, a Blackboard pattern to
begin with. Things are just coming together. You piece them together, you make decision, you move
ahead. This really is a very powerful pattern if you look at it from the power that it brings in for its
systematic steps when things are unknown.

While we look at Blackboard, let's look at the other two patterns, which are tremendous structures for
us. One comment that I would de nitely want to make is that layers and pipes and lters, can you really
bring them together? Would it be possible for us to have a stream of data processed within layers as
well? You see, there would be a mix and match of these patterns in a particular way with a particular
purpose to make things happen. From mud to structure, these three patterns would de nitely ease out the
anxiety related to building a solution because it gives you a pattern. Patterns, as we have seen, are
extremely powerful in getting you to a goal and ultimately build that superior software and give you a feel
of sitting on a chair, looking out to a window with beautiful scenery. That's the feeling part that we looked
at earlier. Architectural patterns of this nature, mud to structure have real structured approach, choices
that you make to build ultimate software. In summary, we've explored the mud to structure in a systematic
way, we've understood the patterns in this category, and we have spoken about some of the applications
of these patterns. Much more can be reviewed, much more can be explored, knowing the mud to
structure way of doing things.

Architectures - Distributed Systems

Distributed Systems - Category

• Patterns in this category use the combined power of multiple nodes on the network
• Distributed
• High performance and scalable

Video Transcript:
These are going to be nodes interconnected, probably each having their own function, but cooperating
with each other to ultimately build a high-performance and scalable system. Patterns in this category
use the combined power of all the participating node, and these participating nodes have a speci c
functionality. They have their own computing power, processing power, or they have some specialities as
some nodes may be smart, maybe

Distributed Systems - Architectural Patterns

• Pipes and Filters

• Provides processing stream of data. But is more used for structuring the functional core rather than
distributed. Hence discussed in Mud to Structure.

• Microkernel
• Applies to software systems are must be able to adapt to changing requirements. Hence discussed in
the Adaptable Systems.

• Broker
• Used to structure distributed software systems with decoupled components that interact by remote
invocations.
fi
fi
fi
fi
 • A broker component is responsible for coordinating communications - requests, results and
exceptions.

Video Transcript:
Let's take a look at the patterns in this category. Wow. There is pipes and lters again. What is pipes and
lters doing in distributed systems? If you really see, this is a pattern that provides processing for stream
of data. More used in a structural manner within the functional core of the system rather than
distributed. But then one can stretch one's imagination and say that each of the nodes is really going to
do the processing. The interconnections between the nodes will actually form the pipes. Again, one can
imagine in that particular manner. Pipes and lters can be looked at from a distributed systems
manner. But we in our discussion, have treated it from a more functional core perspective, hence, this gets
discussed in the mud-to-structure category. There is another pattern of a similar nature, microkernel,
which applies to software systems.

Which need to be able to adapt to the changing requirements. Now microkernel to brie y talk about it is
like it is supposed to work on changing hardware. Yes, it is really going to work from hardware A to
hardware B to hardware C. It needs to adapt to a particular hardware, and microkernel is required
to provide standardized services to the upper layers. Really can form part of a component where you see
all together as distributed nodes. But by and large, microkernel helps out in adaptable systems. Hence, it
is discussed as a part of adaptable systems. That leaves us with one and only pattern. It's an amazing
pattern called the broker. The name itself should ring the bell as to what it would be like. It is used to
structure distributed software systems with decoupled components, so each of them are decoupled. But
they interact with each other and have remote invocation capability. Component A can invoke a
function or something that is required of the other component. Component a to component.

Thus, as the name suggests, broker will really broker the systems and work together with other
components to make things happen. Primarily, one can look at the very old days of actually making a
long-distance phone call. You actually spoke to a person who set up the phone call and
ultimately connected you in the system. The person brokered the call for you. Today, we don't do that in a
similar manner. But exact same job gets done in a very advanced manner, where the moment you
dial, there are numerous systems that work together to ultimately make your call happen. May be long
distance, or it could be international call. It may go through the Internet, it may go through the satellite
communication, but it just brokers the call for you. Extremely powerful pattern from an architecture
perspective and can be used in a mix-and-match manner with other patterns to bring out elegant
solutions.

Video Transcript:
Let's look at the broker pattern a bit more in detail. What is this broker pattern responsible for? It's
responsible for coordinating communications, which is requests from one to the other results that come in
from the responding party if you will. There is a requesting party, that is a responding party, a requesting
node, a responding node. Of course, while doing so, we are also going to get errors exceptions, and a
variety of things can happen, and those need to be handled by the broker. Let's imagine a city information
system. A person who's new to the city comes in at the information kiosk. Lands at the airport gets to the
nearest information kiosk, and now is looking for transportation place to stay. Place to eat food
would want details about how the city is laid out, how far is the railway station or how far is the bus
stand. Such a system will have a central information desk. This test could be manned, or this desk could
be a web portal. When this is a web portal, all the systems are available through a click of a button on
demand of the user. All these requests will go. They will be sent by the broker to the exact server which
has those details. If it's a query about transportation, it would take on to the lists from a server related to
taxi, railway, bus. If it's about food, it would start looking at the server that has all the details related to the
restaurants in and around certain area. If it's about place to stay, it would be about hotels, the hotel
server. One can see that such an information system is much e ciently built with this architectural pattern.

Distributed Systems - Broker

• Context - Distributed environment, possibly heterogeneous system with independent cooperating

components.
• Problem De-coupled but inter-operating components rather than monolithic application.
• Solution - A broker component to achieve better decoupling of clients and servers.
fi
fi
ffi
fi
fl
 Video Transcript:
If you look at the trio, the context problem solution trio, context is, we have a distributed
environment. Possibly a heterogeneous system with independent cooperating components. Each of these
servers are independent. As we looked at, the entire city details may be available through the broker, or
each server could serve city details in that particular area independently. It is not a mask that one
goes through the broker in that particular application. What are the problem, the forces that are
being resolved over here? They're decoupled. They're inter-operating, they work together, rather than
creating a monolithic stack or a single operation for doing the whole job. Imagine if it's monolithic the
changes would be so expensive from time energy money perspective. Since it's distributed, say when the
hotels list gets updated, only that server needs to update. If it's a transportation update, that only that
server needs the updates. What's the solution here? We have a broker component to achieve better
decoupling among clients and servers. I have a client. There's a broker, and there is a set of
servers, ultimately, who will talk to each other and get the job done. A very powerful architecture pattern.

Distributed Systems Broker

• A system over the WWW which can comprise of:

• Clients
• Servers
• Brokers
• Bridges
• Client-side proxy
• Server-side proxy
• An IOT system may have broker architectures through its Web Services.

Video Transcript:
Here, let's consider a system which is built over the World Wide Web, WWW, which comprises of certain
sub components. We will even call them nodes. So broker really is one of the nodes within such a system.
And if we take the same example, the city information system, you would have clients. Clients would be
human beings who are looking for information. And for a moment let's consider that broker is actually a
person who is going to listen to the queries and further translate it to get data from the systems which the
person is looking at. And the information held by such systems are indeed the servers. Servers for
transportation, hotel and food joints.

So now you can see and imagine such an architecture, right? There is a client, there is a broker, and then
there are servers which ultimately are going to provide the information. If you look at all of this being
digitized by and we take the human out, bring an app which is in the hands of the user. So there is a
mobile phone app which ultimately is going to be the gateway or the broker to connecting to such servers
where one can inquire about the services that one is looking for and would get answers from all these
servers. Now, to make things easier, because it would be a large interconnected system, we would also
have numerous clients. It will not be just one or two persons, but hundreds and thousands and millions of
people who would want to know that information.

In fact, early days, early times, when there was a person who was asking for information, the person
arrived at the city to look for the information. But with digitization, you would have people across the world
looking for the city information, even if they may or may not visit the city. Thus the number of requests
would increase, would increase from clients. Hence the responses from servers also need to increase
because they now need to be capable to handle many more requests. And to make all this happen, there
would be bridges that would be built across these nodes for further performance enhancement. There
come the role of bridges. Client side proxy and server side proxy. So you see, in any broker system you
would nd these components really working together, holding onto their responsibility, but making sure
that the information is available. Right then and there in a connected manner in real time. I think that's
what the broker system can do. As we looked at the city information systems for a moment, let's consider
IoT system of today.

And it's on a factory oor. Factory oor, where there are numerous CNC machines, automatic machines,
which are operated by operators. They would load up the job, they would program the machines
and ultimately are monitoring these machines. The operator on the shop oor would be monitoring either
on the display, the human machine interface, or even has a way to view and take a look at the machine
while it is doing the machining.
fi
fl
fl
fl
 Needless to say, in the same o ce or from a remote location. The management is also going to look at
this particular data in terms of what's going on, what's the progress. Are there any breakdowns? What is
the e ciency? So each one of them will have di erent purpose of looking at the system for a moment,
look at how such systems will be architected through an app or a browser that becomes the portal or a
gateway into the world. And that really brokers the deal of a question to getting the answer question may
be let me know what the machines in a particular city, in a particular factory, operated for this particular
client's order. What's the progress? And there goes the entire query and the result comes out.

This can be imagined as a distributed system with broker as the architecture pattern. And isn't it a very
e ective way of getting things done with such a pattern? I'm sure you would realize that this is a very
powerful pattern and really useful pattern on a day to day basis in variety of application domains. I would
put out another example there. Say there is admissions portal for higher education. Again one could look
at a broker which gets details of the streams, courses, colleges, universities, all those are available
ultimately to the user.

It's very clear from all these examples that distributed systems have the power. In fact, digitalization and
digitization have really used these architectures to bring in power at the hands of the user. With the
available data being used, processed and further analysis of such a data makes more queries
happen, ultimately bettering the system.

Architectures - Interactive Systems

Interactive Systems - Category

• Patterns in this category allow higher degree of user interaction mainly through GUI and multimodal
inputs.
• The challenge is to keep functional core independent of the UI.
• Provide customised UI and Navigation.
• The category of patterns should be happy when subjected to change and should provide adaptation.

Video Transcript:
Let's delve into this deeper. What are interactive systems primarily? One way to look at it is that it will
have a UI, and it will have interactions. I think that's absolutely correct, but that's a very small but
signi cant part of the entire interactive systems. What these patterns in such a category do is that they
allow a higher degree of user interaction mainly through GUI and multi-modal inputs. Inputs could be
through a keyboard, mouse, touch, any pointing devices, a variety of inputs. In fact, it could be through
camera and gestures as well. Now, when you develop such applications, such systems which are very
interactive and graphical user interface intensive, there is a need for the GUI part, the UI part, the
interactive part, to be separate from the functional core and the challenge is exactly that. How do you
keep it independent? One of the prime motivation to keep it separate is that UI, GUI, and the way of
interaction can independently change while the functional core will change independently, but they have to
interact and work together. The independent change would mean that they're of course in line, but they
don't change at the same time, and many at times you would want only the UI to change, whereas the
functional core, there is nothing really to change, so we need such category of patterns which will
be extremely happy when subjected to change, and they would be able to provide a tremendous amount
of adaptation for situations of change, UI, as well as the core logic and some of the patterns are exactly
built for that.

Interactive Systems - Architectural Patterns

• Model-View-Controller - Divides the system into three components:

• Model - Core functionality and Data
• Views - Display information
• Controller - Handle user input

• Presentation-Abstraction-Control-An interactive systems organised as an hierarchy of cooperating

agents.
• Agent - Speci c functionality
• Communication with other agents
ff
fi
ffi
fi
ffi
ff
 VIdeo Transcript:
Looking at how these patterns need to exist, in fact, there is a prime need for these patterns to
exist, simply because our applications have become interactive, so there are two such architectural
patterns, the Model-View-Controller, and the Presentation-Abstraction-Control. These are the two
patterns, also known as MVC and PAC. What MVC does is that it divides the system into three
components, a model, a view, and a controller. Now this is where the magic happens where the model
which deals with core functionality and data is completely independent than the view, which is the display
information. The core functionality may maintain all the data, say pertaining to grades and grade
distribution in a class whereas the view may be a bar chart view or the tabular form in which the data is
presented, so it would be independent and not dependent on each other. So that is where the separation
happens. Again, we have the controller which will handle user input. The user says, "Give me tabular
data. the user says, "Give me a pictorial representation, or probably get me more details related to one
particular student if you are displaying student grades." You'll look at the cooperativeness of model, view,
and controller, working together to give an enhanced user experience while keeping things architecturally
elegant. Let's also look at presentation, abstraction, and control. Again, an interactive system. What this
necessarily does is that it behaves like an agent. There are PSC agents, and there is a hierarchy of these
agents. Each agent has a speci c functionality, and it communicates with other agents, which necessarily
would mean that if I was looking at student grades, I would have an agent that maintains the data. For our
discussion's sake, let's call it raw data. Now, this raw data is to be represented in a tabular form. Data is to
be represented pictorially or in a graph. All of these will become agents which actually have the
responsibility to do so with their speci c functionality responsibility and as the topmost entity
collaborates, cooperates with other agents in the hierarchy, the relevant data, along with how it needs to
be shown is available. That's presentation, abstraction, and control. At this point, would want to make a
note that as we look at some of the IoT systems or solutions, you would nd that raw data coming in from
the devices may have to be presented or abstracted to a level that each system may want to use it for
di erent purpose, so consider an IoT system or a solution along with presentation, abstraction, and
control but the app that accesses such a system provides all the information to the user on the go itself
may be a Model-View-Controller. Again, the mix and match comes into play. You can imagine the Model-
View-Controller or Presentation-Abstraction-Control for the app, which can be the client in the broker
architecture. I'm just trying to bring in a variety of things so that you can imagine how even patterns can
collaborate and make things happen by working with each other. In summary, interactive systems, when
you look at it as a category, explore them in a systematic way, they have huge potential, and in fact, they
are at the core of practically every application that has a UI today.

Interactive Systems - Architectural Patterns

Video Transcript:
What we have on the screen, the
model view controller, primarily
divides the entire system into three
components. We have the model,
the views, and the controller. The
model maintains the core
functionality and data. View displays
the information, and controller
handles the user input. Let's take an
example here. As we look at an
example, we start seeing say the
data that we have is for A grade, B
grade and C grades, which is given
as A is 10% or 10 people. Ten students have been awarded A grade, 40 students are with a B grade, and
ve students are with a C grade. With this, you could have a table that shows this or we could even have a
graph that shows this. This will depend on what user input we are looking at. Give me a table or give me a
graph. Now, as simple as this, but very e ective when it comes to such applications and you would nd
that numerous such applications depend on such functionality and pattern. In fact, in reality today, the
MVC architecture has been taken forward, and there are variants that have come in related to the MVC
architecture. MVVM is one of them. But at the core of this is this brilliantly crafted architectural
pattern, which is model view controller. Let's further explore how the whole thing happens when it comes
to operating using such architecture. We have the controller. Controller would contain control
logic, receives updates from view, then noti es model to add them. We have got controller that
communicates with the model. The model has the data structure. Updates the application to re ect the
fi
ff
fi
fi
ff
fi
fi
fl
fi
 added item. Something new came in, and the model is now going to learn about it, and further is going to
tell the view, there is something that got added and say, the user has done this job of clicking to add the
item onto the cart. Now you see that the entire cycle is not only complete, but it is also distributed
between the model, the view, and the controller, and the functionality so separated out. With the same
architecture, we looked at how a particular view, tabular, or graphical, and something where we are adding
an item in the cart will operate. That's the power of the architectural pattern model view controller.

Interactive Systems - Architectural Patterns

• Context: Interactive Applications with a exible HCI.

• Problem: UI changes, Extension of application functionality; thus modi cations occur.
• Solution: Separation of UI, core data and functionality and user interaction.

Video Transcript:
As we look at the details, we start looking at the trio context problem and solution. That's the trio that we
will always look for when we always want to analyze or understand an architectural pattern. The context is
interactive application with a exible HCI, human-computer interface, or human-computer
interaction. What problem are we wanting to solve? UI is going to change. We want to make the UI
better. Every few months, we would provide a better UI, a cool UI. We want to make sure that there is an
extension of the application functionality. Like we looked at in the example, maybe more charts get added
to analyze the distribution of grades. We could look at how students have performed in their school or
as you have a shopping cart as an example, maybe we change the way the card is shown. Maybe more
animation gets added, the way there is exibility on the UI, or in fact, the way the entire card gets stored
as saved items. Classically, you would see websites like Amazon save the items in the cart. Maybe you
have multiple cards that can be saved. I have a card 1, card 2, and card 3, and that is the enhancement
that I provide. It's an enhancement in the model, as well as enhancement on the UI, because now I need
to see multiple cards instead of just one card. What's the solution for this? Separation of UI, core data,
and functionality? That is what the solution will be for the problem which builds in all these forces of
change. The MVC architecture pattern really makes it happen for us?

Interactive Systems - Architectural Patterns

Video Transcript:
As you can see, we've organized it in a
hierarchical manner. You have you have
this at the topmost level, then the next
level, and then the third level. These are
cooperating agents, each responsible for a
speci c aspect of application's
functionality, and ultimately been able to
provide the use case. For example, we
have got a IoT application, in which there is
raw data that gets processed, and there is
a certain amount of one of the models that
gets saved over here. We have got Model
1, Model 2, and Model 2 of data. Now, each
of these three models can then be looked at di erently by this particular agent, which is responsible for
say, the UI. Then the responsibility is pertaining to what kind of charts can be shown by this particular
agent. This particular agent, which is agent number 2, may store meta data related to all the raw data, and
ultimately is able to present that data in certain reports to the user. You would see that the UI and the data
and its model can be really used extremely well while keeping the architecture pattern clean, entire
responsibilities distributed in such a way that each of these responsibilities can further be
enhanced. Because say, for example, the PAC 3 can be enhanced further. We may have metadata
upgrades being done, or each of these models themselves can change to another version. Thus, it
provides that exibility to grow this in a particular way to manage functionality, data, and even the UI in a
hierarchical manner, which is unique and much di erent than how MVC deals with it. But you can see that
each of them are unique enough that we can employ exactly the one that suits our purpose.
fi
fl
fl
fl
fl
ff
ff
fi
 Video Transcript:
We have the trio, the three things that we
look for, context, problem, and
solution. For us, the context here is we
want an interactive application. But in
this case, we are looking at agents with a
particular purpose that each agent is
going to do some speci c job, and we
discussed about it. What are the
problems and the forces that we want to
overcome? We want to look at each
of these agents as cooperative agents. Cooperative agents which maintain a data model, which perform
diverse tasks, and these are distributed among all of these agents. They also include things like error
handling or maybe even communication. All these become part of solving the problem. Ultimately, the
solution is a tree structure which further provides enough amount of exibility when you start looking at
the tree structure in a hierarchical manner. Finally, we look at the entire architecture in a tree structure
where there is a root node, and then there are other branches and leaves, and there are leaf nodes that
come into play. You can see that the PAC as an interactive system architecture pattern is very e ective
and powerful and can be employed for speci c applications.

Architectures - Adaptable

Adaptable Systems - Category

• Systems evolve over a period of time.

• Subject to change and adaptation.
• Support newer versions of UI platforms, hardware platforms may be necessary.
• Design for change is the major concern.
• An application should support its own modi cation and extension a-priori.

Adaptable Systems - Architectural Patterns

• Microkernel Software systems that must be able to adapt to changing system requirements.
• Re ection - Provides a mechanism for changing structure and behaviour of software systems
dynamically - a self aware meta level.

Video Transcript:
So what are the patterns under this category? There are two patterns, microkernel and
re ection. Microkernel would ring a bell about kernels in operating systems. Yes, that's where it really gets
its motivation from. So, microkernel is about software systems that must be able to adapt to changing
system requirements. And re ection? Re ection provides a mechanism for changing structure
and behavior of software systems dynamically by making the system self aware with introduction of a
meta level. You can imagine that when things change within the system, it's like I change certain things,
certain con gurations at a meta level. The system starts behaving di erently, right? One could, for an
analogy, recollect that a little change of con guration, that a feature can be switched on or switched o . A
noti cation can be on or noti cation can be o , will lead to the entire behavior of the application or the
system completely di erent. So let's dwell into this and understand the details further. As we look at
microkernel and re ection, we got to explore these in a systematic way. These two form patterns in this
category which have allowed that particular exibility to come into play, adopting the change as and when
it comes, being ready for it. And operating systems, or the con guration in an application would be the
way in which these patterns enhance our systems

Adaptable Systems - Microkernel

• Microkernel- Software systems that must be able to adapt to changing system requirements.
• Separates minimal functional core from extended functionality and customer speci c parts.
• Serves as a socket for plugging extensions and coordinating other collaboration.
fl
fl
fi
fi
fl
ff
fi
fi
fl
fl
fi
fi
fl
fi
ff
fi
ff
fl
fi
ff
ff
Video Transcript:
What does microkernel really do? As a part of microkernel, it separates minimal functional core from
extended functionality and customer-speci c parts. There is a functional core that would be really
separated; separated from hardware change, separated from the middleware change or the
applications. One can imagine as operating system, operating system works with the hardware on the
lower layer, and the middleware and the application area on the higher up layers of the entire software
system. It also provides sockets for plugging, extensions and coordinating other collaboration. Hardware
systems can work with each other. Systems can be plugged in or plugged out. Applications can be
installed or removed. All these can happen because all of these aspects are changes which the system is
ready to take on. That's by design.

Adaptable Systems - Microkernel

• Context • Development of several applications that use similar programming interface that build on the
same core functionality.
• Problem - Application platforms such as operating systems and GUI need to cope with broad spectrum
of similar standards and technologies.
• Solution - Encapsulate the fundamental services of your application platform in a microkernel
component.

Video Transcript:
How do we see it in our context problem solution trial? The context here is development of several
applications that use similar programming interface that build on the same core functionality. That's the
same core. In fact, even when you look at core technologies, core functionality and interface in say pretty
much standardized IoT systems o ering, you will nd that all of these core functionalities allow several
applications to be built because they are practically similar in nature. Data collection, data processing,
viewing. If you look at mobile applications, because the way the structure of platforms like Android or iOS
is that they are able to have hundreds and millions of applications using the programming
interfaces, ultimately the same core functionality to actually work so di erently. I think that's what
microkernel like architecture patterns can do. Problem. The forces that we are wanting to resolve. The
application platforms, such as operating systems and GUI, need to cope up with broad spectrum of
similar standards and technologies. You start looking at a variety of them, but there are numerous changes
as well. In fact, at one time, many of them exist, thus, the microkernel like pattern will have to cater to
those technologies during the similar times. It's not that you're completely upgrading and discarding the
old. Many could exist at the same time. The solution to this is encapsulate the fundamental services
of your application platform in a microkernel component. The moment you have a microkernel
component, you will be able to make your system adaptable and a system that is ready to change.

Adaptable Systems - Microkernel

• Microkernel Structure:
• Internal Servers
• External Servers
• Adapters
• Clients
• Microkernel

• Microkernel is the main component that implements the central services such as communication
facilities or resource handling.

Video Transcript:
A typical structure of a microkernel will have servers, internal servers, external servers, adapters, clients,
and ultimately the microkernel itself. You can imagine microkernel, which is the main component
that implements the central services, such as communication facilities, resource handling, everything the
microkernel would do. But with that, you're able to provide services through servers and adapters to the
clients. Things can be connected. They will be through a communication channel because they would do
a certain function. They would work with the internal servers for certain things to happen. It could be
server or service that is provided for IO, server or service that is provided for management of data. A
variety of things can be achieved with this particular exible and adaptable structure.
ff
fi
fi
fl
ff
 Adaptable Systems - Re ection

• Re ection - Provides a mechanism for changing structure and behaviour of software systems
dynamically - a self aware meta level.
• A meta level provides information about selected system properties and makes the software self-aware.
• A base level includes application logic whose implementation builds on the meta level. Thus, changes to
information kept in the meta level a ect subsequent base-level behaviour.

Video Transcript:
Adaptable systems re ection as a pattern. What does re ection provide? It provides a mechanism for
changing structure and behavior of a software system dynamically, which is a self-aware meta level. It
appears as if with certain changes that is made in selection of a eld, base level of functionality would
change. Like for example, country of origin changes and the entire list of items that can be o ered or
services that can be o ered maybe by the bank, a nancial institution, or a particular website for shopping
would change. Maybe this item requires import and not available directly in a particular country. Such
examples de nitely would bene t from use of re ection as a pattern. Let's look at the meta and the base
level. A meta level provides information about selected system properties and makes the software self-
aware. There are these properties. You create these properties. With those properties, your system has
now become self-aware. A base level that includes application logic whose implementation builds on the
meta level. Meta level changes happen, some change made in the meta re ects straightaway in the base
level. Thus, changes to information kept in meta a ect subsequent base level behavior. It's not only that
certain features are going to change, maybe the entire behavior of that particular application or a system
changes. That's where the term re ection really builds.

Adaptable Systems - Re ection

• Context - Building systems that support their own modi cation a priori.
• Problem - Software systems evolve over periods of time. They must be open to modi cation in response
to changes.
• Solution - Make software self-aware, and make selected aspects of its structure and behaviour
accessible for adaptation and change (Meta Level and Base level).

Microkernel Structure:

• Meta level - Metaobjects, each object encapsulates selected information about single aspect of the
structure, behaviour, or state of the base level.
• Base level - Models and implements the application logic of the software. It speci es the fundamental
collaboration and structural relationships.

Video Transcript:
I believe understanding the structure of re ection will allow a better understanding here. The meta level,
which is meta objects, each object encapsulates selected information about a single aspect of the
structure, behavior, or state of the base level. Meta a ects the state, but now here, you're going to store or
encapsulate this information. Base level has models and implements the application logic of the
software, speci es the fundamental collaboration , and structural relationships. Things that change at the
meta level, we allow those to be re ected at the base level. But here, the model and the application logic
itself is going to change. Like we said, choice of a country on a website changes what that particular
website o ers. For example, in nancial institutions, you would probably have multi country institution
which allows banking for one person who has accounts in say two nations. Now a lot of things would
change based on what the base selections are which are made by that person during banking. We're
talking about this at a high level, not really getting into the banking details, but these are the situations. Or
even on a mobile phone, a simple application where con gurations will allow those to be re ected in the
functionality. As simple as for security purpose, you would nd that location security, the apps would keep
popping, would you allow your location to be checked by the application? Do you want applications
to check the status and running of other application data? All these changes at the meta level or
something that the applications are requesting. From the base level, the platform application logic throws
those dialogues for user to interact. Isn't that a great thing? Because now you have really built the
re ection part into the system and make it usable, and also with its use, certain things can
change. Changeability is built into the platform.
fl
fl
ff
fi
fi
fl
ff
fl
fl
fi
fi
fl
fl
ff
fl
fl
ff
fi
ff
fi
fl
fi
fi
fi
fl
fi
fi
fl
ff
 Week-9

Architectures - Layered

Mud to Structure - Architectural Patterns

• Layers helps to structure applications that can be decomposed into groups of subtasks: subtasks at a
particular level of abstraction.

Video Transcript:
Layered pattern, as we know, layers help structure the application from a very unstructured set of
requirements and all the functionality that we need to build. And while doing so, we decompose them into
subtasks or groups of sub tasks, and each of these subtasks, we look at it from a particular level of
abstraction. So naturally, when the thought process is about subtasks and at a particular level of
abstraction, you will nd that the layered way of thinking leads to the layered architecture itself. Most of
the time you would nd in design thinking from a perspective and choosing a guideline to ask certain
questions. Look at how applications can be decomposed or they can be looked at from a top to bottom
perspective, actually leads to numerous answers and choice of appropriate pattern. At times, one pattern
or a group of patterns may be the solution, but it starts with questions. It starts with analysis of the
situation, it starts with looking at what the requirements are for design.

Mud to Structure - Layered Pattern

• Context: A large system requires decomposition.

• Problem: A typical pattern requires communication
across levels - request<> response from higher<>lower
levels.
• Solution: Build the systems with layers.
• Provides services to upper layers
• Delegates sub-tasks to lower layers
• Architecture for protocols

Video Transcript:
Now let's look at this layered pattern in a bit more detail, in
the diagram we see that we have got three layers, we have
got the layer 1, the layer 2 and the layer 3. Each layer there
are components and each of these components have a
particular functionality. They depend or they serve the upper
layer, they serve the upper layer. So here you can see that component 1.1 serves the upper layer, which is
2.1, and 2.1 in turn depends on the lower layer. There will always be this interdependency, and from the
abstraction that we spoke of, each layer actually abstracts the functionality or the subtasks to its level. So
you will nd this, this and this, these are the three layer 1, layer 2, layer 3, which I've got abstracted in that
particular way. Compare this with certain protocols, with a protocol we are going to have a packet that
reaches the computer. And in layer 1, the header and the trailer are actually parsed and removed and the
inside of the packet is passed up to the upper layer, that's when it moves to layer 2. In layer 2, header and
trailer is again looked at, certain actions taken, and then the core part of this particular data packet moves
to layer 3. Where it probably is looked at, parsed and something is shown on the screen with respect to
dat, so something will come up here as data. If you look at a particular protocol which is transmitting
temperature from a device, maybe ultimately you're going to get the temperature displayed as 28 degrees
Celsius for that particular device. And again there will be a device ID, so if I imagine the device id is 1, 2, 3
so we have device id 1, 2, 3 and 28 degrees Celsius. Which is actually the information that has been
retrieved that has been parsed out of the packet that came in. Thus you would see that layered provides a
mechanism as data and information ow up and ultimately they make sense. Now, why layered? Here you
would nd that we have decomposed the entire system into three layers. Each of the tasks that are done
by every layer can in turn be replaced or upgraded without a ecting the other layer. By this, what we mean
is that if we have the component 2.3, the component 2.3 in layer 2 can be upgraded to component 2.3-, a
newer version. Without a ecting any other layers or any other components even in the same layer. Of
course, provided it de nitely improves over the functionality provided, and not that it just changes
completely that other components and other layers are wondering what exactly happened. So you see,
this allows us to separate the concerns, build layered architecture which allows us to bring a very
fi
fi
fi
fi
fi
ff
fl
ff
 systematic decomposition to our problem. And to your left you can actually see the context problem
solution trio ultimately which allows us to build system with layers. Every layer provides services to the
upper layer and delegates sub tasks to the lower layer, and this is a very classic architecture that is
followed for protocol stacks.

Video Transcript:(continued)
As we have already seen, the layered architecture allows tremendous amount of exibility. It does a very
systematic decomposition of a large system. We have three layers, each layer made up of variety of
components, various components, components which may be interacting with either adjacent
components within the layer or components across the layer. They never skip a layer. So Layer 1, if it has
to interact with Layer 3, for whatever purpose, in whatever way, it will need to use Layer 2, either the
directions, either some information is passing from Layer 1 to Layer 3, or some services are requested
from Layer 3 to Layer 1, they will always go through Layer 2. Those are the kind of design details that one
would always look at. Now, do you believe that these rules are so sacrosanct that they're never
broken? Not really. In certain speci c and special cases, knowingly, you may want to really have a call that
happens from Layer 3 to Layer 1, but in those cases, those need to be well documented, and there has to
be a reason to do so. Remember, ultimately, you're building this entire system so that when components
change or when layer functionality is upgraded, you want your system to work, so it works both
ways. Layered pattern will allow a brilliant design, and as we implement, get to construction, we want to
make sure that even if we bend the rules a little, we will be able to consistently follow the new rules that
we have written or modi cations that we have done, so that we do not break the functionality.

Layered Pattern - Implementation

• De ne the abstraction criterion

• Determine the number of abstraction levels
• Name the layers and assign tasks to each of them
• Specify the services
• Re ne the layering

Video Transcript:
The rst one is, de ne the abstraction criteria. All the criteria that we're looking at from a system, we got to
make sure that we have a de nition for it, we have understood the abstraction criteria. In fact, as you start
looking at and usage of patterns, increases in your design world, you will nd that the moment you read
about a problem statement, you will be able to tentatively talk about a choice of patterns that could solve
the problem. You may ultimately make a choice of one or two out of those, but de nitely with experience,
with knowledge, you'll be able to actually identify what exact pattern you would choose. Similarly, after
you have done the abstraction, the number of layers or number of levels of abstraction is also a matter of
experience, and that becomes one of the key factors because remember, as number of layers increase, so
will the number of calls, so will the amount of code, so will multiple things that would increase because
overall construction cost in terms of time, energy, money, testing, memory requirement, maintenance will
all go up. Once you've gured this out, got the abstraction right, got the number of levels done, name
those layers, and assign particular tasks. You will recollect the components that we put together. We could
have each layer actually have components, and these components perform these speci c tasks.

As the tasks are performed, those would become services for the upper layers, and the upper layers
would actually provide these tasks to the lower layers, so specify those services. Services of A layer, say
Layer 1, when speci ed, the Layer 2 can become more e ective. It will start using the services of Layer
1, and the way to use it and to accomplish its task when it is going to use Layer 1 services, Layer 1
services will start being re ned. Each layer will go through that process. So ultimately, we will be able to
achieve the next step, which is to do with re ne the layering. As we follow these steps, you would nd that
from abstraction to layers, is what we have got to, and that forms one of the key part of actually the
layered architecture.
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
ff
fi
fl
fi
fi
fi
 Layered Pattern - Implementation

• De ne the abstraction criterion

• Determine the number of abstraction levels
• Name the layers and assign tasks to each of them
• Specify the services
• Re ne the layering
• Specify an interface for each layer
• Structure individual layers
• Specify communication between adjacent layers
• Decouple adjacent layers
• Design an error-handling strategy

Video Transcript:
The rst part, rst ve steps. The rst set of steps actually get you
to creating the layers. Here, we have got the abstractions done
and then we have got the layers speci ed.
The second half, that is 6th to 10th step, actually gets you to building the layered architecture or
constructing the layered architecture. In fact, of course it would involve design of the component and the
layer itself. But here is how it starts. You start o with specifying an interface for each layer. So each of
these layer, each of the components, you would nd that ultimately there would be certain interfaces
or the way these components within the layer are going to be accessed or their services used by the
upper layers.

Beyond a point, we start structuring individual layers. Both have to come together. You will nd that we got
to bring in services, abstraction, and then once these interfaces are done, you know that we have now got
the layered architecture well de ned, well de ned with its boundaries. That is the exact step of structuring
individual layers. The specifying communication between the adjacent layers. At times, you would nd that
at one level you may have multiple layers or these layers are operating in a particular way. Let me give you
an example here. This is one layer.

In the second layer you really have it split in a particular way. Let me number it for you, one, two, three and
four. At times for a particular use case to be done well, you would nd that this architecture or these layers
will participate, whereas in other case maybe these would participate. And there is a possibility that you
ultimately have a communication between these two layers as well. That is two and three. You want to
make sure that while there is a dependency or speci ed communication, we want to make sure that we
decouple even the adjacent layers.

Decoupling forms the key. And ultimately, of course, we got to have a error handling strategy at all
levels, at component level, at layer level, at functionality level. At all levels, all errors and exceptions must
be handled. So just to take a quick look back, we have got these two sections. Particularly, one allows the
de nition of layers. Yes, we have got them right. Next stage allows you to get the internals of the layers
right. So if you really see there is always a pattern of thinking when you approach this design. For all
design and design principles and for all designs to be successful, important part is how one thinks and
approaches. And each step is taken with a perspective that we want to solve a particular problem. No
brute force application of a layer for a solution, but let it unfold in terms of how are you thinking about the
problems that you're encountering and the solutions that you're building. Remember the trio, the trio that
we have, which is the context, problem and solution.

Layered Pattern An Example

Video Transcript:
Let's take an example here. We have an example
of an FTP protocol and a very classic layered
pattern. This layering is just amazing and brings
out the core aspects of a layered protocol.

Physical connection is using the Ethernet. So

there is Ethernet. Two machines say this is the
client and this is the server. They are connected
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
ff
fi
fi
fi
fi
fi
 using Ethernet.

Yes, at the lowermost level, there is an Ethernet protocol. There is Ethernet, there is IP, there is TCP. And
using the TCP protocol, FTP sessions are set up. Thus, you would nd that FTP is actually built, that
packet is built, there is TCP there, then there is IP, then there is Ethernet. And ultimately, the entire packet
goes over here, the full packet from the Ethernet, the IP packet is out, the TCP is out, and ultimately, you
will nd that you have FTP content which is set up and sent from client to the server. Exact layering that is
used in such cases.

And remember, FTP really is a magic protocol, right? When we learned it to begin with, it had two
connections, one which allowed control and one which allowed the data transfer. So even when the data
transfer is happening, you could stop it by actually allowing some control. You could monitor it using some
control. In fact, that is one of the advantages of the FTP. Now that's functionality and not really layered
pattern that is making any magic out over here. So you see, this is a perfect example for our layered
protocol.

Architectures - Model, View and Controller

Interactive Systems - Category

• Patterns in this category allow higher degree of user interaction mainly through GUI and multimodal
inputs.
• The challenge is to keep functional core independent of the UI.
• Provide customised UI and Navigation.
• Subject to change and adaptation.

Video Transcript:
To begin with, why does this pattern at all exist? Primarily, this pattern allows a higher degree of user
interaction mainly through GUI and multimodal inputs. That's one. Whenever there is UI, one of our
expectation is UI will change, or UI will de nitely have multiple versions sooner than the core
functionality. Motivations could be maybe multilingual, or depending on certain con gurations, the ow
might change, but the UI de nitely would have some changes. Lot of these changes which come in, come
in in either a batch individual change or otherwise. But whenever such things happen, changes come into
play, we would want to restrict it to a particular box in the architecture. Here, we actually keep the UI box
and the functional core separate. While we do this, we also need to take care of the interaction that
happens with the user. That's the third part.

Interactive Systems - Architectural Patterns

• Context - Interactive Applications with a exible HCI.

• Problem - UI changes, Extension of application functionality; thus modi cations occur.
• Solution - Separation of UI, core data and functionality and user interaction.

Video Transcript:
Let's take this further, and we look at the context problem and solution. Here, the key area to understand
is that whenever there is a interaction that is happening between the user and the application, we've got to
have the view and the controller behave appropriately. Here, use cases will play a very important role, and
each use case would require certain data, functionality, and navigation. Looking at this entire set of
architecture as an interactive system, looking at it from a use case perspective, you will start building
context problem and solution very di erently for a target application. It's like mobile phone, and contacts
application, or you look at a computer and the orange data mining tool. Or we look at web based calendar
management. You start looking at these applications, you will nd that user input, navigation, the data with
respect to that particular use case, forms a crucial part of taking a particular use case from start to
nish. Use cases become prime important to be used as design test data during usage of patterns for a
particular solution. MVC is a great candidate because there is user interaction to a largest extent in this
pattern. We depict a very classic view of what model view controller ultimately provides you with its core
feature.
fi
fi
fi
ff
fl
fi
fi
fi
fi
fi
fl
Interactive Systems - Architectural Patterns

Video Transcript:
The pattern that really allows us to do
multitude of things and which is one of the
core patterns in most of the applications
today. And as we go along, we'll also learn
about the speci cs of usage of this
pattern. As we already know, this pattern
talks of separating the UI and the functional
core.

There is one part that comes into play when

you're looking at once the separation is
done, how would the components that
need to know the updates actually are
informed? That communication is extremely
important. For example, something changes on the view or something changes in the model. All the views
based on the change in the model need to be updated, or based on the change in the model, the
controller needs to be updated to enable or disable certain kind of input from the user. Thus, clearly, you
would need a mechanism to communicate to the view or to the controller. Let's see one of the ways as to
how this is done. This is done in this case by using an observer and this observer class really helps you by
building an update method. At all times, whenever relevant, the update method is called to make sure
that the relevant components get the updates. This is crucial for the entire state of the system to be
maintained and no component falls behind. Well, if a component falls behind does not have the latest
update, it is de nitely going to be disastrous for the application. This exactly is what the observer class
here we have for some of the implementations which have such an update mechanism need not have an
observer class with update functionality. You could do that only through the model, view and controller
and the framework that most of the application frameworks provide. This model, this architecture pattern
is pretty popular, and variants of this have been prepared, made, tested. But in a sense, this is what the
entire pattern looks like. As you can see, you would want the methods which are absolutely relevant one
to initialize the model. You actually are able to get the core data. You're able to get events, updates,
service, display, all interleaved in such a way that the system works as a symphony for a particular UI ow.

Interactive Systems - Architectural Patterns

Video Transcript:
Here, on the screen, you have a dynamic
way of how controller model and viewer
operate. Say, for example, you have an event
that arrives on the controller. The controller
actually calls for a service and this service is
called on the model, which actually does
mean that there is some data that is going to
change and that noti cation happens on the
model, to which model knows that certain
things have changed, and I need to update
the viewer. It sends the message to view for
update and the update of the display. All
those views which have signed up for that
particular functionality will actually get the data and the display will be updated. Further to which any
update that is required by the controller based on the original event and the service provided, the update
to the controller will also be made. Once the entire system goes through this message sequence, it arrives
at a state where model view and controller are consistent with respect to all the events that have
happened. This is such a careful and symphony of actions to separate the core functionality from the
UI, and controller helps in such a brilliant way to make sure that user is also provided the input as to what
is possible and what is not based on the actions. This happens in a ow. One can imagine that the action
may be that the user has actually typed in something on the word processor, and that would be the handle
event. With that, the model updates the view. Maybe there are other views that need to be updated, but
the controller needs to be told that the action related to saving the document is now pending because
fi
fi
fi
fl
fl
there is a change in the word processing model itself. That becomes really a closed-loop system for the
entire system to operate and not miss out on any of the events or actions on services based on the
events.

MVC Implementation

• Separate human-computer interaction from core functionality.

• Implement the change-propagation mechanism.
• Design and implement the views.
• Design and implement the controllers.
• Design and implement the view-controller relationship.

Video transcript:
Let's take a look at step-by-step implementation of MVC. First step, separate human-computer
interaction from core functionality. Once the core functionality is known, and the human-computer
interaction is known, at least those two parts are crystal clear in terms of where the separation will
be. Next, you need to have a change propagation mechanism. Changes happen to the model. How will
the UI know? How will all the other components know? We need to know that. Next step is to design and
implement the views, the controller, and the view-controller relationship. View controller relationship is
crucial to make sure that inputs and the views always remain hand in hand in sync. The change
propagation mechanism helps the model to make sure that the controller and view are always kept in sync
with respect to the changes in the model. What next? Next is implement the entire set-up of MVC.

MVC - Implementation

• Implement the set-up of MVC.

• Dynamic view creation.
• Pluggable controllers.
• Infrastructure for hierarchical views and controllers.
• Further decoupling from system dependencies.

Video Transcript:
Now that you have the three boxes, our M, V, and C, along with the change propagation mechanism
and the relationship between the view and the controller, I think you are ready to set up the MVC. You can
now look at dynamic view creation, based on this particular set-up, you can actually create dynamic views
based on the model and based on the controller that are available. Further to which, entire system can be
enhanced by building pluggable controller. You could build a infrastructure for hierarchical views and
controllers, which further give you insights into variety of views and controllers into the system. At all
times, you would want to make sure that there is enough decoupling from any system dependencies. You
may want to remain agnostic to any of those dependencies and strive for it from a design perspective.

Design Patterns

Interactive Systems - Category

• Creational design patterns abstract the instantiation process.

• Make system independent of its objects are created, composed and represented.
• Inheritance is used to vary the class that’s instantiated.

Creational Patterns - Category

• Creational patterns:
• Prototype
• Abstract Factory
• Builder
• Factory Method
• Singleton
 Singleton Pattern

• Intent - Ensure a class only has one instance and provide a global point a of access to it.
• Motivation - Some important classes must have exactly one instance printer spooler, one window
manager.
• Applicability: Sole instance should be extensible by subclassing.

Creational Patterns - Category

• Structural patterns are concerned with how classes and objects are composed to form larger structures.
• Rather than composing interfaces or implementations, structural object patterns describe ways to
compose objects to realise new functionality.
• Added exibility is due to the ability to change composition at runtime.

Creational Patterns - Category

• Structural patterns:
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Decorator Pattern

• Intent: Attach additional responsibilities to an object dynamically - a exible alternative to subclassing.

• Motivation: Some we want to add additional responsibilities to objects and not to entire class.
• Applicability: To add responsibilities to individual objects dynamically and transparently, that is, without
a ecting other objects

Behavioral Patterns - Category

• Behavioural patterns are concerned with algorithms and the assignment of responsibility between
objects.
• Describe the pattern of objects as well as the communication between them.
• Behavioral class patterns use inheritance to distribute behaviour between classes.

Behavioural Patterns - Category

• Behavioral patterns:
• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy

State Pattern

• Intent: Allow an object to alter its behaviour when its internal state changes.
• Motivation: Objects respond di erently based on its state.
• Applicability:
• Objects behaviour depends on its state and it must change it at runtime.
• Operations have large, multipart conditional statements that depend on the object's state.
ff
fl
ff
fl
Video Transcript:
Let's look at the intent motivation and applicability trio. Intent is allow an object to alter its behavior when
its internal state changes. Since it is to do with the state, as the state changes, we would want the
behavior to change accordingly. What is the motivation for creation of such a pattern? We would like
objects who respond di erently based on their state. What's the applicability? Object's behavior depends
on its state, and it must change it at runtime. Now we can see this. We've got object, it will alter its
behavior when the state changes, and this is going to happen at runtime. This is a great availability of a
feature and a pattern that will make sense in many applications. As a part of applicability, one can always
see that operations have large multi-part conditional statements that depends on the object state. All
operations then will actually go by the state of the particular object. If you can see, state like the TCP
connection in networking, you will nd that the state of the TCP connection, which is either open or closed
or acknowledged, will have a particular meaning in operation of that particular TCP socket. Thus, you
would see state modi es the entire behavior. In a plain UI, you could also look at that when there is no
document open, a lot of menu items are grayed out. Primarily, those objects are in a particular state, that
there is no action that can be taken. Hence, the state of the object is no action. Whereas when a
document is open, actions can be taken because the state got changed. One can look at it from a state
pattern perspective or also from the MVC as to how the C will behave when the view actually changes
based on the model and the state in the model related to the overall word processor. State as a pattern is
extremely useful when you want to manage the operations based on the state of a object.
fi
ff
fi
 Week-10
Languages and System Software
Paradigms and Languages-1

• Procedural: Prototyping, Learning: Python.

• OO: C/C++ for Systems Programming; Java and Python for web and mobile applications; Python for
ML.
• When you use an ipynb notebook for ML, are you doing procedural, OO or functional programming?

Video Transcript:
Then, how can we not go without choosing a paradigm for software development of a system, of a
complex software system? So we have to choose. And what is available to us? Procedural like for
prototyping or machine learning, there is Python. And then there are object oriented languages, C, C++ for
systems programming. Yeah, C is for object oriented programming when it comes to systems
programming. And then Java and Python are there, object oriented again, for web and mobile
applications. Python's object oriented features are used there. And Python, its object oriented procedure
and function, all the features are used for machine learning.
So when you use an ipynb notebook for machine learning, when you are say, doing it with Google Colab,
are you doing procedural OO or functional programming? You consider this. When you actually use it, you
ask yourself, what kind of a paradigm you are programming in? You are not planning big software there,
you are not planning your program, but still you are using one of the paradigms.

Paradigms and Languages-2

• To learn a language on the job, or to use an unknown feature (such as the functional part of Python), one
needs to know a few salient features.
• The "Axes of Classi cation":
• First Class Citizens
• Granularity and Modularity
• Keywords v/sAPI/Lib

Video Transcript:
So when we have no such choice, but we have to learn a new language, it's not chosen by us, but chosen
by the situation, and we have to learn it on the job or use an unknown feature such as the functional part
of Python. No, we can use and we can exploit the functional part of Python. But most of the times we are
not forced to do that, but sometimes we are, we cannot do something just by procedural or simple object
oriented design. Then one has to know some silent features for that language or for that particular
paradigm in that language. So the classi cation access will be, what are the rst class citizens, what is
programmable? So as I gave the analogy earlier with furniture in a house, what are the things that you can
actually change, recon gure, customize, and so on.

And then what are the things which are always there and they are the part of the hierarchy? So these are
rst class citizens. And then what is movable, what is changeable, will be those things which are
programmable. So rst class citizens are like those government o cials who are always there in that
position. Even if the person changes, the position remains, and the power and the relation of that position
with others remains there. Those are rst class citizens. Granularity and modularity is what you can
basically organize, reorganize, recon gure, and that is the programmability. What are the units that you can
change and move around?

And then there will be keywords, which are part of the language grammar, whereas there will be
application programming interfaces, APIs, or libraries.

Libraries are those ready made software pieces which can be used as objects classes or functions
methods and so on, but they are not part of the language grammar. And you can choose di erent
APIs. You can choose a di erent library, and maybe the syntax is the same, but the functionality is
di erent, or the particular signatures of those classes, methods, names, everything may be di erent, but
you know the what part of it that is common. So when you are choosing a language, the keywords are
given, whereas when you are choosing a library, you are choosing the what part of it, what is the
functionality that you are seeking out of it? And that is quite exible. So the rst point here, rst class
citizens, is the least exible part and the libraries is the most exible part.
fi
ff
fi
fi
fl
fi
ff
fi
fi
fi
fl
fl
ffi
fi
fi
ff
fi
ff
 Paradigms and Languages-3 & 4

• C/C++: Each module is self-contained for types. Functions (procedures) are the structural components.
Location addresses are the rst- class citizens.
• Java: Classes are the structural components and rst-class citizens. Objects are the second-class
citizens.

• Python: no structure, no hierarchy.

• Preprocessing, extensions, add-ons, directives, pragmatics: means of reorganising, connecting,
merging, repurposing.

Video Transcript:
Now on this classi cation, let us look at the di erent languages. C/C++, each module is self
contained. Each module means one source le, like .C or .CPP or .C le that is self contained for
types. What that means is that all the type information is available with one module and that's it. And you
can have then di erent types handled synchronously for the same values also, for the same locations also,
but in di erent modules, di erently. That's possible in C/C++.

Here, the structural components, what we can call rst class citizens, they are functions. This has to be
second class citizens. Location addresses are the ones that you manipulate all the time. You can easily
change them, whereas in Java classes are the structural components. And so they cannot be changed on
the y. When you are programming, when you are designing the program, well, yes, you design the
classes, but once designed you cannot change them. They are rst class citizens, objects are the second
class citizens. You can manipulate them, you can also even change them while they are having certain
values. So you can change a lot with objects, but you cannot change a class once you have started
running a program. Then in Python there is no such thing, no structure, no hierarchy. Even types, two
values are not rst class indicators. They are not unchangeable. You can have duck typing. That means,
on the y, you can just decide the type of a value by doing some operation on that value. If that operation
is doable, then that value has that type. It is of that type that has that operation doable. So that is how
Python works. Now, there will be many other peripherals around programming languages as
well. Preprocessing, that means, for example, for C language there are preprocessors, and every C
program is rst preprocessed before the compiler properly compiles it. Now, this pre-processing will give
you some micro processing, and this will help you also compress large complex software systems into
small eggs which get expanded or exploded, we can say. Or the big trees grow out of them when you are
installing. So what you download as a package source is something small. But then using pre-
processing, you can generate source les from some template inside them. And this idea is applicable to
many other languages as well, except that we don't have an explicit pre-processing stage in the
compilation process. But AspectJ, for example, the aspect oriented extension to Java, it's an extension,
and in a sense it is pre-processed. Of course you have separate compiler, but what it does is pre-
processing the aspect oriented code into proper Java code. Because aspects are extensions, we can call
them add-ons also. Sometimes the add-ons are on the y, that is, they are not like language extensions,
but they are like pragma directives. They are put with some special character like ampersand or
@about, such special characters are used there to indicate to the native compiler that, okay, don't worry
about them, they are handled by somebody else. And then those directives will help some pre-
processor, microprocessor or some other extension processor to convert those into some kind of native
code which will be compiled in the target language. So these are all means of reorganizing, connecting,
merging, repurposing, di erent programming languages and di erent components of a
complex cooperative system which may be developed in di erent programming languages. So all these
are the devices for that..

The Main Languages of Embedded Systems

• Assembly, Procedural/00
• Assembly/Verilog, C/C++, Python, Java
• Also: Rust, Lua, Ada
• Embedded C
fl
fl
ff
fi
fi
ff
fi
ff
ff
fi
fi
fi
ff
fi
fi
fl
ff
ff
fi
fi
The Main Paradigm(s)

• It is always combined for embedded systems

• Procedural+OO+Functional
• Type-safety, memory management without segfaults

Video Transcript:
The main paradigms are always combined. Embedded systems software development is never in a
unilinear fashion, and we don't get to do any pure programming here, so it is always combined. We
combine Procedural Object Oriented, and functional all together. What is more important here is type-
safety and memory management, as much as possible completely static. That means the compiler only
handles it or the runtime environment handles it without any crash, which is called segfaults or
segmentation faults, because that is the additional message that used to come on unique systems
whenever there was some problem with memory management. We don't want basically the system
to crash because of some memory management failure.

The Main Considerations

• Optimisation
• Fault tolerance: Mixed criticality
• Type-safety, memory management without defaults
• Development and maintenance are clearly separated in time and pricing, yet must be woven together
• Hardware compatibility is tricky

Video Transcript:
The main considerations are these, optimization, fault tolerance. There is mixed criticality, every system is
not equally critical, even for your automobile, which is not as critical as rocket launcher, but there is a
mixed criticality in that system. For example, you may want your radio in the car to work really to our
test, but at the same time, it must not take your and the engines attention away from the road and the
road conditions. If at that moment, It has to also stop the AC cooling and stop the radio in order to divert
all energy to handing some critical situation in power transmission. It has to do that, even though the
people in the car may be uncomfortable with that. There are certain levels of criticality and fault tolerance
at each level is very critical in software development for embedded systems. Type-safety memory
management without segmentation faults, as I already mentioned, development and maintenance
are clearly separated in time. You cannot do maintenance while the car is running or while the rocket is in
air, of course. Of course, the pricing for these also is di erent. Still you have to view maintenance
considerations in the software development process , design process itself. You cannot separate them in
your considerations. Hardware compatibility is tricky. When the hardware is upgraded, you cannot just
say, I will just put the same software, put means copy the same software into the new hardware. That may
not work, that may fail very badly. Version control thereby is also tricky. You have to keep all the old
versions because you don't know when will you need a copy of some old version for some old hardware.

The Main Languages for Mobile Phones

• iOS: Objective-C, Swift

• Android: Kotlin, Java
• Both: Javascript (React Native); Dart (Flutter)

The Main Paradigm(s)

• It is always combined for mobile systems

• Procedural+OO+Functional
• Type-safety, memory management without segfaults
• Concurrency, synchronous/asynchronous code: coroutines

VIdeo Transcript:
The main paradigms here are, again, they are always combined for mobile systems because again we
have some mixed criticality. Although di erent from embedded systems for automobiles or for rocket
launchers. But we have to combine procedural, object oriented and functional paradigms as usual. Type-
safety, memory management without segments is again critical here. Especially fault tolerance is important
ff
ff
 when the communication functions, that is phone calls and such things are on. And you must have seen
the di erence between, for example, SIM calls. That means calls which are on the SIM card in your mobile
phone coming from the telephone operator, service provider of that particular SIM, and the calls that you
can make on the Internet or data. You can also have a data connection which may be with your SIM
or maybe some WIFI that you are getting from say your campus or wherever. And you can have calls on
the Internet, you can see the di erence. Calls on the Internet are less fault tolerant, fail more often, or even
when you cannot hear the other person, you may be able to talk and the other person may be able to hear
you. and so many things can happen and still the call session continues, whereas when such a thing
happens with sim calls, most probably the call session breaks, calls are dropped. So there is a certain
di erence between di erent kinds of communication paradigms here, but nevertheless fault tolerance is
critical. Therefore the issues will be concurrency and synchronous asynchronous code. There are
coroutines, that means procedures which can be executed simultaneously such that they together give
some functionality or they can give di erent functionalities simultaneously. So recall one of the problems I
have repeatedly asked you in earlier modules.

Can you explain to your grandmother on the phone while talking on the same smartphone how to use that
smartphone's screen to do something else without dropping the call?

So that is not possible without coroutines being programmed in the system software of the phone.

That is, we can still do that, we may be able to teach somebody else also by verbal instruction, but all this
is possible because there are coroutines.

The Main Considerations

• Optimisation
• Fault tolerance
• Type-safety, memory management without support
• Upgrades and system segfaults

Video Transcript:
So the main considerations are again optimization, fault tolerance, type, safety, memory management,
then upgrades and system support. Basically, when softwares are upgraded, when the whole system is
upgraded, some of the application softwares may not be upgraded. But then the system has to continue
supporting them because that is what we can call a service contract. Whereas when the software
packages, the particular applications are upgraded and the system is not supporting them, then you might
want to upgrade the system again. There will be mixed criticality and hardware compatibility. These are
tricky issues, they're also, of course, the import or the impact will be di erent than, for
example, automobile embedded systems or rocket launcher embedded systems. Then version control, as
usual, is again tricky in the case of mobile phone software as well.

GUI Development Frameworks

GUI Toolkits

• Applications that are interactive, complex software systems must have a graphical user interface (GUI).
• GUIs have evolved from punched cards, pure text-based teletype terminals to smart wristbands.
• The idea that interaction involves hand- eye coordination Or some sensory-motor coordination
• Entails: linking cognates and commands

Video Transcript:
GUI toolkits are basically building frameworks or design and development frameworks. Applications that
are interactive, complex software systems, they must have a graphical user interface, and if you have seen
earlier, or maybe even now, some of those old type power looms, cloths, they have such punched card
systems in which the design that is going to be woven, the patterns woven into the cloth, they are
programmed in the pattern on the punched cards. Each position on the card system indicates certain
pattern or some thread that will be woven either Cs or cross. This is, in fact, also a form of interface that
was used in the early computing systems. From there, the evolution went to such teletype terminals, in
which you typed, but you didn't have an immediate screen feedback, it was not like what we have
now; what we type is immediately what we see, and what we see is what we get in terms of the
ff
ff
ff
ff
ff
ff
output, that was not the case. Teletype means it was remotely connected to some computing system
somewhere maybe out of your view, and you would get the feedback only after the computer had equaled
or responded in some fashion on the screen, if at all. These were the interfaces earlier, which were not that
interactive, or we can say not that user-friendly. Now we have come to, from there, the beginning of a
proper graphical user interface, and it has come to this smart wristband, which doesn't have a screen by
itself, it is projecting on your wrist. Then you can use your nger to choose characters, menus. Typing is
not on a keyboard but on your wrist itself, and you have to just choose the correct position on the wrist, or
maybe on the screen also, some button on the screen that is visible there, if you put your nger on that, it
is like pressing a button. It has come to this now, and it can even evolve more, it can become smarter and
more user-friendly also. Applications require such graphical user interface, and they have evolved a long
way now, but the idea that interaction involves hand and eye coordination, that remains. Or it will be some
sensory-motor coordination because sometimes people who are visually challenged, they might require
some auditive feedback, and then they can choose what they want to do and also tell the computer in
some way. This entails linking cognates, that means units, which we recognize as integral and we can say
component units, and connecting them with commands.

Why Toolkits to Build GUIs?

• If I show you the icon of an old transistor radio for a radio button, will you recognise it as an MCQ?
• "Clicking the mouse on an icon"
• Cursor, cell, pointer, "current" context and "current" icon/app/screen region etc.

Video Transcript:
What are they? First of all, look at this, suppose you were to give a radio button in an interface, and you
thought, okay, it must be some picture of a radio, you give a picture and Choice 1, Choice 2, Choice 3 like
that, will it be helpful? Can you, for example, take a quiz in which you have multiple choice questions like
this? Or think of this idea of clicking the mouse on an icon. In the early days, in fact, people used to pick
up the mouse, take it to the screen, point it to the icon, point means physically they thought that it should
be in front of the icon that is seen on the screen and then click, and the cursor would be somewhere
else, and whatever they clicked, it was clicked on that position where the cursor had been. All these ideas,
cursor, cell, pointer, current context, and the current icon or application or the screen region and all these
things, these are crucial in that hand-eye coordination, you have to be able to recognize them as
such. When my mother is asking me help in using her smartphone, she's showing me, see here, when I
click here, and before she knows, she has already clicked because she has put the nger there, and then
the screen has changed, of course it has gone to wherever she has clicked and the target. Then she is
like, oh, what happened? How can I now recover that? I cannot show you what I wanted to show you. All
these ideas have to come to some standard practice between the users and the developers who are
making the interfaces. The way to standardize is widgets

Widgets-1 & 2

• A Windowed Gadget
• "A software widget is a relatively simple and easy-to-use software application or component made for
one or more software platforms. A desk accessory or applet is an example, in contrast with a more
complex application such as a spreadsheet or word processor.”

• Example:
• Pull-down Menus
• Pop-up Menus
• Radio Buttons and Check-Boxes
• Text Input Fields and Boxes
• Push Buttons and Dials
• Cells with Typed Data or Icons
• Cursor/Pointer modes and actions

VIdeo Transcript:
What are widgets? A widget is a windowed gadget. You may search on, say, Google, and you will see
many de nitions, even Merriam-Webster dictionary gives you a de nition, like a gadget, but they forget the
connection. It is a windowed gadget, it is a combination of the two words, historically, now it has become
widget, and now it is part of our vocabulary. A software widget is a simple component, which is like a nut
fi
fi
fi
fi
fi
bolt, it can be plugged anywhere, and then it can x many things together also, and so on. It should be
versatile, it should be available, it should be usable on more than one software platforms. This is in
contrast to whole applications which have many features, complex applications, and perhaps you don't
use even more than 5% of those features in that application, whereas this widget is used only for one
purpose again and again in many di erent contexts for many di erent applications. So it has only one
feature or whatever is the speci c purpose of that widget , that is its feature. They are named also as such
according to the functionality they provide, pull-down menus, pop-up menus, radio buttons, checkboxes,
text input elds, and text boxes in which you type in more things like an editor window also. Push buttons,
dials, cells with typed data or icons, cursor/pointer modes and actions, all these things, will be widgets.

GTK-1

• GTK is a library for creating graphical user interfaces. It works on many UNIX-like platforms, Windows,
and macOS.
• GTK has a C-based, object-oriented architecture that allows for maximum exibility and portability.
• There are bindings for many other languages, including C++, Objective-C, Guile/Scheme, Perl, Python,
JavaScript, Rust, Go, TOM, Ada95, Free Pascal, and Ei el.

Video Transcript:
Now we are looking at the one framework, GTK, it's a library for creating GUIs on Unix, Windows, macOS
and mini. Many Unix-like platforms means Windows/Linux, SCO Unix, which I don't know whether it is
continuing, Sun's systems, Sun, the company that now owns Oracle, all these many di erent Unisys, and
the original AT&T Unix, all these can work with GTK. It is C-based, the whole library is written in C, and the
way you use the calling conventions, the syntax is C. But it is object-oriented in C, and this is important,
and that's why this GTK is taken as an example of GUI toolkits. It allows for maximum exibility and
portability because it is in object-oriented fashion, but it is C-based. But it of course provides
bindings, including to C++, Objective-C, which is used in Apple systems, then Guile or Scheme, these are
object-oriented languages. Perl, which is again an object-oriented language, and it is a precursor to
Python. Python, you are more familiar with most probably, JavaScript also, then Rust, Go all these
are more modern languages, and so many. That means this is a toolkit that is versatile and multiplatform.

GTK-2

• GLib: a general-purpose utility library, not speci c to graphical user interfaces. GLib provides many
useful data types, macros, type conversions, string utilities, le utilities, a main loop abstraction, and so
on. More information available on the Glib website.
• GObject: a library that provides a type system, a collection of fundamental types including an object
type, and a signal system. More information available on the GObject website.
• GIO: a modern, easy-to-use VFS API including abstractions for les, drives, volumes, stream IO, as well
as network programming and IPC though DBus. More information available on the GIObject website.
• Cairo: Cairo is a 2D graphics library with support for multiple output devices. More information available
on the Cairo website.
• OpenGL: OpenGL is the premier environment for developing portable, interactive 2D and 3D graphics
applications. More information available on the Kronos website.
• https://docs.qtk.org/gtk4/overview.html

GTK-3
fi
fi
ff
fi
fi
ff
fi
ff
fi
fl
fl
ff
Qt-1

What is Qt?
• Qt is a cross-platform application development framework for desktop, embedded and mobile.
Supported Platforms include Linux, OS X, Windows, VxWorks, QNX, Android, iOS, BlackBerry, Sail sh
OS and others.
• Qt is not a programming language on its own. It is a framework written in C++. A preprocessor, the MOC
(Meta-Object Compiler), is used to extend the C++ language with features like signals and slots. Before
the compilation step, the MOC parses the source les written in Qt-extended C++ and generates
standard compliant C++ sources from them. Thus, the framework itself and applications/libraries using it
can be compiled by any standard compliant C++ compiler like Clang, GCC, ICC, MinGW and MSVC.

VIdeo Transcript:
Another toolkit, Qt. It is again multiplatform framework, and it is available on all these platforms on which
GTK is, but more also. Because Qt is, in fact, more exible, it is written in C++. The way it builds, that is
when you are using Qt, you are using the API, application programming interface, but it works via a
preprocessor rst, so there is a meta object compiler, and that will generate, again, C++ code, which
makes use of the Qt library e ectively. It will use those Qt extensions, and then the standard C++ code is
generated, which can then be compiled if you have the Qt binaries also with it, or they can be shared
libraries on the target platform as well, so you can write and build standalone applications or they can
be applications which are running on a graphical user interface manager, GDM, which is Qt-based, both
ways it is possible.

Qt-2
• Widgets
• With Qt, GUIs can be written directly in C++ using its Widgets module. Qt also comes with an
interactive graphical tool called Qt Designer. Which functions as a code generator for Widgets based
GUIs. Qt Designer can be used stand-alone but is also integrated into Qt Creator.

• QtQuick
• Another way to write GUIs with Qt is to use the QtQuick module. GUIs using QtQuick are written in
QML. QML is a declarative object description language that integrates Javascript for procedural
programming. QtQuick provides the necessary modules for GUI development with QML. It is possible
to write whole applications in QML only, but usually only the GUI is written In QML and the
application's backend IS implemented in C++ (see integrating QML and C++). Also Qt Creator features
an integrated QtQuick GUI designer and pro ler.

• More Modules
• Qt is far more than a GUI toolkit. It provides modules for cross-platform development in the areas of
networking, databases, OpenGL, web technologies, sensors, communications protocols (Bluetooth,
serial ports, NFC), XML and JSON processing, printing, PDF generation, and much more.
• For a full list of o cial Qt modules, see the All Modules page in the Qt documentation.
• Also, see Inglude.org for a list a of 3rd- party modules based on Qt, for use in Qt projects.

Video transcript:
Then the widgets that Qt o ers will be, again, themselves in a module, and then you can also have
compatibility with other widgets taken from other libraries as well. There is a lot of cross-platform linkages
and compatibility. Then you can also have some quick module, and there is a possibility of building
applications using QML. It's a, we can say, a meta language. QML is a declarative description
language for describing objects, that is like JavaScript. It sits on top of the C++ underlying
framework. Then there are many other such frameworks available like PyQt, Python and Qt bindings. You
can start now building Qt applications without going to the lower level of C or C++ coding. Then there is
more. That's why Qt is more versatile than GT.

Summary

• GUI Toolkits or Frameworks are like sca oldings to do masonry and plastering and painting.
• They are designed around standardised component (widget) libraries.
• GTK and Qt are C and C++ toolkits available on multiple platforms providing uniform GUI design motifs.
fi
ffi
ff
ff
ff
fi
fi
fl
fi
Angular

• Markup language
• Typescript: JavaScript with a strong type system
• Has a command line interface
• Start and scale quickly and systematically

Video Transcript:
today we will be introduced to Angular and ReactJS to JavaScript
frameworks. They are mainly for web development. Web development using
Angular, using ReactJS, JavaScript itself, some introduction to it, and then
their details. Angular is markup language which is also to some extent a
feature of JavaScript. JavaScript itself is a scripting language on top of,
say, a browser or any such web application, which can connect to services
or servers on the web. You have a browser, like say, Google Chrome or Mozilla Firefox and so on. Any of
the browsers you have. Then JavaScript will be a piece of code, you can say, written in Java-like scripting
language, with much LOAD syntax, with much LOADs typing and other things. Typing means type to
variables and so on. But it will be more or less organizing and using the code components that are already
written in Java, and that are available on the server, on the website where your browser, it's
connecting. This is like you create a client side computation piece of code, and that is actually sent like a
request or a command, which will then carry out multiple functions adaptively and interactively. This looks
complicated, but when you're using it, you don't even notice that you're using something like that. When
you're developing, then you think in the same manner as a user. It is if you try to explain to your
grandmother how to use the smartphones home screen and the di erent buttons and apps and links on
that, while talking on the phone, while continuing the call on the same phone. Once you explain, you will
know that when you want to develop such an application, when you want to develop such an
interface, what you need to put together there. Those things are available as standard components, but
you have to be able to organize them seamlessly, consistently, and without any complications or
faults. These are languages which are over and above what we call full edged or native programming
languages. Java, C, C++, Python, these are full edged and native programming languages. Then you
have JavaScript-like languages on top of that. That's why we call this a markup language. But this markup
language is slightly di erent from JavaScript. It is Typescript. It is JavaScript with a strong type system. It
gives those advantages that Java gives you, that it has a strong type system in which even if you are
careless, you cannot make a mistake because the mistake will be caught by the compiler itself. Whereas
in JavaScript, you can make big mistakes, not only that, you can leave the server system vulnerable to
attacks. Because somebody who uses the same piece of code, but for di erent purpose, can completely
hack into the system. Typescript will be giving you also type safety. JavaScript with type. It has a
command line interface, so development can be on the command line. How? You basically write
something like some of those high-level primitives or instructions, which will put together many low-level
components in some integral framework. This is how it goes. It's a markup language, and you can start
and scale quickly and systematically, how it is explained in the image that is adjoining. Most importantly,
what you get, that is you can start and scale quickly and you can also do it alone systematically. But more
importantly, you have a platform that can be easily adopted by a team with some common style. As your
apps grow, you can also transmit your style or your choices, what we can call opinions or strategy or
patterns. Many of those ideas that you have learned through the course, you can apply them with a very
uniform and very shared description of it in a team. You can have basically testable, scalable user-
interface applications which your team can easily adopt. They can easily adopt your accent in natural
language. Similarly, they can easily adopt your style of building such frameworks or building such
applications using these frameworks. That's why it is easily scalable.

Advantages of AngularJS

• Powerful command-line interface:

• The Angular CLI: implements the Angular style guide to support consistency across components while
generating boilerplate code to help you quickstart your app.
• Component libraries
• Built-in support for forms and routing
ff
fl
ff
fl
ff
Video Transcript:
Advantages are that powerful commanding interface. It implements a style guide to support
consistency, even though you can have just chaotically chosen components put them together into some
kind of a mix still, because they are the style guide, and on the command line you will typically go by some
habits of speech which are learned faster than syntax or grammar. These will automatically channel your
thinking and design thinking into some consistent patterns. But of course, the basic promise of all such
frameworks is component libraries and built-in support for forms and routing that is basically di erent
kinds of connections, protocols, and so on so that you have to think of the application part. You have to
think of the data ow of the interaction, of how the application is presented, the di erent kinds of screens,
and all that. You don't need to think of the lower level details. That is the advantage of not just
AngularJS, of all such frameworks. Basic promises are the two
promises stated below.

ReactJS

• A library for both web and native UI

• Use standard or make custom components
• Combine from multiple sources while maintaining uniformity
and integrity
• Components are JavaScript functions.
• Code and MarkUp and input are seamlessly integrated.

Video Transcript:
Here is an example. You can also have basically web and native
UI mixed, and this is a ReactJS example here. You can use
standard or you can make custom components. That is you can
make your own components, and you can mix them. Then you
can combine for multiple sources while maintaining that
uniformity and integrity. Components are themselves JavaScript
functions. You are calling those functions. When you use
components, that means you're calling those functions. But you can mix the native code and markup, and
input also. Input interaction can also help you change the way that code will be run or sequenced. Timing
sequencing also can be dependent on interactive choices, which the end user who is on the browser, what
we can say the end user of the client application can decide. You are giving an adaptive system which, in
a sense, the end user is programming. This appears fancy, but when you have seen old-type remote
control devices, for example, for your TV or for your air conditioner, you can realize that that is what we are
doing now here. The remote control is not like a device with RF transmission, but it's a keyboard and a
screen. That is your remote control for an application that is already programmed into the server you are
adapting its use. You are tuning its use. That is what these frameworks are.

Summary
• Web programming using frameworks such as Angular and React is at the highest level of code, markup
or scripting and interactive programming.
• Choosing and combining the best from all platforms, and distribution of computing resources is
possible.
• While maintaining uniformity, consistency, integrity of the interfaces.
fl
ff
ff