Popular in computer architecture
Popular in Department
This 7 page Class Notes was uploaded by Andre Robinson on Monday January 18, 2016. The Class Notes belongs to computer architecture at a university taught by yi in Winter 2016. Since its upload, it has received 531 views.
Reviews for software
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 01/18/16
6-1 Decomposing a system into subsystems reduces the complexity developers have to deal with by simplifying the parts and increasing their coherence. Decomposing a system into simpler parts usually results into increasing a different kind of complexity: Simpler parts also means a larger number of parts and interfaces. If coherence is the guiding principle driving developers to decompose a system into small parts, which competing principle drives them to keep the total number of parts small? Decreasing coupling is the principle that completes with increasing coherence. A large number of parts will result in a large number of interfaces and many dependencies among the parts. 6–3 You are developing a system that stores its data on a Unix file system. You anticipate that you will port future versions of the system to other operating systems that provide different file systems. Propose a subsystem decomposition that anticipates this change. A Bridge pattern should be used to define a generic interface to the storage subsystem. Consequently, different implementations of the storage subsystem can be provided to dealing with specific file systems. Note that the bridge pattern does not address the problem of moving files from one file system to another. To address this problem, a separate conversion utility needs to be developed. 6–5 Consider the model/view/control example depicted in Figures 6-16 and 6-15. a. Redraw the collaboration diagram of Figure 6-16 as a sequence diagram b. Discuss how the MVC architecture helps or hurts the following design goals. • Extensibility (e.g., the addition of new types of views). The MVC helps extensibility in terms of new types of views, since neither model objects nor existing view objects need to be modified to accommodate the new view. • Response time (e.g., the time between a user input and the time all views have been updated) A pure MVC hurts response time, because the view the user sees is updated only after the model has been updated. This can be an issue for commands involving a rapid series of interactions (e.g., dragging or resizing a geometrical shape). • Modifiability (e.g., the addition of new attributes in the model) The MVC helps this goal, since only the views that need to be aware of the new attribute need to be modified. All other views can be left unchanged. • Access control (i.e., the ability to ensure that only legitimate users can access specific parts of the model). The MVC helps this goal, as the model is accessed using a clear interface (the public methods of the model objects) which can be controlled, for example, using a proxy pattern for each model class. 6.6 List design goals that would be difficult to meet when using a closed architecture with many layers such as the OSI example depicted in figure 611 A closed architecture requires method invocations across each layer boundary and often also copying data between each layer. This hurts both response time and memory foot print. 7.1 Consider a system that includes a Web server and two database servers. Both database servers are identical: The first acts as a main server, while the second acts as a redundant backup in case the first one fails. Users use Web browsers to access data through the Web server. They also have the option of using a proprietary client that accesses the databases directly. Draw a UML deployment diagram representing the hardware/software mapping of this system. 7.5 Why can you not describe boundary use cases during requirements elicitation or analysis? Use cases that describe boundary conditions DEPEND ON SYSTEM DESIGN DECISIONS. For example, software architecture decisions need to be made before developers can describe how the system is started or shutdown. 2.6. Draw a sequence diagram for the warehouseOnFire scenario of Figure 2-17 on page 42 in the book. Include the objects bob, alice, john, FRIEND, and instances of other classes you may need. Draw only the first five message sends. 8–2 Indicate which occurrences of the following inheritance relationships are specification inheritance and which are implementation inheritance: • A Rectangle class inherits from a Polygon class. [specification inheritance] • A Set class inherits from a BinaryTree class. [implementation inheritance] • A Set class inherits from a Bag class (a Bag is defined as an unordered collection). [specification inheritance] • A Player class inherits from a User class. [specification inheritance] • A Window class inherits from a Polygon class. [implementation inheritance] 8–6 In Section 8.4.1, we used a Bridge pattern to decouple the implementation of the ARENA LeagueStore subsystem from its interface, enabling us to provide different implementations for the purpose of testing. Ideally, we would apply the Bridge pattern to each subsystem in our system design to facilitate testing. Unfortunately, this is not always possible. Give an example of a subsystem where the Bridge pattern cannot be used. A Bridge pattern can be used in the case of a subsystem with a single Facade. Subsystems that offer a more complex interface, for example a whitebox framework used for realizing a user interface, are difficult to encapsulate. 9-1 Consider the List interface in the java.util package for ordered collections of objects. Write preconditions and post conditions in OCL for the following operations: ● int size() returns the number of elements in the list. Precondition: the number of elements in the list has to be > -1. Postcondition: returns the number of elements in the list. ● void add(Object e) adds an object at the end of the list. Precondition: none. Postcondition: adds an object at the end of the list; if the list is empty it’ll be the first element in the list. ● void remove(Object e) removes an object from the end of the list. Precondition: an object defined in the parameter has to be present in the list. Postcondition: removes an object from the end of the list. ● boolean contains(Object e) returns true if the object is contained in the list. Precondition: the object compared should be in the list in order for it to return a true value. Postcondition: returns true if the object is contained in the list. ● Object get(int idx) returns the object located at index idx, 0 being the index of the first object in the list. Precondition: an object has to be present at the specified index in the parameter. The index parameter cannot be negative. Postcondition: returns the object located at the index idx. 11–3 Build the statechart diagram corresponding to the PurchaseTicket use case of Figure 11-24. Generate test cases based on the statechart diagram using the state-based testing technique. Discuss the number of test cases and differences with the test case of Figure 11-25. Test case 11-25 is too specific with its use case; use case 11-24 is more general yet it is more flexible and straightforward in comparison with the use case 11-25. Since use case 11-24 is more flexible it applies to more than one specific event that could occur when PurchaseTicket is applied. The first use case is a realistic interaction with the actor; where in this instance the actor would be the person purchasing the tickets. With use case 11-25 being excessively in depth, it does not really qualify for being a proper use case. 11.4 Given the subsystem decomposition comment on the testing plan used by the project manager: comment on the testing plan used by the project manager What decisions were made? What are the advantages and disadvantages of this test case plan? This test plan was generated according to a sandwich testing plan, without unit testing subsystems from the target layer and without double tests. The advantage is that this test plan consists of fewer tasks. The disadvantage is that failures discovered during the Test A,B,C,D activity will be difficult to locate. A better strategy is to unit test the subsystems in the target layer. Advantages ● The testing is done in layers starting from layer 1 working downwards to layer 3. ● Testing in layers helps in terms of time since it is done in groups and whatever falls beneath the hierarchy of layers is tested. Disadvantages ● Not all the individual subsections of the systems are tested even though the layers appear to have been combined into one entirety test for the system. ● For test A, the testing only goes as far as layer 2. ● For test G, the directional test is upwards, and whereas the testing should be done in the second layer for D which is learning.
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'