Head First Software Architecture

Chapter 4. Logical Components: The Building Blocks

Ready to start creating an architecture? It’s not as easy as it sounds—and if you don’t do it correctly, your software system could come crumbling to the ground, just like a poorly designed skyscraper or bridge.

In this chapter we’ll show you several approaches for identifying and creating logical components, the functional building blocks of a system that describe how its pieces all fit together. Using the techniques described in this chapter will help you to create a solid architecture—a foundation upon which you can build a successful software system.

Put on your hard hat and gloves, get your tools ready, and let’s get started.

Logical components revisited

Logical components are one of the dimensions of software architecture. They are the functional building blocks of a system that make up what is known as the problem domain. In Chapter 1 you learned a bit about them, and in this chapter we’ll dive deep into what logical components are and how to create them.

Remember that, in most programming languages, logical components are represented through the directory structure of your source code repository. For example, source code located in the app/order/tracking directory would be contained within a logical component named Order Tracking.

Exercise

Name that component

It’s your first week on the job as the new architect, and you’ve been assigned to an existing project to build a trouble ticket system. You want to understand the logical components of the architecture, but your team doesn’t know anything about logical components—they just started coding. To determine the logical architecture, you have to look at the existing directory structure. How many individual logical components can you identify from the codebase below?

Solution in “Exercise Solution”

Adventurous Auctions goes online

Want to go on a safari in Tanzania? Observe wildlife in the Galapagos Islands? Hike to the base camp of Mount Everest? Adventurous Auctions is here to help!

You’ve probably seen our ads or attended some of our live auctions around the country. These kinds of adventures are hard to come by and can take years to reserve; our company auctions them off at a significant cost savings.

We want more people around the world to be able to access these great trips, so we’re taking our adventurous auctions online (in addition to our in-person auctions).

That’s where you come in: we need a new system to support the online auctions of our adventurous trips.

Here’s what the new system needs to do:

• Include both in-person and online bids in every auction.

• Scale up to meet demand, so hundreds or even thousands of people can participate in each auction.

• Allow online users to register with Adventurous Auctions and provide us with their credit card details so they can pay if they win a trip.

• Allow online users to view live video streams of in-person auctions, as well as all bids placed so far, both in person and online.

• Allow online users to bid on trips, just like the people in the room.

• Determine which online bidder bids the asking price first (this is called “winning the bid”). If an online bidder bids at the same time as an in-person bidder, the auctioneer then determines who bid first.

• When the auctioneer announces an online user as the winner, the system charges the winner’s credit card, notifies the winner, then moves on to the next trip in the auction.

  Note

  Pay attention, because we’re going to show you how to create a logical architecture for this system.

Logical versus physical architecture

A logical architecture shows all of the logical building blocks of a system and how they interact with each other (known as coupling). A physical architecture, on the other hand, shows things like the architectural style, services, protocols, databases, user interfaces, API gateways, and so on.

Note

We’re going to be talking a lot about component coupling later in this chapter.

The logical architecture of a system is independent of the physical architecture—meaning the logical architecture doesn’t care about databases, services, protocols, and so on. Let’s look at an example of what we mean by a logical architecture.

As you remember, Adventurous Auctions needs to create and schedule online auctions and allow bidders to register, search for auctions, and view the trips that are up for bid. Here are some of the components—the functional building blocks—that will help make that happen.

See how the logical architecture doesn’t include the various components of physical architecture mentioned above? It’s a different view of the system. To see what we mean, compare the diagram above with the following physical architecture diagram. Notice how the physical architecture associates services with components from the logical architecture, and also shows the services and databases for the system.

Who Does What?

We had our logical and physical architecture responsibilities all figured out, but somehow they got all mixed up. Can you help us figure out who does what? Be careful—some responsibilities may not have a match (they aren’t part of a logical or physical architecture).

Be sure to check the answers (located at the end of this chapter) before moving on.

Solution in “Who Does What? Solution”

Creating a logical architecture

Identifying logical components isn’t as easy as it sounds. To help, we’ve created this flowchart. Don’t worry—we’ll be covering all of these steps in detail in the following pages.

This flow continues as long as the system is alive.

This flowchart shows a series of steps to begin greenfield applications (new systems created from scratch) and perform ongoing maintenance on existing ones.

Ever wonder why it’s so common for a well-designed system to end up as an unmaintainable mess in no time? It’s because teams don’t pay enough attention to the logical architecture of their systems.

Anytime you make a change or add a new feature to the system, you should always go through each of these steps to ensure that the logical components are the right size and are doing what they are meant to do.

Step 1: Identifying initial core components

The first step in creating a logical architecture is identifying the initial core components. Many times this is purely a guessing game, and you’ll likely refactor the components you initially identify into others. So don’t spend a lot of time worrying about how big or small your components are—we’ll get to that. First, let’s show you what we mean by a “guessing game.”

Given this simple description, you can start out by creating three logical components, one for each of the three major things the system does.

These components aren’t really doing anything yet. You see, we’ve identified the initial components, but we haven’t assigned them any responsibility yet. You could think of them as empty jars. They represent our initial best guess, based on a major action that takes place in the system. That’s why we call them initial core components.

Yes, there is! In fact, you can use several approaches to remove some of the guesswork.

You don’t know a lot of details about the system or its requirements yet, and the components you initially identify are likely to change as you learn more. That’s why we say it’s a guessing game at this stage—and that’s perfectly okay!

We’ll show you two common approaches for identifying initial core components: the workflow approach and the actor/action approach.

There are other approaches that may seem like good ideas initially but that can lead you down a very bad path. We’ll discuss those after we show you the good stuff.

Workflow approach

The workflow approach is an effective way to identify an initial set of core components by thinking about the major workflows of the system—in other words, the journey a user might take through the system. Don’t worry about capturing every step; start out with the major processing steps, and then work your way down to more details.

Note

You can model different workflows to create even more initial components.

Let’s use the workflow approach to identify some initial core components for the Adventurous Auctions architecture.

there are no Dumb Questions

Q: You identified “Video Streamer” as a logical component, but what if our team decides to use a third-party library or service to stream the auction?

A: Great question! Even though you might not develop the functionality yourself, it’s still part of the logical architecture.

Q: Is each step in a workflow always mapped to a single logical component?

A: Not always. You might have several steps in a workflow that point to the same logical component, particularly if their functionalities are closely related.

Names matter.

Pay close attention to how you name your initial core components. A good name should succinctly describe what that component does.

Sharpen your pencil

Your company wants a new system to assign workers to construction sites, and it’s your job as the software architect to identify its initial core components. Using the workflow approach, identify as many core components as you can, matching each to its associated workflow step. Remember, a workflow step can have multiple components, and not every workflow step has to have a unique component.

• Step 1: Maintain a list of all construction workers, their skills, and their locations

• Step 2: Create a new construction project and specify the work site

• Step 3: Create a schedule for when various construction projects start and end

• Step 4: When a new project starts, assign workers based on their skills and locations

• Step 5: When the project completes, free up workers so they can be reassigned

Note

Draw your logical components in this space. Remember to give them good descriptive names.

Solution in “Sharpen your pencil Solution”

Actor/action approach

The actor/action approach is particularly helpful if you have multiple actors (users) in the system. You start by identifying the various actors. Then, you identify some of the primary actions they might take and assign each action to a new or existing component.

Returning to our Adventurous Auctions example, let’s use the actor/action approach to identify some initial core components.

Exercise

You have a bakery that is ready to expand operations, and you would like a new system that lets customers view, order, and pay for bakery items online for pickup. Orders are sent to the bakery coordinator, who purchases ingredients and schedules orders. The baker receives the schedule of items to bake each morning and tells the system when the items are baked. The system then emails the customers to let them know their items are ready for pickup.

Using the actor/action approach, identify what actions each actor might take. Then draw as many logical components as you can for the new bakery system, matching the actions you identified to the components.

Solution in “Exercise Solution”

The entity trap

Welcome to the entity trap.

We call this approach the entity trap because it’s very easy to fall into it when identifying the initial core logical components, and you’ll run into lots of issues if you do this.

First of all, the name “Bid Manager” is too vague. Can you tell what the component does just by looking at the name? Neither can we. A name like this doesn’t tell us enough about the component’s role and responsibilities.

Second, the component has too many responsibilities. All too often, components in the entity trap become convenient dumping grounds for all functionality related to those entities. As a result, they take on too much responsibility and become too big and difficult to maintain, scale, and make fault tolerant.

Note

Pro Tip

Watch out for words like manager or supervisor when naming your logical components—those are good indicators that you might be in the entity trap.

Sharpen your pencil

What other words besides manager can you list that, if they appeared in a component name, might indicate that you’ve fallen into the entity trap?

supervisor

Note

We did this one for you.

Solution in “Sharpen your pencil Solution”

Exercise

Can you select the most appropriate approach to identifying initial core components in the following scenarios? In some cases, more than one approach may be appropriate.

The system has only one type of user	Workflow	Actor/Action
The system has well-defined entities	Workflow	Actor/Action
You have minimal functional requirements	Workflow	Actor/Action
The system has many complex user journeys	Workflow	Actor/Action
The system has many types of users	Workflow	Actor/Action

Solution in “Sharpen your pencil Solution”

there are no Dumb Questions

Q: The actor/action approach reminds me a lot of event storming. Are they the same thing?

A: Great observation, and we’re glad you saw the similarities. Event storming is a workshop-based approach that is part of domain-driven design (DDD). With this approach, you analyze the business domain to identify domain events. While both approaches have the final goal of identifying actions performed within the system, event storming takes identifying components much further than the actor/action approach does. You could say that the actor/action approach identifies the domain event and actor elements of event storming, but doesn’t continue with other elements such as command, aggregate, and view. You can learn more about event storming at https://en.wikipedia.org/wiki/Event_storming.

Q: Can you combine the workflow approach and actor/action approach, or do you have to choose between them?

A: You can combine them, and in most cases this is a good idea. If you start with the actor/action approach to identify actions, you can then use the workflow approach to arrange them in the order in which they are likely to occur.

Q: Are you telling me I should never use the words manager, supervisor, and so on as part of my component names?

A: Not necessarily—there is no hard and fast rule to the entity trap. Sometimes it’s hard to come up with a name for something that does a general task. Take, for example, a component that manages all of the reference data in your application—name/value pairs like country codes, store codes, color codes, and so on. A good name for such a component would be “Reference Data Manager.” However, names like “Order Manager” or “Response Handler” are too broad and don’t describe what those components actually do.

Q: When using the actor/action approach, how many actions should you identify for each actor?

A: That’s a tough question. The purpose of identifying actions is to tease out likely logical components and what they might be responsible for. We usually look at the primary actions an actor might take, rather than diving into too many details.

Step 2: Assign requirements

Once you’ve identified some initial core components, it’s time to move on to the next step: assigning requirements to those logical components.

In this step, you’ll take functional user stories or requirements and figure out which component should be responsible for each one. Remember, each component is represented by a directory structure. Your source code resides in that directory, so it contains that requirement.

Let’s go back to the initial set of components we defined based on what Frank (the CIO) said about the basic workflow of Adventurous Auctions. Now it’s time to assign some responsibilities to these components.

Sharpen your pencil

Your company, Going Green Corporation, wants a system to support its new electronics recycling program, where customers can send in their old electronic devices (like cell phones) and get money. We’ve already identified some of the initial core components. Your job is to figure out which component should be responsible for each of the functionalities listed below, or if a new component is needed. You’ll also need to come up with names for any new components.

Solution in “Sharpen your pencil Solution”

Step 3: Analyze roles and responsibilities

As you start assigning functionality (in other words, user stories or requirements) to logical components, the roles and responsibilities of each component will start to naturally grow. The purpose of this step is to make sure that the component to which you are assigning functionality should actually be responsible for that functionality and that it doesn’t end up doing too much.

Let’s say we create a component called Live Auction Session that has the following responsibilities during a live auction:

With this added functionality, this component is now taking on too much responsibility. This is a common situation, so don’t be surprised if it happens to you. When it does, don’t panic—that’s what this step is here for. Let’s see if we can fix this situation by moving some of the responsibility of the Live Auction Session component to other components.

Note

If you’ve ever had too much on your plate at work, you likely gave some of that work to others. Do the same with components—offload some of the responsibility to someone else.

Geek Note

Have you ever created a class file called Utility? What did it do? Chances are it contained a bunch of unrelated functions that you’d had a hard time placing. The same thing can happen with logical components within software architecture. Try to avoid components that contain lots of unrelated functions.

Sticking to cohesion

When you analyze a component’s role and responsibility statement or set of operations, check to see if the functionality is closely related. This is known as cohesion: the degree and manner to which the operations of a component are interrelated. Cohesion is a useful tool for making sure a component has the right responsibilities.

When analyzing the role and responsibilities of a component, it’s common to find an outlier (an odd piece of functionality) or a component that is doing too much. In these cases, it’s usually a good idea to shift some of the responsibility to other components.

Now it’s your turn to fix the Live Auction Session component.

Make it Stick

Component functions should all be related— but if they’re not, don’t get frustrated. Just start to break the component apart, and you’ll be considered very smart.

Exercise

See if you can offload some of the responsibility of the Live Auction Session component to others by creating new components to handle the additional functionality. Keep the first three original requirements associated with the Live Auction Session.

Solution in “Exercise Solution”

Step 4: Analyze characteristics

The final step in identifying initial core components is to verify that each component aligns with the driving architectural characteristics that are critical for success. In most cases this involves breaking apart a component for better scalability, elasticity, or availability, but it could also involve putting components together if their functionalities are tightly coupled.

Let’s look once again at our Adventurous Auctions example. We previously identified a Bid Capture component that is responsible for accepting bids, storing all bids in a Bid Tracker database, and forwarding the highest bid to the auctioneer. Here is the overall flow for the Bid Capture component:

This architecture looks good, but just to be sure, we should make sure the Bid Capture component supports the system’s critical architectural characteristics (those that are important for success).

We know the system has to support thousands of bidders per second—that’s scalability. We also know the system must be up and running while auctions are taking place—that’s availability. Finally, the system must accept a bid and get it to the auctioneer as fast as possible—that’s performance.

Note

These are all important to the success of Adventurous Auctions.

Now it’s your turn to analyze the Bid Capture component against these critical architectural characteristics.

BE the architect

Your job is to play architect and analyze the Bid Capture component on the previous page to see if it should be modified based on the critical architectural characteristics we identified. Our solution is on the next page.

These are the critical architectural characteristics for Adventurous Auctions:

• Scalability: The system has to support thousands of bidders per second

• Availability: The system must be up and running while the auctions are taking place

• Performance: The system must accept a bid and get it to the auctioneer as fast as possible.

Hints (things to consider):

• What if the database goes down?

• Can the database keep up with the volume of inserts based on the bids coming in?

• Will inserts into the database be fast enough to get the bids to the auctioneer?

• Consider the actions the Bid Capture component has to take upon receiving a bid.

Note

Use this area to draw how you might change the Bid Capture component based on the critical architectural characteristics and considerations above.

The Bid Capture component

Let’s work through this exercise by reviewing the current responsibilities of the Bid Capture component:

1. Accept bids from online bidders and from the auctioneer for live bidders.

2. Determine which online bid is the highest.

3. Write all bids to a Bid Tracker database for tracking purposes.

4. Notify the auctioneer of the highest bid.

It makes sense for the Bid Capture component to write the bids to the database, since it has them. But database connections and throughput are limited, so having Bid Capture do this significantly impacts scalability. It also impacts performance by adding wait time for writing the data to the database, as well as availability if the database were ever to go down.

Note

This is what we mean by analyzing characteristics.

If we assign the last requirement to a new component called Bid Tracker, we can significantly increase the scalability, performance, and availability of the Bid Capture component. That lets the system process more bids faster and get the highest bid to the auctioneer as quickly as possible. The Bid Capture component can send the bids to the Bid Tracker and won’t have to wait for the bid to be written to the database.

Note

You might break apart or combine components in this step, based on the architectural characteristics needed.

Component coupling

Yes, and this is the right time to do it.

As you identify the initial core components, it’s important to determine how they interact. This is known as component coupling: the degree to which components know about and rely on each other. The more the components interact, the more tightly coupled the system is and the harder it will be to maintain.

Remember this diagram from several pages ago? It’s called a “big ball of mud” because there are so many component interactions and dependencies that the diagram starts to look like a ball of mud (or maybe like a bowl of spaghetti).

That’s why it’s so important to pay attention to how components interact and what dependencies exist between them.

You need to be concerned about two types of coupling when creating logical components: afferent coupling and efferent coupling. Don’t be concerned if you’ve never heard these formal terms before—we’re going to explain them in the following pages.

Afferent coupling

