Thinking about Complex Systems

Systems Architecture · Chapter 3

Aykut C. Satici

Studying Complex Systems

Chapter 2 used systems with two or three entities to introduce form, function, relationships, and emergence
Engineering systems usually contain many interacting entities
This chapter introduces methods for studying these systems:

Decomposition and hierarchy
Special logical relationships (class/instance, specialization, recursion)
Techniques for reasoning through complex systems
Architecture representation with OPM

Chapter 2 used systems with two or three entities so students could concentrate on form, function, relationships, and emergence. Examples included an amplifier, Team X, the circulatory system, and the solar system.
Engineering systems usually contain many more interacting entities. Chapter 3 applies the same ideas at that larger scale.
Introduce decomposition and hierarchy, then class/instance relationships, specialization, and recursion.
The chapter also covers top-down, bottom-up, and middle-out reasoning, along with zigzagging between form and function.
OPM is the representation method used in this course.
Discussion: What made the Chapter 2 examples easy to hold in mind: few entities, few relationships, or familiar behavior? Those are different sources of apparent simplicity.

Suggested answer: All three help, for different reasons. Fewer entities reduce how much we must track. Fewer relationships reduce the number of interactions to reason about. Familiar behavior lets us use prior mental models. A familiar car may feel simple while remaining intrinsically complex. Ask students to distinguish a change in the system from a change in the observer’s knowledge. A small system can still be hard to understand when its coupling or behavior is unfamiliar. Ask which factor helped in the chosen Chapter 2 example.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 49-50.

Box 3.1 · Definition: Complex System

A complex system has many elements or entities that are highly interrelated, interconnected, or interwoven.

The definition sets no fixed threshold for “many”
Additional functions and demands for performance, robustness, or flexibility can increase complexity
Connections to other systems also add complexity, such as a car communicating with traffic control or a house connected to the internet

The definition gives no fixed threshold for “many.” Both the entities and their interconnections matter.
Complexity can increase when we ask a system to provide more functions, higher performance, greater robustness, or more flexibility.
Connecting systems can also add complexity. Examples include a car communicating with traffic control and a house connected to the internet.
Some dependencies come from systems outside the designer’s control, so simplifying the internal design may address only part of the problem.
The chapter mentions information content and functional complexity as approaches to measurement. It does not adopt a single numerical metric.
Discussion: If two systems have the same number of entities, what kinds of interconnection could make one much harder to reason about?

Suggested answer: Feedback loops, many-to-many dependencies, shared resources, and tightly coupled timing can make one system harder to reason about even at the same entity count. Compare a chain of tasks with a team in which everyone repeatedly revises everyone else’s work. In the latter, a change can propagate, return through feedback, and affect several others at once. Relationship type and strength matter as well as relationship count. Time delays and state-dependent interactions can also change the complexity of the same network.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 49-50.

Complex ≠ Complicated

Complex

An intrinsic property of the system: many interrelated, interconnected entities and relationships.

Complicated

A property of human perception: something overwhelms our ability to understand it. High apparent complexity.

A system should have the complexity it needs while remaining understandable to the people who work with it.

Architects use abstractions and representations to help people understand a complex system.

In this chapter, complex describes the system’s entities and interconnections. Complicated describes how difficult someone finds it to understand.
A system may need substantial complexity to meet its requirements. Appropriate abstractions, decompositions, and representations help people understand it.
Roman water-delivery networks provide an older example of a complex system. The problem of understanding such systems predates modern engineering.
An architecture needs to be understandable to its designers, builders, operators, and maintainers. Each audience may need a different representation.
Discussion: Name a system that is intrinsically complex but well explained. Which abstraction keeps it from feeling complicated?

Suggested answer: A transit network is a useful example: many trains, stations, signals, and schedules interact, but a route map lets a passenger reason about getting from one station to another. The map suppresses signaling and maintenance detail while preserving useful connectivity. That same abstraction is insufficient for a signal engineer, so comprehensibility is audience- and task-dependent.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 50.

Introducing Team XT

Team XT extends Team X from Chapter 2 with more people, while retaining its function of producing a design
Task 1 identifies the system as the people and the process that develops the design
Form = the people. Function = developing a design.
Observation, experience, or interviews establish each member’s function. Table 3.1 lists 16 team members and four context participants, with their formal structure and functional interactions

Team XT extends Team X from Chapter 2. Its function is still to produce a design, but it contains more people and interactions.
Apply the same four tasks as in Chapter 2. For Task 1, identify the system as the people and the design-development process. The people constitute form, and developing a design is the function.
Determining what each person does requires observation, experience, or interviews. An organizational chart gives only part of this information.
Table 3.1 lists 16 team members and four context participants. It records their functions, interactions, locations, shared tools, and roles.
For Task 2, place Marketing and Operations in the context outside the chosen system boundary.
Task 3 records formal relationships, such as location and reporting, alongside functional interactions.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 50-53, especially Table 3.1.

