Block 3 Unit 9 Flashcards

1
Q

Suggest a reason why choosing the architecture very late on might be a bad idea.

A

Choosing the architecture at a very late stage suffers from the risks of the waterfall approach. By then many other design decisions will have been taken and it will be too late to change them, even if they force us to adopt an architecture that is less than ideal.
An analogy could be with building a house. Would anyone dream of starting construction without an architectural design for the building?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Think of some reasons why reuse is desirable.

A

We thought of several reasons. You may have come up with others.
It avoids duplication of effort and reinventing already existing solutions, which saves resources.
It promotes reliability because developers can use tried and trusted solutions.
It speeds up development because developers can take existing solutions without starting from the beginning every time.
It is a mechanism for spreading good practice among the software development community and familiarising practitioners with tried and tested solutions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What are the various ingredients that make up a framework?

A

A framework consists of an architecture, a small amount of software for the framework, a set of components suitable for use within the framework and the documentation needed to make use of the framework.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

List the various forms of reuse discussed in Section 4 and say briefly what is reused in each case.

A

Architectural styles reuse expertise in large-scale architectural design – the types of component used and the patterns of interaction between them.
Frameworks reuse a particular architecture and a set of software components suitable for use within it.
Product lines reuse reference architectures, software components and expertise about the variations needed to fulfil customer requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is the difference between generalisation and realisation?

A
Generalisation expresses a subtyping relationship between two classes. The subclass is a specialised subtype of its superclass and inherits the attributes and operations defined by the superclass.
Realisation is not a subtyping relationship but instead expresses the fact that a class provides an implementation for all the operations specified by an interface.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Discuss possible advantages of separating the user interface from the domain logic.

A

These are the main advantages.

  1. The user interface is not affected by changes in the implementation of the business logic.
  2. The same domain logic can be used with different user interfaces.
  3. The business logic can be tested separately from the interface logic.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Where in the hotel system might we use a singleton?

A

We could use a singleton instance of HotelChain as a system object that all messages from the user interface are sent to.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Suggest some quality requirements that the Factory pattern might help satisfy.

A

The ones we thought of were maintainability and portability (and flexibility if it is counted as distinct from maintainability). You may have come up with others.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Think of another concept that uses principles similar to those above.

A

From the above principles, a component closely resembles the concept of an object in an object-oriented language.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Think of some possible advantages and disadvantages of building software by plugging together off-the-shelf components.

A

Advantages
1. Reusing a standard component should be cheaper than developing software from scratch.
2. Using off-the-shelf components will allow applications to be developed more quickly.
3. Standard components will have been used in many other projects, so their behaviour will be well understood and any bugs are likely to be known.
4. Components are pluggable, so it is often possible to replace one component with another providing it has the same interface and behaves in the same way.
Disadvantages
1. Using standard components may restrict what we can do since we have to work with the capability of the components.
2. Some additional software is likely to be needed as ‘plumbing’.
3. If the interfaces of components are incompatible, adapters will have to be written.
4. Creating a system by plugging together off-the-shelf components may not be as simple as it sounds.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Suppose a component is implemented as an instance of a Java class. What corresponds to:
the provided interface of the component
the required interface of the component?

A
The provided interface consists of all the public methods in the class.
The required interface consists of all the methods from other classes that the component’s methods make use of.
In object-oriented languages an object belonging to a subclass is allowed to replace an object of the parent class. This is substitutability, which was discussed in Block 2 Unit 5.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

In the context of software components, describe a concept that is similar to substitutability.

A

Components are replaceable: a component can be replaced by another that does the same job.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What would the assume–guarantee contract for a component include and how do the assume and guarantee relate to the component’s provided and required interfaces?

A

The contract for a component would be:
1. the pre- and postcondition of all the operations in the provided interface of the component
2. the invariants that apply to any publicly visible properties of the component
3. the required interface of the component and all the assumptions of the required interface
4. any other assumptions about the environment in which the component will operate.
The assume would be the preconditions of the operations, and items 3 and 4 of the contract above.
The guarantee would be the postcondition of the operations and item 2 of the contract above.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Think of two application areas where the appropriate response measure for a performance scenario would be something other than latency.

