Warnier-Orr diagram

Warnier-Orr diagram is a graphic charting technique used in software engineering for system analysis and design purposes. They were initially developed in France by Jean-Dominique Warnier & in the US by Kenneth Orr.This is a kind of hierarchical flowchart that allow the description of the organization of data and procedures.These diagrams are very much similar to the flow charts, but they look like pseudo code rather than blocks and shapes. These are the graphical representations of algorithms. These diagrams help the programmers work on, and record one problem before moving into the next problem or next part. So, that confusion in the complexity of the program will be reduced. This gives the ability to understand the logical structure of the program without getting confused in the complexity of that program. These diagrams are easy to understand and also easy to create. This method aids the design of program structures by identifying the output & processing results & then working backwards to determine the steps & combinations of input needed to produce them. The simple graphic method used in Warnier/Orr diagrams makes the levels in the system evident and the movement of the data between them vivid.

This diagram shows the processes and sequences very well. Each process is very well clearly explained as by having sub processes in it. These are represented by a bracket, grouping its components. Every process is designed in a hierarchical manner.

To construct a WO diagram, one should move backwards and construct it, such as start from the output and should do analysis backwards. There is a advantage of showing data in processes and in steps and sequences and also flow of data from level to level.

Lets have a quick description of elements of WO diagram

Bracket: A bracket encloses a level of decomposition in a diagram. It reveals what something "consists of" at the next level of detail.

Sequence: The sequence of events is defined by the top-to-bottom order in a diagram. That is, an event occurs after everything above it in a diagram, but before anything below it.

OR: You represent choice in a diagram by placing an "OR" operator between the items of a choice. The "OR" operator looks either like or .

AND: You represent concurrency in a diagram by placing an "AND" operator between the concurrent actions. The "AND" operator looks either like or .

Repetition: To show that an action repeats (loops), you simply put the number of repetitions of the action in parentheses below the action.

The diagram below illustrates the use of these constructs to describe a simple process.

You could read the above diagram like this:

"Welcoming a guest to your home (from 1 to many times) consists of greeting the guest and taking the guest's coat at the same time, then showing the guest in. Greeting a guest consists of saying "Good morning" if it's morning, or saying "Good afternoon" if it's afternoon, or saying "Good evening" if it's evening. Taking the guest's coat consists of helping the guest remove their coat, then hanging the coat up."

As you can see, the diagram is much easier to understand than the description.

The Warnier-Orr Diagram is read from left to right and from top to bottom within a bracket.

There are mainly 8 fundamental building blocks in this WO diagram, they are as follows:

· Hierarchy

· Sequence

· Selection

· Complement

· Repetition

· Concurrency

· Begin/End Blocks

· Recursion

Hierarchy:

Hierarchy on a Warnier-Orr Diagram is represented with brackets.

Sequence:

Sequence represents the order in which the tasks to be done, by listing them one below the other.

Selection:

Selection is used to allow choices between more than two tasks.

Complement:

Complement is nothing but the logical not condition.

Repetition:

Repetition provides looping.

Concurrency:

Concurrency allows different tasks to be done at the same time.

Begin/End Blocks:

Here, the Begin block holds the operations performed in the beginning of the task and End block contains operations performed at the end of the task.

Recursive:

Recursive block contains itself a sub process in it.

In this way, any process in any organization can be explained clearly to everyone, because its nothing but the step wise explanation of the task to be performed.

Cartogram

Cartogram

Cartograms which are called as diagrammatic maps are used for spatial transformations. A cartogram is a graphic that shows the attributes of geographical objects as the object’s area. Cartogram is a well-known technique showing geography-related statistical information, such as population demographics and epidemiological data. The basic idea is to distort a map by resizing its regions according to a statistical parameter, but in a way that keeps the map recognizable. Using cartograms, regularities in the spatial distribution phenomena and interactions among them can be observed more easily. These are used in geographical investigations, especially for electoral votes or population counts purpose. Cartograms are classified into two categories, they are • Linear • Area Area Cartograms are referred as value-by-area map or isodemographic map particularly used for population cartograms, which uses the relative sizes of the populations of the countries of the world, by scaling the areas of each countries to the proportion of its population. Distance Cartogram is also called as central-point cartogram. This is used to show relative travel times and directions from vertices in a network. Cartograms vary on their degree in which geographic space is changed; some appear very similar to a map, however some look nothing like a map at all. There are three main types of cartograms, each have a very different way of showing attributes of geographic objects- Non-contiguous, Contiguous and Dorlingcartograms.


