The principle of the Logical Architecture (LA), commonly called logical architecture, starts to “open the box” by implementing the big decisions of the solution, in terms of principles of construction, and ways to fulfil the expectations of stakeholders; it is then formalized by means of a decomposition into abstract structural elements called Logical Components, and principles of behaviour and interaction between one another, in response to the previous needs.
The definition of the LA consists mainly of a comparison between the needs expressed in previous perspectives, a functional analysis describing the system behaviour chosen to satisfy requirements, and a structural analysis intended to identify the Logical Components that will constitute the system, taking the chosen constraints and structuring principles into account.
The LA is therefore a first general vision, moderately detailed, somehow an abstraction, of what the architecture of the system will be.
Its definition is deliberately maintained at a quite coarse-grained level of detail, just enough to be able to make major decisions for guiding the design, nothing more.
In addition to the identification of the major “imposed” factors constraining the definition of the architecture, the major design decisions structuring it must also be defined and formalized.
Any design detail or accuracy that does not influence the construction or choice decisions of the LA is not justified and will be described later in the physical architecture.
The important rule to comply with is to force ourselves to exclude all technological considerations or implementation choices. This will be the very objective of the Physical Architecture to define the “true” concrete components, which will constitute the System.
Excluding all technological considerations as a design choice will not however prevent us from beginning to take the Non-Functional Constraints into account; Operating Safety, Performance, etc., requirements can thus lead us to group the Functions together in different Components.
Logical Architecture must be stable throughout the whole duration of the project. This will probably not be the case for Physical Architecture, especially if the System must have a long lifespan, due to the technological novelties that will occur and the new Physical Components that may cause large parts of the architecture to be called into question.
Main activities:
Define high-level architectural drivers and build the component-based system structuring.
Define the behavioural principles.
Trade-off analysis and select best compromise architecture.
3. 3
1. Introduction
The System Analysis [1] described before, consisted of functionally analysing the System seen as a
“black box” to specify its expected behaviour, as well as exhaustively identifying important external
exchangeswiththe Actors.
The principle of the Logical Architecture (LA),commonlycalledlogicalarchitecture,startsto“openthe
box” by implementing the big decisions of the solution, in terms of principles of construction, and
waysto fulfil the expectationsof stakeholders;itisthenformalizedbymeansof a decompositioninto
abstract structural elements called Logical Components, and principles of behaviour and interaction
betweenone another,inresponse tothe previousneeds.
The definition of the LA consists mainly of a comparison between the needs expressed in previous
perspectives, a functional analysis describing the system behaviour chosen to satisfy requirements,
and a structural analysis intendedtoidentifythe Logical Componentsthatwill constitute the system,
taking the chosenconstraintsand structuring principles into account.
The LA is therefore a first general vision, moderately detailed,somehow an abstraction, of what the
architecture of the systemwill be.
Itsdefinitionis deliberatelymaintainedataquite coarse-grainedlevelof detail,justenoughtobe able
to make majordecisions forguiding the design,nothingmore.
In addition to the identification of the major “imposed” factors constraining the definition of the
architecture,the major designdecisionsstructuring it must also be definedandformalized.
Anydesigndetail or accuracy that doesnotinfluence the constructionor choice decisionsof the LA is
not justifiedandwill be describedlater in the physical architecture.
The importantrule to comply with is to force ourselvesto exclude all technological considerationsor
implementation choices. This will be the very objective of the Physical Architecture to define the
“true” concrete components,whichwill constitute the System.
Excluding all technological considerations as a design choice will not however prevent us from
beginning to take the Non-Functional Constraints into account; Operating Safety, Performance,etc.,
requirementscanthuslead usto group the Functionstogetherin differentComponents.
Logical Architecture must be stable throughout the whole duration of the project. This will probably
not be the case for Physical Architecture, especially if the System must have a long lifespan, due to
the technological novelties that will occur and the new Physical Components that may cause large
parts of the architecture to be called into question.
Main activities:
Define high-levelarchitecturaldrivers andbuild the component-basedsystemstructuring.
• Define the behaviouralprinciples.
• Trade-off analysisand selectbestcompromise architecture.
4. 4
2. Logical Architecture (LA)
“Howthe system will work to meetexpectations”.
As described in the Arcadia method sections Logical Architecture (LA), the previous System Analysis
consistedof functionallyanalysingthe Systemseenasa“black box”to specifyitsexpectedbehaviour,
as well as exhaustively identifyingimportant external exchanges with the Actors the starts to “open
the box”by implementingthe bigdecisionsof the solution,in termsof principlesof construction,and
waysto fulfil the expectationsof stakeholders.
2.1. Logical Architecture concepts
In the sectionbelow,it will be describedthe main Logical Architecture concepts.
Figure 2.1: Logical Architecture main concepts
3. Logical Architecture artefacts and activities matrix
Below are captured the main activities to be performed when defining the high-level Logical
Architecture.
Let’srecall thatthe Capellatoolautomatically createsaRealizationLink betweeneachLogicalelement
(Function,FunctionalExchange,FunctionalChain) andthe Source Systemelement.Alsorecallthatthe
transitions are iterative and incremental and that noticed that a System Function is missing when
5. 5
workingon the Logical level,it must be absolutelyaddedto the Systemlevelandapply the transition
again.
Step Matrix Diagram Output Step description
Step1 LA1 CRB Capabilities Realization at Logical Architecture
Step2
LA3
LFBD Define Logical Architecture Functions
Step3 LDFB Define FunctionalExchanges
Step4
LA4
LCBD Define logical components
Step5 LAB Allocate Logical Functionsto Logical Components
Step6 LA2
LFCD
FS
ES
Describe Capability Realizations with Functional
Chains andScenarios
Table 3.1: Logical Architecture activities andartefacts
3.1. Capabilities Realization at Logical Architecture
One of the first activities to performwhenmovingto the Logical Architecture is to carry on the work
performed at the System level. Hence, transitions of the System Capabilities can be performed by
Capella from the Activity Explorer. Create the diagram Contextual Realization Blank (CRB) and verify
that all Logical Actors are involvedin at leastone Capability Realization.
Activities:
• Verifythatall actors are involved with at least one Capability Realization.
Modellingtips:
• Transition SystemCapabilities – Performan Automatedtransitionof the SystemAnalysis
Capabilities.
Figure 3.1: [CRB] Logical Capability Realization Blank
3.2. Define Logical Architecture Functions
WhenSystemCapabilities are transitioned,SystemFunctionsshouldalso be transitionedand refined
in newLogical Functions,refinedfunctionscan be groupedunderrelated functionality(e.g.,monitor
or control functionsgroup).
6. 6
When modelling activities are performed in the model it is quite often for a modeler to add new
functions in other diagrams, for example, Logical Architecture Blank (LAB) diagram. As a good
modellingpractice the Logical FunctionsBreakdownDiagram(LFBD) shouldbe revisitedandorganized
and definedfunctionsinvolvement,if needed.
AsmentionedatSystemAnalysis,itis a good practice to change the colour of the transitionedSystem
Functions from green to white in the (LFBD), this can help the modeler to visually identify what
functionsare relatedto the SystemAnalysislayerand consideredtobe furtherrefined.
Activities:
• Refine SystemFunctionsinnewLogical Functions.
• Identifycontainments(hierarchy) fornew LogicalFunctions.
• Verify the LFBD diagram is still correct and consistent when new functions are added during
the logical architecture design.
Modellingtips:
• Transition SystemFunctionsin new Logical Functions.
• In the LFBD, change the transitioned system functions background to white, it will help to
identifywhich functionswere capturedatsystemlayerand transitionedto the logical layer.
In the figure below it can be seen that one System Function can be refined into several Logical
Functionsand newfunctionscan be grouped(i.e.,involved) indifferentfunctionsgrouping.
White functionsrefertoSystemFunctionstransitioned.
Figure 3.2: [LFBD] Logical FunctionsBreakdownDiagram
3.3. Define Functional Exchanges
Whenfunctionshave beenidentified,functionalexchangescanbe definedbetween“leaf”functions.
Remember,thatonlyleaf functionsshould have Functional Exchanges and later allocated to a Logical
Component.
When a System Function is refined in new Logical child Functions, Functional Ports belonging to the
SystemFunctionsshouldbe delegated.
Create Logical DataflowBlank (LDFB) thatdescribesaCapability Realization with functionsinvolved or
anLDFB thatinvolvesallthe Logical Functions. The creationof LDFBapproachdependsonthemodeler
andstakeholderneeds.Forexample,astakeholderneedstofocusandanalyse aspecificaspectof the
functionsand remove fromthe diagram all otherfunctions forsimplicity.
Activities:
7. 7
• IdentifyFunctionalExchangesbetweenLogical Functions.
• Diagrams can be createdand focusedinone aspectof the behaviour,forexample todescribe
a capability realization.
Modellingtips:
• Systemfunctionswillbe decomposedinmore detailat logical layer.Do notforgettodelegate
(i.e., move) function ports from a transitioned system function to the correspondent logical
decomposedchildfunction.
Figure 3.3: [LDFB] Logical Dataflow Blank
3.4. Define logical components
Logical structure can nowbe definedbyidentifyingstructural elementscalledLogical Componentsby
forcing ourselvestoexclude alltechnologicalconsiderationor implementationchoice.Asdescribedin
a section above, Logical Architecture is the first layer of the solution and should capture high-level
architectural aspects excluding any technological aspects. Technological considerations will be
consideredatthe Physical Architecture layer.
Decompose the System into Logical Components and identify parent – child components hierarchy
relationship.
As a good modelling approach revisit the Logical ComponentBreakdownDiagram(LCBD) and ensure
this diagram is still correct andconsist of.That is, duringmodellingactivities new Logical Components
can be created in different diagrams (e.g., LAB diagram) and new Logical Components involvement
may needtobe verifiedfor consistency.
Arcadia rule:
8. 8
• The notionof SubsystemdoesnotexistinArcadia.InSystemAnalysis,itcanonlyhave a single
model elementcalled System.If the modeller wantsto modelSubsystems,there isthe need
to be on an internal:Logical or PhysicalArchitecture level.If thenthere is the needtobe able
to then consider each Subsystem as a full member System with its own System Analysis,
Logical thenPhysical Architecture,it must modeleachSubsystemina specificCapella model.
The ideal being to maintain coherency between the external Exchanges of the different
Subsystemsinthe “global” model of the encompassingSystem; this is exactly what it can be
achievedwiththe SystemtoSubsystemTransitionadd-on.
Activities:
• Identifyand define logical components.
• Identifylogical componentshierarchy(i.e.,containments).
Modellingtips:
• Logical componentsimplementfunctionsthatworktogethertoachieveacommongoalwithin
a component.
• The important rule to comply with is to force ourselves to exclude all technological
considerationsor implementationchoices.
• The functionalanalysis performedatthisstage shouldnotbe regardedasasimple refinement
of the SA,but as the resultof the systemdesignin termsof its behaviours in response tothis
need.
• Revisit the (LCBD) diagram to ensure correctness.
Figure 3.4: [LCBD] Logical ComponentsBreakdownDiagram
3.5. Allocate Logical Functions to Logical Components
Whenlogical functionsandcomponentshavebeenidentifiedandcaptured,functionscanbe allocated
to the relevant component. To allocate functions to components a Logical Architecture Blank (LAB)
diagram can be created and perform the task. As a reminder Arcadia and the approach described in
this documentdonot impose anysequence of activities,hence,it can be createdthis diagram before
othersdescribedabove.
During the elaborationof this diagram, new functions can be identifiedandcaptured as this diagram
provides functionsallocated to component,hence,functionsare now capture in context. Hence,the
verification process described above still applies when new functions and components are captured
in a LAB diagram.
The LAB diagram allows to create Logical Component exchange between Logical Components that
implementsFunctionalExchanges. Thatis,LogicalComponentsisthe meansLogicalFunctionsdohave
to communicate with otherLogical Components.
9. 9
Different LAB diagrams can be produced that reflect a stakeholder needs and expectations, focused
in one aspect of the System-of-Interest(SoI) architecture or showingpart of the Logical Architecture
by showingonlycomponentsexchangesbyapplyingfiltersprovidedbythe Capella tool.
Activities:
• Allocate Logical Functionsto Logical Components.
• Define ComponentsExchange.
• Allocate FunctionPorts to ComponentExchange
Modellingtips:
• Logical Function Ports of the same non-functional type (e.g., Electrical Power) should be
allocated to the same Logical ComponentPort.
• Whencomponentsexchangesare defined,itcan apply the filter: “Hide functions”to showin
the diagram componentsexchangesonly.
• As a good approach re-visit the diagrams that capture functions (LFBD) and components
(LCBD) breakdownandverifyif diagrams are still correctand consistent.
Figure 3.5: [LAB] Logical Architecture Blank
3.6. Describe Capability Realizations with Functional Chains and Scenarios
A Capability Realization can be described byFunctional Chainand scenarios.
Functional Chains and scenarios that describe a Capability Realization can be identified and defined
following a similar approach to the definition of System Functional Chains and scenarios at System
layer.
Activities:
• Identifyfunctionsinvolvedina functionalchain that describesa Capability Realization.
Modellingtips:
• Whena Functional Chain is created,it can be transitionedand createda Functional Scenario.
• A Functional Scenariocan thenbe transitionedandcreatedan Entity Scenario.
• Transitionedfunctionalchainsmightneedtobe “reconstructed”asthe LogicalFunctionswere
refined at logical architecture and Functional Chainsmight have turnedas invalid.
10. 10
Figure 3.6: Logical Functional Chain and Scenarios definition
3.7. Logical Architecture traceability flow
Similarly, to System Analysis, in the figure below the model elements traceability and diagrams
relationship is captured:
• A Logical Capability Realization can be described by Functional/Entity Scenarios and/or
Functional Chains.
• A Functional/EntityScenario andFunctional Chains involve Logical Functions.
• Logical Functionsare allocated to Logical ComponentandActors.
Again,the presentedflowof diagramsshowsareasonedstep-by-stepchoice intermsof activities and
diagrams. Arcadia and this guide do not impose any order on the diagram’s elaboration, both are
flexible and can be elaborated in any sequence. It is the modeler choice and project needs that may
drive the architecture design.
12. 14
Conclusion
The above Arcadia Logical Architecture guided step-by-step method, describes a reasoned step-by-
step choice in terms of activities and diagrams. It can be seen in several of its diagrams traceability
that is providedand inherentin the model.
As described, the principle of the Logical Architecture starts to “open the box” by implementing the
big decisionsof the solution,in termsof principles of construction,and waysto fulfil the expectations
of stakeholders. Any technological decisions should not be captured at this level, this is part of the
Physical Architecture to be describedin a future article.
It was provided some Capella tool modelling tips that should be followed to promote correctness of
the modeland some transitions that helpand accelerate the modelling effort.
![Contents
1. Introduction.......................................................................................................................... 3
2. Logical Architecture (LA)........................................................................................................4
2.1. Logical Architecture concepts......................................................................................... 4
3. Logical Architecture artefacts and activities matrix..................................................................4
3.1. Capabilities Realization at Logical Architecture ................................................................ 5
3.2. Define Logical Architecture Functions ............................................................................. 5
3.3. Define Functional Exchanges .......................................................................................... 6
3.4. Define logical components ............................................................................................. 7
3.5. Allocate Logical Functions to Logical Components............................................................ 8
3.6. Describe Capability Realizations with Functional Chains and Scenarios.............................. 9
3.7. Logical Architecture traceability flow ............................................................................ 10
Conclusion ................................................................................................................................. 14
Bibliography ............................................................................................................................... 15
Figures
Figure 2.1: Logical Architecture main concepts............................................................................... 4
Figure 3.1: [CRB] Logical Capability Realization Blank ......................................................................5
Figure 3.2: [LFBD] Logical Functions Breakdown Diagram................................................................ 6
Figure 3.3: [LDFB] Logical Dataflow Blank....................................................................................... 7
Figure 3.4: [LCBD] Logical Components Breakdown Diagram........................................................... 8
Figure 3.5: [LAB] Logical Architecture Blank.................................................................................... 9
Figure 3.6: Logical Functional Chain and Scenarios definition ........................................................ 10
Figure 3.7: Logical Architecture model elements traceability and diagrams relationship ................. 11
Table
Table 3.1: Logical Architecture activities and artefacts....................................................................5](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)