Completed transition schematic - IDEF3 diagram

This IDEF3 diagram example was redesigned from the Wikimedia Commons file: 5-21 Completed Transition Schematic.jpg.
[commons.wikimedia.org/ wiki/ File:5-21_ Completed_ Transition_ Schematic.jpg]
"As with the Process Schematic, the correctness of the Object Schematic and
associated elaborations are confirmed through validation with the domain expert. After reviewing the Transition Schematic, the domain expert observes that the allowable state transitions displayed in the schematic do not include those representative of a failed request. ...
The domain expert also identified transitions through which the identity of the object was preserved and transitions where the object was actually transformed into an entirely different object. The domain expert’s comments to the analyst yield the schematic
depicted in Figure 5-21." [IDEF3 Process Description Capture Method Report AL-TR-1995-XXXX. idef.com/ pdf/ Idef3_ fn.pdf]
The sample "Completed transition schematic - IDEF3 diagram" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the solution "IDEF Business Process Diagrams" from the area "Business Processes" of ConceptDraw Solution Park.

This IDEF3 diagram example was redesigned from the Wikimedia Commons file: 5-22 Final Object Schematic.jpg.
[commons.wikimedia.org/ wiki/ File:5-22_ Final_ Object_ Schematic.jpg]
"Additional context-setting information is then added to the Transition Schematic as required. For example, the domain expert’s description indicated that purchase requests involving direct projects require an authorization signature. Additionally, the description included discussion of a constraint that account managers or their designated backups must approve all requests involving their projects. This information is noted directly on the schematic. The resulting Object Schematic is displayed in Figure 5-22." [IDEF3 Process Description Capture Method Report AL-TR-1995-XXXX. idef.com/ pdf/ Idef3_ fn.pdf]
The sample "Final object schematic - IDEF3 diagram" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the solution "IDEF Business Process Diagrams" from the area "Business Processes" of ConceptDraw Solution Park.

This IDEF3 diagram example was redesigned from the Wikimedia Commons file: 2-02 Example of a Transition Schematic.jpg.
[commons.wikimedia.org/ wiki/ File:2-02_ Example_ of_ a_ Transition_ Schematic.jpg]
"The schematic in Figure 2-2 represents an Object Schematic for the Order Material scenario derived from the business owner’s description. This example happens to illustrate a Transition Schematic since it characterizes the nature and structure of object state transitions for occurrences of the Order Material scenario. A key document in this process is the Purchase Request form. This form is eventually transformed into a Purchase Order (PO) via the Order Material process. A circle containing the name of an object represents an object of a certain kind (e.g., Purchase Request, Account Manager, Project). These labeled circles are known as kind symbols. A certain kind of object being in a certain state is represented by a circle with a label that captures both the kind itself and a corresponding state, thereby representing the type (or class) of objects that are in that state (within a given process). ... One of the first steps to develop an Object Schematic is to identify the possible states in which the object can exist. Though a real-world object often evolves through a continuum of states, an Object Schematic focuses on those distinguished states of particular interest to the domain expert. The transition arcs (arrows with triangular, filled-in heads) connecting the circles symbolize a state transition, the activity of changing from one state to another. The conditions that establish when an object is in a given state, how it exists a state, how it can transition between states, and how it can enter a new state are recorded on a special form. The banded boxes linked to the arrows (called referents) are aids to describe the relationships between objects states and UOBs, scenarios, or other Transition Schematics that participate in a scenario occurrence. ... The transition junctions containing an “X” (for exclusive or) indicate the choice of exactly one path among several possible paths in an occurrence." [IDEF3 Process Description Capture Method Report AL-TR-1995-XXXX. idef.com/ pdf/ Idef3_ fn.pdf]
The diagram "Transition schematic - IDEF3 diagram example" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the solution "IDEF Business Process Diagrams" from the area "Business Processes" of ConceptDraw Solution Park.

The FTA diagram sample "Fault tree analysis - Insulin delivery system" was redesigned from the illustration of "CMSI 641: Introduction to Software Engineering. Design of Critical Systems. B.J. Johnson. 2005. Loyola Marymount University".
"Another way of assessing hazards is using fault tree analysis. In this process, each of the identified hazards is covered by a detailed analysis to find out what might cause it. Either inductive or deductive reasoning is applied. In the case of software hazards, the usual focus is to determine faults that will cause the system to fail to deliver a system service, such as a monitoring system. A "fault tree" is constructed to link all the possible situations together, to help identify the interrelationships of the failures, which modules may cause them, and what "trickle-down effects" there might be. Here is an example of a fault tree, as applied to the Insulin delivery system from Sommerville...
Note that this tree is only partially complete, since only the potential software faults are shown on the diagram. The potential failures involving hardware, such as low battery, blood monitor or sensor failure, patient over-exertion or inattention, or medical staff failure are noticeable by their absence.
The fault tree and safety specification processes are two ways of helping with system risk assessment tasks. Once the risks are identified, there are other assessments that need to take place. First, the likelihood of the risk occurrance must be assessed. This is often quantifiable, so numbers may be assigned based on things like MTBF, latency effects, and other known entities. There may be other non-quantifiable contributors to the risk likelihood, however, such that these must be assessed and estimated by experts in the domain. (Don't short-change this process when dealing with critical systems!) Finally, the risk assessment must include the severity of the risk, meaning an estimation of the cost to the project in the event the risk item actually does occur. "Cost to the project" means all associated costs, including schedule delays, human injury, damage to hardware, corruption of data, and so on."
[myweb.lmu.edu/ bjohnson/ cmsi641web/ week15-2.html]
The FTA diagram example "Fault tree analysis - Insulin delivery system" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Fault Tree Analysis Diagrams solution from the Engineering area of ConceptDraw Solution Park.

A four level pyramid model of different types of Information Systems based on the different levels of hierarchy in an organization. The first level represents transaction processing systems for workers. The second level represents management information systems for middle managers. The third level represents decision support systems for senior menegers. The fourth level represents executive information systems for executives.
"The "classic" view of Information systems found in the textbooks in the 1980s was of a pyramid of systems that reflected the hierarchy of the organization, usually transaction processing systems at the bottom of the pyramid, followed by management information systems, decision support systems, and ending with executive information systems at the top. Although the pyramid model remains useful, since it was first formulated a number of new technologies have been developed and new categories of information systems have emerged, some of which no longer fit easily into the original pyramid model.
Some examples of such systems are:
data warehouses,
enterprise resource planning,
enterprise systems,
expert systems,
search engines,
geographic information system,
global information system,
office automation." [Information systems. Wikipedia]
This diagram was redesigned using the ConceptDraw PRO diagramming and vector drawing software from Wikimedia Commons file Four-Level-Pyramid-model.png. [commons.wikimedia.org/ wiki/ File:Four-Level-Pyramid-model.png]
This file is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. [creativecommons.org/ licenses/ by-sa/ 3.0/ deed.en]
The triangle chart example "Information systems types" is included in the Pyramid Diagrams solution from the Marketing area of ConceptDraw Solution Park.