#
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example v0.3.6\n"
"Report-Msgid-Bugs-To: mail@modelica.co.kr\n"
"POT-Creation-Date: 2023-01-28 22:37+0000\n"
"PO-Revision-Date: 2023-03-12 22:37+0000\n"
"Last-Translator: Baek Youngjin, mail@modelica.co.kr / Ha HyeonSu, <iloveyou934671@gmail.com>\n"
"Language-Team: modelica.co.kr <mail@modelica.co.k>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.6.0\n"


#: ../../source/components/subsystems/sub_interface.rst:2
msgid "Subsystem Interface"
msgstr ""
"하위 시스템 인터페이스(Subsystem Interface)"

#: ../../source/components/subsystems/sub_interface.rst:4
msgid ""
"The emphasis of this chapter was on how component models could be "
"organized into reusable subsystems.  As we saw in numerous examples in "
"this chapter, there is a common pattern that emerges.  Let's review "
"various aspects of subsystem models to understand this pattern better."
msgstr ""
"이 장에서는 구성 요소 모델을 재사용 가능한 하위 시스템으로 구성하는 방법에 중점을 두었는데, "
"수많은 예제에서 보았듯이 나타나는 공통 패턴이 있습니다. "
"이 패턴을 더 잘 이해하기 위해 하위 시스템 모델의 다양한 측면을 검토해 보겠습니다."
 
#: ../../source/components/subsystems/sub_interface.rst:10
msgid "Parameters"
msgstr ""
"파라미터(Parameters)"

#: ../../source/components/subsystems/sub_interface.rst:15
msgid ""
"Generally, parameters for a subsystem should be ``public``.  Normally, "
"all declarations in any ``model`` or ``block`` definition will be public "
"unless they come after the ``protected`` keyword.  In such cases, it is "
"still possible to declare something as public by adding the ``public`` "
"keyword and placing the declarations after it.  In other words:"
msgstr ""
"일반적으로 하위 시스템의 파라미터는 ``public`` 이어야 하고,"
"일반적으로 ``model`` 또는 ``block`` 정의의 모든 선언은 ``protected`` 키워드 뒤에 오지 않는 한 공개됩니다. "
"만약 ``protected`` 키워드 뒤에 오는 경우라고 해도, ``public`` 키워드를 추가하고 그 뒤에 선언을 배치하여 무언가를 ``public`` 으로 선언할 수 있습니다."
"다시 말해서 아래와 같이 표현 가능 합니다."


#: ../../source/components/subsystems/sub_interface.rst:36
msgid ""
"In the examples from this chapter, it was common to see the parameters "
"either at the start of the definition (where they are ``public`` by "
"default) or in a collection of declarations explicitly marked ``public``."
msgstr ""
"이 장의 예제에서는 정의의 시작 부분(여기서 기본적으로 ``public`` 임) 또는 명시적으로 ``public`` 으로 표시된 선언 모음에서 파라미터를 보는 것이 일반적이었습니다. "


#: ../../source/components/subsystems/sub_interface.rst:40
msgid ""
"Obviously, parameters are made public so that users of the subsystem can "
"have access to them.  We will see shortly, in our discussions on :ref"
":`sub-modifications` and :ref:`propagation`, how the values of these "
"parameters should be cascaded to lower level components.  But for now, "
"the main point is to recognize that parameter declarations are part of "
"the subsystem pattern."
msgstr ""
"분명히 파라미터는 공개되어 하위 시스템의 사용자가 액세스할 수 있습니다. "
":ref:`sub-modifications` 및 :ref:`propagation` 에 대해 뒤에서 논의 할 때 파라미터의 값이 어떻게 하위 수준 구성요소로 캐스케이드되어야 하는지 알게 될 것입니다. "
"그러나 지금은 파라미터 선언이 하위 시스템 패턴의 일부임을 이해 하는 것이 중요합니다."


#: ../../source/components/subsystems/sub_interface.rst:48
msgid "Connectors"
msgstr ""
"커넥터(Connectors)"

#: ../../source/components/subsystems/sub_interface.rst:50
msgid ""
"In some sense, connectors are what differentiates a subsystem from a "
"system model.  A system model is something that is complete and ready to "
"simulate and, as such, has no connectors because it does not expect to be"
" influenced by anything external.  A subsystem can encapsulate a large "
"hierarchy of components (and ultimately, equations).  But the fact that "
"it includes connectors indicates that it is really meant to be used as "
"part of some larger system.  Furthermore, as we have seen in the examples"
" of this chapter, because these connectors are meant to be connected to, "
"they should be ``public``."
msgstr ""
"어떤 의미에서 커넥터는 하위 시스템과 시스템 모델을 구분하는 것입니다."
"시스템 모델은 완전하고 시뮬레이트할 준비가 된 것이므로 외부의 영향을 받지 않기 때문에 커넥터가 없습니다."
"하위 시스템은 구성 요소(및 궁극적으로 방정식)의 대규모 계층 구조를 캡슐화할 수 있습니다."
"그러나 커넥터가 포함되어 있다는 사실은 실제로 일부 더 큰 시스템의 일부로 사용하기 위한 것임을 나타냅니다."
"또한 이 장의 예제에서 보았듯이 이러한 커넥터는 연결 대상이므로 ``public`` 이어야 합니다."