Table 3.1 · The full Team XT

Team XT	Form	Function	Function interaction	From/To	Location	Connectivity	Role
	Sue	Evaluates and approves design	Gets finalized concept/requirements	John, Amy	Cambridge	Share design tool	Team XT manager
	Amy	Finalizes requirements	Gets draft requirements document	Jose, Vladimir	Cambridge	Share requirement tool	Requirements group leader
	Jose	Develops requirement documents	Gets strategy and regulatory input	Mats, Ivan	Cambridge	Share requirement tool	Group member
	Vladimir	Develops requirement documents	Gets needs and competitive analysis	Heather	Cambridge	Share requirement tool	Group member
	Ivan	Interprets regulations	N/A		Cambridge	Share requirement tool	Group member
	Mats	Interprets corporate strategy	N/A		Cambridge	Share requirement tool	Group member
	John	Develops finalized concepts	Gets evaluated options	Mark	Moscow	Share design tool	Concept group leader
	Natasha	Develops conceptual options	Gets finalized requirements	Amy	Moscow	Share requirement tool	Group member
	Analyst 1	Analyzes designs	Gets conceptual options	Natasha	Moscow	Share design tool	Group member
	Analyst 2	Analyzes designs	Gets conceptual options	Natasha	Moscow	Share design tool	Group member
	Mark	Evaluates design options	Gets analysis	Analyst 1,2	Moscow	Share design tool	Group member
	Phil	Leads supporters	N/A		Cambridge		Support group leader
	Nicole	Provides IT support	Supports design tool	Design tool users	Cambridge		Group member
	Meagan	Coaches team	Supports group leaders	John, Amy	Cambridge		Group member
	Alex	Models project finances	Supports design analysts	Analyst 2	Cambridge	Share design tool	Group member
	Dimitri	Provides administrative support	Supports manager	Sue	Cambridge		Group member
System boundary
Marketing					Cambridge
	Heather	Determines needs	Gets competitive analysis	Chris	Cambridge
	Chris	Does competitive analysis	N/A		Cambridge
Operations					Cambridge
	Karen	Plans manufacturing	Gets final design	Sue	Cambridge
	James	Plans supply chain	Gets final design	Sue	Cambridge

Source: Crawley, Cameron & Selva, System Architecture (2016), Table 3.1, p. 51. Retypeset. Blank cells and N/A retained. Zoom: Ctrl-click on Linux. Alt/Option-click on Windows/Mac. Repeat to return.

Purpose and walkthrough (5–7 minutes)

Keep the whole table visible first: each named row is an entity of form. Read across to connect that person to a function, an interaction, and formal structure. The team’s overall function is to develop an engineering design.
Explain the column groups: Form identifies the person. Function says what they do. Function interaction + From/To describes an exchange and the participant at its other end. Location, Connectivity, Role describe formal structure. “From/To” is not a reporting column, and sharing a tool does not imply sharing a manager.
Zoom into Amy’s row: she finalizes requirements, receives draft requirements from Jose and Vladimir, is in Cambridge, shares the requirement tool, and leads the requirements group. Read her Function separately from her Role: doing work and holding authority are different properties.
Trace a dependency across rows: Chris, then Heather, Vladimir, Amy, Natasha, Analyst 1/2, Mark, John, and Sue. Read each interaction phrase to determine direction. Sue also gets requirements from Amy. This trace is one pathway, not every dependency.
Zoom into Natasha and Amy: finalized requirements cross from Cambridge to Moscow. Natasha shares the requirement tool despite working with the concept group. Location, tool connectivity, and organizational role therefore provide different views of the same team.
Zoom into the support rows: Alex is in Cambridge and supports Analyst 2 in Moscow. Nicole supports design-tool users. These enabling interactions belong in the architecture even though they are not steps along the central design pathway.
Point to the dashed system boundary. There are 16 named people inside Team XT and four named context participants below it. Marketing and Operations are external to the chosen design-development system. External does not mean irrelevant. Their blank role cells do not imply that they have no roles in the wider company.
Preserve the source’s limits: N/A and empty cells are not proof that no real-world interaction or connection exists. This table records selected principal relationships. The Role column supports a hierarchy of manager, group leaders, and members. It does not explicitly list every person’s reporting line.

Discussion prompts and suggested answers

Which columns would you use to construct Figure 3.1, and which to construct the hierarchy in Figure 3.2?
- Answer: Form, Function, Function interaction, and From/To supply the people, activities, and exchanges for Figure 3.1. Form and Role supply the named entities and ranks for Figure 3.2. Location and Connectivity support additional geographical and tool-sharing views. No single view shows everything.
Does Vladimir report to Heather because she appears in his From/To cell?
- Answer: No. Vladimir receives needs and competitive analysis from Heather. That is a functional input across the system boundary, not a statement of managerial authority.
Where can you find an interaction that crosses a geographical boundary but stays inside the system?
- Answer: Amy in Cambridge supplies finalized requirements to Natasha in Moscow. Alex in Cambridge supporting Analyst 2 in Moscow is another example. Both endpoints are above the system boundary.
What would an org chart alone hide if Amy’s finalized requirements were late?
- Answer: Natasha’s conceptual-option work depends on those requirements. Delays could propagate through analysis, evaluation, finalized concepts, and approval. These are plausible consequences of the dependencies, not a quantified schedule prediction. Sue also receives requirements from Amy.
Why are Marketing and Operations shown if they are outside Team XT?
- Answer: Their exchanges help define the team’s context: Heather supplies input used by Vladimir, while Karen and James receive the final design from Sue. Omitting them would conceal important interfaces. A broader system boundary could include them, but would answer a different architectural question.
Does N/A in Phil’s interaction cell mean we can remove him without consequence?
- Answer: No. His stated function is to lead supporters and his role is support group leader. N/A here does not establish that leadership has no dependencies or value. Further observation or interviews would be needed to model those interactions.

Transition: The next slide draws the functional relationships recorded here. Later, the hierarchy and decomposition slides reorganize the same entities to answer different questions.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, Table 3.1, p. 51; discussion pp. 50–54. Discussion scenarios and suggested answers are instructor interpretation of the table.

Figure 3.1 · Function and Interaction in Team XT

The value pathway runs down the center. IT, coaching, administration, and finance provide support through links from the right. Marketing and Operations sit outside the system boundary. Source: Crawley, Cameron & Selva (2016), Fig. 3.1.

Figure 3.1 applies Task 3 to the 16 members of Team XT.
Trace the value pathway down the center: interpreting strategy and regulations, developing and finalizing requirements, developing and analyzing design options, then evaluating, choosing, and approving the design.
IT, coaching, administration, and finance support the people on this pathway through the links from the right.
Marketing and Operations sit outside the dashed system boundary and connect through the marked interfaces.
The diagram shows functional interactions. Figure 3.2 adds information about organizational rank.
Include the support and context links in the explanation. They show dependencies that the central pathway alone would omit.
Discussion: Which interaction would create the greatest downstream disruption if delayed or removed? Use the arrows, not job titles, to justify the answer.

Suggested answer: A defensible candidate is the transfer of finalized requirements into design-option development and analysis. Delaying that input can stall several downstream activities or force rework through evaluation, selection, and approval. Trace the actual outgoing arrows and the activities that depend on them. The diagram alone cannot prove a unique greatest disruption: timing, buffers, alternate information paths, and the duration of an outage would be needed to rank failures quantitatively. Accept another interaction if the student demonstrates its downstream dependencies. In Figure 3.1, Amy supplying finalized requirements to Natasha is a concrete example. A shared-tool support failure is another candidate to examine.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 52-53, Table 3.1 and Fig. 3.1.

Decomposition and Integration

Decomposition divides an entity into smaller constituents
Smaller parts let us examine or solve portions of a larger problem
Integration brings those parts together and checks that they work as a whole

“All Gaul is divided into three parts.”

Julius Caesar, The Gallic Wars

In the formal domain, aggregation concerns how physical or logical parts fit together. In the functional domain, we examine how simpler functions interact and what behavior emerges when we combine them.

Decomposition divides an entity into smaller constituents so each can be studied or designed.
The Caesar quotation illustrates the long history of dividing a problem into manageable parts.
Integration brings the parts back together. Check whether their interfaces fit and whether their interactions produce the required behavior.
In the formal domain, aggregation concerns how physical or logical parts fit together. In the functional domain, recombining functions requires reasoning about emergence.
A decomposition can follow form or function. For example, Jose and Vladimir could be grouped by their shared function of developing requirement documents.
Discussion: Propose two valid decompositions of the same familiar system. What question does each make easier to answer, and what does each obscure?

Suggested answer: For a bicycle, a formal decomposition groups the frame, wheels, drivetrain, and brakes. It helps with assembly, replacement, and physical interfaces but can obscure how several parts jointly deliver a function. A functional decomposition separates propelling, steering, supporting the rider, and slowing. It helps reason about outcomes but obscures which parts implement them. Both are useful provided their cross-connections remain visible.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 53-54.

Hierarchy

Hierarchy arranges entities in ranked layers or grades, as in many social systems
What makes one grade rank above another?

More scope: a governor outranks a mayor (a state is larger than a city)
More importance or performance: a black belt outranks a brown belt
More responsibility: a president outranks a vice president

Figure 3.2 shows the hierarchy that Figure 3.1 leaves unspecified: Sue ranks above the group leaders Amy, John, and Phil, who rank above the other members.

