Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MELJUN CORTES Analysis modeling----->DFD and ERD

622 views

Published on

MELJUN CORTES Analysis modeling----->DFD and ERD

Published in: Technology, Business
  • Be the first to comment

MELJUN CORTES Analysis modeling----->DFD and ERD

  1. 1. Analysis Modeling Chapter 12 DFD , ERD Topics MELJUN CORTES MELJUN CORTES
  2. 2. Who does Analysis Modeling? MELJUN CORTES
  3. 3. Why Analysis Modeling? MELJUN CORTES
  4. 4. Analysis Modeling Analysis Model MELJUN CORTES
  5. 5. Analysis Model Structure of Analysis Model MELJUN CORTES
  6. 6. Analysis Model The analysis model must achieve three primary objectives ◦ to describe what the customer requires, ◦ to establish a basis for the creation of a software design, and ◦ to define a set of requirements that can be validated once the software is built. MELJUN CORTES
  7. 7. Analysis Modeling Data Modeling MELJUN CORTES
  8. 8. Data Modeling Data modeling answers a set of specific questions that are relevant to any data processing application. ◦ What are the primary data objects to be processed by the system? ◦ What is the composition of each data object and what attributes describe the object? ◦ Where do the objects currently reside? ◦ What are the relationships between each object and other objects? ◦ What are the relationships between the objects and the processes that transform them? MELJUN CORTES
  9. 9. Data Modeling Data Objects, Attributes, And Relationships MELJUN CORTES
  10. 10. Data Objects, Attributes, And Relationships Data Objects ◦ A data object is a representation of almost any composite information that must be understood by software. ◦ A data object can be an external entity, a thing, an occurrence or event, a role, an organizational unit, a place, or a structure. MELJUN CORTES
  11. 11. Data Objects Data Objects MELJUN CORTES
  12. 12. Data Objects, Attributes, And Relationships Attributes ◦ Attributes define the properties of a data object and take on one of three different characteristics. They can be used to  name an instance of the data object,  describe the instance, or  make reference to another instance. MELJUN CORTES
  13. 13. Attributes Attributes MELJUN CORTES
  14. 14. Data Objects, Attributes, And Relationships Relationships ◦ Data objects are connected to one another in different ways. MELJUN CORTES
  15. 15. Relationships Relationships MELJUN CORTES
  16. 16. Data Modeling Entity Relationship Diagram MELJUN CORTES
  17. 17. Entity Relationship Diagram Entity Relationship Diagram is the representation of data objects between their relationships. MELJUN CORTES
  18. 18. Entity Relationship Diagram Expanded ERD MELJUN CORTES
  19. 19. Analysis Modeling Functional Modeling MELJUN CORTES
  20. 20. Functional Modeling Information is transformed as it flows through a computer-based system. The system accepts input in a variety of forms; applies hardware, software, and human elements to transform it; and produces output in a variety of forms. MELJUN CORTES
  21. 21. Functional Modeling Information flow model MELJUN CORTES
  22. 22. Functional Modeling Data Flow Diagrams MELJUN CORTES
  23. 23. Data Flow Diagrams As information moves through software, it is modified by a series of transformations. data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. A MELJUN CORTES
  24. 24. Data Flow Diagram MELJUN CORTES
  25. 25. Functional Modeling Extensions for RealTime Systems MELJUN CORTES
  26. 26. Extensions for Real-Time Systems Many software applications are time dependent and process as much or more control-oriented information as data. A real-time system must interact with the real world in a time frame dictated by the real world. Aircraft avionics, manufacturing process control, consumer products, and industrial instrumentation are but a few of hundreds of real-time software applications. MELJUN CORTES
  27. 27. Analysis Modeling Behavioral Modeling MELJUN CORTES
  28. 28. Behavioral Modeling Behavioral modeling is an operational principle for all requirements analysis methods. It also reproduces the required behavior of the original analyzed system, such as there is a one-to-one correspondence between the behavior of the original system and the simulated system MELJUN CORTES
  29. 29. Behavioral Modeling MELJUN CORTES
  30. 30. Analysis Modeling Structured Analysis Mechanics MELJUN CORTES
  31. 31. Structured Analysis Mechanics Entity Relationship Diagram MELJUN CORTES
  32. 32. Entity Relationship Diagram 1. During requirements elicitation, customers are asked to list the “things” that the application or business process addresses. These “things” evolve into a list of input and output data objects as well as external entities that produce or consume information. MELJUN CORTES
  33. 33. Entity Relationship Diagram 2. Taking the objects one at a time, the analyst and customer define whether or not a connection (unnamed at this stage) exists between the data object and other objects. 3. Wherever a connection exists, the analyst and the customer create one or more object/relationship pairs. MELJUN CORTES
  34. 34. Entity Relationship Diagram 4. For each object/relationship pair, cardinality and modality are explored. 5. Steps 2 through 4 are continued iteratively until all object/relationships have been defined. It is common to discover omissions as this process continues. New objects and relationships will invariably be added as the number of iterations grows. MELJUN CORTES
  35. 35. Entity Relationship Diagram 6. The attributes of each entity are defined. 7. An entity relationship diagram is formalized and reviewed. 8. Steps 1 through 7 are repeated until data modeling is complete. MELJUN CORTES
  36. 36. Entity Relationship Diagram • Connections MELJUN CORTES
  37. 37. Entity Relationship Diagram • Developing Relationships MELJUN CORTES
  38. 38. Structured Analysis Mechanics Data Flow Model MELJUN CORTES
  39. 39. Data Flow Model The level 0 data flow diagram should depict the software/system as a single bubble; Primary input and output should be carefully noted; Refinement should begin by isolating candidate processes, data objects, and stores to be represented at the next level; MELJUN CORTES
  40. 40. Data Flow Model All arrows and bubbles should be labeled with meaningful names; Information flow continuity must be maintained from level to level, and MELJUN CORTES
  41. 41. Data Flow Model One bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram. This occurs when the analyst attempts to show too much detail too early or represents procedural aspects of the software in lieu of information flow. MELJUN CORTES
  42. 42. Data Flow Model Level 0 MELJUN CORTES
  43. 43. Data Flow Model Level 1 MELJUN CORTES
  44. 44. Data Flow Model Level 1 MELJUN CORTES
  45. 45. Structured Analysis Mechanics Grammatical Parse MELJUN CORTES
  46. 46. Data Flow Model Level 1 MELJUN CORTES
  47. 47. Data Flow Model Level 2 – Monitor Sensors MELJUN CORTES
  48. 48. Structured Analysis Mechanics Control Flow Model MELJUN CORTES
  49. 49. Control Flow Model List all sensors that are "read" by the software. List all interrupt conditions. List all "switches" that are actuated by an operator. MELJUN CORTES
  50. 50. Control Flow Model 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. MELJUN CORTES
  51. 51. Control Flow Model 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 MELJUN CORTES
  52. 52. Structured Analysis Mechanics Control Specification MELJUN CORTES
  53. 53. Control Specification The control specification (CSPEC) represents the behavior of the system in two different ways. The CSPEC contains a state transition diagram that is a sequential specification of behavior. It can also contain a program activation table—a combinatorial specification of behavior. MELJUN CORTES
  54. 54. Analysis Modeling Data Dictionary MELJUN CORTES
  55. 55. Data Dictionary The data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate calculations. MELJUN CORTES
  56. 56. Data Dictionary Name ◦ the primary name of the data or control item, the data store or an external entity. Alias ◦ other names used for the first entry. MELJUN CORTES
  57. 57. Data Dictionary Where-used/how-used ◦ a listing of the processes that use the data or control item and how it is used. Content description ◦ a notation for representing content. MELJUN CORTES
  58. 58. Data Dictionary Supplementary information ◦ other information about data types, preset values (if known), restrictions or limitations, and so forth. MELJUN CORTES
  59. 59. Data Dictionary MELJUN CORTES

×