#: ../../source/components/subsystems/sub_interface.rst:61
msgid "Hierarchical Connections"
msgstr ""
"계층적 결합(Hierarchical Connections)"

#: ../../source/components/subsystems/sub_interface.rst:63
msgid ""
"Because subsystems are typically composed exclusively of components or "
"other subsystems, any physical interaction with that subsystem is usually"
" redirected to some nested component or subsystem.  We've seen this "
"pattern many times in this chapter where connectors at the subsystem "
"boundary really act as \"proxies\" for internal connectors.  A simple "
"example of this can be seen in the ``GearWithBacklash`` model:"
msgstr ""
"하위 시스템은 일반적으로 구성 요소 또는 다른 하위 시스템으로만 구성되기 때문에 해당 하위 시스템과의 모든 물리적 상호 작용은 일반적으로 일부 중첩된 구성 요소 또는 하위 시스템으로 리디렉션됩니다."
"이 장에서 하위 시스템 경계에 있는 커넥터가 실제로 내부 커넥터에 대한 "프록시" 역할을 하는 패턴을 여러 번 보았습니다. "
"이에 대한 간단한 예제는 ``GearWithBacklash`` 모델에서 볼 수 있습니다:"


#: ../../source/components/subsystems/sub_interface.rst:74
msgid ""
"Note that this ``connect`` statement connects ``flange_a``, a connector "
"instance that belongs to the subsystem, with ``inertia_a.flange_a``, a "
"connector instance belonging to the subcomponent ``inertia_a``.  This is "
"a common pattern in subsystem models and it can be easily recognized "
"because one of the connectors named in the ``connect`` statement includes"
" a \"``.``\" and the other one does not.  All the \"internal\" "
"connections that wire together internal components directly to other "
"internal components will have a \"``.``\" for both of the named "
"connectors in the ``connect`` statement, *e.g.,*"
msgstr ""
"이 ``connect`` 문은 서브시스템에 속한 커넥터 인스턴스인 ``flange_a`` 와 하위 구성요소인 ``inertia_a`` 에 속한 커넥터 인스턴스인 ``inertia_a.flange_a`` 를 연결합니다. "
"이는 서브시스템 모델의 일반적인 패턴이며 ``connect`` 문에 명명된 커넥터 중 하나는 "``.``" 을 포함하고 다른 하나는 포함하지 않기 때문에 쉽게 인식할 수 있습니다."
"내부 구성 요소를 다른 내부 구성 요소에 직접 연결하는 모든 "내부" 연결은 ``connect`` 문에서 명명된 커넥터 모두에 대해 "``.``"를 갖습니다. "
"예를 들면 아래와 같습니다."


#: ../../source/components/subsystems/sub_interface.rst:90
msgid "Equation Generation for Hierarchical Connections"
msgstr ""
"계층적 연결을 위한 방정식 생성(Equation Generation for Hierarchical Connections)"

#: ../../source/components/subsystems/sub_interface.rst:92
msgid ""
"In this book, the point has been made repeatedly (*e.g.,* in our "
"discussion of :ref:`acausal-connections`) that the sign convention for "
"``flow`` variables is such that a positive value for the ``flow`` "
"variable represents a flow into the component or subsystem.  At the same "
"time, we also pointed out that :ref:`system-connections` generate "
"equations that sum all the corresponding ``flow`` variables in the "
"connection set to zero."
msgstr ""
"예를 들어 이전에 다루었던 :ref:`acausal-connections` 에서 다룬 것 처럼, 이 책에서 ``flow`` 변수에 대한 부호 규약은 양수 값인 ``flow`` 변수가 구성 요소 또는 하위 시스템으로의 흐름을 나타냅니다. "
"동시에 system-connections이 0으로 설정된 연결에서 해당하는 모든 ``flow`` 변수를 합산하는 방정식을 생성한다는 점도 지적했습니다."


