sysad reviewer.pdf

MODULE 4 - PROCESS MODELING Decomposing Processes: Data Flow Diagrams (DFDs): To manage complexity, business processes can be broken down into a series of DFDs, ea...

MODULE 4 - PROCESS MODELING Decomposing Processes: Data Flow Diagrams (DFDs): To manage complexity, business processes can be broken down into a series of DFDs, each Data Flow Diagrams are used to illustrate how data demonstrating a lower level of detail. flows in a system. It's important to be consistent in your DFD notation and to properly identify and link each process to its higher-level process. There are two types of DFDs: Logical DFD: Focuses on the system process and how data flows within it. Example of a Decomposed DFD: Physical DFD: Indicates how the data flow is The example shows a breakdown of a process (Process implemented, including the location of data processing 2) into lower-level processes (2.1, 2.2, 2.3, etc.). and movement. Each DFD level provides more detail about the process flow. Elements of DFDs: Entity (Source/Sink): An external entity that interacts with the system but is not part of it. Represented by a square. Process: A work or action performed on data. Represented by a circle or rectangle with rounded corners. Data Store: A collection of data that is stored within the system. Represented by two parallel lines or an open- ended rectangle. Data Flow: Data in motion that moves between elements of the system. Represented by an arrow. There are two main notations used for DFDs: Gane & Sarson and Yourdon & DeMarco. Gane & Sarson: Use different symbols for each DFDs are a powerful tool for understanding and element. documenting business processes. Yourdon & DeMarco: Use a more standardized set It's important to understand the different notations of symbols. and symbols used in DFDs. Decomposing processes into a series of DFDs can help to manage complexity. Module 4.1 - Creating DFDs The context diagram shows the overall business process as just one process and shows the data Creating Data Flow Diagrams flows to and from external entities. DFD: Adding Levels of Detail No data stores are included in the context diagram. The highest level, called the context diagram Process is numbered as "O" (level 0), is only an overview. More detail is typically needed for system analysts. Creating the Context Diagram We add detail to a DFD by creating "levels". The context diagram defines how the The first level added after the context business process or computer system diagram is called level "1". interacts with its environment. Each new level breaks apart one process Draw one process symbol for the business and "decomposes" the single process into a process or system being modeled new, more detailed DFD. A complete DFD (numbered 0 and named for the process or can have many (up to 6 or 7) levels system). depending on the complexity of the system. Add all inputs and outputs listed on the form Breaking the DFD into levels is referred to of the use cases as data flows. as "Decomposition". Draw in all external entities as the source or DFD: Numbering Levels destination of the data flows. In a DFD with many levels, it is easy to overlook No data stores are included in the context which level you are on. That is why each level has diagram. different numbering for the processes on the diagram. LEVEL O DIAGRAM The 'level' is equivalent to the number of decimal places required to define a process in it. Here's how it works: Context Diagram Process labeled "O" Level 1 Processes labeled 1.0, 2.0, 3.0,. Level 2 Processes labeled 1.1, 1.2, 1.3.. Level 3 Processes labeled 1.11, 1.12,... A key concept: Balancing CONTEXT DIAGRAM Ensuring that all information presented in a The first DFD in every business process is the DFD at one level is accurately represented context diagram. in the next-level DFD. It shows the entire system in context with its A process model has one and only one level environment. 0 DFD. LEVEL 1 DIAGRAMS Customer receipt Food order Management reports Rule #2 - Inputs to a process are always different than outputs Objects always have a unique name. This way, the diagram is kept uncluttered. Rule #3 - A source or a sink cannot provide data to another source or sink without going through a process. Rule #4 - Data cannot move directly from a source to a data store without being processed. Each process on the level 0 DFD can be Rule #5 - Data cannot move directly from a decomposed into a more explicit DFD called source to a data store or from a data store to a level 1 diagram (or level 1 DFD). sink without being processed. The set of children and the parent are Rule #6 - Data cannot move directly from one identical; they are simply different ways of data store to another data store without being looking at the same thing. processed. Rule #7 - No process can only have outputs. It is important to ensure that level O and This is referred to as "miracle". level 1 DFDs are balanced. Rule #8 - No process can only have inputs. This All process models have as many level 2 is referred to as "black hole". diagrams as there are processes on the Rule #9 - A processing step should not have level 1 diagram. outputs that are greater than the sum of its inputs - e.g., its inputs could not produce the The parent process and the children output shown. This situation is sometimes processes are numbered consistently. referred to as a "grey hole". Rule #10 - A data flow should not flow in only one direction between symbols. Module 4.2 - Data Flow Diagram Rules Rule #11 - A fork means that the same data Rule #1 - DFD levels should be balanced. goes from a common location to two or more processes, data stores or sources/sinks. When decomposing a DFD, you must conserve Rule #12 - A fork means that the same data inputs to and outputs from a process at the next goes from a common location to two or more level of decomposition. This is called balancing. processes, data stores or sources/sinks. One input to the system, the customer order Rule #13-A data flow cannot go directly back to (arrows going into process) the same process it leaves. Rule #14 - A data flow to a data store means Three outputs: (arrows going out of the process) update (delete or change).  Rule #15 - A data flow from a data store means The Entity-Relationship Diagram (ERD) retrieves or use. An entity-relationship diagram (ERD) is a figurative Rule #16 - Data flow has a noun phrase label. representation of the information that is created, Rule #17 - A source/sink has a noun phrase stored, and used by a business system. label. Entities list similar kinds of information Rule #18 - Data store has a noun phrase label. Lines sketched between entities are the Rule #19 - A process has a verb phrase label relationships among the data. (except for context diagram). Special symbols convey high-level business rules. Rule #20 - DFDs are not flow charts. Rule #21 - Conditional or diverging flows should be replaced by individual flows. The 3 basic tenants of Data Model are Rule #22 - Data flow splitting is when a composite data flow at a higher level is split, and Entity: A real-world thing different parts go to different processes in the Attribute: Characteristics or properties of an entity lower level DFD. Relationship: Dependency or association between two entities Module 5 - Data Modeling Types of Data Models A data model is a formal way of representing the data that is used and created by a business 1. Conceptual - This Data Model specifies WHAT system. the entire system covers. This model is normally During analysis, analysts draw a Logical data created by Business stakeholders and Data model which shows the logical organization of Architects. The objective is to manage, scale data without indicating how it is stored, created, and identify business concepts and rules. or manipulated. During design, analysts draw a Physical data Example of a Conceptual Data Model model to reflect how the data will physically be stored in databases or files. Data Modeling Data modeling is the method of producing a data model for the data that is going to be stored in a 2. Logical - Defines HOW the system should be Database. implemented regardless of the DBMS. This Data modeling aids in the graphical interpretation of model is typically created by Data Architects and data and applies business rules, regulating Business Analysts. The purpose is to develop a agreements, and government policies on the data. technical map of rules and data structures. There are two types of Data Modeling Techniques available the Entity Relationship (E-R) Model and UML (Unified Modelling Language). Example of a Logical Data Model 3. Physical - This Data Model explains HOW the system will be applied using a particular DBMS system. This model is usually formed by DBA and developers. The objective is concrete application of the database. Example of a Physical Data Model Cardinality: Defines the ratio of instances between related entities, e.g., 1:1, 1:N, M:N. Primary Key: Uniquely identifies each instance within an entity. Foreign Key: Links tables together by referencing the Entity Relationship Diagram Example primary key of a related table. Modality: Indicates whether an instance of a child entity can exist without a related instance in the parent entity. Examples: Example of 1:1 Relationship: A student can only occupy one seat. Example of 1:N Relationship: One instructor can teach multiple courses. Example of M:N Relationship: A student can enroll in Module 5.1 - Elements of an Entity Relationship multiple courses, and a course can have multiple Diagram students. Entities: Represent real-world objects or concepts, e.g., student, department, product. Module 5.2 - Creating Entity Relationship Diagrams Attributes: Describe properties of entities, e.g., student Steps: name, department ID, product price. Relationships: Connect entities to show associations Identify all entities (e.g., Customer) between them, e.g., a student "enrolls" in a course. Add all attributes to each entity (e.g., *CUS_number) Draw relationships among entities, using appropriate notation (e.g., "makes", "is made by", "adds", "is  added by", "is targeted by", "targets", "creates", "is created by", "is listed in", "lists", "involves", "is involved in", "is included in", "includes", "promotes", "is promoted by") Balancing ERDs with DFDS: The process models and data models are interrelated. Although the process model focuses on the business processes, it contains two data components - the data and the data store. These two data components of the DFDs need to balance with the ERDs. The DFD data components need to correspond with the ERD's data stores (i.e., entities) and the data elements that comprise the data flows (i.e., attributes) depicted on the data model. CROW’S FOOT