Children depend on their parents for a lot of things, like making sure they have plenty of food to eat and a safe place to live, driving them to soccer practice, or even giving them an allowance so they can buy candy or a really cool comic book. As it turns out, parents are afferently coupled to their children, and even to the family dog, because all of them depend on the parents for something.

Afferent coupling is the degree and manner to which other components are dependent on some target component (in this case, Mom). It’s sometimes referred to as fan-in, or incoming, coupling. In most code analysis tools, it’s simply denoted as CA.

To see how afferent coupling works, look at the interaction between three of the logical components within the Adventurous Auctions logical architecture on the left.

Both the Auction Registration component and the Automatic Payment component depend on the Bidder Profile component to return bidder profile information. In this scenario, the Bidder Profile component has an afferent coupling level of 2, because two components depend on it to complete their work.

Geek Note

Did you know that the odd-sounding word afferent means “carrying toward”? It gets its roots from the Latin words ad (meaning “to” or “toward”) and ferre (“to carry”). In the medical field, the word afferent refers to nerves that carry impulses to the brain (your afferent nerves).

Efferent coupling

Now let’s look at things from a young child’s point of view. As a child, you might have been dependent not only on your parents, but also your teachers, friends, classmates, and so on. Being dependent on others is known as efferent coupling.

Efferent coupling is exactly the opposite of afferent coupling, and it’s measured by the number of components on which a target component depends. It’s also known as fan-out coupling or outgoing coupling. In static source code analysis tools, it’s usually denoted as CE.

So, what does efferent coupling look like with logical components? Let’s take a look at Adventurous Auctions again, this time considering the process of accepting a bid from Kate for a trip.

Because the Bid Capture component depends on the Bid Streamer and Bid Tracker components to process a bid, it is efferently coupled to these components. It has an efferent coupling level of 2 (in other words, it’s dependent on two other components).

Measuring coupling

You can measure a particular component’s amount of coupling in three ways: by considering its total afferent coupling (CA), its total efferent coupling (CE), and its total coupling (CT), or the sum of the total afferent and efferent coupling. These measurements tell you which components have the highest and lowest coupling, as well as the entire system’s overall coupling level.

Sharpen your pencil

Given the components below, can you identify the total afferent coupling (CA), total efferent coupling (CE), and total coupling (CT) for each component? Also, what is the total coupling level for this logical architecture? Does the CT for this architecture seem high or low to you?

Solution in “Sharpen your pencil Solution”

Great question. Developers are taught to strive for loosely coupled systems, but not how to do it. We’ll show you how by introducing a technique called the Law of Demeter.

The Law of Demeter, also known as the Principle of Least Knowledge, is named after Demeter, the Greek goddess of agriculture. She produced all grain for mortals to use, but she had no knowledge of what they did with the grain. Because of this, Demeter was loosely coupled to the mortal world.

Logical components work in the same way. The more knowledge a component has about other components and what needs to happen in the system, the more coupled it is to those components. By reducing its knowledge of other components, we reduce that component’s level of coupling.

On the next few pages, we’ll show you more about the Law of Demeter and how it can be used to decouple systems.

A tightly coupled system

Let’s see how the Law of Demeter can be used to decouple systems by taking a look at the logical architecture of a typical order entry system.

Brain Power

What possible issues do you see with the logical architecture above? We’ve provided some (but not all) potential problems. Check off the ones you think might be an issue, and write down any other possible issues you see with this logical architecture.

• The customer might not be available to get their email when it’s sent.

• The supplier might not have stock on hand.

• The Order Placement component knows too much about the steps involved in placing an order.

• _______________________________________________________________________________

• _______________________________________________________________________________

• _______________________________________________________________________________

Applying the Law of Demeter

The total system coupling level didn’t bother us that much. What does bother us is how tightly coupled the Order Placement component is (CT=5), how unbalanced the component coupling is, and how much knowledge the Order Placement component has about the order placement process.

Note

The Order Placement component is taking charge.

Let’s apply the Law of Demeter to fix these problems by moving the “low stock” knowledge to the Inventory Management component.

By moving the knowledge of actions to take for a “low stock” condition to Inventory Management, we reduced the amount of knowledge about the system, and hence the coupling, of the Order Placement component However, we increased the knowledge of the Inventory Management component, and thus increased its coupling. This is what the Law of Demeter is all about—less knowledge, less coupling; more knowledge, more coupling.

