whole-Part :

In this there will be two parts. The structure of whole and part are shown below : Class: Whole

Responsibility:

 Aggregates several smaller objects

 Provides services built on top of part objects

 Acts as a wrapper around its constituent parts Collaborators: Part

Dept. of CSE, SJBIT Page 126 Responsibility:

 Represents a particular object and its services Collaborators: - Nil

 Whole object: It is an aggregation of smaller objects

 The smaller objects are called Parts

Whole object forms a semantic grouping of its Parts in that it coordinates and organizes their collaboration

The Whole uses the functionality of Parts objects for implementing services Implementation

1. Design the public Interface of the Whole

2. Separate the Whole into Parts, or make it from existing ones (Use either bottom- up, top- down or both mixed)

3. Use existing Parts from component libraries or class libraries or package, specify their collaboration if you use bottom-up approach

4. Partition the Whole's services into smaller collaborating services and map these collaborating services to separate Parts if you follow a top-down approach

5. Specific the services of the Whole in terms of services of the Parts 6. Implement the Parts (Recursively if Parts are not leaf)

7. Implement the Whole by putting all the Parts together Advantages

Changeability of Parts Reusability

Defines class hierarchies consisting of primitive objects Makes the client simple

Makes it easier to add new kinds of components Disadvantages

1) Makes your design overly general 2) Lower efficiency through indirection

Dept. of CSE, SJBIT Page 127 7.3 Organization of work : Master-Slave :

 The Master-Slave design pattern supports fault tolerance, parallel computation and computational accuracy. A master component distributes work to identical slave components and computes a final result from the results these slaves return.

 It is used when you have two or more processes that need to run simultaneously and continuously but at different rates. If these processes run in a single loop, severe timing issues can occur. These timing issues occur when one part of the loop takes longer to execute than expected. If this happens, the remaining sections in the loop get delayed.

 The Master/Slave pattern consists of multiple parallel loops. Each of the loops may execute tasks at different rates. Of these parallel loops, one loop acts as the master and the others act as slaves. The master loop controls all of the slave loops, and communicates with them using messaging architectures.

 The Master/Slave pattern is most commonly used when responding to user interface controls while collecting data simultaneously. Suppose you want to write an application that measures and logs a slowly changing voltage once every five seconds.

 It acquires a waveform from a transmission line and displays it on a graph every 100ms, and also provides a user interface that allows the user to change parameters for each acquisition. The Master/Slave design pattern is well suited for this application. In this application, the master loop will contain the user interface. The voltage acquisition and logging will happen in one slave loop, while the transmission line acquisition and graphing will.

 Applications that involve control also benefit from the use of Master/Slave design patterns. An example is a user’s interaction with a free motion robotic arm. This type of application is extremely control oriented because of the physical damage to the arm or surroundings that might occur if control is mishandled. For instance, if the user instructs the arm to stop its downward motion, but the program is occupied with the arm swivel control, the robotic arm might collide with the support platform.

 This situation can be avoided by applying the Master/Slave design pattern to the application. In this case, the user interface will be handled by the master loop, and every controllable section of the robotic arm will have its own slave loop. Using this method, each controllable section of the arm will have its own loop, and therefore, its own piece of processing time.

 The Master/Slave design pattern is very advantageous when creating multi-task applications. It gives you a more modular approach to application development because of its multi-loop functionality, but most importantly, it gives you more control of your application’s time management.

 Here each parallel loop is treated as a separate task or thread. A thread is defined as a part of a program that can execute independently of other parts. If you have an application that doesn’t use separate threads, that application is interpreted by the system as one thread. When you split your application up into multiple threads, they each share processing time equally with each other.

Dept. of CSE, SJBIT Page 128 The Master/Slave design pattern consists of multiple parallel loops. The loop that controls all the others is the master and the remaining loops are slaves. One master loop

always drives one or more slave loops. Since data communication directly between these loops breaks data flow, it must be done by writing and reading to messaging architectures

An access control model describes at a high level of abstraction a mechanism for governing access to shared resources.

Dept. of CSE, SJBIT Page 129 UNIT – 8

Designing and Documenting Software Architecture: Architecture in the life cycle;

Designing the architecture; Forming the team structure; Creating a skeletal system.

Uses of architectural documentation; views; choosing the relevant views; documenting a view;

Dept. of CSE, SJBIT Page 130 UNIT – 8

Designing and Documenting Software Architecture: 8.1. Architecture in the life cycle;

Any organization that embraces architecture as a foundation for its software development processes needs to understand its place in the life cycle. Several life-cycle models exist in the literature, but one that puts architecture squarely in the middle of things is the evolutionary delivery life cycle model shown in figure

Fig8.1: Evolutionary Delivery Life Cycle

The intent of this model is to get user and customer feedback and iterate through several releases before the final release. The model also allows the adding of functionality with each iteration and the delivery of a limited version once a sufficient set of features has been developed.

When Can I Begin Designing?

 The life-cycle model shows the design of the architecture as iterating with preliminary requirements analysis. Clearly, you cannot begin the design until you have some idea of the system requirements. On the other hand, it does not take many requirements in order for design to begin.

 An arc hi tec ture i s “ sha ped” by so me c ollec ti on of func tional, qua li ty, and bus i nes s requi rements ; W e call these shaping requirements architectural drivers and we see examples of them in our case studies like modifiability, performance requirements availability requirements and so on.

Dept. of CSE, SJBIT Page 131

 To determine the architectural drivers, identify the highest priority business goals. There should be relatively few of these. Turn these business goals into quality scenarios or use cases. 8.2 Designing the architecture;

A method for designing an architecture to satisfy both quality requirements and functional requirements is called attribute-driven design (ADD). ADD takes as input a set of quality attribute scenarios and employs knowledge about the relation between quality attribute achievement and architecture in order to design the architecture.

Attribute Driven Design

ADD is an approach to defining a software architecture that bases the decomposition process on the quality attributes the software has to fulfill. It is a recursive decomposition process where, at each stage, tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is allocated to instantiate the module types provided by the pattern. The output of ADD is the first several levels of a module decomposition view of an architecture and other views as appropriate.

Garage door opener example o Design a product line architecture for a garage door opener with a larger home information system the opener is responsible for raising and lowering the door via a switch, remote control, or the home information system. It is also possible to diagnose problems with the opener from within the home information system.

o Input to ADD: a set of requirements

 Functional requirements as use cases

 Constraints

 Quality requirements expressed as system specific quality scenarios o Scenarios for garage door system

 Device and controls for opening and closing the door are different for the various products in the product line

 The processor used in different products will differ

 If an obstacle is (person or object) is detected by the garage door during descent, it must stop

 within 0.1 second

 The garage door opener system needs to be accessible from the home information system for diagnosis and administration.

 It should be possible to directly produce an architecture that reflects this protocol

ADD Steps: Steps involved in attribute driven design (ADD)

1. Choose the module to decompose o Start with entire system o Inputs for this module need to be

available o Constraints, functional and quality requirements

2. Refine the module a) Choose architectural drivers relevant to this decomposition b) Choose

architectural pattern that satisfies these drivers c) Instantiate modules and allocate functionality from use cases representing using multiple views d) Define interfaces of child modules e) Verify and refine use cases and quality scenarios

Dept. of CSE, SJBIT Page 132

3. Repeat for every module that needs further decomposition Discussion of the above steps in more detail: