I'm working through the impedance mismatch between Systems and Software Engineering at the moment, looking for some light at the end of the tunnel. Had a good chat with a reputable fellow on Friday. Some notes.
System Concepts
- System of Systems
- A system that itself is composed of systems
- System
- Has inputs, outputs and processing.
- Does something definable for a "user", even in the absence of other connected systems. For example, a desktop computer with a word processor might be a system in and of itself.
- May itself be a System of Systems.
- Subsystem
- Like a system has inputs, outputs and processing.
- May not do anything useful without another connected system operating correctly. For example, we might eventually decompose to a subsystem that consists solely of software. Without its related hardware subsystem it can't do anything useful.
- Component
- A part of the "physical" architecture.
- Could be software or hardware. Hardware may be pre-installed/pre-configured for its purpose.
- Could be an assembly of other parts.
- Closely related to (equivalent to?) Configuration Item concept.
- Function
- A part of the "functional" architecture.
- I'm still not completely across the definition of what is meant by function, but something akin to a control in a robustness diagram.
- May be decomposed to finer-grained functions
- Definitely not the same as "method" :)
System Structure
Ultimately, each component will have a set of functions associated with it. A component belongs to a given subsystem, which belongs to a given System, which itself belongs to a System of Systems. This implies that there is a set of functions at each of these system levels, so perhaps the process of developing the set of components is more interesting.
Refinement Process
The general waterfall idea is that you start at whichever level you have been given, say the System of Systems. That level has a number of functions associated with it, along with detailed requirements. You develop the next level system down based on your experience, and based on your knowledge of the interfaces between the functions each system will implement.
At the higher level, your goal is to keep systems "real" for as long as possible. You want to ensure that systems are defined in such a way that they can operate on their own without relying on any other.
That only lasts so long as common hardware, operator positions, etc start to crowd their way in. Then you are at the subsystem level, and still trying to make the same sorts of decisions. How can I draw out the subsystems and components in such a way as to make sense in the appropriate engineering domain, as well as to map cleanly to a set of functions?
At each level you decompose the functional architecture and physical architecture incrementally. Initially, the functional architecture dominates. Once you are down to defining subsystems within a system, both play a strong role. The definition of components within a subsystem is strongly influenced by the engineering domain, for example the software engineering domain.
A very rough example
A standard example case in computer science is the Pizza Shop, so I'll give this a rough go based on my evolving understanding. Let's start with some simple context and assumed functionality:
The context is a pizza shop that takes ingredients from suppliers, orders from over the phone, and power that is only used for cooking to produce served pizzas for customers.
The shop only does this one thing: Make Pizza. It doesn't maintain any accounts. It doesn't pay rent to landlords. Nothing complex here. So what kinds of subsystems can we expect to see?
I thought I would break this down roughly by work position. I'm going to have someone on the front desk. I'm going to have someone preparing pizzas, some pizzas in the oven cooking, and someone boxing up the pizzas for serving back to the customer. I haven't explicitly included the role of staff in this system, though they are implicitly there. We are trying to keep this simple, after all.
Having some idea of how I want to break the system up, I now need to refine my functional architecture and begin to describe my physical architecture:
The physical and functional decompositions are related, so here is the refined functional architecture:
The functional decomposition is somewhat subservient to the "physical" domain knowledge, here. However, the functions are decomposed to fit into subsystems. Any function that lands across multiple subsystems is broken up into two or more smaller functions with interfaces in-between. We keep an eye on the kinds of interfaces we are building between functions, and that will hopefully help us avoid some potential pitfalls in subsystem definition.
The theory is that this functional architecture will help us focus on the right kinds of things in the physical architecture. It will help us recognise interfaces that exist between subsystems and components, and control them properly. It will help us avoid spreading functions too widely between elements of the physical architecture without a proper understanding of how they will fit together to form the bigger picture.
The same approach should work one more level down. Here is the unrefined functional architecture of the Preparation subsystem:
Nice and simple? Yes. One component? No.
We know from experience that there will be a preparation table, and bins for storing necessary ingredients. Those bins must be populated, so someone is presumably cutting up some of those ingredients for storage into those bins. It should look something like this:
A refinement on the functional architecture to accommodate these components looks like this:
Now, how you draw the physical architecture is very much a feature of the engineering domain. However, we will be dealing with components of one form or another. I have more-or-less used a software component diagram, here.
It still begs the question for multi-view software architecture, as to which view the functional architecture should sit in. Is it the logical view? Should we consider the whole multi-view software architecture to be only describing different aspects of the physical architecture, or the functional architecture feature in there as well. What did the pioneers in this area intend, and where should we move on from what they intended?
Conclusion
I think I am getting closer to a proper understanding of the systems engineering model and process for functional and physical architecture. It leaves me with two basic ways to apply (for example) the 4+1 View architecture model. Either,
- The Logical View is the functional architecture with the remaining views capturing different aspects of the physical (component) architecture, or
- The functional architecture is not covered by the model, in which case the logical view should be a description of the (physical) components without reference to aspects covered in separate views. The functional architecture would then be covered elsewhere, perhaps in the requirements specification driving the architecture.
Benjamin