ASSIGNMENT 2

MAY 2021 SEMESTER

SUBJECT CODE : CSA400

SUBJECT TITLE : SOFTWARE ARCHITECTURE AND DESIGN

LEVEL : BACHELOR

STUDENT’S NAME : BINIT MANANDHAR

MATRIC NO. : C30101200015

PROGRAMME : BICT (HONS)

ACADEMIC : SHYAM ADHIKARI

FACILITATOR

LEARNING CENTRE : VIRINCHI, NEPAL

INSTRUCTIONS TO STUDENTS

1) This assignment consists of TWO (2) questions. Answer the questions.

2) Plagiarism in all forms is forbidden. Students who submit plagiarised assignment will be
penalised.

3) Your assignment will be examined based on the followings

 a complete working solution.
 ability of using methods available in the learning materials.

4) This assignment carries a 30% weightage toward final grade.

THERE ARE TWO [2] PAGES OF QUESTIONS, INCLUDING THIS PAGE.

INSTRUCTION. Answer ALL questions. [Total : 30 Marks]

Question 1

The increasing complexity of today’s systems has created a set of particular challenges that
makes it hard for software engineers to meet the continuous customer demand for higher
software quality. One of the major challenges while designing software is “Requirement’s
volatility”.

Explain THREE (3) reasons why the software engineer needs to consider the above challenges
while designing software.

[15 Marks]
ANSWER:
Nowadays, the software design phase involved from an ad-hoc, and sometime
overlooked phase, to be a necessary phase of the SDLC (software development life-cycle). The
increasing difficulties or quality of the systems has created a group of specific challenges that
basically makes engineers to satisfy the regular client's demand for the higher quality and
reliable software. There are different challenges that makes software engineers to be additional
closer with the process of design to understand, apply, design principles, quality issues, process,
and best way to overcome the these software design challenges for software engineers.
Some of the challenges for software engineers are as follows:
 Fast-changing technology,
 Design process,
 Requirements volatility,
 Distributed software development,
 Quality issue like (security, performance, usability etc),
 Efficient allocation of the human resource to development tasks,
 Limited budgets
 Unreasonable expectations and schedules
 Incorrect transformation of software production from software requirement
There are three reasons of the software engineer needs to consider the challenges while
designing software.
Requirement’s volatility:
Additions, modifications and deletions of requirements throughout the SDLC (system
development life cycle) is understood as requirements volatility. Requirement’s volatility creates
extra work process during design and coding, and it to blame for cost, time and compromises
quality of the project or system. Sometimes, ignoring requests for amendment in requirements
might responsible for the project failure because of failure to manage requirements volatility and
user rejection. And major reason for software project complexity is the customer's constant
change requirements. When well-designed perfectly then software will be updated, modified or
extend simply however if designed of software is poor, then modifying updating of software
product become overwhelming, complex and result in all form of the problems. This same taint
that creates software, so desirable is what makes it conjointly complex. In this case, engineers
need to be more effort within the requirements phase and to confirm that requirements are
consistent and complete. It's challenging for the software engineering as a result of they're going
to be impact system in future or already going development efforts, emerging new technology
and client requirements are incessantly changing. Therefore, requirements volatility forces
software designer to create designs that has got to be give answer to issues at a given state and
conjointly anticipating changes and accommodating them in minimum effort. For this, software
designer ought to be best design principles and strong understanding regarding the software
design and develop to manage challenges and change requirements in software development.

There are the two main factors of requirements volatility:

Business Environment changes:
They are, for instance, management changes, technological factors, government regulations,
organization policy, market competition, restrictions, legal factors, funding sources and business
laws.
Development environment changes:
They are, for instance, technological desires and evolving user, new technology, incorporation of
price upgrades; resolve requirement conflicts, missing requirements). Requirement errors,
missing members of team project.
Causes of requirements volatility:
Requirement volatility after considering the business and development environment changes it
concluded that there are some cause for the requirements volatility. The main causes of the
requirements volatility are:
1. People errors:
This is error that arises when developer or have less information on method execution, domain
knowledge and generally it may be return from the communication gap between the
stakeholders. Mainly it accompany the poor communication or participation of developer team
and management’s teams. Some of them are as follows:
 Poor participation between the management team and development team.
 Users don’t really know what they need and have unreasonable timelines.
 Users don’t really know what they need and have unreasonable timelines.
 Less understanding domain knowledge, unstructured process execution.
2. Process errors:
During a design and development stage dashing and bad analysis of requirements could rise
requirements volatility. Bad management process, requirements amendment and inadequate
technique of achieving objectives throughout the project development can rise the requirements
volatility. There are condition that is cause requirements volatility.
 Poor management process.
 Requirement change and inadequate method of achieving objectives during the project.
 Bad analysis and rush during requirements analysis, using old methodology and process.
