Difference between revisions of "Logical Architecture"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(101 intermediate revisions by 9 users not shown)
Line 1: Line 1:
The purpose of logical architecture definition (or [[Design (glossary) |design]]) is to work out the functionality and behavior of the [[System (glossary)|system]] while in service. The [[Logical Architecture (glossary)|logical architecture]] of a system is composed of a set of related technical concepts and principles that support the logical operation of the system. It is described with views corresponding to viewpoints, and includes a [[Functional Architecture (glossary) |functional architecture]] view, a [[Behavioral Architecture (glossary)|behavioral architecture]] view, and a [[Temporal Architecture (glossary)|temporal architecture]] view. Other additional views are suggested in architectural frameworks, depending on the domain (refer to the Department of Defense (DoD) ''Architecture Framework'' (DoDAF) (DoD 2010), ''The Open Group Architectural Framework'' (TOGAF) (The Open Group 2011), etc).
+
----
 +
'''''Lead Authors:''''' ''Alan Faisandier, Garry Roedler'', '''''Contributing Author:''''' ''Rick Adcock''
 +
----
 +
Logical Architecture Model Development may be used as a task of the activity "Develop candidate architectures models and views," or a sub-process of the [[System Architecture Design Definition]] process. Its purpose is to elaborate models and views of the functionality and behavior of the future {{Term|Engineered System (glossary)|engineered system}} as it should operate while in service. The {{Term|Logical Architecture (glossary)|logical architecture}} model of a engineered {{Term|System of Interest (SoI) (glossary)|system of interest (SoI)}} is composed of a set of related technical concepts and principles that support the logical operation of the system. It may include a {{Term|Functional Architecture (glossary)|functional architecture}} view, a {{Term|Behavioral Architecture (glossary)|behavioral architecture}} view, and a {{Term|Temporal Architecture (glossary)|temporal architecture}} view. Other additional views are suggested in {{Term|Architecture Framework (glossary)|architecture frameworks}}, depending on the domain.
 +
 
 +
Note: The term ''Logical Architecture'' is a contraction of the expression ''Logical View of the System Architecture''.
  
 
==Concepts and Principles==
 
==Concepts and Principles==
  
===Functional Architecture View===
+
===Functional Architecture Model===
  
A [[Functional Architecture (glossary) |functional architecture]] is a set of functions and their sub-functions that defines the transformations performed by the system to achieve its mission.
+
A {{Term|Functional Architecture (glossary)|functional architecture}} model is a set of functions and their sub-functions that defines the transformations performed by the system to complete its mission.
  
'''Function and Input-Output Flow''' - A [[Function (glossary) |function]] is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematical notation of a function is '' '''''y'''''= ƒ('''''x''''',t)'', in which '''y''' and '''x''' are vectors that may be represented graphically.
+
'''Function and Input-Output Flow''' - In the context of System Architecture, functions and input-output flows are architecture entities. A {{Term|Function (glossary)|function}} is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematical notation of a function is '''''y''''' ''= ƒ('' '''''x''''' '',t)'', in which '''y''' and '''x''' are vectors that may be represented graphically and t = time.
  
In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and its derived requirements as well as the corresponding inputs and outputs of those functions. Generally speaking, there are two kinds of functions:
+
In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and its derived requirements, as well as the corresponding inputs and outputs of those functions. Generally speaking, there are two kinds of functions:
  
*functions that are directly deduced from functional and interface requirements. These equations express the expected services of a system necessary to meet its [[System Requirement (glossary)|system requirements]] and
+
# Functions that are directly deduced from functional and interface requirements. These functions express the expected services of a system necessary to meet its {{Term|System Requirement (glossary)|system requirements}}.
*functions that are derived and issued from the alternative solutions of [[Physical Architecture (glossary)|physical architecture]] and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture elements.
+
# Functions that are derived and issued from the alternative solutions of the {{Term|Physical Architecture (glossary)|physical architecture}} model and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture model elements.
  
'''Functional Hierarchy/Decomposition of Functions''' At the highest level of a hierarchy (Figure 1), it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0 in Figure 1). In order to understand in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine. But a static functional hierarchy does not represent well how the flows of inputs and outputs are exchanged.
+
'''Functional Hierarchy/Decomposition of Functions''' - At the highest level of a hierarchy (Figure 1), it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0 in Figure 1). In order to understand, in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine.
 +
 
 +
This view of functional hierarchy represents a static view of functions which would be populated at different levels over a number of iterations, depending upon the {{Term|Synthesis (glossary)|synthesis}} approach used.  In general, it is not created by a single top-down decomposition. A static functional hierarchy on its own does not represent how effectively the flows of inputs and outputs are exchanged, and may need to be viewed alongside the other models below.  
  
 
[[File:Decomposition_of_Functions_AF_071112(2).png|600px|thumb|center|'''Figure 1. Decomposition of Functions (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
[[File:Decomposition_of_Functions_AF_071112(2).png|600px|thumb|center|'''Figure 1. Decomposition of Functions (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
===Behavioral Architecture View===
+
===Behavioral Architecture Model===
  
A [[Behavioral Architecture (glossary) |behavioral architecture]] is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements (ISO/IEC 26702 2007). A behavioral architecture can be described as a set of inter-related scenarios of functions and/or [[Operational Mode (glossary) |operational modes]].
+
A {{Term|Behavioral Architecture (glossary)|behavioral architecture}} model is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements (ISO/IEC 26702:2007). A behavioral architecture model can be described as a set of inter-related scenarios of functions and/or {{Term|Operational Mode (glossary)|operational modes}}.
  
'''Control (Trigger)''' - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the “on” position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.
+
'''Control (Trigger)''' - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the ''on'' position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.
  
'''Scenario (of Functions)''' - A scenario is a chain of functions performed as a sequence that synchronizes the functions between them by using their control flows to achieve a global transformation of inputs into outputs, as seen in the figures below. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed with considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architectures it is appropriate to use modeling techniques using diagrams, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010). Figures 2 and 3 provide examples of these diagrams.
+
'''Scenario (of Functions)''' - A scenario of functions is a chain of functions that are performed as a sequence and synchronized by a set of control flows to work to achieve a global transformation of inputs into outputs, as seen in the figures below. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed by considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architecture models, it is appropriate to use diagrams as modeling techniques, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010). Figures 2 and 3 provide examples of these diagrams.
  
 
[[File:Illustration_of_a_scenario_(eFFBD)_AF_071112.png|thumb|900px|center|'''Figure 2. Illustration of a Scenario (eFFBD).''' (SEBoK Original)]]
 
[[File:Illustration_of_a_scenario_(eFFBD)_AF_071112.png|thumb|900px|center|'''Figure 2. Illustration of a Scenario (eFFBD).''' (SEBoK Original)]]
Line 30: Line 37:
 
[[File:Illustration_of_a_scenario_Activity_Diagram_AF_071112.png|thumb|900px|center|'''Figure 3. Illustration of a Scenario (Activity Diagram).''' (SEBoK Original)]]
 
[[File:Illustration_of_a_scenario_Activity_Diagram_AF_071112.png|thumb|900px|center|'''Figure 3. Illustration of a Scenario (Activity Diagram).''' (SEBoK Original)]]
  
'''Operational Mode''' - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a "scenario of modes" -  a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger, as demonstrated in Figure 4 below:
+
'''Operational Mode''' - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a ''scenario of modes'', which is a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger, as demonstrated in Figure 4 below.
  
 
[[File:SEBoKv075_KA-SystDef_Scenario_of_Operational_Modes.png|300px|thumb|center|'''Figure 4. Scenario of Operational Modes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
[[File:SEBoKv075_KA-SystDef_Scenario_of_Operational_Modes.png|300px|thumb|center|'''Figure 4. Scenario of Operational Modes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
'''Behavioral Patterns''' - When designing scenarios or behavioral architectures, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment. A pattern can be represented with different notations. Behavioral design patterns are classified into several categories, which can be seen in the following examples:
+
'''Behavioral Patterns''' - When defining scenarios or behavioral architecture models, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment (Gamma, Helm, Johnson, and Vlissides 1995). A {{Term|Pattern (glossary)|pattern}} can be represented with different notations. Behavioral patterns are classified into several categories, which can be seen in the following examples (see also SEBoK Part 2: [[Patterns of Systems Thinking]]):
 +
* Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.
 +
* Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.
 +
* Failure detection, identification, and recovery (FDIR) patterns - such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.
  
*Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.
+
===Temporal Architecture Model===
*Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.
 
*Failure detection, identification, and recovery (FDIR) patterns- such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.
 
 
 
===Temporal Architecture View===
 
 
   
 
   
A [[Temporal Architecture (glossary) |temporal architecture]] is a classification of the functions of a system that are derived according to the frequency level of execution. Temporal architecture includes the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.
+
A {{Term|Temporal Architecture (glossary)|temporal architecture}} model is a classification of the functions of a system that is derived according to the frequency level of execution. Temporal architecture models include the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.
  
'''Temporal and Decisional Hierarchy Concept''' Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.
+
'''Temporal and Decisional Hierarchy Concept''' - Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.
  
To be more specific, "real-time" systems and "command-control" systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:
+
To be more specific, ''real-time'' systems and ''command-control'' systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:
  
*Disturbances on high frequencies (bottom of figure 5) - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or [[Failure (glossary)|failures]].
+
# Disturbances on High Frequencies (bottom of figure 5) - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or {{Term|Failure (glossary)|failures}}.
*Changes happening on low frequencies (top of figure 5) - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
+
# Changes on Low Frequencies (top of figure 5) - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
  
 
[[File:SEBoKv05 KA-SystDef Temporal and decision hierarchy levels.png|450px|thumb|center|'''Figure 5. Temporal and Decision Hierarchy Levels (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
[[File:SEBoKv05 KA-SystDef Temporal and decision hierarchy levels.png|450px|thumb|center|'''Figure 5. Temporal and Decision Hierarchy Levels (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
Line 56: Line 62:
  
 
===Purpose===
 
===Purpose===
The purpose of the logical architecture design process is to define, select, and synthesize a system’s logical architecture to enable it to satisfy and trade-off with the concerned system requirements as well as enable it to perform all operational scenarios. Because of the need for an iterative execution of the design, inputs and outputs evolve incrementally throughout the process. Generic inputs include system requirements, generic design patterns that designers identify and use to answer requirements, outcomes from system analysis processes, and feedback from system verification and validation processes.
+
The purpose of the Logical Architecture Model Development is to define, select, and synthesize a system’s logical architecture model to provide a framework against which to verify that a future system will satisfy its system requirements in all operational scenarios, within which trade-offs between system requirements can be explored in developing such systems.
  
Generic outputs are the selected independent logical architecture of the system and include, at minimum, views and models. These involve functional, behavioral, and temporal views, a traceability matrix between logical architecture elements and system requirements, and the solutions’ elements.
+
Generic inputs to the process include system requirements, generic architecture patterns that architects identify and use to answer requirements, outcomes from [[System Analysis|system analysis]] processes, and feedback from system [[System Verification|verification]] and [[System Validation|validation]] processes. Depending on the Life Cycle Model that is chosen, there will be iterations through which these inputs and outputs, and the relationships between them evolve and change throughout the process (see also [[Applying Life Cycle Processes]]).
 +
 
 +
Generic outputs from the process are either a single logical architecture model or a set of candidate logical architecture models together with the selected independent logical architecture model and a rationale for its selection. They include, at minimum, views and models. These involve functional, behavioral and temporal views, a traceability matrix between logical architecture model elements and system requirements.
  
 
===Activities of the Process===
 
===Activities of the Process===
 
Major activities and tasks performed during this process include the following:
 
Major activities and tasks performed during this process include the following:
  
*Identify and analyze functional and behavioral elements:  
+
* Identify and analyze functional and behavioral elements:  
**Identify functions, [[Input-Output Flow (glossary) |input-output flows]], [[Operational Mode (glossary)|operational modes]], [[Transition of Modes (glossary)|transition of modes]], and [[Operational Scenario (glossary)|operational scenarios]] from system requirements by analyzing the functional, interface, and operational requirements.
+
** Identify functions, {{Term|Input-Output Flow (glossary)|input-output flows}}, {{Term|Operational Mode (glossary)|operational modes}}, {{Term|Transition of Modes (glossary)|transition of modes}}, and {{Term|Operational Scenario (glossary)|operational scenarios}} from system requirements by analyzing the functional, interface, and operational requirements.
**Define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result in the deduction of the necessary functions to use, transform, move, and generate the input-output flows.
+
** Define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result in the deduction of the necessary functions to use, transform, move, and generate the input-output flows.
*Assign system requirements to functional and behavioral elements:
+
* Assign system requirements to functional and behavioral elements:
**Formally characterize functions expression and their attributes through the assignment of performance, effectiveness, and constraints requirements. In particular, study the temporal aspects from requirements to assign duration, response time, and frequency to functions.
+
** Formally characterize functions expressions and their attributes through the assignment of performance, effectiveness, and constraints requirements. In particular, study the temporal aspects from requirements to assign duration, response time, and frequency to functions.
**Formally characterize the input, output, and control flows expression and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements.
+
** Formally characterize the input, output, and control flows expressions and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements.
**Establish traceability between system requirements and these functional and behavioral elements.
+
** Establish traceability between system requirements and these functional and behavioral elements.
*Define candidate logical architectures. For each candidate:
+
* Define candidate logical architecture models for each candidate:
**Analyze operational modes as stated in the system requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of modes. Eventually decompose the modes into sub-modes and then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral patterns.
+
** Analyze operational modes as stated in the system requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of modes. Eventually decompose the modes into sub-modes and then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral patterns.
**Integrate these scenarios of functions in order to get a behavioral architecture model of the system (a complete picture of the dynamic behavior).
+
** Integrate these scenarios of functions in order to get a behavioral architecture model of the system (a complete picture of the dynamic behavior).
**Decompose previously defined logical elements as necessary to look towards implementation.
+
** Decompose previously defined logical elements as necessary to look towards implementation.
**Assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.
+
** Assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.
**Define several levels of execution frequency for functions that correspond to levels of decision in order to monitor system operations, prioritize processing on this time basis, and share out functions among those execution frequency levels to get a temporal architecture model.
+
** Define several levels of execution frequency for functions that correspond to levels of decision, in order to monitor system operations, prioritize processing on this time basis, and share out functions among those execution frequency levels to get a temporal architecture model.
**Perform functional failure modes and effects analysis and update the logical architecture elements as necessary.
+
** Perform functional failure modes and effects analysis and update the logical architecture elements as necessary.
**Execute the models with simulators (when possible) and tune these models to obtain expected characteristics.
+
** Execute the models with simulators (when possible) and tune these models to obtain the expected characteristics.
*Synthesize the selected independent logical architecture:
+
* Synthesize the selected independent logical architecture model:
**Select the logical architecture by assessing the candidate logical architectures against assessment criteria (related to system requirements) and compare them, using the system analysis process to perform assessments (see the [[System Analysis]] Topic). This selected logical architecture is called “independent logical architecture” because, as much as possible, it is independent of implementation decisions.
+
** Select the logical architecture by assessing the candidate logical architecture models against assessment criteria (related to system requirements) and compare them, using the system analysis process to perform assessments and decision management process for the selection (see the [[System Analysis]] and [[Decision Management]] topics). This selected logical architecture model is called ''independent logical architecture model'' because, as much as possible, it is independent of implementation decisions.
**Identify and define derived logical architecture elements created for the necessity of design and corresponding with the derived system requirements and assign these requirements to the appropriate system (current studied system or external systems).
+
** Identify and define derived logical architecture model elements created for the necessity of design and corresponding with the derived system requirements. Assign these requirements to the appropriate system (current studied system or external systems).
**Verify and validate the selected logical architecture models (using as executable models as possible), make corrections as necessary, and establish traceability between system requirements and logical architecture elements.
+
** Verify and validate the selected logical architecture models (using as executable models as possible), make corrections as necessary, and establish traceability between system requirements and logical architecture model elements.
*Feedback logical architecture definition and system requirements (this activity is performed after the physical architecture definition (design) process):
+
* Feedback logical architecture model development and system requirements. This activity is performed after the physical architecture model development process:
**Model the “allocated logical architecture” to systems and system elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments.
+
** Model the ''allocated logical architecture'' to systems and system elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments.
**Define or consolidate derived logical and physical elements induced by the selected logical and physical architectures. Define the corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements in requirements baselines of impacted systems.
+
** Define or consolidate derived logical and physical elements induced by the selected logical and physical architecture models. Define the corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements into the requirements baselines of impacted systems.
 
 
===Artifacts and Ontology Elements===
 
This process may create several artifacts, such as:
 
 
 
*system design documents (describe the selected logical and physical architectures)
 
*system design justification documents (traceability matrices and design choices)
 
 
 
This process handles the ontology elements of Table 1.
 
 
 
<center>
 
{|
 
|+'''Table 1. Main Ontology Elements as Handled within Logical Architecture Design.''' (SEBoK Original)
 
!Element
 
!Definition
 
----
 
Attributes (examples)
 
|-
 
|'''Function'''
 
|A task, action, or activity performed to achieve a desired outcome. A function uses input flows and generates output flows.
 
----
 
Identifier; name description; duration (execution time).
 
|-
 
|'''I/O Flow'''
 
|An input or an output or a trigger of a function (used for input-output flow, control flow). An I/O flow can be made of material and/or energy and/or information.
 
----
 
Identifier; nage; description; type (input, output, trigger); initial quantity; quantity consumed or produced; preconditions; priority; precision; accuracy; concurrency
 
|-
 
|'''Operational Mode'''
 
|An operational situation/configuration of a system characterized by its active functions (synonym of state). Inside an operational mode, the system can perform specific operational scenarios and activate the corresponding functions.
 
----
 
Identifier; name description
 
|-
 
|'''Scenario'''
 
|A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.
 
----
 
Identifier; name; description
 
|-
 
|'''Rationale'''
 
|Argument that provides the justification for the selection of an engineering element.
 
----
 
Identifier; name; description (rational reasons for relevance of the element)
 
|-
 
|'''Risk'''
 
|An event having a probability of occurrence and a gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and a danger or a threat.
 
----
 
Identifier; name; description; status
 
|}
 
</center>
 
 
 
Note: The element scenario is used for logical architecture because, as defined, a scenario includes a large set of functional, behavioral, and temporal elements. Sequences of operational modes and the transition of modes can be used alternatively, depending on the used modeling techniques.
 
  
===Methods and Modeling Techniques===
+
===Artifacts, Methods and Modeling Techniques===
 
Logical architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable models):
 
Logical architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable models):
  
*Functional models these include models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced Functional Flow Block Diagrams (eFFBD), and the function analysis system technique (FAST).
+
* Functional Models These include models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced Functional Flow Block Diagrams (eFFBD), and the function analysis system technique (FAST).
*Semantic models- these include models such as entities-relationships diagrams, class diagrams, and data flow diagrams.
+
* Semantic Models- These include models such as entities-relationships diagrams, class diagrams, and data flow diagrams.
*Dynamic models these include such models as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG. 2010), and petri nets.
+
* Dynamic Models These include such models as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG 2010), and petri nets.
  
Depending on the type of domain (defense, enterprise), architecture frameworks such as DoDAF (DoD 2010), TOGAF (The Open Group 2011), the Zachman framework (Zachman 2008), etc. provide descriptions that can help to represent additional aspects/views of architectures - see section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]]. See also practical means for using general templates related to ISO/IEC/IEEE 42010 (2011), which are available at: [http://www.iso-architecture.org/42010/templates]
+
Depending on the type of domain (e.g. defense, enterprise), {{Term|Architecture Framework (glossary)|architecture frameworks}}  provide descriptions that can help to represent additional aspects/views of architectures - see the section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]]. See also practical means for using general templates related to ISO/IEC/IEEE 42010 (ISO 2011).
  
 
==Practical Considerations==
 