#: ../../source/components/subsystems/sub_interface.rst:100
msgid ""
"But, when dealing with hierarchical subsystem definitions there is a "
"modification to this rule.  For a subsystem, the sign convention for "
"``flow`` variables remains intact.  So, a positive value for the ``flow``"
" variable on a connector still represents a flow of a conserved quantity "
"into that component.  And it is still the case that a conservation "
"equation will be generated for each ``flow`` variable in a connection "
"set.  However, in that conservation equation, the sign for ``flow`` "
"variables on connectors belonging to internal components will have the "
"opposite sign as ``flow`` variables on connectors belonging to the "
"subsystem itself."
msgstr ""
"그러나 계층적 하위 시스템 정의를 처리할 때 이 규칙이 수정됩니다. "
"하위 시스템의 경우 ``flow`` 변수에 대한 부호 규칙은 그대로 유지됩니다. "
"따라서 커넥터의 ``flow`` 변수에 대한 양수 값은 여전히 해당 구성 요소로의 보존된 양의 흐름을 나타냅니다."
"그리고 여전히 연결 집합의 각 ``flow`` 변수에 대해 보존 방정식이 생성됩니다. "
"그러나 그 보존 방정식에서 내부 구성 요소에 속한 커넥터의 ``flow`` 변수에 대한 부호는 하위 시스템 자체에 속한 커넥터의 ``flow`` 변수와 반대 부호를 갖습니다."



#: ../../source/components/subsystems/sub_interface.rst:111
msgid ""
"To understand the implications of this, let us consider the following two"
" ``connect`` statements from the ``GearWithBacklash`` model:"
msgstr ""
"이것이 의미하는 바를 이해하기 위해 ``GearWithBacklash`` 모델의 다음 두 ``connect`` 문을 살펴보겠습니다."

#: ../../source/components/subsystems/sub_interface.rst:118
msgid "From these equations, we get the following two connection sets:"
msgstr ""
"이 방정식에서 다음 두 연결 세트를 얻습니다."

#: ../../source/components/subsystems/sub_interface.rst:120
msgid "**Connection Set #1**: ``flange_a``, ``inertia_a.flange_a``"
msgstr ""
"**연결 세트 #1**: ``flange_a``, ``inertia_a.flange_a``"


#: ../../source/components/subsystems/sub_interface.rst:121
msgid "**Connection Set #2**: ``idealGear.flange_b``, ``inertia_b.flange_a``"
msgstr ""
"**연결 세트 #2**: ``idealGear.flange_b``, ``inertia_b.flange_a``"

#: ../../source/components/subsystems/sub_interface.rst:123
msgid ""
"In each of these connection sets, there is a ``flow`` variable, ``tau``."
"  Using the rules for :ref:`system-connections` described previously, we "
"might expect the following two equations to be generated for the ``flow``"
" variables on these connectors:"
msgstr ""
"이러한 각 연결 세트에는 ``flow`` 변수인 ``tau`` 가 있습니다."
"앞에서 설명한 :ref:`system-connections` 에 대한 규칙을 사용하면 이러한 커넥터의 ``flow`` 변수에 대해 다음 두 방정식이 생성될 것으로 예상할 수 있습니다."


#: ../../source/components/subsystems/sub_interface.rst:133
msgid ""
"However, in our previous discussion on :ref:`system-connections`, all the"
" components were at the same hierarchical level (*i.e.,* as "
"``idealGear.flange_b`` and ``inertia_b.flange_a`` are).  But with "
"subsystem models, this isn't always the case.  And, as described a moment"
" ago, for cases where the connections are at different levels, we need to"
" introduce a sign difference for contributions at different levels.  "
"Taking that into account, **the actual equations that will be generated**"
" will be:"
msgstr ""
"그러나 시스템 연결에 대한 이전 논의에서 모든 구성 요소는 동일한 계층적 수준(*즉,* ``idealGear.flange_b`` 및 ``inertia_b.flange_a`` )에 있었는데, "
"하위 시스템 모델의 경우 항상 그런 것은 아닙니다. "
"그리고 조금 전에 설명한 것처럼 연결이 서로 다른 수준에 있는 경우 서로 다른 수준에서 기여도에 대한 부호 차이를 도입해야 하는 것 입니다. "
"이를 고려하여 **생성될 실제 방정식** 은 다음과 같습니다."


#: ../../source/components/subsystems/sub_interface.rst:147
msgid ""
"Note the minus sign in front of the ``flange_a.tau``.  Remember that "
"``flange_a`` is meant to be acting as a proxy for ``inertia_a.flange_a``."
"  If that is the case, then by changing the sign of ``flange_a.tau``, the"
" first equation above can be transformed into:"
msgstr ""
"``flange_a.tau`` 앞에 있는 빼기 기호에 유의 해야 합니다."
"``flange_a`` 는 ``inertia_a.flange_a`` 의 프록시 역할을 한다는 것을 기억해보면, "
"``flange_a.tau`` 의 부호를 변경하여 위의 첫 번째 방정식을 다음과 같이 변환할 수 있습니다."


