Unit 10 - Components, patterns and architecture Flashcards
(a) What are the main issues addressed by the Layers pattern and what are the main mechanisms used to address them?
(b) How does the adoption of the pattern facilitate reuse and flexibility?
(a) The main issues addressed by the pattern are achieving low coupling between elements, and separating concerns. This is realised by organising the system elements in layers, each layer addressing a particular concern, and managing the coupling between layers carefully.
(b) The implementation of general services can be separated from that of other parts of the system. Hence services can be potentially reused in other applications, or their implementation replaced while still providing the same basic services.
(a) Describe the relationship between the two styles of Layers pattern illustrated in Figure 1.
(b) What do you think may determine the flavour of the patterns that should be adopted for the architecture of a particular enterprise system?
(a) The five-layered version (Figure 1(b)) introduces two mediating layers between the fundamental layers of the three-layered version (Figure 1(a)).
(b) Complexity and flexibility are determining factors. For instance, if the relationship between the presentation and domain layers is straightforward and can be easily modified and tested, then it might be more efficient to distribute the logic between these two layers rather than introducing a third one. On the other hand, in a system that allows complex interactions to occur with a large variety of users and where changes are frequent, the introduction of an application layer might allow the logic in the two other layers to be independently modified, tested and validated. A similar argument applies to the technical services layer.
(a) What do we mean by software architecture?
(b) How does an architectural pattern relate to software architecture?
(a) Software architecture is a high-level abstract description of the structure of a software system – its major parts and how they are interrelated.
(b) An architectural pattern focuses on particular elementary principles used in software architectures, so that aspects of the way a particular architecture works can be accounted for by reference to architectural patterns.
(a) What are the various ingredients that make up a framework?
(b) How does a domain model differ from a conceptual model?
(c) What is a common business object?
(d) How do frameworks help in the reuse of components?
(a) A framework comprises an architecture, together with a component repository that contains components suitable for use within the framework, plus whatever documentation would facilitate the use of the framework. (b) A domain model addresses a general set of possible problems or requirements, whilst a conceptual model addresses a specific problem.
(c) A business object is any entity, such as a customer, that occurs in a business application. A common business object is one that recurs widely and often, and is worth placing in a component repository.
(d) Components may not quite fit into a particular application, or can be too general to be useful. A framework only places in the repository those components that do fit and are useful. The framework will guide the user to the component required, so that general search methods are not required.
Describe very briefly a method for developing a framework, based on the discussion of the Layers pattern and frameworks above.
1 Characterise the domain in general terms. 2 List the different elements of the system, possibly with the help of a use case diagram. 3 Develop a preliminary class diagram for the framework, with a just a few abstract classes, based on what your examples have in common. 4 Identify the layering styles that the framework is to use. 5 Identify some of the component concrete classes that could be substituted for the abstract classes. 6 Use this class diagram to modify and elaborate the class diagram of the framework.
Suppose that your company makes a range of computer games, and now wants to offer simple variants on these games that are personalised to a company or a person. The rules may be changed in simple ways, and names and pictures may be changed to fit characters in the company’s or the person’s life, and so on. How would you design such a software product-line for your company?
An analysis should be made of a number of games, to determine the variety of customisations that could be made, referring to prospective customers and games experts wherever possible (domain analysis). Reference architectures would then be developed in which the games themselves were represented at a high-level, highlighting only those places where customisation may be required (architectural specification). A repertoire of possible customisations that people might want would be built up, such as variant game rules, or unusual card faces or different game characters, also allowing for words and images requested by the customer to be inserted (component collection).
Discuss how the Application Controller pattern may apply in a layered architecture.
The Application Controller pattern fits nicely in a layered architecture, as illustrated in Figure 9. The controller may sit in the application layer and mediate between presentation and domain objects. Actor events are translated into system events between the interface and the controller; this may result in a number of messages between the controller and domain objects.
Discuss possible advantages of separating presentation from domain logic.
The two main advantages of this separation are: first, presentation logic is not affected by changes in the implementation of the business logic; second, business logic can be tested separately from the presentation logic.
What sort of business logic will be invoked by the application controller?
The application controller will invoke business logic to:
- locate class instances within the system, by mapping value and object identities;
- invoke methods on business objects to check operations’ preconditions (the application controller takes the role of the client in the operation contract);
- delegate the satisfaction of the operations’ postconditions to business objects.
Discuss the differences and similarities between the application controller and the controller in the MVC pattern.
The application controller isolates and abstracts business logic from presentation logic, and controls the workflow of a business process. The MVC controller manages user inputs through a user interface in order to modify business data. Thus the contexts of their applications are different: a business process versus a user interface. The main similarity between the two controllers is that they support a separation of concerns: presentation logic from business logic in the case of the application controller; data from the user’s view in the case of the MVC controller.
What is the difference between generalisation (e.g. the superclass in inheritance) and realisation?
Generalisation expresses a subtyping relationship between two classes: the subclass is a specialised subtype of its superclass, and instances of the subclass can appear anywhere that instances of the superclass can; the subclass inherits attributes and operations of the superclass. Realisation is not a subtyping relationship, but instead asserts that a class realises a protocol specified by an interface. The realising class provides an implementation for all the operations that are declared in the interface.
Discuss a circumstance under which it would be appropriate to use the Singleton pattern in the hotel reservation example shown in Figure 2.
If the software was being designed to manage a single hotel chain, then the class HotelChain would be required to have only one instance. The Singleton pattern could be applied to enforce this condition. Note that the hotel reservation application is almost certainly both distributed and multi-threaded, so implementing Singleton will be more complex than using static methods.
Discuss some advantages of using factories for the creation of objects rather than applying GRASP Creator directly to classes of the domain layer.
One advantage is that the logic for the creation and initialisation of objects of a given class is encapsulated within the factory. This improves system flexibility as changes to how the objects are created and initialised will be local to the factory. Also, the coupling within classes in the system is reduced for the following reasons:
- The factory knows how to create and initialise a hierarchy of objects such as ReserverPayer and Reservation in Figure 22, removing that knowledge from the ReserverPayer and HotelChain classes.
- The delegated creation methods such as createReservation in ReserverPayer (again in Figure 22) are not necessary. The factory knows that there must be a link between a ReserverPayer and its reservations, so that HotelChain need not be concerned with this detail.
- By implementing a factory as a singleton, the factory can be accessed without the need for links between the factory object and its clients.
Summarise the steps you need to take to define an enterprise bean.
To define an enterprise bean it is sufficient to define one interface and one class. The interfaces represent the business functions supplied by the bean, which clients need to make use of the bean. The class represents the implementation of the bean and provides the code for all the methods declared in its interfaces.
Java EE applications follow the Layers architectural pattern. Discuss where Java EE containers play a role in a layered architecture.
With reference to three-layer architecture, client containers and applet containers work in the presentation layer, while the EJB container works in the domain layer. Technologies such as JDBC, which are available in most containers, provide an interface to databases and hence integration with the data source layer.