==Practical Considerations==
Key pitfalls and good practices related to logical architecture design are described in the next two sections.
+
As stated above, the purpose of the logical architecture model is to provide a description of what a system must be able to do to satisfy the stated need.  This should help to ensure that the needs and/or concerns of all stakeholders are addressed by any solution, and that innovative solutions, as well as those based on current solution technologies, can be considered.  In practice it is human nature for problem stakeholders to push their own agendas and for solution architects or designers to offer their familiar solutions.  If a logical architecture model is not properly enforced with the chosen life cycle, it is easy for both problem and solution stakeholders to ignore it and revert to their own biases (see Part 5: [[Enabling Systems Engineering]]).  This is exacerbated if the logical architecture model becomes an end in its own right or disconnected from the main lifecycle activities.  This can occur either through the use of abstract language or notations, levels of detail, time taken, or an overly complex final architecture that does not match the purpose for which it was created.  If the language, scope, and timeliness of the architecture are not matched to the problem stakeholder or solution providers, it is easier for them to overlook it. Key pitfalls and good practices which can help to avoid problems related to logical architecture models are described in the next two sections.
  
 
===Pitfalls===
 
===Pitfalls===
Some of the key pitfalls encountered in planning and performing logical architecture design are provided in Table 2.
+
Some of the key pitfalls encountered in developing logical architecture are provided in Table 1.
  
 
<center>
 
