Connecting Data Flow Diagrams to System Architecture

UPI Study › Courses › Software Engineering › Free lessons › Lesson 9.1 Free with a free account

Connecting Data Flow Diagrams to System Architecture

Software Engineering · Chapter 9: Component-Level Design and Practical ApplicationSection 9.1 · lesson 61 of 1035 min · free with a free account

← Transform Mapping: Turning Data Flow into ArchitectureNext lesson: What Goes Into Component-Level Design →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access

In this lesson

Transaction mapping: when 1 input triggers 1 of several paths.

  • Distinguish transform-flow from transaction-flow diagrams
  • Recognize a transaction center
  • Map a transaction center to a dispatcher architecture
  • Choose the mapping technique that fits a diagram's shape

Transcript

Everything said in the video, section by section (641 words). Read along, or search it.

Component-Level Design and Practical Application

Connecting Data Flow Diagrams to System Architecture

Not every data flow diagram has the same shape, and the shape matters. A diagram built around one continuous pipeline calls for one way of deriving an architecture. A diagram where one incoming item triggers one of several paths calls for another. This section covers that second case. Transaction mapping.

Shape Matters

2 Shapes a DFD Can Take

A transform-flow diagram has a roughly linear shape. Data enters, moves through a sequence of steps that progressively transform it, and exits. That shape suits the pipeline-style mapping covered earlier. A transaction-flow diagram looks different. A single incoming item arrives at a point, and triggers exactly one of several distinct processing paths, depending on what kind of item it is. Recognizing which shape a diagram actually has is what determines which technique fits it.

Figure 1

Pipeline vs. Fan-Out

Here are the two shapes, one above the other. On top, transform flow. Input, then processing, then more processing, then output. One continuous pipeline. Below, transaction flow. An input arrives at a transaction center, and from there it takes exactly one of several paths. The shape gives it away. One pipeline, or one dispatch point branching into mutually exclusive paths.

The Signal

Recognizing a Transaction Center

The point where an incoming flow splits into several distinct, mutually exclusive paths is called the transaction center. Which path is taken depends on what kind of item just arrived. Finding a transaction center is the signal to reach for transaction mapping, rather than the pipeline-oriented technique. A diagram with one input branching into self-contained alternatives has a fundamentally different shape. Forcing it into a pipeline structure fights against how the problem is actually organized.

Transaction Mapping

From Transaction Center to Dispatcher

Once a transaction center is identified, it translates fairly directly into an architecture built around a dispatcher. A top-level component receives the incoming item, and determines what kind of item it is. It then routes the item to exactly one of several subordinate components. Each one handles a single path the diagram showed branching out. So the architecture mirrors the diagram's own fan-out shape. A dispatcher above several independent, parallel handlers.

Table 1

Transform vs. Transaction Mapping

Here are the two techniques side by side. Transform mapping fits a linear input, process, output pipeline. It produces a sequential structure along that pipeline. Transaction mapping fits one input branching into distinct alternative paths. It produces a dispatcher with several parallel handlers. And the core questions differ. Transform mapping asks how data gets progressively transformed. Transaction mapping asks which of several paths an item should take.

Worth Noticing

Recognize the Shape First

It is worth noticing where the real skill lies. It is in recognizing the diagram's actual shape, before choosing a technique. Forcing a transaction-shaped diagram through a pipeline derivation, or the reverse, produces an architecture that fights the problem's natural structure. Neither technique is universally correct. Each fits the shape of diagram it was built for. And both aim at the same goal. A reasonable first-cut architecture, derived directly from analysis, rather than starting from nothing.

Why This Matters

Analysis as Raw Material

This is a concrete example of a pattern covered earlier. Design depends directly on analysis's output. The data flow diagram produced during analysis is not just documentation. It is the actual raw material an architecture gets derived from.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Transaction mapping derives an architecture from a transaction-flow diagram, turning its fan-out shape into a dispatcher over parallel handlers. A transaction center is the point where an incoming item triggers exactly one of several distinct, mutually exclusive paths. A dispatcher is a top-level component that determines an incoming item's type, and routes it to the right handler. And transform mapping is the complementary technique, for linear, pipeline-shaped diagrams.

Key Takeaways

What to Carry Forward

To pull this together. Transform flow is a continuous pipeline. Transaction flow fans out from a single point. A transaction center splits one input into mutually exclusive paths, depending on the kind of item. It maps to an architecture with a dispatcher over parallel handlers. And the diagram's own shape should decide which technique gets used.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Connecting Data Flow Diagrams to System Architecture

What is the difference between transform flow and transaction flow in a DFD?
Transform flow has a roughly linear shape: data enters, moves through a sequence of steps that progressively transform it, and exits as one continuous pipeline. Transaction flow fans out: a single incoming item reaches a point and triggers exactly one of several distinct processing paths, depending on what kind of item it is. Recognizing which shape a diagram has determines whether transform mapping or transaction mapping fits it.
What is a transaction center in a data flow diagram?
A transaction center is the point in a DFD where an incoming flow splits into several distinct, mutually exclusive paths, with the path chosen by the kind of item that arrived. Finding one is the signal to use transaction mapping rather than the pipeline-oriented transform mapping technique. Forcing a diagram with a transaction center into a pipeline structure fights against how the problem is actually organized.
How does transaction mapping produce a dispatcher architecture?
Transaction mapping turns the transaction center into a top-level dispatcher component that receives each incoming item, determines its type, and routes it to exactly one of several subordinate handler components. Each handler corresponds to one of the paths branching out in the diagram. The resulting architecture mirrors the diagram's fan-out shape, with a dispatcher sitting above several independent, parallel handlers.
How do you choose between transform mapping and transaction mapping?
Let the data flow diagram's shape decide. If the diagram is a linear input, process, output pipeline, use transform mapping, which produces a sequential structure along that pipeline. If one input branches into distinct alternative paths, use transaction mapping, which produces a dispatcher over parallel handlers. Neither is universally correct, and both aim at a reasonable first-cut architecture derived directly from analysis.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Software Engineering
3 credits · NCCRS
Enroll →