UOPeople Software Engineering 1

Question 1

What is software engineering?

Answer 1

Software engineering is a discipline for solving business problems by designing and developing software-based systems. As with any engineering activity, a software engineer starts with problem definition and applies tools of the trade to
obtain a problem solution.

The purpose of software engineering is to develop software-based systems that let customers
achieve business goals

Question 2

Why is SE difficult?

Answer 2

Expertise

If you are a civil engineer building bridges then all you need to know is about bridges. Unlike
this, if you are developing software you need to know about software domain (because that is
what you are building) and you need to know about the problem domain (because that is what
you are building a solution for).

formality

A further problem is that software is a formal domain, where the inputs and goal states are well defined. Unlike software, the real world is informal with ill-defined inputs and goal states.

Change

software engineering is primarily about modeling the physical world by finding good abstractions, but the complexity of the physical world, being infinitely complex, cannot be captured in its entirety by our abstractions, therefore our abstractions are only approximations of the physical world.

The informal domain of reality tends to increase disorder. Whatever order was captured by our abstractions, tends to get dispersed into disorder. Our (approximate) abstractions necessarily become invalid with passing time and we need to start afresh.

Question 3

What are the most basic steps of the SE process?

Answer 3

Plan
Design
Implement
Evaluate

Question 4

Waterfall process

Answer 4

Requirements
Design
Implementation
Testing
Operation and Maintainance

Question 5

SLDC: Waterfall

Answer 5

Requirements
Design
Implementation
Testing
Operation and Maintainance

Question 6

Advantages and disadvantages of the waterfall approach?

Answer 6

Advantages
.
There is a psychological attraction to the waterfall model: it is a linear process that leads to a
conclusion by following a defined sequence of steps

Disadvantages

Given that Software design is unlike the design and development of other products, a process that follows a linear order of understanding the problem, designing a solution, implementing and deploying the solution, does not produce best results.

Question 7

Difference between Software and other types of products?

Answer 7

Unlike most other products, software is intangible and hard to visualize. Most people experience software through what it does: what inputs it takes and what it generates as
outputs

Software is probably the most complex artifact—a large software product consists of so many bits and pieces as well as their relationships, every single one having an important role—one flipped bit can change the entire sense of a program

Software is probably the most flexible artifact—it can be easily and radically modified at any stage of the development process, so it can quickly respond to changes in customer requirements (or, at least it is so perceived)

Question 8

Architecture: Client/Server

Answer 8

Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.

Question 9

Architecture: Component-Based Architecture

Answer 9

Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

Question 10

Architecture: Domain-Driven Design

Answer 10

An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.

Question 11

Architecture: Layered Architecture

Answer 11

Partitions the concerns of the application into stacked groups (layers).

Question 12

Architecture: Message Bus

Answer 12

An architecture style that prescribes the use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.

Question 13

Architecture: N-Tier / 3 - Tier

Answer 13

Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.

Question 14

Architecture: Object-Orientated

Answer 14

A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.

Question 15

Service-Oriented Architecture

Answer 15

Refers to applications that expose and consume functionality as a service using contracts and messages.

Question 16

What is the simplest form of a Client/Server Architectural Style?

Answer 16

The simplest form of client/server system involves a server application that is accessed directly by multiple clients, referred to as a 2-Tier architectural style.

Question 17

Common variations of a Client/Server architectural style

Answer 17

Client-Queue-Client systems. This approach allows clients to communicate with other clients through a server-based queue. Clients can read data from and send data to a server that acts simply as a queue to store the data. This allows clients to distribute and synchronize files and information. This is sometimes known as a passive queue architecture.

Peer-to-Peer (P2P) applications. Developed from the Client-Queue-Client style, the P2P style allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients. It extends the client/server style through multiple responses to requests, shared data, resource discovery, and resilience to removal of peers.

Application servers. A specialized architectural style where the server hosts and executes applications and services that a thin client accesses through a browser or specialized client installed software. An example is a client executing an application that runs on the server

Question 18

Main benefits of the client/server architectural style

Answer 18

Higher security. All data is stored on the server, which generally offers greater control of security than client machines.

Centralized data access. Because data is stored only on the server, access and updates to the data are far easier to administer than in other architectural styles.

Ease of maintenance. The roles and responsibilities of a computing system are distributed among several servers that are known to each other through a network. This ensures that a client remains unaware and unaffected by a server repair, upgrade, or relocation.