Note

Coupling is all about how much knowledge components have about the rest of the system.

Geek Note

Did you notice that while we reduced the coupling of the Order Placement component, the total system coupling level remained the same? That’s because we didn’t remove the knowledge from the system, we just moved it to another component—Inventory Management.

Test Drive

Now it’s time to take the Law of Demeter for a test drive to see if you can decouple a logical architecture. Below is a logical architecture for a system where customers who have purchased a support plan with an electronic item can submit a trouble ticket and have an expert come out to fix the item. Here’s how it currently works:

• A customer creates a ticket.

• The ticket gets assigned to an available expert in the field.

• The ticket is uploaded to an app on the expert’s mobile device (that’s Ticket Routing).

• The customer is notified that the expert is on their way to fix the problem.

• Once the expert fixes the problem, they mark the ticket as completed.

Keeping the components the same, how can you make this architecture more loosely coupled?

Solution in “Test Drive Solution”

A balancing act

Do you remember the First Law of Software Architecture? Here it is again (because it’s so important):

Everything in software architecture is a trade-off.

Loose coupling is no exception. Let’s compare the two architectures we’ve just seen and analyze their trade-offs.

With the tightly coupled architecture, if you want to know what happens when a customer places an order, you only have to look at the Order Placement component to understand the workflow.

However, changing the Item Pricing and Supplier Ordering components will no longer affect the Order Placement component.

With loose coupling, you distribute the knowledge about what needs to happen, so that no one component knows all the steps. If you want to understand the workflow of placing an order, you have to go to multiple components to get the full picture.

However, in this case, the Order Placement component is dependent on four other components. If any one of those components changes, it could break the Order Placement component.

Two components are coupled if a change in one component might cause a change in the other component.

Note

This is a good rule to remember.

Some final words about components

Congratulations! Now that you can identify logical components and the dependencies between them, you’re on your way to creating a software architecture. We know this was a long chapter, but it’s also an important one. Thinking about a system as a collection of logical components helps you, as an architect, better understand its overall structure and how it works.

In the next part of your software architectural journey, you’ll be focusing on the technical details of the system—things like architecture styles, services, databases, and communication protocols. But before you go, review the following bullet points to make sure you fully understand everything about logical components.

Bullet Points

• Logical components are the functional building blocks of a system.

• A logical component is represented by a directory structure—the folder where you put your source code.

• When naming a component, be sure to provide a descriptive name to clearly identify what the component does.

• Creating a logical architecture involves four continuous steps: identify components, assign requirements, analyze component responsibilities, and analyze architectural characteristics.

• You can use the workflow approach to identify initial core logical components by assigning the steps in a primary customer journey to components.

• You can use the actor/action approach to identify initial core logical components by identifying the actors in the system and assigning their actions to components.

• The entity trap is an approach that models components after major entities in the system. Avoid using this approach, because it creates ambiguous components that are too large and have too much responsibility.

• When assigning requirements to components, review each component’s role and responsibilities to make sure it should be performing that function.

• Coupling happens when components depend on one other to perform a business function.

• Afferent coupling, also known as incoming coupling, occurs when other components are dependent on a target component.

• Efferent coupling, also known as outgoing coupling, occurs when a target component is dependent on other components.

• Components having too much knowledge about what needs to happen in the system increases component coupling.

• The Law of Demeter states that services or components should have limited knowledge of other services or components. This law is useful for creating loosely coupled systems.

• While loose coupling reduces dependencies between components, it also distributes workflow knowledge, making it harder to manage and control that knowledge.

• Determining the total coupling (CT) of a logical architecture involves adding the afferent and efferent coupling levels for each component (CA + CE).

Logical Components Crossword

Now’s your chance to have a little fun and see how much knowledge you’ve gained. See if you can fill in this crossword puzzle with clues about logical components.

Across

3. Each component performs a _____

4. _____ gateways appear in a physical architecture but not a logical one

6. A physical architecture associates _____ with components

7. One system component might be a live video _____

9. Avoid building a big ball of _____

11. Be sure to avoid the _____ trap

12. Coupling might be _____ or efferent

13. Logical _____ are the functional building blocks of a system

16. Early on, you’ll identify _____ core components