<center>
 
{|
 
{|
|+'''Table 2. Pitfalls with Logical Architecture Design.''' (SEBoK Original)
+
|+'''Table 1. Pitfalls with Logical Architecture Development.''' (SEBoK Original)
 
!Pitfall
 
!Pitfall
 
!Description
 
!Description
 
|-
 
|-
|'''Inputs for design'''
+
|'''Problem Relevance'''
|The major input for design activity is the set of system requirements and there are times that they do not address the right level of design. The consequence is that the designer lets the requirements fall to the side and invents a solution with what he or she understands through the input.
+
|The logical architecture model should relate back to the operational scenarios produced by {{Term|Mission Analysis (glossary)|mission analysis}}.
 
|-
 
|-
|'''Decomposition too deep'''
+
|'''Inputs for Architecture Model'''
| A common mistake many beginners in design make that consists of decomposing the functions too deeply or having too many functions and input/output flows in scenarios or in the functional architecture of the current system block.
+
|The major input for architecture definition activity involves the set of system requirements and the instances in which they do not address the right level of architecture. The consequence is that the architect allows the requirements to fall to the side and invents a solution with what he or she understands through the input.
 
|-
 
|-
|'''Not considering inputs and outputs together with functions'''
+
|'''Decomposition Too Deep'''
|A current mistake is to consider only the actions supported by functions and decomposing them, while forgetting the inputs and the outputs or considering them too late. Inputs and outputs are integrated parts of a function.
+
| A common mistake made by many beginners in architecture consists of decomposing the functions too deeply or having too many functions and input/output flows in scenarios or in the functional architecture model of the current system block.
 
|-
 
|-
|'''Considering static decomposition of functions only'''
+
|'''Not Considering Inputs and Outputs Together with Functions'''
|Static function decomposition is the smallest functional design task and answers the question, "How is this done?" The purpose of the status decomposition is to facilitate the management or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical design almost finished.
+
|A common mistake is to consider only the actions supported by functions and decomposing them, while forgetting the inputs and the outputs or considering them too late. Inputs and outputs are integral parts of a function.
 
|-
 
|-
|'''Mixing governance, management, and operation'''
+
|'''Considering Static Decomposition of Functions Only'''
|Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Functional design should deal with behavioral design and with temporal design.
+
|Static function decomposition is the smallest functional architecture model task and answers the basic question, "How is this done?" The purpose of the static decomposition is to facilitate the management of or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical architecture is close to complete.
 +
|-
 +
|'''Mixing Governance, Management, and Operation'''
 +
|Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Logical architecture model should deal with behavioral architecture model as well as with temporal architecture model.
 
|}
 
|}
 