Hierarchy arranges entities in ranked layers. Social and organizational systems provide familiar examples.
Rankings can reflect scope, performance, or responsibility. A governor and a mayor illustrate scope, belt grades illustrate skill, and a president and vice president illustrate responsibility.
Ask students which ranking criterion applies to their own examples.
Figure 3.1 does not identify Sue’s rank relative to Amy, John, and Phil. Figure 3.2 uses the Role column of Table 3.1 to show that hierarchy.
Leaders also participate in functional interactions. A person’s position in the interaction diagram therefore does not establish their rank.
Discussion: Can a person be high in one hierarchy and low in another, such as responsibility versus technical expertise? What architectural confusion follows if we collapse those rankings?

Suggested answer: Yes. A project manager may have high decision responsibility while a junior specialist has greater expertise in a particular subsystem. Responsibility hierarchy answers who authorizes or owns a decision. Expertise hierarchy answers who can best assess its technical content. Collapsing them can route technical questions to the wrong person or treat advice as authorization. Examples of the three ranking bases: system/subsystem for scope, graded skill levels for performance, and project manager/work-package lead for responsibility.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 54.

Figure 3.2 · Hierarchy in Team XT

Three ranked layers show managers, group leaders, and members. The diagram leaves reporting relationships within each layer unspecified. Source: Crawley, Cameron & Selva (2016), Fig. 3.2.

Table 3.1’s Role column places Sue in the manager layer, Amy, John, and Phil in the group-leader layer, and the other members below them.
Sharing a layer indicates equal rank. It does not specify reporting relationships within that layer.
Compare the functional exchanges in Figure 3.1 with the ranks in Figure 3.2. Each diagram selects different information about the same team.
Ask students to identify what each diagram shows and what it leaves unspecified. An omitted relationship may still exist.
Discussion: What question can Figure 3.2 answer immediately that Figure 3.1 cannot? What can Figure 3.1 answer that Figure 3.2 cannot?

Suggested answer: Figure 3.2 immediately answers who occupies a higher organizational tier, such as Sue relative to the group leaders. Figure 3.1 answers which activities exchange information and contribute to design development. A higher tier does not identify every direct reporting link, and an interaction arrow does not imply managerial authority. Use the reporting decomposition when a specific reporting relationship is needed. In Figure 3.2, Sue is the manager and Amy, John, and Phil are group leaders.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 54, Fig. 3.2.

Hierarchic Decomposition

Often, decomposition and hierarchy combine into a hierarchic decomposition: more than two levels, with reporting relationships between them
Smaller groups are easier to scan than a flat list. The text uses seven ± two as a rough grouping guide
Requirements, Concepts, and Support provide one grouping. Other questions may call for grouping by location, connectivity, or functional relationship

Hierarchic decomposition combines ranked levels with a breakdown into smaller groups. Figure 3.3 adds groups and reporting relationships to the layers in Figure 3.2.
The text uses Miller’s 7 ± 2 as a grouping heuristic. Several small groups are easier to scan than one long list. This is a rule of thumb rather than a universal design limit.
Requirements, Concepts, and Support provide one useful grouping. Location, shared tools, or another functional criterion could lead to a different decomposition.
Choose the decomposition according to the question being studied.
Discussion: If Team XT were decomposed by location rather than function, which coordination problem would become visible, and which functional story would become harder to see?

Suggested answer: A location-based grouping makes Cambridge–Moscow handoffs, time-zone coordination, and dependence on remote communication visible. It makes the end-to-end requirements-to-design story harder to see because people performing related functions can lie in different location groups. The grouping changes the view of the same team, rather than changing who actually communicates or what work must occur. Concrete cross-site exchanges include Amy supplying Natasha and Alex supporting Analyst 2.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 54-55; Miller (1956), cited by the authors as Ref. 1.

Figure 3.3 · Hierarchic Decomposition of Team XT

Three group leaders reporting to Sue, about four people reporting to each leader. Source: Crawley, Cameron & Selva (2016), Fig. 3.3.

Trace the reporting relationships: Amy leads Requirements, John leads Concepts, and Phil leads Support. All three report to Sue, with about four members reporting to each leader.
The diagram has three levels and small groups of direct reports.
Compare Figures 3.1, 3.2, and 3.3. They show functional interactions, organizational ranks, and reporting groups, respectively.
These are different representations of the same 16 team members. Select a view according to the information needed.
Discussion: Does this reporting decomposition also minimize the functional interactions that cross group boundaries? Figure 3.1 supplies the evidence needed to test the organizational choice.

Suggested answer: Not necessarily, and the reporting chart cannot establish that it is minimal. Requirements, concept development, and support must still interact across groups. To test the claim, overlay Figure 3.1’s functional exchanges onto these groups and compare cross-group exchanges with alternative groupings, ideally weighting their frequency, criticality, and coordination cost. Some cross-boundary interaction is necessary to deliver the design. Eliminating all of it is not a sensible objective. Examples to trace include Amy supplying Natasha and Alex supporting Analyst 2.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 55, Fig. 3.3.