#: ../../source/components/subsystems/sub_interface.rst:157
msgid ""
"In other words, by introducing the sign change on ``flange_a.tau``, any "
"conserved quantity the flows in through ``flange_a`` **also** flows into "
"``inertia_a.flange_a``, which is exactly what we expect from this kind of"
" \"proxy\" relationship."
msgstr ""
"즉, ``flange_a.tau`` 에 부호 변경을 도입함으로써 ``flange_a`` 를 통해 유입되는 모든 보존된 양 **또한** ``inertia_a.flange_a`` 로 유입됩니다. "
"이것이 바로 이러한 종류의 "프록시" 관계에서 기대하는 것입니다."


#: ../../source/components/subsystems/sub_interface.rst:163
msgid "Implementation"
msgstr ""
"구현(Implementation)"


#: ../../source/components/subsystems/sub_interface.rst:165
msgid ""
"A subsystem model is typically just a wrapper around a collection of "
"components.  As we've discussed already in this section, the parameters "
"and connectors exposed by the subsystem are ``public`` because that is "
"how users of the subsystem will interact with it."
msgstr ""
"하위 시스템 모델은 일반적으로 구성 요소 모음을 둘러싼 래퍼입니다. "
"이 섹션에서 이미 논의한 것처럼 하위 시스템의 사용자가 상호 작용하는 방식이기 때문에 하위 시스템에 의해 노출된 파라미터와 커넥터는 ``public`` 입니다."


#: ../../source/components/subsystems/sub_interface.rst:170
msgid ""
"The actual internal details of the subsystem represent the implementation"
" of the subsystem.  This implementation is generally a collection of "
"components and other subsystems that are connected together with one or "
"more of the their connectors connected to the subsystem's connectors."
msgstr ""
"서브시스템의 실제 내부 세부사항은 서브시스템의 구현을 나타냅니다. "
"이 구현은 일반적으로 하위 시스템의 커넥터에 연결된 하나 이상의 커넥터와 함께 연결된 구성 요소 및 기타 하위 시스템의 모음입니다."

#: ../../source/components/subsystems/sub_interface.rst:176
msgid ""
"Normally, these implementation details are best hidden from the end user "
"of the subsystem.  To accomplish this, all non-``parameter`` declarations"
" in a subsystem are typically marked as ``protected``. There are two main"
" reasons for doing this.  First, it hides implementation details from the"
" users of the subsystem model.  This has the effect of simplifying the "
"interface down to just parameters and connectors and avoids mixing things"
" the user really needs to know with things that they do not need to know "
"(or even should not know). Another reason to make the implementation "
"details ``protected`` is to provide the flexibility to improve or "
"refactor the implementation in the future.  If users are allowed to "
"reference the implementation details, that means they will then (perhaps "
"even unintentionally) become **dependent** on them.  As a result, if they"
" change in the future it will break the end user's models."
msgstr ""
"일반적으로 이러한 구현 세부 정보는 하위 시스템의 최종 사용자에게 가장 잘 숨겨집니다. "
"이를 달성하기 위해 하위 시스템의 모든 비 ``parameter`` 선언은 일반적으로 ``protected`` 으로 표시됩니다."
"이렇게 하는 데는 두 가지 주요 이유가 있습니다. "
"첫째, 하위 시스템 모델 사용자에게 구현 세부 정보를 숨깁니다. "
"이는 인터페이스를 파라미터 및 커넥터로 단순화하는 효과가 있으며 사용자가 실제로 알아야 할 사항과 알 필요가 없는(또는 알 필요가 없는) 사항이 혼합되는 것을 방지합니다. "
"구현 세부 사항을 ``protected`` 하는 또 다른 이유는 향후 구현을 개선하거나 리팩토링할 수 있는 연성을 제공하기 위해서입니다. "
"사용자가 구현 세부 정보를 참조하도록 허용되면 이는 사용자가 (의도하지 않게) 해당 구현 세부 정보에 **의존** 하게 됨을 의미합니다. "
"결과적으로 나중에 의도하지 않게 변경되면 최종 사용자의 모델이 손상됩니다.        "


#~ msgid "**Connection Set #1**: `flange_a`, `inertia_a.flange_a`"
#~ msgstr ""

#~ msgid "**Connection Set #2**: `idealGear.flange_b`, `inertia_b.flange_a`"
#~ msgstr ""

#~ msgid ""
#~ "However, in our previous discussion on"
#~ " :ref:`system-connections`, all the "
#~ "components were at the same hierarchical"
#~ " level (*i.e.,* as `idealGear.flange_b` and"
#~ " `inertia_b.flange_a` are).  But with "
#~ "subsystem models, this isn't always the"
#~ " case.  And, as described a moment"
#~ " ago, for cases where the connections"
#~ " are at different levels, we need "
#~ "to introduce a sign difference for "
#~ "contributions at different levels.  Taking "
#~ "that into account, **the actual "
#~ "equations that will be generated** will"
#~ " be:"
#~ msgstr ""

#~ msgid "public"
#~ msgstr ""

#~ msgid "protected"
#~ msgstr ""