19. A user’s journey through the system is called their _____

20. Each logical component has a _____ and a responsibility

Down

1. A component’s _____ is about how interrelated its operations are

2. Give each component a descriptive _____

5. Afferent and efferent coupling are both forms of _____ coupling

8. The Principle of Least Knowledge is also called the Law of _____

10. A good place to look for components is the codebase’s _____ structure

12. Step 2 is to _____ requirements to logical components

14. An architecture diagram can show the logical or _____ architecture

15. Adventurous Auctions lets users _____ on trips

17. You can identify components with an _____/action approach

18. Identifying logical components may involve taking your best _____

Solution in “Logical Components Crossword Solution”

From “Exercise”

Exercise Solution

Name that component

It’s your first week on the job as the new architect, and you’ve been assigned to an existing project to build a trouble ticket system. You want to understand the logical components of the architecture, but your team doesn’t know anything about logical components—they just started coding. To determine the logical architecture, you have to look at the existing directory structure. How many individual logical components can you identify from the codebase below? Here are our answers.

From “Who Does What?”

Who Does What? Solution

We had our logical and physical architecture responsibilities all figured out, but somehow they got all mixed up. Can you help us figure out who does what? Be careful—some responsibilities may not have a match (they aren’t part of a logical or physical architecture).

From “Sharpen your pencil”

Sharpen your pencil Solution

Your company wants a new system to assign workers to construction sites, and it’s your job as the software architect to identify its initial core components. Using the workflow approach, identify as many core components as you can, matching each to its associated workflow step. Remember, a workflow step can have multiple components, and not every workflow step has to have a unique component.

• Step 1: Maintain a list of all construction workers, their skills, and their locations

• Step 2: Create a new construction project and specify the work site

• Step 3: Create a schedule for when various construction projects start and end

• Step 4: When a new project starts, assign workers based on their skills and locations

• Step 5: When the project completes, free up workers so they can be reassigned

From “Exercise”

Exercise Solution

You have a bakery that is ready to expand operations, and you would like a new system that lets customers view, order, and pay for bakery items online for pickup. Orders are sent to the bakery coordinator, who purchases ingredients and schedules orders. The baker receives the schedule of items to bake each morning, and tells the system when the items are baked. The system then emails the customers to let them know their items are ready for pickup.

Using the actor/action approach, identify what actions each actor might take, then draw as many logical components as you can for the new bakery system, matching the actions you identified to the components.

From “Sharpen your pencil”

Sharpen your pencil Solution

What other words besides manager can you list that, if they appeared in a component name, might indicate that you’ve fallen into the entity trap?

From “Exercise”

Exercise Solution

Can you select the most appropriate approach to identifying initial core components in the following scenarios? In some cases, more than one approach may be appropriate.

From “Sharpen your pencil”

Sharpen your pencil Solution

Your company, Going Green Corporation, wants a system to support its new electronics recycling program, where customers can send in their old electronic devices (like cell phones) and get money. We’ve already identified some of the initial core components. Your job is to figure out which component should be responsible for each of the functionalities listed below, or if a new component is needed. You’ll also need to come up with names for any new components.

From “Make it Stick”

Exercise Solution

See if you can offload some of the responsibility of the Live Auction Session component to others by creating new components to handle the additional functionality. Keep the first three original requirements associated with the Live Auction Session.

From “Sharpen your pencil”

Sharpen your pencil Solution

Given the components below, can you identify the total afferent coupling (CA), total efferent coupling (CE), and total coupling (CT) for each component? Also, what is the total coupling level for this logical architecture? Does the CT for this architecture seem high or low to you?

From “Test Drive”

Test Drive Solution

It’s time to take the Law of Demeter for a test drive to see if you can decouple a logical architecture. Below is a logical architecture for a system where customers who have purchased a support plan with an electronic item can submit a trouble ticket and have an expert come out to fix the item. Here’s how it currently works:

• A customer creates a ticket.

• The ticket gets assigned to an available expert in the field.

• The ticket is uploaded to an app on the expert’s mobile device (that’s Ticket Routing).

• The customer is notified that the expert is on their way to fix the problem.

• Once the expert fixes the problem, they mark the ticket as completed.

Keeping the components the same, how can you make this architecture more loosely coupled?

Logical Components Crossword Solution

From “Logical Components Crossword”