Simple, Medium, and Complex Systems

Simple system: a one-level decomposition into essentially atomic elements, using 7 ± 2 as a rough guide (Figure 3.4)
Medium-complexity system: a two-level decomposition, with up to 9² = 81 elements at the lowest level under that guide (Figure 3.3)
Complex system: a two-level diagram whose lowest elements are still abstractions of further structure

Figure 3.4: one-level decomposition of Team XT. Source: Crawley, Cameron & Selva (2016).

Practical scale limit

Decomposition diagrams usually show one or two levels at a time. With nine elements per grouping, a third level could contain 729 elements.

Present simple, medium, and complex as the textbook’s scheme for describing decomposition depth.
A simple system has one level of essentially atomic elements, using 7 ± 2 as a rough grouping guide. Figure 3.4 shows Team XT reduced to its main groups.
A medium-complexity system has two decomposition levels. With up to nine elements per grouping, the lowest level could contain 9² = 81 elements.
A complex system may use the same two-level diagram while its lowest displayed elements still contain further structure.
For example, Natasha’s box might stand for an entire organization that she leads. The diagram would then hide additional decomposition levels.
A third decomposition level could contain 9³ = 729 elements under the same assumption. This helps explain why diagrams usually show only one or two levels at a time.
Discussion: What evidence would tell you that a Level 2 box is atomic for your purpose? How would you check for relevant internal structure?

Suggested answer: An element is atomic for the present model when its interfaces and behavior can be specified and checked without examining its internal parts for the decision at hand. Evidence includes an adequate interface specification, tested behavior, and no unresolved internal dependency that changes the architectural conclusion. If a failure, constraint, or design tradeoff depends on hidden internals, the box is an abstraction needing further investigation. A small diagram alone is not evidence of atomicity.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 55-56, Figs. 3.3-3.4.

Decomposition Levels and Atomic Parts

Level 0 is the reference system. Level 1 down and Level 2 down describe its constituents at successive depths. The architect’s viewpoint determines Level 0
Names such as module, assembly, component, routine, and section vary across disciplines and organizations

Atomic part: from Greek átomos, “indivisible.”

Mechanical systems: “Call it a part when you can’t take it apart.”
Informational systems: “Call it a part if it loses meaning when you take it apart.”

Level 0 identifies the reference system. Level 1 down contains its immediate constituents, and Level 2 down contains their constituents.
The architect’s viewpoint determines Level 0. Terms such as module, assembly, component, routine, and section vary between disciplines and organizations.
Atomic comes from the Greek átomos, meaning indivisible. It describes a stopping point for the current decomposition.
In a mechanical model, a bolt, screw, or chip may be treated as a part. In an informational model, a word, instruction, or data unit may lose its intended meaning if divided further.
Level 1 up and Level 2 up describe larger systems containing the reference system.
Atomicity depends on the purpose of the model. A chip or screw can have internal structure that is irrelevant to the current question.
Discussion: At what level would a battery cell be atomic for a vehicle architect, and at what level would it cease to be atomic?

Suggested answer: For a vehicle-level energy or packaging study, a battery cell can be treated as atomic once its voltage, capacity, mass, thermal limits, and interfaces are adequate inputs. It ceases to be atomic when investigating electrode design, electrolyte behavior, internal degradation, or thermal-runaway mechanisms. There is no universally correct numerical level: with vehicle as Level 0, pack as Level 1, and module as Level 2, the cell would be Level 3. Choosing the pack as Level 0 renumbers it.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 56-57.

3.4 Special Logical Relationships

The Class/Instance Relationship

A class describes a category’s general features. An instance is a particular occurrence of that class
A car model defines a class. A Vehicle Identification Number (VIN) identifies an individual car, which is an instance
A part number refers to a class. A serial number identifies an instance

Class and instances in Team XT

Table 3.1’s Analyst 1 and Analyst 2 can be represented as instances of the class Analyst. The 11 players on a soccer team and the 88 keys of a piano are instances of the classes “Player” and “Key.”

A class describes a category’s general features. An instance is a particular occurrence of that class.
A car model identifies a class, and a VIN identifies an individual car. Similarly, a part number identifies a class and a serial number identifies an instance.
Team XT’s Analyst 1 and Analyst 2 can be modeled as instances of the class Analyst.
Other examples include the 11 players on a soccer team and the 88 keys of a piano. Ask students to suggest another class and identify its instances.
Instances share a class definition but can have different attribute values, states, and histories.
Discussion: In Team XT, which properties belong to the class “Analyst,” and which belong only to Analyst 1 or Analyst 2?

Suggested answer: The Analyst class describes the shared role: analyzing candidate designs, required competencies, and the expected input/output interfaces of that role. Analyst 1 and Analyst 2 have particular identities, assignments, locations, workloads, and experience values. A class can define an attribute such as location without fixing the same value for every instance. Other examples: a sensor model is a class and the installed sensor with serial number S17 is an instance. The identifier names the instance. It is not itself the physical sensor. Table 3.1 specifically identifies Analyst 2 as receiving Alex’s support. Do not automatically assign that relationship to every Analyst instance or treat a shared observed location as a defining class property.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 57.