Question 19

When to consider Client/Server Architectural Styles?

Answer 19

Consider the client/server architectural style if…

your application is server based and will support many clients,

you are creating Web-based applications exposed through a Web browser,

you are implementing business processes that will be used by people throughout the organization,

or you are creating services for other applications to consume.

The client/server architectural style is also suitable, like many networked styles, when you want to centralize data storage, backup, and management functions, or when your application must support different client types and different devices.

Question 20

Drawbacks of the Client/Server Architecture pattern

Answer 20

The traditional 2-Tier client/server architectural style has numerous disadvantages, including the tendency for application data and business logic to be closely combined on the server, which can negatively impact system extensibility and scalability, and its dependence on a central server, which can negatively impact system reliability.

To address these issues, the client-server architectural style has evolved into the more general 3-Tier (or N-Tier) architectural style, , which overcomes some of the disadvantages inherent in the 2-Tier client-server architecture and provides additional benefits.

Question 21

Major difference between Object -Orientated Design and a Component-BAsed Architectural style?

Answer 21

CBA provides a higher level of abstraction than object-oriented design principles and does not focus on issues such as communication protocols and shared state.

OOD objects, even though separated into different classes, are compiled into and run as a monolithic app, Whereas CBA components are run as separate functional units or components, often on different servers or machines

Question 22

Key principles of Component-Based Architeture

Answer 22

Reusable. Components are usually designed to be reused in different scenarios in different applications. However, some components may be designed for a specific task.

Replaceable. Components may be readily substituted with other similar components.

Not context-specific. Components are designed to operate in different environments and contexts. Specific information, such as state data, should be passed to the component instead of being included in or accessed by the component.

Extensible. A component can be extended from existing components to provide new behavior.

Encapsulated. Components expose interfaces that allow the caller to use its functionality, and do not reveal details of the internal processes or any internal variables or state.

Independent. Components are designed to have minimal dependencies on other components. Therefore components can be deployed into any appropriate environment without affecting other components or systems.

Question 23

Key benefits of a component-based archtitecture

Answer 23

Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.

Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.

Ease of development. Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.

Reusable. The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.

Mitigation of technical complexity. Components mitigate complexity through the use of a component container and its services. Example component services include component activation, lifetime management, method queuing, eventing, and transactions.

Question 24

Key benefits of Domain Driven Design

Answer 24

Communication. All parties within a development team can use the domain model and the entities it defines to communicate business knowledge and requirements using a common business domain language, without requiring technical jargon.

Extensible. The domain model is often modular and flexible, making it easy to update and extend as conditions and requirements change.

Testable. The domain model objects are loosely coupled and cohesive, allowing them to be more easily tested.

Question 25

When should you consider using Domain Driven Design pattern?

Answer 25

Consider DDD if you have a complex domain and you wish to improve communication and understanding within your development team, or where you must express the design of an application in a common language that all stakeholders can understand. DDD can also be an ideal approach if you have large and complex enterprise data scenarios that are difficult to manage using other techniques.

Question 26

When should you consider a component-based architectural style?

Answer 26

Consider the component-based architectural style if you already have suitable components or can obtain suitable components from third-party suppliers; your application will predominantly execute procedural-style functions, perhaps with little or no data input; or you want to be able to combine components written in different code languages. Also, consider this style if you want to create a pluggable or composite architecture that allows you to easily replace and update individual components.

Question 27

List the most commonly used software architecture

Answer 27

1. Monolith
2. Component-Based (CBA)
3. Client/Server
4. Domain-Driven Design (DDD)
5. Layered Architecture
6. Message Bus
7. N-Tier
8. Object-Oriented (OOD)
9. Services-Oriented Architecture (SOA)

Question 28

What are some common layers in the Layered Architectural pattern

Answer 28

Presentation
Service
Business logic
Persistence
database/infrastructure

Question 29

Variations of Layered Architectural pattern

Answer 29

1. N-tier
2. Cached
3. Open/Closed

Question 30

Keys to Layered Architectural pattern

Answer 30

Separation of concerns. Separated Presentation patterns divide UI processing concerns into distinct roles; for example, MVC has three roles: the Model, the View, and the Controller. The Model represents data (perhaps a domain model that includes business rules); the View represents the UI; and the Controller handles requests, manipulates the model, and performs other operations.