</center>
 
</center>
  
 
===Proven Practices===
 
===Proven Practices===
Some proven practices gathered from the references are provided in Table 3.
+
Some proven practices gathered from the references are provided in Table 2.
  
 
<center>
 
<center>
 
{|
 
{|
|+'''Table 3. Proven Practices with Logical Architecture Design.''' (SEBoK Original)
+
|+'''Table 2. Proven Practices with Logical Architecture Development.''' (SEBoK Original)
 
!Practice
 
!Practice
 
!Description
 
!Description
 
|-
 
|-
|'''Constitute scenarios of functions'''
+
|'''Constitute Scenarios of Functions'''
|Before constituting a decomposition tree of functions, one must model the behavior of the system, establishing scenarios of functions, and decompose functions as scenarios of sub-functions.
+
|Before constituting a decomposition tree of functions, one must model the behavior of the system, establish scenarios of functions, and decompose functions as scenarios of sub-functions.
 
|-
 
|-
|'''Analysis and synthesis cycles'''
+
|'''Analysis and Synthesis Cycles'''
|When facing a system that seems to contain a lot of functions, try to synthesize functions into higher abstraction levels of functions with the help of criteria. Do not perform analysis only, but instead, small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.
+
|When facing a system that contains a large number of functions, one should attempt to synthesize functions into higher abstraction levels of functions with the assistance of criteria. Do not perform analysis only; instead, conduct small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.
 
|-
 
|-
|'''Alternate functional and behavioral views'''
+
|'''Alternate Functional and Behavioral Views'''
|A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Use this to consider a behavioral view of the system that transitions from one operational mode to another.
+
|A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Utilize this to consider a behavioral view of the system that allows for the transition from one operational mode to another.
 
|-
 
|-
|'''Order to create a scenario of functions'''
+
|''' The Order to Create a Scenario of Functions'''
|When creating a scenario of functions, it is more efficient from a mouthed viewpoint to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.
+
|When creating a scenario of functions, it is more efficient to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.
 
|}
 
|}
 