The Specialization Relationship

Specialization/generalization describes the connection between a general object and a set of more specific objects
Colonial, Victorian, and modern houses are more specific kinds of “House”
In Team XT, we created three specializations of the generalization “Group”: a requirements group, a design (concepts) group, and a support group

Specialization is akin to inheritance in object-oriented programming: a class is created from a more general class, inheriting some attributes and functionality while adding its own.

Specialization relates a general kind to a more specific kind. Compare “this kind of house” with “this particular house” to distinguish specialization from instantiation.
Colonial, Victorian, and modern houses are specializations of House. A particular Victorian house is an instance of that specialization.
Team XT specializes Group into Requirements, Concepts, and Support, each with its own purpose and composition.
In object-oriented programming, inheritance lets a specialized class retain attributes and functionality from a general class while adding its own.
Students with programming experience can illustrate the relationship using a class hierarchy from their code.
Discussion: Classify “vehicle,” “electric vehicle,” and “the car with VIN 123” using both relationships.

Suggested answer: Vehicle is a general class. Electric Vehicle is a specialization with additional properties, such as an electric propulsion system. The particular car identified by VIN 123 is an instance of an appropriate vehicle class, including Electric Vehicle if it has that propulsion type. Specialization relates types through “is a kind of”. Instantiation relates a concrete occurrence to its type through “is an instance of.” In code, ElectricVehicle can inherit from Vehicle, while car123 is an instantiated object. Instances need not have identical attribute values. Neither specialization nor instantiation means “is a physical part of.”

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 57.

Recursion

Recursion: an object or process defined in terms of itself, or an organizing pattern that repeats at successive levels
Team XT contains three groups that are themselves small teams, repeating the team structure one level down
Software engineering uses recursion explicitly and often: a class Node with an attribute Neighbors that is itself an array of Nodes

Recursion occurs when an object or process is defined in terms of itself, or when the same organizing pattern recurs at successive levels.
Team XT contains groups that are themselves small teams. The team structure repeats one level down.
A software example is a class Node whose Neighbors attribute is an array of Node references. This type of definition appears in graphs, trees, and linked lists.
Repeated Analyst instances illustrate repetition at one level. Teams containing subteams illustrate a pattern repeated across levels.
Discussion: Which properties must repeat across levels before you would call a structure recursive rather than merely nested?

Suggested answer: The same organizing rule or relationship pattern must recur at successive levels, such as a team containing subteams that themselves coordinate members using a team structure. A box containing a battery and a cable is merely nested unless that same organizational rule recurs inside its parts. In a recursive algorithm, the same operation applies to smaller instances of the problem and needs a termination condition. A self-referential Node type permits recursion but does not by itself guarantee a tree or termination. The recurring pattern need not have exactly the same size or identities at every level.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 57-58.

3.5 Reasoning through Complex Systems

Top-Down / Bottom-Up / Middle-Out

Top-down

Start from the goals of a system, proceed to concept and high-level architecture, then increase detail until reaching the smallest entities of interest. Follows the “left-hand side” of the systems-engineering V model.

Bottom-up

Start from the artifacts, capabilities, or services available at the lowest-level entities, and build upward, predicting emergence.

Middle-out

Start at an intermediate level and reason about the levels above and below it. The chosen system is usually part of a larger system.

Top-down reasoning starts with system goals, develops a concept and architecture, and then adds detail. This follows the left side of the systems-engineering V model and much of the textbook’s development.
Bottom-up reasoning starts with available components or capabilities and considers what they can accomplish together. For example, a CEO could assemble 16 employees and ask them to organize a design process.
Middle-out reasoning begins at an intermediate level and examines the levels above and below it.
The chosen system is usually part of something larger and contains smaller systems. Top and bottom therefore refer to the scope of the current study.
The book also describes outer-in reasoning: begin with both the goals and the available capabilities, then work toward a meeting point to identify mismatches.
Discussion: For a redesign constrained by an installed legacy subsystem, where would you begin and why? Identify what must be reasoned downward and what must be reasoned upward.

Suggested answer: Begin at the fixed legacy subsystem’s interfaces and capabilities: a middle-out approach is natural when that subsystem is a binding constraint. Reason upward to determine what system-level performance it can support and whether it meets stakeholder needs. Reason downward to establish internal limitations, integration details, and necessary adaptations. Keep a top-down check from stakeholder goals so the redesign does not simply reproduce the legacy system’s limitations.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 58.

Zigzagging

Term coined by Nam Suh in his work on axiomatic design
Alternate between form and function, using each decision to guide the next
For Team XT, begin with developing a design, propose small groups, then identify what each group must do. Repeat at lower levels