Event-based notification. The Observer pattern is commonly used to provide notifications to the View when data managed by the Model changes.

Delegated event handling. The controller handles events triggered from the UI controls in the View.

Question 31

When to consider the Layered Architectural pattern

Answer 31

Consider the layered architectural style if you have existing layers that are suitable for reuse in other applications, you already have applications that expose suitable business processes through service interfaces, or your application is complex and the high-level design demands separation so that teams can focus on different areas of functionality. The layered architectural style is also appropriate if your application must support different client types and different devices, or you want to implement complex and/or configurable business rules and processes.

Consider a Separated Presentation pattern if you want improved testability and simplified maintenance of UI functionality, or you want to separate the task of designing the UI from the development of the logic code that drives it. These patterns are also appropriate when your UI view does not contain any request processing code, and does not implement any business logic.

Question 32

Two common variations on the Message Bus

Answer 32

Enterprise Service Bus (ESB). Based on message bus designs, an ESB uses services for communication between the bus and components attached to the bus. An ESB will usually provide services that transform messages from one format to another, allowing clients that use incompatible message formats to communicate with each other

Internet Service Bus (ISB). This is similar to an enterprise service bus, but with applications hosted in the cloud instead of on an enterprise network. A core concept of ISB is the use of Uniform Resource Identifiers (URIs) and policies to control the routing of logic through applications and services in the cloud.

Question 33

When should you consider using a Message Bus Architecture

Answer 33

Consider the message bus architectural style if you have existing applications that interoperate with each other to perform tasks, or you want to combine multiple tasks into a single operation. This style is also appropriate if you are implementing a task that requires interaction with external applications, or applications hosted in different environments.

Question 34

When should you consider using a N-Tier Architecture

Answer 34

Consider either the N-tier or the 3-tier architectural style if the processing requirements of the layers in the application differ such that processing in one layer could absorb sufficient resources to slow the processing in other layers, or if the security requirements of the layers in the application differ. For example, the presentation layer should not store sensitive data, while this may be stored in the business and data layers. The N-tier or the 3-tier architectural style is also appropriate if you want to be able to share business logic between applications, and you have sufficient hardware to allocate the required number of servers to each tier.

Consider using just three tiers if you are developing an intranet application where all servers are located within the private network; or an Internet application where security requirements do not restrict the deployment of business logic on the public facing Web or application server. Consider using more than three tiers if security requirements dictate that business logic cannot be deployed to the perimeter network, or the application makes heavy use of resources and you want to offload that functionality to another server

Question 35

Key benefits of Object Orientated Design

Answer 35

Understandable. It maps the application more closely to the real world objects, making it more understandable.

Reusable. It provides for reusability through polymorphism and abstraction.

Testable. It provides for improved testability through encapsulation.

Extensible. Encapsulation, polymorphism, and abstraction ensure that a change in the representation of data does not affect the interfaces that the object exposes, which would limit the capability to communicate and interact with other objects.

Highly Cohesive. By locating only related methods and features in an object, and using different objects for different sets of features, you can achieve a high level of cohesion.

Question 36

When to consider Object-Orientated Approach

Answer 36

Consider the object-oriented architectural style if you want to model your application based on real world objects and actions, or you already have suitable objects and classes that match the design and operational requirements. The object-oriented style is also suitable if you must encapsulate logic and data together in reusable components or you have complex business logic that requires abstraction and dynamic behavior.

Question 37

SOA Architecture: Two kinds of services

Answer 37

Atomic: Well defined and self-contained, do not rely on other services

Composite: composition of two or more atomic services, which depends on each other

Question 38

SOA Architecture: Service Classification

Answer 38

Frontend: terminals, service consumers, etc

Integration: gateways, adapters, etc

Business: business functionality

Public Enterprise: security, authentication, etc

Infrastructure: event logging etc

Question 39

What is the backbone of every SOA System?

Answer 39

Enterprise Service Bus: Could be a single server or some complex middleware, it is responsible for handling the integration part of the system

Question 40

SOA Architecture: SDR

Answer 40

Service Description Repository/Registery

How consumers of a service discore services and how to connect with them

Question 41

When should you consider a SOA architecture

Answer 41