</center>
 
</center>
Line 200: Line 161:
  
 
===Works Cited===
 
===Works Cited===
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.
 
 
 
Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. ''Design Patterns: Elements of Reusable Object-Oriented Software''. Boston, MA, USA: Addison-Wesley.
 
Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. ''Design Patterns: Elements of Reusable Object-Oriented Software''. Boston, MA, USA: Addison-Wesley.
ISO/IEC/IEEE. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
 
  
ISO/IEC/IEEE. 2011. Systems and software engineering - Architecture description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.
+
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.  
  
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering complex systems with models and objects''. New York, NY, USA: McGraw-Hill.  
+
ISO/IEC. 2007.''Systems Engineering – Application and Management of the Systems Engineering Process.'' Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.  
  
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.
+
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Architecture Description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.  
  
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
+
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill.  
  
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
+
OMG. 2010. ''OMG Systems Modeling Language Specification'', version 1.2, July 2010. Available at: http://www.omg.org/technology/documents/spec_catalog.htm.
  
 
===Primary References===
 
===Primary References===
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended practice for architectural description for software-intensive systems]]''. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/[[IEEE 1471]]-2000.
+
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended Practice for Architectural Description for Software-Intensive Systems]]''. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/[[IEEE 1471]]-2000.
  
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities,'' version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
+
 
ISO/IEC. 2007. Systems Engineering – Application and Management of the Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.
+
ISO/IEC. 2007. ''Systems Engineering – Application and Management of the Systems Engineering Process.'' Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.
  
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
  
 
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].
 
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].
  
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]].'' 3rd ed. Boca Raton, FL, USA: CRC Press.
+
Maier, M. and E. Rechtin. 2009. ''[[The Art of Systems Architecting]],'' 3rd ed. Boca Raton, FL, USA: CRC Press.
 
 
OMG. 2010. ''MDA Foundation Model''. Needham, MA, USA: Object Management Group. ORMSC/2010-09-06.
 
  
 
===Additional References===
 
===Additional References===
 
Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. ''A Pattern Language: Towns, Buildings, Construction''. New York, NY, USA: Oxford University Press.
 
Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. ''A Pattern Language: Towns, Buildings, Construction''. New York, NY, USA: Oxford University Press.
  
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.  
+
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.  
  
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
+
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill.
  
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill.  
+
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren
 +
Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
  
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.
+
Zachman, J. 2008.
 +
"John Zachman's Concise Definition of The Zachman Framework™."
 +
''Zachman International Enterprise Architecture.'' Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
  
 
----
 
----
<center>[[System Requirements|< Previous Article]] | [[System Definition|Parent Article]] | [[Architectural Design: Physical|Next Article >]]</center>
 
  
 +
<center>[[Functional Architecture|< Previous Article]] | [[System Architecture Design Definition|Parent Article]] | [[Physical Architecture|Next Article >]]</center>
 +
 +
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category:System Definition]]
 
[[Category:System Definition]]
{{DISQUS}}
 

Latest revision as of 22:40, 2 May 2024


Lead Authors: Alan Faisandier, Garry Roedler, Contributing Author: Rick Adcock


Logical Architecture Model Development may be used as a task of the activity "Develop candidate architectures models and views," or a sub-process of the System Architecture Design Definition process. Its purpose is to elaborate models and views of the functionality and behavior of the future engineered systemengineered system as it should operate while in service. The logical architecturelogical architecture model of a engineered system of interest (SoI)system of interest (SoI) is composed of a set of related technical concepts and principles that support the logical operation of the system. It may include a functional architecturefunctional architecture view, a behavioral architecturebehavioral architecture view, and a temporal architecturetemporal architecture view. Other additional views are suggested in architecture frameworksarchitecture frameworks, depending on the domain.

Note: The term Logical Architecture is a contraction of the expression Logical View of the System Architecture.

Concepts and Principles

Functional Architecture Model

A functional architecturefunctional architecture model is a set of functions and their sub-functions that defines the transformations performed by the system to complete its mission.

Function and Input-Output Flow - In the context of System Architecture, functions and input-output flows are architecture entities. A functionfunction is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematical notation of a function is y = ƒ( x ,t), in which y and x are vectors that may be represented graphically and t = time.

In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and its derived requirements, as well as the corresponding inputs and outputs of those functions. Generally speaking, there are two kinds of functions:

  1. Functions that are directly deduced from functional and interface requirements. These functions express the expected services of a system necessary to meet its system requirementssystem requirements.
  2. Functions that are derived and issued from the alternative solutions of the physical architecturephysical architecture model and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture model elements.