Architectural reasoning in practice

Zigzagging between form and function can accompany top-down, bottom-up, or middle-out reasoning.

Nam Suh introduced zigzagging in axiomatic design, which relates needs to functional requirements and design parameters.
Zigzagging alternates between reasoning about function and reasoning about form.
In Team XT, begin with developing a design, propose the Requirements, Concepts, and Support groups, and then identify the functions each group must perform. Repeat at lower levels as needed.
Zigzagging can accompany top-down, bottom-up, or middle-out reasoning.
At each switch, ask whether the proposed form can provide the required function, or which functions the proposed form can support. Use that answer to guide the next choice.
Discussion: Start from one desired function in a student project. Propose a form, then state the next lower-level function that choice creates.

Suggested answer: Example: a student robot must grasp an object. Choose a motor-driven two-finger gripper as candidate form. That choice creates lower-level functions such as generating finger motion, transmitting force, and limiting contact force to avoid damage. A proposed force sensor then creates the further function of interpreting its signal and adjusting motor effort. Each form choice constrains the functions that must be achieved next. Other gripper concepts would lead to different subfunctions. An alternative example is delivering water to soil: choosing a pump, reservoir, and tubing creates pressurizing, conveying, powering, and flow-control functions. A gravity-fed reservoir and valve creates different subfunctions.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 58-59; Suh (1998), cited by the authors as Ref. 3.

3.6 Architecture Representation: OPM

Views and Projections

A description of a complex system’s architecture contains more information than any one person can readily comprehend.

Integrated model and projections: generate the needed views from one shared model. In 3D CAD, for example, floor plans, façades, and sections derive from the same geometry.

This course uses OPM (Object-Process Methodology), which follows the integrated-model approach.

A complete architecture description usually contains more information than someone can consider at once.
Separately maintained views require coordination when the design changes. Views generated from one integrated model share the model’s information.
Use the building analogy: separately drawn floor plans, façades, and sections must be checked against one another. A 3D CAD model can generate them from shared geometry.
OPM uses an integrated model to represent objects, processes, and their relationships. Individual diagrams can display the information needed for a particular question.
Shared information helps keep views consistent, but the underlying model still needs to be checked.
Discussion: What governance or tooling is needed to keep separately maintained views consistent after a design change?

Suggested answer: Use stable entity identifiers, an authoritative model or controlled data source, versioned changes, named owners, and traceability from each view to the model elements it shows. Changes to an interface should trigger review or regeneration of every dependent view and automated consistency checks where possible. Agree on units, states, and interface meanings as well as names. Shared-model projections reduce synchronization errors, but they cannot guarantee that the underlying model is complete or physically correct.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 59-60.

OPM

Dov Dori developed Object-Process Methodology at Technion to represent objects and processes in one model
Objects (boxes) and processes (ovals) connect through typed relationships. An object can enable a process as an instrument, or a process can change it
A single model holds form, function, and logical relationships. Individual diagrams display selected details

Dov Dori developed Object-Process Methodology at Technion to combine objects and processes in one model.
Objects represent form and appear as boxes. Processes represent function and appear as ovals.
Typed links describe the relationships. An instrument enables a process and is treated as unchanged. A process can also create, consume, or change an object, corresponding to the operand role introduced in Chapter 2.
The model includes form, function, and logical relationships. Use diagrams and projections to show selected details without displaying the entire model at once.
Discussion: What is gained by placing objects and processes in one model? What new diagram-density problem does that create?

Suggested answer: Putting objects and processes together makes function-to-form allocation and operand changes explicit: we can ask what enables each process and what it changes, consumes, or produces. The cost is density: many objects, states, and typed links can clutter one drawing. Use in-zooming, abstraction, and purpose-specific diagrams within the same integrated model. A single model does not require every detail to appear on one sheet.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 61-62.

Figure 3.6 · An OPM Diagram

Building a house: objects (Crane, Lumber, Foundations…) and processes (Foundation constructing, Wall constructing, Roofing) in one view. System Architect: Dov Dori, inventor of OPM. Source: Dori, D., gollner.ca (2008), reproduced in Crawley, Cameron & Selva (2016), Fig. 3.6.

Identify boxes as objects and ovals as processes in the house-building example.
Objects include Crane, Raw material, Plan, Architect, Constructor, Lumber, Nails, Saw, Tile, Foundations, Wall, Roof, and House. The Building process contains Foundation constructing, Wall constructing, and Roofing.
Trace the links: Building consumes raw material, while Plan, Architect, and Constructor enable it. The subprocesses produce Foundations, Wall, and Roof, which are parts of House.
The figure shows these relationships without specifying a construction schedule.
Relate the notation to form, function, decomposition, and functional relationships from Chapters 2 and 3.
Check the link symbols when interpreting the figure. Filled dots, open circles, arrowheads, and aggregation triangles have different meanings.
Discussion: Choose one object and explain whether the process changes it, uses it without changing it, or produces it.