Consider the SOA style if you have access to suitable services that you wish to reuse; can purchase suitable services provided by a hosting company; want to build applications that compose a variety of services into a single UI; or you are creating Software plus Services (S+S), Software as a Service (SaaS), or cloud-based applications. The SOA style is suitable when you must support message-based communication between segments of the application and expose functionality in a platform independent way, when you want to take advantage of federated services such as authentication, or you want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.

Question 42

3 major categories of design patterns

Answer 42

Creational Patterns: These design patterns provide ways to create objects while hiding the creation logic, instead of instantiating objects directly using the new operator. This gives the program more flexibility in deciding which objects need to be created for a given use case.

Structural Patterns: These design patterns deal with class and object composition. The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new

functionality.
Behavioral Patterns: These design patterns are specifically concerned with communication between objects.

Question 43

Creational Patterns

Answer 43

Creational Patterns: These design patterns provide ways to create objects while hiding the creation logic, instead of instantiating objects directly using the new operator. This gives the program more flexibility in deciding which objects need to be created for a given use case.

Abstract Factory. The abstract factory pattern is used to provide a client with a set of related or dependant objects. The “family” of objects created by the factory are determined at run-time.

Builder. The builder pattern is used to create complex objects with constituent parts that must be created in the same order or using a specific algorithm. An external class controls the construction algorithm.

Factory Method. The factory pattern is used to replace class constructors, abstracting the process of object generation so that the type of the object instantiated can be determined at run-time.

Prototype. The prototype pattern is used to instantiate a new object by copying all of the properties of an existing object, creating an independent clone. This practise is particularly useful when the construction of a new object is inefficient.

Singleton. The singleton pattern ensures that only one object of a particular class is ever created. All further references to objects of the singleton class refer to the same underlying instance.

Question 44

Structural Patterns

Answer 44

Structural Patterns: These design patterns deal with class and object composition. The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionality.

Adapter. The adapter pattern is used to provide a link between two otherwise incompatible types by wrapping the “adaptee” with a class that supports the interface required by the client.

Bridge. The bridge pattern is used to separate the abstract elements of a class from the implementation details, providing the means to replace the implementation details without modifying the abstraction.

Composite. The composite pattern is used to create hierarchical, recursive tree structures of related objects where any element of the structure may be accessed and utilised in a standard manner.

Decorator. The decorator pattern is used to extend or alter the functionality of objects at run-time by wrapping them in an object of a decorator class. This provides a flexible alternative to using inheritance to modify behaviour.

Facade. The facade pattern is used to define a simplified interface to a more complex subsystem.

Flyweight. The flyweight pattern is used to reduce the memory and resource usage for complex models containing many hundreds, thousands or hundreds of thousands of similar objects.

Proxy. The proxy pattern is used to provide a surrogate or placeholder object, which references an underlying object. The proxy provides the same public interface as the underlying subject class, adding a level of indirection by accepting requests from a client object and passing these to the real subject object as necessary.

Question 45

Behavioral Patterns

Answer 45

Behavioral Patterns: These design patterns are specifically concerned with communication between objects.

Chain of Responsibility. The chain of responsibility pattern is used to process varied requests, each of which may be dealt with by a different handler.

Command. The command pattern is used to express a request, including the call to be made and all of its required parameters, in a command object. The command may then be executed immediately or held for later use.

Interpreter. The interpreter pattern is used to define the grammar for instructions that form part of a language or notation, whilst allowing the grammar to be easily extended.

Iterator. The iterator pattern is used to provide a standard interface for traversing a collection of items in an aggregate object without the need to understand its underlying structure.

Mediator. The mediator pattern is used to reduce coupling between classes that communicate with each other. Instead of classes communicating directly, and thus requiring knowledge of their implementation, the classes send messages via a mediator object.

Memento. The memento pattern is used to capture the current state of an object and store it in such a manner that it can be restored at a later time without breaking the rules of encapsulation.

Observer (pub/sub). The observer pattern is used to allow an object to publish changes to its state. Other objects subscribe to be immediately notified of any changes.

State. The state pattern is used to alter the behaviour of an object as its internal state changes. The pattern allows the class for an object to apparently change at run-time.

Strategy. The strategy pattern is used to create an interchangeable family of algorithms from which the required process is chosen at run-time.

Template Method. The template method pattern is used to define the basic steps of an algorithm and allow the implementation of the individual steps to be changed.

Visitor. The visitor pattern is used to separate a relatively complex set of structured data classes from the functionality that may be performed upon the data that they hold.