1 (a) The principle of component independence means that it ought to be possible to replace one

component with another that is implemented in a completely different way. Using an example,
explain how such component replacement could have undesired consequences and may lead to
system failure.

Component Independence is an essential principle that allows for the creation of component based
systems that ensures scalability, flexibility and maintainability, among other characteristics. It allows
developers to focus on each and every module independently and if one component of the system fails,
it might not affect the whole system. It also promotes for each and every module to be updated
independent from other module.

Replacement of one component module is desirable as it allows for the system to get new feature and
more competitive. However, it is not always the case and such practice may lead to undesirable
outcome and possible system failure. Some of the issues that might arise are:

i. Compatibility with legacy systems – Sometimes newer module might have new features but
may not be able to integrate with legacy systems. This usually is due to differences in
interfacing with the legacy system in which the component can end up becoming a blocker.

ii. Compatibility with embedded systems – Challenges might arise on replacing system
component for embedded system in which they may fail to communicate affecting the
functionality of the whole system. They might end up requiring upgrade to hardware
components of the system thereby likely to increase the cost of the whole operation.

iii. Compatibility with regulatory requirements – In financial systems, upgrading components

will likely come with enhanced services to financial users, however they might not be able to
be implemented due to regulatory measures that conform to old modules of the system.

A real life situation where component replacement resulted in system failure is the case of Boeing
Company. In 2011, Boeing introduced a new version of their 737 airplane which have advanced
features, among them the MCAS system. The system was a new component replacement that was
meant to automate some of the operations of the pilots. However, it relied on data that was provided
by sensor prone to providing wrong data and deactivation of the system could also switch off other
critical components making the airplane very risky to fly. The system resulted in two fatal crashed before
they were grounded. According to [1] it was elicited that avionic systems should not be reduced their
automation and increase independabilty of each other so that failures will not affect other components
of the aircraft.
(b) Explain why it is difficult to validate a reusable component without the component source code. In
what ways would a formal component specification simplify the problems of validation?

Validation of reusable would be easy if they are provided with their source code for reference. However,
that is not always the case as source code is not always available and disclosed outside of the
developers. It is difficult to elicit the specific of a software structure apart from its general context [2]. It
will be difficult to know without sufficient information all components associated with a software object
and their dependability if we are to reuse it. [2]

Without source code, only viable validation option is black box testing where tester have to heavily
analyze the input into the component and the output. The software documentation is also helpful in the
validation as it is able to bring out specifics of the system and possible dependency for a more accurate
testing.

It is also difficult to debug if the component fails internally. Testers will have to assume the component
does not have fail points. This is a big risk as it will take long to address issues to their root and there is
likely to remain a number of unresolved cases. All this makes validation difficult.

A formal component specification can simplify the process through the following:

i. It elicits functional requirements which outlines the expected behavior of the component.
ii. Integration specification is provided which specifies how the component communicates with
others systems thus reducing integration complexity.
iii. Performance Metrics will be documented which details on throughput and response times.
iv. Component limitations are also documented which helps validating usability and efficiency
of the component.

With a formal component specification, validation complexity is reduced and testers able to make a
accurate validation of the component
(c) It has been suggested that an independent certification authority should be established. Vendors
would submit their components to this authority, which would validate that the component was
trustworthy. What would be the advantages and disadvantages of such a certification authority?

In software engineering, establishment of an independent authority on component certification would

be beneficial in maintaining software standards as well as trust from potential clients. This has its own
merits and shortcomings.

Advantages:

1. Ensures fair competition – Software companies are given a similar certification platform on the
same level as other institutions which ensures they hold outmost standards to ensure
competitiveness of their products.
2. Trust by consumers – Such a body will be beneficial for software organizations in that potential
clients will have confidence in their products since they are certified.
3. Standardization – Software components will have to follow streamlined standards, meeting
minimum expectations. This results in components that exudes quality, reliability and secure.
4. Reduction in risks – A certification board ensures regulatory compliance which results in lower
risks associated with componentization and makes it easier to identify and mitigate risks that
might arise in using the components.

Disadvantages:

1. Certification can be costly – It is possible that smaller software organization might not be able to
meet the cost to certify will result in them having uncertified products in turn impacting their
businesses.
2. Administration Complexity – Running the certification organization might incur processes
affecting costs, maintenance. Defining the charter regulation certification process can be
ambiguous, one sided and possibly affecting time sensitive projects.
3. Possibility of software compromises – Vendors might resort to creating less qualified software as
they focus on meeting certification requirement rather than a high quality software.
4. Certification bias – Since software products have a large variety and application spectrum, it is
difficult to define certification process and standards. This in turn might turn into certification
bias to which some organizations might not agree too. Multiple certification bodies might be
established which risk in watering down the initial goal for the whole industry.
3. (a) What is the fundamental difference between a fat-client and a thin-client approach to client–
server systems architectures?

Fat client system architecture, is a client server architecture variant where resources of the system are
deployed locally rather than being distributed over a network [4]. In this architecture the client side
handles its processing and storage functions enabling them to execute task independent resources hosted
on a server. They however can still work in combination with a server. Such an architecture is beneficial
when work needs to continue without a network connection as well as enhanced performance for end
users. The drawbacks however come in costs incurred in managing the client devices and potential
inconsistences working offline.

Thin clients, however, has an architecture where the client has minimal processing it can do, with other
computing resources distributed over a network. The server side will be heavily used to most
computational storage whilst the client focuses more on input which it then passes to the server and
output operations as well as interfacing with end users. Thin clients are more secure, scalable ad have
reduced hardware requirements to the whole system.

b) Giving reasons for your answer, suggest two important types of applications where you would
not recommend the use of service-oriented architecture.

Service oriented architecture (SOA) in software architecture approach where different components of a
system are provisioned as separate services which have the ability to communicate with each other over a
network. Each service component is independent from the others with its own implementation and
communicate with others using standard protocol. Service oriented architecture is scalable, flexible and
maintainable as well as enhanced interoperability between components.

As desirable as the architecture is, it is not always not always recommendable not be used in some
scenarios. These include:

1. Embedded Systems – embedded system usually have limited processing capabilities.

Implementation with SOA increases complexity due to need for communication and handling
between services in a system where resources are constrained. Communication services
introduces communication latency which might not be desirable for systems that time constrains
in completing tasks. SOA in embedded systems might hinder optimal performance when network
is not available.
2. Small Scale Monolithic Systems - Small scale systems are designed for them to be simple with
easier deployment and maintenance. Using SOA bring complexity to such systems in managing
multiple services, networking and distribution of these services. This in turn defeat the simplicity
the system intended to have, driving up development efforts needed in decomposing the system
and maintenance costs.
(c) Suggest how you could use aspects to simplify the debugging of programs.

Aspects are part of Aspect oriented programming, which are features of a system which are liked to other
module or functions but these features do not constitute the basic functionality of the system.
It provides ability to conduct debugging without altering core functional code base [5]. One is able to
trace the program flows, eliminating need for debugging packages. The source code can be broken into
segments which are easier to trace thus reducing simplicity and helping isolate errors. Aspects in
programming could be logging security, transaction management or error handling.
4. (a) Explain why incremental development is the most effective approach for developing business
software systems. Why is this model less appropriate for real-time systems engineering?

Incremental development is a software development process where a system is built through deploying
small modules in an incremental manner with each module representing a functional part of the system.
Each incremental module is designed, developed, tested independently and then integrated into the overall
system [6]. The development process allows a software to be built through continuous improvement
emphasizing on stakeholder feedback and changing requirements [7], making it ideal in developing
business software systems.

With incremental development, a software system can be delivered early and incremental components are
delivered with outmost efficiency and businesses can begin using the system even though it is not yet
complete.

With incremental development there is room for flexibility. Small manageable increments can be adapted
for changing business requirements as well as feedback from stakeholder without overshooting costs.

All stakeholders have a more precise and improved collaboration on the requirements. This ensures the
system conforms with the business needs. Regular interaction between all stakeholders ensures better
acceptance of the system.

With incremental development, potential risks are identified early and they never grow much larger to
cause major failures. In each increment corrections can be done easily. This reduces over risks associated
with large systems like those for business software systems.

(b) You are a software engineering manager and your team proposes that model-driven
engineering should be used to develop a new system. What factors should you take into account
when deciding whether or not to introduce this new approach to software development?

Model driven engineering is a software development process model which uses domain models to build
software system rather than traditional code. According to [8], the process involves building and using
abstraction of processes with repetitive tasks being automated. The process model aims to have a software
system of better productivity, high maintainability and high quality. Determining feasibility of using
model-driven engineering to develop a new system, there are factors that needs to be considered:
1. Project complexity and size – Model Driven Engineering can be beneficial for large system that
constitute complex processes. With the ability to provide higher level abstraction, there is better
management if intricate systems [9] It also helps to maintain consistence across different
modules.
2. Project infrastructure and resources – These are important in determining how much of the
infrastructure and resources are available to support the development model.
3. Expertise of the team – It is crucial to know if they team have knowhow and necessary skills
required to develop a successful project using model driven engineering.
4. Project costs – determination of the budget allocation for the project over the project timeline.
5. Risk Management – Identify possible risks that might arise with adoption of model driven
engineering and conduct risk analysis to determine if to adopt the model or not.
6. Integration with existing process – determine whether model driven engineering can be adopted
into what the organization has been doing previously, and the impact of change to the new model.
[1]
[Link]

[2] [Link]

[3] [Link]

[4] [Link]

[5] Filman, R. E., Tarr, P., Asoiso, D., & Cannon, S. (2000). Aspect-oriented programming: A catalog of
benefits and challenges. IEEE Computer, 33(5), 68-72.

[6]
[Link]
story

[7]
[Link]
Software_Systems

[8] [Link]

[9] France, R., & Rumpe, B. (2007). Model-driven Development of Complex Software: A
Research Roadmap. Future of Software Engineering (FOSE '07). IEEE Computer Society, 37-
54.