Chapter 2: Understanding Organizational Style and Principles Underlying Structured Analysis and Design

1. Chapter 2: Understanding Organizational Style and Principles Underlying Structured Analysis and Design Instructor: Paul K Chen

2. Topics • Organization Characteristics • Principles Underlying Structured Analysis and Design • Data Flow Diagram • Entity Relationship Diagram • Structured vs. Object-Oriented Approach

3. Organizational Characteristics • They are complexcomposed of interrelated and independent subsystems. • System and subsystem boundaries and environments impact on information system analysis and design.

4. Principles Underlying Structured Analysis • Functional Decomposition (Divide and conquer) The process of analyzing a system by breaking into smaller pieces until a complete, consistent and finite picture has been drawn of what are the pieces to be automated SA tools: DFD (data flow diagram) & ERD (entity relationship diagram) • Decomposition rules: leveling and Balancing • Target: An understanding of the problem domain

5. Partitioning the System via DFD Leveling A leveled set of DFDs is made of a top, a bottom, and a middle. Top-- Context DFD defining the system domain. Middle—Providing progression from general to specific. Bottom—(called unit function or function primitive) indicates that functions are ready for program specifications.

6. A leveled DFD Conceptual Level Context Logical (functional) Level Subsystems PGM Spec Level Physical Level

7. Leveling & Balancing Concept of leveling • When a single process on a higher level diagram is partitioned to show the level of detail. • When several processes on a data flow diagram are grouped together as a single process on a higher level diagram.

8. Leveling & Balancing Concept of balancing • The inputs and outputs of a child diagram must exactly match those of its parent diagram • Every flow must have a place to come from and a place to go to.

9. DFD—Parent & Child Relationship A (H2) Process C (Water) B (O) A (H2) C (Water) B (O)

10. Functional Decomposition 1 1.1 1.2 1.3 System Specification 1.1.2 1.1.1

11. Principles Underlying Structured Design • Modularity & Information Hiding (Black Box) SD tools: Structured Chart; Decision Tree; Decision Table Data repository (metadata); Data store; data dictionary Specifications: Structured English; Decision Table

12. Structure Chart Transaction Input Process Output

13. Two Types of Models

14. DFD (Data Flow Diagram) A tool for building a process model of the system • Graphic representation • Hierarchic description • Emphasis on data flows

15. Components (Notations) Process representing the Transformation of data Entity, External actor, data source & Sink submitting data to processes, or Receiving results, or both Data Flow representing the Trigger of a process or its reaction File and Data Store representing the storage of data required by the processes

16. Entity, External Actor • It’s a logical group of things or persons that represent a data source or recipient. • It cannot modify or transform the data conveyed by the system; it is outside the system. • When we designate a thing or a system as an entity, we implicitly define the boundaries of the system.

17. Process A processtransforms data in order to produce a response or a result. • By definition, the system constitutes a process in itself. • The same symbol is used to represent the system and processes affected by the system.

18. Data Flow A data flow is a channel through which a process exchanges data with its environment. • The data flows link a process to an external actor, a data store or another process; • The flow whose destination is a process and triggers its execution is called an initiating flow or stimulus; • The flow originating from a process is called a response flow or result.

19. Data Store A data is the memory of the system, it is responsible for the storage of data required by system processes. • When a flow enters a data store, this represents the storing (add, modify or delete) of data; • When a flow leaves a data store, this represents the access (data query) to the data previously stored. • Identification: It usually refers to the name of an entity (or subject) of the conceptual data model.

20. ProcessData FlowData Store Manage Member Module Process File/Database Access Routine Data Flow Retrieve Update Read, write Member Data Store Table

21. Data Flows –the Don’ts External actor External actor External actor

22. Data Context Diagram The data context diagram is used to show: • Communication between our system and the environment • Entities in the environment with which our system communicates • The functional boundary for our system

23. ATM Context Level DFD Dispense cash; print receipt; eject card Cash Machine Status Display Customer ATM Customer Commands Bank account OK Bank Consortium Affiliated Bank Account OK

24. Entity Relationship Diagram A tool for building a data model of the system. An ERD is a picture of what we know about the target system, in terms of required information, illustrated by joining logical groups of information (data) together, and showing the business rules (relationships) with which they are associated.

25. ATM ERD –Subject Context Level

26. ATM ERD –Subject Context Level Customer ATM uses Has Owns Bank Consortium Account Affiliated Bank Holds Consists of

27. Entity An entity is: • Something we need to know about in order to conduct business. • A person, place or thing, of interest to the user community. • Some essential thing which, if not present, will prevent us from conducting business.

28. Entity Entities are NOUNS. • Not any noun is an entity. • Only those nouns within the scope of the user’s view of information are candidates for entities.

29. Association/Relationship • An association is a relationship between two or more entities that the user wishes to keep track of relative to specific conditions in the business. Each relationship must be as specific as possible so that its meaning is clear. Using the ATM ERD for example, a customer (an entity) has an account (an entity). What does “has” mean? –possession; or management.