Suggested answer: Choose the saw: it enables Wall constructing and is treated as unchanged at this abstraction, so it is an instrument rather than a produced output. Lumber and nails are input materials incorporated into the wall. The wall is an output produced by the construction process. Plan is another enabling object used without being consumed. If tool wear matters to the question, add a wear process affecting the saw to represent that additional physical change. In the larger Building process, Plan is an instrument, raw material is consumed, and the subprocesses produce Foundations, Wall, and Roof. Justify each role with its link symbol. A modeled unchanged plan can still be revised elsewhere in a real project.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 61, Fig. 3.6.

OPM Representations

OPM has its own visual conventions for the logical relationships from Section 3.4:

Relationship	OPM Notation
Decomposition / aggregation	Triangle-headed tree
Specialization / generalization	Open-triangle tree
Class / instance	Paired filled/open-triangle tree

Course modeling convention

This course uses OPM as its architecture representation tool throughout.

Use this table when drawing the three logical relationships in OPM.
Decomposition/aggregation uses a filled triangle. Specialization/generalization uses an open triangle.
Class/instance uses the paired filled/open-triangle symbol in Table 3.2.
Practice by representing a small portion of Team XT’s decomposition in OPM.
The textbook compares local notation patterns across modeling methods. Translating complete models or generating views requires more than substituting these symbols.
Discussion: Cover the labels and ask students to identify each relationship from the triangle symbol alone, then explain the semantics in words.

Suggested answer: Filled triangle: aggregation/participation, meaning the whole consists of the linked parts, such as a pump and its components. Open triangle: generalization/specialization, meaning a specialized kind inherits the general kind’s properties, such as Centrifugal Pump being a kind of Pump. Paired filled/open triangles: classification/instantiation, linking a class to a particular occurrence. The quick semantic checks are “part of,” “kind of,” and “instance of”. These are different claims even when the same nouns appear.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 62, Table 3.2.

Section 3.7 Summary

Feature of Complex Systems	Approach
Smaller entities make up the system	Use decomposition and hierarchy, showing about two levels at a time or stopping at atomic parts
Logical relationships recur among entities	Identify class/instance, specialization/generalization, and recursion
Relationships connect levels, form, and function	Reason top-down, bottom-up, or middle-out, and zigzag between form and function
Architecture can be viewed or projected for understanding	Project from a single integrated model (OPM)

Ask students to explain how each row connects a feature of complex systems to a method for studying it.
Decomposition and hierarchy organize smaller entities. Class/instance, specialization/generalization, and recursion describe recurring logical relationships.
Top-down, bottom-up, and middle-out reasoning work through levels. Zigzagging connects decisions about form and function.
Projections select information from an integrated architecture model.
Compare this summary with Chapter 2’s Table 2.6, which addressed systems with fewer entities.
Table 3.3 also previews methods developed later: distinguishing the system, accompanying systems, and context, tracing value-pathway layers, reasoning about functions and goals, and “2 Down 1 Up” reasoning.
Discussion: Give students an unfamiliar complex system and ask which row they would use first. Different starting choices should reveal different assumptions about the problem.

Suggested answer: For an unfamiliar automated warehouse, one defensible start is decomposition into storage, transport, picking, and coordination subsystems to establish scope. If the immediate problem is an installed robot fleet, start middle-out from its capabilities and interfaces. If inconsistent drawings are the problem, start with an integrated-model projection. If repeated robot types dominate the description, start with class/instance structure. There is no unique first row. A good answer names the immediate question and explains why its chosen approach exposes the relevant assumptions. First establish the system boundary and the question. If choosing a design from required capabilities, reason between function and form.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, pp. 62-64, Table 3.3.

Next: Form

Chapter 4 begins Part 2, Analysis of System Architecture, which examines form and function in more detail.

Reference

Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 3.

Chapter 3 completes Part 1, System Thinking.
Chapter 1 introduced architecture through examples such as Apollo, NPOESS, and Boeing. Chapter 2 developed the four tasks using simple systems. Chapter 3 added methods for handling more entities and relationships.
Chapter 4 begins Part 2, Analysis of System Architecture. Chapters 4–8 examine form and function in more detail, starting with simple systems before applying the methods to complex cases.
Exit prompt: In one sentence, name the technique from Chapter 3 you would use first when a system feels complicated, and state what information it would reveal.

Suggested answer: “I would begin with a two-level decomposition to reveal the major subsystems, their responsibilities, and the interfaces I need to understand.” Also accept a justified alternative, such as tracing a value pathway to expose dependencies or comparing model projections to locate a mismatch. The answer should name a technique and the information it reveals, rather than simply promise to simplify the system.

[Sources] - Crawley, Cameron & Selva, System Architecture (2016), Ch. 3, p. 64, and the transition to Part 2.