NON-CONTIGUOUS CARTOGRAMS

Non-contiguous Cartogram is the simplest type of the cartogram. In this the geographic objects do not have to maintain connectivity with their adjacent objects. This connectivity is called as topology. By freeing the objects from their adjacent objects, they can grow or shrink in size and still maintain their shape.
















CONTIGUOUS CARTOGRAMS

In contiguous cartogram topology is maintained , but this causes great distortion in shape. This leads to the single most difficult, but intriguing problem in creating cartograms. The cartographer must make the objects the appropriate size to represent the attribute value, but he or she must also maintain the shape of objects as best as possible, so that the cartogram can be easily interpreted.

DORLING CARTOGRAMS

This cartogram is named after its inventor Danny Dorling of the University of Leeds. A Dorling cartogram maintains neither shape, topology nor object centroids, though it has proven to be a very effective cartogram method. To create a Dorling cartogram, instead of enlarging or shrinking the objects themselves, the cartographer will replace the objects with a uniform shape, usually a circle, of the appropriate size. Professor Dorling, for the reason described above in the non-contiguous cartogram section, suggests that the shapes not overlap but rather be moved so that the full area of each shape can be seen. Another Dorling-like cartogram is the Demers Cartogram, which is different in two ways. It uses squares rather than circles; this leaves fewer gaps between the shapes. Secondly, the Dorling Cartogram attempts to move the figures the shortest distance away from their true locations; the Demers cartogram often sacrifices distance to maintain contiguity between figures, and it will also sacrifice distance to maintain certain visual cues. Most Populated Counties in California are labeled in each of the two cartograms below for reference.
















PSEUDO-CARTOGRAMS

Pseudo-cartograms (or false cartograms) are representations that may look like cartograms but do not follow certain cartogram rules. Perhaps the most famous type of pseudo-cartogram was developed by Dr. Waldo Tobler. In this case, instead of enlarging or shrinking the objects themselves, Tobler moves the object's connections to a reference grid such as latitude or longitude in order to give the same effect. This maintains good directional accuracy in the cartogram however, this is a false cartogram because it creates extensive error in the actual size of the objects.

Cause and Effect Diagram

Cause & Effect Diagram

The cause and effect diagram was first used by Kaoru Ishikawa in 1943 to explain to a group of engineers working in Kawasaki steel works about working process and how various work factors could be stored and related. For this reason these diagrams are called as Ishikawa diagrams, and also called by many names like fish-bone diagrams because they look like a fish skeleton. These are also called as Cause and Effect diagrams because they help us to think of all the possible causes of the problem instead of just considering the most obvious ones. These diagrams are one of the types used in quality management techniques. When utilizing a team approach to problem solving, there are often many opinions as to the problem's root cause. One way to capture these different ideas and stimulate the team's brainstorming on root causes is the cause and effect diagram, commonly called a fishbone.

This diagram provides a structured way to help you think through all possible causes of a problem. This helps us top carry out a thorough analysis of a situation.

Steps to be followed to solve a problem using Cause and Effect diagram are:

• Identify the problem
• Work out the major factors involved
• Identify possible causes
• Analyze your diagram

To construct a fishbone, start with stating the problem in the form of a question, such as 'Why is the help desk's abandon rate so high?' Framing it as a 'why' question will help in brainstorming, as each root cause idea should answer the question. The team should agree on the statement of the problem and then place this question in a box at the 'head' of the fishbone.

The rest of the fishbone then consists of one line drawn across the page, attached to the problem statement, and several lines, or 'bones,' coming out vertically from the main line. These branches are labeled with different categories. The categories you use are up to you to decide.

You should feel free to modify the categories for your project and subject matter.

Once you have the branches labeled, begin brainstorming possible causes and attach them to the appropriate branches. For each cause identified, continue to ask 'why does that happen?' and attach that information as another bone of the category branch. This will help get you to the true drivers of a problem.

Once you have the fishbone completed, you are well on your way to understanding the root causes of your problem. It would be advisable to have your team prioritize in some manner the key causes identified on the fishbone.

Cause Enumeration

In general, it is difficult to identify which are the main causes. In such situations there are ways of identifying them effectively.

• Brain storm and get a list of causes.
• Sort the list by grouping
• Identify each group by giving a name and make your cause and effect diagram.

The advantage of the cause enumeration technique is that you stand a much better chance that all causes will be listed, especially hidden ones, and your diagram will be a complete and useful picture. The disadvantage is that it may be difficult to relate all the causes clearly to the result, making the diagram hard to draw.

