MODELING
Carrigan Group utilizes IDEF0 modeling methodology to document workflow
processes for design
review.
Our solutions are built upon the results of the requirements review
phase plus an on-site workflow analysis.
We model the project's workflow processes incorporating the following
methodologies:
• IFEF0 (FIPS 183)
• IDEF1X (FIPS 184)
• CMM
• ISO 9001, ISO 9002
From the behavioral data models we generate simulations of the proposed processes. Our Modeling & Simulation techniques ensure the highest levels of design requirements communication, due diligence, QA testing & systems implementation.
HOW TO READ AN IDEF0 DIAGRAM...
The precise information about a system is in the diagrams themselves. The following reading sequence is recommended:
1. Scan the boxes of the diagram to gain an impression of what is being described.
2. Refer back to the parent diagram and note the arrow connections to the parent box. Try to identify a “most important” input, control and output.
3. Consider the arrows of the current diagram. Try to determine if there is a main path linking the “most important” input or control and the "most important" output.
4. Mentally walk through the diagram, from upper left to lower right, using the main path as a guide. Note how other arrows interact with each box. Determine if there are secondary paths. Check the story being told by the diagram by considering how familiar situations are handled.
5. Check to see if a related FEO diagram exists.
6. Finally, read the text and glossary, if provided.
This sequence ensures that the major features of each diagram receive attention. The text will call attention to anything that the author wishes to emphasize. The glossary will define the author's interpretation of the terminology used.
Each diagram has a central theme, running from the most important incoming boundary arrow to the most important outgoing boundary arrow. This main path through the boxes and arrows outlines the primary function of the diagram.
Syntax...
The structural components and features of a language and the rules that define relationships among them are referred to as the language's syntax. The components of the IDEF0 syntax are boxes and arrows, rules, and diagrams. Boxes represent functions, defined as activities, processes or transformations. Arrows represent data or objects related to functions. Rules define how the components are used, and the diagrams provide a format for depicting models both verbally and graphically. The format also provides the basis for model configuration management.
Boxes...
A box provides a description of what happens in a designated function. A typical box is shown in Figure 1. Each box shall have a name and number inside the box boundaries. The name shall be an active verb or verb phrase that describes the function. Each box on the diagram shall contain a box number inside the lower right corner. Box numbers are used to identify the subject box in the associated text.
Figure 1. Box Syntax
Arrows...
An arrow is composed of one or more line segments, with a terminal arrowhead at one end. As shown in Figure 2, arrow segments may be straight or curved (with a 90° arc connecting horizontal and vertical parts), and may have branching (forking or joining) configurations. Arrows do not represent flow or sequence as in the traditional process flow model. Arrows convey data or objects related to functions to be performed. The functions receiving data or objects are constrained by the data or objects made available.
Figure 2. Arrow Syntax
Syntax Rules...
Boxes
1. Boxes shall be sufficient in size to insert box name.
2. Boxes shall be rectangular in shape, with square corners.
3. Boxes shall be drawn with solid lines.Arrows
1. Arrows that bend shall be curved using only 90-degree arcs.
2. Arrows shall be drawn in solid line segments.
3 Arrows shall be drawn vertically or horizontally, not diagonally.
4. Arrow ends shall touch the outer perimeter of function box & shall not cross into box.
5. Arrows shall attach at box sides, not at corners.
Semantics...
Semantics refers to the meaning of syntactic components of a language and aids correctness of interpretation. Interpretation addresses items such as box and arrow notation and functional relationship interfaces.
Box and Arrow Semantics...
Since IDEF0 supports function modeling, the box name shall be a verb or verb phrase, such as “Perform Inspection”, that is descriptive of the function that the box represents. The example "Perform Inspection" function transforms
un-inspected parts into inspected parts. The definitive step beyond the phrase-naming of the box is the incorporation of arrows (matching the orientation of the box sides) that complement and complete the expressive power (as distinguished from the representational aspect) of the IDEF0 box.
Standard terminology shall be used to ensure precise communication. Box meanings are named—descriptively—with verbs or verb phrases and are split and clustered in decomposition diagramming. Arrow meanings are bundled and unbundled in diagramming and the arrow segments are labeled with nouns or noun phrases to express meanings. Arrow-segment labels are prescriptive, constraining the meaning of their segment to apply exclusively to the particular data or objects that the arrow segment graphically represents. Arrow meanings are further expressed through fork and join syntax.
Each side of the function box has a standard meaning in terms of box/arrow relationships. The side of the box with which an arrow interfaces reflects the arrow’s role. Arrows entering the left side of the box are inputs. Inputs are transformed or consumed by the function to produce outputs. Arrows entering the box on the top are controls. Controls specify the conditions required for the function to produce correct outputs. Arrows leaving a box on the right side are outputs. Outputs are the data or objects produced by the function.
Arrows connected to the bottom side of the box represent mechanisms. Upward pointing arrows identify some of the means that support the execution of the function. Other means may be inherited from the parent box. Mechanism arrows that point downward are call arrows. Call arrows enable the sharing of detail between models (linking them together) or between portions of the same model. The called box provides detail for the caller box (see Section 3.3.2.10).
Standard arrow positions are shown in Figure 3.
Supporting information concerning the function and its purpose shall be addressed in the text associated with the diagram. A diagram may or may not have associated text. When acronyms, abbreviations, key words, or phrases are used, the fully defined term(s) shall be provided in the glossary.
Figure 3. Arrow Positions
For more information,
or to schedule a consultation,
please contact Carrigan Group
today at 609-883-9691, or
E-Mail: Info@CarriganGroupInc.com