3. Documentation errors
During requirement specification software engineer or requirement analyst ought to be create all
documentation as well as system work flow and modules. If there's some little error or mistake
it'll have an effect on the whole project. Throughout requirements specification software
engineers need to be verify and validate the all user requirements. Because of lack of proper
verification and validation may arise the system requirements volatile? It conjointly occur of team
may don't understand the use of standards or policy of the user' organization.

Question 2

There are TWO (2) categories of interaction-oriented architecture, the Presentation-Abstraction-

Control (PAC) and the Model-View-Controller (MVC).
 Figure 1

Explain the MVC architecture as illustrated in Figure 1.

[15 Marks]

ANSWER:

The major objective of the interaction-oriented architecture is to differentiate the interaction of

the user from the business data processing and data abstraction. It divided into the 3 major
partition.

1. Data module:

This data model provides the business logic and data abstraction.

2. Control model:

Control model identifies the system configuration actions and flow of the control.

3. View presentation module:

It provides the user interface visual or audio output and input user interface.

There are two major variety of the interaction-oriented architecture they're Presentation-

Abstraction-Control (PAC) and Model-view-controller (MVC).a

Presentation-Abstraction-Control (PAC):
In presentation-Abstraction-Control, the system is organized into a hierarchy f the
different cooperating agent. PAC was come from the model-view-controller (MVC) to support
the application demand of various multiple agents additionally to interactive requirements. All
agents has three elements:
The abstraction component: Processes and retrieves and also the data.
The presentation component: Audio and visual presentation of data.
The component: These elements handles the task like communication between two
components and flow of control.
The PAC and MVC architecture are similar in sense that presentation module is like view
module of MVC. The controller module feels like the MVC controller module and, The abstract
module looks like the MVC model module, however they're completely different within their
control flow and organization. There's no direct connection between presentation component
and abstraction component in every agent. Block diagram for a single agent in the PAC design
is shown in the following figure.

Both PAC and MVC have completely different flow control system. PAC (presentation-view-
controller) is agent based mostly hierarchical architecture and MVC does not have hierarchical
structure clear as compare to PAC. MODEL-VIEW-CONTROLLER (MVC): Model view
Controller (MVC) have their interconnected elements and that they facilitate within the
differentiating the internal representations of information from the knowledge accepted for
presented from the user.

Model:
The main central component of the model view controller is model and model manages
and maintain the logic, constraints and data of an application. The model contains data
components, which manage the application logic and data for user interface.
 When there has been modification or modify in its state, the model offers notification to
its associated controller to update or change the available set of commands and views to
show the output data.
  It’s an independent interface for user and model catch the behavior of application
problems or problem domain.
View:
View is illustration of knowledge and data in computer program in several sort of
graphical kind, cherish char diagrams. View consists of various type presentation
elements which offer the visual representation of data in user interface.
 Completely different multiple views of constant data and information are possible, such
as a tabular view for accountants and a bar chart for management.
 Views capture the input from the user and send request information from their connected
model with the help of controller and generate the output in user interface using controller
and model data.
Controller:
Controller accept input by the computer and converts it to commands for the view or model.
Controller consists of components of input process and these component manage the input from
the users by modifying the model.
 Controller send commands to the model according to the view to change or update the
model’s state and to its associated view to vary the view’s presentation of the model.
 Controller work as the interface between the views, models and the input field.

MVC – I
Easy version of MVC architecture is MVC-I. In MVC-I, system was divided into the two
subsystems. They’re:
 Model
It copes with all core functionality and data It notifies the Controller-View module
of any data changes within the Model module.

o Controller/View
It handles input and output process and their user interfaces, and it registers with
(attaches to) data module.
ARCHITECTURE: MVC-I

The model send notification to controller-view module of any data modify or changes so
as that any graphics data display are changed accordingly. The controller also take the action
with data changes.

In an exceeding system the association between model and controller-view may be

designed in a form of pattern of subscribe-notify whereby the controller-view subscribe model,
and it sends notification to controller-view of any updates or changes. The Controller-View can
be referred to as observer of the information within the Model module. The view and controller
are combined and act as input and output at user interface and the domain services, data,
information offer by model.

Allow us to think about one simple GUI (Graphical user interface) example designed in
MVC-I. During this, design view has a GUI interface with two text fields. The system shows the
easy form and user enters a brand-new two number with some bottom. And controller capture
the input number from view and send to the model as command. Models have all logic and data
manipulation, and it sums the amount and save it. At the moment, controller send it back to the
read and show the summation of the amount in user interface.

END OF ASSIGNMENT QUESTIONS