Booch Diagrams

Booch Diagrams

Booch method of diagrams was designed by Grady Booch at Rational Software, prior to the invention of the well popular modeling language i.e., Unified Modelling Language(UML), as we all are aware of it.

Grady Booch was one among the designers of the "Unified Modeling Language". This UMl has its origin from this Booch method only.

This UML has its graphical elements drawn from this BOOCH method, and also elements from object modeling technique(OMT) and object oriented software engineering(OOSE).

Methodological aspects of the Booch method have been incorporated into several methodologies and processes, the primary such methodology being the Rational Unified Process (RUP).

HOW TO DRAW BOOCH DIAGRAMS

Grady Booch's Object-Oriented Design (OOD), also known as Object-Oriented Analysis and Design(OOAD), is a precursor to the Unified Modeling (UML). The Booch method includes six types of diagrams: class, object, state transition, interaction, module, and process.

Booch's Class and Object Diagram Notations

Classes:
Illustrate classes using a cloud shape with a dashed border.

You can find the Booch symbol libraries in SmartDraw under Software Design and Other Symbologies. Simply drag and drop shapes to the page and edit them.

Objects:
Draw objects using a cloud shape with a solid border.

Class:

Adornments Use adornments to provide additional information about a class. You can create an adornment notation using the basic triangle shape in SmartDraw. Place a letter inside the triangle to represent the following: A - Abstract. An abstract class cannot be instantiated because it represents a wide variety of object classes and does not represent any one of them fully. For example, mammal could be thought of as an abstract class. F - Friend. A friend class allows access to the nonpublic functions of other classes. S-Static. A static class provides data. V - Virtual. A virtual class is a shared base class, the most generalized class in a system.

Metaclass:
A metaclass is a class whose instances are also classes.

ClassCategories:
A class category represents a cluster of similar classes. Illustrate a class category by drawing a rectangle with two compartments.

ClassTemplates:
Draw a template using the standard class symbol attached to a box with a dashed outline. List template parameters or formal arguments in this box. When you draw a class created from a template, replace the dashed border with a solid one.

ClassUtilities:
Class utilities describe a group of non-member functions or subprograms. Illustrate a class utility with a shadowed cloud.

ClassVisibility:
Visibility markers signify who can access the information contained within a class. Public visibility allows an attribute or an operation to be viewed by any other class. Private visibility means that the attribute or the operation is only accessible by the class itself and its friends. Protected visibility makes an attribute or operation visible only to friend classes and classes that inherit it. Implementation restricts the accessibility of an attribute to the class only (not even friends have access to these attributes).

Place visibility markers next to the attribute they refer to.

ObjectVisibility:
Draw a visibility marker on a link to signify the relationship between the connected objects. These markers can be:

G-Global P-Parameter F-Field L–Local

Relationships
Indicate relationships between objects using lines and arrows.

Relationship Meaning

Aggregation (has)

Aggregation by value

Aggregation by reference

Uses

Instantiates - Compatible type

Instantiates - New type

Inherits - Compatible type

Inherits - New type

Metaclass

Undefined

Booch'sDynamicDiagrams:
Use state transition and interaction diagrams to illustrate the dynamic nature of an application. Below is a table that lists what each of the dynamic Booch diagrams corresponds to in UML.

Booch (OOD)	Unified Modeling Language (UML)
State transition diagram	State chart diagram
Interaction diagram	Sequence diagram

Booch's Dynamic Diagram Notations

State:
States represent situations during the life of an object. Draw a Booch state symbol using a rectangle with rounded corners and two compartments. Use the oval-shaped H symbol to indicate the most recently visited state.

Booch's Physical Diagrams:

Draw module and process diagrams to illustrate the physical design of your application. Module diagrams correspond to UML's component diagrams and process diagrams correspond to UML's deployment diagrams.

Booch's Physical Diagram Notations

Processor:
Processors are hardware pieces that execute programs. Use devices and processors to draw process diagrams.

Device:
Use a device notation to illustrate hardware that is not capable of executing programs.

Modules:
A module is a unit of code that serves as a building block for the physical structure of a system. The specification module contains the declaration of entities and the body module contains the definition of entities.

MainModule:
This module is the main program from which the system is activated.

Subsystem:
A subsystem refers to a collection of related modules.

Example of Booch Diagrams:

This is a little about Booch Model of Diagrams , you can explore it as much as you can. I hope you all will do so.

Thank You

Fathima. MD