Functional Hierarchy/Decomposition of Functions - At the highest level of a hierarchy (Figure 1), it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0 in Figure 1). In order to understand, in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine.

This view of functional hierarchy represents a static view of functions which would be populated at different levels over a number of iterations, depending upon the synthesissynthesis approach used. In general, it is not created by a single top-down decomposition. A static functional hierarchy on its own does not represent how effectively the flows of inputs and outputs are exchanged, and may need to be viewed alongside the other models below.

Figure 1. Decomposition of Functions (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Behavioral Architecture Model

A behavioral architecturebehavioral architecture model is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements (ISO/IEC 26702:2007). A behavioral architecture model can be described as a set of inter-related scenarios of functions and/or operational modesoperational modes.

Control (Trigger) - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the on position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.

Scenario (of Functions) - A scenario of functions is a chain of functions that are performed as a sequence and synchronized by a set of control flows to work to achieve a global transformation of inputs into outputs, as seen in the figures below. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed by considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architecture models, it is appropriate to use diagrams as modeling techniques, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010). Figures 2 and 3 provide examples of these diagrams.

Figure 2. Illustration of a Scenario (eFFBD). (SEBoK Original)
Figure 3. Illustration of a Scenario (Activity Diagram). (SEBoK Original)

Operational Mode - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a scenario of modes, which is a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger, as demonstrated in Figure 4 below.

Figure 4. Scenario of Operational Modes (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Behavioral Patterns - When defining scenarios or behavioral architecture models, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment (Gamma, Helm, Johnson, and Vlissides 1995). A patternpattern can be represented with different notations. Behavioral patterns are classified into several categories, which can be seen in the following examples (see also SEBoK Part 2: Patterns of Systems Thinking):

  • Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.
  • Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.
  • Failure detection, identification, and recovery (FDIR) patterns - such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.

Temporal Architecture Model

A temporal architecturetemporal architecture model is a classification of the functions of a system that is derived according to the frequency level of execution. Temporal architecture models include the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.

Temporal and Decisional Hierarchy Concept - Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.

To be more specific, real-time systems and command-control systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:

  1. Disturbances on High Frequencies (bottom of figure 5) - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or failuresfailures.
  2. Changes on Low Frequencies (top of figure 5) - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
Figure 5. Temporal and Decision Hierarchy Levels (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Process Approach

Purpose

The purpose of the Logical Architecture Model Development is to define, select, and synthesize a system’s logical architecture model to provide a framework against which to verify that a future system will satisfy its system requirements in all operational scenarios, within which trade-offs between system requirements can be explored in developing such systems.

Generic inputs to the process include system requirements, generic architecture patterns that architects identify and use to answer requirements, outcomes from system analysis processes, and feedback from system verification and validation processes. Depending on the Life Cycle Model that is chosen, there will be iterations through which these inputs and outputs, and the relationships between them evolve and change throughout the process (see also Applying Life Cycle Processes).

Generic outputs from the process are either a single logical architecture model or a set of candidate logical architecture models together with the selected independent logical architecture model and a rationale for its selection. They include, at minimum, views and models. These involve functional, behavioral and temporal views, a traceability matrix between logical architecture model elements and system requirements.

Activities of the Process

Major activities and tasks performed during this process include the following:

  • Identify and analyze functional and behavioral elements:
    • Identify functions, input-output flowsinput-output flows, operational modesoperational modes, transition of modestransition of modes, and operational scenariosoperational scenarios from system requirements by analyzing the functional, interface, and operational requirements.
    • Define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result in the deduction of the necessary functions to use, transform, move, and generate the input-output flows.
  • Assign system requirements to functional and behavioral elements:
    • Formally characterize functions expressions and their attributes through the assignment of performance, effectiveness, and constraints requirements. In particular, study the temporal aspects from requirements to assign duration, response time, and frequency to functions.
    • Formally characterize the input, output, and control flows expressions and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements.
    • Establish traceability between system requirements and these functional and behavioral elements.
  • Define candidate logical architecture models for each candidate:
    • Analyze operational modes as stated in the system requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of modes. Eventually decompose the modes into sub-modes and then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral patterns.
    • Integrate these scenarios of functions in order to get a behavioral architecture model of the system (a complete picture of the dynamic behavior).
    • Decompose previously defined logical elements as necessary to look towards implementation.
    • Assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.
    • Define several levels of execution frequency for functions that correspond to levels of decision, in order to monitor system operations, prioritize processing on this time basis, and share out functions among those execution frequency levels to get a temporal architecture model.
    • Perform functional failure modes and effects analysis and update the logical architecture elements as necessary.
    • Execute the models with simulators (when possible) and tune these models to obtain the expected characteristics.
  • Synthesize the selected independent logical architecture model:
    • Select the logical architecture by assessing the candidate logical architecture models against assessment criteria (related to system requirements) and compare them, using the system analysis process to perform assessments and decision management process for the selection (see the System Analysis and Decision Management topics). This selected logical architecture model is called independent logical architecture model because, as much as possible, it is independent of implementation decisions.
    • Identify and define derived logical architecture model elements created for the necessity of design and corresponding with the derived system requirements. Assign these requirements to the appropriate system (current studied system or external systems).
    • Verify and validate the selected logical architecture models (using as executable models as possible), make corrections as necessary, and establish traceability between system requirements and logical architecture model elements.
  • Feedback logical architecture model development and system requirements. This activity is performed after the physical architecture model development process:
    • Model the allocated logical architecture to systems and system elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments.
    • Define or consolidate derived logical and physical elements induced by the selected logical and physical architecture models. Define the corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements into the requirements baselines of impacted systems.

Artifacts, Methods and Modeling Techniques

Logical architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable models):

  • Functional Models – These include models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced Functional Flow Block Diagrams (eFFBD), and the function analysis system technique (FAST).
  • Semantic Models- These include models such as entities-relationships diagrams, class diagrams, and data flow diagrams.
  • Dynamic Models – These include such models as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG 2010), and petri nets.

