Answer: use xor to swap:
a = a^b
b= a^b
a= a^b
Thursday, July 22, 2010
Interview questions
Question: How to swap two variables, without using third variable ?
Answer: use xor to swap:
Answer: use xor to swap:
Monday, July 12, 2010
What is context diagram?
The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities (systems, organizational groups, external data stores, etc.).
Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be helpful.
A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information system. DFDs are one of the three essential components of the structured-systems analysis and design method (SSADM). A DFD is process centric and depicts 4 main components.
Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many analysis tools they have been leveraged for other purposes. For example, they can also be leveraged to capture and communicate the interactions and flow of data between business processes. So, they don’t have to be restricted to systems analysis.
A sample Context Diagram is shown here.
A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or synchronization of processes such as which processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow which can show these things.
Some of the benefits of a Context Diagram are:
A number of factors should be considered when deciding what approach to use (top down or bottom up) to create a Context Diagram. First let’s be clear about what each approach means.
The top-down approach: this approach refers to starting directly with the Context Diagram and creating it from scratch. This is done by placing the system under consideration in the center and then identifying each of its interactions based on either the analyst’s current knowledge or by asking others who may have the knowledge.
The bottom-up approach: this approach refers to starting with a lower level data-flow diagram, identifying known processes and the data that flows between them, and then following the data trail to uncover other unknown processes. After the lower-level data-flow diagram is completed, the processes can be rolled up to the system level.
The top-down approach is a more direct approach and is often the direction many analysts choose to take (whether right or wrong for their particular situation). It can work well under some circumstances, particularly if the system under consideration has only a few interactions with external entities or if the same analysts support the application on an ongoing basis and are very familiar with all of the possible interactions and dependencies that the system has. But if the system has a very large number of interactions and dependencies or if the analyst is unfamiliar with the system then this approach can be difficult. The less informed analyst would need to rely on a very iterative approach where the context diagram is evolved over time by reviewing it with a number of subject matter experts that understand pieces of the environment.
The bottom-up approach is a less direct method, but can be exceptionally valuable as an investigative technique. Starting with a lower-level data flow diagram allows the analyst to document the bits and pieces of the system that are understood and then follow the data to identify the various system interactions and dependencies that exist. This tends to be a more natural approach as it uses the power of the technique to document the entire scope of the system and its surrounding environment. In the top-down approach it can be difficult to know when the analyst has reached completion since it’s hard to know that which you don’t know. In the bottom-up approach the data-flow diagramming technique itself drives the analyst to a state of completion.
Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be helpful.
A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information system. DFDs are one of the three essential components of the structured-systems analysis and design method (SSADM). A DFD is process centric and depicts 4 main components.
- Processes (circle)
- External Entities (rectangle)
- Data Stores (two horizontal, parallel lines or sometimes and ellipse)
- Data Flows (curved or straight line with arrowhead indicating flow direction)
Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many analysis tools they have been leveraged for other purposes. For example, they can also be leveraged to capture and communicate the interactions and flow of data between business processes. So, they don’t have to be restricted to systems analysis.
A sample Context Diagram is shown here.
A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or synchronization of processes such as which processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow which can show these things.
Some of the benefits of a Context Diagram are:
- Shows the scope and boundaries of a system at a glance including the other systems that interface with it
- No technical knowledge is assumed or required to understand the diagram
- Easy to draw and amend due to its limited notation
- Easy to expand by adding different levels of DFDs
- Can benefit a wide audience including stakeholders, business analyst, data analysts, developers
A number of factors should be considered when deciding what approach to use (top down or bottom up) to create a Context Diagram. First let’s be clear about what each approach means.
The top-down approach: this approach refers to starting directly with the Context Diagram and creating it from scratch. This is done by placing the system under consideration in the center and then identifying each of its interactions based on either the analyst’s current knowledge or by asking others who may have the knowledge.
The bottom-up approach: this approach refers to starting with a lower level data-flow diagram, identifying known processes and the data that flows between them, and then following the data trail to uncover other unknown processes. After the lower-level data-flow diagram is completed, the processes can be rolled up to the system level.
The top-down approach is a more direct approach and is often the direction many analysts choose to take (whether right or wrong for their particular situation). It can work well under some circumstances, particularly if the system under consideration has only a few interactions with external entities or if the same analysts support the application on an ongoing basis and are very familiar with all of the possible interactions and dependencies that the system has. But if the system has a very large number of interactions and dependencies or if the analyst is unfamiliar with the system then this approach can be difficult. The less informed analyst would need to rely on a very iterative approach where the context diagram is evolved over time by reviewing it with a number of subject matter experts that understand pieces of the environment.
The bottom-up approach is a less direct method, but can be exceptionally valuable as an investigative technique. Starting with a lower-level data flow diagram allows the analyst to document the bits and pieces of the system that are understood and then follow the data to identify the various system interactions and dependencies that exist. This tends to be a more natural approach as it uses the power of the technique to document the entire scope of the system and its surrounding environment. In the top-down approach it can be difficult to know when the analyst has reached completion since it’s hard to know that which you don’t know. In the bottom-up approach the data-flow diagramming technique itself drives the analyst to a state of completion.
Subscribe to:
Posts (Atom)