Presentation on theme: "Cardinality and Modality (ERD)"— Presentation transcript:
1 Cardinality and Modality (ERD) Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N)Modality - zero (0) for an optional object relationship and one (1) for a mandatory relationship
2 Cardinality: Implies that a single customer repair action (s) Cardinality: Implies that here may be repair action (s)COUSTERREPAIR ACTIONIs provided withModality: Mandatory Implies that in order to have a repair action (s), we must have a customerModality: Operational Implies that here may be a situation in which a repair action is not nessary
3 Functional Modeling and Information Flow (DFD) Shows the relationships of external entities, process or transforms, data items, and data storesDFD's cannot show procedural detail (e.g. conditionals or loops) only the flow of data through the software
4 Data store Output data External entity Intermediate data Input data Transform#1Transform#2Transform#3Transform#4Data storeIntermediate dataInput dataData store outputData store input
5 Functional Modeling and Information Flow (DFD) (continue) Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds)To model real-time systems, structured analysis notation must be available for time continuous data and event processing (e.g. Ward and Mellor or Hately and Pirbhai)
6 Monitor and adjust temperature level Monitored temperatureTemperature set pointInput “Continuous”Output “Continuous”
7 Behavioral Modeling (STD) State transition diagrams represent the system states and events that trigger state transitionsSTD's indicate actions (e.g. process activation) taken as a consequence of a particular eventA state is any observable mode of behaviorHatley and Pirbhai control flow diagrams (CFD) can also be used for behavioral modeling
8 Creating Entity Relationship Diagrams The following steps are required to build an ERD.Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entitiesAnalyst and customer define connections between the objectsOne or more object-relationship pairs is created for each connectionThe cardinality and modality are determined for an object-relationship pairAttributes of each entity are definedThe entity diagram is reviewed and refined
9 Creating Data Flow Diagram Useful guideline for creating DFDsLevel 0 data flow diagram should depict the system as a single bubblePrimary input and output should be carefully notedRefinement should begin by consolidating candidate processes, data objects, and data stores to be represented at the next levelLabel all arrows with meaningful namesInformation flow must be maintained from one level to levelRefine one bubble at a timeWrite a PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD
10 Creating Control Flow Diagrams To select potential candidate control ,the following guidelines are suggestedList all sensors that are "read" by the software.List all interrupt conditions.List all "switches" that are actuated by an operator.List all data conditions.Recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs.Describe the behavior of a system by identifying its states; identify how each state is reached; and define the transitions between states.Focus on possible omissions-a very common error in specifying control; for example, ask: "Is there any other way I can get to this state or exit from it?"
13 Data Dictionary Contents Name - primary name for each data or control item, data store, or external entityAlias - alternate names for each data objectWhere-used/how-used - a listing of processes that use the data or control item and how it is used (e.g. input to process, output from process, as a store, as an external entity)Content description - notation for representing contentSupplementary information - other data type information, preset values, restrictions, limitations, etc.