Depending on the type of domain (e.g. defense, enterprise), architecture frameworksarchitecture frameworks provide descriptions that can help to represent additional aspects/views of architectures - see the section 'Enterprise Architecture Frameworks & Methodologies' in Enterprise Systems Engineering Key Concepts. See also practical means for using general templates related to ISO/IEC/IEEE 42010 (ISO 2011).

Practical Considerations

As stated above, the purpose of the logical architecture model is to provide a description of what a system must be able to do to satisfy the stated need. This should help to ensure that the needs and/or concerns of all stakeholders are addressed by any solution, and that innovative solutions, as well as those based on current solution technologies, can be considered. In practice it is human nature for problem stakeholders to push their own agendas and for solution architects or designers to offer their familiar solutions. If a logical architecture model is not properly enforced with the chosen life cycle, it is easy for both problem and solution stakeholders to ignore it and revert to their own biases (see Part 5: Enabling Systems Engineering). This is exacerbated if the logical architecture model becomes an end in its own right or disconnected from the main lifecycle activities. This can occur either through the use of abstract language or notations, levels of detail, time taken, or an overly complex final architecture that does not match the purpose for which it was created. If the language, scope, and timeliness of the architecture are not matched to the problem stakeholder or solution providers, it is easier for them to overlook it. Key pitfalls and good practices which can help to avoid problems related to logical architecture models are described in the next two sections.

Pitfalls

Some of the key pitfalls encountered in developing logical architecture are provided in Table 1.

Table 1. Pitfalls with Logical Architecture Development. (SEBoK Original)
Pitfall Description
Problem Relevance The logical architecture model should relate back to the operational scenarios produced by mission analysismission analysis.
Inputs for Architecture Model The major input for architecture definition activity involves the set of system requirements and the instances in which they do not address the right level of architecture. The consequence is that the architect allows the requirements to fall to the side and invents a solution with what he or she understands through the input.
Decomposition Too Deep A common mistake made by many beginners in architecture consists of decomposing the functions too deeply or having too many functions and input/output flows in scenarios or in the functional architecture model of the current system block.
Not Considering Inputs and Outputs Together with Functions A common mistake is to consider only the actions supported by functions and decomposing them, while forgetting the inputs and the outputs or considering them too late. Inputs and outputs are integral parts of a function.
Considering Static Decomposition of Functions Only Static function decomposition is the smallest functional architecture model task and answers the basic question, "How is this done?" The purpose of the static decomposition is to facilitate the management of or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical architecture is close to complete.
Mixing Governance, Management, and Operation Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Logical architecture model should deal with behavioral architecture model as well as with temporal architecture model.

Proven Practices

Some proven practices gathered from the references are provided in Table 2.

Table 2. Proven Practices with Logical Architecture Development. (SEBoK Original)
Practice Description
Constitute Scenarios of Functions Before constituting a decomposition tree of functions, one must model the behavior of the system, establish scenarios of functions, and decompose functions as scenarios of sub-functions.
Analysis and Synthesis Cycles When facing a system that contains a large number of functions, one should attempt to synthesize functions into higher abstraction levels of functions with the assistance of criteria. Do not perform analysis only; instead, conduct small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.
Alternate Functional and Behavioral Views A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Utilize this to consider a behavioral view of the system that allows for the transition from one operational mode to another.
The Order to Create a Scenario of Functions When creating a scenario of functions, it is more efficient to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.

References

Works Cited

Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA, USA: Addison-Wesley.

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

ISO/IEC. 2007.Systems Engineering – Application and Management of the Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

OMG. 2010. OMG Systems Modeling Language Specification, version 1.2, July 2010. Available at: http://www.omg.org/technology/documents/spec_catalog.htm.

Primary References

ANSI/IEEE. 2000. Recommended Practice for Architectural Description for Software-Intensive Systems. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC. 2007. Systems Engineering – Application and Management of the Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Maier, M. and E. Rechtin. 2009. The Art of Systems Architecting, 3rd ed. Boca Raton, FL, USA: CRC Press.

Additional References

Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. A Pattern Language: Towns, Buildings, Construction. New York, NY, USA: Oxford University Press.

Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

The Open Group. 2011. TOGAF, version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.

Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024