Oose Unit-3

us design - Design process - aifiter- User interface design - Case Study. Contents Software Design 32. Design Process 23. Design Concepts 44 Design Patterns 35. Model-View-Controller 46 Publisher-Subscriber Pattern 37 Adapter 38 Command 39 Strategy 310 Observer 411 Proxy 312 Facade 318 Role of architecture 44 Architectural Styles 2 {ayered Architectural Style io Ot Server Style 28 pp red Architecture dig He and Filter ‘Ser interface Design a » 2 Twa Marks Questions with Answers Design cone nce ~ Design patterns - Model-view-controtha - Observer - Proxy - Facade - Architectural « o-7 rE ’ nject Oriented Software Engineering 3-9 Software Design Pattern can be used for current work. Pattern can be used to solve similar kind of problem with different functionality. | BEG Information Hiding |" Ipformation hiding is one of the important property of effective modular design. The term information hiding means the modules are designed in such a way that information contained in one module cannot be accessible to the other module (the module which does not require this information). Due to information hiding only limited amount of information can be passed to other module or to any local data structure used by other module. ‘The advantage of information hiding is basically in testing and maintenance. Due to information hiding some data and procedures of one module can be hidden from another module. This ultimately avoids introduction of errors module from one module to another. Similarly one can make changes in the desired module without affecting the other module. Functional Independence « The functional independence can be achieved by developing the functional modules with single-minded approach. ¢ By using functional independence functions may be compartmentalized and interfaces are simplified. * Independent modules are easier to maintain with reduced error propagation. Functional independence is a key to good design and design is the key to software quality. ‘The major benefit of functional independence is in achieving effective modularity. © The functional independence is assessed using two qualitative criteria- Cohesion and coupling. EERE] cohesion . * With the help of cohesion the information hiding can be done. * A cohesive module performs only “one task” in software procedure with little interaction with other modules. In other words cohesive module performs only one thing. * Different types of cohesion are : 1. Coincidentally cohesive - The modules in which the set of tasks are related with each other loosely then such modules are called coincidentally cohesive.Softw. Object Oriented Software Engineering g- wee 2. Logically cohesive - i we need with each other is called logically cohesive. The module in which the tasks need to be ecutey bf ‘A module that performs the tasks that are logic 7 3. Temporal cohesion - some specific time span is called temporal cohesive. Procedural cohesion - When processing elements of a module are x, lat with one another and must be executed in some specific order then an module is called procedural cohesive. 5. Communicational cohesion - When the processing elements of a Modul share the data then such module is communicational cohesive. * The goal is to achieve high cohesion for modules in the system. Coupling *° Coupling effectively represents how the modules can be “connected” with other module or with the outside world. © Coupling is a measure of interconnection among modules in a program structure * Coupling depends on the interface complexity between modules. ° The goal is to strive for lowest possible coupling among modules in softwar design. * The property of good coupling is that it should reduce or avoid change impact and ripple effects. It should also reduce the cost in Program changes, testing and maintenance. * Various types of coupling are : i) Data coupling - The data coupl: ing is possible by parameter passing or éi? interaction. ii) Control coupling - The modules share relat iii) Common coupling - In common shared among the modules, iv) Content coupling - Content ted control data in control coupling coupling common data or a global data * ; a coupling occurs when.one module makes ¥% aintained in another module. Coupling Coupling represents ho wth ; = modules are connected with San e jfohesion, the cohesive module modules or with the outside word ¥ one thing. With coupling interg — ted pelos ‘ace complexity With Sohesion, data hiding can be Cohesiona vented Software Engineering Ben The goal of couplin, : - Software Design tower couping, “M6 TS Bal Of Shaan We ake Wl cohesion, re 7. Various types of couplings are - cea “atious types of cohesion are Data coupling, Control coupli 5 Camenion | coupling? “ana ene. Coincidental cohesion, Logical cohesion, coupling. Temporal cohesion, Procedural cohesion and| Communicational cohesion, oa Refactoring Refactoring is necessary for simplifying the design without changing the function or tehaviour. Fowler has defined refactoring as "the process of changing a software system insuch a way that the external behaviour of the design do not get changed, however the internal structure gets improved", Benefits of refactoring are - + The redundancy can be achieved. «Inefficient algorithms can be eliminated or can be replaced by efficient one. * Poorly constructed or inaccurate data structures can be removed or replaced. * Other design failures can be rectified. The decision of refactoring particular component is taken by the designer of the software system. Design Classes Design classes are defined as the classes that describe some elements of p domain, focus on various aspects of problem from user's point of view. The goal of design classes is : oe 1. To refine the analysis classes by providing the detail design, so that further implementation can be done easily. for implementing the infrastructure roblem of the software. 2. To create new set of classes There are five different types of design classes Fig. 3.3.2 Types of design classes ist for knowledg® TECHNICAL. PUBLIGATIONS® - an upthrust frObject Oriented Software Engineering 3-12 Software. | 1. User Interface Class The user interface class defines all the abstractions that are Bacednary for Huy Computer Interface(HCl). The user interface classes is basically a visual TePTesentation the HCI. 2. Business Domain Class Business domain classes are the refinement of analysis classes. These classes idengi the attributes and services that are needed to implement some elements. of business domain. 3. Process Class Process class implement lower level business abstractions used by the busines domain. 4. Persistent Class These classes represent the data store such as databases which will be retained as itis even after the execution of the software. 5. System Class These classes are responsible for software management and control functions that are used for system operation. Each class must be well formed design well formed design classes - *© Complete and Efficient A design class must be proj perly encapsulated with corresponding attributes and methods. Design class must ‘contain all those methods that are sufficient to achieve the intent of the class, * Primitiveness Methods associated with one class should not provide another © High Cohesion A cohesive designed class must responsibilities must be associated © Low Coupling class. Following are some characteristics of Particular class must Perform unique service and the Way to implement the s; ame service. Poses small, focused ; set of responsibilities and the® with all the attributes of that class. fend messages to the methods of neighbouring 4¢5®" classes only. TECHNICAL PUBLICATIONS® - an_ up-thrust for knowledgenject Oronted Software Engineering 3-13 Software Design Me review Questions 7, Describe decomposition levels of abstraction and modularity concepts in software design, 2, Explain about the various design concepts considered during design. Describe the concepts of cohesion and coupling. State difference between cohesion and coupling with a suitable example. What is modularity ? State its importance and explain coupling and cohesion. List and explain any five fundamental software design concepts. Design Patterns Pattern name "Definition of design pattern : Design Problem | pattern is general reusable solution to Design pattern commonly occurring problem within a aed given context in software design. Consequence Fig. 3.4.1 In general the pattern has four essential elements - tern name is used as handle to describe the design pattern. The Pattern name : The pat naming of the pattem increases the design vocabulary. Due to the name of the pattern it becomes easy to think about the design and to communicate the design with the others. Finding the appropriate name for the design pattern is one of the hardest and tricky part blem describes when to apply the pattern. It explains the problem Problem : The prol and its context. It might describe various things such as algorithm for the problem, the class or the object structure of the problem or it can list down the conditions that must be followed before applying the pattern. Solution : The solution describes the elements of the design, their relationships, responsibilities and collaborations. The solution never describes the concrete design or the implementation because the pattern is like templates and it can be applied to various Problems in varied situations. ‘The consequences describe the results and trade-offs of applying oncerned with space and time trade-offs. pattern. The consequences for software often c in evaluation of the design pattern. Consequence : The listing of consequences help: i TECHNICAL PUBLICATIONS® - an up-thrust for knowledge“ey Object Oriented Software Engineering 3-14 Software Deg, \ Generally the design pattem is divided into three categories - creational patie, structural pattern and behavioral pattern. Design pattern ~ Creational design Structural design Behavioral design pattern pattern pattern . Fig. 3.4.2 Categories of design pattern State the role and patterns while developing system design. CESS Solution : Sr.No Pattern : Role 1. Creator. The role of creator pattern is to find creator that needs to be connected] to the created object in any event. 2. Information expert This pattern assigns the responsibilities to various objects that ar participating in the system design. 3. Singleton This pattern ensures that a class has only one instance and provide global point of access to it. 4. Factory method Itis responsible for creating the instances of several derived classes. | | 5. + Bridge The role of this pattern is to separate out the interface from implementation without using inheritance. | 6 Adapter The role of this pattem is to allow the interface of existing dass to used from another interface. Observer ES role of this pattern is to define the link between objects 90 th! when one object's state changes, all objects are updated] automatically. Spee Se Strategy The role of this pattern is to define the family ly of algorithms} encapsulate these algorithms within in clea ae a interchangeable. Creational Pattern Creational design pattern are the design pattern that are used for object creation mechanism. This type of pattern is used in the situation when basic form of obje creation could result in design problems or increase complexity of a code base. The creational pattems show how to make the software design flexible. a a ere ae 3| \ object Oriented Software Engineering 3-16 Software Design \ ‘There are five well known design patterns that are part of creational pattern. These are- . Abstract factory pattern : This pattern is for creating the instances of several families of classes. 2. Builder pattern : This pattern separates the object construction from its representation. 3, Factory method pattern : This pattern is for creating the instances of several derived classes. 4, Prototype pattem : It specifies the kinds of objects to create using a prototypical instance and create new objects by copying this prototype. 5. Singleton pattern : It ensures that a class has only one instance and provides global point of access to it. Structural Pattern In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. The structural design pattern serves as a blueprint for how different classes and objects are combined to form larger structures. Structural patterns are just similar to data structures. There are various design patterns that are the part of structural design pattern - P Bridge : This pattern separates the object interface from its implementation. 2. Adapter : This pattern matches the interface of different classes. 3. Composite : This pattern is based on the tree structure of simple and composite objects. Decorator : In this pattern the responsibilities on the object are dynamic. Facade : In this pattern the single class represents the entire subsystem. Flyweight : This pattern makes use of fine-grained instance for efficient sharing. Private class data : In this pattern there is restricted access to the class data. eX ae eS . Proxy : In this pattern one object represents another object.Object Oriented Software Engineering 3-16 S Behavioural Pattern ee The behavioral design patterns are design patterns that identify communication patterns between objects and realize these patterns. By these patterns increase flexibility in carrying out this communication. Common doing %, A behavioral pattern explains how objects interact. It describes how different objects and classes send messages to each other to Make things happen and how the various tasks are divided among different objects, There are various design patterns that are the part of behavioral design pattern . 1. Chain of responsibility : The chain of responsibility pattern is a design patter that defines a linked list of handlers, each of which is able to Process requests, 2. Command : The command pattern is a design pattern that enables all of the information for a request to be contained within a single object. 5: Interpreter : This pattern specifies how to evaluate sentences in a language. Ths Pattern is useful when developing domain-specific languages or notations, 4. Iterator : This pattern is designed to sequentially access the elements of a collection. >. Mediator : In this pattern the communication between objects is encapsulated with a mediator object. Instead of classes communicating directly, classes send messages to the mediator and the mediator sends the. ‘se Messages to the other classes. 6. Null object : This pattern is designed to act as a default value of an object. 7. Memento : This pattern captures and restores an object's internal state. 8. Observer : The observer pattern is a design Pattern that defines a link betwee" objects so that when one object's state changes, all dependent objects updated automatically. 9. State : In this pattern it alters the object's behavior when its state changes. 10. Strategy : In this pattern, it encapsulates an algorithm inside a class. 11. Template method : This Pattern defers a the exact steps of an algorithm subclass. 12. Visitor : This class defines new Operation to class without changes.Object Oriented Software Engineering 3-17 ‘Software Design [: Write a short note on the structural patterns, EE] Model-View-Controller Problem : The user interface often gets changed when we extend the functionality of an application. Sometimes a customer may call for a specific user interface adaption. Different users may place conflicting requirements on the user interface. Building a system with required flexibility is expensive and error-prone if user interface is tightly interwoven with core functional logic. Solution The Model View Controller is also known as MVC architecture. It divides the whole application logic into three sections model, view and controller. This design pattern separates the user interface from core functional logic. Structure The working is as follows - 1. Suppose a user is requesting a web page from the server, then server will send this request to a specific controller. 2. The controller then asks to get the data from the model. 3. The model interacts with the database and sends the data to the controller on validation. 4 The controller then sends this data to the view in order to render it or to make a Presentation of that data. 5. The view sends the proper presentation of data to the controller. 6.The controller then sends this presentation to the client who requested the web Page. This presentation is considered a response to the client’s request.Object Oriented Software Engineering 3-18 Software Des, The following figure illustrates the above work. 6. Response Client Fig. 3.5.1 Model View Controller architecture > Participating classes : The purpose of each component of Model-View-Controller architecture is described as follows - Model 1) Ithandles the business logic or data logic. 2) It interacts with the database to get the requested data. 3) Itperforms the validation of that data. 4) It then sends the valid data to the controller. View 1) It prepares the presentation of the data received from the controller. 2) It then sends the presentation to the controller, Controller 1) It handles the request flow from client, to model and from model to the vie™ Again from view back to the client. 2) Sends the response to the client. Known uses : The MVC pattern is used mostly in web development applications. The best-known example of the use of the Model-View-Controller patter is the interface framework in the Smalltalk environment,Ng ne a yftware Engir nject Oriented Sor ingineering 3-19 Software Design > Consequences : ‘Advantages 1) It is easy to make modifications in separated from the presentation logic. 2) The development of applications becomes fast. 3) It is easy for the developers to collaborate and work together. 4) Development of application becomes fast. Disadvantages 1) Itis a complex architectural pattern and difficult to learn and implement. 2) For developing simple applications MVC is not a suitable design pattern as it adversely affects the performance of such applications. the application as the business ‘logic is Publisher-Subscriber Pattern Problem : A commonly arising situation is that data changes at one place and there exists many components depending on this data. For example in some GUI based application, if some internal data gets changed, then multiple views based on this data get affected. Solution To solve this problem there must be some dedicated component who can inform the changes in the data to all the dependent components. Hence, in the publisher subscriber pattern, one dedicated component takes the role of the publisher(also called as subject). All the components dependent on changes in the publisher are called its subscribers(also called as observer). The publisher maintains a registry of currently subscribed components. Whenever a component wants to become a subscriber, it makes use of subscribe interface offered by publisher. * Whenever the publisher changes the state, it sends the notification to all its subscribers. The subscribers then retrieve the changed data. Following are the freedoms used in publisher-subscriber pattern - © The publisher can decide which internal state changes it will notify to its subscribers. © An object can be subscriber to many publishers. © An object can take both the roles - it can be publisher or it can be a subscriber. Based on publisher-subscriber pattern the push and pull models are derived. TECHNICAL PUBLICATIONS® - an up-thrust for knowledgeae Object Oriented Software Engineering 3-20 Software ora Inthe push model, the publisher sends all the changed data to its subscribers, In the pull model, the publisher only sends minimal information about the chan to its subscribers. It is then subscribers’ responsibility to get the required data from the publisher whenever needed. . The push model has rigid dynamic behavior whereas the pull model is flexible, Structure : Event Publisher canbe pi Pro Proxy Proxy publisher suibserbet publisher Fig. 3.6.1 Publisher-Subscriber pattern Known uses : Event messaging : Publisher-Subscriber pattern is widely used in delivery logistics. As we shop online more frequently for a wider variety of goods, package delivery has become commonplace. Logistics companies need to use delivery resources more efficiently. To optimize delivery, dispatching systems need up-to-date information on where their drivers are, Pub/Sub-event messaging helps logistics companies do this. Advantages: 1) There is a support for distributed system, 2) Extensibility | Disadvantages : 1) Less efficient | 2) Complex pattern to implement Eid Adapter her because of some reason. In such a situaio® face two components, g < $ £ g 3 zy & Ssject Orianted Software Engineering 3-21 Software Design power cord in your laptop you can use an adapter. You plug the power cord in the adapter and the adapter in to laptop slot. problem: How to resolve incompatible interfaces. How to provide a stable interface to the components having different interfaces ? Solution Convert the original interface of component into another interface through intermediate adapter object. This pattern is also known as wrapper. This is a GoF pattern. There are two types of adapters - 1, Object adapters 2. Class adapters Object adapters : In this type of adapter pattern the adapter contains the instance of a class it wraps. When the Client wants some task to get fulfilled it makes a request to the Target. The Adapter inherits the Target and at the same time holds the instance of Adaptee. Hence a specific requests of Adaptee can be invoked by the Apdapter. Thus it is the Adapter who hides the Adaptees's interface from the client. It is illustrated in the Fig. 3.7.1(a). Class adapters : Call for Fun() Fig. 3.7.1 (a) Object adapter pattern In this type of adapter pattern the Adapter uses multiple polymorphic interfaces of Adpatee. Hence the number of requests of Adapteel,Adaptee2.., AdapteeN can be "Woked by the Apdapter. It is illustrated in the Fig. 3.7.1(b). TECHNICAL PUBLICATIONS® - an up-thrust for knowledgeObject Oriented Software Engineering 3-22 Sete cey | Fig. 3.7.1 (b) Class adapter pattern Example The typical examples of adapter pattern are WindowsAdapter in Swing API or JDBC. _ ODBC API. Benefits 1. Two compatible objects or classes can be interfaced using adapter pattern. 2. Reduces coupling between the objects,” 9: Due to use of polymorphism and indirection only essential behavior is focused. in MMe ely 1. Wt stort noteon apr patr ESTATE 2. What are the two types of ‘adapter pattern ? 3. Write short note on adapter. CORE 4. What is design pattern ? Explain the GoF design patterns, CEST Command * Command patter is one of the behavioural . used to implement loose coupling in a reque: I design patter. This design pattem is st-response model. The command pattern converts a request or an operation into a standalone object that contains all the information about the request. TECHNICAL PUBLICATIONS® - an Uup-thrust for knowledge.anject Oriented Software Engineering 3-23 Software Design ‘Also Known As Action, Transaction Motivation There is an encapsulation of the operational request of a sérvice into an entity called command so that the same service can be used to trigger different operations. Optionally the command can also be used for undo, logging or queueing operations. Participants Command_Interface : Declares an interface for executing an operation. ConcreteClass (Command_name...) i * Defines a binding between a Receiver object and an action. * Implements Execute by invoking the corresponding operation(s) on Receiver. Client (Application) : Creates a ConcreteClass object and sets its receiver. lnvoker (command) : Asks the command to carry out the request. Receiver (Receiver_item) : Knows how to perform the operations associated with carrying out a Tequest. Any class may serve as a Receiver. Structure '<>] Command texecute() ConereteCommand Receiver myReceiver TECHNICAL PUBLICATIONS® - an up-thrust for knowlarinaObject Oriented Software Engineering 13-24 te Implementation lass Invoker { private Command myCommand; public void setCommand(Command aCommand){ myCommand = aCommand; //actual command } public void trigger(){ myCommand.execute(); } } absract class Command { abstract void execute(); } class ConcreteCommand : Command { Private Receiver myReceiver; Public ConcreteCommand (Receiver aReceiver) { myReceiver = aReceiver; } Public void execute() { myReceiver.operation(); + 2 class Receiver { Public operation() { // operation here } Z class Client { © public static void Main(Stringl} args) { | Command c = new ConcreteCommand(new Receiver)); __ Invoker i = new Invoker() _ igetCommand(c); itrigger() Example Consider an application in which we wa 7 xt a int to perform some operations on a 1% Let us call it as FileOperation application, , These operations can be Read File ope?*" TECHNICAL PUBLICATIONS® . an yop‘Object Oriented Software Engineering 3-25 Software Design Write File operation using Read or Write commands. To implement Read and Write commands we need a text file. Hence the text file is called as Receiver over here. The ReadFileOperation and WriteFileOperation are the concrete classes that will invoke the commands Read and Write respectively. These methods are placed in the Receiver. Hence Receiver is something that will actually execute the commands. There is an Executor or an Invoker which will invoke the commands. The Invoker will have the list of commands that will be executing currently. This facility of Invoker is also useful if we want to perform undo operations. The Client is a command application. The Client calls the Invoker which in turn executes the desired command. To Summarize, Command : Read and Write operations Receiver : File on which the operations are to be performed. Invoker : Contains the list of commands that are currently executing Client : Will be using the Invoker to call the commands The implementation for the above example is as follows - //Command Interface public interface FileOperation { String execute(); + W{Concrete Class1 Public class ReadOperation implements FileOperation { Private Text_File myfile; Constructor Public ReadOperation(Text_File myfile) { ___ this. myfile = myfile; I "Public ‘WriteOperation(Text_File myfile) { _, this.nyfile = myfile;Sof Object Oriented Software Engineering 3-26 ftware etn ‘Public class Text File { _. private String file name; //Constractor public Text_File(String file_name) { ‘this.file_name = file_name; } Actual Code for Read Command public String Read() { retum "Reading a file: "+ file name; } //Actual Code for Write Command public String Write() { return "Writing to a file: "+ file name; } } ‘/invoker or Executor public class MyFileOperationInvoker { / creating list of operations private final list List = new ArrayList<>(); Public String executeCommand(FileOperation myOperation) { //Adding the currently invoked command to the ArrayList List.add(myOperation); return myOperation.execute(); 4 } {Client class Application _Client { public static void main(String args[]) { _ {client is invoking the invoker or Executor ‘MyFileOperationInvoker myExecutor = new MyFileOperationInvoker(); /fUsing Executor object the command for execution =e _ myBxeoutor.executeCommand(new ReadOperation(ne w Text File(‘test1.txt"))); myExecutor.executeCommand(new WriteOperation ( one m new Text_File(‘test1.txt")));ject Oriented Software Engineering 9-27 iat Citen ) Merits and Demerits "merits 1)New commands can be easily added to the existing application. 2)Itis easy to perform redo and undo operations while using the commands. 3) It decouples the classes that invoke the operation from the object that knows how to execute the operation Demerit 1) Using command design pattern may requires more effort on implementation, since each command requires a concrete command class, which will increase the number of classes significantly. Strategy Intent ¢ There are common situations when classes differ only in their behavior. For this case, is a good idea to isolate the algorithms in separate classes in order to have the ability to select different algorithms at runtime. © This is a kind of design pattern in which a set of similar algorithms to be defined and encapsulated in their own classes. Thus this pattern is intended to define a family of algorithms, encapsulate each of them and make them interchangeable. * Strategy is like Template Method. Structure and Implementation Following is an UML diagram which represents how to implement strategy design Pattern. Client class makes use of interchangeable algorithms. It maintains the reference to Strategy object. TECHNICAL PUBLICATIONS® - an up-thrust for knowedge.Fig. 3.9.1 Representation of strategy IStrategy declares an interface common to all supported algorithms. The client uses this interface to call the algorithm defined by a Implementation1, Implementation? and soon. Implementation1, Implementation2 represent instances that provide different algorithms that can be used by the client. The skeleton code for this can be as given below ‘static class Program Public static void main(String arg{]) { /fnvoking the algorithm() of Implementation1 ; /fnwvoking the algorithm() of Implementation? B. ‘public class Client //declaring strategy object ‘public abstract class IStrategy A public void algorithm(); bs public class Implementation! extends Istrategy : public void algorithm() vi a TECHNICAL PUBLICATIONS® an go- njet Oriented Software Engineering eee Pipe class Implementation extends IStrategy {le void algorithm() { } } Example : In online shopping system modes of payment is a typical example of strategy pattern. The online payment mode can be card payment, cash payment and so on. > Merits and Demerits Merits 1.If one needs to have several different behaviours that the object to perform, it is much simpler to keep track of them if each behaviour is a separate class. One can add, remove or change any of the behaviours very easily. 2. This strategy brings the flexibility in the code. 3, When you have several objects that are basically the same and differ only in their behaviour, it is a good idea to make use of the strategy pattern. Demerits 1. The application must be aware. of all the strategies to select the right one in right situation. 2. The memory requirement for implementing this pattern is more as Client has to maintain the object of Strategy base class, in order to choose appropriate algorithm each time. (EEEREREED For tie description given below, draw the class diagram and identify the roles for @ strategy design pattern. Mention the roles identified for each class and its relevant behaviour in the class diagram. Grand health club offers a scheme for membership of the health club, The optioris available for registering are "yoga’ and ‘aerobics’. The monthly charges for aerobics membership are 2000.00. The monthly charges for yoga membership are 1000.00. The members can avail a single option out of the two options. If a person books for three months, he gets 20 % discount. If he books for six months, he gets 25 percent discount. If he books for nine month, he gets 35 % discount. If he books for one year, he gets 50 discount, :8 Object Oriented Software Engineering cea otware Design Solution : option . +monthly_charge ThreeMonths SixMonths NineMonths OneYear +discount = 20% | | +discount = 25% | | +discount = 35% | | +discount = 50% Fig. 3.9.2 Apply strategy design pattern to the following and draw the class diagram. A company has many employees. Each employee has a name and a performance index in the range of 1 to 5. When the index is 2, the increment 45 10 percent of the previous year salary. ‘3 the increment is 15 percent of the previous year salary, 4 the increment is 20 percent of the previous year salary and when 5 the increment is 25 percent of the previous year salary. Indicate the roll of each class in the class diagram, Solution : [Snares | rforman *¥performance_index = @ tincrment = 25%'P Fig. 3.9.3Software Engineering 3-31 mie po Observer Intent The observer pattern is a design pattern that defines a link between objects so that when one object's state changes, all dependent objects are updated automatically. This pattern allows communication between objects in a loosely coupled manner. Software Design Structure and Implementation Following is an UML diagram which represents how to implement observer design pattern. Observable interface or abstract class defining the operations for attaching and de- attaching observers to the client. It is also called as subject. Observable Observer notify( ) : void update( ) ‘ConereteObserver 2 Fig. 3.10.1 Representation of observer update ) ConcreteObservable is a concrete Observable class. It maintain the state of the object and when a change in the state occurs it notifies the attached Observer. Observer is the interface or abstract class defining the operations to be used to notify this obj ject. ConcreteObserver1, ConcreteObserver?2 are concrete Observer implementations.Object Oriented Software Engineering sae Sette Resigy The flow of execution is as follows - The main function instantiate the ConcreteObservable object. Then it instantiat attaches the concrete observers to it using the methods defined in the Ob, interface. Each time the on the change in state, it notifies all the attache ConcreteObservers using the methods defined in the Observer interface. e ang 'Servable > Merits and Demerits Merits 1. This pattern is useful when there is a change of state in one object that must be reflected in another object. 2. The new observers can be added easily with the minimal changes in the entire code. 3. It allows to send the data to many other objects in very efficient manner, Demerits When there are several Observabels(subj Telations that need to be maintained. Due to Proxy Intent jects) and Observers then there are multiple which the overall code becomes complex. Provides the placeholder for another object to control access to it, Also Known as Surrogate Motivation * In this pattern the class represents the functionality of another pattern. . This type of pattern belongs to structural design pattern, ‘The intention ofthis pattem isto provide a dient for an object to control access Using extra level of indirection controlled and intelligent access can be provided: The proxy object gives the client that actual request is handled by the proxy:~ \ pect Oriented Software Engineering Stas Software Design. \ structure , \ Following UML diagram represents how to implement proxy design pattern. \ <> Distiemeneeee ae implements implements . Proxyltem ( ItemName: String *realltem: Realliem +ltemName: String, +Proxyltem(), +display(): void +Realltem() +display(): void ‘tgetitem(): void 4main(): void Fig. 3.11.1 Representation of proxy Implementation When client needs some item, it will actually use the Proxyltem to get an objet for Item. The Item is an interface which is implemented by the concrete classes RealItem and Proxyltem, The Proxyltem is a proxy class which uses the instance of Realltem. The skeleton code for the above representation is as given below The interface is created as follows The concrete classes Realltem and Proxy! ‘Item are as follows - ‘priar eaTIONS® - an up-thnust for knowledgeObject Oriented Software Engineering 3-34 Seta, \ Realltemjava Public class Realltem implements Item { private String ItemName; public Realltem(String ItemName) { this ItemName = ItemName; getitem(ItemName); } public void display() { System.out.printin(‘Displaying Item : " +ItemName); } private void getitem(String ItemName) { ‘System out printin("Item: " +ItemName +" is obtained’); } p3 Proxyltem.java Public class Proxyitem implements Item i private Realltem myltem; private String ItemName; public Proxyltem(String ItemName) { this.ItemName = ItemName; myltem = new Realltem(ItemName); myltem.display(); t & Clientjava public class Client Pees public static void main(String}} args) { Item item = new Proxyltem("MyFavorite Item’); ‘/ivem will be obtained using getitem first and then will be displayed ‘Sidiiiedied den‘The payment made by the customer by cheque or by bank demand draft is proxy for the actual cash present in the account. A cheque or DD can be used in place of cash for making purchases and ultimately controls access to cash in the issuer's account. > Merits and Demerits Merits 4, Security is the most primary advantage of this remains protected from the client access by providing the pro this saves the system's memory space design pattern. The main object xy instance. 2. The duplication of the object can be avoided, and also increases the performance of application. Demerits The conflicts in the behavior of the system may occur if one client real object and another client accesses the proxy object. 1. Explain the proxy designer pattern with directly accesses the suitable example. Fagade The Fagade design pattern is a s! word facade which means “frontage” OF “face”. It defines the high-level interface that makes the sub: tructural design pattern. It is evolved from the French system easier to use. Intent * Provide a unified’ interface higher-level interface that makes the subsyste! * Wrap a complicated subsystem with a simpler interface. to a set of interfaces in a subsystem. Facade defines a m easier to use. Motivation th To simplify the complex system archi Facade object is used. The Facade shield: tecture by unifying it with different interfaces, the complexity of the system from the client. ~ hcl a SeObject Oriented Software Engineering 90. Software oy Structure Subsystemt Cast Fig. 3.12.1 Example Consider a scenario where a customer has some issues with the product he/she has Purchased. So the customer calls makes a call on customer care number and speaks witha customer service representative. The customer care service person acts as a Facade Providing an interface to the order fulfilment. The underlying system may include a tean of service engineers. The corresponding service engineer of that region is then assigned duty to look after the complaint raised by thé customer and solve the complaint. The order of execution will be - 1) Customer calls the ProductServiceSystem 2) The customer care service person then hands it over to a subsystem that assigns the appropriate service engineer. 3) The service engineer visits the customer and solves the issue raised by th customer. ImplementationvWwO ee object Oriented Software Engineering 3-37 ‘Software Desigit pani class CustomerCareServicePerson(){ private ProductServiceSystem service; __ private ServiceEngineer engineer; " gervice.assignServiceEngineer(); _ engineer.getRequest(); engineer fulfllRequest 3% ~~ > Merits and Demerits Merits 1) Ithides much of the complexity and makes the subsystem easy to use. 2) It helps to have the principle of loose coupling, so changes can be made to the system without affecting the clients. 7 t —_Demerits i 1) It incorporates the additional level of indirection. 2) There is high degree of dependence on facade interface. 3) Clients cannot access underlying classes and certain functionalities might be unavailable to clients. acl /s 1. Explain the intent, motivation, structure, implementation, merits and demerits of Facade design pattern. Role of Architecture © Architecture is a design of a system which gives a high level view of the parts of the systems and focus on the relationship among these subsystems. * There is no unique structure of the system which can be described by the architecture. In fact there are various types of structures. Hence the architecture can be formally defined as Definition : Software architecture of the system is a structure or structures of the system Which consists of software elements and the externally visible properties of those Clements and relationships among them., 3-38 Software Object Oriented Software Engineering tion the elements that have some important Properties + According to this defini f these elements is a pay, ; a considered as the main elements. The behaviour o! architecture. - © The uses of the software architecture descriptions a |. Understanding and communication se 4. Under The software architecture description is for communicating the architecture g ° the system to its users, developers and to the architects. This description hes these stakeholders(users, developers and architects) to understand the micrp properties of the system and how the system satisfies the functional and Quality requirements. o. The architecture description of proposed system will describe how the system will be composed and what the parts of it are. This will help in understanding te ) proposed system. ©. The architecture description is also useful for understanding the existing system, 2. Reuse © Software architecture helps in reusing the software. The software reuse help in increasing the productivity and decreasing the cost of software. © Software engineers are working for developing such software components thi will be useful for building any desired software system. Then architectures ar chosen in such a manner that these components will be reused effectively. © If there are similar types of products then architectures suggest the components that can be reused in similar products. 3. Construction and evolution © For construction of the system, the Partitioning is done. © Architecture partitions the need to be inco - ide system will get effare yin the S¥stem then architecture 44 made carefully without disturbingeo Bae es nest ‘oriented Software Engineering 3-39 Software Design 4. Analysis: , Before building the actual system some important properties of the system can be determined. The software engineers use the models to analyze the design of a product for its cost, reliability and performance. Architecture helps in determining such models. o The properties of the system that has to be build can be predicted if the system is developed from the architecture. Thus architecture description helps in analyzing the system before its actual development. | What is software architecture ? Also explain the uses of software architecture description. Eady Architectural Styles * Architectural style is a pattern for creating the system architecture for the given problem. Most of the large systems are heterogeneous and do not follow a single architectural style. These styles can provide ideas for creating an architectural view for the given problem. Styles can be combined to form richer views. Many systems use multiple styles and different parts of a system may use different styles. Various architectural styles are - © Layered architectural style © Client Server style © Tiered architecture © Pipe and Filter style EEG Layered Architectural Style * The layered architecture is composed of different layers. Each layer is intended to Perform specific operations so machine instruction set can be generated. Various components in each layer perform specific operations.3-40 1 Desi, “User interface layer ‘Application layer utility layer performing various operations Fig. 3.15.1 Layer architecture of components * The outer layer is responsible for performing the user interface operations while the components in the inner layer perform operating system interfaces. + The components in intermediate layer perform utility services and application software functions. Client Server Style ¢ In this style, there are two component types client and server, * The client can communicate to the server but Not to another client, * The communication between the client and server is initiated by the client. The client sends the request to the server and for service and the server supports. nt on a specific port, Then it builds th med to the client, The server receives any request from the clie requested service and then the result is retu blocked until the request Bets a replay.

Oose Unit-3

Uploaded by

Copyright:

Available Formats

Oose Unit-3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oose Unit-3

Uploaded by

Copyright:

Available Formats

You might also like