1a.
You are commissioned by an enterprise, whose core business is the provision of
computationally intensive processing of data for organizations in the West African sub-region,
to design and implement a data visualization system. Write a report to incorporate the following:
(i) Suggestion of an architecture for the proposed system with justifications; [5 marks]
(ii) Design issues envisaged; [5 marks]
(iii) Description of procedural and message-based interactions in the proposed system and the
mechanisms that allow these interactions.
**Report on Designing a Data Visualization System**
For the proposed data visualization system, a microservices architecture is recommended. This
architecture divides the system into smaller, independently deployable services, each
responsible for a specific function. Here's a breakdown of the components:
- **Data Ingestion Service**: Responsible for collecting and ingesting data from various
sources, such as databases, APIs, or streaming platforms. It ensures data integrity and
consistency before forwarding it to the processing layer.
- **Data Processing Service**: This service handles the computationally intensive processing of
data. It performs tasks like data cleaning, transformation, aggregation, and analysis to prepare
the data for visualization.
- **Visualization Service**: The core component responsible for generating visual
representations of the processed data. It offers a variety of visualization options, including
charts, graphs, dashboards, and reports, catering to different user requirements.
- **User Management and Authentication Service**: Handles user authentication,
authorization, and management functionalities. It ensures secure access to the system and
provides personalized experiences for users.
- **Data Storage Service**: Stores both raw and processed data efficiently. It may utilize a
combination of relational and non-relational databases, data lakes, or cloud storage solutions
to accommodate varying data types and volumes.
**Justifications:**
- **Scalability**: Microservices architecture offers scalability by allowing individual services to
scale independently based on demand. This is crucial for handling computationally intensive
processing requirements.
- **Flexibility**: Each microservice can be developed, deployed, and updated independently,
providing flexibility in technology stack, deployment environment, and development lifecycle.
- **Resilience**: Decoupling services minimizes the impact of failures or changes in one service
on the entire system, enhancing fault tolerance and resilience.
**2. Design Issues Envisaged:*
- **Data Integration**: Integrating data from diverse sources while ensuring consistency and
quality may pose challenges.
- **Performance Optimization**: Efficient processing of large volumes of data and generating
real-time or near-real-time visualizations requires careful optimization.
- **User Experience**: Designing intuitive and responsive user interfaces that cater to different
user roles and preferences
- **Security**: Implementing robust security measures to protect sensitive data and prevent
unauthorized access or data breaches.
**3. Procedural and Message-Based Interactions:*
- **Procedural Interaction**: Users interact with the system by performing actions such as
querying data, configuring visualization settings, or generating reports through the user
interface. These interactions trigger backend processes, such as data retrieval, processing, and
visualization generation, following predefined procedural workflows.
- **Message-Based Interaction**: Inter-service communication within the microservices
architecture relies on message-based interactions. Services communicate asynchronously via
messages exchanged through a message broker or middleware. For example, the Data Ingestion
Service publishes data ingestion requests to a message queue, which is consumed by the Data
Processing Service for further processing. This decoupled communication ensures scalability,
fault tolerance, and loose coupling between services.
1b. Using an example of a remote procedure call, explain how middleware coordinates the
interaction of computers in a distributed system.
The client initiates an RPC request to execute a remote procedure. The middleware intercepts
the request, serving as an intermediary between client and server. Middleware identifies the
server hosting the requested procedure. The request is sent to the server efficiently and reliably
over the network. The server's middleware processes the request, extracting necessary
information. The server executes the procedure based on the request. The server encapsulates
the result and sends it back to the client via middleware. The client's middleware forwards the
response to the application for processing.
2a. Explain why design conflicts might arise when designing an architecture for which both
availability and security requirements are the most important non-functional requirements.
Availability requires that the system be accessible and available to users, while security
requires that the system be protected from unauthorized access. This can lead to a conflict
between making the system available and secure, as it may be difficult to find a balance
between the two. For example, if the security measures are too strict, it may limit the availability
of the system, while if the security measures are too lax, it may leave the system vulnerable to
attack.
2b. You have been contracted as a consultant to design a system that requires strong
authentication and authorization. The system must be designed so that communication
between parts of the system cannot be intercepted and read by an attacker. Suggest the most
appropriate client-server architecture for this system and propose how functionality should be
distributed between the client and the server systems.
- Three tier architecture is the most appropriate. This architecture separates the system
into 3 layers:
1. Presentation layer (client): this handles user interface and interaction, capturing
user credentials and securely transmits them to the server for validation.
2. Application layer (server): this contains the core business logic as well as the
authentication and authorization processes. It verifies user credentials, determines
access rights and ensures secure communication using encryption.
3. Data Access Layer (server): here sensitive data is stored securely in encrypted
databases. User-specific data is retrieved based on authorized requests then
necessary processing or validation is performed before results are returned to the
client.
- Reasons for choosing thee tier architecture are:
1. It allows each layer to be scaled and maintained independently
2. It reduces the attack surface and mitigates unauthorized access or data breaches
3. It facilitates code organization, maintenance and updates.
4. It accommodates diverse user interfaces and interaction patterns
3a. Explain why you normally use several architectural patterns when designing the architecture
of a large system.
When designing a system you would normally use several architectural patterns when designing
the architecture of a large system because you may need different architectures for different
components. For example, a large system may be a distributed system and the overall
architecture may reflect that but one component may be best implemented using a client server
pattern and another component structured as a repository. In designing a large system it is most
useful to know how the components that make up the large system are going to communicate.
Once you know how the components are going to communicate it is easier to design the
components themselves and properly structure the entire system to maximize the benefits of
each decision and minimize the drawbacks.
3b. The Mental Health Care - Patient Management System is intended for use in clinics to
manage the details of patients who are consulting specialist doctors about mental health
problems. It makes use of a centralized database of patient information but has also been
designed to run on a PC, so that it may be accessed and used from sites that do not have secure
network connectivity. When the local systems have secure network access, they use patient
information in the database but they can download and use local copies of patient records
when they are disconnected. The system may interact and exchange data with other clinical
information system.
Suggest an appropriate architectural model for this system. Give a generic architecture and
provide an instantiation with this system. Discuss the various components of the architecture
and list it merits and demerits
**Generic Architecture:**
The most suitable architectural model for the Mental Health Care - atient Management System
is a hybrid of the Client-Server and Distributed architecture models.
**Components of the Architecture:**
1. **Centralized Database Server:** This component hosts the centralized database of patient
information. It stores all patient records securely and ensures data integrity and consistency.
2. **PC-Based Client Application:** The client application runs on local PCs in clinics and
allows users to access and manage patient information. It provides functionality for querying,
updating, and adding patient records.
3. **Offline Data Synchronization Module:** This module enables the client application to
synchronize patient data with the centralized database when the local system has secure
network connectivity. It ensures that local copies of patient records are updated with the latest
information from the centralized database.
4. **Local Database:** When disconnected from the centralized database, the client
application utilizes a local database to store patient records. This ensures accessibility to
patient information even in offline mode.
5. **Clinical Information System Interface:** This component facilitates interaction and data
exchange with other clinical information systems. It allows seamless integration with external
systems for sharing patient information and interoperability.
**Merits:**
- **Accessibility:** The hybrid architecture ensures that the system can be accessed and used
from sites without secure network connectivity, enhancing accessibility and usability in diverse
clinical settings.
- **Data Security:** Patient information is securely stored in the centralized database and
encrypted during transmission between the client application and the database server, ensuring
data confidentiality and integrity.
- **Offline Capability:** The ability to download and use local copies of patient records ensures
uninterrupted access to critical patient information, even in offline mode.
- **Scalability:** The centralized database architecture supports scalability, allowing the
system to accommodate growing volumes of patient data and increasing user demands.
**Demerits:**
- **Complexity:** Implementing and maintaining a hybrid architecture involves managing both
centralized and distributed components, increasing system complexity and administration
overhead.
- **Synchronization Challenges:** Ensuring data consistency and synchronization between the
centralized database and local copies can be challenging, especially in environments with
intermittent network connectivity.
- **Dependency on Local Infrastructure:** The system's offline functionality relies on local
infrastructure and resources, such as local databases, which may introduce dependencies and
potential points of failure.
**Instantiation with the Mental Health Care - Patient Management System:**
In this instantiation, the centralized database server hosts patient information, while the PC-
based client application allows clinics to access and manage patient records. The offline data
synchronization module enables synchronization of patient data between the client application
and the centralized database, ensuring data consistency. Additionally, the system interfaces
with other clinical information systems to exchange data and facilitate interoperability.
4a. Discuss the concept of object-oriented design and its groups of activities
Object-oriented design (OOD) is a software design approach that emphasizes modeling
software systems as collections of interacting objects, each responsible for specific
functionalities and data manipulation. It is based on the principles of object-oriented
programming (OOP) and involves designing software systems by defining classes, objects, and
their relationships
The process of developing a system design from concept to detailed object-oriented design
involves several steps:
- Understanding Context and External Interactions: Define the system's context and
external interactions to understand its requirements and boundaries.
- System Architecture Design: Design the overall architecture of the system, including its
components, modules, and high-level interactions.
- Identifying Principal Objects: Identify the main objects that will form the core
components of the system.
- Developing Design Models: Create design models, such as class diagrams, sequence
diagrams, and state diagrams, to visualize the structure and behavior of the system.
- Specifying Interfaces: Define clear interfaces for communication between different
components and modules of the system, ensuring interoperability and modularity.
4b. Illustrate the concepts of inheritance and polymorphism with simple programming
examples
Sure, let's illustrate the concepts of inheritance and polymorphism with some simple Python
examples:
1. **Inheritance:**
Inheritance allows a class (subclass) to inherit attributes and methods from another class
(superclass). This promotes code reuse and facilitates the creation of specialized classes.
Here's an example:
class Animal:
def __init__(self, name):
self.name = name
def sound(self):
pass
class Dog(Animal):
def sound(self):
return "Woof!"
class Cat(Animal):
def sound(self):
return "Meow!"
In this example, we have a superclass `Animal` with a method `sound()`, and subclasses
`Dog` and `Cat` that inherit from `Animal`. Each subclass provides its implementation of the
`sound()` method.
2. **Polymorphism:**
Polymorphism allows objects of different classes to be treated as objects of a common
superclass. This allows for flexibility in method calls and promotes code extensibility. Here's an
example:
class Animal:
def sound(self):
pass
class Dog(Animal):
def sound(self):
return "Woof!"
class Cat(Animal):
def sound(self):
return "Meow!"
def make_sound(animal):
print(animal.sound())
In this example, the `make_sound()` function takes an `Animal` object as an argument and
calls its `sound()` method. Even though `dog` and `cat` are instances of different classes
(`Dog` and `Cat`), they can both be passed to `make_sound()` because they inherit from the
common superclass `Animal`. This demonstrates polymorphism, where objects of different
types are treated uniformly through a common interface.
4c. Identify possible objects in the system below and develop an object-oriented design for it.
You may make any reasonable assumptions about the system when developing the design.
A filling station is to be set up for fully automated operation. Customers swipe their debit cards
through a reaer connected to the pump; the card is verified by communication with the
customer's bank, and a fuel limit is established. The customer may then take the fuel required.
When fuel delivery is complete and the pump hose is returned to its holster, the customer's
card is debited with the cost of fuel taken. The card is returned after debiting. If the card is
invalid, the pump returns it before fuel is dispensed. [
Here operations and attributes are associated with each object in the fuel tank system and
provided a partial description of the system controller.
Object Attributes Operations
fuel_dispensed
active
Price
deactivate
Pump Hose_status
deliver_fuel
Trigger_status
stick_update
Fuel_type
Card_number
read_card
Card_type
Card_reader check_status
Card_status
print_receipt
Credit_limit
add_fuel
Fuel_tank current_fuel_level
Remive_fuel
number_dialled send_card_number
Communication_system
Credit_limit return_card_status
Card_number
Card_type
System_controller Max_delivery
Price_table
Fuel_delivered
lookup
Price_table fuel_prices
Amend_price
A UML state diagram showing the possible state changes in the filling station system is:
The filling station system performs the actions in various states as shown:
1. When the swipe card state is completed, the card details are verified in the verifications
state.
2. If the credentials are valid then the fuel limit is established and the fuel filling state is
processed.
3. After the fuel filling state, the returning pump state occurs and the card is debited.
4. When the card is debited or if the credentials are not matched, the card returning state
occurs.
5a. Describe the principle of information hiding as it applles to software design.
The principle of information hiding implies that modules only share information with each other
on a "need to know" basis to achieve some specific software function. Hiding enforces the
procedural constraints to both the module procedural detail and any data structures local to
the module.
5b. State the sallent issues in Object-Oriented Analysis
Object-Oriented Analysis (OOA) involves identifying and specifying objects, classes, attributes,
methods, and relationships in a system to understand its requirements and structure. Some
salient issues in Object-Oriented Analysis include:
1. **Identification of Objects and Classes:** Identifying the right objects and classes is crucial
for a successful OOA. This involves understanding the problem domain, user requirements, and
system functionalities.
2. **Defining Attributes and Methods:** Once objects and classes are identified, their attributes
(properties) and methods (behaviors) need to be defined accurately to represent the system's
data and functionality effectively.
3. **Modeling Relationships:** Modeling relationships between objects and classes, such as
inheritance, composition, and association, is essential for capturing the structure and behavior
of the system accurately.
4. **Encapsulation and Abstraction:** Encapsulation ensures that the internal state of objects
is hidden and can only be accessed through well-defined interfaces, enhancing data security
and integrity. Abstraction involves representing complex systems in simplified forms, focusing
on essential details while hiding unnecessary complexities.
5. **Analysis of Behavior:** Analyzing the behavior of objects and classes involves
understanding how they interact with each other and respond to external stimuli. Use cases,
scenarios, and sequence diagrams are often used to capture and analyze system behavior.
6. **Use of Modeling Tools:** Utilizing appropriate modeling tools and techniques, such as
Unified Modeling Language (UML), helps in visualizing, documenting, and communicating the
OOA artifacts effectively.
7. **Iterative and Incremental Approach:** OOA is an iterative and incremental process,
allowing for continuous refinement and improvement of the analysis artifacts based on
feedback from stakeholders and evolving requirements.
8. **Handling Complexity:** Dealing with the complexity of large and complex systems requires
careful attention to detail, proper decomposition of the system into manageable components,
and the use of modular design principles.
9. **Validation and Verification:** Validating and verifying the OOA artifacts against the user
requirements and system specifications is essential to ensure that the analysis accurately
represents the intended system behavior and functionality.
10. **Scalability and Reusability:** Designing the OOA artifacts in a scalable and reusable
manner enables the system to accommodate future changes and extensions effectively,
promoting maintainability and adaptability over time.
5c. Write short notes on:
(1) Coupling; [2 marks]
(ii) Abstraction; [2 marks]
(III) Overloading; [2 marks]
(iv) Modularity. [2 marks
(1) Coupling:
Coupling refers to the degree of interdependence between modules or components in a
system. It measures how closely connected or reliant one module is on another. Low coupling
implies minimal impact of changes in one module on others, enhancing modularity and
flexibility.
(ii) Abstraction:
Abstraction simplifies complex systems by focusing on essential aspects while ignoring
irrelevant details. It enables developers to represent real-world entities as objects or concepts
in software systems, promoting modularity, encapsulation, and code readability.
(III) Overloading:
Overloading allows multiple functions/methods with the same name but different parameter
lists to coexist within the same scope. It provides flexibility and convenience in function/method
naming and usage, improving code readability and maintainability.
(iv) Modularity:
Modularity breaks down complex systems into smaller, independent modules or components,
each responsible for a specific functionality. It promotes code organization, reusability, and
maintainability by facilitating encapsulation, information hiding, and separation of concerns.
6a. Suggest how you could use aspects to simplify the debugging of programs.
1. Logging: Implement logging functionality as an aspect to capture detailed information about
the program's execution, such as method calls, parameter values, and intermediate results. By
separating logging concerns into an aspect, developers can easily enable or disable logging
across different parts of the codebase without modifying the core logic.
2. Exception Handling: Define exception handling logic as an aspect to centralize error handling
and recovery strategies. By encapsulating exception-related concerns, developers can focus on
writing clean, readable code for the main functionality without cluttering it with error-handling
logic.
3. Profiling: Create profiling aspects to gather performance metrics, such as execution time,
memory usage, and method invocation counts. By abstracting profiling concerns into aspects,
developers can analyze and optimize code performance without altering the main
implementation.
4. Tracing: Develop tracing aspects to track the flow of execution through the program, including
method entry and exit points. By modularizing tracing functionality, developers can quickly
identify the sequence of operations during program execution and pinpoint potential issues or
bottlenecks.
5. Debugging Hooks: Introduce debugging hooks as aspects to inject breakpoints or custom
debugging logic into the code at specific join points. This allows developers to dynamically
insert debugging functionality without modifying the original source code, facilitating easier
debugging and troubleshooting.
By employing aspects to encapsulate debugging concerns, developers can maintain a clean
separation between debugging code and the core functionality of the program. This not only
simplifies the debugging process but also enhances code readability, maintainability, and
reusability.
6b. Summarize what is meant by scattering and tangling. Using simple examples, explain why
tangling and scattering can cause problems when system requirements change
1. Tangling: Tangling occurs when different functionalities or concerns become intermixed
within a module or component. This means that code related to one aspect of the system is
tangled or mixed together with code related to other aspects. As a result, it becomes difficult to
understand, maintain, and modify the code because related functionalities are not logically
separated.
2. Scattering: Scattering happens when related functionalities or data are spread across
multiple modules or components instead of being grouped together. This leads to a situation
where code related to a single concern or functionality is scattered across different parts of the
system. As a consequence, making changes to a particular functionality may require modifying
code in several different locations, increasing complexity and reducing maintainability.
Example:
Consider a web application is initially structured with separate modules for user authentication,
profile management, and notification sending
If tangling occurs, code related to different functionalities becomes mixed within the same
modules. For instance, authentication logic may become intertwined with notification sending
code. This complicates maintenance and modification, especially when system requirements
change, such as adding two-factor authentication.
On the other hand, scattering may occur, where related functionalities are spread across
different modules. For example, authentication logic may be in one module, while profile
management and notification sending logic are in separate modules. When system
requirements change, such as updating user profile fields, developers must locate and modify
scattered code, increasing complexity and potential errors.
6c. Highlight the difference between a join point and a pointcut. Explain how these facilitate the
weaving of code into a program to handle cross-cutting concerns.
1. **Join Point**:
- A join point is a specific point in the execution of a program where additional behavior can be
introduced by an aspect.
2. **Pointcut**:
- A pointcut, on the other hand, defines a set of joint points in the program's execution flow
based on specific criteria or conditions. Pointcuts provide a way to express patterns or rules for
identifying joint points, enabling developers to modularize and manage cross-cutting concerns
effectively.
During the weaving process, aspect code is integrated into the program at defined joint points
and according to specified pointcuts. This integration occurs either at the bytecode or source
code level. Weaving ensures that the aspect behavior is applied only where specified by the
pointcut definitions, thus effectively integrating cross-cutting concerns into the application's
logic.
