# A Method for Enterprise Architecture Model Slicing
## 4 A Method for EA Model Slicing
### Adapting PS to Develop EAS  
The following insights about the **commonalities** between the two areas (Program reuse and EA reuse) support us in deriving parts of EAS similar to PS.  
* Goal: Both PS and our proposed EAS aim to **save costs** on software engineering tasks. For PS, such tasks are program re-development and program maintenance. While for EAS, such tasks might include new model development and maintenance.
* Solution: To save costs, both methods exclude irrelevant lines of codes/model components that are not \"of interest\" and try to find the **minimum subset** of the original program/repository.
* Criteria pattern: Criteria are needed to clearly define how to select the minimal subset, namely, what defines the \"interest.\" Both PS and EAS employ a similar criteria pattern specifying **a location** (statement/view) and **a variable/component**.
* Algorithm premise: Both algorithms of PS and EAS rely on a **graph-like structure** provided by the original program/repository. PS depends on a control flow graph with nodes and edges. In comparison, an EA model repository consists of components and relations between them and is naturally organized as a graph.  
In addition, we require more **unique features** to slice EA data.
* Flexible parts of Criteria: Criteria define what makes a subset of the original program/repository concerning a criterion of <S, V> be \"of interest.\" For PS, in a slice, the value of V at the position of S should remain the same as that in the original program. Such a **precise** and **unambiguous** criterion could be found for PS because programs are usually created by professional programmers, executed by computers, and therefore are formal and rigorous. However, finding a similar criterion for EAS might not be easy. Under many circumstances, models are **not accurately** defined or used because they are usually created by and used for humans who might not have specific expertise. In other words, we might not be able to define the criteria in EAS precisely due to the diversity of metamodels, inconsistent model data, and different requirements of using a slice in advance. Therefore, the EAS method might need to allow more flexibility (to allow for manual screening) for the criteria in EAS.
* Flexible parts of Algorithms: To address the flexible part of the criteria, we propose to introduce manual intervention in addition to a computerizable slicing algorithm. While the computerizable algorithm captures the fixed and accurate part of the criteria,the manual screen examines the flexible parts and decides on inclusion/exclusion based on the actual settings.  
To summarize, the original version of PS starts from a location/statement, then continuously finds new points/statements along the edge/flow in the program's control or data flow and judges whether it is relevant to the requirement according to the pre-defined criteria, and when to stop traversing. Our proposed EAS works similarly. The difference is that the traversal and judgment of PS are automated, while the judgment in our version is partially manual. As mentioned above, the data in the EAR may have some inconsistent issues, such as missing attributes or misuse of similar relations. We perform automated traversal and preliminary screening with pre-set criteria and then use manual screening to handle data inconsistencies.