30. Types of Associations • One to one (1:1) : For example, a husband is married to a wife. (If you violates this one-to-one relationship, what happens?) • One to many (1:M): For example, a customer has a one-to-many accounts. • Many to many (M:M): For example, a part has many orders; an order belongs to many parts.

31. Types of Associations 1.1 1.1 1,M 0,1 0,M 1,1 1,1 0.1 1,M 1.M

32. Identifying Relationshipvs.Non-Identifying Relationship • Identifying Relationship An identifying relationship is a relationship between two entities in which primary key of one entity appears as a foreign key in the other entity as a key data element or set of data elements. For example, the relationship between parent entity and child entity is an identifying relationship.

33. Identifying Relationship vs.Non-Identifying Relationship ·Non-Identifying Relationship A non-identifying relationship is a relationship between two entities in which the primary key of one entity appears as a foreign key in the other entity as a non-key data element. For example, the relationship between an Organization entity and a Project entity is a non-identifying relationship. Additionally, the Organization identifier appears as a foreign key (as an element), but not part of the primary key in the Project entity.

34. Types of Entities • Independent Entity (Fundamental entity) An independent entity is a group of data that exists without dependence upon any other entity. Therefore it does not have any identifying parent(s). Its primary key does not contain a foreign key from any other entity ·  Dependent Entity (Attribute Entity) A dependent entity (or child entity) is a group of data that cannot exist without the support of another entity (or parent entity). Its primary key contains a foreign key from another entity.

35. Types of Entities ·Associative Entity An associative entity is an entity that exists when decomposing a many-to-many relationship between two entities. For example, a many-to-many relationship between an entity called Project and another called Organization would result inan associative entity called Project-Organization.

36. A Hierarchy of Models (Process-Data Interdependence) DFD ERD Conceptual Level Context Subject Level Logical Level Subsystems Data Store Denormalized Entity Normalized Entity PGM Spec Level Physical Level Tables

37. Structured vs. Object-Oriented Approach

38. Object-Oriented and Component-Based Development Component-based development is the process of building systems by combining and integrating pre-tested and Pre-engineered software objects, such as class libraries, encapsulated software modules, and frameworks. For most, components are synonymous with proprietary Objects-- encapsulated binary objects, most notably Microsoft’s OLE (Object Linking and Embedding) and Ado (ActiveX Data Objects).

39. UML – Quick Reference UML (Unified Modeling Language) • Recognized as a modeling language, not as a methodology or method • Will replace all of those analysis and design (Booch, Coad, and so forth) with a single notation • Endorsed by the Object Management Group(OMG) Leading Vendor: Rational Rose (using XML as repository)

40. UML – Quick Reference Use Case Diagram -Shows the system’s use cases and which actors Interact with them-- to capture user requirements. Class Diagram - Shows the existence of classes and their relationships in the logical view of a system. Statechart Diagram – Shows the state space of a Given context, the events that cause a transition from one state to Another, and the actions that result.

41. UML – Quick Reference Sequence Diagram - Shows objects in the system and how they Interact-defining the logic for a use case scenario. Component Diagram -Shows the dependencies between Software components. Deployment Diagram - Shows the configuration of runtime processing elements. Collaboration Diagram - Shows the message flow between objects.

42. Use Cases Professor Input Marks Enroll in course Student Registrar Distribute Transcripts The actors; the use cases they are involved; & the boundary of the application

43. Use Cases vs. Events • An “event” is an essential business condition, a requirement that exists which the target system or business area must respond to or deal with in order to carry on operations to successfully support its key business objectives, goals, mission, directions and vision.

44. Event List –Gathering Requirements Sales • Customer places an order. • It is time to price order. • It is time to check inventory. • Customer requires order information. • Company decides to hold order. • Company or customer decides to change or cancel an order.

45. Use Cases vs. Events • Business Event Analysis is an effective way of identifying internal and external interfaces of a system. It looks at things that require a response from a system. An individual stimulus from one data object to another is an event. Events are discovered by investigating the external influences that act upon a system, and the data transformation that occurs within a system that converts inputs into outputs. Thus, source and target data objects that interact with an event can be identified. For example, an event “customer buys a product” as depicted below is initiated by the data object “customer” who requires a response from the data object “sale”, “product”, and “payment”.

46. Use Cases vs. Events

47. UML – Quick Reference User reqt’s Analysis Design Code Use case Diagram Component Diagram Class Diagram Statechart Diagram Sequence Diagram Source code Use cases Deployment Diagram Collaboration Diagram

48. Software Modeling/Prototyping WithBuilt-in Testing Validation/Project Evaluation & Control Target System Existing System Physical Model Physical Model Built-In Testing Validation Prototyping Project Evaluation/Control Logical Model Logical Model Approach: Structured or Spiral or Iterative Approach Rapid Application Development CASE tools; Deliverable Templates