Specification of an Architecture Meta-Model - SPES 2020
Specification of an Architecture Meta-Model - SPES 2020
Specification of an Architecture Meta-Model - SPES 2020
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Specification</strong> <strong>of</strong> <strong>an</strong> <strong>Architecture</strong> <strong>Meta</strong>-<strong>Model</strong><br />
to the structural elements where they are needed by using requirements traceability<br />
me<strong>an</strong>s as described in Section 2.3. The <strong>SPES</strong>MM methodology paper (to appear)<br />
gives a detailed description how to use abstraction levels, perspectives, <strong>an</strong>d aspects in<br />
a system model.<br />
2.1.4.1 System<strong>Model</strong><br />
The System <strong>Model</strong> <strong>of</strong> the <strong>SPES</strong>MM aims to provide the same features as the System<br />
Package in EAST-ADL2. It is supposed to be a template for how engineering information<br />
is org<strong>an</strong>ized <strong>an</strong>d represented. The org<strong>an</strong>ization thereby refers to the presence<br />
<strong>of</strong> different abstraction layers <strong>an</strong>d system aspects. While the number <strong>an</strong>d names <strong>of</strong><br />
abstraction layers <strong>of</strong> EAST-ADL2 are fixed, <strong>SPES</strong>MM provides a variable number <strong>of</strong><br />
abstraction layers which c<strong>an</strong> have arbitrary names. The system model only referes to<br />
the topmost abstraction level to start with.<br />
Through the abstraction level names <strong>an</strong>d the artifacts associated with each abstraction<br />
level the system architect c<strong>an</strong> distinguish concerns <strong>an</strong>d relev<strong>an</strong>ce for stakeholders.<br />
A system model is a package <strong>an</strong>d c<strong>an</strong> therefore be arbitrarily structured by other subpackages<br />
<strong>an</strong>d contain reusable elements. As a package a system model c<strong>an</strong> belong to<br />
<strong>an</strong>other package if there shall be a hierarchy <strong>of</strong> system models available.<br />
Generalizations: Package<br />
Aggregations<br />
• abstractionLevel : AbstractionLevel [1..*] The set <strong>of</strong> abstraction levels in the<br />
system development process.<br />
Associations<br />
• topLevel : AbstractionLevel [1] The highest level <strong>of</strong> abstraction <strong>of</strong> the development<br />
process. Serves as <strong>an</strong> entry point for the process.<br />
2.1.4.2 AbstractionLevel<br />
Related to the ISO/IEC 42010 IEEE Std 1471-2000 St<strong>an</strong>dard for Systems <strong>an</strong>d S<strong>of</strong>tware<br />
Engineering – Recommended Practice for Architectural Description <strong>of</strong> S<strong>of</strong>tware-<br />
Intensive Systems [ISO07] <strong>an</strong> abstraction layer is a gr<strong>an</strong>ularity/detail viewpoint constraining<br />
a component view based on level <strong>of</strong> detail or gr<strong>an</strong>ularity criteria <strong>an</strong>d regarding<br />
descriptive me<strong>an</strong>s. Abstraction levels are ordered, r<strong>an</strong>ging from simplified to very detailed.<br />
At least one level <strong>of</strong> abstraction contributes to a design process phase. <strong>Model</strong>s<br />
c<strong>an</strong> be created in one abstraction level but also be referenced from different abstraction<br />
levels. Such models are part <strong>of</strong> different perspectives which c<strong>an</strong> be decomposed<br />
independently.<br />
14/135
Change language