Use case diagrams: Depicts the typical interaction between external users (actors) and the system. The
emphasis is on what a system does rather than how it does it. A use case is a summary of scenarios for a
single task or goal. An actor is responsible for initiating a task. The connection between actor and use case is a
communication association.
Class diagrams: Class diagram technique is vital within Object Oriented methods. Class diagrams describe the types of objects in the system and the various static relationships among them. Class diagrams also show the
attributes and the methods. Class diagrams have the following possible relationships:
Association: A relationship between instances of 2 classes.
Aggregation: An association in which one class belongs to a collection (does not always have to be a
collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part can
exist without the whole. For example: A line item is whole and the products are the parts. If a line item is
deleted then the products need not be deleted.
Many-to-Many Ex: Category, Experiment
Composition: An association in which one class belongs to a collection (does not always have to be a
collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part cannot
exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole
and the line items are the parts. If an order is deleted then all the line items should be deleted as well (ie
cascade deletes).
One to many or One-to-One: Ex: Experiment, Wavelength
Generalization: An inheritance link indicating that one class is a super class of the other. The Generalization
expresses the “is a” relationship whereas the association, aggregation and composition express the “has a”
relationship.
Ex: Promotions; coupons, one stop
Dependency: A dependency is a weak relationship where one class requires another class. The dependency
expresses the “uses” relationship. For example: A domain model class uses a utility class like Formatter etc.
Sequence diagrams: Sequence diagrams are interaction diagrams which detail what messages are sent and
when. The sequence diagrams are organized according to time. The time progresses as you move from top to
bottom of the diagram. The objects involved in the diagram are shown from left to right according to when they
take part.
Package diagrams: To simplify complex class diagrams you can group classes into packages.
Façade pattern: The façade pattern provides an interface to large subsystems of classes. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a façade object that provides a single, simplified interface.
The Front Controller suggests that we only have one Servlet (instead of having specific Servlet for each specific
request) centralising the handling of all the requests and delegating the functions like validation, invoking business
services etc to a command or a helper component. For example Struts framework uses the command design
pattern to delegate the business services to an action class.
Benefits
Avoid duplicating the control logic like security check, flow control etc.
Apply the common logic, which is shared by multiple requests in the Front controller.
Separate the system processing logic from the view processing logic.
Provides a controlled and centralized access point for your system.
Command pattern: The Command pattern is an object behavioral pattern that allows you to achieve complete
decoupling between the sender and the receiver. (A sender is an object that invokes an operation, and a receiver is an object that receives the request to execute a certain operation. With decoupling, the sender has no knowledge of the Receiver's interface.) The term request here refers to the command that is to be executed. The Command pattern also allows you to vary when and how a request is fulfilled. At times it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. In procedural languages, this type of communication is accomplished via a call-back: a function that is registered somewhere to be called at a later point.Commands are the object-oriented equivalent of call-backs and encapsulate the call-back function.
83: What is a business delegate? Why should you use a business delegate?
Problem: When presentation tier components interact directly with the business services components like EJB,
the presentation components are vulnerable to changes in the implementation of business services components.
Solution: Use a Business Delegate to reduce the coupling between the presentation tier components and the
business services tier components. Business Delegate hides the underlying implementation details of the business
service, such as look-up and access details of the EJB architecture.
What is a session façade?
A 84: Problem: Too many method invocations between the client and the server will lead to network overhead, tight
coupling due to dependencies between the client and the server, misuse of server business methods due to fine
grained access etc.
Solution: Use a session bean as a façade to encapsulate the complexities between the client and the server
interactions. The Session Facade manages the business objects, and provides a uniform coarse-grained service
access layer to clients.
Session façade is responsible for
Improving performance by minimizing fine-grained method calls over the network.
Improving manageability by reducing coupling, exposing uniform interface and exposing fewer methods to
clients.
Managing transaction and security in a centralised manner.
emphasis is on what a system does rather than how it does it. A use case is a summary of scenarios for a
single task or goal. An actor is responsible for initiating a task. The connection between actor and use case is a
communication association.
Class diagrams: Class diagram technique is vital within Object Oriented methods. Class diagrams describe the types of objects in the system and the various static relationships among them. Class diagrams also show the
attributes and the methods. Class diagrams have the following possible relationships:
Association: A relationship between instances of 2 classes.
Aggregation: An association in which one class belongs to a collection (does not always have to be a
collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part can
exist without the whole. For example: A line item is whole and the products are the parts. If a line item is
deleted then the products need not be deleted.
Many-to-Many Ex: Category, Experiment
Composition: An association in which one class belongs to a collection (does not always have to be a
collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part cannot
exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole
and the line items are the parts. If an order is deleted then all the line items should be deleted as well (ie
cascade deletes).
One to many or One-to-One: Ex: Experiment, Wavelength
Generalization: An inheritance link indicating that one class is a super class of the other. The Generalization
expresses the “is a” relationship whereas the association, aggregation and composition express the “has a”
relationship.
Ex: Promotions; coupons, one stop
Dependency: A dependency is a weak relationship where one class requires another class. The dependency
expresses the “uses” relationship. For example: A domain model class uses a utility class like Formatter etc.
Sequence diagrams: Sequence diagrams are interaction diagrams which detail what messages are sent and
when. The sequence diagrams are organized according to time. The time progresses as you move from top to
bottom of the diagram. The objects involved in the diagram are shown from left to right according to when they
take part.
Package diagrams: To simplify complex class diagrams you can group classes into packages.
Façade pattern: The façade pattern provides an interface to large subsystems of classes. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a façade object that provides a single, simplified interface.
The Front Controller suggests that we only have one Servlet (instead of having specific Servlet for each specific
request) centralising the handling of all the requests and delegating the functions like validation, invoking business
services etc to a command or a helper component. For example Struts framework uses the command design
pattern to delegate the business services to an action class.
Benefits
Avoid duplicating the control logic like security check, flow control etc.
Apply the common logic, which is shared by multiple requests in the Front controller.
Separate the system processing logic from the view processing logic.
Provides a controlled and centralized access point for your system.
Command pattern: The Command pattern is an object behavioral pattern that allows you to achieve complete
decoupling between the sender and the receiver. (A sender is an object that invokes an operation, and a receiver is an object that receives the request to execute a certain operation. With decoupling, the sender has no knowledge of the Receiver's interface.) The term request here refers to the command that is to be executed. The Command pattern also allows you to vary when and how a request is fulfilled. At times it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. In procedural languages, this type of communication is accomplished via a call-back: a function that is registered somewhere to be called at a later point.Commands are the object-oriented equivalent of call-backs and encapsulate the call-back function.
83: What is a business delegate? Why should you use a business delegate?
Problem: When presentation tier components interact directly with the business services components like EJB,
the presentation components are vulnerable to changes in the implementation of business services components.
Solution: Use a Business Delegate to reduce the coupling between the presentation tier components and the
business services tier components. Business Delegate hides the underlying implementation details of the business
service, such as look-up and access details of the EJB architecture.
What is a session façade?
A 84: Problem: Too many method invocations between the client and the server will lead to network overhead, tight
coupling due to dependencies between the client and the server, misuse of server business methods due to fine
grained access etc.
Solution: Use a session bean as a façade to encapsulate the complexities between the client and the server
interactions. The Session Facade manages the business objects, and provides a uniform coarse-grained service
access layer to clients.
Session façade is responsible for
Improving performance by minimizing fine-grained method calls over the network.
Improving manageability by reducing coupling, exposing uniform interface and exposing fewer methods to
clients.
Managing transaction and security in a centralised manner.