A

Here are several examples we thought of:

  1. a system controlling a plant processing industrial chemicals – deadline
  2. an online shopping site – throughput
  3. an online gaming site – jitter (since users will expect consistent response times)
  4. a social networking site – data loss
  5. an online shopping site – miss rate.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

From your study of the module, list some other types of reusable solution, apart from design tactics, that are available to software engineers.

A
We thought of:
analysis patterns
requirements patterns
architectural styles
design patterns
language idioms
components
services.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Write down in your own words what flexibility means in relation to software.

A

Flexibility is the ability for software to be changed easily.

17
Q

What concepts introduced in the module relate to flexibility? Come up with as many as you can and write them down. Don’t spend too long though: 10 minutes or so is enough

A

We came up with the following. The list almost certainly isn’t complete and it could be much better written, but it’s what came out of our brainstorming so we left it as it is.

  1. Low coupling so changes don’t have knock-on effects.
  2. High cohesion so functions that are closely related can get changed together as a unit.
  3. Hiding implementation behind interfaces and contracts because this keeps coupling as low as possible.
  4. Use component-based development so components are pluggable/replaceable.
  5. Delegate details such as object creation to factories so clients don’t need to know them and coupling is kept low.
  6. Use layers. Low coupling and separation of concerns.
  7. Wrap legacy software (related to hiding functions behind interfaces).
  8. Package functions as loosely coupled services.
18
Q

List as many ways as you can think of to reduce coupling.

A

Use components that hide their implementation behind interfaces.
Use services that hide their implementation behind interfaces.
Use a layered architecture.
Use packages to group closely related elements.
Separate model from presentation.
Hide legacy software behind wrappers.
Delegate object creation to factories.
Use a registry to locate objects or services instead of having to know their location.

19
Q

Java EE applications follow a layered architecture. Describe how the Java EE containers and other elements shown in Figure 10 fit into a three-layer architecture like the one described in Unit 1.

A

Browsers, applet containers, application clients, web containers, JavaServer Faces and servlets are all in the presentation layer.
The EJB container and EJBs are in the application domain, since EJBs are business components.
The database is part of the infrastructure.

20
Q

Suppose the management of the hotel chain decides it would like a way of sending customers information about special offers. It would also like to be able to send important bulletins to the application clients installed in the hotels.

a. Which two Java EE technologies mentioned in subsection 5.1 could be used to meet these requirements?
b. What architectural style are these an example of?
c. Both these technologies run in the web container. Redraw your sketch of the hotel system architecture to include them and the associated communication.

A

JavaMail and JMS (Java Message Service) respectively.

b. Notification.
c. Our answer is shown in Figure 13. Notice that the application clients are now in communication with JMS in the web container, as well as with EJBs. Web clients and mobile clients would receive information about special offers via their normal email systems.

21
Q

Which parts of the hotel system would you expect to change the most often?

A

The part of the system dealing with core business functions can be expected to change quite frequently in response to changes in business rules.
The part of the system that constructs web pages is also likely to change quite frequently as new features and page layouts are introduced.

22
Q

Reread the discussion on tactics for flexibility in subsection 4.4 and suggest some examples of the use of these tactics in the Java EE hotel system.

A

We thought of the following examples of modifiability tactics in the Java EE hotel system. You may have come up with different ones.
Minimise coupling
Java EE keeps coupling low in many ways, such as by:
using interfaces
using loosely coupled messaging systems (JMS and JavaMail)
using loosely coupled RESTful web services
separating concerns and placing them in different layers
dependency injection which hides the details of creating resources such as EJB instances.
Maximise cohesion
Java EE components of all kinds tend to have good cohesion because they are generally written to be responsible for a small number of closely related tasks. The ConverterBean and the ConverterService are good examples of this, since they each do just one thing.
Keep modules small
Java EE components with their dedicated focus are also usually small and relatively easy to change or replace. The ConverterBean and the ConverterService are again good examples.
Bind as late as possible
An example of this is the dependency injection in the application client, where the container binds an instance of the ConverterBean to the name converterBean only at run-time when the application client needs to use the EJB object.